Impact-driven development
It is my fifth year working as a professional software engineer, and I think it’s a good time for me to share a few tips, dos, and don’ts I learned throughout past four years. This is the first article in a series of three, and it focuses on development process.
Moving towards becoming a senior engineer, I noticed paying more attention to the impact my work produces. These days I would much rather compile a number of small simple changes to “wow” the users, as opposed to building unnecessarily complex nice-to-haves. This sounds simple and straight-forward, and some reader might even say “That’s silly, everybody knows that”. However significant number of engineers I meet don’t concentrate on how much impact they produce.
It’s easy to get caught up in a daily routine: you close an issue after issue, there’s a stable flow of requirements from the business meetings. It’s not always easy to know when to stop and think “Do I really need to do this?”.
Get the priorities right
Divide amount of impact task produces by amount of effort you’ll have to put into completing it. Arrange the tasks by this factor.
More often then not you can drop items with low impact/effort ratio.
Separate what is needed from what is asked
Know who the stakeholders are for each task, feature, or a project you work on. Understand their underlying motives. Anyone can fall a victim of an XY problem, it is your responsibility as an engineer to make sure that stakeholders ask for what they actually need.
Know when to say “No”
In the very beginning of my career I gladly took every single task thrown at me. It soon became an issue: work that actually needs to get done is not getting done quickly enough. Knowing when to say “No” is an art that takes practice.
Think about your work
Beware of routines, repeating the same workflow time after time is damaging when it comes to building software. Stop each time before you proceed to the next step, and ask yourself if you’re performing the task in the best way possible. Be mindful about your work.
Be a catalyst for change
Be the first to promote the change. Did you notice a poor practice on a project? Begin a more efficient practice (if it’s appropriate based on your role in a team of course). Don’t go on telling people how wrong what they use is. Show everyone how the new way is better on practice, and your colleagues will adopt successful trend.
Don’t fall a victim of deferring responsibility: be aware that when multiple people are involved, every member of a group relies on other people to get things done. Be the one to take on responsibility when it’s unclear who should.