Great and successful developers are often responsible but not necessarily so. Responsibility means that you know yourself and your own limitations while also maintaining awareness of what the project requires. I will try to explain who exactly is a responsible developer and why it’s fortunate to have one (or more) on board.
There was an episode of Ruby Rogues recently that focused on what makes a top-drawer developer. They covered great developers who have achieved success in their field. Here I’ve listed a few key qualities of such people:
I’ve worked with many people from various backgrounds - from fresh interns to senior-ninja-guru-level developers — and I’ve observed that it doesn’t really matter what they saw in the past; it’s more about how they look into the future.
Example: you get a brief from a very busy client, but it lacks clarity.
What would a responsible developer do? (WWRDD)
The dev tries to analyse the brief once again — maybe it’s written down somewhere, or perhaps there was a discussion on Slack. If they still cannot find it - they write to the client with specific questions like: “I’ve read through the brief, but some of it is a bit ambiguous — please tell me if we should take X or Y into consideration”. Being specific is really the key here - time is a precious resource and let’s keep that in mind. But that’s not the end of the story — the dev doesn’t wait for the client to ask (remember - they tend to be really busy). The dev should at least think about some potential solutions and use his/her best judgement in order to determine how to build the solution.
In such a case it’s crucial to allocate your time wisely — don’t allow yourself the luxury of wasting hours on doing nothing. If you really (check twice!) aren’t able to move forward, do something else which will take your project one step further.
A few tips here:
This is a more general point about taking things on that we’re not ready to handle. If you know that what you’re about to deploy is highly unlikely to function properly, hold back. Previously I mentioned that it’s easier to ask for forgiveness, but if the odds are against you then just hold off. There might be cases when you’re new to the project, and you’re left alone for a couple of days — maybe that’s not the best time to deploy crucial changes in the application.
I recently came across a pull request with a small feature and Rails upgrade hidden somewhere in between. The application was designed to process some financial data, but was quite outdated and lacked a decent layer of tests. There was a huge temptation to merge this feature but what if something went wrong? In addition, it was the last day before the dev went on vacation. I wasn’t brave enough to merge it all at once, so I rejected the Rails upgrade from the Pull Request and merged the feature only. And I have to tell you — that was the moment when I realized that holding some things back because of the potential risk is a good thing. We did the migration later on and kept the software stable up to this point.
Working as a developer for someone isn’t just about pushing code. The responsible dev knows that communication and transparency are as important as the code itself and that we should always try to understand and carefully consider the customer’s business goals when working on the app.
If we just did everything we’re told, we would be like robots, whereas a developer’s task is to deliver value to the client, and sometimes that might mean not delivering at all:) It really does make sense to hold off sometimes — the amount of time/money/effort might not be entirely appropriate for whatever it is that you have to implement. There is a really nice post related to this — I really recommend you read this one called Why I Strive to be a 0.1x Engineer.
It’s a developer’s job to talk with the customer about the implementation and the future of the code/feature being built. A developer shouldn’t just see it as it looks right now but should also take a wider perspective on the repercussions of merging it with the codebase.
I recently experienced a situation when my colleague was asked to migrate an application from one server to another. He spotted that this application sends emails, but we don’t use any 3rd party provider for this. After a quick call to confirm that it’s perhaps not really the best solution and 5 minutes later there we are using Sengdrid to send our emails. Why do I think it’s important to highlight situations like this? This developer spotted a flaw, confirmed that it could be improved and took the responsibility to change it — the team benefitted right away. It took 5 mins to change, but that’s going to serve us well for months if not years.
Let’s go back to experience - I mentioned that you don't have to be experienced to show responsibility. Sometimes, the fact that you were assigned to a ticket doesn’t mean you have to contribute directly. If you put your hand up and ask for help, someone else can step in to do a little work here and there to deliver your ticket — nothing wrong with that, and you should always value delivering a feature over implementing it.
Most probably you’re not the only one working on a project. Even if you’re the only developer, there are other people around you — project managers, QAs, designers, marketing guys — and all of you come together to create an important group, known as the team.
A responsible developer knows how to cooperate with each individual team member and knows what their roles are. Thus, he/she doesn’t have to be constantly asked to describe stuff, answer emails or do maintenance work. If that’s what has to be done, he/she does their job to keep the team moving forward. The dev understands that communication and transparency is key for the team, so he/she communicates blockers, risks, problems, and seeks out help where necessary. Finally and most importantly, you won’t catch such a person lying because that leads absolutely nowhere. And “nowhere” isn’t a place that anyone responsible would like to go.
If the team has agreed on daily standups - you can be sure that the responsible dev is always there. You can be sure that this person will let you know in advance if something is about to happen (e.g. if s/he's not going to make an initial estimation or deliver a sprint). The responsible dev reacts to feedback with understanding and is open to changing the way he/she works.
Being responsible for your team means not leaving their team in the lurch when errors show up that were caused by your deploy. It’s you who’s responsible for putting things back on the right track. The same goes for an unfinished assignment — if you want to be considered responsible, don’t leave stuff half done and finish your task before starting a new one.
And last but not least — attitude counts. The responsible developer doesn’t irritate easily and looks for a solution to the problem with a level head rather than moaning and groaning and making things even worse for the team.
So, there you have it — a kind of developer’s Savoir-vivre. If you follow these suggestions, I guarantee your team will appreciate it. Be a better, more responsible developer. It won’t be long before everyone sees that they can count on you to foster a positive relationship with your clients, colleagues and projects.
I hope you enjoyed my post! If you have your own observations, please share them in the comments!