I remember the days I started coding, and how much I enjoyed that. I was able to create things with just the power of my thoughts, and it felt like a superpower.
Nowadays, I feel like I have to jump so many hoops and spend so much mental bandwidth just to get the permission to code. It would be fair to say that on avg I spend less than 20% of my time coding or solving problems.
Any project I work on is connected to a million different tools, workflows and services, that all do things their own way, and everything lives in a totally different place, where it’s hard to monitor what’s going on.
I feel like anything can break at any moment and ruin my day. I don’t understand any of the tools well enough to be confident that it’s stable, and the worst problems are the silent ones. This is giving me anxiety.
I work mostly with Javascript — and that doesn’t help. All the frameworks/libs I use insist on being too flexible, to the point where I don’t know where to start and how to do things. Just show me the “right” way, and let me figure out how to opt out if I want to. Oh and every 10 minutes there is a new tool that pops up that does things differently.
I wish I could go back to the days where I spent most of my day in the IDE and at the end produce something that was (to me) amazing. My most challenging moments were when I had a tough logic problem to solve — but I enjoyed those immensely. I’d rather fight with my brain than with the tools I use.
I wish I could just use an IDE that takes care of all the crap for me and just lets me code and write business logic.
I now understand why there’s a trend of developers who want to go live in a farm or take up woodworking: tough(er) problems, but with less variables & easier to reason about. If the wood breaks, you can see where and can probably guess why. Making a table is a mostly linear set of steps, and the basic tools you use don’t change much throughout the years. There is no invisible ghost that lives in a separate realm (dev environment) that can ruin your work at any time and leave no trace.
Any insights? Should I just switch careers?
My wife's dev environment VMs are 'remediated' at 8pm regardless if she's using them or not - there is no override policy - and the company is singing the success story of saving 40 dollars in licensing.
At another corporation, it can take several weeks to learn how to fill out the IAM role and permission boundaries to allow a new app to run - and a governance board has to review it and allow it.
We have weaponized Agile and Scrum - loathsome coworkers will write stories to write stories. Upper management is pushing us to mark "out of office" one day a week, but to then work through it, due to superfluous meetings dragging the productivity down.
A 4000 dollar, maxed out macbook pro boots up directly into a load average of 20.00 and upwards, as antivirus software scrubs every interaction and files open and even at rest deep on the SSD disk. Teams videos run at 3 FPS and lag constantly, making one look like they dont understand the conversation.
All of this, to dabble in code, the thing we're passionate to do, to try and help these places exist.
I didn't fall out of love with coding. I love it deeply, but there's an abusive guardian at the front door with a shotgun, oblivious that I'm here to help
Every profession needs to have some processes in place to make things run smoothly, but when the processes themselves get in the way instead of helping; then the tail is wagging the dog.
It is kind of like free TV shows. We always understood that commercials were necessary to pay the bills when we were not, but now many shows are completely unwatchable as 60% or more of the time spent in commercials.
I had no idea such a thing even existed. Sure, there's a schedule to appointments and you can't just take all the doctor's time, but I had never ever heard of anything like that. As if at 15:01 into the examination, we'd both turn into pumpkins or something. Or the idea that really any health problem someone had could be observed, diagnosed, and treated in a quarter hour.
Turns out that the hospital system she worked in had been aquired by nameless-faceless-health-conglomerate, and that's how they (and many other) hospitals worked now. Everything was KPIs, everything was maximizing people-in-and-out every day.
When I asked the doctor how she felt about it she obviously tried to be as democratic as possible about voicing her displeasure at the new system. Annnnnnd about 6 months after that, she transferred to working at a senior living facility where she just gets to chat with elderly people all day, refill their prescriptions, and make sure they stay healthy.
I was reading research on this recently because I’m working on an EHR software. The cited study concluded that physicians spend about 15% of their time face-to-face with patients and about 17% filling out documentation. For interns it’s worse with 11% time with patients and 22% writing things down.
This was in Principles of Health Interoperability, a book from ~2016.
On the bright side, all this documentation has been shown to literally save lives. Not sure it’s doing as much for us coders.
I distinctly remember thinking in 2014 there was no way the respective app stores were going to get worse. By far my worst professional prediction.
In the end, I'm glad we deployed this.
Not shutting down my machine saves me 2-5 minutes probably. Which seems like it might be worth a few pennies, but I hate the waste and environmental costs of wasted energy.
What we really need is a program that shuts off a devs environment, but then can boot it back up 5 minutes before they start working and somehow open all the applications that were running back to the exact state they were in before shutting down..
Add in that management will make commitments to customers without having any idea what it will take to execute, schedule 20 hours of meetings per week, expect us to work a total of 60-80 hours a week to meet the arbitrary schedule, and also change priorities seemingly at random based on which customer is making the most noise.
The best part is HR regularly talks about how we are a certified great place to work with amazing work life balance.
I'd quit but equity...
From what I've seen, those golden handcuffs are usually gold-plated handcuffs with the same steel underneath.
Have had this problem so much. The problem is managers and analysts are productive through meetings.
Software Engineers are productive in blocks of 4-6 hours of focused concentration. Many managers don't realize this and forward FYI meeting invites to developers all day long.
All of the bizarre decisions by higher-ups--red tape, bad hiring, conflicting goals, ridiculous security policies--it all boils down to "what do we report on the financials, and how can we manipulate investors to continue to buy and hold"? It doesn't even matter what's actually profitable, just what's perceived as increasing real or potential share values by the actors in the market.
The premise ignores the layers of people in-between the 'C' levels trying to get that return, and the engineers trying to build stuff. It seems lots of these people are mostly interested in politicking and justifying their position. (which I think accounts for some of the WFH resistance. If people can get stuff done with less supervision, it might lead to less managers :-P )
Related, distantly:
"The secret to success in the stock market is not predicting which stocks will appreciate but rather anticipating which stocks most investors believe will increase in price."
—John Maynard Keynes, who in addition to writing foundational economic texts became rich as a result of astute investments in the stock market
There are of course management problems, but that happens in every field. Software isn't special in that regard. My issue with software is that, in general, the software industry is both myopic, clinging to some bygone coding aesthetic of the 80s, and discontented, constantly creating new stuff or wanting to complicate stacks.
Just look at the current status quo of source code management in Git. Management didn't make that decision. Software engineers did. Git is the most overly complicated software ever for its purpose, but it was software engineers who chose it as the standard and decided everyone needed to code as if they're on the Linux kernel team.
Sorry, but I call bullshit on this.
Git has a lot of features. Most people probably don't use or need most of those features. Maybe it's like Microsoft Word, where the quip is that people only use 20% of the features, but it's a different 20% for each person. That's not relevant.
What is relevant is that to use Git effectively for most projects you don't need to know that much, you don't need to get into the "advanced" features, and in fact can learn everything you do need to know by reading only the first 3 chapters of the manual, and knowledge of the "git flow" workflow (you can of course modify this to your needs).
It is not harder to effectively version control your software with Git as compared to any other VCS/SCM I've used and, in fact, branching and merging is excellent, and makes life a lot easier for everyone involved. Pull requests also make life very easy as compared to other systems.
Switching to Git, within a few days it was apparent to me that it was better and easier than CVS, SourceSafe (!), Subversion, Sourcegear Vault, Perforce, and AccuRev (I can't speak to others because I haven't been exposed to them).
Of course, you can make Git complicated - or perhaps I should say more complicated than you need to for your use case - but that's optional and entirely on you (or other devs you work with - in either case, Git isn't your problem).
However what's wrong about Git for code? How would you cover the same features differently? When I say "Git" I refer to all the ecosystem that's based on Git, including GUIs for those who don't like the command line
The issue with places like that is that risk is prioritised higher than delivery speed, which is arguably fair enough when there is a risk of large regulatory scrutiny and reputational risk.
They are also set up to scale to thousands of engineers, so need consistency in technologies, reporting and ways of working.
I didn't enjoy working in that environment, but I have more empathy nowadays for why they have to work in that way.
Work for a smaller company or startup, and all of that stuff goes away.
I don't think most organisations actually make such decisions knowingly.
I don't believe the CEO ever says "This endpoint management system will remove 20 minutes of productivity per person per day, but it's worth it, let's deploy it"
More likely the organisation salami-sliced away productivity 2 minutes at a time, the bosses have don't see the problem because they use macbooks, and the endpoint management team all love endpoint management so they ignore the problem.
My kid takes the school bus to school. The bus is often late making my kid late. Mind you, my kid is at the bus stop an hour before school starts and school is only a 10 minute drive away. When this happens, my kid gets marked tardy and after 3, she gets a referral, even though it was the school that was responsible for her getting there on time. When she asked why, the response was, "it's policy."
Personally, I made the choice to join big tech and collect a bigger check. The work can be slow and boring, but it's a conscious tradeoff I am making - money instead of fun.
Customer wants to see: Yes, Company X has Y anti-virus product on all devices.
I'm not a professional programmer, and when my laptop takes 10 minutes to start moving the mouse cursor smoothly after waking from a weekend suspend (today!), I'm pointing fingers at you all, the professional "dabblers" who don't understand computers, don't understand firewalls, don't understand databases, don't understand algorithms, don't understand garbage collectors, don't understand or care about any kind of security or legal compliance regulations, don't optimise anything, don't want any constraints, any meetings, any plans, any accountability, just want to 'optimise developer productivity' where you play with the most fun framework of the day and millions of users suffer the consequences of it.
"Developers" have only "developers" to blame for how software takes down a 1,000,000 IOPS SSD to the point of complete machine unresponsiveness. It's not 'Jira' or 'stories' or 'weaponised Agile' or 'Indian outsourcers' or 'management' doing that.
Maybe instead of seeing it as red tape garrotting you or an abusive guardian at the front door with a shotgun, see it as end users with scowls their hired heavies at the door, end users wanting their computers back from your code, wanting their data back from your clutches, wanting their time back from your advertising, wanting their lives back from your industry's overreach. People who've had enough of the priority always being your comfort and convenience. People who've had to bring in the security heavies with their legal and compliance regulation to try and herd you because left to yourselves you leave SQL injection and plain text secrets and cross site scripting and logging libraries that can talk to the internet and execute arbitrary code and when told to get your act together, throw your toys out of the pram and want dynamic languages and moving fast and breaking things because anything else is too boring.
Hobbyists can be dabblers, end users can be dabblers, people who get their job done in VBA and Excel or a Perl script copied from the web, or IFTTT, you aren't "here to help", you're here to laugh at them for using VBA and Windows and offer them a worthless meta-interpreter in LISP or a workflow from the 1970s. People are crying out for help and all they get from professional developers is scorn of business apps and CRUD software and yet another text editor and whining that it doesn't work on Linux. End users are not interested in whether Java has type erasure in its generics, or whether the BEAM VM is outdated or whether TypeScript is an improvement on JavaScript, they're interested in how to share a spreadsheet with a supplier in another company and why search never returns what they typed in, and why their phone can't respond to the 'answer call' button before the caller hangs up.
As 'Uncle' Bob Martin said in a talk in some recent year, if the software development industry can't sort this out itself, if it can't fix the Boeing 747 Max and the cars on the road being exploitable over their cellular connections through the infotainment system to disable the brakes and cut the engine, if it can't fix the senator's private emails being leaked, or the shareholders being hit by a company taken out for a week by ransomware, it can expect governments to implement laws regulating software development, and those laws will be overreaching, uninformed, out of touch, hard work, no-fun, and mandatory.
Apologies for not reading your comment fully, but in this specific instance it's because a weekend suspend causes hibernation, which means all your RAM is saved to the disk. The file can be pretty large (same as your RAM, say 32GB) but reading it fully takes much longer (at 200MB/s it's three minutes). In order to wake up your computer quicker (a few seconds), instead of reading it fully to RAM, the memory is read on demand, i.e. when a process needs it. This comes at the cost of keeping your computer lagging for the next few minutes. This is just one of many many small engineering quirks that makes up an operating system. However considerate the developers work, tradeoffs have to be made here or there. You can't power off the computer and expect to restore its state fully within 5 seconds.
> the professional "dabblers" who don't understand computers, don't understand firewalls, don't understand databases, don't understand algorithms, don't understand garbage collectors, don't understand or care about any kind of security or legal compliance regulations
A single code base consists of many parts independently written by developers of all fields. There are CPU people, networking people, disk people, kernel people, compiler people, cryptography people, etc. And there are things that are simply not possible even if they work their best. There are developers that focus on making the operating system as safe and stable as possible, but they build aircrafts, cars, rockets and household applicances, which (from a software development perspective) are far less powerful than regular computers.
That said, the community of developers is indeed very bloated and there is no need for so many of them. We just haven't found a way to distribute money to that small set of necessary developers without compensating everyone else and bloating the company to keep talents away from competitors.
For most of the past decade, the true cost of "developer productivity" was borne by the users of their software in wasted time, wasted electricity, and money thrown after buggy or nonfunctional features.
At this point in the aviation industry's lifecycle, we had gone from learning that flying was possible to landing on the moon. If software had followed the same trajectory, we'd have AI servants right now. But programmers insist on re-creating the wheel every few years, so instead we just get new frameworks and languages that do what the existing frameworks and languages do, and a whole lot of new bugs as programmers race to adopt the hot new thing.
I wish you were right because it can be fixed by looking at developers but its the entire snake oil industry of deciding what to do that is the problem
I've worked with some very ignorant, lazy, incompetent, individuals. Some had 'programmer' or 'developer' in their title, others were managers or product owners or QA, etc. etc.
I do agree with your last point. I expect the real-world consequences of Bad Software to become more serious and common, and that will result in more regulation of the industry.
You know, this I never quite understood - why not provide example repos that follow all of the best practices? After all, the majority of the apps will be quite similar in their architectures and technologies (at least in some enterprises, e.g. "a Java shop" or something like that), so surely one can create some templates or snippets to work with.
Having templates is useful though so you know what you need to define for your policies inside your boundaries.
The core fundamentals that make development enjoyable and sustainable are being ripped away from us, insidiously.
They tend to be people who couldn't cut it as actual engineers, and so they end up in administrative roles, the ones that OP lambasted as writing stories to write stories, and causing more work, because they need things explained to them slowly and with crayons, and that takes more time, because the engineers just want to be left alone meanwhile the PM gets yelled at by customers, and decides to side with the customers and is just one more person yelling at the devs.
What does remediated means in this context?
Try working on something fun on the side. Make a game, or a mobile app, or something you’ve always been curious about that doesn’t have anything to do with your job. You might be amazed by how productive you feel when you work on something ambitious that doesn’t involve all of the corporate machinery.
I’ve been getting a nice dose of that with game development. Sometimes I sit down on a Saturday with a big plan that should last me through the weekend, and I get it done before dinner that evening, and I feel like some kind of programming wizard. It’s been a great reminder that I am a talented programmer, but I’m just feeling burned out on all of the tedious process that’s involved when coding professionally.
I ask as a matter of curiosity and personal interest--it's something I'd like to learn as a hobbyist, but my knowledge is limited to simple OpenGL tutorials and the (relatively speaking) watered-down Graphics course I took in College years back.
Unfortunately, many managers are bad at giving positive feedback. The only time you hear from them is when something isn’t working. Corporate processes slow things down and make you feel ineffective. Eventually you start to wonder if you’re actually bad at software development, or if you’re just a bad worker.
Let’s say you get a ticket for a performance problem. It turns out that the app is doing something kind of silly, and it would be easy to fix the problem and you’re confident that users would be okay with it. Well, too bad. You’re not allowed to make product decisions; only management can do that. So you bring it to management, but they’re in a meeting. You don’t have enough time to do anything else, so you spend 15 minutes reading HN.
They get out of the meeting, and you explain the problem. They’re okay with the change, but because it affects the UI, you need to get approval from the UX team. You explain that it’s a very minor change, but management insists that you have to follow the process.
You go to UX. You explain the problem, but they don’t have time to get back to you. You figure it’s going to be a bit, so you grab another ticket. 20 minutes later, it turns out that they’ve approved your request. It was a very small change, after all. So now you have to put your ticket back, which is going to mess with the time tracking in Jira that your boss gets pissy about, but whatever.
You make the change, which takes about 5 minutes. You commit, push, and open a PR. The CI tests fail. Apparently there was some kind of silly linter error, so you fix that and push again. Now you wait for the tests to pass, which takes about 40 minutes.
The QA team requires a detailed set of instructions for how to test every ticket, so you start writing up those instructions in the Jira ticket. As that’s happening, you get a Slack message from the documentation team. They noticed your ticket status change, and you forgot to mark it as requiring doc review because it affected the UI. You apologize and go back to update the ticket.
When you’re done updating the ticket, you notice the build has failed. Looks like a flakey test that’s been a problem for months now, but no one ever gets time to fix it. You re-run the tests and cross your fingers.
Time for a sprint planning meeting. Two hours later you resume work. The build passed, but your irritatingly picky co-worker has requested a change on your PR. He always requests at least one change on every PR, no matter how small. You used this method to find an element in an array, and while there’s nothing wrong with that, he personally prefers that method for doing it, and he won’t approve your PR until you change it.
So you update the branch and push again. Then you start working on filling out information for the compliance team which is needed for anything affecting this part of the application. You wrap that up and notice that the flakey test failed again. Swearing under your breath, you re-run the build.
You spend some time reviewing PRs for your co-workers and see that your build passed and your picky co-worker approved the changes. You merge and move onto something new. A few minutes later you get a message from the QA team. You didn’t provide documentation for how to test the code. You remember that you were in the middle of writing it when you got interrupted, and you forgot. You apologize and finish writing it.
You look at your watch and realize that it’s the end of the day. You know your boss is going to be irritated with you after standup tomorrow because you spent all day working on a ticket that was only estimated for half a day.
This is the kind of stuff that makes me want to run away from software development and never return. It’s not the code; it turns out that after all these years I still love programming. It’s all of the soul crushing BS that makes me lose the will to live.
And so far, the antidote for that has been to work on something with zero red tape where I have full autonomy. It reminds me that I’m actually very good at software development.
Key thing is to make small game projects that you aim to finish in well under a year. Once you embark on a big project and feature creep sets in, you’re back to avoiding programming.
1. install ftp/sourcesafe
2. connect to url and authenticate
3. edit button
4. upload
2023: edit html button
1. install git
2. setup git credentials in terminal
3. setup git ssh key in terminal and browsers
4. use internal bootstrap tool to install node
5. macos no longer supports bash, spend 10 mins switching everything to zsh
6. install npm
7. try to clone and install the code with npm i
8. 20 different node js errors, deprecation and dependency warnings
9. embark on a bunch of side missions to resolve all the node issues
10. try to start local environment
11. local requires docker
12. install docker
13. docker requires sudo permission
14. request sudo from IT
15. fill an IT form explaining why you need sudo
16. get lectured by condescending IT dweeb about how you're being monitored and to use sudo ONLY for approved things, have to try drag in manager to explain why sudo is needed
17. finally install docker (requires a giga f*ckton of ram to run and slows down your machine)
18. start the local environment
19. docker starts installing a bunch of crap and updating
20. try to edit the html button
21. the local server not refreshing or your change is not reflecting
22. turns out this repo is just for the button only, to update the copy requires another f*king repo (go back to step 7)
23. finally done, try to commit changes
24. your changes are 10 commits behind the branch
25. try to merge automatically, cannot be merged
26. make a PR
27. smug know it all "senior" developer with 2 years experience, gives a bunch of nitpicky comments on the PR and refuses to merge it
28. stare into the abyss
If setting up your environment requires all this, your environment is too complicated. But unfortunately, many production projects require environments this complicated.
You've realized that your work is stripped of many elements of creativity in the name of making you replaceable. Of course, we can't say that last part, so we instead talk up how great tooling is, and how quickly we can onboard people (Nobody asks why there is such a need to onboard people so often, or so quickly.)
When your pursuit of mastery is thwarted by guardrails everywhere, you're not going to feel like you're progressing. And people have to feel like they're pursuing mastery.
To move forward here, you need to think hard about what you want from a job. It goes beyond just "being able to use my brain and an IDE to solve problems." What domain are you interested in? What type of stack would you like to work on? What would your ideal day look like? What type of people are your coworkers like? What markets do you want to serve?
I made a similar leap in 2012. I ditched webdev because I determined the culture at large to be toxic to the craft of engineering. Started self-teaching myself compilers because it seemed far enough from webdev that I wouldn't get sucked back in. 10 years later, doing similar stuff still. 10/10, can recommend. Now contemplating specializing in another domain to spice things up again.
If your career is made to be safe and as similar to everyone else, it is much harder to gain leverage.
You can't trust capital to take care of you.
Bureaucratization (aka "bullshit jobs") is the inevitable result of organizational psychology and risk aversion.
More participants -> more coordination overhead -> more fallacies (groupthink, sunk costs, myopia, etc) -> delay, overruns, and failure.
> Started self-teaching myself compilers...
Fewer "stakeholders", more autonomy, less need for permission.
How do you get in? Basically any domain that’s not just enterprise line of business crap, and SaaS apps seems to only ever hire seniors/staff/whatever developers with 10 years of of hyper-specific domain knowledge or new grads they managed to source a [State University] Recruiting Event. Hell I’ve been rejected in otherwise normal web dev jobs here recently because I didn’t have experience in a specific domain.
I mean I can teach myself lots of things, but that doesn’t mean that I’ll just be able to waltz into a job.
It's hard and partially driven by forces outside of your control. All you can do is be as ready as possible when something comes along.
Very good point
I was just skimming and read that, and I thought "he is working in Javascript" and yep, later on that's it.
I stay away from the Javascript/TS ecosystem (npm et al). I program mostly in Go, but also quite a bit in Typescript.
I would learn/use (even if for personal projects) more boring tech stacks, like Java/C#/Go/PL-SQL/T-SQL. For myself, Go has extremely stable tools that just work and have well-known limitations. Consider a lateral move within tech.
I like typescript, I've tried Deno but it's just insane to me how people get caught up in all the hype around the NPM ecosystem only to end up crashing into walls like 'entire system shutting down' with no idea how to fix it. Friend who came before me hit me up asking about a 'linux problem' and it was just webpack crashing his entire computer with semaphore exhaustion. I keep that stuff confined to where it was spawned from, in the browser, anywhere else just doesn't feel sane to me.
This feeling is absent from React-based apps. The React eco system has been around for many years now, but is missing many of the advantages age typically brings. The eco system feels much more fragile and driven by hype. I simply don't trust things to work as smoothly. Maybe this instability is what keeps React popular? If it becomes more stable, it will not generate as much hype and developers move to the next big thing.
As you point out, the React ecosystem does seem to be mired in "what approach should I take"-style questions for basic things like data loading, routing, etc.
I used Spring Boot at work and I have worked with backend libraries like Express(JS), Flask(Python), Gin(go) all the experiences have been much better than using Spring Boot. Java takes too long to compile, dependecy injection in Spring just seems to take forever, and overall Java is very very verbose. Just to create a stupid API, you have to create a new class for request, one for response, controller, service. I can do it if I am paid for it but using that for side projects, a big NO.
I tried to do side projects with Spring Boot and I also worked with it professionally. I never got to the point where I can focus on just solving problems, I'm always fighting with the framework, looking for how to do certain things in the depths of blogs and stackoverflow because I can never find what I need in Spring docs. I actually find it interesting how some people seem to be very productive with it, while others have issues similar to mine.
I rely on the TS compiler to bundle into a single JS file, so I avoid bundler (etc).
I build a simple framework that meets my needs that I can essentially vendor and keep in my head. I'm would love to use an established framework rather then my own (don't get me wrong, there are serious downsides to rolling my own), but it must be small enough I can read it easily in a single sitting. I will not touch the NPM ecosystem. I sometimes will pull a dependency in by manually copying in the parts I need (preserving licenses, etc).
There are real downsides to doing what I do, but I do it to keep myself sane. I do not touch the npm ecosystem.
I also review every line of code I pull in from any language (Go, TS, etc). An ecosystem that makes this difficult or impossible is just a non-starter.
IMO JS is really fun to program this way. You program straight to the capabilities of the browser. All of the problems people promised I'd face by avoiding their framework of choice didn't show up after all.
That's when I started experimenting with Elm, Bucklescript (now ReScript) and Clojurescript. It was a very insightful journey that made me enjoy frontend development again.
Today, Clojurescript is my favorite method of working with frontend code and, as long as I can pick my own tools, that's the one I'm sticking with.
For those suffering of Javascript fatigue, I highly recommend playing around with these alternatives. Try doing a simple, small side project in them. It may reignite your joy for programing and who knows, maybe you can find a job to work full-time with these tools.
I use vanilla JS & CSS wherever possible, usually in a Go template.
If I have to create a SPA then I use Vue - I've found it's the least complex of the front-end frameworks. I build it using ESBuild from the flat JS files downloaded from the Vue site and stay as far from yarn/npm as possible.
I'm trying to work out how to compile Go to WASM and manipulate the DOM easily from there, but so far it's more complex than just writing JS.
For example the mentioned Go has a HTML templating package in the std library.
You could use something like htmx (the creator is a regular on here) which is a very small, very convenient library that gets you 80% of the way for your typical web application.
For the rest, you can always just stick with plain old DOM manipulation or write web components if you want something that's more re-usable and general. No build step or transpilation shenanigans required here.
I've made a career writing Django apps. In most cases, the JS I write is limited to vanilla JS with no JS dependencies (the minification is done by a Python library which might depend on JS, but it's abstracted away enough that I don't have to know). There needs to be a serious amount of justification to even install Node/NPM as part of a project.
The vast majority of work is done on the backend, with JS only being used for UX. I used to pull in React+ReactDOM on some projects, but Web components are paving the way for that to no longer be necessary.
As I mentioned elsewhere, it's possible to pull all of pip into a Python project and have all the same problems, but the culture around Python isn't quite as myopic as the JS community, so I've generally been able to keep dependencies more sparse when working on Python teams.
Yes, most jobs are filled with corporate drudgery. Business doesn't generally require tough (technical) problems to be solved. The point of business is always to make money by serving the customer.
You need to find a way to thrive in that environment otherwise you'll just drown.
I work on boring-ass bank payment stuff. I spend my days writing google docs and convincing PMs that their ideas are totally out of whack and hold their hands as I explain how things need to be done to not code ourselves into a corner. I barely code and when I do it's mostly some stupid API calls and shoving that from one DB to another.
Instead I look at my job as a way to make loads of money and get better at my social skills, and outside of work I do the hard cool technical work I want to do.
And I am able to do that because I really, really want to code. I don't waste time on social media, games, etc. Coding is more fulfilling than that for me so I do that instead.
If you can find a job that lines up with your interests, great! Go for it! But there's no ideal job and there will always be stupid work that someone needs to do.
As someone told me early in my career: different company, same shit
This was my previous job… sort of. It paid well enough that I was going to use it to ultimately save enough money to get out and pursue other things.
But then I got laid off. And now the market is looking so destitute, and the money looks like it will dry up for people like me. Without the money there’s nothing to keep me around except for the fact that it’s too late to do something else (at least anything worth doing).
I never even planned to go into software development as a career, definitely not initially. It just happened to be a good ticket for a young uneducated person who needed to pay rent, and had hacked around a lot in the past.
First, the market sucks at the moment but there’s no reason the money will dry up for you. Keep your skills up, practice for the interviews and you’ll be good.
Don’t get into this mindset that it’s too late to do something worth doing. The only time it’s too late is when you’re dead. Do you really wanna go through life with this kind of self-pity? Who the heck cares if could’ve done something different earlier? You already spent those life years and you ain’t getting them back. The only way is forward.
If you were good enough to get a well paying job, you’re definitely good enough to grind till you get where you want to be.
My next piece of advice is to stop thinking you’ll be able to save enough to quit and do something else. You won’t. The situation will never be ideal and you’ll just have to commit and do it.
Sure build some cushion, ideally use the money you save to generate you some income (e.g., buy a rental property), but you’ll still have to make the jump.
The only way you’ll make it is by believing you can do it in the first place.
1. If you're severely burned out take some time off, as much as you can. A few weeks would be nice but a month or more would be even better. I've found that after spending the first few days (or even the first entire week) being a sloth on the couch I'll begin desiring to program again. Working on personal projects or just learning something new without worrying about work often helps me out of these valleys you're describing.
2. If you're moderately burnt out you may want to consider joining a smaller company or startup. The need for code is much greater and the agency you get at a smaller company is incredible. No need to ask for permission, they want you to code.
3. Finally if you're not quite burned out or if switching to a new company is not an option I'd honestly recommend reading some books like Peopleware, Mythical Man Month, Coders at Work and others. This will give you some respite as what you're experiencing is not uncommon. Learning how others have experienced what you're experiencing and how they push back or fight against cruft like this will embolden you to hopefully make change within and push back intelligently.
I hope you feel better and that the joy of coding comes back. And if it doesn't I hope you ultimately find happiness, wherever that may be.
Our company was hired to take on a project that was failing. It was an order export and update system between a website and an ERP system, neither to be named for the obvious reasons, and of fairly significant mismatch between the data in the two systems.
It started with some visual tools for the data flow, got a shit-ton of node and random libraries piled on, running on a hosted service with a deployment system for faster updates cause it broke constantly. It lost data 5% of the time or just failed to export the orders. It was shuffled around to different groups which changed up how it worked.
If I had to work on it I'd have quit. Instead I rewrote in 3 days in .NET Core C# as a console app running on a schedule using Json.net, XElement and hand written transforms and it was fun. Copied it up, got it running, buffed off a handful of rough edges for about 2 more days of work and it's been running fine since. No updates needed no data or orders lost.
My point? Reject all that shit that is just bad languages and bad systems and poor choices. Do it with what makes you and the client happy. Clients don't care what it's written in the just want it to work. So choose what you like and gets the job done and lets you move onto the next fun thing. If you don't enjoy your work you're trading your life for money.
5 years ago I started https://github.com/akalenuk/wordsandbuttons to focus on interactive writing. Just text and JavaScript to make interactive illustrations. There are no dependencies in principle. Nor external, neither external. Only text and code. Tons of fun, no red tape.
You might think that this works for small projects only. Well, there are more than 50 interactive pages now (would have been more, but I spent 1.5 years writing a book), and things haven't started to fall apart yet.
I strongly advice vanilla programming for hobby. JavaScript or not.
I left programming as a career, and now use it in support of the website I run. I went from dreading going to work to skipping meals because I can't lift my hands from the keyboard. The passion came back, and it's stronger than ever.
You know what's fun? Just building stuff on our own terms, and going outside when the cafeine wears out. I overengineer or hack together as I goddamn please, and boy howdy does it feel like a million bucks.
Get rid of Agile, meetings, red tape and fixed work hours, and I guarantee you that you'll feel the magic again. But ditch programming and keep every other part of the job, and you'll hate it just the same.
But I *hate* work, for all the reasons you and others in this thread have mentioned. Recently it's gotten bad enough that I dread getting out of bed in the morning--but I still love getting off work and being able to hack on my side project. I'm constantly being exposed to advice on HN and the like that entrepreneurship isn't for everyone, but goddamn if it still doesn't seem like the best thing in the world to me. I don't need a huge salary or even great work-life balance (at this stage of my life, anyway), but I definitely do feel the need to work on something I actually give a shit about and have that freedom of owning the product myself.
You certainly seem to be in a rut, but before you take up woodworking or glassblowing try branching out and do some programming in a totally different area. This could lead to a change of career focus but you would have to start in a part-time/hobby way. I can't make any concrete suggestions since I don't know you or your circumstances, but make radical changes. Choose a new language, get into a totally different programming area, think of your own projects where you have total control.
Personally, I work in the scientific area doing a lot of varied work including visualization. I have an embedded programming hobby in the Arduino world using C/C++. I have been making measuring instruments for ham radio but currently I'm in the middle of three clock projects. All of them are designed to JUST WORK™. They guess the current timezone, take time from the internet and try to handle daylight savings changes automatically. Configuration, to set access point and password, is done through a web server that runs on the clock acting as an access point. I cut acrylic cases for them and they are good enough to make nice gifts. It's very satisfying to take a project from the back of the envelope through to completion, and it appears that is something you are missing.
I recommend trying Swift/iOS/macOS development. No more editor or framework hopping or megatrees of unmaintained dependencies spewing dependabot hell. You will be using Xcode with Apple's APIs to build exciting things that often weren't possible with web tech alone. SwiftUI is easy to learn if you know React. The skills are in demand. The Swift/iOS communities are mature and supportive. Apple's hardware isn't going to become less interesting or less popular any time soon (Apple VR/AR products are on the horizon). Swift is a very nice language; much more fun to use than JS/TS.
Downsides are ecosystem lock-in, general lack of openness when you run into bugs with Apple's APIs, having Apple as a gatekeeper between you and your customers, and not being able to use latest Swift language features or APIs due to minimum OS versions, but if you're prepared for all of that it's a satisfying ecosystem to work in.
Others here are recommending backend, but having been in a similar position to you I get the feeling you might not love it. Large modern backend services are often just as over-engineered and prone to cargo-culting as frontend. You will likely spend more time writing YAML than you feel you have the emotional energy for. The cloud certificate courses people will send you on will feel like sales and marketing systems designed to lock you into building end-to-end solutions with a provider's stack; not satisfying education that promotes personal growth. You will probably have to be on-call, which is not as common for frontend or mobile/Swift devs. By all means explore it, but I'd be a little more careful on that path.
Good places to start are:
https://exercism.org/tracks/swift to learn Swift.
https://www.hackingwithswift.com/100/swiftui to learn SwiftUI.
I realize that many of the practices of the past either won't scale or are not sufficiently secure but I sure do miss the days of, for one example, builds and deploys being simple things that anyone could reason about and accomplish in a matter of minutes (with maybe an easy to learn tool that helped automate even those simple things).
Now we have tools that require domain experts to configure and manage effectively, processes that are arcane and convoluted, services that are so flexible and abstract that you can't easily determine how to use them and their documentation has to be so specific that after a bit of time and evolution half of what you find online is wildly out of date, "Oh, yeah... don't follow those instructions you found on our site. Try this Github repo instead".
I miss just building cool things but I also feel so burnt out and worried about income that I have fallen into a rut myself.
Over all your example is flawed.
The reality is that in many businesses, the job of software engineering past the entry level is a lot more than just coding.
This isn't a dynamic that is limited to software engineering. I'm renovating my house, and it has been extremely frustrating at times to work with my architect. It occurs to me that those frustrations are typically around the aspects of her job that aren't design oriented, and I can see how those other things probably dominate her work.
Coding is very creative, and I suspect that's what drives many of us to get into the career. But the deeper you get, the more you find that the highest value things you can do from a business are bridging your creative work to all of the systems and processes. This is how you can create a business that harnesses the work of hundreds of producers to meet coherent goals. And unfortunately, this can't be completely externalized to all of the administrative people, like PMs and managers.
What you wrote also speaks to another dynamic, which is that over time, there is a divergence between the platform and the real business needs. More and more time gets spent working around that mismatch. There is no silver bullet solution for this. You can shrink the platform (e.g. microservices) but then you will feel the pain in increasingly complex integration and operations.
But the good news is that platforms are constantly improving, and I think we're getting closer to the point where we stop solving all the wrong problems. For instance, server-side rendering is having a renaissance, getting us away from all of the emergent complexity of client-side frameworks. Tools like Temporal, Airplane.dev, Trigger.dev, Patterns.app, etc. are creating platforms for writing operations and automation tooling with far less operational overhead.
I thought this was well put: > I now understand why there’s a trend of developers who want to go live in a farm or take up woodworking: tough(er) problems, but with less variables & easier to reason about. If the wood breaks, you can see where and can probably guess why. Making a table is a mostly linear set of steps, and the basic tools you use don’t change much throughout the years. There is no invisible ghost that lives in a separate realm (dev environment) that can ruin your work at any time and leave no trace.
There's not many things less starting an implementation and discovering a series of hard to anticipate incompatibilities between your implementation and the rest of the system. I'm sure this happens in other professions, but perhaps it's easier to work around?
But it's also possible to find joy in tech by moving to a new area for a while. Of course, it feels like another particularly tough era to think about moving, which may contribute to both the feelings of anxiety and sadness about where the OP is at the moment.
My recommendation when counseling folks on this situation is to start by finding a willingness to try a new path. Working on getting onto a better path is often as engaging at rewarding technical work.
The act of creating art is a means to an end. It doesn't keep you up when you're down, it doesn't check in to see how you're feeling; creating something is often emotionally draining. You have to dig deep inside to create something, take the risk of putting it out there in front of others, be vulnerable, realize that your first attempts won't live up to your expectations, that the real work begins once you start editing and refining... and the final result may never be what you initially imagined; and so you seek to put yourself through it again, one more time.
Don't fall in love with this process! It's way easier to remain impartial and you will retain a lot more of your creative energy when you do. You will be able to take constructive criticism and be more productive with it. It will help you refine your work and get closer to that ideal form you envision.
Programming is very much a creative endeavour. It has similar ups and downs. Don't fall in love with it!
It seems to me that you're not giving up on programming but perhaps are not enjoying something about the process. It could be the tools! It could be that you don't see that what you're building is worth the effort. Maybe you need a new project? Maybe you will enjoy embedded programming or systems programming more? Maybe there's some problem you would rather be working on?
Which is more fun? importing graphics.draw as g and calling g.lineto(x,y) or writing your own lineto(x,y) function?
Don't switch careers, but take a side project doing your own cool stuff. Get your pen and paper out! Draw thos lines; write that code. Will anyone use it? Probably not. Will you enjoy it? Totally!
That’s why I’m going to get out of it, I’m going to make sure of that.
On that time, worked on my own software and passions. This lead to being able to work again with a team and with somebody else, but now on something that is my passion and that I love doing (most of the time).
Just encouraging to make the jump!
I started my career in the server rendered 'rails like' monolithic web framework days, where only sprinkles of JS using libs like jQuery and prototype were being used for a bit of UI dynamism.
I saw (and partook in!) the rise of what I'll call the 'client-rendered' era with libs like Angular and React. This is often also referred to as SPAs, but SPA really is just an implementation detail. The important bit is that most responsibility for rendering, data, and state management, takes place on the client - be it in a single-page bundle architecture or no.
I saw that happen from the ground floor and so I know what momentum building for that kind of paradigm shift looks like. It takes years, and goes through various stages of hype cycle. I remember 2-3 years into this cycle many companies and parts of industry not yet taking React seriously, or believing it was or would be something very important in the industry (regardless of your opinion of it we can all agree it is important).
The point being that these changes and turnarounds are very, very slow indeed. I believe we're now about two years in to a shift back the other way, to a fundamentally more server-based approach taking only the best ideas of the client-rendered era and throwing away the bad ones, or at least the tradeoffs that weren't worth it.
We're seeing it in frameworks like Remix, and NextJS, and even some of the edge-based ones like Deno's Fresh (indeed, edge compute is one of the new things that exist since 10 years ago that I believe will help drive the transition back to server-based rendering).
The full transition back may take another 2, 3 or even 5 years. But I am confident now that it is happening and that it will happen. So you may want to get involved in driving this forwards!
Try another language if you're burnt on the ever changing ecosystem. I would consider Go (golang) for instance.
The tooling is much simpler, so much so that you might not want to go back to javascript.
There is not a big story around building UI with it but some people are working on it (including me). :)
I got fed up with the ADHD of javascript back in 2013 and made the switch. Probably won't ever go back. Bare js is fine but the frameworkitis and build tool-itis, I can't deal with.
I own a farm and a carpentry business, both since the start of covid. And I do freelance development. I have no plans to return to corporate coding. Life is great, never been happier or more fulfilled. But that is just me, your mileage may vary. Also it is a lot of hard physical work, at least during building and growing season. The grass is always greener. I code in the winter.
Yup. I would even say it's probably the root cause. Stop working with JavaScript.
Burnout doesn't come from working hard, it comes from there being a dichotomy between the level of effort you're putting in and the reward you get back. Programming itself is very rewarding but dealing w/pedantic micromanaging bosses, writing emails, etc sucks.
As a consultant, I bill by the hour and I get to command a certain rate within my niche. My employers can inhibit my progress as much as they like, I'm going to bill them either way. The amount of fun drives I've taken in my Porsche while waiting for a blocker to get unblocked or a product to compile is hilarious.
In my industry there certainly was a lot of jobs being dumbed down and hiring standards falling, with the indivisible challenging work being concentrated into the hands of a small number of people.
Personally, I don't find technical implementation any more interesting than creating Excel spreadsheets - it's just a tool for me. Maybe some applications require very sophisticated implementations, but I don't think that's the majority of cases. There's no high-tech feel about IT in 2023 to me.
Problem is that, at my age and experience, this bureaucracy is expected from the industry.
I'm learning - psychologywise - to deal with it. But, I'm frustrated to be honest.
My "side job" is to invest the more I can, aiming to be able to retire in my early 50ies and, finally, be able to be a programmer again.
I won't itemize all the ways here, because I started, and had to delete them, because it would take hours and ruin my day (and some communities would never speak to me again).
Another thing that bothers me is that Web search hits are mostly SEO, posturing, or otherwise low quality or negative.
It's no wonder, if a lot of people are seeing software as an unpleasant and poorly-effective corporate BS activity that one only does for income and ladder-climbing/job-hopping. Because that's what it's being made into.
Another thing that bothers me is mostly symbolic: so many open source projects now base much of their communities and support around Discord. Despite nominally being about open source, it seems they've somehow missed the ongoing lessons of the last few decades in that space.
There was a time when this would be glaring sign of bumbling corporate effort that didn't "get it"; now it just means ordinary programmers or brogrammers who're just mimicking what they see around them (which is self-perpetuating).
If you're feeling discouraged, I don't have a good answer right now, but I guess look around for like-minded people, and how to carve out a less-BS oasis.
I'm guilty of this, and yet I looked at all the available options, and Discord was the least terrible. What's the alternative? Matrix/Element? IRC? I've tried organizing the community with both and ~most people can't/won't use either of them. Gitter I guess?
Tool fatigue is real. Most companies and developers do not invest in their SDLC. So you end up with a system where even a small change can require outsized effort leading to burnout. Tool fatigue is real.
Many libraries/languages/frameworks encourage a simple, vanilla SDLC. Think `rails` or `poetry` or `make`. But rarely does that scale once a project gets more than two developers, more than one repo, or more than one way of declaring dependencies. Everything turns into a snowflake script running a build-system integrated with hundreds of yaml files spreading out over repos and toolchains. Good luck doing fast end-to-end iteration on a change to something three layers deep in your dependency stack.
I wish the industry would try to solve this in a way that doesn't have vendor, language, or cloud lock-in.
Maybe some combination of containers, nix, asdf, and bazel or something. It doesn't seem that hard to be honest, just requires some innovation and resources to find and execute on an extensible and sane SDLC toolkit.
Until then: Find a way to iterate on your core problem. Become a jedi in at least your smaller domain. Focus on developer productivity. Make it easy to make a change. If it's not, find out why, and solve that problem exactly once rather than having to solve it for every change. Easier said than done. Often times it's politics and momentum that you'll have to overcome. Hopefully your company values this work.
I took a break and did a lot of reflecting. I bought a workbook in career changes and started working through it. After a bit I started getting the itch to code again, so I did a Udemy course in a programming area I had done previously and really enjoyed but had gotten away from.
After a while I realized I was ready to go back to work. Before I did, I tried to figure out what made me so miserable previously. In my case it was the poor decision-making processes with unclear ownership that made me feel like I was always seeking permission to get things done. I also decided I didn’t want to work on large projects with untyped Python. When I started interviewing, I decided not to be picky or make too many assumptions in the early stages of the process. Once I started interviewing, I really honed in on these things and asked a lot of questions about it. I ended up at a small startup that’s doing reasonably well with really high velocity. I feel like I have a conversation about some design thing in the morning and I’m well on my way to implementing it in the afternoon.
I've made a presentation about this approach at FOSDEM 2023: https://presentations.clickhouse.com/fosdem2023/
(the video will be published soon)
How long have you been at this? As in, is this frustration with the org / current tech stack, or is it maturity and moving past just pushing bits around?
The JS ecosystem is notorious for what you describe - piles of busywork nonsense for its own sake, wheels regularly reinvented. I do some UI work, I manage to stave off 99% of the bull by using vanilla JS, vue, functional css and absolutely no build chains, no npm, no node. And for the love of all that is holy, keep JS out of the backend, only use it where you have to (ie, the browser).
It sounds like your org isn't that well organized. Perhaps it's not a career change, but a place-of-work change that's in the cards? Making a living as a woodworker, a tradesperson or a farmer is -hard work-.
I do consulting now and when I get to see the response from dev, product and QA teams when they get to experience better first hand it's rewarding. Hearing excitement about the changes from execs first hand is wonderful.
If that's not your cup of tea though, try learning something that makes you think differently. For me, this was getting into Elixir and Phoenix. I binge-read Programming Phoenix in about 24 hours and my colleagues will tell you I haven't shut up about it ever since. :-)
Try learning Rust.
Your anxiety of things constantly breaking will disappear.
I've been coding for about 20 years. My joy of coding would be gone if not for Rust. Instead, writing code is my primary hobby today, in addition to it being (part of) my job professionally.
I wanted a more deterministic and reasoned approach to things. Also as another person stated elsewhere, practicing minimalistic engineering where you roll your own instead of mindlessly bringing in another library can help sometimes.
The correct approach is to keep your love and job distinct (though perhaps intersecting). This keeps your love your love while still allows you to work.
There's a reason why we have a review panels behind protocols. IF you leave it open to people working in their spare time, you end up with the current chaotic world of JS!
Nowadays and after lots of years of experience mainly in early-stage startup environments, I don't even care about the code or the low level stuff.
I'm trying to embody my self to the mission. I'm looking for the right metrics to watch and when these metrics are impacted by my actions (or my teams' actions because these environments tend to be very team-driven) thats when I get the same feeling as when I was writing those Visual Studio LoCs and was building those grey UIs with MS Access for data storage.
With the right mission and metrics, comes a problem. With the right problem that will motivate you and excite you, comes the solution. And the solution will be a package of the right code, the right UI, the right line of communication, the right team policies.
I've stopped using the term software engineer for my self, I prefer the term product engineer. And building the right product is my mission.
If you haven't explored that path, of changing your perspective of what gives you that feeling, maybe it would be helpful before deciding to go live in a farm. :) All the best.
I would also like to hear from people that went through that path and where that lead them because I'm still early in my career (in my 30s now).
Usually libs in the dotnet ecosystem are pretty clear on how to use them, and the stdlib of dotnet is huge - so you use a lot less 3rd party dependencies than other enviroments.
Personally for webapps I prefer MVC to Razor Pages, but that is personal choice and probably because I am so used to it.
I also do a lot of JS/TS work and really know what you mean with "fighting" the ecosystem.
It seems like the SPA trend is slipping away which I think is a good thing.
We talked for a bit, he works in Forestry for the provincial government there.
He was going around gathering data from wireless water temperature logging devices, data which would enable analysis of the effect of logging and other extraction operations on trout migration patterns.
He left me with a hot tip - versus the groundwater fed ones, surface-fed rivers are clear and cold, perfect for taking a dip on a hot July day.
I felt a bit upset with coding as well. Then I found that most of that comes from management failures, random people in industry, companies that don't care about employees, and pretty much what they do (except money).
So advice is stop "working", start happy hacking.
This comment speaks to me very deeply.
It isn't like this where I work now, but I've worked a couple of larger enterprises that were exactly like this. Everything was set up to prevent developers from sitting down and coding. I haven't worked enough different places to know if there's a clear pattern here, but in neither of these companies was tech their core business. One was an tech-based offshoot of a financial services company, and the other was a very large retailer.
Not everywhere I've worked where tech isn't core business has been like this, so that's why I hesitate to draw a general pattern. However, I've worked at four different software/tech companies over the years and, whilst they all had their flaws, in none of them did I ever feel like I had to get permission to code. Actually, that's not quite true: I did work at one for a number of years where latterly it did start to feel like that, and it was one of many reasons I left. But it definitely wasn't the norm for the majority of the time I was there.
In my experience, you have to have a hobby outside of coding. Whether it's wood working or something else. Now, take that hobby and combine it somehow with coding. If it's music, make your own synth. Make your own tools to learn music theory. If it's exercise, make your own workout tracking app. You might even just build tools to empower your own dev workflows. Maybe it's a bookmarklet or user script to taylor your favorite websites to your liking.
Don't do too much planning or thinking ahead, just let yourself get into a creative flow state. Flow state is key! And it sounds like that's what you're missing in your day job.
I wrote about this idea on my blog if you want to read about my experience. I combined my love of hiking with coding and discovered a newfound enthusiasm that I hadn't experienced in a long time: https://jameals.com/essays/build-for-fulfillment
I read it really quickly, but different language, different org that's more flexible? Try out a few different ones?
Yea, it sucks to build your own framework for your own app -- but also, the patterns of this model are well known and visible in 100s of other frameworks. You don't actually have to use $COOL_THING to get the specific advantages of $COOL_THING that your company/project needs.
It's very hard to weigh the issues of cost in a) how much unknown cost will there be fighting our framework and b) how much unknown cost will there be in building our own framework.
It's been my experience that discipline in choosing these vendor-packages, and choosing fewer, and choosing more to build in-house has, over a longer period of time, been a better investment. However, it also requires a good architect to be around for a long time. When team-leaders are bouncing around on short time-frames (<2yr) the in-house route is not stable (but it's not the codes fault, your house is unstable anyway). Folk think in that case it will be easier to ramp-up new staff on $COOL_THING but, guess what -- you're using $COOL_THING_V0 and the new hire has only been using $COOL_THING_V15 -- so now, rather than learning a little syntax for your custom solution to common problem -- they're going to spend the first months on-staff migrating your $COOL_THING forward -- and fighting unknown demons the whole way.
Too much vendor-driven-churn and bloat -- YAGNI!
> Any project I work on is connected to a million different tools, workflows and services, that all do things their own way, and everything lives in a totally different place, where it’s hard to monitor what’s going on.
It sounds to me like it isn't coding you're falling out of love with. It actually sounds like you still love coding and you're bemoaning the fact that you never get to do it!
Without knowing the specifics of your situation, it could be that you're at the wrong company or in the wrong role. There absolutely are companies and roles out there that let you spend the overwhelming majority of your time writing code.
> I work mostly with Javascript — and that doesn’t help.
I bet it doesn't. Not to rub it in, but this is why I don't work with JS/frontend. I think you might be onto something here, I bet the JS ecosystem and the way it all shakes us out is a large contributor to why you feel the way you do. I think changing careers right now might be rash decision (though, of course, you should remain open to anything). Why don't you start to devote some energies to moving into a different branch, such as backend/API development? I used to work on mobile apps and, while not as bad as the JS world, I found that I didn't enjoy how much of my time was spent perfecting pixels and the workings of the UI (some people do enjoy that, just not me) so I moved to working on larger distributed systems and APIs. There's no UI to content with and there's a lot of writing code. If I were you, I'd start devoting some energy to looking into that, assuming, of course, you have any interest in it.
Maybe finding a side project you actually like and understand can help.
I do know some people that had to switch careers entirely, but often it's the job tearing one apart.
If you think there is anything worth salvaging, just go to your boss and tell them that this ship needs righting or you're gone. Preferably with some things you feel could be done right now.
Why not try and hack something on the side in your own way? Experiment with new stack, build something that solves your own problem? Thats what fun coding is about?
I see a lot of my friends being disgusted by their jobs because it took their permission to be playful. In the end code can be creative (based on your ideas and obviously with some constraints).
I started learning a few months back but I never plan to make it a job. I learn slower as I don't practice it on a daily basis, but I really love it and love building small things.
Yes the ecosystem is unstable in all languages but I accept the technical challenges willingly over being shoved into a "work tickets and dont think" box.
I feel you though, it seems more and more frequent that I dream of moving to Montana and living on a farm.
I'm not saying working can't be fun but I have a mental model of what "most fun" I can extract from "coding" and whatever nets me the highest amount of money in the shortest amount of time.
In my case, my joy for coding is greatly enhanced by interactivity. Across the stack, I try to remove friction: hot reloading is sacred in my frontend work (I make sure to fix it whenever I notice anything funky going on); click to run in VSCode and 'rich text comments' in my files to have a better REPL workflow; shortcuts, snippets, scripts to automate; faster tests; autocomplete using types and Copilot. Overall, stuff that gives me Thinking in Principle vibes (https://www.youtube.com/watch?v=PUv66718DII).
Making my workflow more interactive has made me enjoy programming more :)
* https://www.lexaloffle.com/pico-8.php
* https://100r.co/site/uxn.html
* https://love2d.org (shameless plug: http://akkartik.name/post/roundup22)
I never work with raw pixels at my day job, and it's been enormously satisfying to take control of a whole app and build things nobody else will ever build.
a. You come to a green empty field. Nothing is done, everything is possible.
b. You come to a town. A lot has been built, a lot of space used, but there are still many fields around the town to expand to, and build new things.
c. You come to a City. All the space is used. Everything you build must work with has already been built. Some things can be built, but only if it does not inconvenience what is already there.
Software as a whole is approaching/already in stage C. Sure you could make something that does not connect with anything that exists. But what use is that to anybody. People want to connect with the thing they already use.
This metaphor works with a lot of things. Operating Systems, the Cloud, even things like Game Libraries, ala Steam. To produce value, you need to work with what's already there.
1. Learn a new language. Even if you don't expect to use it on the job, it can be exciting to spend time learning a new language and working basic practice examples in it. Depending on your employer, you may even be able to convince them to allow you to use some "professional development" time and resources at work to do this. Check to see if your employer has things like PluralSight access and if your manager would be interested in giving you 10%/20% time to professional education/learning. You may need to be able to market whatever language you pick as "potentially useful to future projects", but good managers often encourage a small bit of "professional development" time because it keeps you sharp (and that is good for them).
2. Find some reason to code for fun outside of work if you need it. Be careful with any attempts at moonlighting because the failure case is burn out (and possibly dangerous levels of burn out at that) and work/life balance is generally a good idea. As others have suggested you could build a hobby project of some sort, perhaps a game idea you might want to explore. If you want more "guide rails" (which might help to avoid some burn out by narrowing your focus) there are things like attempting Project Euler problems [1] or also a small category of Games on Steam where playing the game encourages/requires writing some of your own code. For instance, I've been playing some Bitburner [2] lately. It uses JS to "play" but you can start from a very stripped down "no toolchain, no frameworks" place and just explore/learn the game's API at your own pace with end goals already encouraged by the game structure. It may be an interesting anecdote to some of your current work struggles.
As someone who got out of farming and into programming I would suggest looking into other options before pulling weeds for the next 24 months. One option that you may want to look into is Recurse Center which is a great place for software people dealing with burn out to reconnect with what brought them into coding in the first place.
Join (or start!) a startup and this problem will go away. It'll be replaced with a heap of different problems instead of course, but you will find them more exciting.
I work on my own code ([1], comments at [2]), and it is exactly why I do this; I wouldn't enjoy it otherwise.
For me, I just decided to forego jobs and work on my code the way I want to until I eventually make a business out of it. Or to keep it as a hobby and do something else as a job. (I have a CDL for this reason.)
I don't know if that will work for you. But something else might.
[1]: https://gavinhoward.com/2023/02/why-i-use-c-when-i-believe-i...
You’re gonna have this issue you’re talking about at any company that has more than like 200 engineers. At that scale you’re solving both technical and organizational problems. Remember. More people, more politics. They don’t send in a Marine battalion to get Osama, they send in a few highly trained Navy SEALs who can do the quick, efficient, and dirty work.
As for “complexity” don’t confuse actual software design patterns with shitcode that 99% of average software engineers shit out.
Read Clean Code, Clean Architecture, and Designing Data Intensive Applications if you’re serious about becoming a better software engineer. Otherwise anyone can write some garbage code that solves the problem at hand. That’s not hard.
Some of that is "build it and find out" kind of stuff, but I'd pay cold hard cash in a lot of cases to have a well-documented git repo to look at and learn best practices from (even if they're a bit opinionated) rather than have to stitch together my understanding from some diverse collection of "getting started" code, crappy toy examples and SEO-optimized blogs that have way way too many words per useful bit of information.
This is why I prefer reinventing the wheel. I have exactly zero desire to learn someone's mental model when I could instead learn how to perform actual work.
Although, I don't consider connecting APIs to be coding either.
I shifted into a job where programming enhanced the role. Now I expend mental effort on coming up with novel algorithms. My struggle is to express how I think in terms a computer will understand, rather than wrestling with the Jormungandr of what the profession has turned into.
And if you try that and still hate coding, I highly recommend plumbing!
I coded anyway, but on my own time. The company missed out on some pretty awesome software, but that was their loss. I don't think they cared.
Being an active coder, helped me to be a better manager.
That said, I hated being a manager, and jumped right back into coding, when I left that job.
Couldn't be happier.
An important caveat to all that, is that I code the stuff that I want to code, at my pace, and on my terms. That makes a huge difference.
But I learn, every day, write Swift, every day, and take great joy in my work.
WFM. YMMV.
Working in software development as a profession does take some of the joy out of that over time, but I've found that trying to learn things outside of working and working on my own projects is still very enjoyable.
Out of all of the languages javascript roles has been cargo culted into the daily standup, the 5 layer approval process and the unnecessary meeting. I've never wanted to leave the field until I spent a year in a true javascript role. Happiest for me are full stack roles where you control both ends and have a smaller teams and less demands for meetings.
It's why I gravitate toward small pre product market fit startups as either one of the first employees or founder. There is only process where I make process and everyone is executing as quickly as possible. I get to learn a ton and feel productive. I'm much more motivated by intrinsic factors than things like a large salary so it works for me.
Secure the income stream by doing what is expected of you, and use your personal creativity on side projects with a potentially new language (e.g., Rust, ...)
On a personal note, the older I get, the more I code, so it was those work environments that made me doubt.
But seriously, you may just need to switch things up and tackle a new line of work or find a new employer that isn't so rigid in their SDLC practices.
Spot on.
Ditto being compelled to lie about everything. What David Graeber calls "justifying" labor.
Breaking out the crayons and finger paste to show PHBs how stuff works, clearing tech debt on the down low, estimates, concocting status reports, performance and peer reviews, etc.
as a freelancer i have fled from one project due to code base complexity, consistent need for hot fixes, and developer anxiety
I’ll drop a small plug here since I was in the same spot as you a couple of months back (I worked as a PM consultant in the software industry, rather than as a software engineer). That’s when I decided to make my “last call” in the PM world, and set a goal of getting back into engineering, because I’ve burned out in the PM role.
I’ve decided to pick up Rust since it was (and still is) a very loved/trendy language. And the fact that it’s difficult to write shitty code sealed the deal.
Since I’ve had some background in Javascript, I’ve naturally opted-in for web development in Rust and just the sheer amount of knowledge you need to soak in was overwhelming, let alone everything else that revolves around backend development (mainly infrastructure/devops).
At that time, I’ve stumbled upon shuttle (cloud development platform for Rust) which takes that whole devops layer out of the scope, letting you focus only on writing clean & efficient Rust code, without any residue. Fast-forward a couple of months; I work at shuttle (hence the plug mention), as part of a "new career" and I'm finally happy again.
I feel like this might be something that might spark that love towards engineering and problem-solving, if you are willing to put in the time to learn a new language.
But let’s disregard that ‘potential solution’. Remember that it's important to prioritize your mental health and well-being. If the stress from your job is getting to be too much, it might be worth exploring a different career path or taking a break to recharge. What helped me is a 2-week long trip to a village in the mountains without any technology; just nature, air, and calmness. It really changed the outlook I have on everything and it got me in a better state to do some much-needed decisions.
I wish you the best
Then go do that bro. Life is short.
When, as a retired musician, painter, plumber or electrician, you walk into a project that was done yesterday, you can just understand it and start working. With software (well, frontend mostly), you will have spend an insane amount of work figuring out which billions will of crappy dependencies and myriad of frameworks were chosen and then learn those to start working.
That is just not very normal in most professions.
But sure, you could get bored after doing something for a long time. The getting annoyed and frustrated by not being able to do your job because someone added crap no one asked for (for tech ego etc), making all kinds of pain you have to figure out before writing code, I have not seen outside software dev.
Setting all that CI/CD stuff up took me maybe 6 hours. Building the website (front and back-end) took me a few weeks. It's a complicated piece of software, but fun to build.
I avoided using unnecessary tools. I only added what was absolutely necessary. And based on my 22+ years of experience (including some FAANG companies and the likes), in any professional setting, this project would've taken 5 front-end developers, 3 back-end developers, 2 testers, 1 project manager, 1 scrum master, 1 product owner, 1 UX and 1 UI designer, and perhaps one or two interns.
And it would've taken 2 years or longer.
I've done projects with teams like that in the past where trivial work was drowned in red tape, office politics, endless opinions and meetings, weekly time-wasters (Scrum... fuck I hate Scrum!), endless "documentation" that nobody reads...
And I remember being put on a dashboard page. The team was taking 4 hours to plan all the stories. During that time I just started working (remotely, muted, camera off) and I finished the entire dashboard completely to specs, no bugs, in the time it took them to write the stories and tasks and estimate them.
"Done."
"What?"
"I'm done. It's all done. I pulled all 18 tasks to myself, verified them, and the entire story and epic is now done."
"What?"
"I also wrote all the e2e-tests."
"What?"
"Scrum is a huge waste of time."
"Actually, I disagree, because..."
Yeah, consultant who is paid by the hour. It makes perfect sense to pull all 20+ people into a 6-hour long retrospective every single week. Because 12 of those people are from your employer, and that's a lot of money for doing fuck all.
When I worked at Apple, we had a small team and we just did standups on Slack. Just write "I did X, I will do Y, no impediments," and that's it. No scrum bullshit, no sprints, no retrospectives. We just communicated using words (written, preferably) and got shit done.
Now I'm working for a large corporate company that follows all the things by the book. And the book sucks. I counted: 16 hours per week in unnecessary meetings. Then another 10 hours in meetings where most people are unnecessary. And when I speak up against it, people don't trust me. Scrum is their God.
I hate my job so much.
1. It doesn't sound like the problem is actually that you're falling out of love with coding. You said, "on avg I spend less than 20% of my time coding or solving problems".
2. I feel ya. Reading stuff like TAOCP and SICP was what initially inspired me to pursue this career. But chasing the money for coming up on two decades has worked me into a position where I'm really efficient at putting different web skins on the same four CRUD operations on a database. The kind of problems that got me into this career, aren't the kinds of problems I'm solving on a day to day basis.
3. Having talked to lots of people in lots of careers, it seems like anything you do as a job is going to be less satisfying than if you do it for its own sake. I love playing guitar, but the reality of playing guitar professionally, even if you're financially successful, is that it isn't all that fun. Some high-level Go player (I think Cho Chikun, but I can't find a source), when asked why he liked Go so much, said "I hate go". People in the adult film industry generally have low satisfaction with their sex lives. Money ruins everything. Once you start basing your ability to eat, clothe yourself, live under a roof, etc. on something you do, you're no longer doing it for fun, and it stops being fun. Put in psychology terms, adding extrinsic motivation to an activity decreases your extrinsic motivation to do it.
4. Because #3 applies to every activity, switching careers may not be the solution you think it is.
5. That said, doing something you are intrinsically motivated to do as your job, does seem to be more enjoyable than doing something you're not intrinsically motivated to do. So finding coding jobs that let you do more of the part of the job you like, the actual coding, might help.
6. JavaScript's ecosystem is the obvious, abjectly terrible result of decades of "move fast and break things". That's a controversial opinion, I'm aware, and I'm not going to argue with people who disagree because no one will be educated or persuaded. It's possible to write good code in any language, but I think it would be difficult to even learn to write good JS, because the culture is all about introducing a massive amount of dependencies on bleeding-edge garbage and antipatterns like global state are the norm, not the exception. The problems you mention, "I feel like anything can break at any moment and ruin my day. I don’t understand any of the tools well enough to be confident that it’s stable, and the worst problems are the silent ones"--that's at least partially a problem specific to JavaScript's ecosystem. You might find better luck in a better ecosystem. But unfortunately the disease has also infected other ecosystems: if you pull all of pip into your Python project and use a bunch of global state you'll run into the same problems.
7. Returning to why you're doing what you're doing--the real, underlying reason--is helpful. I know people who work truly horrible jobs, but feel happy about it because their work lets them provide food, housing, and education for their kids. I'm not saying have kids (I don't have kids) but to some extent being aware of what I'm getting from my work keeps me from being too frustrated when I have to work. And if you can't find a reason, then maybe find ways to work less, until you're only working as much as you need to.
8. The subtext of #7 is that satisfaction probably isn't going to come from your work. Few people dream of doing labor.
Get a job doing something else that involves coding. Do you know advanced math and physics? There are tons of opportunities in the applied sciences and you'd be a god-tier coder among men at federal research labs etc.
