When I was young, I really enjoyed programming - but for the sake of creating stuff. I viewed coding as a tool. Means to an end, really.
I wasn't the type that really geeked out on things like editors, programming languages, etc. but I really enjoyed making stuff, that was the fun part. Solving problems with the tools I had.
Then I joined the workforce after Uni., and found out that I didn't really enjoy the process that is called modern software development. I still enjoyed solving problems, but everything around it just didn't vibe with me.
And then there's the competition - I early discovered that I could never outperform my competition. I'm talking about the guys that live and breathe everything CS/SWE related. The guys that will continue to work on hobby projects at home after work, the guys that are extremely invested in every part of the tool-chain, and are passionate about all the stuff I found boring.
Couldn't really see myself transitioning to a manager role either.
So I chose to pursue a domain I find interesting, and become an analyst. Now I can solve problems - which I enjoy to do - and use whatever tools I want.
Coding is fun again, because I can do it fast and half-assed. I'm the only one using the code, and most scripts I write are use-once. Programming is once again just another tool in my toolbox.
The times I actually write more persistent stuff, I can take my time and still have a lot of freedom.
"Modern software development" says a lot. It's the people and more specifically, the rules and processes they make around programming and task allocation that can be really needless and meaningless. Even competition is a human construct.
The most enjoyable form of programming seems to be it's most solitary form. Who would've thought that despite all the doctors saying we're social creatures we'd prefer solitude.
> I'm talking about the guys that live and breathe everything CS/SWE related. The guys that will continue to work on hobby projects at home after work, the guys that are extremely invested in every part of the tool-chain, and are passionate about all the stuff I found boring.
Every trade/craft has these kind of folks. I think it comes from people who like to teach others or have to work closely with others. Things like deep toolchain configuration become table stakes on large or open projects.
>> And then there's the competition - I early discovered that I could never outperform my competition.
100% this. I'm a bit competitive, but only a bit :). After 20 years of being a dev I realised I didn't want to compete anymore and shortly after that I quit as a dev.
I've now switched more into an analyst role and because I've been a dev i think I know what makes a good analyst because I know what I would have to know to write the code - if it were me. But here's the best part, the mark of a good developer is their attention to detail. And attention to detail is also the mark of a good analyst, but as an analyst you don't have to sacrifice yourself to the detail of tool-chains, stacks and frameworks.
Working on large scale problems as a dev, and doing it right, is slow (with a small number of devs) and chaotic with a large number. But as an analyst I can work at the speed of thought, work on many projects simultaneously, and see the fruits of my ideas take shape as the devs start to deliver them and I shepherd them into existence.
So for now I'm pretty happy, I write code in my spare time for fun and like the OP - I'm back where I need to be.
Typically interface with customers/users/stakeholders, identify and document requirements, and...well, beyond that it varies a lot in different orgs, if its not actually coding, and its involved with the process of developing/maintaining software, there's some organization where someone titled as an "analyst" (usually with a prefix like "business", "system", or something) does it,
In most industries, software analysts are a thing of the past. Scrum has largely replaced them, and project managers, with product owners - the people who have to do both of these jobs for a price of one.
> I'm talking about the guys that live and breathe everything CS/SWE related. The guys that will continue to work on hobby projects at home after work, the guys that are extremely invested in every part of the tool-chain, and are passionate about all the stuff I found boring.
Because it’s just absurdly important. I can’t say anything about the projects you’ve worked on, but I can pretty much guarantee that the projects I work on will descend into an immediate free for all without the toolchain.
I realised that as of this year I've been programming in one language or another for 37 years. Right now, if I stopped writing code I wouldn't miss it for a while.
Like you, I think I got into coding because of the same urge that makes me want to build stuff and do bits of DIY. When I was a kid coding was a constructive, creative outlet that didn't require much space or resources other than a computer (a ZX Spectrum in my case), and it didn't make a mess.
Good article, I can relate to it. Just this morning I was thinking, while interviewing an SDE 2 candidate: "how did we ever get here?". By "here" I mean in a situation where it seems that software developers after 3-4 years of experience are forced/coerced/encourage to "influence other orgs", "execute through others", etc. instead of designing systems and writing code.
Every time I get a new team/org, I just tell everyone that I will minimize the meetings and maximize the ability to write code and build stuff. One would think this would make me a popular manager, but feedback is always mixed: more experienced engineers complain that I am taking away their promotion opportunities by de-emphasizing "influencing other orgs". Some leave.
I am also a prolific interviewer, and I have noticed that developers learned the game and are now emphasizing "leadership and alignment" skills vs. actual technical skills. Back then when I started, maybe 1 out of 3 candidates I interviewed were the hacker-oriented engineer who loved solving problems. Now it's maybe 1 in 20 - all the rest are more concerned about showing how they aligned 300 product managers to build a batch job to remind the customer to buy shoes. It's a depressing state of affairs.
It's because the traits that make a good programmer like high introversion and interest in the abstract are exactly the opposite of the traits that allow you to exert influence in a company.
Middle management have wrestled control back from developers with the scrum/agile garbage. That is soul-sucking insofar as you are working a conveyor belt where if anything drops of then you are the problem. SW development has entered the factory automation phase where humans are still doing the "automation". The sooner middle management can replace them with AI the sooner SW developers will be consigned to the dustbin of history. Right now, middle management hates the status quo.
Other way around is possible too. With automation a single developer can build a whole business on their own. Which means they don’t need other developers. Which means they don’t need managers to manage other developers.
As a former middle manager, I would expect my career to disappear if engineers themselves disappeared. Simply implementing features wasn’t the bulk of my job. The bulk was coordinating humans, career development, orchestrating resources, and things like that. AI won’t need any of that.
I think the people that will benefit from a mature AI engineering service will mostly just be the C-level. Below them, you might have a much smaller team of AI operators and validators.
Today's engineers will be the future "middle managers", trying to translate the "specs" they get from up above into actual specs that the AI can process, and then reviewing the code the AI produces (which always looks perfect but may still contain egregious mistakes). Fun times...
I have absolutely zero advice to give, but I absolutely feel the sentiment of “I want to write programs, but I don’t want to be a programmer.”
I walk my dog around the US Capitol a lot, and every time I’m there I find myself wondering if I wouldn’t be happier doing landscaping for the architect of the capitol and writing code as and when I want, how I want, only as a hobby.
I'm reminded of something. There's a Finnish guy on YouTube, goes by Bisqwit. He programs a lot in his spare time and he's a fucking genius. Writes a lot of graphics and 3D code, on old platforms like DOS, that sort of thing. Turns out he drove a truck for a living and programmed in his spare time only. Seemed to be having a blast. Don't know if he's changed careers since, I think he tried programming as a career and switched back to driving a truck or something.
Interesting post. I feel the author has had a fairly unlucky stream of companies and work to come to this conclusion.
I'm in complete opposite situation. Programming is pretty much the only thing I can do and the only thing I'm good at. I'll choose arguing with a compiler any day over people. I don't particularly like people but I love code. Code is reproducible (arguably!), people constantly change their minds.
I hurt myself hanging something on the wall in my bedroom at 16 years old (a long time ago...) My mother laughed at me non stop and she told me "you better be good with computers! Because you are shit at everything else!". That was my career councelling done at 16, thanks mum.
Programming, in a nutshell, saved my life and gave me one.
> I aspire to settle the substantial $65,000 student loan burden that granted me the “privilege” of contributing to someone else’s vision during the conventional 9-to-5 grind.
It's crazy to me that we let people do this to themselves. There's no reason a student should have to take out that much debt for their degree and I'd bet there were probably ways for OP to avoid it if the right people were there to help. Ultimately it's a huge systemic issue in the US but it's also an issue with bad high school guidance counselors not helping students navigate the broken system
Unfortunately many colleges advertise and make it seem like the most experience of your life - but of course after working for 10 years most degrees are worth the same!
I really recommend people to take up niche programming languages (Clojure gets my recommendation) and find work in places where there aren't thousands of applicants per position, because I have found in those places management treats you like a person, like an expert in your field, give you autonomy and respects your opinion. Doing JavaScript when there are 10 thousand other people who could take your job at an instant creates the sort of environment where processes rule everything, managers don't value you because you're just another cog in a machine. Either that or become a consultant. Or best of all, become a consultant in a niche language, like Clojure. I don't know about the U.S, but in EU consultants are usually treated like experts in their field and paid much better than employees.
Depends on the niche language one chooses, I think. But in the case of Clojure, a lot of companies are willing to hire you even without any previous Clojure knowledge, so long as you are otherwise an experienced developer and are interested in learning. Then, once you have some real experience with the niche language, getting new jobs gets much easier with recruiters reaching out to you and more companies opening their doors.
I'd imagine it would be similar for other niche languages, but I can't say for sure. All I know is to try to find a way to be a bit more special in your field as that seems to (in my case at least) result in better treatment.
OP needs to get a different programming job. Writing test code all day sounds horrible. That should maybe be a portion of your job, but not the entire job.
I hope the author discovers that not all companies do software like he describes. It sounds like it is time he starts interviewing the company, too, instead of just letting them interview him. Ask about how the projects are structured, ask how much autonomy a developer has to make decisions about how the code is structure, whether developers have some input on the projects they work on, maybe ignore companies that are "agile".
Another option is contracting, particularly building MVPs. Frequently these are solo projects or small teams. I don't think this is a great choice for someone starting out since you won't get exposed to people who are better than you, but the author has 6 years of experience so that's less of an problem.
> I hope the author discovers that not all companies do software like he describes. It sounds like it is time he starts interviewing the company, too, instead of just letting them interview him. Ask about how the projects are structured, ask how much autonomy a developer has to make decisions about how the code is structure, whether developers have some input on the projects they work on, maybe ignore companies that are "agile".
Protip: Companies will lie through their teeth about stuff like this. "Interviewing the company" sounds all well and good until you consider the power asymmetry: you lie on your part of the interview, you get fired or maybe sued. They lie on their part, unless you can retain a good employment attorney AND they blatantly violated labor laws, the most you can do is quit (and you may not be able to afford to do that).
You can complain about power imbalances and whatnot, but that's helpless cynicism, especially for the developer-types that mostly frequent this forum where the power balance is more even, and maybe even weighted in favor of developers. But power imbalance is irrelevant, the whole point is to figure out a way to determine what it's like to work at the company (which, I suppose, you could argue is tilting any power imbalance back in your favor).
When the interviewers ask if I have any questions, I ask "what's one thing you like about the company, and what's one thing you'd change if you could?" After three or four answers you start to get a picture of the positives and negatives of the company, and it's the individuals' experiences, so they're reasonably candid, albeit you have to read between the lines sometimes.
Seems like the problem is that "programming as a career" often means "waiting". All the process stuff he mentions is (personally) fine with me, it's just that you often have no agency over when it happens. Everything requires permission. Or there's "no budget for it".
This resonates with me a lot. During our most recent sprint planning, our team was given a task that's much larger than we've gotten before and I was asked if I thought we'd have the time for all this extra development work. My answer was yes, we have the time. We've always had the time. Not once have I been bottlenecked by a lack of my own time for writing code, it's always been because we need wait days to get permission and support to do anything.
That's easily one of the worst aspects of the worst jobs I've had. It's rather insulting that these employers refer to you as a sort of "engineer" but don't allow you to engineer anything. Instead, your role is to execute orders while being gaslit that you have the freedom to make the code better. This is a joke when only a select few programmers are given ownership of things. I've heard the word "ownership" thrown around my whole career as a buzz term, but it seems almost no one gets to own anything. Maybe I should have based my career around nepotism instead of skill.
I experienced this a lot doing mainstream programming, but when I switched to niche things (Clojure), I never experienced that anymore. Companies trusted me, gave me (and other engineers) autonomy. Maybe try to look into some niche thing? I was pretty burned out of programming before, but it definitely lit the candle once more.
Also, lots of jobs get posted in the Clojurians Slack channel, as opposed to job boards. Perhaps try to find where the jobs get posted with Elixir, because at least with Clojure it certainly is not LinkedIn or other mainstream job boards. And then, once you find the jobs, don't be afraid to reach out to companies even if you don't have experience. They might just give you a chance! Remember, you no longer have a massive amount of competition with niche languages, so it's highly likely they actually read every CV.
It obviously is the right career for you, because it's granted you a level of privilege that few people experience. It's enabling you to pay off your debt and save up loads of cash which you'll use to retreat to a cabin in the woods. Most people cannot do that. Most people's jobs are not the right job for them, but they do it because they have to, and they live paycheck to paycheck, and they'll never be able to retreat to a cabin in the woods.
It's something I've been thinking about lately. I feel like most of the value and importance of things come when people are doing things they think are worth doing in a way that they think is more or less the right way to do them.
On the one hand, there are many things worth doing that have sub-tasks that aren't particularly "fun", but I think in a fair number of cases people can make peace with those by understanding that they are part of the overall worth-doing task and are part of what it means to do it right.
On the other hand, a huge amount of value is sucked out of our world by "business", which is basically a way to take things that are worth doing and wrap them in money so the actual thing people wanted to do (both as creators and consumers) is muffled and hidden.
Form his videos, he is obviously a skilled programmer, and he seems to enjoy it a lot. And yet, as a day job, he drives a bus. I don't remember the details but it seems to be along the lines of not wanting to think hard doing what others tell him to do. That's why he makes his living with a relatively mindless job, while at the same time actively using his brain on the things he likes, doing them the way he wants to.
I can't really agree with the testing part. I worked with many projects where I came across Issues which definitely could have been prevented by more automatic unit / E2E tests.
I imagine the engineers who wrote the code for the Boeing 737 MAX MCAS or the Tesla engineers who accidentally wrote log files to the internal flash thought the same. Maybe another team member could show the author why these tests are important...
TBF, he does write "I do see the importance in many of the things I just listed [one of them being testing], but they sure do take the fun out of the act". And I, for one, agree with that. Testing is important, but in practice it's often just another dumb metric (e.g. achieving x % code coverage), which however doesn't say anything about whether the tests are actually helpful or just call the code so it's "covered"...
The problem here (in my mind) is that hindsight is 20/20, so you can always look at a bug and say that a test could've prevented it. But in the author's case, it sounds like they still have bugs despite all the tests, so I guess the people writing the tests just aren't very skilled? And if that's the case, couldn't a more skilled engineer just write better code to begin with?
I totally get tests as a way to prevent known incidents from happening again. But tests as a way of preventing unknown issues seems dubious to me.
> But tests as a way of preventing unknown issues seems dubious to me.
True. At my previous job, I used a new C compiler [1] that revealed a bug due to undefined behavior [2]. It was a two-line fix, but my manager at the time refused to accept the fix unless I 1) made a test that showed the error, and 2) write tests to show other instances of this type of bug. The test would have been useless since I used an unsanctioned C compiler, and (due to the nature of the bug) I'm not sure if static analysis would have found the bug anyway.
[1] Test driving the latest Ubuntu Linux installation for development.
[2] The code worked as expected on the business-supported C compilers (it's undefined behavior, anything can happen). Even valgrind didn't catch the error (we were using that at the time) because of the way the code was generated.
The frog on a dissection table approach to software development seems like it is probably a primary cause of incidents involving lost surgical tools in production.
In traditional development you didn't have one organ in a harness, then 3 organs in a harness, etc, having modified them to have no thickness that could hide something from a unit test. That's as different from the functioning frog as the dissected one.
There are endless permutations that are possible in this modern ideal that are all correct for some or all testing purposes, during all test runs, and in every system the average project participant will ever see up close.
They are wrong in production, vastly outnumber correct production configurations, and confuse any discussions about the attempt to port things to production as they are more canonical to the group than production itself.
That's not to say there aren't ways to do this style of multiple test types correctly, only that I think it was done with more care at each level instead of less as layered redundancy needs particular properties or you get holes that all line up, configuration for tests that make it to production, etc.
Computers have been a hobby all my life. I well remember the epiphany I felt while learning Logo in elementary school, at the moment I understood what recursion is. I don't think the fact that the language I have mostly written code in in recent years is Emacs Lisp is unrelated to the above moment.
Yet I have never desired to work as a professional software developer. I majored in history and Spanish in college while working for the university's Unix systems group. My computer skills got me my first job out of college, in an investment bank's tech equity research group; my manager was looking for a CS major but I was able to convince her that I had the equivalent thereof.
I'm glad, for the sake of civilizational and economic progress, that others are able and willing to program for pay. Meanwhile I will continue to putter around with Elisp at home.
Most Agile is glorified middle management.....I have never once seen it do anything to improve an existing productive team or provide measurable benefits....it to not looks that way when you have no structure...because it's better than nothing.
so it works....with mid-level efficiency and tends to push the feel goods up the chain and push the work down the chain..... direction still comes from the top in every attempt regardless of slogans like 'developer engagement' stakeholder management etc.
This is why I transitioned to being a technician early on, and then transition to working on hardware. I still mostly do programming work, but not for (direct) pay.
Very normal realization. Also a healthy one i think. If you enjoy programming on side projects, do it. I stopped chasing fullfilment in my dayjob. Feels good.
Don't tell the internet why you think a job is shit. Tell them why you think some specific alternative career is better. You have a decent chance of hearing from someone who's gone the opposite direction.
I fear AI in that context will be just another computer program that is used to make cost-saving decisions while avoiding accountability.
For example, no promotion again this year? Too bad, your boss's AI tool decided you didn't deserve it, and since your boss is now directly responsible for 1000 people you can't even meet with them to talk about it.
I reinterpret Chomsky
"Students who have such little foresight and so acquire large debts putting themselves through school are unlikely to acquire the capacity to think about changing society. "
The op is complaining about having a cush job. He should try construction, garbage, policing, working in ER, etc.
I've done a couple of those, and there's no such thing as a cush job. My current career is usually done from a comfy desk setup, but it's just as hard as the physical work, in a different way.
Programming can be very challenging mentally and very exhausting. Maybe it's cushier when working on one's own code, but spending day after day untangling messes in corporate codebases is absolutely draining. There are days I wish my work was physical because there'd be something to show for it. Not only is programming difficult, but a hard day's work doesn't clearly deliver value a lot of the time. For instance, I really couldn't tell you what I've built in the last year that brought value to customers. I know I've fixed things... but none of that means anything to anyone who didn't report or fix those issues. They shouldn't have existed in the first place.
I understand you. My buddy’s a general contractor, and he said it feels good to drive down a street and say “I built that house, and put that roof on, and remodeled that one…”
I wouldn’t swap places with him, but I do envy him that.
It's not a cush job. Corporate work can be mentally and emotionally crushing because there's no agency and no reward.
You don't get to see the end product, you don't get to see users enjoying - or not - the end product, and even if that weren't true you still have almost no agency to improve the end product.
Being a doctor in ER can be horrific, but at least you have some control over what's happening [1]. And sometimes people will be really, really grateful.
[1] As long as you don't have to ask insurers to pre-approve anything.
I've got a collection of anecdotes from people who've done both kinds of work. Usually the take is more nuanced. My father did forestry for a while, and said it was less stressful than his later work as a teacher. A friend dropped out of uni to be a gardener. Some other friends worked as cops and thought the worst thing was the shift work.
Meanwhile, construction and ER are said to be awful because of the long hours and awful management, factors they often share with corporate tech jobs.
I've done various manual labor (both skilled and unskilled). I would 100% go back into plumbing if the U.S. had a social safety net.
Have a fulfilling job where you get to see the product of all your hard work at the end of the day? Check. Ability to turn your mind off after work and actually sleep well? Check. Fresh air, sun, exercise, and real camaraderie with your colleagues? Check. No bullshit job manager to micro-manage, gaslight, and make my life hell? Check. Stress? I have never once felt stressed on a job site. I've gotten pissed off at dumbasses who've given me injuries, but it's not chronic, low-grade anxiety that permeates into my entire life like software engineering.
Main problem is the healthcare isn't guaranteed. So if I fuck up my body, my career is over, and so is my access to medicine (and so is my ability to have a roof over my head!). Have fun with your 4 week wait-times (just for a consult) and "large jobs" only for any sort of tradesman! The problem is only going to get worse.
No one with good foresight goes into the trades unless their family owns a business and is trying to hand it off to them -- or their family is in a union and are guaranteeing them a spot (don't do non-union).
Ironically, the people usually going on about how "tough" certain jobs are have never done them for any extended period of time. It tends to give you a certain humility, that at the end of the day we're all just trying to stay alive, and no better than another. Shocking how shedding sweat with a recovered meth addict just out of jail will give you some empathy for your fellow man; while working in an alienating and cut-throat environment will turn you into a psychopath just to survive.
I wasn't the type that really geeked out on things like editors, programming languages, etc. but I really enjoyed making stuff, that was the fun part. Solving problems with the tools I had.
Then I joined the workforce after Uni., and found out that I didn't really enjoy the process that is called modern software development. I still enjoyed solving problems, but everything around it just didn't vibe with me.
And then there's the competition - I early discovered that I could never outperform my competition. I'm talking about the guys that live and breathe everything CS/SWE related. The guys that will continue to work on hobby projects at home after work, the guys that are extremely invested in every part of the tool-chain, and are passionate about all the stuff I found boring.
Couldn't really see myself transitioning to a manager role either.
So I chose to pursue a domain I find interesting, and become an analyst. Now I can solve problems - which I enjoy to do - and use whatever tools I want.
Coding is fun again, because I can do it fast and half-assed. I'm the only one using the code, and most scripts I write are use-once. Programming is once again just another tool in my toolbox.
The times I actually write more persistent stuff, I can take my time and still have a lot of freedom.