Get Inspired
Have you ever had a moment when you discovered a new way of doing things, and it totally rocked your world?
Did that question fill you with excitement? Or frustration? Or maybe bewilderment?
I believe for many people, this is a key to truly growing and enjoying programming.
Defensive programming
We all go through phases as developers.
When I learned programming, after the initial discovery phase where everything was fresh and new, I began to realize that doing things in certain ways caused certain problems.
That’s a pretty natural part of the learning process. But it also makes development difficult.
Before you know better, you prematurely optimize… or prematurely refactor. You neglect to use source control. You use a database when all you needed was a file. You neglect to write tests for a critical logic path, and realize later you can’t add tests without a significant refactor. You over-engineer something and create an unmaintainable mess.
We get bitten, and it hurts, so we seek ways to prevent that in the future. We read about best practices. We read about all the ways you should or shouldn’t do something.
Or maybe we don’t even need the failure to motivate us to research — maybe we’re just naturally reluctant to make a move without knowing the “right” way.
Either way, we turn to others and start to build a suite of shoulds and shouldn’ts. We start to “should” on ourselves.
And — I’m speaking for myself here — I really started to put stock in my list of rules. I got annoyed (and unfortunately still sometimes get annoyed) when people didn’t adhere to them. “How can they not see this? It’s so obvious. They must not care.”
Of course, the first thing worth saying is that most of those rules probably apply only in a few very specific circumstances. Even when they do apply, there are still likely alternatives.
But what I really want to focus on is the fact that trying to observe a bunch of rules doesn’t create high quality work. It’s defensive thinking. You’re spending so much energy trying to avoid what could go wrong that you miss out of the box, innovative solutions. In my experience, the best product comes from the most creative solution. If you’re limiting your creativity and your thinking by rules, you’ll never get there.
That’s because programming is all about tradeoffs. There is no inherently “best” way to develop all software. Rather, with every decision you make, you’re prioritizing one thing over another.
Following rules without thinking cuts off whole categories of possible solutions, without you even being able to examine them for their tradeoffs.
As you gain experience, you do naturally gain wisdom. You learn that certain types of approaches work better than others in certain types of situations. More importantly, you understand why, and you can adapt your approach to the current situation, because no two scenarios are exactly the same.
The trouble occurs when we maintain and enforce rules. Understanding, when combined with experience and self-reflection, creates wisdom. But rules limit our ability to understand, because they create artificial boundaries, and we stop considering any possibilities beyond those boundaries.
A better way
The key is to have an ideal that you strive for.
I don’t mean an abstract idea, like “clean code” or “well-tested code”. Those things could be ways of getting to your ideal, but they’re not what I mean by ideals.
Rather, I mean an actual experience in your past that was pivotal for you. Think back to a time when you experienced code, a product, or a development process that inspired you, changed your mindset, brought excitement, brought you joy.
A notable one for me was what you might call a “glassy” UI. My experience was that most websites and applications were filled with bugs, glitches, and were slow and often unresponsive. But then I came across a handful of apps that were on a completely different level, and were a pleasure to use. When I began programming, I did some experimenting and realized how simple it really was to achieve this. I learned some basics about the CPU and memory, and it completely changed the way I saw development.
Rather than performance being some lofty goal you could only achieve by adding all sorts of additional systems and optimizations, I realized that computers are naturally incredibly fast. What’s hindering performance in most modern-day applications is not a lack of optimization — it’s the presence of a lot of extra work the computer doesn’t really need to do. Increasing performance means removing unnecessary things getting in the computer’s way.
Removing unnecessary things was something I could do!
I wasn’t using low-level languages at my day job. But the ideal still applied to web development. I found that by removing a lot of the stuff that runs by default in web apps, I was able to achieve a much higher performing result than I had before. Since I knew the goal was to remove stuff rather than add optimizations, I was able to come up with all manner of creative ways to achieve that objective… while still balancing maintainability. Of course, I never achieved in Web apps the level of performance I had from native code… but it was always a personal goal to reach for. So it’s a way to continually push for excellence. It made me a much better programmer, because I was constantly seeking to improve.
Since my goal was measurable (is this application fast enough for my preferences?), I was able to rate potential solutions by an objective measure. And so I was able to have confidence in my decisions, because I knew how to judge them. That’s so much more freeing than trying to keep up with all the current “best practices”, which in many cases are constantly changing, and even different depending on who you ask.
Of course, if you’re working for a company producing software, the development team will have their own conventions and best practices, so you will need to balance — and override — any ideal you personally hold with their programming culture.
But in my case, there are plenty of ways to advance performance in web applications while adhering to a team’s chosen culture and best practices, and I’d venture to guess it’s probably the same with whatever your ideal is.
People have commented on my ability to produce innovative ideas or solutions they hadn’t thought of before. Much of the time, this is because I’m oriented toward my ideal, so I have a never-ending supply of motivation and ideas to achieve it.
What if you don’t have an ideal?
Get one!
Remember, I’m not talking about dogma, or a list of rules. I’m talking about an experience you had that inspires you and brings you joy. So much joy that you reorient your development process in order to achieve or reproduce that.
If you haven’t had an experience like that, then maybe the seed is already there, but you don’t know it yet. Maybe there’s a video game you love to play, or a productivity app that makes one aspect of your life ten times easier. Or maybe it’s a particular development process or practice that sparks joy in you, that makes you love the process of building something.
If you’re having trouble thinking of something, you might try thinking of things that really annoy you… and then think of something that doesn’t annoy you. Why doesn’t it annoy you? What sets it apart from the things that do? Is there another app or process out there that maybe does it better? If you could make it even better, what would you do? If there are no better examples, could you create one?
Whatever it is, examine it. Think about why you like it. What makes this app better than others? What sets it apart? Is it the aesthetic? Or the gameplay? The beautiful UX?
If it’s a development practice that you love, ask yourself why. What emotion does it stir in you? How does it benefit your life?
As you delve deep and ask these questions, enjoy the process. Digest it, think about it, turn it over and play with it in your imagination. Eventually you may start to notice that you start to have new ideas about it.
If nothing comes, or you start to experience frustration, don’t force it. Put it down and walk away, and come back to it later, if you feel like it. The whole point is to find enjoyment and excitement in programming, not force yourself to do another thing you don’t like.
Once you’ve identified what you love and why, try replicating it yourself. Get your hands on it. Get a taste for what it’s like to build your own version. Make it yours.
If you’re able to do this, I really believe it will change your development experience. You’ll be more creative, more effective, learning will come naturally, and over time you’ll become a leader and teacher to your peers.