Responsibilities of Modern Software Developers Part 2

For part 1, click here…

4. Say “No”, be the bad guy

If you’re not confident a particular deadline or task is achievable, or even the best solution, then say “No”. Few people enjoy refusing a request, but it’s important to avoid passive aggressive behaviour.

Have confidence. The team and supporting staff will be able to adjust appropriately or communicate out the sooner they know there’s a chance a task will not be delivered or will cause issues. It’s no good after the damage has been done.

5. Raise Risks/Concerns

Some potential risks or issues with a project may not be obvious to management. Never assume they’re obvious.

If something makes you feel uncomfortable about the project, raise it and ensure it is heard. It is our responsibility to do this until either we understand why it’s not an issue, or management understand that it is one.

If you're not confident a particular deadline or task is achievable, or even the best solution, then say ``No``. Few people enjoy refusing a request, but it's important to avoid passive aggressive behaviour.

6. Clarify Requirements and Ambiguity

In an ideal world, the product owner/user/stakeholder would know exactly what they want, and put it into words, communicated to developers without ambiguity or misinterpretation. The software would be delivered exactly as requested.

In reality that’s not the case. If that was the case, then Waterfall would be a sufficient methodology. In reality, the customer will not have thought of all the details and scenarios beforehand. The customer may also realise initial requirements are no longer appropriate or ideal, and need to be solved in a different way.

This is the purpose of iterative development – allowing us to develop just enough of the product to confirm or deny our assumptions, while refining the next lot of work, then repeat. Therefore, it is not entirely the responsibility of clients to capture all the detail to a sufficient standard.

It is our responsibility as developers to ensure the requirements are clear enough for us to begin the work. We will all learn as we go and modify the roadmap as required. So when things are realised to have been missed, avoid the blame game. Reflect on how you can avoid missing something like that again and acknowledge everyone’s still human.

7. Don’t become a single point of failure

We’ve likely all worked on a project when someone goes on holiday or off sick. You’re about to go live or the test environment goes down, or a peculiar bug rears its head again.

That someone was the only person who knows where that script is, the login details for the CI environment, has the right permissions, or knows that clever trick to fix it. Perhaps that’s been you and your relaxing day-off at the beach was interrupted.

As developers, we have a responsibility to help prevent becoming that single point of failure. Constantly ask yourself: How easy would it be if a new developer joined the team? How easy would it be for them to begin contributing – end-to-end, all the way to production? Consider writing a light how-to or readme for setting up your dev environment and running tests, important URLs (e.g. for build servers), point-of-contacts and how to receive any appropriate access to systems.

When things are realised to have been missed, avoid the blame game. Reflect on how you can avoid missing something like that again and acknowledge everyone’s still human

8. Write accessible, maintainable code

As with ensuring we do not become a single-point of failure, it’s our responsibility to ensure source code is written in a way that is intuitive to a fellow software developer. Just as a good UI is intuitive to the user.

Ask yourself: How easy would it be for someone to begin contributing? Am I following common standards and an intuitive folder structure?

Following common standards; writing unit tests, integration tests; clearly naming and structuring code all help to achieve this. That doesn’t mean comment the **** out of everything though! I’ll save my vendetta on (the majority of) code comments for another blog…

Overall, we as Software Developers should feel pride in what we deliver. To achieve this sense of pride we need to take responsibility in what code we write, what decisions we make, what estimates we provide and how we chose to do all this. We can never be responsible for something without assuming accountability as well. With this sense of accountability we are more conscious to adjust and learn from any mistakes. And that, in my opinion, is the best way for us as Software Developers to ensure our own empowerment and autonomy.

Recommended further reading: The Clean Coder, a fantastic book written by Robert C. Martin on professionalism. It’s written in the context of Software Developers, but there’s plenty to gain for any roles in the industry.

Leave a Reply

Your email address will not be published. Required fields are marked *