Improving developer skills: Knowing when code is not the solution
Solving problems with code is something all software developers love to do, it probably ignited your passion in the first place and keeps you motivated in your career and side projects alike. Getting to a point where yourself and peers might agree that you are a good developer requires you to solve problems with code that is human understandable, robust and change-able in a timely fashion. However, I believe it’s progression beyond this stage where differentiation in ability starts to go beyond how your code ‘looks-and-feels’ and starts to become a question of ‘do you know when to wield your powers?’
In martial arts (not my speciality, but I can read Wikipedia just as well as the next person), the black belt does not symbolise mastery, it denotes the beginning of advanced learning. Similarly in software development, after a few years you feel confident, you feel like a good developer, implementations of clean code are not alien to you, test frameworks are your best friend and it feels like no coding problem is insurmountable… but this is just the start of advanced learning my young padawan (PS: it doesn’t matter how young/old/somewhere-in-between you are for this to be applicable).
Developers who have been around the block know that all systems rust without attention. The influence of the original developer(s) ability, and that of anyone who touched it since inception, pales in significance to other forces that act on systems over time. Everything from deprecated libraries, change in business focus, increase in workload demand, changes to team personnel and more, means that delivering sustainable, predictable, value over time is harder the more software there is to maintain. At every stage in a system’s life it will do something bespoke (hopefully it’s that bespoke-ness that makes the system/product/service/capability valuable!), but there is a point in time where the amount of bespoke-ness acts against the delivery of value. It is this inflexion that great developers can foresee and guard against, thus making their expertise more valuable to peers and the organisation they contribute to. I believe you can be one of those great developers by knowing when writing code is not the optimum solution, let me give you a few examples.
It’s ironic that all developers lean heavily on third-party libraries to get the job done, but rarely consider third-party services as a complete alternative. Consideration to buying ‘off-the-shelf’, or re-using something internal, over building yourself is not just the Architect’s job, it’s yours too. You are part of the maker community, the ones who deliver the vision, without you nothing is achieved. Make yourself aware of services in your domain that you could recommend as reasonable alternatives to spending time, effort and money on building and maintaining something in-house. Examples of functionality that you would benefit from not building include auth, logging, monitoring, alerting, user analytics, test frameworks (you want to spend more time writing business logic than it takes to keep the test suite running reliably…)
You want system A to send to system B, you naturally either build something in both or, if at least one is SaaS, something in-between to provide that functionality, but what if they can be ‘connected’ without that additional component? Integrating your version control system with your cloud deployment platform, with your team communication tool, and your organisation change management system — think ‘plugins’!
At a finer granularity, cloud platforms are forever providing abstractions from infrastructure and ‘glueware’ with service integrations. For example, next time you need a metadata endpoint for an API on AWS, consider an API Gateway/DynamoDB integration (or AppSync resolver if using GraphQL) instead of writing a Lambda to connect the two. Doing some up front thinking, and trying to work within the constraints of that integration, gives you an easier to maintain solution for the future (next time you need to bump your lambda versions there’s one less thing to do).
It won’t work in every scenario, but if there’s one thing you change in your approach to your next problem make it evaluating whether writing code is the best thing to do. It doesn’t detract from your awesome skills right now and it might save you some pain down the road 🎈