People love to talk about legends, myths, creatures, conspiracies, and unknowns. There’s some sort of primal pleasure in trying to explore the unknowns to uncover the truths.
There’s a big problem, though: humans also love to embellish the truth to fit their narratives, ease their worries, or win over their friends. This has the unfortunate effect of causing people to accept things that simply aren’t true or are, at the very least, not totally true. Like the game of telephone, the message gets distorted, lost, or garbled until it’s not recognizable or doesn’t represent the full context of the originating source.
Remember that quote at the beginning of The Lord of the Rings movies?
“Much that once was is lost, for none now live who remember it.”
“And some things that should not have been forgotten were lost. History became legend. Legend became myth…”— Galadriel in The Lord of the Rings: The Fellowship of the Ring, The Lord of the Rings
That about sums it up.
We want to dedicate time to debunking what we find to be pervasive myths about software engineering. Whether you’ve heard about burnout culture, minimal job availability, or if you’re just suffering from imposter syndrome, we’ve got you covered.
As you read through our explanations, it’s important to remember that usually a myth begins with a foundation of truth. Somewhere along the way, the real version got manipulated or was infiltrated by noise to the point where it no longer related to the foundation. It’s not that these myths have no truth. Instead, it’s that there’s a lot more nuance and shades of gray than people want to admit.
Myth #1: All Software Engineers Experience Burnout
We all value our personal lives. We have family, friends, hobbies, personal aspirations, and relaxing downtime all trying to share a slice of our attention. These are the things that collectively define our surroundings, influences, inspirations, and support systems. Without them, we have the potential to be isolated, anxious, fearful, depressed, and a host of other negative emotions.
And yet, many of those critical parts of our lives are absent from our jobs, workplaces, and careers. Depending on how many hours you work per week (20, 30, 40, 50+), it’s totally understandable that you may not get the necessary amount of battery recharge afforded by the personal parts of our lives.
On top of the hours worked, you may be indirectly pressured by the styles of work and schedules of your team members or directly influenced by the demands of those above you on the business totem pole. Without our own courage and support from others around us, we get frustrated and eventually burned out.
As a software engineer, you may have the luxury of working from home for a majority of your time. But that may actually increase the problem of burnout for two reasons depending on your work style. First, if you’re unable to separate your work life from your home life, there will be fireworks (not the good kind) between you and your family. Second, traveling to an office helps you get into a scheduled routine in which you know the time boxed boundaries of your work. This helps you stay mentally sound since you know you’re free outside that box.
Aren’t we supposed to be debunking this myth? Well, sure, but keep in mind that sometimes there is a bit of truth and nuance to myths.
Ultimately, the probability of burnout is highly variable between individuals, businesses, industries, communities, and cultures. It’s true that there are many stories out there about abusive practices by software companies, and we don’t want to minimize the hurt caused by those players. But that doesn’t mean burnout culture is an epidemic.
Investigate Your Interests
First, sign up for and use sites like Glassdoor to check reviews and news about places that you want join so that you’re aware of any red flags. Keep in mind that like many other review sites (Yelp, Google), people are more likely to share their negative experiences than positive outcomes. It’s more emotionally satisfying to many people to say “This place sucks” rather than “I had a great time.”
Join community groups using sites like Meetup.com to find some like-minded developers and teams. By easing yourself into an established community (or even one that you start yourself), you’ll be able to find out who is genuine and who is fake. This allows you with time to assess the opinions of people who work in local companies. Such an approach is similar to researching via Glassdoor but on a much more personal level.
Keep yourself open to interviews for any type of technology company that needs your skills. Even if you don’t want to work at a company, you can get some good practice by at least going through the interviewing process and will get a chance to network with some employees. During the interview, you’ll get a broad idea of the work/life balance, company culture, how current employees feel about working there, and you might even get a tour of the building. You can tell a lot about potential burnout at a company just by seeing how the desks are arranged.
Have Some Self Confidence
The previous advice works if you aren’t yet employed somewhere and are on the job hunt. You can avoid a lot of hurt by following those patterns.
But what if you’re already working at a job that you like but feel like you’re going down a path to burnout? This is going to sound cliché, but a huge help to your own well-being is to find a source for self-confidence in your abilities and decision-making skills. Understand that as a successful software engineer, you’re probably a technical savvy person, have above average intelligence, and have the ability to forge your own destiny.
It’s common for developers to feel pressured into crunch time Herculean efforts that even the most efficient among us would couldn’t finish. It’s understandable. Engineers are problem solvers, not deflectors and excuse makers. When confronted with an issue, we want to do nothing more than figure out the root of the problem, solve it, and be rewarded for the hard work required to release that solution.
Here’s the problem though. Engineers are only human. That might come as a surprise, but it’s obviously true, so give yourself some slack.
That doesn’t mean you should just kick back, put your feet up on your desk, and ignore all the requests coming in from people at your job. But you should keep yourself and your team honest by realizing that constant fire fighting isn’t sustainable. Push back when you’re feeling overwhelmed. Let people know that you aren’t comfortable working outside normal business hours. Note that you may have contractual obligations depending on the hiring stipulations, so be cautious here.
At the end of the day, it’s important to remember that the software industry is massive and growing every day. No two companies are alike. There are thousands and thousands of businesses out there that have great work-life balance and absolutely respect 40 hour work weeks. It’s just a matter of taking control, setting up the necessary precautions to avoid the bad players, and actively seek out the good ones.
Myth #2: All Software Engineers Are Being Outsourced
There’s no doubt about it: the world is connected more now than ever. We live in a global economy. This is especially true in predominantly digital industries and software communities. One of the inevitable facts of life in an industry that allows for remote and flexible work is that it’s possible to find workers in cheaper parts of the world. That said, there are still opportunities to find a position or a business that requires local developers.
Common Outsourcing Scenarios
- Quality assurance automation by creating automated unit tests, integration tests, user interface tests, user experience tests, deploy tests, and really any other type of automated testing
- Mass updating minor versions of libraries and dependencies across hosts of microservices
- Mass updating log configuration files across hosts of applications and services
- Taking a pattern or template that was established in house and applying that to a standard, regular application design
Notice anything common across those examples? They consist of boring, mundane tasks that don’t require a lot of expertise to accomplish. These are tasks that we find most in house developers and engineers want nothing to do with. Instead of spending their previous (and expensive) time on test automation and configuration updates, many companies instead opt to outsource that work to a trusted company at far less expense.
You should also notice, however, that outsourcing in these scenarios doesn’t exclude you as an in house developer. Developers that are available during local business times are able to answer questions in real time, provide feedback immediately, and are able to join meetings with other business divisions.
We’ve found that the most successful teams tend to combine the talents of local developers with the talents of outsourced developers to make a winning team. Basically, it’s not a zero-sum game. It’s possible to have local talent and outsourced talent on the same team (and in some cases even preferable).
Put Yourself Into a Hard to Outsource Position
So we’ve established that most technology companies want at least some sort of local talent for various reasons.
Something else to consider is that there are more job titles out there beyond “Junior Developer.” It’s much easier for engineers that have just entered the workforce or company to have their positions replaced by offshore developers. This isn’t a hard and fast rule, of course, but is a generally accurate representation.
What’s that mean for you, though? If you’re a junior developer, you might just be out of luck until you get more experience. But that doesn’t have to be universally true. Instead, if you can show your coworkers, boss, and other stakeholders that you know what you’re doing, care about the products that you support, and are willing to take ownership, you’re putting yourself into a position that makes you desirable and, in some cases, irreplaceable.
We aren’t suggesting that you become a single point of failure where your removal will result in the complete demise of the company. You should, however, take initiative and work yourself into a highly respected role within your domain. That could mean becoming a subject matter expert, a high-value communicator, a well-organized super contributor, or take a path toward leadership and management.
This definitely isn’t a quick path. It requires a lot of dedication on your part, understanding on the part of your employer, and potentially a lot of time.
Find an Industry That Needs Local Talent
Maybe you were a leader of your business and still found yourself replaced by outsourced teams. Sometimes it happens. The business may have been making budget cuts, the new leadership may not understand the value of local talent, you may not have been fully trusted by someone for reasons unknown to you, or maybe your project’s contract just ended. Regardless, you’re still not out of luck!
Whether you are a new hire or a seasoned veteran looking for a new position, there are companies out there that belong to industries that almost always hiring local talent first.
For example, the defense industry constantly opens positions which require security clearances. We aren’t sure if you can get a security clearance as a foreigner, so it’s highly likely these positions are exclusively available to citizens.
Here’s a list of some industries that fall into this bucket:
- Defense: sometimes requires security clearances and background checks that only local citizens can obtain
- Healthcare: highly confidential data compliance issues around HIPAA usually excludes outsourcing certain positions
- Hospitality/Tourism: some businesses in this industry require local developers to be on site to understand the user experience as customers engage in hotels, theme parks, and shops
- Various small businesses: usually they don’t have the budget to manage an entire outsourcing wing and only has a demand for a small local team
Myth #3: I Don’t Think I’m Smart Enough
We won’t sugar coat it. Programming can be challenging. That’s good for people who like a challenge but bad for people who feel that they don’t have what it takes.
Have you ever seen a job listing that looks like this?
Must have 15 years experience with tool that has only existed for 5 years
Must have experience with Python, C#, C++, Java, Rust, and 15 other languages
Must have experience with Windows, Linux, Mac, NetBSD, and 5 other operating systems
Must have PhD in computer science— Some clueless employer
OK, we’ll admit it’s a bit of an exaggeration. Just a bit though. The point to take away is that companies make up these types of job listings in an attempt to cast a wide net. They’re hoping that someone who knows any of the hundred listed languages will apply. Don’t get scared off by listings that look like only Superman would fit them. It’s good to use these types of job listings as a data point to determine the trend of what companies in your area are looking for, but you shouldn’t treat them as if they’re the arbiter of job requirements.
If you’re still feeling out of the loop, the good news for you is that there is an endless supply of information available to you. On this blog alone, we’ve written an ultimate guide to software engineering, what to do if you want to be an engineer but only have an IT degree, and how to meet software career success without a college degree. That’s just this blog! Imagine what else is out there on the Internet and at your local libraries.
We’ll save you the trouble of searching. Check these out and let us know how they help you overcome your intelligence anxieties.
- KhanAcademy for absolute beginners
- Coursera for structured high level online university courses
- Pluralsight for online flexible deep dives
- Ways to overcome bad programming habits
- Discussion of things every software student should know
- Ways to stays organized as a software developer
- Essential knowledge for every programmer
Imposter syndrome can take hold strongly, but you can break through it by finding your source of confidence, confiding in your coworkers and family for a support, and incrementally improving your skills through your personal project portfolio.
Tons of Opportunities
Programming, software development, and software engineering are vast, broad topics with plenty of wiggle room for people all over the knowledge spectrum. Technology companies have many more job titles and career niches that you might fit into as well.
Want to use your algorithms and performance improvement knowledge for more operation and infrastructure solutions? Try a Site Reliability Engineer (SRE) role.
Maybe you don’t like the standard Software Development Lifecycle (SDLC) process and would rather be strictly in operations and delivery automation. Then a DevOps role is probably the right fit for you.
Many positions in the software engineering spectrum are respectable, well paid, and take advantage of programming abilities. Most of the same tools apply to these roles as well, so you don’t need to spend precious time relearning everything if you want to shift positions.
Not Everyone Is a Rockstar, and That’s OK
This might sound harsh, but it’s perfectly normal for you to not be the top of the class. In fact, the majority of people in courses or in a job are considered average. That’s how the average of a data set works!
We’re saying this to you because we want you to understand that not every developer and engineer is going to be company’s super star, and that’s perfectly OK.
Maybe you’re right about yourself. Maybe you don’t have the smarts to reach whatever mythical pillar you’ve placed in front of yourself. Our guess is that you’ve placed some imaginary goal so high up that you’ll never attain it. Or you’re comparing yourself to someone that has a completely different set of skills and backgrounds than you. Setting unrealistic goals and comparing yourself to completely different people are unfair rules to yourself causing undue stress on your career aspirations.
We aren’t suggesting that you should settle at being mediocre. Everyone wants to be better than they are. But you should at least go in to any new role with a realistic mindset and the knowledge that it’s acceptable to be average.
All that said, try to realize that you probably are capable even if you don’t believe it. Programming is a huge, broad topic that has varying levels of difficulty. You can most certainly find somewhere that you fit. Remember that it’s acceptable to not know something. Ask questions regularly. Stay determined.
Myth #4: All Software Engineers Have Computer Science Degrees
This one is particularly frustrating because it’s a pervasive myth. People get confused by thinking that computer science is the be-all and end-all requirement to becoming a software engineer.
There are many STEM degree programs in the world, and most of them little to do with computer science. Yet holders of those degrees go on to become successful software engineers every year. For example, having an Information Technology (IT) degree makes you a good candidate to be a software developer, but many people think you are only cut out to be a system administrator.
Software Engineering Is a New Profession
Where did this misconception come from? Software engineering is still a young profession. Consider that some engineering professions (industrial, for example) stretch back centuries. That’s a lot of time to mature the processes therein. Bridges are built in very specific, standard ways. Buildings use standard materials and foundations. Sure, new designs, materials, and regulations are coming out all the time. But these are adapted into the existing processes gradually.
On the other hand, software engineering started only started recently in full after World War II and “modern” approaches date back only a couple of decades. While it was originally a requirement to understand the exact binary sequences that made up your code, the profession has progressed to a point where it’s no longer required to understand the extremely fine details of computers and computer science.
Being a Super Genius Isn’t Necessary
Yes, having that knowledge is helpful and will give you an advantage in the profession. But that doesn’t mean it’s a strict requirement to be successful. Do you think that every developer to have created a web page or a mobile application understands how to create or use a red-black tree? No, because it isn’t necessary.
We should note here that your specialized interest will ultimately determine what type of academic background you need. Computer security and encryption will likely require advanced math and algorithms designs whereas basic web application development would only require knowledge of the fundamentals of computers, software, and programming.
Science, technology, engineering, and math (STEM) degrees can certainly help in your journey. We would liken this to starting a few rungs up on the ladder to success. You’ll have already covered many of the basics behind computer fundamentals, math, and topics beyond STEM that round you out as a person, but these aren’t hard requirements to being successful as a programmer. The Internet and good old-fashioned physical books have an absolute ton of easily accessible information of which you can take advantage any time. Thorough discipline, scheduling, and constant practice will take you a long way.
Myth #5: One Programming Language Is the Best and All Others Are Useless
We find this myth to be most commonly repeated by inexperienced developers, people with an agenda to push, or just those that like to stir up trouble online.
Let’s get something out of the way right from the start. “Best” is hardly a useful word to describe something. It implies that something can be objectively better than everything else in its relative category. We find that to be impossible to quantitatively measure in most scenarios as shades of gray are more common. In software and programming, it’s even less true.
Sure, you can get obnoxiously granular with your categories and maybe define the best. For example, what is the best programming language created by Microsoft but for people who don’t like VisualBasic? Hmm, I guess the best would be C#. OK, we’re being facetious, but you get the point.
Realistically, the best language is one that you determine through a series of questions:
What is your team familiar with or already using? If your team is already using C# + SQL + JSON, then you would probably not get a lot of luck by writing Rust + Mongo + YAML. It’s just not realistic to expect your team to shift to whatever language you read about on HackerNews that week.
What are your company or team standards? Sometimes a company, through their endless wisdom or restrictive legal teams, will dictate a specific language to use. One of our authors was employed at a business that required everything to use a proprietary rules engine language exclusively without any question about it. If you find yourself in that unfortunate situation, then that quickly becomes the best language to use.
What type of developer are you? Embedded? Mobile? Web? Game? Desktop? The answer to these questions can potentially limit your choices. Embedded developers are going to stick with a super popular low level language like C. On the other hand, game developers that don’t want to struggle with lower level issues and instead want to focus on building a game might use an entire engine like Unity + C#.
Have we made our point yet? Try not to focus on the raging language wars that you see on Reddit and instead focus more on what you know, what your team knows, and your specific project requirements. You’ll be able to cut out a lot of noise and make a more accurate and less painful decision.
Myth #6: There Are No Software Jobs in My Area
These days, computers, mobile phones, laptops, and electronics are so prevalent in our daily lives. Rarely will we hear from people that they have literally zero ways of obtaining a software job in their area. However, the world is a vast and sometimes a geographically barren place. Some countries have thousands of miles of grass and desert with barely any sign of civilization. Yet people live in these remote areas.
What if these people want to be software engineers? Are there even opportunities in these areas for blossoming programmers? What if the nearest big city is hours away? Your first thought might be that they’re completely out of luck. But that’s not the case! Software development is a remote-friendly profession with the flexibility to work across city, county, state, country, and time zone lines.
At the very least, software engineers need electricity and a computer. Both of these are readily available regardless of where you live in most first world countries. Electricity is widespread and laptops can be delivered nearly anywhere by Amazon or various postal services. And let’s be honest, if you don’t have electricity, it’s because you are actively seeking to avoid it, or you live in a place that is generally depressed with bigger problems.
With the equipment problem solved, next you would need Internet if you’re expecting to download software, receive automatic updates, contribute to open source, or collaborate with other teams. This can be tricky for the truly “out there” locations. Phone lines are ubiquitous, so you’ll be covered by dial-up at the very least. But for most jobs, that’s just not going to cut it. And while there are government initiatives to install broadband in all areas, some people are still left with the worst of all worlds.
If working from home isn’t an option because you don’t work well in isolation, you can’t separate your work life from your home life, or you don’t have acceptable Internet services, you could look into cities near you that offer coworking spaces for rent. One downside is that you’ll have to potentially deal with employees at other businesses (it is a shared space, after all).
After all that, if you still don’t have what you need to be a valuable contributor to software, you either have a lot of daily travel in your future or will need to find somewhere closer to a larger city to which you can relocate.
As you can see, you have a lot of options to explore in your arsenal (work from home, remote work, coworking spaces) before having to go for the nuclear option (moving).