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.
This post was originally published on blog.professorbeekums.com
Top comments (5)
I might also say that, perhaps taking this question on from another angle, that a developer's job is not truly done until someone else can modify and maintain this code without speaking to the original developer.
I would agree in general, though while there are exceptions to my view, there are exceptions to this one as well. There are times when taking on a lot of technical debt makes sense. A cash crunch is one of them. No one will be modifying or maintaining the code if the company goes under. Maybe if it's a popular open source project, but even then it needs an evangelist.
I would suggest that there are two conditions that indicate when someone is done with a codebase:
1: As Ben says, when all responsibility can be handed over.
2: When the code is no longer in service, because it's been withdrawn / replaced [or the company has gone under!] This is typically a much longer timespan than initial delivery, and gets forgotten when companies operate a project mentality (cf: construction metaphors that fail), instead of a product life cycle one.
As a developer, it's good to have these exit conditions in mind when you create new code :)
When Is A Developer's Job Done?
It depends.
Sometimes, when your code is in front of the users it is not yet done.
Sometimes it's never done.
Sometimes it's done when you move your code to QA.
When the developer's job is done depends pretty much on the team and the stakeholders.
Is it done when it is tested, with no more bugs and ready for delivery to the production or is it done when it is successfully installed in the production? Or maybe when it is deployed and integrated with other systems?
I think the most important thing here is that the whole team agrees on what it means to be done. to have the common agreement on what 'done' means. The Definition of Done ;)
Yes, The definition of Code is of the TEAM, and if that TEAM include QA ppl, QA opinion has to be listened.