Certainty Is Fleeting
In the land of software development, certainty has a short life and often dies a painful death. Guarantees are beasts of myth and getting it right the first time is as unlikely as you slaying a fire-breathing dragon. Today’s solution maybe tomorrow’s problem and architecture that provides no real business value is the dark overlord.
You’re probably thinking one of two things, “what the hell is he talking about?” or “You’re so right, now what?” Well if you’re one of the “now what?” people, all is not lost. Knowing what makes this land so unpredictable will help. There are three key reasons for this unpredictability:
- Today's problem isn't necessarily tomorrow's problem.
- We will know more tomorrow than we know today (duh).
- The landscape is changing (languages, tools, and techniques are evolving).
The problems listed above have a lot in common and so do their solutions. How can you be certain when everything is changing? Don’t try to solve tomorrow’s problem today. Just focus on the problem at hand. A simple solution is easy to change (or easier to change than its complex counterpart). I’m sure your experience is telling you, you need to future-proof your application so it’s robust and scalable. Perhaps, I’m not saying that’s impossible. But let’s be honest with our selves, tomorrow doesn’t exist and its problems may never materialize. So unless someone is paying you to create an elaborate architecture or you have droves of users, your application may never need to scale. Especially if it’s a steaming pile of bad-user-experience.
Number two should be obvious, hence the “duh.” This point is best embellished by my favorite quote from Men in Black:
"A person is smart. People are dumb, panicky dangerous animals and you know it. Fifteen hundred years ago everybody knew the Earth was the center of the universe. Five hundred years ago, everybody knew the Earth was flat, and fifteen minutes ago, you knew that humans were alone on this planet. Imagine what you'll know tomorrow."
Reason number two doesn’t stand alone. Two and three have a symbiotic relationship. Software development is not a static discipline. You must be able and willing to adapt. Change is inevitable and accepting that fact will make it easier to deal with. So how should you spend your effort? Focus your effort on learning as a general practice; discover how you learn. Your ability to learn (and unlearn) is your most valuable skill. It’s good to keep-up with the new stuff all the cool kids are doing but that shouldn’t be your only concern. Attachment to techniques, vendors or tools will only hinder your learning. Having the ability to shed your scaly skills and grow new skills is a great virtue. You should be objective when evaluating a new technique, vendor or tool. Not because I said so, but because preference tends to cloud our ability to recognize merit.
Becoming a good software developer is a journey. Don’t get too high and don’t get too low. Avoid getting caught up in the coolness of your shiny new code. Give yourself a small pat on the back and move on. If you find out later that the code wasn’t all that special or maybe a bit buggy, don’t worry. This is a pretty regular happening. Keep your decisions and your designs small. Large complex systems are composed of many simple working parts. If you’re writing code for a complex system, ensure the pieces you’re responsible for are simple and work well. The future is uncertain and your code should mirror that reality