Writing code is ultimately a creative endeavor, you start with the absence of code and finish with the existence of code. Your brain tells your fingers what to type, and then stuff happens. You can type anything you want. Just like you could paint anything you want were you painting rather than typing. You could paint a sweet picture of a sword. That would be sick. It really doesn’t matter. Of course, however, there are different outcomes depending on the combination of things you type. So if you have some specific set of ideal outcomes those are going to act as constraints. Constraints enhance creativity. Think of how little creativity a prison escape would require if prisons were parks and prisoners were told to sit on the grass for a little while. As far as prisons go that would be a bad design and The Shawsank Redemption would have been a much shorter and less interesting movie.
Luckily I work for a company that doesn’t blindly push conformity, but sometimes it’s easy to forget that we need to think laterally when we write code. We’re called Software Engineers and engineering conjures notions of rules and formality and boundries and deteminism. Blueprints to be followed. That might be closer to the truth for engineers who create physical things, but we engineer abstractions, our blueprints are less formal. Create something that keeps prisoners in generally the same spot for as long as we need them to be there. That’s about as formal as it gets a lot of times.
The scope of our requirements definitely vary. The prison example is pretty broad, like project-level broad. Most of the time the scale of our requirements are at the method level, or at least that’s the unit we work with most often. I need to take an array of user objects and return a list of first names sorted alphabetically – that kind of thing. It’s pretty specific. It’s also not a hard problem to solve. Your room to get creative is limited unless you want to write a bunch of code nobody understands. Other people understanding our code is a universal constraint placed upon us as software engineers. Like other creatives, our work must encapsulate our message, our intent. But unlike other creatives we can’t obscure our intent for the sake of being coy or to jog interpretation. However, when we’re designing how these simple atomic implementations come together to fulfill our broad requirements there isn’t always a clear path forward. We must get creative.
Most of us probably got into this profession because we like building things, solving problems, and doing it in a way that doesn’t make us feel like machines. And that’s the point, that’s what we need to remember – as creative problem solvers we flourish. We learn from each other. We are happier. We develop novel solutions. We are not calculators. This is why we should always take time to write useless code.
Useless code is code without an agenda. It may be related to the problem at hand or it might just be exploratory, what-if-we-tried-this type of code. Useless code is sketching. It’s working through your curiousity without being attached to utility. It’s taking things apart and putting them back together differently, or just flat out breaking things.
Sometimes there is definitely a smell and you aren’t sure exactly where it’s coming from, but you know you don’t like it. You can sense that things could be organized better or you’re sure there’s an abstraction hiding somewhere. Maybe there’s even an entirely new service buried in a tangle of some other things. When they’re not obvious how do you find those seams without exploring, trying, poking, prodding? You’re going to have to write some code that might just get thrown away to find your bearings and get rid of the smell. Or maybe the smell is one you have to live with, but at least you looked and now know it to be true.
We get presented with the same flavor of problems a lot so we end up reusing patterns, algorithms, and techniques. We also have to deal with technicalities a lot, things like why-won’t-this-thing-talk-to-that-thing-and-that-other-thing-is-maybe-configured-wrong-and-all-I-want-to-do-is-write-code kinds of things. Other times we have to move fast so we shove some code into a class it doesn’t belong or copy and paste from somewhere just to get things out the door. These situations come with the territory but over time they make our creative muscles tight. Useless code is stretching. Stretching creates space. Space gives you room to grow.
This all might sound like fluffy woo woo. Worse, it might sound like wasting time. That’s the wrong perspective. This approach is an investment. The freedom to be expressive, curious, and creative drives engagement and it’s profitable. It’s the only way to solve hard and new problems. Those problems are differentiators and solving them creates value. Value is nothing more than a packaged solution to a problem other people need solving. That’s the ultimate irony of useless code, it’s of utmost use.
Times are weird right now but they might also present opportunities to solve interesting problems in interesting ways with interesting code. So remember to let yourself stretch, and just as importantly, encourage the engineers you work with to stretch. Remember the difference between standards and personal preference, between telling and teaching. Remember it’s possible to communicate clearly with different sounding voices. Remember that creativity is distinct from technical know-how. Remember that this is so much freaking fun. Remember that you can type anything you want.