Computer science as it’s taught in school is not enough to craft good software. The majority of software written, even if it’s in the context of a larger project, begins in a wide-open design space. A blank canvas, so to speak. This, in my opinion, is where engineering meets art form, and it is what makes software engineering truly enjoyable.

Software engineering is full of standard practices, tools, strategies, and techniques. These are the kinds of things you learn about in school and on the job through experience. In school, you learn about algorithms, data structures, programming paradigms, and theory. Once you’re in the real-world, you begin learning about source control, trade studies, and software architecture, among other things. These are all very well understood topics. In a sense, you don’t have to think too much to apply them. They are straight-forward things you either know how to use, or you don’t. Knowing these is table stakes for software engineering. You need to know these things to be effective at your job.

There are no teachers, books, or YouTube videos that will tell you how to design and craft the code you are trying to write, because there are just too many “it depends” choices. You have to find your own style, through trial and error.

Let’s switch gears for a moment and talk about music. Musicians will often toe the line between theory and art, especially during composition. However, by and large, they spend more of their time on the “art” side. It’s worth noting that musicians are referred to as “artists” and not “music engineers”, despite many musicians relying heavily on history and theory (some more than others). When composing a new song, there is a lot of trial and error. They will try many different lines, exploring the space of harmony and melody, until they find a line that “feels right”, and then they will keep going.

I think one of the keys to being a good software engineer is to be willing to explore the design space a little more, and choose a path that “feels right”. This is especially important if you are making a large design decision, with far-reaching impact (e.g. a library that is widely used). The key is that you must explore. You will not be able to assess whether it feels right until you try it out. And even after you try it out, it’s usually a good idea to sleep on it. This allows a chance for your inner voice to speak up. In the morning, it’s much easier to answer the question: “does it feel right”? If it doesn’t feel right, go back to the drawing board.

This idea of exploration in software engineering implies that you will write code that will never be used. This is normal, and a good thing. By analogy, this is the musician’s line that almost sounded good, but was not quite right. It only ever existed for that brief moment in time, but it served as a spring board to allow the musician to find the right line.

It feels like there is a stigma in software engineering that you must write code once, and it must be correct and good. This is akin to asking a musician to compose a song on the fly, completely improvised. It’s possible, but extremely difficult, and usually results in something that could have been done better with more thought and time. Much of this stigma stems from schedule pressure, and the fact that most projects don’t budget for “experimentation” time.

How will you know when something feels right? I think this becomes easier the more experience you have. A junior engineer fresh out of college will not have a trustworthy “inner voice”, because they just haven’t failed enough to learn the right lessons. It can be a good idea for junior engineers to ask their seniors whether the solution “feels right”. Even for the junior engineer, it is important that they listen to their inner voice, and tune it over time based on the lessons they learn. Once they’ve been engineering for long enough, they can begin to trust their inner voice more.

In summary: don’t be afraid to throw away code. And if you’ve implemented something that has a large impact on the product, take time to ask yourself “does this feel like the right solution?”, and then sleep on it.