Software Engineering is an amazing career choice. We use our skills, continuously learning along the way, to solve business problems in ways that provide impact to the business and the world.
Tech never sits still, so we can always re-invent ourselves by generalising and/or specialising when new technologies come to light (👋 metaverse). You work with people who enjoy creating solutions in a collaborative environment and have a blast creating aha moments together. I love being part of the tech community, the tech field, and as a software engineer at Netflix, helping bring more joy to the world!
With all of that being said, there are some known uncomfortable truths we can accept about software engineering. I believe each person once they accept these hard-to-swallow truths can adapt, and handle them in a productive way. I will note, these truths are based on my career as a private sector employee with ~10 years of experience, so your truths may differ slightly.
1. You will never know everything
There are many different technical career paths as a dev. You can become focused on the web, specialising in WordPress, Angular, or React. You can choose to be a Python expert or Java or JavaScript. You can work on internal applications or be an expert in consumer-facing ones instead. You can specialise in AX Dynamics or Salesforce. You can learn augmented reality, virtual reality, or build games. Dare I even say, you might be interested in being part of web3.
Not only do all of these variations exist, but the technology down each path constantly changes.
With a ridiculous amount of technologies and specialisations, it’s going to be impossible to know everything and master all of these technologies.
Coming to terms with this uncomfortable truth helps you shift your mindset to prevent burnout, imposter syndrome, and perfectionism. Instead, we know that the best we can hope for is learning a little bit each day, leading us to wisdom and expertise in the long term.
2. Imposter syndrome is real
Wikipedia defines imposter syndrome as, ‘a psychological pattern in which an individual doubts their accomplishments and has a persistent internalised fear of being exposed as a fraud.’
Yes, IS has been talked to death but I think it’s important to remind ourselves of this regularly to avoid getting in a rut.
Thinking on the second-order effects from our first uncomfortable truth: you will never know everything, I believe drawing a conclusion that it causes imposter syndrome is a fair one. Think about it, no matter how much you know about technology X, there is not only more to know about it (Dunning Kruger - the more you learn, the more acknowledge there is still more to learn), but there are technologies a, b, and c, that you know nothing about.
Additionally, the development community is alive and well. People are writing books, have amassed huge Twitter followings, and sell courses that educate thousands of people. Comparing ourselves against them is detrimental. Not to mention the unbelievable amount of open source contributions people are able to make, even with full-time jobs.
It can be challenging for someone who is being recognised as an expert to feel they know nothing or have zero following on social media. This is what I believe leads us down the path towards imposter syndrome.
Technical interviews cause imposter syndrome as well. Why is this? You can have years of experience building software, solving problems, and even be rewarded and recognised for them throughout your career; yet, when you are asked to interview and solve LeetCode problems on graphs, trees, or other topics you may not have used for years, you can feel like a fraud by not knowing how to answer them.
You have the credentials for the role, yet the technical interviews can cause you to doubt the achievements and level of skills you have.
I’ve written about Dunning Kruger and Imposter Syndrome in the past if you want to dive deeper into this topic!
3. Burnout is a big deal
Physical and/or mental fatigue caused by too much stress, too many hours, and too much pressure is a huge deal, not to be taken lightly. Engineers in the midst of burnout feel emotionless, don’t care about what they are working on, and are demotivated.
In a world where we always need to be on and productive, we forget the power of letting our bodies and mind relax. Our mind can only focus and create so much without a break, and seeing as engineering software requires both, it is imperative we incorporate those breaks.
The Honeypot community are huge supporters of mental health awareness. Our careers are marathons, not sprints, let’s treat them as such. Check out Honeypot’s documentary about a software developer’s unconventional way of dealing with burnout.
4. Perfect systems don’t exist
The longer a codebase exists, the more technical debt increases. This is the nature of the software lifecycle, especially when business requirements and priorities conflict with codebase health.
Teams do indeed invest in reducing technical debt, improving developer experience and productivity. We try our best iterating and using new innovative language or framework features; but, never to the point of becoming tech debt-free.
Architecting our software in a modular, flexible, and simple-to-change fashion remains a key responsibility of developers within a team.
Some say architecture discussions can be thought of as a “war” in which feelings should be left out of the discussion, and opinions should be held strongly like you are striving to win an architecture decision battle. I find this to be an outdated operating mechanism to have productive conversations, and one we should improve upon - there should never be an excuse to leave feelings out of it within a team, especially when all team members are responsible when it comes to implementing the changes.
Throughout my career, I’ve heard and also have said, “this is the right way we should architect it.”
Instead, I believe we should change the narrative to say: “based on the current requirements and our knowledge of the roadmap, we have decided to make changes X, Y, Z based on our decision framework that prioritises flexibility, backend-driven frontends, and simplicity over other attributes.”
By doing so, we recognise the trade-offs we are making for a given choice based on the results we want. My reasoning comes from the nature of huge roadmap changes, leading to additional architecture discussions, and then more changes to the originally envisioned architecture (the one people believed was the right one).
The quickly changing, no-safe assumption environment of the business world these days means we must adapt, and there are many, many ways to solve each and every change. A perfect and ‘right’ way most likely doesn’t exist.
My conclusion here is this:
Architecting systems in ways that we believe are best creates better systems. There are best practices teams can follow (and of course those change over time), but they might not always be the right way. Many times the right way leads to unforeseen second-order effects and revamps as time goes on.
My recommendation would be to avoid the biggest mistakes within architecture, such as huge amounts of code duplications or breaking multiple rules of 12-factor applications. It’s typically the big mistakes that do the biggest harm, so avoiding them can make a huge difference over the lifetime of the product. Remember, the uncomfortable truth is we will never craft the perfect system - we can only try!
5. You need more than technical skills
Writing design documentation, PR review comments, blog posts, slack messages, creating presentations, and collaborating effectively with your team all fall into the realm of being a Software Engineer.
Did you notice that none of these are actually writing code?
Technical skills are foundational — while growing your communication, leadership, and other soft skills takes you to the next level! The old stereotype of a hooded lone wolf in the back of the room is obsolete — development teams collaborate and work together every single day.
It’s like Will Smith said in his memoir:
“There’s no such thing as ‘just business,’ everything is personal.”
Due to generally more hours being spent on non-coding activities, like partnering with cross-functional teams, we need these soft skills for success!
6. We need more diverse teams
Using data from ComputerScience.org it is quite clear that work needs to be done that increases diversity within our industry; because, creating environments that people of different ages, ethnicities, races, and gender feel welcome and comfortable is imperative. Diverse ideas are important for humanity and for businesses.
We each can help do our part by giving back our time to the community. We can speak about our careers to younger generations and volunteer to mentor or coach someone learning how to code for the first time. We can be allies as we help stand up, drive, and improve the D&I initiatives within the companies our industry supports.
See potential, take chances, and mentor others so we can all thrive (abundance mindset please :D)!!
Concluding thoughts
Software engineering has helped me make a positive impact on the world. It’s connected me with brilliant people, solving challenging problems together. It has brought so much joy into my life that I am thankful for.
These uncomfortable truths are adaptable — we each play our part. Reading about them, educating others, and growing throughout our careers will help tackle each one.
The better we get at soft skills, avoiding burnout, diversifying ideas from people of various backgrounds, and continuously learning with the knowledge we can’t know everything, the better our industry becomes as a whole. Each of us can do our part in spreading these ideas, creating a career that upcoming generations (or those who change into tech) can thrive in!