Over the last six months, I’ve had the chance to begin working as a professional software engineer. I was an intern at Tanium this summer, and now am working full-time as a junior software engineer at ARA. There have been many lessons that have stood out to me since entering the tech industry. Here are three more of them.
There is a big difference between personal projects and professional projects
In personal projects, the development process is easy. You plan out what you want to do, and then you go and do it yourself, hacking away until things work the way you want. Development in this fashion is what I was used to prior to working in the industry. It is what feels natural and easy. The major advantages of this style of development is that, generally speaking, you understand nearly every aspect of the codebase because you yourself actually wrote the code for it or pulled in the needed library. You don’t have to worry about anyone else’s style of coding or worry about what others on your team are doing.
However, in professional projects, the development process is very different. In large projects, you may have to plan things out for months before ever writing any code. You also have to work with a large number of other people. Beyond just the development team, you have project managers, stakeholders, engineering managers, designers, and QA team members to deal with. Often, you won’t understand all of the codebase and may only ever touch one tiny aspect of it, which you may not fully understand either. You also need to work with version control and deal with rebasing, pulling in other team members’ work, and resolving merge conflicts. There is constant code decay and technical debt that inevitably piles up.
The moral of the story is that the development process for personal projects is very different from the process for professional projects. This was a lesson that came as somewhat of a shock to me. Although I was expecting things to be fairly different, I didn’t necessarily expect it to be this different. I thought I would be pretty prepared for the work I would be doing. However, as with anything, I’ve learned that there is inevitably a learning curve with understanding the professional development process.
Process is just as important as code
Alluded to in the previous paragraph, there is a lot more to learn about the development process beyond just learning how to code. There is so many processes that go into a finished software product. As consumers, we never experience the behind-the-scenes process, and so we tend to think that software just magically appears in the finished state that we use. As I’ve jumped into the behind-the-scenes world, I’ve been learning that software can oftentimes be a messy process, with countless moving pieces, processes, and competing interests. It has sometimes been hard for me to wrap my head around just how much is going on with the pieces of software that I’m working on. I’m learning that it’s okay to be confused sometimes. It’s okay to not understand the entire process or understand how everything fits together. While the end goal is to gain a solid understanding of a project, this doesn’t happen overnight.
Software is a people business
Another big lesson I’ve also been learning is software is still, at its core, a people business. At the end of the day, software is built by people. These people have different styles of working, different ways of looking at things, different communication styles, and different attitudes and capabilities. In the professional world, a major key to success is learning how to manage these different styles and personalities, as well as learning how to develop your own style of communication. I’ve learned that focusing on how to better communicate and work effectively with your team is just as important as being a brilliant coder. In fact, I would go so far to say that being an effective collaborator is more important than being an effective coder in many cases. As an individual contributor, I can’t know or understand the entirety of a given project, so it is vital that I learn how to rely on and work effectively with my team members.
Conclusion
I suppose the overarching message of this post is that software, at the end of the day, is imperfect because it’s built by imperfect people and imperfect processes. Like I mentioned, it’s easy to think that software products, especially big tech software products, are shiny and perfect and never have any errors or vulnerabilities. This is most definitely not the case. All pieces of software that I’ve gotten the chance to work on this year have been littered with bugs, and I mean absolutely littered! Some of the most finished pieces of software still have so many bugs that I’m shocked that the product is being used in the real world by actual humans and is actually making the company money. I had no idea that building good software was so difficult and that maintaining those pieces of software over their lifespan was even more difficult.
The moral of this article, then, is that entering into the professional world of software forces you to take off your rose colored glasses and see the industry for what it is. That’s not to say that the software industry isn’t exciting or interesting because of its imperfections. In fact, I’d argue that the fact that the software industry is still full of problems and room for improvement makes it even more exciting. I just mean to say that coming into the industry with realistic expectations is something that every new software engineer should do. Software isn’t perfect, but that makes it all the more fun.
