4 Things They Don't Tell You When You Start Your Career As A Software Engineer

When I became a Software Engineer, I was always told about this greenfield project by recruiters I would get to work on, I seemed to have a lot of language specific tests in interviews, Maths was a significant part of my degree and the ‘no estimates’ movement was making a lot of noise.

There are 4 things that you learn when you gain experience as a Software Engineer that you either didn’t get told, or fly in the face of your experience when entering the industry.

1. Needing Advance Maths is a Myth

I have worked on some complex projects in complex industries during my tenure. I have worked on trading platforms for some of the world’s leading financial organisations all the way through to advertising search platforms dealing with significant scale across the world and have never used advanced maths.

Sure, you will need to use it at points, I would argue the level is rudimentary.

The logic flow and patterns have always been more complex than the maths at this level in our industry advancements. So much of it is buried under layers of abstraction before most of us ever get to interact with it.

There are exceptions to this rule. I can image working on software for the aeronautical industry, rocket guidance, or scientific research to name a few examples. The number of engineers in these roles is a significant minority.

If you want to have a great career as a Software Engineer, you do not need advanced math.

2. Fundamentals > Language and Framework

Great Software Engineers use the knowledge of the fundamentals to shift to the technology that is best to achieve the task and truly understand what is required to put a new wall up and not paper over the cracks. They are engineers. The rest is syntax.

Our industry moves too fast to risk just sticking to language and frameworks. Learn the fundamentals and your knowledge is timeless.

Early in my career, and even before I go my first role in fact, most of my technical interviews would be extremely language specific.

As a junior, I was interviewing for a voucher codes website. The technical test was a multiple choice quiz on PHP functions. This test was closed. It was under a strict time limit and I couldn’t use the internet. I didn’t get the job (not bitter still I promise). Even after nearly 2 decades in the industry I would fail a test that required me to have an encyclopedic knowledge and I think I have done reasonably well. I would simply Google things I had forgotten. Every developer does this.

Every developer uses ChatGPT, Stack Overflow or Google as a frequent source of help. To deny a tool as crucial as this in your day job when interviewing is counter intuitive.

Requiring Software Engineers to have an encyclopedic knowledge of a language or framework screams ‘you will be working on a factory development line’ where you need to do your one small job over and over again and have no architectural design freedom or leadership potential.

As a Software Engineer, you will get much further if you focus on understanding the core principles and fundamentals over being tied to one language.

3. People Love Estimates

No matter what, you will get asked for estimates. People love estimates. No industry is immune to this.

The trick to giving a good estimate is to take your highest estimate and add 50%. If it beginning to sound a bit silly, you are on the right track.

There is a no estimates movement, and in time in the industry you will hear their voice. Honestly, I understand their desire and arguments. In my experience it has never been the case that a business doesn’t need to estimates.

It goes deeper than just building software as Software Engineers in our teams. You will likely have sales teams planning pitches, marketing scoping campaigns, finance doing projections and forecasting for some key features you build and release. They need time to do this. To do this well they need time and a target time range to aim for. The rest of the business can’t just wait for the tech teams to turn around and say ‘we are done now’. It’s a team effort.

4. Nearly Everyone Works on Legacy Code

When I look for roles as a Software Engineer you would frequently see roles advertised as ‘working on an amazing greenfield project’. This is normally always too good to be true. What they don’t tell you is that you will be spending 6 months learning how the monolithic legacy code base works in order to migrate a few endpoints.

Every business has legacy code. As soon as you have shipped your code, it becomes legacy.

If you are looking for a role where you only work on new stuff, don’t squash bugs, don’t have to deep dive into the legacy monolith every now and then you will spend a lot of your career being disappointed.