Why Shouldn’t be a Software Engineer

Software engineering is a popular option for workers interested in a career change due to high pay, flexibility, and work-life balance. The benefits are attractive, but the job isn't right for everyone.

So, that begs the question – how do you know if you shouldn't become a software engineer? Here are some answers.

You're Not Interested in Continuous Learning

Software engineering is not a good fit if you dislike learning continuously. The upfront learning requirements for a 4-year Computer Science degree or a coding bootcamp are immense. Career-long learning requires even more desire to be up-skilling constantly.

How much continuous learning is required? A recent LinkedIn survey found that 48% of software engineers learned a new skill recently compared to just 12% of the general workforce. That tells you that half of all software engineers are continuously learning at a rate four times higher than their non-software counterparts.

Two factors drive the need to learn:

· The depth of the field
· The speed of new emerging technologies

A good software engineer must know many languages for UI design, like JavaScript, HTML and CSS. They also need a backend language like Python, Ruby, or Go and a database language like SQL or MongoDB.

Already this requires knowledge of roughly five languages.

Yet, these languages only cover a single application of building websites or apps. Along with understanding base languages to form a tech stack, different companies use different combinations of languages for their stacks.

If you have had multiple jobs, you will have had to learn various combinations of languages. Some companies may even have separate tech stacks across their projects. To be competent, you must be able to dive into different technologies and tech stack language combinations. If you are not learning new stacks to master the depths of software engineering, you may be learning to keep up with the current trend.

Learn New Things

Best practices have a shelf life. You'll likely be learning new best practices every few years.

While languages do not phase out, the frameworks built on top of them do. For anyone working in front-end development around 2010, the need to pivot to the next big thing was immense. Angular 1.0 gave way to React, then Vue, then Angular 2.0, Gatsby, NextJS, and NuxtJS. This framework rush was a nightmare. Each new framework has its benefits.

Employers, especially small companies and startups, are eager to adopt the new thing.

Software engineering requires constant learning to stay attractive and flexible with career opportunities and to maintain knowledge competency. The skills can be time-consuming to master, so eagerness to learn is a must for anyone looking to enter this field.

You Don't View Creativity as a Strength

Being creative is a requirement for becoming a software engineer. This creativity is not limited to the traditional arts, though that may help with front-end development.

In this case, creativity is the ability to approach novel issues and create novel solutions.

Printing out every item in an array is basic and uninspiring. The syntax may differ slightly, but the approach will be the same. Retrieving all records from a database table, performing string manipulation on their attributes, creating new record mappings for a 3rd party database, and syncing these records with the off-system database is an entirely different task.

Software engineering is not about copying and pasting code. It's about understanding how systems should work and applying this to loosely defined and often open-ended business requirements.

Any requirement could have infinite solutions, but it is your job to create new approaches to solve the issue. This does not always require reinventing the wheel but requires thinking critically and creatively about what you are trying to accomplish and what tools you have available.

Often the solution to your issue will not be apparent. It will take time, effort, and creativity to devise a solution that meets business requirements and works well within the system.

You Don’t Always Immerse Yourself in the Details

Immerse in Details

Attention to detail in software development goes far beyond catching syntax errors. Actual attention to detail uncovers issues like functional codes that do not solve a user or a business stakeholder's problem. Another example could be working code that leaves the app and company vulnerable to attack or constant errors.

When you design a system, do you know the peak usage hours and the read and write request volume these periods generate?

Are your systems resilient to cyberattacks or bad inputs and misuses from clueless users?

There is a lot to consider beyond if the code works.

Some of these issues fall into the category of programming deemed as defensive programming. This approach to coding looks at solving what could go wrong instead of just focusing on the best-case scenario. To predict errors, software engineers must pay attention to edge cases or situations that are not likely to happen but need to be considered.

While defensive programming catches edge cases, writing tests for your code ensures that the code will work. Software developers do not write tests for fun; they write them for peace of mind.

All of these approaches to ensure excellent user experience comes down to attention to detail, and they are a must for anyone looking to get into software engineering.

You're Not Comfortable Talking "Technical Ideas"

Trio, a developer agency, said communication is software engineers' number one soft skill. While they acknowledge that software engineering can include long periods of working on problems independently, strong communication is key for getting all team members and stakeholders on the same page.

Along with explaining functionality, a software engineer must be able to communicate the feature planning and build process. They also have to explain time constraints and costs for different solution routes. Additionally, they have to be able to take low-level details and explain them to non-technical business stakeholders so they can make informed decisions.

When technical problems arise, they need to talk with product managers about high-level issues and solutions, even though they occur at a low level. That means you must be able to communicate effectively to be both a good software engineer and an asset to your team.

You Don’t Embrace Ambiguity

Don’t Embrance Ambiguity

Do you work well when problems are not fully defined or when questions are open-ended? This is the ambiguity that software engineers live in every day. Most features or bugs are reported by business stakeholders who are not technical. They understand the business but may not and are not required to know how these business issues translate to code issues.

A software engineer is a bridge between business domain knowledge and technical implementation. This requires a lot of communication to translate vague issues of a 404 or 500 error to identifying logic errors or API outages that impact your systems.

You live in ambiguity because you work with an incomplete picture of the issues. Software engineering may not be for you if you find these situations too stressful or do not like searching for puzzle pieces to solve problems.

You're Not a Fan of Receiving Feedback

No one is perfect, and any good piece of software goes through at least a few iterations before it is ready to be brought into the world. Some of the iterations may focus on getting the code to work, but once you get to the collaborative stages of iterations, mainly code reviews, the focus shifts to best practices.

There is no definitive correct answer for solving a software engineering problem. However, some solutions are better than others. Every solution has tradeoffs for developer time, app scalability, and system resiliency. Sometimes you can have everything, but often this approach leads to over-engineering, which wastes developer time and company resources. Knowing what is "good enough" is as important as knowing how to implement this solution.

Whether you are a new developer or a staff engineer, you will be working with others. Contrary to popular media, software engineering is a very socially intensive career. Because of this, you will need to be able to communicate with others and also receive feedback from them on your work. Being told you are wrong is not always easy, but it is worth it when that is the first step to getting the correct solution. This Stack Overflow Blog post details how to keep your review process and environment productive.

Knowing you do not work well with constant feedback may make you reconsider becoming a software engineer. Developing software is driven by receiving feedback on all levels of the process, from feature ideation to final deployment. While you do not have to implement every piece of feedback you receive, you will need to be able to listen to other team members' thought processes and weigh the benefits against your proposed solution.

You Aren't Continuously Curious

A big part of learning is curiosity. Are you a generally curious person who loves to learn why things work instead of just stopping at how they work? What is the difference between the why and how?

Say you are working with an event bus pattern for sharing messages. Are you content with knowing that a function works, or are you curious to know what code supports the function working?

It may seem like splitting hairs, but curiosity about seemingly unrelated topics is vital for growing your understanding and skills as a software engineer. You will find that only some things you learn are useful. You may read many blogs before solving a problem and understanding how your code should work. The critical point is that you are curious enough to learn how things work and further examine topics around why they work.

You’re Not a Master of Managing Priorities

Master of Managing Priorities

The success of any job comes down to how well you can complete tasks in a specific order. It does not matter how well you do tasks if the order does not make sense.

Imagine firefighters cleaning up debris from a building before putting out the fire. It does not work. Software engineering is very similar. Work generally falls into two buckets:

· New features
· Fixing existing code

Either you are building new functionality for the business or customers or fixing and improving existing features.

Should you always fix existing code before developing new features?

Maybe, but that is a judgment call more than a strict rule.

You will need to be able to both judge what tasks are critical in your assigned tickets and also be able to communicate with your business stakeholders to ensure you are aligned. Even the business stakeholders may not know what takes priority, so you need to leverage your technical knowledge to determine the order of work-dependent tasks.

To succeed, you must manage and constantly reevaluate your priorities for code to build and code to fix.

You're Not Interested in the Business

You may love the idea of developing and building technical solutions, but the coding itself is only a means to the end, not the final product. Being a professional software engineer means translating the technical needs of business stakeholders into elegant, scalable, and maintainable code. For this, you need to understand the purpose of your business, from widgets to help features.

Understanding the business goes beyond building features to spec. Complete business knowledge lets you understand and predict how a user thinks and uses the system. This can lead to better-informed UI/UX decisions or data processing on the back end.

Creating a record can look entirely different depending on what the user expects. Giving users an immediate response or waiting a few minutes until a job server is accessible provides completely different experiences for your user.

You need to be curious about the business you are building solutions for. Without this interest and desire to learn about your users, you may build software solutions that do not solve users' issues or are inconsistent with their needs.

Do You Have What it Takes to Become a Software Engineer?

Suppose you read through all these points and believe that software engineering fits you, then congratulations! Software engineering can be a highly fulfilling and rewarding career path full of learning and growth.

Now that you know you want to become a software engineer, it is time to start learning. There are many ways to learn the skills for software development, but bootcamps are one of the quickest and surest ways to start your career. Check out Thinkful's Software Engineering Bootcamp, a significant next step in your software journey.

Share this article