Recently a team member sent around a link to a post from Matt Briggs about the role of a Senior Developer. It’s a very interesting read that I recommend to anyone who wants to grow as a developer. The post is an over simplification of what it means to be a junior, intermediate, or senior developer, but it also goes out of the way to point this out to the reader.
As a developer who has only been a professional in the industry for slightly over 3 years, I find it enjoyable to read an article that makes a point of time does not make a senior developer. We truly are part of a young industry. Studies in computer science are some of the only “new” sciences in the modern world. Artificial Intelligence for example, pre WWI would be nothing more than a crazy fantasy. Whereas now, google has cars that can drive themselves. In an industry so young there is no magic formula to determine if someone is a senior developer, but somehow we’ve decided time determines the title, despite the fact that this is entirely wrong. Before I had even completed my 2nd year in the industry, I was already leading a team of 4 other developers. Its not because I was the senior on the team, Its because I work hard at my job, and I earned the privilege. (its also because I work for an awesome company that works to provide leadership opportunities regardless of tenure).
Lets put aside my rant of how obviously awesome I am, and ignoring the fact that I clearly grace the face of the earth with my presence.
Here is one of the distinctions about an intermediate developer from the blog post:
An intermediate is someone who is looking for answers on how to build things The Right Way, and finding them through experimentation, literature, and discussion with other programmers.
The way I see it is an intermediate is someone who is trying to build things The Perfect Way. An intermediate always believes that there is a perfect or right way of doing everything. Each problem can be perfect and beautiful if it is engineered and architected properly. The perfect design pattern will allow for the ultimate flexibility. Changing the requirements on me? No Problem. Add a feature? Piece of cake. Nothing can survive my ultimate engineering mind.
I have reached a point where I don’t believe this anymore. Architecture and engineering are essential to making good code. But the quest for Perfect code will always leave you empty handed.
Don’t get me wrong, you will absolutely write code that you believe to be Perfect. But have another developer review your code, or give yourself 10-15 months. It is never as Perfect as you once thought it to be.
This doesn’t mean that we shouldn’t keep trying to write good code. We should always try to make things elegant, beautiful and dare I say ‘sexy’. But we should also recognize that no code lasts forever.
I recently had to relearn this. I wrote some code that was beautiful, sexy, everything that you could dream of. But then, like clockwork, Apple announced iOS 9.
The reason I bring this up in particular is because even if we write some code that we truly believe will stand the test of time. Even if we write something that will never have changing requirements. Even if we write Perfect code. There will always be an outside entity. There will always be a world outside of the sandbox of our code. Microsoft will still release a new .net. Mongo will still update. Angular 2.0 will still break Angular 1.0. Google will still release Android 5. Samsung will still screw up Android 5. Apple will still release iOS 9. Whether you live in the sandbox world of Apple, Microsoft and Google, or the free land of GitHub, things will still change.
As we progress from intermediate to senior, we have to know, don’t stop trying to make things better. Perfect is a journey with no destination, as such, we can never get closer to the finish line. But we can always get further away from the starting line.