Combing through the copious number of job openings for software engineers, it is easy to come away with the impression that only a very narrow skillset, a specific journey in early adult life, qualifies one for the job. Often this path will include a four year CS degree from a university and a number of years in the rearview mirror working as a professional dev, accompanied by a long list of hard technical skills.
For many of us, including myself, we don’t know what exactly we want to do when we’re 18. Due to either the environment we grew up in, or societal bias, or just sheer luck, we may not have even been truly exposed to computer science and programming by this time in our lives. Even if we have, jumping headfirst into it might just not be the path that we are supposed to walk. But that doesn’t mean that it isn’t the path we are supposed to end up on — and in my personal opinion, these less traditional years are equally additive when one eventually makes the jump to engineering.
To build software is to create a digital tool of human experience. Often it is a translation of something existing in our world already. Other times it aims to offer a new solution to an age-old problem. But at the end of the day, software is about people. This is where a unique background can become a major asset. Other types of experiences teach us other types of abilities — non-technical skills, like communication and project management, business acumen, domain expertise — the list goes on. Each of these provides its own edge to software engineering, and its own value to all stakeholders, from the company, to consumers, managers, and other developers.
Communication & People
It never ceases to amaze me how wrongly it is assumed that software engineering is a solo sport. It is not (at least not if you are working on any sort of a team). Engineering is actually quite social for two reasons.
The first reason — To work effectively, engineers must be in communication with other engineers about priorities, dev decisions, and roadblocks. Frequent conversations take place with managers, product teams, design teams, marketing teams, etc, in a sort of never-ending and always-evolving feedback loop of company needs. At times, there can be a lot of voices pushing up against one another. As you can image, strong interpersonal skills are an invaluable asset in these moments. It doesn’t matter if you’re the engineer — you are a part of a team with a larger mission, and it is equally your responsibility to keep keep the trains running smoothly.
The second, engineers are contributing to a living, breathing thing that is, in itself, a form of communication. Every line of code that is written will eventually be read and interpreted by other engineers down the road. We each have a responsibility to be intentional about what we are communicating with these lines. Will it be interpreted as we intended it to? Is it clear what the code is doing, and how we expect it to be used? Have we crafted something easily navigable and easily expanded upon? This takes clear and thoughtful communication — much harder than just writing something that works.
Industry Expertise
As I said earlier, all (or at least most) software aims to provide a digital solution to an existing human problem. Many of the most lauded tech companies have found success in disrupting massive industries. The first step to this? Understanding the industry being taking on.
Now, some engineers make the mistake of thinking that this is not their responsibility. It is the job of product or operations or anyone else really, to tell the engineers what to build. But that doesn’t work. It is the engineers who have to make decisions about system design, and proper tooling, and scalability. It is engineers who, as the build process unfolds, can see the shape that things are taking, and see the tradeoffs between, say, future flexibility and time being made.
The more that we as engineers know about the business in which we are operating, the better we can navigate each one of these situations. Imagine an engineer who has worked at a record label and is now working for a music tech company. This person will be able to give nuanced input about the needs of the end users and how the program will eventually be used. Or take a dev who worked in a hospital for years, a complex ecosystem in itself, and is now working in health tech. No amount of reading and studying the needs of doctors, nurses, and patients can replace seeing it first-hand. The right unique background +engineering role fit can be absolutely indispensable to a team.
Business Acumen
This one is simple. As engineers, we work for businesses. And businesses survive through things like project timelines, budgets, progress reports — you get the picture. Engineers are an essential part of most every business these days, and the more that we are able to work with instead of against these practices, the more helpful we are to our larger teams.
The moral of this story is that there is no one path that leads to software engineering, and it is important that the field attract people who do have a variety of academic and professional background. This diversity of experience will help build more well-rounded, thoughtful, and communicative engineering cultures.
