This may sound like a silly question. “When is a developer’s job done?” It seems obvious at first. Developers write code. Their job is done when code is written.

I used to have this view. My first job out of college had 3 month code freezes before each release. That 3 months was for the QA team to fully test things. The code I wrote was often tested weeks after I wrote it. Maybe I’d hear back from them if something was broken. Probably wouldn’t hear anything if it worked.

That’s a huge delay in feedback. Certainly made me feel my job was done when I sent something to QA. I often didn’t hear anything about my code after all. If QA did send anything back to me, I thought of it as new work for me to do instead of finishing some earlier work that I thought was done.

That attitude changed very quickly when I joined a 12 person company next. At that size, there was no QA team. I tested my code. There was also no time for a 3 hour code freeze much less a 3 month code freeze. I had to test that code well in a short amount of time.

More importantly, I also deployed the code I wrote to our live servers. My job wasn’t done until my code was in front of users.

This is an important distinction for many reasons. The first is: code provides zero value when it just sits around. There are some exceptions, such as prototyping code, but for the most part code doesn’t serve a purpose if it isn’t being used. Maybe the developer had fun writing it, but it generates nothing a user can use and consequently zero revenue for the company.

Without revenue, a company can’t pay developers our fancy salaries.

From the company’s perspective, the job is done when the code is in front of users. That means developers need to be caretakers of their code until it is in front of users.

This is a good thing. This attitude makes us better developers. Instead of just making sure code works on our development machines, we perform extra thought to make sure the code works when it is live. Since the code doesn’t disappear into some black box handled by another team, we end up seeing it through its entire life cycle. This provides a greater sense of ownership and raises the stakes for us to do better work.

Getting here isn’t solely on developers to do though. The company has to be structured in a way that encourages it. If you take a developer with this desirable attitude and put them in an organization where their work gets handed off to another team, then they will start to disassociate away from the need to see their code in front of users. They will start to see their job as being done as just writing the code.