DuclearcThe role of a great dev
- Posted on: May 17, 2024
- Co-author: Scott Fletcher
- This post was picked up and re-published by Scrum.org and by Amazing Outcomes
Most of us have the same image of a good dev in our minds: someone who puts their head down and diligently types away, checking tasks off a list: ticket in, ticket out. They are reliable, productive, and usually keep themselves out of the way. This is all well and good, but we want to challenge this notion by showing how a great dev can be something more. We want to illustrate how devs have the power to shape much more than the code they write.
In our team, we work with Scrum and we do so because we believe it is the best way to deliver more value faster. Scrum is the most agile way to organize work that can at times be unpredictable. Ever had a simple code change that ended up taking the whole day to complete because of a domino effect you didn’t expect? Scrum will provide you with a system to re-prioritize your tasks accordingly. And you’ll always know you’ve finished them because of the Definition of Done (DoD), which ensures not only that you didn’t forget anything, but also that what you’ve produced adheres to the quality and security standards of the rest of your codebase. This is why we value this workflow.
A Scrum team usually consists of a Product Owner (PO), a Scrum Master, and three to five Developers who have the skills to do the work. We’ll be specifically writing from the point of view of the devs. Everyone has their role to play, including helping keep each other on track, but our focus is on getting things done more than anything else. The PO has the final decision on what we do, and it’s our responsibility as developers to figure out how. Doing our job professionally means that we are regularly and responsibly delivering increments that are complete, testable, and shippable. We divide our workload into 2-week periods, called “Sprints” and every Sprint we deploy at least one stable update to the product that will be live and available to real users. That is why we do what we do.
Where the power of a great dev comes in, is being able to shape not only the code that gets written, but how we fundamentally work as a team. This includes making changes to the status quo of developing. The standard workflow in IT is that each person pulls a task, works on it alone, and tries to integrate it afterwards. That approach often leads to more time being spent integrating than developing - Pull-Requests blocking other tickets, unintended side effects, not to mention merge conflicts. With that in mind, we decided to experiment with an alternative workflow: what if our default is working together rather than separate? In theory you might think two people working on one ticket at a time is slower, but as is so often the case, we found that less multitasking leads to more tasks being completed. It aligns with one of agility’s prime directives: stop starting and start finishing. Going into the experiment we were afraid that so much pair programming would leave us burnt out, but we found that the opposite happened. Coding with a partner keeps us accountable not only for code quality and knowledge sharing, but also for self care. We found that we took more consistent breaks and finished the work day on time, all while delivering more done increments in a shorter time than any other team we’d previously worked with.
One key addition to our collaborative coding sessions is the digital whiteboard that we use to bounce ideas off each other. Many times we’d approach a complex task thinking that we already have the same mental plan on how to implement it, only to realize after a few lines of code that we’re miles apart. Out would come the whiteboard, and we would tackle tough architecture decisions before needing to do costly refactorings. A prime example of this is when we implemented a feature sending users an email with a link to activate their accounts. Starting the ticket, we thought, “easy enough!” and got to coding, only to realize there was hidden complexity: what happens if the user opens the link in a different browser, or after they’ve been logged out - how will we know who is attempting to activate their account and whether they’ve been authenticated? It was clear we’d have to allow the user to log in before the activation, but one of us argued we should use a state to remember that the user wants to activate their account after logging in, while the other argued for using a URL parameter. We brought out the whiteboard to list the pros and cons of each approach, and then we realized we could get the best of both by simply reusing our login mask on the activation page - fewer changes, less risky, more robust. When developers are working alone, often these disparities in vision only come up in code reviews, usually after it’s too late to make fundamental changes.
Another advantage of working in tandem is that it empowers us to suggest strategic pivots to the Product Owner. Case in point: recently we were challenged to improve a website’s search engine optimization (SEO). This, however, is not how the task was originally phrased. Our original plan was to: “change the codebase to a server-side-rendered (SSR) framework so that we can have a better SEO ranking”. With 2 weeks’ deadline to achieve this, naturally our first brainstorming session was aimed at breaking this down into subtasks. So we quickly realized that the goal behind it wasn’t actually to implement SSR: what we were really asked to do was improve ranking. With that distilled goal in mind we took an afternoon’s timebox to research how to make our existing code more SEO friendly and it turns out SSR was not required at all! SEO has evolved since client-side applications became popular and there are many ways to improve your scores without needing big refactors. So we took our findings to our PO to challenge the scope, presented our research, and made a case for fulfilling the DoD without SSR. With him on board, we got started on our improvements. A bit of playing around with the url inspection tool, some tweaks to the HTML tags and robots.txt, and voilà: we got the same results with significantly less work. This is an important role a developer can fulfill: defying assumptions on how to achieve a goal. A month-long refactoring became a task we finished within 3 days. This was only possible by having the whole team focusing on the goal, trusting each other’s expertise, and adhering to the DoD.
Really, we’re arguing that our shared concept of a “good developer” needs an update. A dev isn’t someone who just writes code. They actively contribute to optimizing the workflow, sharpening communication, and aligning everyone in the team to the goal of ultimately delivering more value. Devs can and should feel empowered to try new approaches to collaboration; our success with pair programming proves that the status quo isn’t necessarily the right method. In the end, business value comes from the teams who produce it, and a great dev contributes to their team in many impactful ways beyond just coding.
Written in collaboration with Scott Fletcher