The 10 Hard Truths About Being A Software Engineer

They’re lying to you. These Universities, bootcamps, and institutions are not telling you the whole truth.

Maybe lying is a harsh word, but the reality is that there’s tons of confusion and uncertainty around the Software Engineering space. And worse? Not many people seem to want to clarify it.

This is why today, I want to tell you 10 hard raw truths about being a Software Engineer.

• No sugarcoating ❌
• No romanticizing ❌
• Just the raw truth ✅

Ok, let’s get into them.

Don’t feel like reading? Watch the video!

Watch the video version of this article that I posted on the ZTM Youtube Channel.

#1. Software Engineering is not a dream job

Working as a Software Engineer is work. And quite frankly, it can be very hard work.

At the end of the day, this role is just like any other job. It’s a means for you to pay your bills, afford to live, and have some kind of purpose, and sometimes we forget that.

We forget that this career choice occasionally has a hard work-life balance. That it can be a stressful environment. Heck, we forget that most of the time, we might not even be working on something we actually love.

We even forget that sometimes it's tedious tasks, regular meetings, and a constant fear of being inadequate.

All of this being said, I still would never quit programming - I simply enjoy it too much (and yes, the pay is good).

I just think it’s important to understand that it's not a dream job, no matter what anybody tries to tell you.

Not every company has yoga classes, free jiu-jitsu, and fireside chats. And even if they do, you’re usually busy while this stuff is happening.

#2. Most people don’t want innovation in this industry

Now this one can be a hard pill to swallow, but the fact of the matter is that most of the time, companies are looking for cheap, quick wins.

This means that most companies in this industry want to stick to tried and true methods, where they can increase profit margins and decrease their running costs, all while doing this in an expected method.

The keyword here is ‘expected’. Unfortunately, innovation and unexpected results go hand in hand, which is why companies steer clear of it for the most part.

Now, this doesn't mean that you should just lose hope and not even try to be innovative. All I'm saying is that if you have a great idea, expect mostly negative feedback and brace yourself for an uphill battle.

It can be accepted but it might take time and effort to make it happen.

#3. Incompetence in Software Engineering is no joke

In this industry you will deal with people who simply don't know what they're doing, to put it nicely.

This isn't always someone on your team. It can be a manager at a partner company, or some C-level executive on the client side who hinders the process as a whole, which is frustrating and tedious to work around.

Quite frankly, learning to deal with incompetence is a skill, all on its own.

Obviously, you never want to be rude or distasteful, so the best way to navigate a situation like this is to be proactive. Seeking out additional resources, delegating tasks to more efficient workers, or even just having an honest conversation with these people can all help you get past this.

Just remember to keep it civil.

#4. You will work with uncertainty most of the time

You see, people nowadays don't really know what they want. And even when they do, they typically forget to ask the most important questions, like:

• Is this possible?
• Is this practical?
• Etc

And it’s not just people either that make things uncertain in this job. Sometimes you’re questioning a new technology that you're using or a 3rd party provider that is new to the project.

Also? Personally, I think there's a big misconception in this industry regarding processes, and what I mean by that, is that it's not as smooth as you think.

Your product manager doesn't just give you perfect instructions and guidelines when handing you a task. It’s never as simple as grabbing the instructions, coding it, and that's it, and everyone's happy.

Editor’s note: I feel this is a huge part of why AI won’t take our jobs either. Because until people can learn to effectively ask for what they want, AI won't be able to deliver.

Anyways, back to Aldo…

Most of the time you will spend weeks gathering the requirements and figuring out what needs to be done.

Sometimes you will even be talking to Developers on the 3rd party side, attempting to see if this project is even feasible. Only to then have to go back to the stakeholders and tell them that their idea is not going to work, or at least not exactly how they want it to.

And that’s when you present the other ways that it may be possible, and look awesome for having alternative solutions (learning to be agile and adapt like this though makes you an incredibly valuable employee).

#5. You don’t know as much as you might think, so never stop learning

This was by far the hardest truth that I had to face.

I don’t know if I was just being young and naive, but I had this assumption that I would reach a point where I would know it all, and be able to take my foot off the gas pedal, but that's so far from the truth.

There are so many different libraries, frameworks, packages, and languages out there that it’s literally impossible to know it all.

So instead, learn to embrace the fact that you won’t know everything.

There will always be something new to learn and to be honest, that's probably part of the reason you fell in love with the idea of being a programmer anyway right? If you’re anything like me, then you’re a lifelong learner.

And hey. Everything you learn compounds on the last thing, so it’s not like you’re learning from scratch each time.

#6. Writing documentation is not prioritized as much as it should be

I don’t know if this is just me, but when I see code that is well organized, maintained, and documented then I get this warm feeling inside.

Call it happiness, hope, or whatever you like. But unfortunately, more often than not, you’ll be dealing with code where the first thing that pops into your head when reading it is simply, “What were these Developers thinking!?”

What makes it even more difficult, is that this to me, is one of those skills that you really can’t teach.

Don’t get me wrong. You can learn good principles and aim to write dry code, but without some personal experience and disciplined practice, you’re going to get into bad habits, and it will bite you in the ass.

Don’t believe me?

Wait until you have to deal with legacy code that makes no damn sense, you’ll immediately start to see why having great documentation and writing easy-to-understand code, will pay dividends in the long haul.

#7. You’ll rarely ever write something from scratch

When you’re at a University or a bootcamp, you’re building these projects that are 200-400 lines of code, where you’re the main contributor, and you work on the majority of the project from start to finish.

This simply isn’t how it works in the real world. Most of the time, you’ll be working on a codebase with hundreds of thousands of lines of code, where you’ll get stuck wondering “What on earth were your colleagues smoking when they wrote this code?”

You also might be thinking that the feature that you’re adding onto the project will be big, flashy, and cool to work on, but it won't be.

Instead, most of the time you’ll be doing patch work on a bug, where you write 10 lines of code or so, and then sit and wait for the next fire to be put out.

#8. Great Software Engineers think just like Designers

One of the things that I love about Designers is the focus that they have on the user.

Every decision they make when they're working on a project has to please the user of that project.

It’s not exactly the same as being a Software Engineer, but if you really want to go above and beyond, and become a great Software Engineer, then you have to develop this user-first mindset.

It doesn't matter if it's an external API or a user interface, always ask yourself:

• Who will be using it?
• How will it be used?
• Why will it be used?
• And why is it important to the user?

When you ask yourself these questions, you can’t help but keep your user in mind and provide a better user experience.

#9. Technical debt is real

For those that don’t know, technical debt refers to when a company does not fix a problem properly, and so it will come to bite them in the ass sometime in the future.

This is typically done for saving time. Maybe there’s a deadline coming up, or they simply don't want to handle it at that moment.

Why is this important?

Because as a Developer, you can bet your ass that this will come back to haunt you. Instead of putting out new features, you’ll be putting out fires caused by this issue that was ignored, possibly due to something that happened before you even started working there!

Even worse, technical debt can have a chain reaction of issues, causing months or even years of work for the entire team to fix!

#10. Not all meetings are needed (but not all meetings are bad!)

As a Software Engineer, you’ll be attending so many meetings. Sometimes you get lucky with just one stand-up per day, other times you might have back-to-back meetings throughout the entire day!

And although you would rather be writing code and actually using those skills that you spent years learning, I’m sorry to say but most of the time, those meetings actually are necessary.

Meetings keep the entire team aligned and ensure that everyone is focused on exactly what they should be focused on. And although you may not think so, it’s important that you have an understanding of how other departments are moving, and simply what is going on with them in general.

• Has the quality assurance team had any major complaints or issues?
• Is the marketing team caught up on timeline updates?
• Are all stakeholders involved happy with the way the feature is progressing?

It’s all interconnected, and meetings are an important part of how information is shared, so you need to have them.

Why I still think you should become a Software Engineer

As you can see, there is more to this career than meets the eye, but I’m hoping that this article has helped shed some light on certain things that are just not spoken about enough.

Let's face the facts here. No job is perfect, and neither is every industry.

All work has its pros and cons, whatever you decide to choose as your career. Software Engineering can be hard work but it sure beats waiting tables or being stuck in a factory for 14 hours a day. It’s just not as glamorous and easy as most people make it out to be.

This article isn’t designed to make you second guess your decision to become a Software Engineer. I love it myself and always want to work in the industry.

Instead, I want you to go into this new career with your eyes open so that you have the perseverance to get it done, so you can thrive here.

And like I say. The money is extremely nice.

Want to start your journey to becoming a software engineer / programmer / developer?

Check out this free guide to learn to code and get hired in 5 months for free or the free crash courses on our Youtube channel.

P.S. These hard truths are based on my own personal experiences and my conversations with other developers and software engineers including those in the ZTM Community but I was inspired by these 2 great articles:

1. Things they didn’t teach you about Software Engineering
2. 20 Things I’ve Learned in my 20 Years as a Software Engineer

These are great posts by people who have been in the industry longer than I have. It's always important to go and read different perspectives as well, so definitely go give these a read 🤓.