As Long As It Compiles

This is something I wish I had understood before getting ready to find my first job straight out of college. It would have saved me from a significant misunderstanding about what building software really involves—a misunderstanding that I see many new software engineers make when joining the industry.

It wasn’t apparent to me when I first started working as a software engineer intern. Admittedly, it wasn’t even clear to me a year into my career, but when I made the realization, it helped me focus on the things that really make you a great engineer. This is something I hope will help those starting their own careers or for those who haven’t yet come to the same conclusion I have.

How is building software like building a house?

I mean this metaphorically, but drawing parallels will help highlight some key points that will hopefully change your approach to software development. This analogy was a result of having to explain my job to my elderly, non-tech-savvy neighbor once.

1. We don’t reinvent the hammer

Do construction workers build their own hammers from scratch? Chop their own lumber? Or forge their own nails? No, they don’t. Neither do software engineers.

If there is one thing school does well, it is making us believe that coding our own data structures and search algorithms from scratch is the norm. I understand the value of teaching it in school, but I have yet to come to a point in my career where I have had to build a linked list or even use one.

Besides a small subset of engineers, the majority of us do not reinvent or build things from scratch. Like construction workers, we use ready-made tools and materials. I don’t want to discourage the scholarly folks who want to keep pushing the boundaries of computer science, but for the majority of us who will end up working for profit-making companies, we use what is readily available.

What I mean is, all those nifty data structures you learn about are usually packaged as part of the programming language you are using. We do build search features, but not the underlying algorithms that do most of the work. Spoiler alert: most of the time, it’s a query to a database.

Most of these large projects we work on are made up of other people’s code, often from people who have never worked at the company. They take the form of dependencies, libraries, or frameworks. Want to know why there are so many import statements at the top of most code files? Because we like to borrow code so we don’t reinvent the hammer.

2. Building a house takes many different tools

Imagine a construction worker who only learns to use a hammer and nothing else. Think about how far they can get building a house if that’s all they know. Learning and focusing on only one tool, in most cases, the programming language alone, won’t get you far. Instead, focus on trying to learn all the different tools available to you.

I have seen many junior developers enter the industry and focus solely on coding as a means to grow in their careers. Don’t do that. Instead, try to open yourself up to learning all the different technologies and tools that companies use. Learn why they are used and how they are used, then maybe look to see if there are alternatives.

There is a common joke in software that if you only know how to use a hammer, every problem starts to look like a nail. Trust me, from experience, not all problems are nails, and not all the problems you will encounter while building software can be solved if you just code harder. Sometimes you will need to debug an issue and will need to rely on your IDE, sometimes you will deal with a customer issue that will require you to go looking in a database, or building a REST endpoint—better fire up Postman. Just like in construction, tools were built to make our lives easier, to make building a house easier, so do not neglect their importance.

3. Don’t forget you are building a house

This is where building a house and software look the most alike to me. You’ve got your materials and tools, and you are ready to build a house. But remember, a house isn’t just some walls with windows, a roof, and a door; it also includes all the electrical wiring and plumbing pipes with flowing water and, most importantly, the foundation it sits on. Software development is about putting together a bunch of different parts to build a larger whole. Not all of it is code.

It’s easy to get overwhelmed when you first start a job. It’s like being dropped into the middle of a construction site with no idea what’s going on. All the people moving around you—it’s easy to feel intimidated. Maybe for the first few days, they will just have you carrying things from one side to the other, and maybe after a while, they let you hold a hammer. We all started off like that, but the important thing I want to stress is don’t forget to take a step back to see the house get built.

Most modern software is built with the help of an infrastructure team, or DevOps, or whatever they call it. They play a critical role in making sure that the software is secure, deployable, and available to customers. Every software project I have ever worked on relies on a database to store and retrieve data. For customers to use the software, there are UX Designers and engineers working together to put text and buttons on a screen. Software is also built by putting a bunch of pieces together with the help of many people.

4. Before there was a house there were plans drawn up

This was one of the harder things for me to understand early in my career, and one I have seen others struggle with. Imagine you have been working in construction for a bit, and you know how to add a window to a house. Your manager comes up to you and asks you to add a window to one of the walls. If your instinct is like mine and you go and add the window without asking anyone anything, you would already be wrong.

The impulse to act on very little information is something I struggled with early on. I did not allow myself time to stop and think about whether I had all the information I needed. For example, I should have asked: What size window? Where exactly do they want it? When does it need to be done by? This is something I see many juniors do; they are so excited to build something they don’t stop to think whether they may need more information. Not once in my career have I ever built something meaningful and had all the information I need upfront.

If you have ever seen a construction crew, they don’t start by simply erecting a house in the first empty space they find. The lots for each home have been defined, the number of rooms, the location of the water pipes, the electrical wiring have all been laid out ahead of time. Software is sometimes like this. There is usually a product team that has some vision or idea of what they want built. Sometimes the vision is clear, but sometimes it’s very ambiguous. My point is, stop to ask questions and make sure you are building what is expected.

I will say that as you gain more experience, this particular part of the software-building process becomes a lot more collaborative.

5. There are building standards for a reason

Did you know the average width gap between the center of two studs is 16 inches? Do you know why it’s 16 inches? Because after many years of building homes, construction companies found that it’s an ideal width that balances structural integrity, material efficiency, and facilitates the installation of other things such as drywall, wiring, and plumbing. Software has these building standards as well, but they come in the form of best practices, design patterns, and methodologies.

There is a reason we don’t continue to build our homes out of mud and sticks, because we found better ways to build homes. Humans have been building homes for ages, and all that knowledge has been passed down and shared. Engineers have been building software before most of us were even born. There is a lot of learning and knowledge that has been passed down from them as well. Take the time to learn those lessons. You can’t begin to build better software if you don’t learn from the successes and failures of others.

When you start in this career, you will quickly find that you really hate deadlines. There will often be expectations to finish things faster while still delivering good quality. This is where learning best practices and common design patterns can help you. They help set a baseline for problem solving that has been iterated and improved on.

One huge word of caution with this and maybe it won’t make sense until you have learned it the hard way like I did, but make sure you are using the right solution for the job, many patterns may seem like they can help but the devil is in the details. You may find yourself introducing complexity for no reason.

6. Learn how the house gets built

As I mentioned before, a house is made of many parts put together by many people. If you truly want to advance in your career, my suggestion to you is to learn how the house gets built. Maybe take time to learn how to manage a database, or take time to learn how cloud providers like AWS and Azure work, or take time to learn how an idea can become a feature. You won’t learn to build a house in a day; this will take several years to accomplish, but set yourself on the right path. Don’t just focus on becoming better with just a hammer because it will limit your opportunities. At the end of the day, companies pay us to build houses because that is what they sell. Become the person who knows how to build a house.