21 Developer Rites of Passage

Everyone has memories of certain formative experiences that seemed to mark the end of naive adolescence and the beginning of cynical adulthood.

When I think back over my career as a software developer, I realize that I’ve had several experiences that taught me some hard and valuable lessons about the art and science of software development that seem like rites of passage in hindsight.

Here are some of my more memorable ones. Most are either bone headed mistakes or else situations that could have been avoided with more disciplined engineering practices and better methodologies in place. Nevertheless I look back on them with a slightly masochistic fondness. After all, what better way to truly understand the reasons behind best practice than to have experienced the pain that they are trying to remedy first hand.

Enjoy.

In no particular order…

  1. Releasing software to production that took twice as long as the original, padded estimate with half the features and still having the users be happy about it.
  2. Being on both the giving and the receiving end of a situation where consultants were given god-like powers by executive management.
  3. Laughing out loud in a meeting with an auditor because I thought they were making a joke about some new software development mandate only to find out that they were serious.
  4. Averaging more than 70 hours a week for 6 months straight and then getting yelled at for not making an arbitrary delivery date when the requirements were in a constant state of flux.
  5. Feeling more like a lawyer than a developer while trying to explicitly capture requirements or determine whether an issue that surfaced during testing is really a new feature or a bug.
  6. Realizing for the first time that office diplomacy often had a bigger influence on project success than how many software best practices were being followed.
  7. Deciding to stop printing out a project’s object model and\or database because it would no longer fit on the walls of the largest conference room.
  8. Being at least indirectly responsible for a bug that cost the company more money than I made in a year (I used to work in a banker’s bank that loaned billions).
  9. Helping to write a 500 page requirements document that very few people read and that was hopelessly out of date before it was even finished printing.
  10. Getting woken up on a Friday night in order to troubleshoot a production problem remotely in a code base that I’ve never seen before.
  11. Accidentally trashing a half million records in a production database.
  12. Having to fix a problem with a system that the company no longer had the source code to.
  13. Realizing that I no longer remembered how to do a hello world app in a technology that I used to be viewed as an expert in.
  14. Spending multiple days on a problem that took only one line of code to fix.
  15. Spending over 6 months creating an application that worked flawlessly only to have it scrapped because of a merger and downsizing.
  16. Being treated like a hero for out-of-the box functionality that took only minutes to implement.
  17. Being treated like an idiot for taking too long to solve a nearly impossible problem that other developers weren’t even sure could be done.
  18. Being solely responsible for the decision to fire another developer.
  19. Having a sense of deja vu when reading about a latest and greatest technology and\or methodology.
  20. Having to debug and then clean up the data carnage caused by a 1500 line stored procedure with no error handling or transaction management.
  21. Realizing that I still love my job even after eight years of coping with extreme dysfunction in an industry that rarely learns from its mistakes.

Do any of these sound familiar? What are your most memorable rites of passage as a developer?

16 Comments

  1. Thomas Guest September 8, 2008 2:30 am 

    Leaving a large company to work for a smaller company, only for the smaller company to be taken-over by the larger one a few months later.

  2. Seth Petry-Johnson September 8, 2008 7:22 am 

    Experiencing multiple cycles of (1) feeling incredibly competent, (2) learning something new, and then (3) feeling incredibly incompetent when you realize how wrong you’d been in the past.

  3. Dan Lewis September 8, 2008 8:49 am 

    Using a profiler to find an extremely obvious performance enhancement in a library that has been sitting around for years, wasting cycles

  4. Paul W. Homer September 8, 2008 9:48 am 

    Spending years to successful build a complex software product, only to realize that the one thing I couldn’t control, the company, was the real problem.

    Burning out an old plotter by running a Spirograph algorithm to produce pretty pictures for fun.

    Erasing the kernel on the ancient UNIX box I was managing, only to realize that it was the one file that wasn’t backed up on a regular basis.

    Single stepping through a debugger for a whole week to find some weird stack-based bug on Mac OS 6.

    Paul.

  5. Jason September 8, 2008 11:51 am 

    On point #21
    Why is realizing that YOU still love MY job a rite of passage? :)

  6. Russell Ball September 8, 2008 12:10 pm 

    @Jason – oops…thanks for the heads up. I really need to find someone to proof-read this stuff…:-)

  7. Russell Ball September 8, 2008 12:14 pm 

    @Thomas – Hilarious. I guess they just really wanted you to work for them.

  8. Sergio September 8, 2008 5:52 pm 

    Discover, with Google, the username & password of the work email of one of your ITC security consultant.

  9. Sumpygump September 8, 2008 8:46 pm 

    Number 13 also needs to be proof-read. Nice list.

    In number 20, I think “sproc” should be spelled out as “stored procedure” for people who might not know what a sproc is.

  10. DrStrangeLug September 9, 2008 1:10 am 

    Learning that people you thought were examples of professionals at their peak were actually producing code that was worse than yours.

  11. Chris September 9, 2008 6:31 am 

    Looking around and realizing that I was the only playing the “Lets make the project’s result useful” game while everyone else was playing “How can I shove my work onto you (sucker)?” game.

  12. je88484 September 9, 2008 9:41 am 

    Coming to understand that every new hot methodology (not excluding XP) that purports to “empower” developers is really meant to make life easier for managers. And experiencing the perverse satisfaction that comes from the knowledge that it won’t.

  13. Robz September 9, 2008 6:37 pm 

    Gee, I think I was there for most of that… :D

  14. JR September 23, 2008 12:50 pm 

    Funny, I think I was there for some of those too. Love the 500 page Requirements Doc that took a two-wheel dolly to move!!!

  15. dissertation proposal writing June 28, 2013 4:06 am 

    I am looking forward to reading most recent blog posts. I was extremely remarkable. You have truly unique style. Keep up the outstanding efforts! I must say that you have a big talent! When I saw your work I was extremely remarkable. You have truly unique style…

Leave a Reply