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.

Bugs Kill

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

Finally, don’t marry your skillset. It’s a skillset, not you. In this field we need to continue to stay up-to-date with the latest technologies. Years ago it was Ajax today its HTML5 and mobile phones (I’m guilty of not doing much with these yet). My Dad for instance is an old Unix guy with lots of experience on HP UX, Solaris, and other ancient Unix flavors. This served him well for a very long time until the DOTKABOOM! He doesn’t make 6 figures anymore and is struggling to cut his teeth in a world dominated by Windows and Linux servers. Another person I know took a management job very early on in his career (still has it), but doesn’t do much programming anymore. He doesn’t understand Ajax, JavaScript, OOP, and many other vital components of a modern web oriented organization. What would happen if he were to lose his job? Management jobs are not plentiful and if he could not find that type of job he would have to regress to a very entry level and likely low-paying position based on his skills.

Conclusion

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.


3 Comments

  • PJ Brunet says:

    Yes, compilers are unforgiving and rigid. If a writer forgets a semicolon, no big deal, but one missing semicolon can crash an entire system.

    As far as “early adopter” learning goes–every programmer should take a basic marketing class. I had every book about Java back in 1994, I was very excited about it at the time–but look what happened, the promise of “write once, run everywhere” is just now a reality all these years later–my dual core Pentium laptop is just barely fast enough to run basic Java applications–that’s how slow and inefficient Java is.

    Look how many years it took for Java to become popular–by 1999 the market for Java development was still tiny–let’s be honest, Applets sucked back then, crashed browsers and I never heard anyone begging for Java developers. But people wanted Perl code–Perl wasn’t as “ivory tower” sexy but it kicked Java’s ass for years and years in terms of market demand, practicality and ruled the web.

  • John M says:

    Another lesson – don’t be clever, e.g. that really clever framework you are putting together to make your applications future proof – won’t because it is so complex no one will understand it and they’ll just throw it away (bit at a time if need be).

  • mark says:

    “Perl wasn’t as “ivory tower” sexy but it kicked Java’s ass for years and years in terms of market demand, practicality and ruled the web.”

    That is simply not true.

    If Perl would have ruled the web, PHP would have had no chance.

    Quite the opposite – as a glue language, Perl was good. But as a WWW language, it was lacking.

    PHP took that opportunity and kicked perl’s ass. Of course from a language design point of view, PHP is horrible, but people still managed to create great software like mediawiki or phpbb with it. Or wordpress.

1 Trackback