Things they didn’t teach you about Software Engineering
I’m jet-lagged, running on too much espresso, and decided to finally hit “publish” on the notes I’ve been stashing in my phone since last summer. These are the bits nobody bothered to warn me about when I started writing code for money. All subjective, all from the trenches — your mileage will almost certainly vary.
I kept postponing this post because each week another “oh right, that too” moment popped up. Twelve months later the list is messy but long enough, so here we go.
You rarely write something from scratch
My first paid gig was a green-field Turbo Pascal app — a tiny invoicing tool for a local shop. Full control, no legacy, no Jira, just pure dopamine. I haven’t had that kind of autonomy since. These days the canvas is already covered in thick layers of someone else’s paint, and your job is to retouch a corner without breaking the perspective. Romantic? Not quite.
Universities like throwing 400-line assignments at you: “write Dijkstra from scratch,” “generate a maze,” that sort of thing. In real projects you open a repo with a few hundred thousand lines — half of which were written at 3 a.m. by a colleague (or so the git log suggests). You spend four days spelunking through docs and Slack threads, then push ten lines that stop the bleeding. Next sprint, same story, until you become the new keeper of that monster.
Most professionals work on tiny slices of a huge system, and nine times out of ten that slice is maintenance. (I could be wrong, but the ratio feels even higher in fintech and healthcare.) The sooner you accept that “refactor” beats “rewrite,” the less frustrated you’ll be.
Domain knowledge is more important than your coding skills
Nothing accelerates feature work like truly understanding the business you’re coding for — ledgers in banking, table turns in gastronomy, settlement cycles in logistics. When those concepts click, the architecture almost sketches itself.
That said, I wouldn’t go as far as claiming domain > engineering across the board. I’ve seen brilliant accountants-turned-devs grind to a halt because they never learned to debug race conditions. Conversely, strong engineers with weak domain chops often ramp up fast once the team pairs them with a subject-matter expert. Hiring managers know this; many prefer to teach the domain rather than rebuild someone’s fundamentals from scratch.
So the hierarchy is muddy: understanding why the thing matters is fuel, but knowing how to build and debug it is the engine. Neglect either and the car doesn’t move.
Writing documentation is not emphasized hard enough
The first time I inherited a microservice with zero docs I spent half a week reverse-engineering query params from wireshark captures. That pain rewired my brain: future-me would never wish that on anyone (including myself six months later).
Universities make you comment functions; they rarely grade you on whether a stranger can run the service on Tuesday at 2 a.m. After a few midnight incidents you’ll start treating READMEs like insurance policies.
(Debugging deserves the same spotlight. Courses teach “write unit tests,” then move on. Systematic debugging — tracing, binary bisection, reading core dumps — is a survival skill and should probably get its own semester. “Why Programs Fail” saved me countless hours; wish I’d met it earlier.)
Code is secondary. Business value is first.
Nobody outside engineering cares how many lambdas you inlined last week. What they do notice: the checkout flow loads faster, or the site crashed during the sale. Code → Software → Value. Break any arrow and the chain is useless.
If duct-tape Perl gets customers unblocked by Friday, congrats — you delivered. If your immaculate Kubernetes stack ships zero user benefit, you didn’t. The trick is keeping one eye on elegance because tomorrow’s value depends on today’s maintainability. (I learned this the hard way: a quick-and-dirty script that printed invoices became a tens of thousands of lines of code monolith none of us dared touch.)
You’ll need to work around incompetence
At some point you’ll hit a wall: an API vendor that replies every three weeks, a stakeholder who wants blockchain because “investors love buzzwords,” a manager who schedules deployments on Friday evenings. You can fume or you can route around it.
I lean on three habits: 1) write everything down — meeting notes turn into receipts when timelines slip; 2) build failsafes so someone else’s mess can’t topple your service; 3) give honest, private feedback early. (Still working on #3 — the line between candid and jerk is thinner than I thought.)
The short list I fall back on:
- Pull extra resources if possible.
- Delegate to someone who can unblock faster.
- Add circuit breakers, retries, fallbacks.
- Book a 1-on-1 and state the impact, calmly.
- Do all of the above without snark — future you still has to work here.
Enjoyed the read? Join a growing community of more than 2,500 (🤯) future CTOs.
You work with uncertainty most of the time
The syllabus promised neat specs; the job delivers half-baked ideas and a moving deadline. Your PO waves a napkin sketch: “A-to-B, brand colors undecided, third-party API comes once we tell them what we need.” Welcome to the actual craft: extracting clarity from that soup.
Requirement gathering feels slow because success is invisible — nobody applauds the bug that never ships. Yet skipping it is how you end up rebuilding the same feature twice.
Some tasks sit in discovery for weeks before you write a single line. I used to think that was failure. Now I see it as cheap insurance.
Assume everything has bugs
Quick mental model I use (borrowed from too many post-mortems):
- Your code: obviously buggy.
- Third-party libs: also buggy, you just haven’t hit the edge case.
- OS calls: better, still buggy (see OpenSSL CVEs).
- Hardware: occasionally buggy — hello, rowhammer.
- Power grid: mostly fine until someone with a digger hits a cable.
Treat every layer as guilty until proven innocent, design for failure, sleep better.
(I’m not entirely sure this mindset scales to five-nines medical devices, but for web apps it saves a lot of pager duty.)
It's not a dream job
Yes, there’s decent pay and a comfy chair; there’s also context switching, releases at odd hours, and the creeping dread of obsolescence. Some places expect you to monitor Slack 24/7, but healthier teams rotate on-call and enforce offline weekends. If perpetual standby is a deal-breaker, filter for companies that treat uptime as a team sport, not a personal sacrifice.
- Long stretches of keyboard time.
- Work can follow you home unless boundaries are explicit.
- You won’t love every ticket — some are pure grunt work.
- Career ladders plateau; sometimes you need to switch companies to climb.
- Deadlines + defects = stress.
- Remote perks come with isolation; plan social time deliberately.
- Tech shifts fast, so keep learning or risk rusting.
Aesthetics can't be taught
Clean code isn’t just the right amount of indentation; it’s flow, symmetry, the absence of friction when you read it. Professors can show examples, but taste develops the hundredth time you refactor someone else’s switch-statement labyrinth into a tidy polymorphic dispatch. I still grimace at my 2014 commits; that’s progress.
Estimations will be asked even when you don't want to give them
Ideas start as “two-week prototypes,” budgets follow the numbers you mumble. Resist or embrace, but the ask won’t disappear. Experience helps — after enough varied projects your gut builds a lookup table of pain.
At Mindnow we throw a coarse number at the whole project first — big enough to scare us if we’re off by a factor of two — then refine sprint by sprint. Not perfect, but it keeps lights on and scope in check.
Not all meetings are bad
The meme says “that meeting could’ve been an email.” Sometimes true. Other times that 15-minute sync saves a week of re-work because design, QA, and marketing discovered the same blocker at once. The trick is insisting on an agenda and leaving the call if it derails — politely, with notes.
Information wants to travel; meetings are just one highway. Keep them short, focused, and the codebase will thank you.
Conclusion
If you’re eyeing software engineering, know that it’s less “change the world” and more “stop the pager from ringing.” Still, it pays the rent and, on good days, gives you the same buzz as finishing that Turbo Pascal app. Protect the fun parts and the rest becomes tolerable.
Add your own unspoken truths in the comments — I’m still collecting.
Other Newsletter Issues:
Worried your codebase might be full of AI slop?
I've been reviewing code for 15 years. Let me take a look at yours and tell you honestly what's built to last and what isn't.
Learn about the AI Audit →No-Bullshit CTO Guide
268 pages of practical advice for CTOs and tech leads. Everything I know about building teams, scaling technology, and being a good technical founder — compiled into a printable PDF.
Get the guide →
78 Comments
Thanks a lot for this. I’m just starting out as a software engineer and I could totally relate to this. It was a great read!
I think this is very biased by your personal bad experiences in bad companies.
Great article. Really well written, enjoyable, illustrated and true! Software Developer por 26 years here. Cheers!
Nice article. I’m usually pretty skeptical of these types of articles, but I’ve been writing software professionally for nearly 20 years and this is well written and a good summation.
Great article, but this point is just way off-base:
Rare work-life balance. In other professions, your work day ends at 18:00, and you forget about the job. Not here. You will most likely always be online and checking the code, even in the evening.
Only time I’m working late is if there’s a deadline that we’re late for (very rare) or I’m on-call. Definitely not the norm.
Totally can relate to all this.
So many of these problems go away when you’re using modern lean/agile development frameworks. I’m been doing software for 40 years, all of which I have enjoyed, but the last 10 have been like walking out of a dark cave into the sunlight.
Nice, pretty much spot on based on my 25 years development experience. I live by 2 rules: All software has bug and people make mistakes.
Good list.
“Electricity will always be there”
Rare to hear people considering this, as someone who grew up in a third world country. I’d also add Internet to that, so many apps have gone viral for doing off the wall shit during a AWS or DNS resolving problem
Customers are better than managers; a) you can have many independent ones at the same time, b) you can guide them to good decisions, c) you can tell them “No, I won’t do that.”. Bad managers just make your life miserable.
Collaboration with egoistic team members that wants to show themselves and don’t listen to other opinions and managers listen to them and take what they said as the only and best solutions.
Great post, loved the section on creating value — some of it went to my quotes pad 🙂
I agree though with others raising their concerns around work-life balance. How much time you spend at work is your choice and if your managers or peers expect you to do overtime, it’s probably a toxic environment.
Any time someone says “X can’t be taught”, all I hear is “I don’t personally know how to teach X”. Do you also believe that nobody who goes to art school comes out a better artist?
Granted, it “can’t be taught in a one-semester course” — which is why software engineering is almost always a degree program which takes a few years to complete. I can’t think of any other subfield of software engineering which can be taught in a one semester course, either, but that doesn’t mean we throw up our hands and say “Databases can’t be taught”.
Politics has more influence on your success in your career than your skill or knowledge. Software engineering is full of incompetent people who are good at politics. They can barely write a line of code, but could sell snow to an Eskimo. They crave power and are often found in positions of influence, where they create processes to control the people under them. If this happens to be your boss the only way to succeed is by engaging in politics with them – by being subservient and doing everything they say. If you’re lucky you get on their good side and you might get a positive annual review and maybe a salary increase. If you’re unlucky they make a mistake and you take the blame.
I have worked strictly in agile development with a small team. We are actually transitioning to be more wagile, because as we’re pumping out features saying the framework is deprecated, the framework is deprecated! The whole company is like, “The website is still working…?” So, getting people to realize backend needs is definitely a challenge. Yes, the code may work now, but if browsers implement a change, the code may immediately stop working.
You are not the “go to” person about this topic apparently. You have scared me to my death about my decisions right now.
Very nice writeup – it does indeed resonate with a lot of the real-life lessons I learned in 25 years as IT professional.
A few additions, if I may:
“your memory is not as good as you think / you are not as clever as you think” – every developer is bound to have at least once to come back to his/her own code after a long hiatus, and spend at least one full day wondering in disbelief “WTF is this!”. Writing easy-to-understand code trumps writing smart code (this includes both striving for good commenting practices and for uniform coding style a.k.a the principle of least surprise).
“it’s easy to be an asshole when you are often smarter than your peers” – mandatory advice for all It practitioners who think they are superstars, and especially true in the first years of career. A few humbling experiences here and there can help rectifying one’s hubris back to levels which make it acceptable for profitable human interaction.
“alone you go faster, together you go farther” – smart, highly-effective people often end up overburdened and then burned-out, both because they like their job and take pride in what they do, and because their colleagues and managers can easily take advantage of that. Always remember that there is value in having a team of individuals with diverse skills ready to support you.
The only piece of advice I have a dissent view on is the one about the “dream job”. True, there are real downsides, but I still can think of very few careers which will grant you economic stability and full-employment guarantee all the while allowing you to basically play with your favourite toys…
I’ve been in the industry for 35 years, and everything you say here reflects my own experience.
I had a university prof who once gave out a vague assignment, forcing students to research the topic before they could code anything. When they howled in protest, the prof’s response was “welcome to the real world”.
Fantastic! I’ll be saving this post.
Na’aman Hirschfeld
Great read! It really is like that. I’ll send this post to my coworkers.
Great post, as a Gen.Z who just entered workforce (been working for few months now), every point resonated with my experience till now. I am not sure if I like software engineering though after personally experiencing all these bullet points.
It was a good read, and a lot of it is true. But I don’t agree with ‘ Highly unlikely that you will make a meaningful difference in the world, but in the end, it’s just a job’ – it truly depends on the company you work for. You surely can make difference with your ideas and even finding existing bugs which can be fixed for future improvements. You have to enjoy being a developer, if you just think it’s just a job you can’t become better. You can earn a lot of money too and raise your salary much quicker than most industries.
Very good article
Good article
For sure amazing!
if all the commente are anonymous why bother giving them a name?
also good article
As a multi decade software engineer it captures a great deal of reality. And I particular love the “why would I dream about labour” image.
To those saying it scared them to death about their current choices or might put them off just look at how many of us have posted saying it’s largely true but have still happily done it for 20-30 years (like me). I think it’s best to know it has many such realities but can still be enjoyed.
Good article! I would add testing. You hopefully spend a good amount of time wilting automated tests. This comes as a surprise to many new grads who don’t learn about automated testing in school. It you end up in a job where your coworkers aren’t spending a significant percentage of their time writing automated tests, you’re not working with a great team.
Thank you for summarizing almost 20 years of being a developer.
Aesthetics *can* be taught. Not in one semester, but with a design degree. That’s why proper agencies have both design and development crews working hand in hand.
Lot’s of truth here about the negatives, but I personally have never had trouble finding work or paying the bills. So, it could be a lot worse.
One of the best and truest articles I’ve ever read. There is only one point of disagreement. Aesthetics can be taught. It requires lots of repetitive code reviews. It was done in a boot camp which I was teaching in. The results were satisfying.
I think this is very true having done development for 30+ years in various roles and various companies. If some of those people commenting below have not had these experiences, they can be happy as it is certainly the norm to find most or all of these issues in practice.
Agile doesn’t make any of these issues go away magically. Any company still has to work proactively to reduce or eliminate some of these issues and some of them is simply the nature of business in the real world as the author pointed out.
Thank you for a well crafted and useful article, Vadim!
The “domain knowledge” one is especially galling. So many software engineering job descriptions are just boilerplate ; it’s so frustrating to not even have an inkling of what the company actually *does*. I started working in cheminformatics/bioinformatics/biostatistics in 2001, and fortunately it was made very clear in the interview that there would be a steep learning curve in some highly complex technical areas (there certainly was), but I loved it.
Very well written and I feel seen as a developer. All of the points resonated with me. I don’t know if it’s nice to know that these are all kind of universal things that developers have to deal with lol
Oh boy, I don’t even know where to start:
– comments: same category as documentations. For me comments are smells, the code should be clean enough so comments are not needed, plus 95% of the comments are useless. Such as: loops through i (not quite as bad, but I hope you get my point). Also they are rarely maintained by others, so they are often misleading because they describe a previous version of the code. I treat them the same way as you described the way you treat the code (they have bugs)
– estimates: an established team can estimate ETAs based on their throughput without ever neding to estimate effort.
– everyone can learn writing clean code, they just need to care and need to practice. Katas are good examples
– testing/automation/static code analysis/monitoring tools: these should be the #1 concern of every developer. Everything you said about bugs and human mistakes is true, so every developer should do DevOps, this is actually what DevOps is about.
I have more, will add some more tomorrow…
Do we need commented code?
Well explained the absolute truth of software development. It was exciting to go through each section and can easily correlate it with my day-to-day activity at the work.
In the eighth paragraph, the word is “waiters”.
I really enjoyed reading this article, but, holy shit, am I really the only software engineer on this planet gets a hard-on for my work? Seriously, I love my job. I love the meetings. I love discussing requirements and setting expectations with stakeholders. More importantly, I spent at least 50% of my time each week actually writing code. The only stuff I dislike are writing tests and doing peer reviews, but even that is really not that bad. Good luck out there, may you find your happiness.
Absolutely awesome read, thank you very much.
This article covers most of the major points. #8 is what separates a junior SE from a senior SE. Even if you find a bug, can you fix it or create a workaround? If it’s in a library that you can’t change then you will have to find a workaround. Finding bugs in multi-threaded code can be pretty tricky because it can be difficult to re-create because it won’t show up when you’re stepping through your code in a debugger.
If you use threading in any concurrent programming then you will always get problems and deservedly so. using functional programming does not cause these problems.
Having been a developer of business applications for 40 years I can absolutely say that it is my passion. Many times I have worked long hours for no extra pay but found the reactions of my customers to a successfully completed product version to be payment enough. Other times I have been given conflicting directives and a project has stalled or died due to management issues. Primarily I love developing software. I’ve had many options to move towards management but decided to stay in a position I love. Too many are promoted beyond their capabilities.
Great read but a bit too cynical. I am now retired and worked in software engineering (real time, safety critical and high integrity systems) for over 45 years as a coder, tester, manager, assessor, auditor and loved it. The best bit was the coding. I now code at home as a hobby, even better fun. One thing you missed was testing your code – I hope you left no Zero-days in them 🙂
A well written piece on the realities of the software engineering profession.
I was a senior software engineer when I retired in 2014 after 43+ years in the field.
I always enjoyed working with the technologies but couldn’t stand most of the management. They were arrogant, incompetent, and mostly had no real idea what a professional was talking about.
I am still heavily involved with development but on my own projects and still enjoy the work.
Most young people today entering the profession have no clue of what to expect and nor do most of them have any real qualifications to do the work. Their single largest drawback is that young people are no longer taught how to do in depth research. If they can’t look it up on the Internet they don’t know where to look…
Could you please tell more about depth research
I enjoyed reading this. So far you were spot on and I cannot think of anything left. Maybe that you most of the times have to deal with people tachar doesn’t seem to be supportive. People that apparently is only keeping you from achieving goals. People you will easily think they are the worst. For me, that is the latest big lesson in my career. Being more empathetic, more understandable and always trying to move the team forward. Sometimes I think, when will it be my turn to be the SOAB from whole everybody has to learn? I’m still working on it.
Thank you for this post.
Awesome article! Thank you for sharing your experience!
Nearly spot on all aspects of my 20+ year career. Although early career was spent writing lots of code, some 80% of my time. As these stack up, maintenance takes over but your single most valuable message here is the being a domain expert. Have people that understand the business is the difference between success and failure. How many 3rd party vendor systems have simply failed because each one builds their own silo and has no real understanding of the business.
When you get the domain right, most of the time the system succeeds. Thanks for the great read.
Great article! My 2c:
“Code is secondary” is an understatement. I’d say “Code is not an asset, it’s a liability.” The delivered business value is inversely propotional to the amount of code added for implementing the feature.
Kerem Ispirli
All so very true. I’d also add that you will continually be asked to grow and learn. Eventually, that Silverlight app is going in the trash.
Awesome artcile! Can I translate it as Chinese and reprint it on my blog(https://yorick.love/)? I will indicate the source.
[Answer]: Sure, feel free to translate it. Also if others are wondering, of course you can translate it, just link back 🙂
That’s a real awesome article! Describing the real wold. But remember: You’re the only one who can provide these software to all the other people. That’s real fun!
Thanks, I love this article. WIll link it from my own blog in Beginner’s resources category https://suchdevblog.com/resources/BeginnersResources.html
> Rare work-life balance. In other professions, your work day ends at 18:00, and you forget about the job. Not here. You will most likely always be online and checking the code, even in the evening.
we should not make this normal. this is not normal, nor acceptable. toxic companies don’t provide good work-life balance, but THERE ARE MANY who do. if you are stuck in one who doesn’t, look for another employer 😉
“Aesthetics can’t be taught.” Yes and no. Aesthetic can’t come from a lecture or a book. Yes coding is a craft, and you have to learn that craft by doing that craft. However, as in writing were a good editor can help make you a good writer, a good set of reviewers that you ask to look at not just correctness, but style, clarity, readability, and maintainability can help teach you the craft.
Also of note, your own aesthetic always needs to be tempered to max the aesthetics of the project. One doesn’t simply add “modernist” elements to an “art deco” design. Projects are a collaborative process, and while one can influence change over time, passive aggressive “I write code in my aesthetic” isn’t going to your influence to make that change.
Indeed very realistic view. It feels a bit depressive reading all the negative sides of the job, but I have also experienced them.
I would also like to mention that if you are a clingy type of person, you may find it hard when your coworkers leave for another company (way too early). As there is an abundance of job offers in IT, anyone can make the switch any time they want.
In conclusion I would say that we software engineers are pretty lucky, as we have above average salaries and good working conditions compared to others.
This article speaks so much like a teacher to the younger me. I was once a developer (though not a rockstar one, I believe I’m one of the best), and there are times when I worked on code so hard that I would expect some great recognition of that masterpiece.
But it is just that…a piece of a puzzle. And there’s a lot more people who worked on a different piece (may not be as hard), people who reviewed our work, people who sold it to the world. You will be commended, but it will not always translate to a promotion, or higher pay. You are indeed being paid to do that work you did.
What really matters is the impact of things you do or say. And present that in numbers (ex. influenced 50+ developers), and that will bring you that value. Impact.
You _never_ get any appreciation on the most magnificent hacks you make. The (few) times somebody has given me highly positive feedback has been after some trivial piece of code or at most on the finalized product.
As a software developer one must contend on patting own back when we talk about solving difficult problems.
This based on over 40 years of day-to-day coding career…
Hi, this is a super insightful thing that I have been mapping to myself from the very beginning to now. That’s hard-fact for lots of ppl out there.
Do you mind if I translate it into Vietnamese and also have a link back to this original post?
Super work!
Wow. I love this article. very insightful. I came from a very different career background and now I’m working full time as software developer and this article almost touched on everything I’ve gone through. I cant help but reiterate on Documentation as the most important aspect in software, I noticed when a developer leaves the company without documenting some stuff its so hard for the next developer to come and continue his work, taking him almost weeks just trying to figure out stuff
and that it’s better to automate some procedure, instead of writing ambiguous 20 step manual or design easy to understand interface, instead of creating docstrings with concepts explanation. When time is a limited resource, the documentation is in the middle of priority pile, under the working code, modular code, and self-documenting code
Thanks for the great article. As an developer in early career, I can feel some of things you mentioned here. Your points help me clear my mind a lot
I learned the hard way that skipping documentation can turn into a nightmare, especially when you’re trying to figure out past decisions made in a hurry. Getting to know the ins and outs of the business side has saved me countless hours of coding in the wrong direction. It’s not just about the code; it’s about making something that actually solves a problem. Trust me, investing time in understanding the domain and keeping track of your rationale through documentation is a game-changer for any developer.
Just starting out in the field, good to know all this!
Spot on
Empathy in coding’s super important, lol. Ever tried explaining code to someone not into tech? It’s like, wow. Keeping stuff simple and being patient makes a huge diff. Also, learning new tech stuff together as a team’s pretty cool, keeps everyone on the same page. Isn’t it more than just typing away at the keyboard?
Really vibed with the bit about knowing your stuff beyond just the code. Getting what’s happening around the app makes a huge difference. Also, yeah, documenting everything’s a game-changer. Saves so much headache later. Makes work smoother for everyone. Spot on.
The article really nails the day-to-day life of a software developer, especially the part about the importance of understanding the business context. In my own experience, diving into the specific industries my projects were part of massively improved how relevant my contributions were. Also, keeping my documentation straightforward has saved me countless hours when revisiting old code.
Good content and nice writing as well. Thank you.
This is spot on
In my current job, I wrote at most 2-300 LoC in over 3 years. I really dislike corporations…they try hard to find the best candidates, they give you high school tests from hackerank…then they keep you for “potential use” 🫢
Managing incompetence is one of the biggest problems in this industry, especially with the over-reliance on AI that makes people believe that anyone with little or no training can become a good programmer.
I just wanted to echo what everyone has been saying. Great writing and great reflection. It’s clear you’ve really given thought to what the ins and outs of the field are. It also brings some comfort to know we’re all thinking the same thing (even though you can’t really talk about it with your colleagues…because we’re all sitting behind our screens the whole day)
great article !