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
Deleted Comment
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.