Programming is so different than software engineering, to the point some people (like me) love the former but little by little are starting to hate the latter.
Learning for the sake of learning, being able to be picky about what to learn, feeling like a god by creating your own worlds, trial and error… these are all traits of programming.
On the other hand, software engineering is about sprints, useless deadlines, using the wrong tool for the job, writing code to increase shareholders value, high-performing-team obsession, useless C-level execs, broken tech interviews…
I think you are confusing the working conditions of writing software in a corporate environment with software engineering. To me software engineering is about skilled application of a wide range of engineering concerns to programming, such as architecture, data modeling, and QA processes.
I find such engineering fun and meaningful. As a software engineer, you understand that is not enough simply to write code that works, the right (or wrong) architecture, for example, can have a massive impact on various stuff like performance, reliability, code-quality, etc.
The BS involved in working for the tech industry as part of a team is another thing entirely.
I think that the original advocates of software engineering -- people like Margaret Hamilton -- were promoting an approach akin to chemical engineering.
Chemistry is about understanding chemical elements and compounds and the ways they react with each other to form different compounds. This includes the synthesis of new compounds, to understand the mechanism by which they might be created and the properties of the new compound; accordingly, chemical synthesis by a research chemist tends to take place in small amounts.
Chemical engineering is about the production of chemical substances, reliably, at massive scales for industrial purposes. Chemical engineers elicit and apply the manufacturing processes necessary to synthesize these chemicals by the kilolitre or more, which may be totally different from the processes the experimental chemist uses in a lab.
Similarly, programming is the act of writing code for a computer to fulfill some task, or explore some computational idea. Software engineering is the application of a standard, defined process to reliably produce code at massive scales for industrial purposes (enterprise applications, etc.). Architecture, data modeling, and QA are part of it, but the heart of the discipline is finding and applying the means to organize a large team to produce software that is robust, scalable, and maintainable to support an organization over the long term.
People who fancy themselves artisan programmers chafe at the industrialization and standardization of software engineering. But, as Milt Bryce said, "There are very few true artists in computer programming; most are just house painters".
"Software Development" includes programming, engineering, and "the BS involved in working for the tech industry as part of a team". Your title can be [software] programmer, software "engineer", software developer, or a plethora of other things.
Granted, software engineering is a pretty ill-defined term, but I'm pretty sure most would agree that agile project management is not software engineering.
"Being able to be picky about what to learn" being programming is also a really confusing idea. Programming is writing programs, it's not some learning philosophy, and it's certainly not some liberated opposite to software engineering.
I guess you're confusing having a job with software engineering, and spare time coding with programming.
> On the other hand, software engineering is about sprints, useless deadlines, using the wrong tool for the job, writing code to increase shareholders value, high-performing-team obsession, useless C-level execs, broken tech interviews…
That is not at all what "Software Engineering" is. It is Management's view and practice of what it should be based on the fad of the month/year, simplistic efficiency/productivity models, cluelessness about human psychology and its specific nuances when it comes to knowledge/programming work, erratic/idiotic business goals, bad human resources management and in general not understanding that while one can look to established Engineering disciplines for inspiration one cannot apply those processes/techniques blindly to Software Development since it is so very different.
The classic works of Gerald Weinberg, David Parnas, Barry Boehm etc. gives one the proper viewpoint to have towards "Software Engineering".
His research was a product of his times when programming/coding was considered a clerical job with the real brain work being done by System Analysts and System Designers who produced System Requirements Specification Documents and System Design Specification Documents. He was the first to show that software development costs would outstrip hardware development costs and the importance of its Risk Management through a Spiral Model. He brought "big picture" engineering process lens to the management of software development which became "Software Engineering" today.
All of these ideas are still valid though they would need to be modified for current times given the decades of experience we have had since then. Software development at the Individual level involves creativity/art/craft/individual flair and companies must acknowledge and provide means for expression of these psychological needs. OTOH, Software development at the Company level is all about Risk Management in the service of its Business Goals and hence needs a reproducible process and associated methodologies. We need to find a balance between the two.
I agree that risk management is important for software companies, in the same way it is for construction companies, and part of that involves software engineers.
But I think pretty much any business has risk management processes that involve domain knowledge, and a much larger and more distinctive part of any kind of engineering involves non-business considerations and tradeoffs that AFAIK Boehm didn’t really concern himself with. For example, a civil engineer designing a bridge is thinking about wind shear, traffic volume, vehicle weight allowances, and so on, just as a software engineer is thinking about latency, throughput, error propagation, and so on. To me, these sort of non-business-logic but very much domain-specific considerations are what comprise the core of software engineering (as compared to programming, which I would classify as just getting the business logic correct without any meta-considerations).
This comment is poorly edited, but essentially Boehm’s processes to me are better described as “software business management” than “software engineering”.
Agreed, though IMO "Software Engineering" subsumes everything. You are looking for a holistic and reproducible process which can be communicated using well defined methodologies.
One important point though; IMO Risk Management in the Software Industry is qualitatively different than that from other Industries. This is because of the greater play and importance of Human Factors involved and their cumulative non-linear effects. In very few other industries (eg. Finance) can you have a factor of 10x/100x productivity between the average and the best since it does not follow the normal distribution. If i have a Jeff Dean/John Carmack programming or a Steve Jobs salesmanship in my company i can break every engineering rule i want and still come out on top.
Nassim Taleb's ideas on Mediocristan/Extremistan, Power Laws/Fat Tails are all relevant here. Here is a great video explaining these concepts (though we have to adapt and apply it to Software Engineering) : Pareto, Power Laws, and Fat Tails - https://www.youtube.com/watch?v=Wcqt49dXtm8
That's somewhat arbitrary, don't you think? I think of "programming" as just writing code, "engineering" is coming up with what to code.
Rather, this is about capitalism. You want more freedom in going about your business. You cannot have that in a profit-oriented company. (Rare exceptions apply.) We're so focused on delivering, what we deliver becomes less of a concern, even though it should be the number 1 concern. The rest follows.
A solution oriented programmer can have the best business goals in mind by not half assing a hotfix but proposing a full new featue with large budget demands.
Some managers respect and care about good software but may need to compromise on budget cuts from higher up.
> Besides that: find small (2-3 day) project ideas that require you to learn max. 1 new technology or idea, and build lots of such projects.
That's how you learn programming. It's not a bad idea, but at least for me software development is more about long term issues coming up, team communication, features that create short term value but long term problems. How to organize big piles of code.
A lot of abstractions don't make any sense in a 2-3 days project and you are better of hacking away a script than looking into "properly" modelling things.
My impression is always that as a junior you learn how to do stuff. Then you learn to do complicated stuff. And becoming a senior you learn how not to do complicated stuff.
This takes some of the fun out of it as well. Deploying a feature that is simple and that just works without any issues does not create nearly as much excitement as "saving the company" with a big hack and high risk deployments, although it is much better to not have to "save the company" in the first place.
> Deploying a feature that is simple and that just works without any issues does not create nearly as much excitement as "saving the company" with a big hack and high risk deployments, although it is much better to not have to "save the company" in the first place.
Some people are more risk-affine, and some are more risk-averse.
The fact that such things work rather kindles a desire to do new interesting, experimental stuff in risk-affine people - something that a corporate environment often prohibits, which frustrates risk-affine people.
As someone who does play music, although not professionally, I don't really agree with the analogy that writing code is like playing music.
You don’t expect to learn how to play the piano by reading a book, but you might expect to pick up a programming language or concept because you read about it. Really, it doesn’t work that way. You have to read it, and then use it and practice it and make a hundred mistakes, and then you’ll gain the skill to use that concept more correctly over time.
I'm aware of code katas, but I bet close to 0 of the great programmers regularly spend hours a day just writing loops in C, just to REALLY make it second nature. Yet many great musicians do just that, except with exercises. I've spent months or years straight practicing an extremely easy to understand, but hard to execute riff. The dexterity and muscle memory needed for certain musical patterns on an instrument like guitar or piano can take many, many hours to develop.
I just don't know of anything even remotely similar to this in programming. Learning how to type fast is the closest analogy I can think of, but being good at typing is almost entirely unrelated to being a good programmer. It would be like a pianist not being able to play chords, yet still being considered a (technically) good pianist.
---
If one develops a good technical understanding of their programming language, and reads a lot of code, they could produce some quite good code in that language on their first try. In this case, it would help to have a very solid technical understanding of first principles as well. Asa result, I really think programmers with very strong discrete math skills, for example, can pick up any idea in programming.
If you write a lot of C code then you will write a lot of loops. It won't be deliberate practice but it will be practice.
What I find interesting is how much of this knowledge we take for granted once we have internalised it. My wife came into my study the other day and asked what I was doing so I started to explain it. After she ran away I counted up the number of concepts I needed to know to understand the twenty five lines of code I was looking at. There were nearly forty in that short piece of code.
although i'd counter with the idea that it isn't code-writing which we practice continually to master the art, but world modelling: we model the world within the constraints of code in our mind, to become experienced enough to do so reliably, then usefully within different contexts
In that analogy, the programmer is more like a luthier then, not a musician. Great luthiers generally aren't also great musicians. Completely different set of skills
I've gotten into the habit of actually reading the manuals for my synths and DAW after realizing I was missing out on lots of little quality of life things. I've used enough synths--and not just subtractive!--that I can usually pick a new one up in seconds, but the people who made it and the people who know it best contribute to those manuals and the stuff they share can lead to massive leaps in proficiency.
The specific analogy with music isn't great, but it makes more sense if you step back and say that a large part of software is aesthetic rather than technical concerns.
It’s not about writing for loops, the practice is to get good at problem solving and algorithmic thinking. For loops are a means to an end, like writing letters on a page.
Since the article jumps around a lot, let me add one more;
Software is an amazing passion, but a terrible job.
Imagine you love music, play the piano for hours every day, then once you grow up someone pays you a huge salary just to play. You're in heaven.
Now imagine someone who loves classical music, but can't play. You see the fortunes being made by piano players, so you decide to learn. Which takes years of doing tedious stuff like learning scales. Then you get a job playing hip-hop (a music style you abhore) for a band you don't like... Then you discover the business crap of "music business".
Programming is the same. If you love it, it's fantastic. But to those in it for the salary it's a mind-numbing hunt for tiny bugs, days spent searching for a missing comma, wading through the same old crud, doing the same task over and over, locked to a desk, dealing with sub-par teammates, inflexible management, projects that get canceled, crunch time, stupid users (and I can go on.)
The passionate thrive because the joy dwarfs the pain. (Also, because they tend to be -very- good so can largely ignore the bullshit. They're paid well doing something they'd do for free.
As a -job- though, every part of it is objectively terrible. From the interview to the firing. (Go on, write a job description of what you do all day. Now consider that description in light of someone who doesn't actually -like- programming...it's terrible right?)
Naturally there's good money in it. If it's not your passion, then by all means, do it for the money. Find your joy elsewhere, that's OK, but do find it. Because without that joy elsewhere, what good is all the money in the world?
This is really spot on. I realized how soul sucking it was after I got a teaching job. It was low pay English teaching in Japan but I felt a kind of joy, playfulness, humanity and a stress-free life I never experienced in working in tech. I've since gone back to tech and miss my students so much. Don't think I'll ever get that feeling at my current corporate job. I also ended up making way more side projects since my programming brain wasn't being used all day.
I spend a lot of time talking to non-I.T people due to my partner being a veterinarian and the local improv/music scene. The absolute disdain people have for the idea of sitting at a desk and taking orders from pointy-haired manager is humbling. They're very envious of things like remote work, etc, so we have it pretty cool in lots of ways, but I think there's something to learn for many programmers on the mental health/spirituality front from that contempt.
The happiest psychologist I know is many, many times more content than the happiest programmer I know at a corporate job. The most passionate software engineers I know might be able to claim similar joy, but they have overwhelmingly quit their corporate gigs and fly solo.
"contempt" isn't the word I'd used to describe my feelings towards this existence. It would be more like a deep, existential sadness. That life can fall into these local minimums of optimization - where everything is, on average, good.
- I'm happy, but not very
- I'm financially successful, but not very
- I like what I do, but too much
- I'm comfortable, but not too comfortable.
It's like my entire personality, likes, and dislikes have been smeared into a 2-dimensional caricature and propped up by a couple supports, for everyone to see and admire. This sort of existence is safe, inoffensive, and unremarkable.
Love your blog btw, it gives me confidence to be more like myself in my own life.
I read about some research recently where the researcher asked people how much money they earned and how much they would need to feel financially secure. No matter how much they earned they all felt they needed about 50% more.
It seems we are programmed to feel mildly dissatisfied no matter what our circumstances. I guess that is what drives us on.
This point of view is very popular and I've seen zero evidence for it throughout my entire life. Consider you might be living in a bubble where "the hedonistic treadmill" tired trope makes perfect sense... and that bubble is fairly small. Ever thought of it?
Practically every person I ever asked told me more or less this:
"Yeah sure, who would not want 100K a month? But I am not willing to forfeit my personal and family life for it and that kind of money always comes with a catch. Nah man. I'd be happy with 20K a month but it ain't ever happening while there's always the next a-hole CEO who wants a bigger yacht than his bros in the golf club."
So yeah, I heard your take many times and I have not seen it out there. Not once.
Assuming you were responding to my statement "It seems we are programmed to feel mildly dissatisfied no matter what our circumstances." I can't see how that squares with the paper I talked about. Of course you can raise your anecdotes but that proves nothing.
>> The most passionate software engineers I know might be able to claim similar joy, but they have overwhelmingly quit their corporate gigs and fly solo.
Yes, I'd agree with this. You make more money in a corporate gig, but if you're doing it for passion, not money, then the money doesn't overcome the corporate shackles.
> The most passionate software engineers I know might be able to claim similar joy, but they have overwhelmingly quit their corporate gigs and fly solo.
I have done the solo thing and have come to realize I much prefer coding for others. There’s just too much annoying bullshit in running a business and I don’t need to deal with almost any of that as an employee despite getting basically all the same freedom, impact, and influence as a high level engineer.
There’s even a point where things switch from your boss telling you what to do to your boss asking you what to do.
Agreed. Managing, fundraising, legal, roadmaps, payroll, hiring, sales, marketing, customer support etc. If you're a coder running a company, it's likely you might not get to code at all, or ever again if you're very successful. I wouldn't do my own business if my hope was to be more hands-on with software dev unless you find a partner to whom you outsource all of the above, but now you're back to the situation where you don't have full control anymore.
If you're happy with not having a bigger slice of the pie, it's easier to just focus on SWE as an employee and let someone else figure out all of the other stuff unless you really crave the company building aspect.
The main factor was the extremely low pay. Weird schedule too. (I worked in a conversational school, so not really even a teacher). Unless you work in international schools, you won't be making much more than minimum wage. It's a lot of fun though. I'd happily do it for possibly my whole life if the pay was better or I had another source of passive income.
You can also teach your skill. I do that, although not full time, but there is money to be made. If you are reasonably good at your craft you can teach novices and you can make sure they get their money's worth. Or give training at a company. I teach creative coding for lighting designers and vj's and if I could do it every day of the year it would net me a good income. However, the market is too small to live off.
I work with a bunch of people who fit into this mind set.
My view is that they want to play and not work to get things done.
I also see it as we are engineers first and foremost and we use a software language as a tool to solve a problem.
I’m also a musician who had the chance to make a living in audio production and nothing is worse than working on other peoples tedious projects, so decided to keep the art I love for myself and have a much better paid career in tech.
> My view is that they want to play and not work to get things done.
Nope, not at all. It's people who got sick of being sheep-herded into assembly-line processes. That you don't want to be an assembly-line does not automatically put you at the other extreme (namely the divas who want to only work on pet problems and get paid a lot).
You seem to have a terrible job, you should fix that.
Meanwhile many people happily make a living programming in a mostly stress-free, creative environment where every day brings new challenges and the codebase is well ordered and easy to navigate.
Also, tracking down bugs is fun! I can see how it would not be fun in a terrible codebase and have experienced that side of things, but nobody is forcing you to work at a particular company.
> but nobody is forcing you to work at a particular company.
It really isn't all that simple. I felt the same way when I was younger - "just switch jobs yo" - but as I grow up I realize that there are increasingly many external life factors forcing people into an unhealthy work environments which can be outside their control.
I work in a shitty legacy PHP codebase, but I do it for the great money and can accept the pain willingly. It is much easier to tolerate things when you know there is an exit nearby, but I imagine people can get much more jaded when their visa depends on the shitty employer, debts loom over their head, medical costs are piling up, kids require feeding every month etc.
It really is that simple and as I reach the end of my career I appreciate that more.
Life is too short to stay in bad situations for a long time. Of course it’s sometimes hard to move/switch job but it’s never impossible and why spend most of your waking life on something you hate with unremitting passion like the OP?
> Life is too short to stay in bad situations for a long time
Life is also too short to get evicted of "your" house (that the bank actually owns) when you miss 3 mortgage payments because you left because "life is too short to stay in bad situations".
I am forgiven to have been exhausted by the grind and for trying to be loyal and go all-in where I am hired.
Wait, it turned out I am not forgiven and just taken advantage of.
So yeah, I am trying. Not easy by any means. But lesson learned, though way too late in my life and career. I'll definitely be doing that going forward.
> You seem to have a terrible job, you should fix that.
You hiring?
Because what your parent commenter describes are at least 90% of all programming jobs. Everywhere. And I am being generous by not saying 98% because it's likely closer to that number.
"Many people" could be true only in the absolute numerical sense of the world. Say, 500K out of the dozens of millions.
Your comment resonates with me a lot. I have a passion for programming, as evidenced by my website. I have a history of jobs that pay well (as far as Canada goes). But every job has been rather boring and have not been a good fit for my skills. Instead of doing deep technical work, I get to deal with ever-shifting requirements, poor communication, and almost nonexistent project management.
The funny thing is 15 years ago, programming was nearly everyone's passion for those that were in the field. There were very few "job" type programmers. Not the case today.
I’d say the same thing except about 25-30 years ago and definitely not 15, which suggests to me that both of us suffer from observer bias and likely there’s always been a real mix of programmers who were really into it and others who were only after a job. Perhaps the proportion of uninterested programmers has increased though.
A lot of people heard there is money in programming so they did the bare minimum and landed a job.
The managers who hired them were not complete idiots, mind you. They knew what they were getting but they are playing their own games: they need the bigger head-count, they want to hire their cousin to oversee these sub-par programmers, they want to be seen as professional when they inevitably have to ask for external consulting when their underlings crap the bed on a regular basis, etc.
But it's mostly power play, I found, almost on a sexual kink level. A lot of people in power out there will hire you if you are meek and can't stand up for yourself. Really weird.
Having hired more than a few people, I'll suggest a much simpler reason. These programmers might just do the bare minimum, but that bare minimum is enough to accomplish the job we need them to do, and we can stop interviewing and get back to work.
It probably follows the booms and busts of the industry. Boom times encourage people to enter the industry whether they are interested or not. During a bust you will only get people who are interested in the subject for its own sake.
Like all crafts it depends on your market position.
If you're good enough to have more control over the terms of your indenture then it's a pretty solid career. The complaints you level are the same for any job where you're not trusted with much autonomy.
> Software is an amazing passion, but a terrible job.
Very well said! And it is all the Software Industry's fault.
When i look back at the noob me decades ago, i see a young'un full of energy, enthusiasm, curiosity and a hunger to learn anything and everything, knowledge for knowledge's sake, to prove oneself to the world and in general a would-be World Conqueror.
So what happened in the subsequent decades that lead to the current cynical fuddy-duddy? The battle in the trenches of "Software Industry" happened. The battlefield was stacked against him in every way possible, viz; He was told Knowledge acquisition without a Business Goal/Money was worthless, People clearly unqualified in the domain were appointed as his Managers and gave orders, His curiosity was curtailed, He was subject to inane and brain-dead management processes, His self-worth was actively diminished by denying his uniqueness and being explicitly treated as a mere inconsequential cog-in-the-wheel etc. etc.
So the grizzled veteran retreated from the battlefield, worked on getting back that "original beginner mindset", rekindle the passion, and vowing to never again allow himself to be put in such a situation even though he might be poorer for it.
> The passionate thrive because the joy dwarfs the pain. (Also, because they tend to be -very- good so can largely ignore the bullshit. They're paid well doing something they'd do for free.
I've thought to myself many times that I still can't believe someone is paying me to code, whether that's an investor or an employer. I happily do it for free even when unemployed, or practically for free for years on end when working on early stage startups as a co-founder. I've often wondered what this must feel like for people who don't actually like any of it, when for many of us it feels like play.
Right, you're not wrong but... "No", you can't scan that box in Chicago, the system says it's in New York. The world state is invalid, not the system. Screw that guy just trying to do his job, right?
Gotta be careful with that attitude even though it represents some insight.
My understanding is this is how USPS packages with tracking can seem to teleport around the country. They accidentally get scanned for the outbound to somewhere, it gets caught while never leaving the tray, and they scan it back in.
Let's take names. I have diacritics in mine and an appalling number of computer systems can't handle them properly. Should I drop them completely and loose a part of my language in the process? Or deal with more □? firstName + lastName is another, where our idea of naming is forces on to others with a different system.
Dates. The US sets weeks from Sun-Sat and much of US software defaults to it, even when it should know that in my locale Mon-Sun is the default. In some cases I can't even change it. And don't get me started on MM-DD-YYYY.
Processes. Talking to a human is easy. There is leeway. A computer says no. Now I have to conform.
More broadly, we humans do fantastically well with ambiguity. Modelling ambiguity is tricky, after all, computers are extremely fast morons. So that ambiguity gets lost.
A word of caution for highly intelligent but otherwise regular (not well connected) people. The software industry is the most manipulated industry on the planet and in human history. If you work on any significant, high exposure project, be prepared for unimaginable political f***ery.
It's also one of the least meritocratic industries in existence because most big companies have monopolies and can afford to be extremely inefficient when it comes to software development. The bar is mediocre. You just need to rehearse your leetcode to pass the interview; beyond that, you just need to be very good in a tiny area. You will be so highly specialized in the minutiae of your role that basically you will be useless as a software developer. You better hope there exists an equivalent role in a different large company if you want to have any leverage at all in the market. Startups or any business which relies on efficiency and actual skills will not have any use for you...
Still, the biggest problem is just how easy it is for incompetent people to bullshit their way out of anything and the metrics that are used to measure performance are so objectively horrible that it would be better if no metrics existed.
I've been in this industry for over 15 years. Not sheltered by big tech. Careful what company you join because working for the wrong company can be literal hell on earth.
It is clear to me that this industry is still very new and almost nobody knows what they're doing. Most people who lead this industry are not equipped to do so. They just got lucky and now set the rules which are essentially arbitrary and change all the time because they suck.
It's not like Law or Medicine; these industries have existed in various forms for thousands of years and there is a lot of philosophy behind those. It's relatively easy to figure out who is a good lawyer or a good doctor. With software development, it's extremely difficult for people to do because there are many aspects to consider and almost nobody understands which ones are actually important.
Imagine being a really good surgeon with years of experience and a 100% success rate on your surgeries but the hospital fires you because one of your colleagues was jealous and filed a fraudulent complaint claiming that you don't hold your scalpel in the approved way. Without metrics to accurately measure individual performance, everything becomes political hearsay. It becomes all about stupid immaterial things and all the important stuff is ignored.
I hope this saves some people from suffering. I would not recommend this industry if you enjoy coding. There is a non-trivial chance that you will be a life of pain. Especially if you are skilled.
I have met some top engineers who were so bright, passionate and were pioneers in their area and ended up miserable and brought to the edge of insanity. If you don't have deep social connections to this industry or intelligence agencies or other entities that can give you an insider's edge, stay away.
There are many stories about software devs who ended up retiring from Microsoft or other to be goose farmers or similar. These people are not eccentric; they are rational... And these are the lucky ones.
You don't want to know what happens to those who got trapped in this industry, got their passion for coding completely beaten out of them and can't find any off-ramp.
Huh. I enjoy my job at a big tech company. And I enjoy coding. I don't have deep social connections to the industry or intelligence agencies.
In the past I worked at a factory for a short amount of time, and did not enjoy it. I also worked for a short time in academia (basically an internship), and while better than the factory, I didn't like it as much as my current job.
Do you have experience working in big software companies or not ? Is this advice also valid for those refusing to work in big software companies or not ?
(Or is this about monopolies using underhanded tactics to try to shut down high profile projects of their smaller competitors ?)
> You don't want to know what happens to those who got trapped in this industry, got their passion for coding completely beaten out of them and can't find any off-ramp.
Burnout babyy. You lose the joy in life and become a cynical gremlin full of spite. Or develop substance abuse habits or any other myriad coping strategies
Definitely the case. Apologies if my comment is overly negative. I hope the next few decades will be better and that this was rock bottom. In any case, some people have had a great time in this industry even after 2010s but I think a larger amount of people have had a horrible time.
I guess it's not the 80s anymore. Those were the good times.
That this comes with an ugly bouquet full of mental and physical health problems is another topic entirely, and that can fill 10 tomes of books though.
> Imagine being a really good surgeon with years of experience and a 100% success rate on your surgeries but the hospital fires you because one of your colleagues was jealous and filed a fraudulent complaint claiming that you don't hold your scalpel in the approved way.
Are you sure that isn't just imagining green grass on the other side of the river? Politics comes with the humans, not the profession. Occasionally in hospitals it turns out that you are working with literal serial killers too. I doubt those sociopaths would have any particular compunction about murdering a colleague, let alone filing fake complaints.
Learning for the sake of learning, being able to be picky about what to learn, feeling like a god by creating your own worlds, trial and error… these are all traits of programming. On the other hand, software engineering is about sprints, useless deadlines, using the wrong tool for the job, writing code to increase shareholders value, high-performing-team obsession, useless C-level execs, broken tech interviews…
Two different worlds.