Developers: You’ve Got 99 Problems but Your Code Ain’t One
Coding elegant solutions is only the start…follow these tips for career-enhancing success
You live and breathe code. Armed with a keyboard and IDE, you can craft solutions to the most complicated of problems. Gone are the days however where a Developer’s effectiveness within the workplace is measured solely by the lines of codes they write. 21st-century businesses value technically capable individuals that can complement a cross-functional team’s ability.
The Agile Manifesto teaches us that collaboration and interaction with our extended teams is key to successful delivery. Therefore, knowing what drives your stakeholders and how to add value to your interactions with them is beneficial for all involved.
To name but a few, it can:
- Mitigate re-work
- Ensure expectations are met
- Realize customer-pleasing business value sooner
- Emphasize leadership qualities in yourself
- Improve engagement and morale amongst teams
The tips that follow look at a Developer’s most common stakeholders. Each role is important in its own right in ensuring your work delivers value to your customers. By focusing on these interactions, you can enhance your career within software development.
Testers
Often downstream of the output you produce, Testers are your safety net. On a good day, they can be seen as an added layer of bureaucracy, slowing down the time it takes for your latest feature to hit Production. On a bad day, they prove you’ve overlooked a particular scenario within 5 minutes flat.
Leave your pride at the door. Fail gracefully in the hands of your Tester rather than being caught red-faced by your customers.
Driver: Stopping 100% of undesirable functionality reaching the Production system
Hand-over don’t throw-over
Most teams use tools such as Jira, Azure DevOps or Trello to track the progress of their deliverables. Due to this, it’s often too easy for a Developer to move their item of work from the “Coding” column to the “Testing” column, implicitly expecting the Testers to check their work at their earliest convenience.
More often than not, however, the Testers will spend 5 minutes smoke testing the Developer’s work to find an obvious defect. This results in the Tester logging a bug to be fixed now at the Developer’s earliest convenience.
Instead of using the tooling to throw the work over the fence to be tested, hand the work over to the Tester. This can be as simple as a 5-minute, informal chat where the Developer demonstrates what work they’ve done to the Tester. If the duo finds undesirable behaviour during the hand-over, instead of logging a defect, the Developer has the option to fix the issue on the spot. (Think pair-programming between Developer and Tester).
This approach will avoid unnecessary churn between Developers and Testers whilst collaboratively ironing out any overlooked scenarios.
Don’t fob them off
“Ah, don’t worry about testing that…it’s untestable. Trust me, it works…”
Testers have two options here:
- Accept that the Developer is right and let the piece of work pass. They don’t want to be the reason why this new piece of functionality is delayed.
- Stand their ground and reject the work. If it’s not testable, it reflects the Developer’s inability to write high-quality code, not the Tester’s inability to do their job.
Sometimes, certain coding tasks are very hard to test by Testers. It isn’t possible to prove your new feature works as expected via the user interface or an API request via Postman. This doesn’t mean your code is untestable, however.
The role of the Tester on your team is to act as judge and jury when it comes to the quality of code being produced. Therefore, if something isn’t testable by the Tester but can be proven with a suite of unit tests, provide your Tester with evidence of this. You can talk through the scenarios your tests cover and possibly add new ones to put your Tester’s mind at ease.
If your code is truly untestable, it may well be time to go back to the drawing board and decide whether or not you provided the right solution to the problem.
Product Owners
There are varying types of Product Owner but they all have something in common — the desire to augment their product with features to satisfy their customers.
By following the Product Owner’s vision, Developers are given direction as to what they should deliver. With your product fighting to remain competitive within its given market, it’s not unknown for Product Owners to change their future product roadmap.
Driver: Knowing that there is a tangible correlation between their product and improvement to their customers’ way of life
“Give it to me straight…can this be done?”
Product Owners are full of ideas…some great, some not-so. To aid them on the path to product discovery, it’s beneficial that you try and discuss their future plans with them and the team.
Collaboratively, you should discuss the art of the possible with them. If something isn’t possible from a technological perspective, try and provide them with alternatives. Ask for them to schedule in an exploratory spike task for a future iteration so that you can explore possible solutions.
It’s also worth mentioning that if a Product Owner asks, “can this be done?”, it is not to be misinterpreted as, “please can you drop everything and try to do it now”. I’ve seen this happen several times before. Developers wish to do what they can to help out but for now, focus on the theoretical aspect of the question.
Honest estimates
Product Owners will come to you with their vision and ask you, “how long will it take to deliver this?”. (Or in Agile, “what effort will it take to deliver this?”).
On one hand, you could understate your estimate to exaggerate your coding prowess. The problem comes when you need to deliver to that commitment. You either miss the commitment or work countless hours behind the scenes to meet the date.
On the other hand, you could over-estimate the time/effort to protect yourself from pressing deadlines. Although you will be saving yourself the stress of missing the deadline, the long-term effects will impact you, your team and your business. Stakeholders will question the integrity of future estimates and your team will be seen as less productive.
Informed and educated estimates are our best efforts at defining what it will take to deliver. The expectation is to be set with the Product Owner that being estimates, they will not always be true reflections of what it takes to deliver their requirements. Things can go wrong and things can go very right.
What you can promise your Product Owner, however, is that every time you deliver something, you will assess how close your estimate was to reality. If it took more effort than estimated, was it because requirements were under-defined when you started the work? If it took less effort, did you realize halfway through delivery that one of your colleagues had more knowledge as to how you could deliver it quicker?
Being honest with your estimates ensures your integrity remains intact. Your Product Owner will understand that to the best of your knowledge, your estimate is accurate.
Project Managers
You’ll often find Project Managers in the mix when client-specific functionality needs to be delivered by a given deadline. Being the conduit between the customer and your business, they’ll often mirror the emotions of the customer. When a deadline has been hit, they’ll exude gratitude and celebrate your successes with you. Understandably, however, if the delivery plan is showing signs of being jeopardized, it’s not uncommon to see your Project Manager start losing their cool.
The key to keeping your Project Manager happy is to focus on the push factors (as opposed to waiting for them to pull information from you).
Driver: Ensuring delivery is in line with expectations; not exceeding budget, agreed deadlines or compromising on deliverables
“How’s things progressing?”
When kept in the dark, Project Managers will hunt you down to find the answers out themselves. This may well happen midway through the day when you’re in flow state and at your most productive. It’s frustrating therefore to find someone at your desk questioning how things are going and if everything is still on track.
Project Managers have a job to do though and need to be relentless in knowing if everything is going to plan. To mitigate the need for them to pay you impromptu visits, you will need to take control of the situation. Have a conversation with them to discuss what information they need and how frequently they need it.
This could well be a quick one-liner email to the Project Manager at the end of every day or you may be able to point them in the direction of your Burndown Chart. Whatever it turns out to be, have the conversation with them and agree upon a mutually beneficial format and frequency.
By pushing this information to them instead of them relying on pulling it from you, you can protect your invaluable, productive hours of the working day.
Be open and honest
A project delivery plan that is left in a red state is of no use. Imagine standing in the middle of a road, seeing a car one kilometre away from you driving towards you and choosing to do nothing to stop it from hitting you.
As inevitable it is that the car will hit you, leaving a project delivery plan in a red state will inevitably fail to meet expectations.
If your Project Manager gets a sniff that their project delivery plan is turning red, they’ll be looking to see what they can do to bring it back on track again. The later in the day they discover the project is running off course, the more extreme the measure will be to rectify the problem. For Developers, this can mean working additional hours in the evenings and weekend to make ends meet.
If you sense that something isn’t going to plan, it’s best to be open and honest with your Project Manager as soon as possible. Trying to hide the issue or valiantly fix it before anyone finds out is likely to lead to problems. By raising the red flag, you are giving the Project Manager as much notice as possible to handle customer expectations. Also, the size and effort of the corrective action will be considerably smaller compared to realizing there’s an issue at the eleventh hour.
Support Team
Imagine if you had to stop work every time a customer wished to ask you a question about the software you developed. You’d never get anything done!
Your Support Team are the first line responders at hand to coolly and calmly interact with the people in receipt of your software. Sometimes, they need to diplomatically help the customer realize the error of their ways. Other times, in the face of adversity, the Support Team need to address errors in your software with logical measures to triage the problem.
Driver: Being able to resolve 100% of customer issues first time whilst utilising the customer’s voice to influence future product improvements
“Let me show you where the problem is…”
Electronic tooling allows tickets from the Support Team to be passed to the Development Team without needing to meet face to face.
The written word can sometimes lose context and meaning. Humans, by their very nature, are more likely to understand complex problems via the medium of storytelling. I have made the mistake in the past of misunderstanding the problem written on a Support Team ticket. I found myself implementing a solution to the wrong problem.
Treat the Support Team ticket as the start of a conversation.
When setting out to fix the bug, allocate a portion of time to sit with a member of the Support Team to talk you through the issue. If possible, let them replicate the problem in front of you so you can see the cause and effect.
Before bringing the conversation to a close, confirm with the Support Team what they believe the desired fix should look like. You could implement a solution of your choosing but the Support Team understands the customer better than you. Gain insight from the Support Team as to what functionality would be accepted by the customer as a viable solution.
Share your knowledge
During my years as a Developer, I’ve had the pleasure of working with some exceptional Support Teams. Support Teams filled with people that have the desire to move mountains to ensure their customer is happy. People that have the subject matter expertise to understand the most complex of queries. Within these Support Teams, you’re also likely to find people at the start of their careers looking to take their next step into the world of information technology.
Look for opportunities to share the wealth of your knowledge with your Support Team. Not everyone wants to become a Developer but keep a lookout for Support Team members showing an interest in your trade.
When demonstrating the fix to a bug to an enthusiastic Support Team member, make the effort to ask if they want to see the inner-workings of your code. Take them on the journey as to how you took the problem, diagnosed the issue and implemented your fix.
Your actions may end up influencing tomorrow’s up-and-coming Developer. You may also be provided with a more informed prognosis from the Support Team when future bugs are handed over to you.
DevOps Engineers
You may have coded the greatest feature your company has seen to date but unless it is deployed and made available to your end customers, no business value will be realized. Likewise, once your new software is released into the wild, how do you know it’s functioning as expected?
Your DevOps Team are at hand to deliver your software into this world and conduct the necessary health checks to ensure it doesn’t become unruly.
Driver: Being able to maintain a healthy system with 100% availability, remediating issues before the customer experiences degraded performance
Think delivery, not just development
It’s one thing coding a solution, it’s another thing to deliver it in its working form to the customer.
Once you’ve completed your coding and handed it over to the Tester, it is not off your plate — you are to own it through to its delivery. When you have a DevOps Team looking after your deployments, this means providing them with the instructions as to how they deploy your work.
If you are using automated build and release pipelines, you want to ensure the process is predictable and repeatable; SQL scripts have been tested, no missing dependencies, no secret sequence of events that need to be followed to ensure it works. 100% predictable and repeatable.
Without automated builds and deployments, you’ll need to provide an adequate level of deployment notes. A step-by-step sequence of events detailing how to deploy your work onto the Production system. Ensure you test these steps out yourself before passing them over to the DevOps Team. As said, you’re still accountable for your work at this stage.
“Ok, we’ve just deployed it but how do we know it‘s working as expected?”
Your work is now deployed and “live”. How do we know it’s gone to plan though?
Work with your DevOps Team to come up with some quick checks to conduct once it’s been deployed. This could be checking your New Relic or Datadog instance for any unexpected activity. Another common approach is running through some scenarios via the user interface to check a critical path.
Whatever you choose to be a suitable measure before you can deem your work “Done”, the collaboration between you and DevOps is key. You have knowledge of the change being conducted, they have the knowledge of the means available to prove its success.
Without these discussions, you’re risking customers finding problems before you do.
For a long time, Developers have been told: “Code is King”. This phrase still holds true but as another famous adage goes, “behind every great man there’s a great woman”. I, therefore, encourage Developers to remember that in addition to the King, be mindful of his female companion…
…Communication is Queen
By knowing what drives each of your stakeholders, you can align your actions with what they wish to achieve. This symbiotic relationship can be strengthened by practicing the interactions mentioned in this article.
If I missed any stakeholders or other useful tips, feel free to drop me a message below.
