This is our story. For some of us, those with 10 or more years of experience
in software, it might sound familiar. For the others, still in the early stages
of their careers, there should be plenty of advice about what’s coming up next
in your short-to-medium-term future.

The early stages
We are not entirely sure how, but it happens. A light sparkles and we just
fall in love with programming, maybe after finishing building that university
project or the other piece of software we built just for our own use. So much to
learn, so much to experiment with. There’s this very short reward cycle in
programming that increases our dopamine levels continuously and makes us
addicted to it. We have been bitten by the programming bug, but don’t worry,
it’s not a disease, it’s just brain
chemistry.
We find our first place to work, and we feel very lucky to have been hired for
the job. We start as incredibly self-motivated, we are ready and willing to
learn everything about everything. We don’t mind picking up any of the tasks at
hand. Ticking them off the to-do list gives us that reward our brain is looking
for. We don’t really mind what projects or technologies we are working on
either, as long as we get to learn and build new things.
At this stage in our career, though, we might just not be asking enough
questions. Usually, we think it’s probably because people are just ashamed to
ask, of admitting that they don’t know something. Depending on the personality
this can definitely be the case, but sometimes, as engineers, we just prefer
wasting hours on a problem and get to a solution ourselves rather than asking
for help. This might go back to the reward system, it’s great for our brains to
manage to fix the issue at hand, there’s no satisfaction in being given the
answer to a particularly hard problem. If you can relate to this, make sure you
do ask questions, there’s plenty of challenges ahead, you want to make sure you
maximise the knowledge you gain from the time you spend on this planet and
asking questions is a great way to do just that.
Absorbing the knowledge of someone that spent years learning from his mistakes
in a fraction of the time is invaluable.
We also tend not to challenge our mentors too much, blindly following their
advice. Don’t get me wrong, this is usually good practice, but we should also
make sure we validate things from time to time, especially when they don’t feel
right. At times mentors do tend to become a little overly pragmatic and might
need a shake up. Take your time to build a showcase for what you think is an
improvement so they can easily evaluate it, if it’s good they will embrace it,
they should be experienced and smart engineers. If it won’t work, or it’s not an
improvement, they will help you understand why, and these are all valuable
lessons.
Another common mistake in our early days is going fast, and I mean, really
fast. We want to demonstrate we are performant, we write tons of code, but
sometimes we are not even sure whether we are actually building the right thing.
This can be a massive waste of your time, so please, slow down, clarify the
requirements again, take a long breath, and work on your tasks with a more
focused plan.
The “fun” game of jumping ships
The first few months or years go by, we reach the point where we seem unable to
step up our game. Our colleagues now look less knowledgeable than they did
before, even our best mentors don’t look that special anymore. We’ve absorbed
all the knowledge we could, so we start looking around in search of a place
where our learning adventure can continue.
We also become a little stricter in our job search, we now want to work in a
place where not only we can keep learning new things we know nothing about, but
where we could also use our favourite technologies to build wonderful things.
During this period we might jump a lot of ships, companies look great on paper,
but once inside it gets boring pretty quickly.
Eventually, with
perseverance, we find a great place to work again, or at least one that suits
our current needs, and we get back to work.
There is no such thing as over-engineering
We’ve evolved over time, and if we are unlucky enough, we have developed an
[OCD](https://en.wikipedia.org/wiki/Obsessiveâcompulsive_disorder) towards
achieving perfection in our code. Refactor after refactor after refactor your
code becomes more and more beautiful to your eyes and more and more obscure to
the other members of the team.
A word of advice: try to write down how long it takes you to write down your
new beautiful DSL, or super-generic uber-abstract future-proofed solution (that
is only currently used in a couple of places in the codebase). And in addition,
double check your “git diff”. Have you really improved your code after that
refactor? It’s usually a good sign if you managed to remove a big chunk of
code from the codebase, otherwise, you can always choose to reconsider and
park it in a branch for the time being.
At this stage in our career, we always want to demonstrate how smart we are to
the rest of the company, or the rest of the world. We need this in order to get
that dopamine shot we need to get through our days at the office. Normal tasks
do get repetitive, so this is our escape route. We start spending a lot of time
innovating on what already works and not enough time writing code that is
actually solving business problems.
Even if we know a way that works well and it’s battle-tested in production, we
still seek for “new” ways or magical improvements. We tend to spend a lot of
time trying to refine what’s already working quite well and is clearly
understood by the engineering team.
One of the best pieces of advice I can give for these situations is the
following: having code that works in production gives you more time to
evaluate new methodologies, cutting-edge frameworks and experimental libraries
during not particularly busy times. The stress that comes from new mysterious
production issues is no fun. Make sure you experiment in less critical parts of
the system or build a few well-tested side projects. This will make production
adoption much easier as you will be able to share what you’ve achieved with your
colleagues, get feedback, and eventually manage to have a smoother transition of
your improvements into production.
Another common pitfall is trying to make everything work 100% of the time.
We consider every possible minor edge case and write tons of complex code to
handle it (which might actually make things worse), making the codebase harder
and harder to maintain. You might think this is the only way, but it isn’t.
Imperfect systems are sometimes fine from a business perspective, just ask the
business for their opinion, they might prefer to use their resources and time to
move on and build the next feature instead, and just send an email to a human to
manually fix the problem if it occurs.
Why do we follow the buzz?
Another thing that happens naturally during our careers is this: we just put
the world on pause and start learning something new. It can be a new language,
a new framework, a new methodology, an entirely new area of development, or
something different. But how do we choose?
Sometimes, something just attracts our attention because it seem to solve one of
the problems we are currently facing. Sometimes we just do it because it feels
like the whole world is moving in that direction. Sometimes it’s only for the
sake of getting a better job.
The tricky part is how to learn how to distinguish temporary noise from actual
industry-changing technologies. The only advice I have on how to approach this
comes down to trying things out yourself, and I mean, really trying them
out.
Spend some relevant time on it, don’t just read blog posts about it, dig deeper,
come up with your own pros and cons list. Does it really solve the problems it
is claiming to solve?
After endless time spent mastering frameworks and libraries, I’ve learnt that
the most important thing is keeping them at the edges of my software systems. If
they turn out to be heavily bugged, abandoned or superseded by new alternatives,
they could be easily replaced.
Learning to cut through the noise will make you a much better engineer. New
technologies come up every day, no one forces you to use them.
A very good step towards maturity in software engineering is to prioritise
having working production code over new buzzwords to put on your CV. It can be
tricky at times, and it does not sound cool saying this in an interview, but it
should be far more valuable to a company to have working and maintainable
software.
Please note: this does not mean we should stop being curious or not spend
time on learning the next big thing. We should just try to balance things out
while learning to keep having fun from the junior members of the team, but
accept that you should get the job done sooner rather than later.
The road to greatness
During the transition into more senior positions, we tend to grow more and
more pragmatic. This tends to make us look a little annoying and less
competent to the junior members of the team or the engineers we are currently
mentoring. We also tend not to code as much as before, some of us think trivial
tasks are beneath us, which amplifies the problem, try instead to lead by
example and close down those trivial or boring tasks yourself.
Having enthusiastic team members can help us remember that we should try to
remain curious and keep learning. We should keep trying things out, our
expertise will help you make a much more informed decision on which tech to pick
up compared to a few years back in your career.
It’s not easy to generalise how a senior software engineer looks like after
decades, though. We tend to evolve in different directions, but we still share
the same potential issues.
We are much more likely to fall into the trap of under-engineering. Our
experience now tells us that early abstractions are not going to work most of
the time. Just remember, if your team doesn’t enjoy working on some parts of the
codebase, it’s a sign that it might have been under-engineered and left behind.
It might need improvements, so prioritise it whenever you have time to address
tech debt.
Another likely danger is becoming a victim of our own cargo cults, the ones
we’ve developed over the years. Make sure you challenge them from time to time.
A note on humility
Years of experience don’t directly translate to better-written code, keep asking
for opinions and code reviews. Sometimes I ask my wife (she’s not a
programmer) to proofread my code to see whether she can understand what it
does.
You’ve probably heard this one before, but your experience should have taught
you one critical thing: you can’t know everything. Anyone can still teach
you something you don’t know anything about.
Don’t give up
We all have highs and lows in our software engineering careers. Some of us start
prioritising money over job satisfaction, ending up in either contracting roles
or highly paid boring jobs. Some might move into management in search of a
bug-free life.
It can be intellectually challenging to have to deal with a continuous stream of
problems, and in software, this is just how things are. It’s impossible not to
experience those days where it’s just too much to take in, and think: “*Why am I
still doing this? *Everything is
broken".
If you feel like you need a change of career, take a break. It usually works
quite well to just disconnect for a few days or even a few weeks. You won’t
believe how much revitalised you will feel when you come back, actually craving
for something to build, or a big mess to sort out.
**This is our story**. For some of us, those with 10 or more years of experience
in software, it might sound familiar. For the others, still in the early stages
of their careers, there should be plenty of advice about what’s coming up next
in your short-to-medium-term future.

### The early stages
We are not entirely sure how, but it happens. A light sparkles and **we just
fall in love with programming**, maybe after finishing building that university
project or the other piece of software we built just for our own use. So much to
learn, so much to experiment with. There’s this very short reward cycle in
programming that increases our dopamine levels continuously and makes us
addicted to it. We have been bitten by the programming bug, but don’t worry,
it’s not a disease, it’s just [brain
chemistry](https://en.wikipedia.org/wiki/Reward_system).
We find our first place to work, and we feel very lucky to have been hired for
the job. We start as incredibly self-motivated, we are ready and willing to
learn everything about everything. We don’t mind picking up any of the tasks at
hand. Ticking them off the to-do list gives us that reward our brain is looking
for. We don’t really mind what projects or technologies we are working on
either, as long as we get to learn and build new things.
At this stage in our career, though, **we might just not be asking enough
questions**. Usually, we think it’s probably because people are just ashamed to
ask, of admitting that they don’t know something. Depending on the personality
this can definitely be the case, but sometimes, as engineers, we just prefer
wasting hours on a problem and get to a solution ourselves rather than asking
for help. This might go back to the reward system, it’s great for our brains to
manage to fix the issue at hand, there’s no satisfaction in being given the
answer to a particularly hard problem. If you can relate to this, make sure you
do ask questions, there’s plenty of challenges ahead, you want to make sure you
maximise the knowledge you gain from the time you spend on this planet and
asking questions is a great way to do just that.
> Absorbing the knowledge of someone that spent years learning from his mistakes
> in a fraction of the time is invaluable.
We also tend not to challenge our mentors too much, blindly following their
advice. Don’t get me wrong, this is usually good practice, but we should also
make sure we validate things from time to time, especially when they don’t feel
right. At times mentors do tend to become a little overly pragmatic and might
need a shake up. Take your time to build a showcase for what you think is an
improvement so they can easily evaluate it, if it’s good they will embrace it,
they should be experienced and smart engineers. If it won’t work, or it’s not an
improvement, they will help you understand why, and these are all valuable
lessons.
Another common mistake in our early days is going fast, and I mean, **really
fast**. We want to demonstrate we are performant, we write tons of code, but
sometimes we are not even sure whether we are actually building the right thing.
This can be a massive waste of your time, so please, **slow down**, clarify the
requirements again, take a long breath, and work on your tasks with a more
focused plan.
### The “fun” game of jumping ships
The first few months or years go by, we reach the point where we seem unable to
step up our game. Our colleagues now look less knowledgeable than they did
before, even our best mentors don’t look that special anymore. We’ve absorbed
all the knowledge we could, so we start looking around in search of a place
where our learning adventure can continue.
We also become a little stricter in our job search, we now want to work in a
place where not only we can keep learning new things we know nothing about, but
where we could also use our favourite technologies to build wonderful things.
During this period we might jump a lot of ships, companies look great on paper,
but once inside it gets boring pretty quickly.<br> Eventually, with
perseverance, we find a great place to work again, or at least one that suits
our current needs, and we get back to work.
### There is no such thing as over-engineering
We’ve evolved over time, and if we are unlucky enough, we have developed an
[OCD](https://en.wikipedia.org/wiki/Obsessiveâcompulsive_disorder) towards
achieving perfection in our code. Refactor after refactor after refactor **your
code becomes more and more beautiful to your eyes and more and more obscure to
the other members of the team**.
*A word of advice*: try to write down how long it takes you to write down your
new beautiful DSL, or super-generic uber-abstract future-proofed solution (*that
is only currently used in a couple of places in the codebase*). And in addition,
double check your “*git diff”.* Have you really improved your code after that
refactor? It’s usually a good sign if you managed to **remove a big chunk of
code from the codebase**, otherwise, you can always choose to reconsider and
park it in a branch for the time being.
At this stage in our career, we always want to demonstrate how smart we are to
the rest of the company, or the rest of the world. We need this in order to get
that dopamine shot we need to get through our days at the office. Normal tasks
do get repetitive, so this is our escape route. We start spending a lot of time
innovating on what already works and not enough time writing code that is
actually solving business problems.
Even if we know a way that works well and it’s battle-tested in production, we
still seek for “new” ways or magical improvements. We tend to spend a lot of
time trying to refine what’s already working quite well and is clearly
understood by the engineering team.
One of the best pieces of advice I can give for these situations is the
following: **having code that works in production gives you more time to
evaluate new methodologies, cutting-edge frameworks and experimental libraries
during not particularly busy times**. The stress that comes from new mysterious
production issues is no fun. Make sure you experiment in less critical parts of
the system or build a few well-tested side projects. This will make production
adoption much easier as you will be able to share what you’ve achieved with your
colleagues, get feedback, and eventually manage to have a smoother transition of
your improvements into production.
Another common pitfall is **trying to make everything work 100% of the time**.
We consider every possible minor edge case and write tons of complex code to
handle it (*which might actually make things worse*), making the codebase harder
and harder to maintain. You might think this is the only way, but it isn’t.
Imperfect systems are sometimes fine from a business perspective, just ask the
business for their opinion, they might prefer to use their resources and time to
move on and build the next feature instead, and just send an email to a human to
manually fix the problem if it occurs.
### Why do we follow the buzz?
Another thing that happens naturally during our careers is this: **we just put
the world on pause and start learning something new**. It can be a new language,
a new framework, a new methodology, an entirely new area of development, or
something different. *But how do we choose?*
Sometimes, something just attracts our attention because it seem to solve one of
the problems we are currently facing. Sometimes we just do it because it feels
like the whole world is moving in that direction. Sometimes it’s only for the
sake of getting a better job.
The tricky part is how to learn how to distinguish temporary noise from actual
industry-changing technologies. The only advice I have on how to approach this
comes down to trying things out yourself, and I mean, **really trying them
out**.
Spend some relevant time on it, don’t just read blog posts about it, dig deeper,
come up with your own pros and cons list. *Does it really solve the problems it
is claiming to solve?*
After endless time spent mastering frameworks and libraries, I’ve learnt that
the most important thing is keeping them at the edges of my software systems. If
they turn out to be heavily bugged, abandoned or superseded by new alternatives,
they could be easily replaced.
> Learning to cut through the noise will make you a much better engineer. New
> technologies come up every day, no one forces you to use them.
A very good step towards maturity in software engineering is to **prioritise
having working production code over new buzzwords to put on your CV**. It can be
tricky at times, and it does not sound cool saying this in an interview, but it
should be far more valuable to a company to have working and maintainable
software.
**Please note**: this does not mean we should stop being curious or not spend
time on learning the next big thing. We should just try to balance things out
while learning to keep having fun from the junior members of the team, but
accept that you should get the job done sooner rather than later.
### The road to greatness
During the transition into more senior positions, **we tend to grow more and
more pragmatic**. This tends to make us look a little annoying and less
competent to the junior members of the team or the engineers we are currently
mentoring. We also tend not to code as much as before, some of us think trivial
tasks are beneath us, which amplifies the problem, try instead to lead by
example and close down those trivial or boring tasks yourself.
Having enthusiastic team members can help us remember that we should try to
remain curious and keep learning. We should keep trying things out, our
expertise will help you make a much more informed decision on which tech to pick
up compared to a few years back in your career.
It’s not easy to generalise how a senior software engineer looks like after
decades, though. We tend to evolve in different directions, but **we still share
the same potential issues**.
We are much more likely to fall into the trap of under-engineering. Our
experience now tells us that early abstractions are not going to work most of
the time. Just remember, if your team doesn’t enjoy working on some parts of the
codebase, it’s a sign that it might have been under-engineered and left behind.
It might need improvements, so prioritise it whenever you have time to address
tech debt.
Another likely danger is **becoming a victim of our own cargo cults**, the ones
we’ve developed over the years. Make sure you challenge them from time to time.
### A note on humility
Years of experience don’t directly translate to better-written code, keep asking
for opinions and code reviews. Sometimes I ask my wife (she’s *not a
programmer*) to proofread my code to see whether she can understand what it
does.
You’ve probably heard this one before, but your experience should have taught
you one critical thing: **you can’t know everything**. Anyone can still teach
you something you don’t know anything about.
### Don’t give up
We all have highs and lows in our software engineering careers. Some of us start
prioritising money over job satisfaction, ending up in either contracting roles
or highly paid boring jobs. Some might move into management **in search of a
bug-free life**.
It can be intellectually challenging to have to deal with a continuous stream of
problems, and in software, this is just how things are. It’s impossible not to
experience those days where it’s just too much to take in, and think: “*Why am I
still doing this? *[Everything is
broken](https://medium.com/message/everything-is-broken-81e5f33a24e1)".
If you feel like you need a change of career, **take a break**. It usually works
quite well to just disconnect for a few days or even a few weeks. You won’t
believe how much revitalised you will feel when you come back, actually craving
for something to build, or **a big mess to sort out**.