Improve Your Thinking

We’ve all worked with them. There is always that one developer who is called a “senior” developer. They’ll tell you that they have 12 years of experience, but after you watch them work for a while, you realize that they really have one year of experience, repeated 12 times. While this has been something that nearly every developer has noticed in their career, few take the time to really quantify what it means to be a senior developer. It’s not really about the number of years of experience you have, but rather about how the years of experience force you to think about your code in a wider context. If you look at the history of manufacturing and industrial development all the way up to the age of software, you’ll realize that the core principle is all about leverage. In the most basic sense, your work as developer (or as someone working on the average industrial project, for that matter) is centered around trying to make it so that someone else can use your work to be more effective at their job. Essentially, in most development jobs, you don’t DO THE WORK, you simply make it so that the people doing the work can do so more effectively. This understanding of your job is probably not the one you were taught in school, but is nevertheless the one that really matters to your employer. You either do the work yourself or you make the work more efficient – regardless of what they tell you, they aren’t hiring you for anything else. If you understand this, it’s not as difficult to advance in your job or to get a better job elsewhere. If you don’t understand it, getting a better job or advancing in your current job is impossible, regardless of how long you’ve been in the industry, because you will be making less than optimal decisions. The way you think as a developer determines how far along you really are. There are plenty of beginner developers that have the mindset of a senior developer (without some of the required practice), just as there are plenty of senior developers who have very neophyte understandings of what they are actually doing. While hiring managers often view a senior developer as someone with years of experience, this is really a secondary understanding of the type of leverage that a senior developer can (should) be able to provide. If you can provide this sort of value as a junior or mid-level developer, you will be well ahead of the other people at your level. Ultimately, it all comes down to an understanding of how developers can provide leverage to their employers. Episode Breakdown Considering pulling in a third party component to handle part of the application functionality, assuming the component works well and has a reasonable cost. A bad approach would be “I don’t want to learn how to use that component – I’ll just write my own”. The problems with this are that most things are more complicated than you’d think and that ongoing maintenance can be a real pain. A better approach would be to directly integrate the new component into your code and deal with the consequences. While this gives you the advantage of using the new component, you are still facing some risk if the component changes, has a major security issue, or has a bug. The best approach would be to integrate the new component in a way that decouples its implementation from the rest of the application. This lets you get the benefit of using the component, but limits the number of problems the component can cause for the rest of the application. Notice as the developer uses better approaches, they do so with an eye towards first reducing costs (via using a component someone else has built) and then with consideration towards limiting systemic risk. A critical error has occurred in production and it is due to an entirely preventable problem.