10 hard-to-swallow truths they won't tell you about software engineer job

Last weekend I had a chance to talk with some students who just got their degree. They are pursuing their first software engineer job. In conversation with them, I learned that they have a pretty wrong perception of this job.

This is because the reality for these new kids is so skewed. They only see good pay, remote work, team building, and pizza parties.

These are all good perks, but no one is talking to them about the real things that we do in this job.

As someone who spent a lot of years in this industry, I gave them a slap of reality in the face. I told them good things but also some hard-to-swallow truths.

After reading this article, some people will say I am talking overly negatively about it. but my opinion is that these things go together with the job and you have to accept it.

1) College will not prepare you for the job

This is the first thing I explained to these guys.

To precisely describe how college will prepare you for the job imagine that you are learning how to swim.

Your instructor spends a huge amount of time to describe you all the moves you need to make. He makes you recite all those moves, asks you questions about it and you have exams about it. But you never touch the water.

After 5 years, you get a piece of paper that proves your swimming skills. Then the day comes, and you have to swim now. The guys in the swimming place just kick you into the water.

You have a hard time breathing, you fight for your life. Maybe you will drown, maybe you will manage to swim.

That's what the first 6 months look like for a freshly graduated student in a software engineer job.

The college will prepare you for some basics, but what most of the colleges teach is so far away from day-to-day jobs. Most of the professors who teach at universities are not good software engineers.

Only a small percentage of them even worked as software engineers. Also, the university curriculums are heavily outdated. They trot years behind the software development market needs.

You have to put in extra work while you are in college. Code more projects besides homework and seminars. Do some volunteering. Learn about business domains to prepare for the job that awaits you.

Most of the students don't do that. They wait until they get their diploma to start working on their portfolio.

2) You will rarely get greenfield projects

In college or boot camps, you get a lot of smaller assignments that you write from scratch. Total freedom to express yourself. You can implement all the fancy stuff you learn, like algorithms or design patterns.

The time you spend on those assignments is at most a few weeks, but mostly a couple of days of work. Typically those assignments contain at most 500 lines of code.

In day to day job you are working with projects that contain multiple layers and thousands of lines of code. Multiple people work at the same time on those projects. You have limited freedom, you have to adapt to the project. The time you spend on projects is usually half a year to a couple of years.

Sometimes you spend a whole week fixing the nasty bug. The fix is just a couple of lines of code. You talk with your colleagues. You exchange information about the project. You collaborate with them to get approval for your solution.

New projects are rare, and most of the time you work on existing projects. You can consider yourself lucky if you get the normal project and not some old legacy project.

3) Nobody gives a f*** about your clean code

You can forget that your boss will tell you: "Congratulations on writing this elegant and clean code, I am gonna give you a raise!". Quite the opposite, nobody cares about your clean code.

Don't get me wrong, people will expect you to write good and clean code. Still, you will rarely get any praise for it. Except sometimes from your colleagues who will review your code.

This may be a shock for some new folks, but it makes perfect sense. As a software engineer, your primary task is to generate value for users. Writing code is just a step that accomplishes that goal.

You can think of it as the following cycle:

• software engineer writes code
• users get new features
• more users use your products
• company profits from products

So code is just a tool to get profit.

I have seen so many graveyards of projects, with horrible legacy codebases. Still, these projects are successful as they have fancy landing pages and solve user's problems. So users are happy to pay for using them.

The user doesn't know how the codebase looks. The user just sees what features that product is offering. So don't get overly attached to your clean and elegant code. Focus on shipping the feature on time and bug-free.

4) You will sometimes work with incompetent people

People have prejudices that only smart and competent people work in the IT industry. Especially the software development branch. But this is far from the truth.

As in every job, you will sometimes have incompetent people in your environment. Working with them is very frustrating. They waste so much time and create a toxic environment. On top of that, they are extremely unproductive. All this reflects on deadlines and produces delays. This costs companies money and resources.

Unfortunately, I also had experience working with those kinds of people. I have to say, they tested my nerves so well that I spent a good amount of time thinking of ways to get around their incompetence.

Here are some advice:

• try to be efficient and productive as much as you can, focus on yourself and not on them
• try other options/solutions that don't involve that person in the process
• document everything you do. If things go wrong, you will have proof of their incompetence
• if you have a blocker because that person didn't do their job, try to ask someone else to unblock you (if it's possible)
• talk directly to them, be professional but not mean, and tell them what and how they can improve

Remember that there is no need to be a jerk to them.

Sometimes you don't know the whole story. I have seen some cases where a person just can't do their job properly. They are burdened with tons of tasks and doing work for 2 people.

5) Get used to being in meetings for hours

Meetings are an important part of the software development job. Some of them are good, but some of them are just time wasters.

There are recurring meetings scheduled on a daily or weekly basis. Most of these are not productive. The majority of them are forced by a person who is organizing them because that's the only "work" that that person is doing.

It's just an empty protocol to prove their purpose of existence in the company.

On the other hand, there are productive meetings. Those meetings ensure information exchange between team members or different teams.

The majority of software engineers hate meetings. But remember that your job is also to communicate about things openly and proactively.

Sharing information is crucial for projects to move forward. When you share information it can help other teams to better understand what you are doing and the opposite.

6) They will ask you for estimates a lot of times

Business revolves around numbers. Every project has its cost, and to calculate the cost, management needs to estimate how long it will take to build a certain feature.

Then, it goes down to software engineers to estimate their work. Usually, estimates are time-based, but sometimes they also ask for complexity estimates.

In a lot of situations, you will have no clue how long it will take to build something. You read requirements, do some research and you give a number.

Later, when you start to work on that feature, you encounter many problems that you weren't aware of when you gave time estimates. Then you need to compensate for the wasted and hope not to break the deadline.

That's why it's always good to underpromise but overdeliver.

For example, when your project manager asks you to implement feature X by Friday, you won't say "Oh, I can finish it by Tuesday". Instead, you will say: "Sure, no problem".

Why?

Because if you promise to deliver it by Tuesday and you run into some problems, you won't be able to fulfill the promise. Instead, if you accept Friday as a deadline, and you finish it by Wednesday, you can deliver it 2 days earlier.

There are a lot of formulas on how to do estimates, and everyone has their own rules. I also have my own rules.

If I need to deliver some feature, and I think it will take 2 days, I add roughly 40% more time to it, just to be safe. So, in this case, the estimate will be 3 days. Later, if I am done in 2 days, I can just deliver it earlier.

7) Bugs will be your arch-enemy for life

The more you code, the more you are aware that bugs in the code are everywhere. When you are just starting with programming, you think you will code something, it will work fine and it's the end of the story.

But in reality, it's a different story. There are countless things that can produce bugs:

• your own code - humans make mistakes, and you should not trust that code is working perfectly. You can write tests, but bugs can occur after that due to various reasons that you aren't even aware of.
• 3rd party libraries - those libraries are also written by software engineers like you and me. Always watch for activity and how frequently those libraries are updated.
• hardware failure - software relies on hardware. Mark Hanna explained what your software is without hardware in his quote: "It's fugayzi, fugazi. It's a whazy. It's a woozie. It's fairy dust. It doesn't exist. It's never landed. It is no matter. It's not on the elemental chart. It's not f***ing real."

• electricity - yep, hardware needs electric power to run, without it, it's useless. I worked on one project with Raspberry Pi. The client had constant problems with the device turning off at random times. After days of investigation, we finally found out the issue. He used a different power supply than the original one provided. Because of that device was turning off at random times.

So the truth is you should assume that everything has bugs. That's why experienced devs never trust their code if it runs successfully on the first try. Even if the QA engineer reports a bug, assume that the bug ticket has a "bug" and check for everything.

8) Uncertainty will be your toxic friend

In this job, you will feel uncertainty almost all the time.

I already explained the estimates example above. That's just one example where you feel uncertainty. You give your best shot but you are not 100% sure you can finish the work in that estimate.

Besides that, there are countless other things that are uncertain. Here are some examples:

• implementing something in your project you never worked with, eg. 3rd party API - how are you going to implement something you aren't familiar with
• transfer to a new project, with new technologies - you will think about how you are going to be efficient and productive with something you need to learn
• move to a new company - you are unsure how you are going to settle in and vibe with new people
• bug report on the day you need to finish the work - you fear that you are gonna break the deadline
• job security - economic situations, pandemics, wars, and other factors heavily affect this industry which results in layoffs
• the evolution of technology - you are never sure if tomorrow you are gonna be replaced by some new technologies like AI

The good thing about uncertainty is that drives you to be a better software engineer. It demands improvements and learning if you want to stay in the game.

9) It will be almost impossible to disconnect from your job

From time to time, I catch myself thinking about my job, problems, and bugs. Or things I have to do tomorrow when I should relax and chill.

Sometimes, cold water in the shower wakes me up from my thinking about how I am gonna fix the nasty bug I worked on yesterday. I had countless squabbles with my girlfriend about why I am on Slack when we are on the beach.

So I publicly admit, that I have a hard time disconnecting from work.

It's especially hard to disconnect when you are working from home. If your laptop is on, you can always check emails or Slack messages.

So to avoid all this:

• I turn off my laptop after I am done with the work,
• I put quiet hours on my mobile phone for my business emails
• I pause Slack notifications after working hours. I disable them on weekends.
• When my mind gets into this "think about work" loop, I try to immediately cut it out. I remind myself that rest and relaxation are important to be productive.
• I take long walks after work. On some days I do sports like padel or football.
• I try to engage socially as much as I can, avoiding screen time after work.

Still, with all these steps I do every day, I fail a lot of times.

10) You will profit more from good soft skills than from good technical skills

Technical skills are the ones you can learn easily. With different projects, you can understand a particular programming language. You can learn its syntax, pros and cons. It's just a matter of practice.

On the other hand, soft skills are much harder to improve. Improvement takes a lot of mental strength. You must do things you are not comfortable with.

You have to put yourself in situations where you can improve or practice particular soft skills.

For example, communication is one soft skill that people always talk about. Let's say you suck at public speaking. You have to force yourself into situations where you can practice some public speaking.

It's very hard to intentionally put yourself into situations where you know you will suck at. Your mind will do everything to avoid those situations. It will bring hundreds of excuses and it's easy to give up.

Besides communication, there are other soft skills:

• teamwork
• learning mindset
• organization/time management
• emotional intelligence/empathy
• approachability
• persistence/patience
• confidence

I have met a lot of folks who are good with technical skills but awful to work with.

For example, one colleague would ask me for help a lot of times. I helped him a couple of times. Then, I noticed after we fixed his problems, he would come back to me and blame me for messing up other things on the project. Then I had to spend more time with him fixing stuff I wasn't even aware of. And because he was blaming me with such a bad tone, I stopped helping him. I would say that I have a lot on my plate to do, so I can help him tomorrow.

Another example, I was the new guy on the project. A colleague (let's call him George) was assigned to help me with anything I needed. I set up the project pretty much by myself, but there was one error I was getting when I tried to run the project. I asked George for help. He spent maybe 2 minutes with me in total to solve a problem and said that he didn't know the solution. I thanked him anyway, tried to solve the error on my own but finally succeded with the help of colleague Michael. On daily standup, George said that he spent his whole day supporting me. I never asked George for help, after that.

One more example, there was one colleague who was the main man on the project. Still, the whole team hated him (other devs, project managers, QA, designers, etc). He was a good software engineer, but a real jerk. Extremely rude in communication with everyone. He never wanted to admit he was wrong or accept constructive criticism of his code. Management tolerated him as he was always the loudest one in the room. When he finally resigned, the whole team was celebrating.

With good soft skills, people will like you more and you have a better chance of getting a raise or promotion. If you are technically gifted but hard to work with, your chances are slightly reduced.

Also, with good soft skills, people who know you will spread a good word behind your back. They can recommend you for the job, without even you knowing about it.

Conclusion

Software development is not a dream job.

Working in software engineering often means long working hours. Most of the time, you are glued to a computer screen, with little work-life balance.

The job demands an online presence, sometimes even after work hours. This often leads to stress and limited personal time.

Additionally, job satisfaction is frequently hindered by tedious tasks. Depending on the situation you have limited career growth prospects. There is also potential isolation in remote work. And there is always a threat of job insecurity due to rapidly evolving technology.

But, there is also positive stuff.

Software development nurtures continuous innovation. Software engineers can create attractive applications and solve interesting problems.

The global demand for software solutions across diverse industries is big. This means there is always a demand for good software engineers. Software development careers provide flexibility with remote work options.

It's one big blessing to work from any location. Flexibility allows you to sleep in the morning without an alarm. You can work from your home in comfy pajamas. Also, you don't waste your precious time and money on commuting.