1 08 2011
Lessons Learned as a Developer
There are a few things I’ve had to learn the hard way over the years as a developer. In 2006 I was working as a Network Admin and decided to start programming in my free time. In 2007 I took a job working for an e-commerce company and really cut my teeth fast diving head first into a fairly complex LAMP environment. In 2010 I switched jobs for another e-commerce and again had to relearn some of the same lessons. I’m writing this blog more for myself, but its certainly a worthy read for novice, intermediate, and maybe even some jaded senior level programmers.
Your Boss Probably Doesn’t Really Know What They Want
This isn’t a jab at your boss. Sure they know what they want, but they don’t know how they want it. They may know what they want it do in scenario A and B, but never gave C, D, and E much thought. If you take what they want at face value and just start programming without thinking about it you are going to create more work in the end. This can also lead to hacks entered into your code base down the line to fix little business logic errors.
The worst part about not realizing this FACT is that it will make your project feel like its never ending. When a project wasn’t thought out you get into a cycle of not just break-fix, but realize-implement. You don’t get to enjoy that satisfaction of “Yippie I finished this awesome project and now get to move onto the next awesome thing.” It can be deflating and I think lots of developers and organizations (me very much so included) fall into this cycle.
Thoroughly plan what you’re going to do and try and plan out scenarios of failure in the process. It’s easy to just start hammering away at your keyboard and you get that instant gratification of getting something done, but in the long run you’ll enter into a never ending cycle. I’m not saying this is always avoidable, but its certainly worth TRYING to avoid.
Your Project Never Ended When You Committed That Code
This next point is probably more true for web application development where release cycles are rapid and organizations move fast. We like to think our project ended and we’ll be moving onto the next great thing, but this is rarely true. It’s best to prepare yourself for so called feature creep after a release. We are not perfect and don’t think of everything so this is natural. I’ve seen developers get angry about this and I have too on occasion. You’ll do much for your mental stability if you just accept that version 1.1 is right around the corn. There are ways to mitigate this, but few ways to solve it. The best thing to do is just accept it.
Attack of the killer bugs! Oh sure one bug can rarely kill you, but multiple bugs one after the other flying in before you were able to squash the last one can really drain on a developer. I’ve seen system failures and bugs in I/T and Development that absolutely make some people feel sick. Thankfully these are rare and I haven’t been directly involved in many of these. Worst of all is some in management expect flawless systems, this expectation can be incredibly stressful on developers. We are humans, yet sometimes are expected to not have a single bug. In many cases we write apps the size of novels, but are expected not to have a single grammar or spelling error. Our jobs can impact hundreds, thousands, millions, and billions of users on the Internet. Not a lot of people outside of development truly appreciate that. We as developers know this though and really need to strive against the urge from within to release to early and strive against the pushes of management to release code to early. Some places are better than others at this and some developers are better than others too.
Impulsive Code Rewrites
I see this much more out of new developers than older ones. That’s because the older developers have dealt with the pain of rewriting a poorly developed yet working application. This is not to say certain systems should not be rewritten, but it should certainly be avoided unless there is a truly compelling reason to do so. Those reasons might be that adding new features has become cumbersome, the state of the code leads to lots of development hours when adding new features, the system is way too slow, or what management wants is absolutely not feasible with the current design. Reasons to not rewrite are the code sucks or is hard to read. Especially avoid rewrites if you don’t anticipate needing to dive back into the code for a while. The most important thing is avoid rewrites of mission critical applications where a nasty bug can have grave consequences on the organization.
I used to be rewritter, but after a year or two in development I realized it’s not worth it to mess with a working system. If you do choose to rewrite just prepare yourself and management for some bugs.
Don’t Get Stuck
These are just some of my thoughts and this is probably more of a reminder for me than good reading for you, but I appreciate any comments and notes on what I may have left out.