Many imagine that building apps must be boring. Spending hours trying to make a webpage look pretty, or trying to make page loading a fraction of a section faster sounds like completely meaningless work, right? But software engineering is more than that–it’s about making people’s lives easier, connecting people to each other, and giving people tools that help them be successful in whatever their goals are. Being a software engineer is incredibly fulfilling–the challenges are just different from when I was a teacher.
My work is akin to solving puzzles and I’m going to explain why the process of puzzle-solving aka problem-solving is so fulfilling.
Building an app is like building a house. Think of a house that is under construction. The first part involves engineering and constructing the actual structure including digging up the land, laying down the concrete foundation, constructing the beams that hold up the floors and divide the house into different sections, piping, electrical wiring, roofing, etc. Then comes the cosmetic layer such as laying down wood or tile on the floors, putting in kitchen cabinets, windows, bathtubs, doors, painting, lighting, etc. This second part has its own intricacies. Failures in this portion of the construction will affect the beauty, energy, usability, and appeal of the house but is unlikely to affect the structure or foundation.
The same kind of process applies to building software. My team has been responsible for building a whole new tool from the ground up. By the time I joined the team, the framework/foundation had already been built and we were focused on adding the cosmetic layer, while still making small changes here and there to the foundation. We execute by dividing up our work into 2 week sprints. At the beginning of every sprint, we determine which aspects of this tool need to be completed, updated, refined, fixed, removed, etc. We then create tickets, which detail individual tasks, and we track the tickets on a Jira Board (Jira is a software project management application). A week ago we launched the MVP (minimum viable product) and so now, we are focused on addressing bugs that users discover and eventually we will start adding whole new features to the tool.
As a junior engineer with very limited knowledge and experience, I started off only able to take on beginner type tasks. These tasks involve fixing some issue that has been discovered or adding a really minor feature, but there’s never step by step instructions on how to do this. So the first step for me is always to investigate. I have to figure out what the ticket is asking me to do and which part of the codebase I need to be working in (a large codebase is filled with thousands of files and hundreds of thousands of lines of code). Once I’ve located the important areas of the codebase to focus on, I have to read through the code in those areas to try to understand what the code does. Given my inexperience, I won’t understand 60-70% of the code but I can usually gather a general understanding of what it’s doing. If I find important code that I really don’t understand, I’ll then have to either do some online research OR I’ll have to ask a more senior teammate to explain the code to me. After doing this for some time I will begin to understand where I need to add code or fix code. If the problem or task is something I’ve never faced before, I’ll have to piece together a solution by 1)using context clues and logic 2)online research and/or 3)asking a teammate to point me in the right direction. Then I test my solution and tweak it until it works.
Once I’ve found a working solution I submit my solution to my team, who then reviews it and makes comments, suggestions, etc. Sometimes my code may have a minor mistake, or it’s not as efficient as it could be, and that’s where my teammates come in again. After multiple rounds of edits my team will then approve my code and my changes are added to the official company codebase. Then a Quality Assurance Analyst will go to the live tool to test the feature that I created or updated. They do everything they can to try and break the feature in order to ensure that it is well-rounded and will not break even if a user uses it improperly. For example, if a form is only supposed to take in numbers, the QA analyst will try to see what happens when they enter letters or symbols into the form (when we write code we must write it in such a way that accounts for the fact that users will make mistakes when using a feature, and some users will maliciously misuse features in order to steal data or sabotage the company). Our QA folks are very important because they will often find unexpected or unforeseen problems. Then they report back to me what they have found and I may or may not have to make another round of edits.
The cool thing about all of this is that every step along the way, I am learning. The process in summary is something like “investigate, learn, ask questions, problem solve, ask questions, problem solve, investigate, learn, problem solve.”
The reason this is fulfilling is because 1) There is so much to learn. 99% of the time I have no idea what I’m doing or how to do something. I’ll never be able to reduce this number down to 0% but it will go down very slowly over time. So there is a constant sense of growth and triumph as I learn to take on more and more complex tasks. 2)I am building real technology that other people are going to use or do use. I imagine everyone who designs/builds things whether its electronics, software, houses, cars, planes, or highways feels a very strong sense of accomplishment when dozens, thousands, or millions of people go on to use and benefit from their creations. 3)It is exciting to know how amazingly skilled I will be 5 and 10 years from now. The senior engineers on my team blow me away every day with their knowledge and ability. They make me look forward to the day when I can imagine very complex software that solves really important problems. One day I’ll be able to lead very large software development projects that impact the world.
Now, the job is fulfilling but tough days do exist. The challenges of my job come from the fact that 1)I constantly get stuck, sometimes for hours, occasionally for days, trying to figure out how to do something. Those moments can be very frustrating and emotionally taxing. I’ve been on the verge of tears more than once after spending hours trying to get a solution to work and failing over and over again. Many of the tasks I work on would take a senior engineer a small fraction of the time it takes me. So there’s always this sense of inferiority and I have to learn to become very comfortable with failure. 2)I’ve had to learn to admit my ignorance, often. Seeking help from a fellow engineer can feel like I’ve failed because I couldn’t figure it out on my own. Although my teammates are very supportive and helpful, there’s always the insecurity or fear in the back of my head that I am being judged for not knowing enough or that someone will think I’m not qualified for my job. But the more I learn to overcome these insecurities and seek help, the more I learn.
So the daily sense of inadequacy, frustration, and cluelessness can become stressful. I also hear that this stress never entirely disappears because as you become more senior your responsibility increases and the problems assigned to you become more complex. Engineers also have to constantly learn new technologies. Just like people who construct houses have to stay up to date on construction innovations, new types of materials, or new laws and restrictions, plus learn to meet the demands of clients who ask them to build houses in ways they’ve never done before.
The problem solving process within engineering is unique in many ways, but there are many careers that require problem solving and these seem to be the more fulfilling jobs because they require complex thinking, investigation, and self-reflection rather than repetitive or mundane work. In this sense, teaching is similar to software engineering. As a teacher, I was always learning, constantly strategizing and then assessing and revising my strategies. I had to use problem solving skills when trying to get specific students more engaged, or dealing with difficult parents, or helping a student with a learning disability.
So I’m happy to say that I did not leave a terrible job for a better one. I left one fulfilling job for another fulfilling job!
If you’re interested in becoming a software engineer, I hope this article can be helpful in figuring out if a career in this field is right for you! And if you’d like to talk one on one, feel free to setup a meeting here.
COSMOSIRIS 