A new place and the same old issues
As stated on January 10, 2012
I started my first new job in almost five years recently. With it came a change from working with a single organization to the world of client services. Mobile services to be precise.
I’m on the newest team there – the Web Developers. It is always funny to me that the Web Developers are the new kids on the block in mobile (according to the majority of people with whom I interact). With the company telling us we have to agree and choose a framework such as Sencha Touch (since these directions are coming from people in the native world, not the open, progressively enhanced web world I like to frequent), there are many conversations that have taken place where tempers have flared a bit with different members. But something else has been bugging me much more, and it has occurred ever since I first learned HTML and took my first computer science class in college. People are ashamed of their code.
Since I started, I’ve heard multiple people tell me to forgive their code because it’s not that great. If only I had had a different requirement I would have supported that browser earlier. I always told myself I would stand by my code, but when I heard myself make an excuse to my coworker for my Javascript (“Full disclosure: I’ve never worked with JQuery Mobile before, and that’s what the original developer I took over for started with, so I think I completely butchered the MVC pattern that was trying to be achieved”) I realized something was wrong, and it bothered me greatly.
It might just be the organizations I have worked with, but I have always heard more people make excuses or claim they just wrote the worst code of the their (“but at least it works!”) than those who are proud of their work. Why do we do it?
I hate feeling embarrassed to show my code to other people. But it happens. My first code review in the career world was horrible. I was proud of what I wrote, but then another developer was told to find at least five things to improve. Whether or not there was anything to really improve. So arbitrary best practices were thrown at me, and my non-technical boss looked at the review with disappointment in my skill. Beyond that, we would have demo days where we would share code with each other that we were proud of, and people would start interrupting (“you should have used a static final synchronized class instead of a static final class!”).
From college and beyond, I’ve studied/worked with people who will look at legacy code and openly mock it – even if it’s really not that bad. It’s not in their preferred style so it must suck. Everyone does it. But so many times, the person who worked on the code is there. Maybe they worked on it five years earlier when they were a junior developer, forgive them. Maybe they were in a time crunch and management was pushing the timeline first, forget it. Maybe it’s better than what you would have done, so be quiet.
So I wonder if that’s it. There are a lot of great developers out there who write great code. There are a lot more out there who write great code but who might have missed some optimization here or there. We should all be proud of what we do – especially if it works. There’s always room for improvement – for everyone. Especially in this day and age. The iPhone has only been out for less than half a decade. Mobile computing is still young. Heck, the web is still young. What was great a great coding technique last year may be irrelevant the next. I take pride in seeing things work, and seeing users interact with my work. Even if I declare one Javascript variable in the middle of a method. Or if my previous life as a Java developer makes me mess up my terminology for Javascript functions.