Ask HN: I’m falling out of love with coding

I get bored of laying in bed all day after the first week or two.

I try to set my life up so that every day is an adventure :)

Glad you enjoyed yourself. And yes safety is paramount. Gloves and glasses are a staple for me, and hearing protection. I know a guy that lost the tip of his thumb. And not from a saw accident either. He got a splinter and it became infected. He tarried going to the doctor and ended up needing to have the tip amputated.

Yep.

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.

Did you use something like Unreal or Unity for this, or start at a more foundational level and deal directly with graphics APIs etc.?

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.

One paragraph mentioned that, but the thrust of the argument was about burnout. For me, burnout occurs when I feel like I’m putting a lot of time and effort into something but I’m not getting enough back to justify it. Burnout is like a mechanism to get you to stop pouring energy into something that isn’t working.

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

If you don’t like JS/TS then just don’t do front end? There’s plenty of backend only jobs.

It's worth stating: you can write frontends without buying into the ecosystem at large. I've been working on a multiplayer video game using Go + websockets in the backend, and a JS frontend with zero dependencies.

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.

I once suffered from Javascript fatigue, had to work with frontend anyways, and had the privilege of picking my own tools.

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.

Just learn Next.js (Vercel), TypeScript, and MUI and don’t use anything else. Make sure you also understand CSS flex-box and such.

For the front-end I write SPAs.

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.

I stay away from all the JS dependency bullshit as much as possible.

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.

I mean, making a career pivot away from front end is technically an alternative

You can make interactive web sites with a minimal amount of JS (et al).

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.

Sure, but you don't have to do it the way most JS projects do it.

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.

WASM?

You are correct to an extent, but its a fallacy to assume the language and tooling have no impact on the culture or people it attracts. Go is very specifically not "elegant", it has a stdlib where npm has hundreds of dependencies which differ between projects. Errors in JS (Ruby, etc) can come from unexpected places, but the code can elegantly hide them. In Go they are in your face at all times -- but then they rarely surprise you. etc. Its a series of trade offs that are more than simple choices IMO, they target and attract different audiences. And to an extent many people will likely gel better with one than the other. Its only a piece of the puzzle to be sure and the people and company matter more, but I strongly disagree that languages / frameworks matter little. I think those with big differences (Node/Ruby vs Go) there's probably a substantial difference in "average" workplace culture.

My experience with React has been different hence commenting here. That is just not true. I have used react with nextjs in the past but moved to remix. Moving to a new framework requires you to learn it, quite similar to learning a new language but it is much better than manually creating webpack loaders. I had a decent experience with nextjs but my experience with remix has been better.

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 recently fired up a project in Django, after not using it for a decade, and I had the same feeling. I defined a couple of models and BOOM I had a working website. Felt a little bit like the last ten years of web framework development hasn't resulted in anything better.

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 have several side projects where I use a simple Spring Boot backend and I feel I can focus more on the fun part (solving problems)."

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.

Came here after searching for threads related to anxiety in the software development field. I feel this way too. In most professions, after you learn the specific number of things you need to learn while starting out, you just tend to improve upon them with time. And just like you said, a woodworker could get back to a project years later and he would feel right at home, unlike the SW field where things move so quickly. I battle impostor's syndrome daily.