The responsible developer profile explained

At nepit, we take much pride in our company values. They are ingrained in everything we do, from selecting customers to managing our work-life balance to hiring new candidates. To achieve these company values, we need all of our colleagues to be honest human beings who have a passion for sharing knowledge and delivering quality. For our technical people, we’ve created a term for this: responsible developers. This is why we only hire responsible engineers and don’t really care about seniority.

What are the traits and behaviors of responsible developers? To make sure we keep hiring the right people, we’ve defined that for ourselves and we are happy to share it in this article.

What makes you a responsible developer?

Is a responsible developer not just the same thing as a senior developer? When asking people to explain the difference between a senior and a junior profile, the usual answer is about years of experience. We don’t think years bring responsibility. One of our youngest developers (with the fewest years of experience) is also one of our best leaders. Being a responsible developer is measured in qualities other than time.

Information handling

Responsible developers actively search for the information they need and ask questions directly to the right people (product managers, clients, stakeholders, etc.) if they feel like something is missing. Information needs to be documented, so answers should be documented in a way that makes them easy to find and clear for everyone in the future.

Honest communication, asking for help and keeping each other in the loop

Maybe even more important than clarity is honesty when it comes to communication. Responsible developers are good communicators and help each other out by being honest when they don’t understand something. Being honest can sometimes be hard. However, being fully aware of the situation and context, while staying polite and keeping in mind that everyone makes mistakes, is always the better thing to do.

A responsible developer also understands that there is no shame in needing help and asking for it. He does not take pride in doing things alone and realizes proper engineering is a team effort. Getting help and then completing the task rather than struggling and eventually doing it on their own, will cheapen the experience and benefit the clients.

It’s easy to lose information on chat channels or video calls. So even though video calls are great to discuss important topics, responsible developers record the call or take notes and afterward make them available to the whole team. But that is not the end of it. Documentation may need updating, other colleagues or teams may need a heads up on important changes, and or technical updates, pair programming is an important tool for responsible developers.

Responsible developers are part of the team

By now it should be clear that communication is one of the most important factors for a successful team, but communication is two-way so listening is just as important. A responsible developer respects other people’s opinions and helps in creating a safe environment where everyone can speak up and give their opinion.

But a team needs time to work, so a responsible developer doesn’t waste other people’s time, comes prepared to conversations, and helps keep the focus in any discussion. Since a responsible developer needs to manage their own time, they should be aware of the overall planning and what colleagues are working on. Using proper tools can help developers prevent disruption greatly too.

Develop others & yourself

To be able to deliver quality, knowledge is needed. A responsible developer cultivates learning relevant things (technical and non-technical) but stays critical at all times when deciding upon technicalities or tools. They do not follow trends because they are trends, but first, they try things out in a less critical environment rather than in a client project. The needs of the client, their timing and budget, are far more important than the joy of trying a new fad for a responsible developer.

But the responsibility doesn’t stop at the developer. Responsible leaders can also do things to help the team grow. Everyone has different knowledge and skills, so to make a team thrive it’s important to let everyone share this with short introductions on new topics (recorded, of course, documentation is important), blog posts, Slack channels for discussion, or speaking at conferences. At nepit, we have a variety of mediums to support sharing and discussing things.

The needs of the client, their timing and budget, are far more important than the joy of trying a new fad for a responsible developer.

And finally, the responsible developer thinks about their colleagues’ improvement as well. They give constructive, actionable feedback, but they also generously give credit whenever someone else deserves it. We created a tool to provide just this kind of peer-to-peer feedback, called Reflect. Feel free to give it a spin.

Goals, goals, goals

If you think that a responsible developer is a top-notch developer that can produce code of the highest quality, then you’re right, but they also take into account the goals of the client. It’s not always necessary to produce the highest quality code, the budget, the timing or even the purpose of the project together can make hacking things the better option. In any case, a responsible developer always leaves the campground cleaner than they found it, but without wasting time on things that don’t deliver value for the project.

A responsible developer takes ownership. They commit to a task and then either get it done or communicate swiftly if that becomes impossible. This means they take responsibility and make sure any job gets finished.

They also improve how the team works. A responsible developer is critical of how things get done and promptly takes action if a process needs to be improved or even removed to make sure the team works well.

Responsible developers are always aiming for quality

Quality requires testing. A responsible developer never assumes their code will work, nor do they ever assume someone else will test it. That’s why they write automated tests by default and then manually test as well. But watching over quality starts earlier, with gathering feedback on their work, by pair programming, or code reviews. Once again, communication is key. Top tier developers provide context and background so that others can provide relevant and appropriate feedback easily.

To provide this quality quickly, a responsible developer takes the time to master their tools. As with technology and frameworks, while being critical of them, tools should not be swapped out lightly, because mastering a new one takes time.

Reference: madewithlove.be