The Three Stages of a Programmer
A pet theory of mine is, that there are three stages every programmer goes through throughout their career. Maybe they sound familiar to you.
Holy Cow, I Made the Computer Do Something
If you ever wrote even a single line of code, you probably remember the feeling when you ran your first program. Maybe it printed "hello world" to the screen. In any case it made you realise you could do anything with that mystic machine in front of you. It was a feeling of empowerment and control. Suddenly everything seemed possible, because after all you just had to add a few more lines of code to make the computer do anything.
Let Me Handle It, I'm a Pro
Some time has passed since you started out. Maybe a few days, maybe a few years, or even a few decades. In any case, now you know programming. Actually you are a pretty damn smart coder. The code practically flows out of your fingertips.
Sure, you could have done it in 5 lines. But doing it all in a single line means improves performance by saving a few unesecarry assignments. Sure, you could have split the code into a few different classes. But instead of scattering the code across multiple files you can just hide some stuff with a bit of clever scoping. Sure you could use programming patterns. But why make bloat the code if you can do your own much leaner thing?
You have quite a few opinions on what the right way to program is. And just imagine what we could do if more people would do as you do.
Actually, I Have No Idea
Some more time passes. You have waded through some code bases and worked with quite a few people. You saw code that was ugly as sin that somehow worked, and code that was an example of codemanship, yet somehow failed to solve the actual problem. You have worked with a few languages and frameworks, have dabbled in patterns, concepts and paradigms. Yet somehow the more you see and learn, the more of your opinions blur.
There seem to be countless ways to tackle any given problem and twice as many reasons to do it in a different way. Any solution has drawbacks and it's not about finding the best one, but finding the one least bad.
Code that seemed simple and elegant just a while ago, now seems arcane and unnecessary convoluted. If you just had made it readable instead of trying to be smart about it, you would be having a much easier time understanding it now.
And so you strife to make everything as clear, simple and explicit as possible. All to have a slightly higher chance of understanding what the heck the code is doing the next time you will read it.