How my dad taught me to be an engineer

Software Engineering is less about your tech stack and more about how you use the tools you have access to. Technology, languages, and frameworks change. We did not use Next.js 10 years ago. Next.js is undoubtedly different from what it was when it was released. Every language or framework is. These technologies will continue to evolve, be replaced, and die to irrelevance only for new technologies to take their place.

Dealing with all this change is a topic for another article, but underneath these ever-changing technologies is a collection of fundamentals and philosophies that prescribe how to use tools to make stuff. I don't claim to know all these fundamentals and philosophies, as it varies from person to person. I do have the ones that I was taught and follow. Here are some engineering principles I will carry for the rest of my career and my whole life, taught by my Old Man.

My father was not an engineer by trade, but he thought like one. People are rarely born with specific behavior traits, but my dad showed a creative knack for building things from a young age. From making bicycle ramps, assembling bicycles, and making deafeningly loud car stereo systems, my dad loved to make things. He continued this throughout his life, bringing vehicles back from the dead, modifying the room layout in the house, building a patio cover, designing an automatic water change system for our aquarium, and modifying his motorcycle. This list goes on and on. Building and fixing things was my dad's happy and safe place. My dad was always thinking about ways to optimize his work. I was fortunate enough to spend lots of time helping him build things, and through that, I learned many skills and philosophies that I would like to share. Unfortunately, my dad died in a motorcycle accident. It is sad, but I am incredibly grateful for the time we had and the skills he taught me.

A large part of our jobs as engineers is knowing a wide range of tools and knowing when and how to use the best one for the task. I doubt I am exaggerating when I say there are millions of ways to do one task. However, the best approach depends on the situation, your goals, and what you have access to. If your goal is to make something as quickly as possible, you will likely use different tools than someone who plans on maintaining the software for 10+ years. Even more so, you will likely use your tools differently.

My dad loved tools. He had an entire trailer full of them. He had tools for doing specific tasks like taking off motorcycle fairings or trimming palm trees. He used his miter saw when cutting wood into a particular shape, not the palm tree saw. This practice might seem obvious, but you need to know what your tools are for to apply them to the correct situations. For some, it might seem evident that Next.js is a web framework while React Native is for building mobile applications, but others might not find it obvious. Also, just because you can use a tool for something doesn't mean you should. You can use vanilla JavaScript to make a website, but that doesn't mean you should use it over Next.js or Angular. Just because you can use a hand saw to cut something doesn't mean you should use it over an electric circular saw. These power tool analogies might not make the most sense, but it's what my dad taught me, and you get the point.

My dad often cut palm trees as part of his work. Ideally, he would have used tree climbing equipment or a lift, but he couldn't access those things. Instead, he used a ladder and asked a teammate to hold it while he worked. This approach was not the safest or most efficient, but it was what he had access to, and he found the right technique to do it as safely and quickly as possible.

Software Engineers are lucky because we can usually learn new tools quickly. However, we don't always have time to learn a new skill or the option to choose a different technology. If you are working on a server made in Express.js, you can't randomly start building it with Django. Even if you wanted to migrate it over, your manager might not want you to migrate to Django. What do you do? Use Express.js the best you can. As a Python developer, it might not be ideal for you, but as an engineer, you can figure out how to use it just as well as you would use a Python framework.

It is impossible to know how to solve every software engineering problem. You can't possibly memorize that many solutions, especially when dealing with issues that don't exist yet. Often what differentiates engineers is the skill to solve problems with unknown solutions. Use what you know to solve what you don't.

My dad once took a job building a shed. The client bought some sort of kit to build the shed. My dad was not familiar with building sheds or using this kind of kit. He could have told the client that he couldn't do the job, but that wasn't my dad's attitude. My dad understood that the difference between knowing enough and not knowing enough to do something is an illusion. Sure, he didn't know exactly how to build a shed, but he knew how to learn and figure it out. That is just as good, if not better, than knowing how to build the shed in the first place. Why would he turn down work that he knew he could do, even if he didn't know how to yet? That's how my dad learned how to work on cars, rebuild motorcycles, do drywall, and anything else he could do. As a side note, my dad built that shed and was hired by the same client to do more work.

Sure, I don't know C++, but I am 110% confident I could figure out how to use it. I know how to learn a new language, which is more valuable than knowing the language skill itself.

That's not to say there isn't a difference between knowing C++ and not knowing it. The point isn't to pretend you know all the skills you don't. The key here is to approach software engineering and life in general with a growth mindset. You'll never know everything you'll ever need to do your job as a software engineer, but you can grow and learn to solve problems you and others don't know how to solve yet.

My dad once said that lazy people actually work the hardest because they take shortcuts that result in more work in the long run. Smart people, on the other hand, make optimizations that take more upfront work but result in less work in the long run. The difference between the two is a difference of ignorance.

Before I continue, I should clarify that the lesson here is not to make bad shortcuts. The skill is distinguishing between a lazy shortcut and an optimization.

When cutting wood, my dad always told me, "Measure twice, cut once." That is a common saying amongst artisans but highlights a critical philosophy. A good translation is testing. Like measuring twice, writing tests takes more time upfront but saves so much time in the long run. Sure, measuring once takes less time, but if you have to go back to Home Depot to buy another piece of wood because you made a wrong cut, that second measurement would have been worth it.

Another good example is using TypeScript. JavaScript might be initially quicker, but TypeScript saves time in the long run, especially as the application expands.

Some issues require brute force and persistence. Persistence is an overarching principle encompassing many other principles. Everyone has some experience with persistence, yet it is a relatively rare skill. Doing something difficult is uncomfortable, which is generally something people try to avoid. People often view discomfort and stress as negative, but my dad and I disagree. Embrace stress and discomfort with open arms because growth, success, and fun are on the other side. Embracing discomfort is difficult, but another skill/principle makes it possible and even easy. I could talk about many Stoic ideals here, but I'll save that for another article.

In the meantime, check out this TED talk about stress.

Patience goes hand in hand with persistence, but it is a different skill. Patience is the willingness to wait to finish or accomplish something. Often, the issue is not fear of discomfort but a need to achieve things immediately. Some people get frustrated because they aren't experts after one day of studying a framework. This frustration stems from a lack of willingness and acceptance that things take time. While it is important to be efficient with your time, as this saves your company money, patience saves time, too.

When I was younger, I would get frustrated and impatient when I asked my dad to fix something, and it took more time than I thought. He explained that this mindset of getting things done immediately would make them take longer. "Don't rush," he would tell me. Doing things when you are rushing and frustrated is more challenging, leading to mistakes that take longer to fix than doing the task itself.

While people are often taught to idealize patience from a young age, you shouldn't overlook its importance. Many people comment on our shortening attention spans, so I'll keep my comment short. This skill is even more valuable in an age where people expect gratification in increasingly shorter amounts of time.

As Treebeard from The Two Towers says, "We must not be hasty".

Having persistence and patience to solve problems on your own are important skills. However, equally important is knowing when to ask for help. When teaching me how to fix things, my dad often told me that it was okay to ask for help. He displayed this skill by asking me for help himself. Again, this skill applies to all of life, but it also applies to software engineering.

Not asking for help when you should is often the result of pride and a rampant ego. Some people think they are more valuable if they can do all their tasks without help. They also feel more proud of their work. However, pride isn't what makes software successful. Also, this "do it all by myself" mindset tends to waste time, which is never valuable.

When my dad asked me for help, I often quickly pointed out the issue. When you fixate on a problem long enough, you can become sort of blind to it simultaneously. Someone else might recognize the issue quickly.

First, I said that you should persist in solving complex issues, and now I am saying to ask for help. While it might not seem so, these two principles are not contradictory. Asking for help is not giving up. On the contrary, it is an extension of persistence. You are using your resources, which include your coworkers and teammates. However, there is a balance to this. Asking for help is good, but you should try to solve it independently first. Respecting your coworkers' time is equally essential, so constantly asking for help is not ideal. On the other hand, being determined to do everything yourself is unreasonable and unhelpful.

As mentioned before, dealing with a particular bug or problem for a long time can make you blind to the solution. We get fixated on a specific aspect of the code, neglecting other areas that could cause the bug. This inability to find the bug can lead to frustration, making matters worse.

I must briefly warn you about the story I am about to tell, as it is slightly graphic but demonstrates an important lesson. Feel free to skip to the next section. You've been warned.

One day, my dad was redoing the flooring in one of the rooms. He was replacing some nasty dog and cat pee-ridden carpet with laminated wood floors. He had been working on it for a few days, spending a lot of his time after work on it. One day, he was very close to finishing the project. He finished the flooring and only had a few more pieces of baseboard to cut. He was tired and needed a break, but it was only a few more pieces, so he kept going. I don't remember if it was the last piece or the second to last, but he made a mistake when cutting it. I was helping him and noticed what was going to happen after it was too late. My dad ran his finger into the table saw. He didn't lose his finger but cut 2/3 of the way through. My dad, being my dad, drove himself to the hospital. He underwent surgery, and his finger was relatively okay. He never got a full range of motion back in that finger. This incident was all caused by my dad being tired but refusing to take a break, leading to a mistake far worse than finishing the project the next day.

From that point on, he would force himself to take a break whenever he felt weary from working on some project or task. He often joked about what happened the previous time he refused to take a needed break.

While you aren't going to accidentally chop through your finger when software engineering, you could make a silly mistake that costs lots of time and money to fix just because you were tired and needed a break. While it seems inefficient upfront, taking a break saves time and money in the long run.

Solutions come from many different places: Stack Overflow, the lead engineer, your manager, Chat GPT, or even the intern or junior engineer. While not all suggestions are created equal, don't neglect one because it came from the intern instead of the lead engineer. Consider suggestions at face value, without bias. This is a challenging skill, but it is essential.

Yes, the lead engineer likely has a better approach than the intern, but that doesn't mean they actually do.

My dad worked with many different people with varying skill levels, but he never neglected or favored suggestions because of who gave them. When I, someone who knew little about cars, offered a suggestion on how to fix one, my dad honestly considered it. There were a few occasions where my suggestion was actually the solution. We might have spent longer solving the issue if he had brushed aside my suggestion just because I was less experienced.

Software development is incredible (I might be biased) and super fun. Unfortunately, getting caught up in the day-to-day work is easy, and we lose sight of how lucky we are. Being a software engineer is the dream job of millions, so be grateful and have fun with it.

When working on projects with my dad, he would always show me how fun it was. We never took it so seriously that it wasn't fun anymore. He would show me things that were "cool," such as his electric PVC cutters or laser measurement tool. It is common to get so used to modern technology that it loses its fun. However, developers from 20 years ago would be amazed at the things some of us see as typical.

The antidote to this is approaching your work with enthusiasm and curiosity. Again, there are tons of Stoic principles I could talk about here. I'll mention one. Epictetus says, "People are troubled not by things but by their judgments about things." This idea applies to having fun with your work. If you want work to be fun, see it as fun. View your tasks from an enthusiastic and curious perspective instead of an "I do this everyday-this is boring" perspective. Not only will you enjoy your work more, but you will likely do a better job. Enthusiasm is more potent than caffeine, and I know how powerful caffeine is for some of you.

When I first got diagnosed with myopia (nearsightedness), the optometrist told me I couldn't be a pilot because of it. I'm unsure if this is true or why she told me this, but I believed it. It didn't bother me because I had no interest in being a pilot. I told my dad about it casually, and he stopped me with all seriousness. He told me not to let anyone tell me what I'm capable or not capable of. He said if I want to achieve something, I must at least try.

As a software engineer with a less common background, I've heard my fair share of "you can't." If I dared to let that bother me, I would simply remember what my dad told me. This principle applies to you even if you have a conventional background. If someone says you can't work at your dream company, or even if they say the chances are low, don't let that discourage you. Try anyway, even if the chances are incredibly slim. If you are passionate about it, giving up because someone told you to is silly.

While lots of people think you are not capable, there are also plenty of people who believe you are. Choose to listen to those people instead. Don't decide the outcome before you even try. Rejecting doubt applies to the job search and actual engineering. If engineers only did what seemed clearly possible, our technology and software would be nowhere near where it is.

One of the last things my dad told me before he died was to take time for myself. He explained that your life will flash by if all you do is work. As software engineers, getting lost in learning the next, best framework or technology or trying to fix that pesky bug is common. However, life is more than engineering. Live your life, and live it well. To do this, you must take time for yourself. Don't neglect your health, friends and family, or hobbies. Balancing your life will allow you to do your work with higher energy and success.

That was a long article for my first post, but I genuinely believe in these philosophies, and I wanted to appreciate the skills my dad taught me. I hope you find something valuable.

Live well and happy engineering.