How to Be a Responsible Developer?

Great, Successful, Happy… But Responsible?

There was an episode of Ruby Rogues 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:

• They work proactively.
• They contribute to the developers’ community — they may be role models for us also because of their work in the public domain.
• They have a growth mindset - they know that their most basic abilities can be developed through dedication and hard work — brains and talent are just the starting point.
• They are fantastic communicators.

Responsible Doesn’t Mean Experienced

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. 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 additional tips:

• Talk to the team, maybe the client isn’t the only one who knows what you need to know.
• Don’t hang around endlessly waiting for an answer — you need to crack on.
• Know your limitations/blockers and be honest about them — that’s far more useful than promising something you can’t deliver.
• If you’re alone, use your best judgement — it's easier to ask for forgiveness than for permission.

We Don’t Deploy on Friday!

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 realised 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.

Your Job Isn’t Just to Rush Through a Pile of Tickets

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.

Small Things That Matter

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.

You’re There for Your Team

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, they doesn’t have to be constantly asked to describe stuff, answer emails or do maintenance work. If that’s what has to be done, they do their job to keep the team moving forward. The dev understands that communication and transparency is key for the team, so they communicate 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 they're 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 they work.

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.

The Take-away — What Does It Mean to Be a Responsible Dev? What Can You Do to Be One?

And finally, here's my list of the things you can apply to your routine:

1. Ask specific questions.
2. Be transparent and honest.
3. Be aware of your own limitations and don’t hesitate to ask for help.
4. Think about the consequences - sometimes it’s better for you to NOT implement a given feature. Deploy things you’re able to handle.
5. Be there for your team. If you can contribute right now, don’t wait — do it.
6. Test your code.
7. If there is a rule for something, follow it — it’s there for a reason.
8. Don’t pretend that you can’t see a flaw in your software. Know when to dig deeper as opposed to delivering a “good enough” feature.
9. Be positive.
10. Think about yourself as a real end user of the feature.

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.