Owning it 101.
Imagine a person who has been trying desperately to have a baby for a few years. What would you think about them if they’ve left the little one right after it’s been born? If you’re not a psychopath, you’d probably find him lacking responsibility, devotion and logic.
Why git commit, git push and forget then?
What an average developer does…
One of the things that motivate us, developers, are challenges. Difficult tasks which require exceptional problem solving skills. Or a new technology which is interesting and mastering it becomes a point of focus.
There are also certain situations that annoy us. A critical bug which distracts us from our work and has to be solved as soon as ASAP. A nasty task which hopefully, we will never be assigned to.
Whether it’s a feature that excites us or a day long bugfix which makes us frustrated, we sometimes tend to forget that our responsibility does not end after pushing the code to the repository.
…and what a brilliant one does
A common coding task has a few lifecycle steps, that look more or less like this:
- A developer is assigned to the task.
- It’s “in progress”, meaning the developer is coding it at the moment.
- The task is finished and a developer pushes it to a branch.
- The developer sets up a code review / pull request.
- The task is tested by QA engineers.
- It is merged to the master branch.
- Finally, it’s deployed.
While in your case some of those might be missing or have different order, you should get the overall idea. Many of us, especially in early stages of our careers, tend to abandon their child in point 4. Why?
While the creative process of doing the task is interesting, other may not seem so. We tend to leave uninteresting parts of our work to others and get our hands on the cool stuff.
Other developers definitely have to do the review. QA engineers have to test your task. Someone has to merge it and deploy it.
Pushing the responsibility for those stages to others is like having a baby and then sitting at home waiting for a catering lady to come and feed the kid. Or waiting for a clothing company to come to your house and dress the child, after it was bathed by a kindergarten representative.
If you want the child to survive and want yourself to be recognized as a good parent, you have to take care of it.
Own it!
You are responsible for your piece of work during the whole mentioned lifecycle. You should take care of it unless it’s deployed to production, when your company releases frequently. Or — if a new version goes public every few weeks, months or years — when it’s in the master branch. But how?
Progress updates
First of all, depending on the project management tool your company/team has chosen, make sure you update the status of a given task as you go. This way, you keep your scrum master or a project manager happy and they don’t have to ask you every 2 hours about your progress.
Pull requests
Remember the 30/60 rule I mentioned in one of the previous posts? You can base your actions on a timeframe while dealing with pull requests as well. Let’s divide PR’s lifecycle into two stages — leave it and push it stage. It’s normal that nagging someone about your review instantly can be really frustrating if you do this too often. Your mates also need to focus and have some time to work without distractions. That’s why, we first go with leave it stage, which means waiting for someone to take a look on their own. Then, we follow with push it phase, which is all about asking someone personally.
The only thing that is tricky here is developing the framework for determining how long each phase should last.
It’s probably a good idea to drop a review link to a selected person instantly if it’s a hotfix. If it’s really urgent, leave your desk and explain the situation face to face. If it’s something that just needs to land on production soon, act after 2 hours. If it’s a feature, take actions after the half of the day. You can ask someone to give it a look next day if it’s something that can wait and you plan to deploy this in a couple of days.
Time balance depends on your deployment frequency and the importance of the task. Feel free to play with it. Ask your teammates about their reviewing system. Some people do this twice a day, some do this immediately, others do reviews only at the end of the day. That information can be useful to sort out these proportions.
Testing
If you pass your changes to QA engineers, make sure they know they have to test it and they can proceed with it. We use Target Process and have a “Ready for testing” stage in our process. I wrote a Slack bot which automatically notifies a responsible tester that there is some work that needs to be done. You can do this manually as well. If possible, make sure you know who tests it, that he / she is aware that it’s ready for testing. Then, get back at some point to ask about the results. It’s their green light you’re waiting for to proceed to the next step.
Merging & deploying
This one really depends on the release model in your company. If it’s a SaaS company, you probably release often, sometimes a few times a day. In such case, your role ends when you merge the code, it goes live… and works.
A tip that can save your ass — try to get your lines to production as soon as possible or at least track when it will go online. There’s nothing more frustrating than your teammate calling you later saying that he / she just deployed your changes and they broke the entire production.
It’s simpler when you release rarely, as your part probably ends after merging to the master branch and you leave the rest to buildmasters.
Keeping track
If you use an advanced project management tool, like Jira or Target Process, there’s surely a way you can filter your sprint board to see only your assigned tasks. Make sure you take a look at them a few times a day to determine what actions should be taken. If Jira or TP scares you, set up a Trello board for yourself, define stages and keep track of your work there. Just make sure you reflect your changes in the official tool as well.
…and chill out
It may sound scary, but you can (and should) get used to owning your work and it won’t take much of an extra time if you master it. The advantages are endless — no teammates saying you fuc*ed up, no surprises on production, no delays because you forgot about your pull request. Better control of your flow and less people asking you “how about that thing you started…” are the other pros.
I hope I convinced you and I hope that owning it makes sense now. If you like it, heart it. If you have any doubts or comments, leave them below.
