Not Just a Code Monkey
As a developer there are many roles we can take on through a project and through our careers. First and foremost it would appear that our job is to write code and do as we are asked to deliver a product, or solve a problem. Do not underestimate how valuable your experiences as a developer are, and how you can use them to influence the solutions you deliver. Don’t settle into that comfort zone, find how to add even more value.
Recently in a retrospective with a client, our project stakeholder made a statement to his peer that they needed to be more mindful when working with project teams to ensure that they weren’t working with teams that were just doing as they were asked. He then went on to elaborate that Echobind was providing value by “challenging client requests”, and it was greatly appreciated. In our Sprint Planning and Grooming meetings, we are often asking questions to understand what problem we are trying to solve as well as talk through the potential pitfalls or options we have to solve the problem based on our experiences. When we do this, we are ensuring that our client is getting our best, and the end-user will have the best user experience possible.
Sometimes this can feel like we are walking a fine line, especially as an agency. You obviously do not want to offend your client and personalities can be challenging. Finding what works for each project takes some time. You do not come HOT right out of the gate, you build rapport and mutual respect; with this, they will value your questions and understand that your questions or comments come from a place of good intention.
When you think of your role as more than just a “coder” you not only help bring the most value to the project but you help your future self too. If we blindly do exactly what we are being asked, knowing it isn’t the best solution or that it will have a domino effect of other issues; then we will end up having to fix those later. It may seem counterintuitive that as an agency we would not want to let the client create “more work”. However, you win more business by doing your best work, and not by creating extra work that could have been avoided.
I’ll share with you a story of the value you can bring when you ask the right questions, and keep asking until you get the answers. Several years ago now, I was working on a very complex project that had very complex statistical algorithms as well as data from several sources. One of my business partners asked for a “data dump” to Excel. My first question was “Why?”. When I wasn’t getting a clear answer I then asked, “When you get this data in Excel what will you do with it? There are hundreds of thousands of lines of information here, that seems like a lot to wade through.”. The response I received was that they had a plan to write advanced formulas and some macros that would scan the data and let them know when certain criteria were met that meant a transaction should be investigated further. This would have been a very manual process and would take this person quite a bit of time to set up initially and then complete on a regular cadence. I then learned that others would need to have similar processes which meant there was room for discrepancies in how each person might be calculating these flagged transactions. After this discussion, I suggested that we allow the computer to process all these transactions each time we loaded the data, use the business rules defined to flag the appropriate items, and then alert the owner that there were a select number of items that needed their attention. This allowed them to have a repeatable process and only look at the items that required attention instead of thousands and thousands of items that did not require attention. In the end, we saved them several hours of work each week.
One last comment, just for a reality check. Just because we have these conversations doesn’t mean we always go down the suggested path either. There are of course tradeoffs. It may be necessary to make the choice to do the unfavorable task now in order to get past a hurdle or deadline, but by having the conversation all parties are aware of the risks involved or the tradeoffs being made and plans can be put in place to mitigate or address them when the time is available.
Now I challenge all of my fellow devs to raise your hand, ask the questions, provide feedback to your stakeholders. In addition, I challenge all the stakeholders out there to look for those that don’t just do what you ask but have a constructive conversation about the problem you are trying to solve so that they can deliver the best possible solution.
Cheers to being more than a code monkey! 🐵