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?

Photo by Uriel Soberanes on Unsplash

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.

Service reuse

Service integrations

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 🎈