Ask HN: I’m falling out of love with coding | Hacker News Reader

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

235 pointszikero290 comments

I spoke to a lot of software engineers around me and the feeling seems common.

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?

View on HN

The red tape is garroting us.

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

A lot of this sounds like big company stuff, perhaps in financial services?

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.

> The issue with places like that is that risk is prioritised higher than delivery speed,

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.

Not all companies are like this. I know it sounds hard to believe. I had to look for a while but trust me, there are much, much better places out there. You just gotta find them. It's hard to judge in advance, and there's luck involved, but it's possible. Don't lose hope and don't settle for crap like this, get out while you can.

This sounds soul crushing enough to me that I would look for a job elsewhere, even if it means taking a financial hit. Many places are not like this; I would look outside compliance departments, large financial and utility companies and established defense contractors for a more open setup.

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

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.

Speaking directly to the AWS case since that's what this is about, the whole point of permission boundaries is to prevent the blast radius of your IAM policy from being too wide. Coupled with service control policies ("thou shalt not" at an account level), I wonder why you'd need a manual review of your IAM policies. Unless it's a "we didn't know you could do that! time to stiffen up our policies" meeting, which seems weird.

Having templates is useful though so you know what you need to define for your policies inside your boundaries.

I am writing best practices for my department. Nobody else wants to do that, it does snot help the career and it eats up you own time from other projects that still need to be delivered. Managers don't care, they are not measured by that. I do it for my team and share with others, there is no other reason.

This was poetic.

This sounds so much like my company.

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

schedule 20 hours of meetings per week

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.

A relevant essay: Maker's Schedule, Manager's Schedule http://www.paulgraham.com/makersschedule.html

(It's by Paul Graham, but I won't assume everyone on Hacker News has read it.)

Just ask if you should be focusing on anything other than your important project and if they could help with the communication around pushing the deadline out a day to attend this meeting.

Or just skip it and say you are working on x or y.

> I'd quit but equity...

From what I've seen, those golden handcuffs are usually gold-plated handcuffs with the same steel underneath.

Meaning, the eventual payout is rarely what you think it is?

In a sense, yes. To be honest I didn't really want to spell it out because I like leaving something to the imagination for my readers.

Sometimes they're solid gold (ie, preferred equity) and one has to ask themselves whether or not it's worth their time, attention, security, and happiness. Often the handcuffs are gold-plated (ie, employee options), and give the illusion they're worth suffering for in a similar manner as the solid gold ones.

At the end of the day, they're both handcuffs and serve the same function as the steel ones.

A lot of programmers don't realize that there's a difference between <building an application> and <ensuring that the actors that make up the global economy generate predictable returns on investments in order to grow stock-based compensation for shareholders>.

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.

That seems to assume organizations are 'rational actors'... Which sadly is the minority of organizations I've worked for.

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 )

I've never met an organization staffed with rational actors that had more than like 8 people in it, so you're not wrong.

I think what I'm getting is that ultimately every edict that flows downward into the layers of management and engineers is centered around increasing perceived profit for shareholders. Any department, project, etc. at large enough organizations was ultimately greenlit for the sake of possibly making more money (not for improving the product at a cost to the company or improving society, etc.)

>> I've never met an organization staffed with rational actors that had more than like 8 people in it, so you're not wrong.

LOL - I like that, I'm stealing that line :-)

I disagree with 'was ultimately greenlit...'. Seems like quite a lot of them are greenlit to improve someone's political position within the organization. (often, despite being told it will be a net negative for the organization as a whole)

Things like 'use it or lose it' budgeting, compensation tied to headcount (and not value generated), etc. cause real conflicts of interest at many organizations.

Anyway - thanks for the chuckle - I really love the 'rational actors' line :-) (hopefully, I'm one of the 8 ? :-D )

Oh--I see what you're getting at. Yeah, I understand and agree. I'll have to say my point with that caveat in the future. I'm glad you liked my joke!

"Perceived": profound

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

I agree and offer another perspective. My red tape comes from Google Play and App Store. Their restrictions, opaque manual review process, slowness, inability to quickly push updates, and cumbersome storefront backends have pushed my company to move away from native mobile development, which I love, to a web wrapped app, which I disdain.

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.

It makes me wonder whether companies should consider hiring more people dedicated to dealing with the red tape to unblock engineers. I suppose managers to a certain extent are the ones doing this work, but in many cases it's not enough, how about a new role that is dedicated to cutting the red tape?

This is what a squad lead is SUPPOSED to be doing

Their called PMs (with P being Project, or Product, or Planning or whaterver)

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.

This is absolutely a mis-characterization of the average PM, in my experience. If the PMs in your organization act like this you've got bad PM management. The PMs I work with are professional cat-herders and bullshit-filters (both engineer bullshit and management bullshit). They keep projects pushing in the right direction, ask insightful questions to help remove blockers, and are overall a force multiplier.

I am extremely grateful for the product manager I work with most often. He saves me a lot of time by organizing communication with other people in the organization that I now don't have to.

> They tend to be people who couldn't cut it as actual engineers

I don't doubt your experience but it's also a harsh generalization.

I've worked with many TPM's who were skilled engineers. It can be a path to transition to management and test the waters before taking on formal management responsibility. Or some people just think differently and are good at managing organizational complexity and finding the actual needs before starting to build things.

If your managers aren't doing that, they're neglecting their duties

Also in this agile scrum world no one seems to care about technical feats or technical acumen. Its all about closing JIRA stories. Somehow Agile just grinds out all the fun out of coding making coding feel dreary and robotic.

Programming isn't the only career that is having its soul crushed by red tape. My wife is a doctor and these days about half of her time is spent filling out forms and jumping through bureaucratic hoops instead of actually serving her patients. It is amazing how many nurses, admins, and others around her are constantly trying to figure out how to navigate the system to get any real work done.

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 remember in 2017 I went to my GP in the US for a physical + bloodwork, and when I said what I was there for, the doctor recoiled a bit – because allegedly I had been booked for a 15 minute slot, rather than 30. And there was no way to do everything in 15 minutes.

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.

> about half of her time is spent filling out forms and jumping through bureaucratic hoops

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.

Hilariously, the rates are even better if you have a medical transcriber in the room, taking notes for the doctor so they can focus.

... as long as we can get patients to speak in the normal way they would with a doctor, instead of being inhibited because of the second person in the room.

> as long as we can get patients to speak in the normal way they would with a doctor, instead of being inhibited because of the second person in the room.

Now... That looks like a place where AI can help.

> all this documentation has been shown to literally save lives

The docs saved them.

As I said earlier, some processes are beneficial. Properly documenting something can help doctors do their job correctly.

The same is true for programming. Having good comments, unit tests, and other things that can sometimes seem tedious while we do them; can actually save us time and help us write better code.

It comes down to having the right balance of process where it helps instead of gets in the way. The trouble with bureaucracies is they never know when to stop growing.

You've summed that up absolutely beautifully.

The core fundamentals that make development enjoyable and sustainable are being ripped away from us, insidiously.

Fun to read this comment, as I'm part of the team that deployed the exact same measure as for your wife: we now shutdown dev environments each day at 8PM. We decided to do so because over the weeks, we saw that a lot of devs "forgot" about their dev envs and they were up & running for 6+ months for absolutely nothing. On the other side, we are constantly requested to reduce infra costs, and dev environments (even unused) cost a lot.

In the end, I'm glad we deployed this.

Not only would they be forgotten about, but without forced downtime/reset, they start slipping into production use. The dev asks someone to “try it on my server”, then the word gets out about this other server that works better and has more features. Before you know it 2 years have gone by and this “dev” server is a critical system the business needs to function.

In our case, those dev envs are actually feature envs: they are a copy of staging with only the microservice they are working on that differs. So it is impossible for those env to end up as prod stuff for us. However, each FE is an almost exact copy of staging, and each dev has 1-2 running FE, so it requires a lot of compute and stopping them has a real impact

Couldn't this be done by giving the devs some transparency into how it's killing their team's budget and reminders, instead, so that they'd manage this themselves? Because this sounds super frustrating to deal with.

We kind of already have. We built a CLI that allows them to create/update/delete/list all their dev envs, so they have all the tooling needed. Also, we are still a small/medium sized company, so we often had the chance to talk with them to expose this issue, but in the end it never really worked.

> we are still a small/medium sized company

Sorry this is somewhat off-topic, but _why_ do you have virtual development machines?

We currently have ~40 microservices running (for the same number of devs), and having the full stack on a laptop is not possible. Especially with 80% of the devs having MacBook and Docker in a VM.

Also, this allow us (the infra folks) to chose how devs will work (partially), so it's easier for us to debug when they have issues because we do not have to deal with custom Makefiles etc.

Is it really needed to have 40 microservices for 40 devs? What I mean is that you generally scale out to so many services when you need each to have variable scalability, so each part of the system can scale up/down as necessary.

If you don't need this, all these services could be written as larger modules, with proper separation of concerns but easy to be deployed as a single piece. Collect some stuff that are similar in domain and create a well designed monolith. Easier for operations, easier for devs to maintain. Dependencies upgrades aren't a nightmare, or you need very good tooling to not create toil (which generally a small operation won't have).

Just throwing this in the wind because it sounds pretty heavy for a 40-body shop to be carrying as many services, at least I don't see the benefits unless for the aforementioned scalability advantage.

One example can be to target many different OSes/CPU architecture / GPUs architecture.

A weekly digest over email, or a dashboard on a real screen if you all work out or the same office, indicating costs and what's contributing to them. That will do wonders.

That will also add a lot of overhead/maintenance cost that we can't currently handle.

How much does it cost to have a single environment running overnight?

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

Initially, we were using kube-downscaler to do this. It stops a namespace at a given time and restart it in the morning. However, a lot of namespaces (= dev env in out case) were restarted for nothing, so we created our own tool that stops them at 8PM, and restart them when the dev runs a command with our internal CLI.

There is no value in constant-surveillance antivirus software on a modern Mac — if your IT requires this, run far, far away

For many companies it's just a checkbox towards compliance of some sort. You can argue and be right until you're blue in the face, but in the end it's the approval of, and certification by external auditors that matter.

Have seen this where I am since we have grown from a small company to a medium sized one. Spyware, endpoint protection which crippled sudo, can't update tools that we have used for years.

As someone who works in IT, it is almost never up to IT what goes onto the Mac device. It's usually a compliance/legal ask, good luck explaining to a customer why you don't have anti-virus.

Customer wants to see: Yes, Company X has Y anti-virus product on all devices.

What customers demand antivirus software for office workers who provide a service to a company who provides a service said customers?

You could say some certification requires it and customers demand that certification but that doesn't cover most cases.

> "All of this, to dabble in code"

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.

Very reactionary take here. Blaming developers for everything that's wrong is just as bad-wrong as blaming everything on management, the C-suite, capitalism, or anything else.

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.

I think he's focusing on the word "dabble", and how unprofessional it sounds. I'd be inclined to agree. I'm a developer and would never say I "dabble" in code. It just sounds light, playful and uncommitted. If your goal at work is to "dabble" in code because you're "passionate" about it, you have an unprofessional mindset. You're putting your passion above the mission. Maybe reading too much into a couple of words, particularly since this is the internet, but in general I'd recommend avoiding words like "passion" and "dabble" in professional contexts.

As the commenter above who used those words, I stand by them: my influence over code these days is, indeed, light, playful, and uncommitted. I'm the art teacher who draws a single line on the canvas of the student whom is stuck, and then walk away. That's my role, to exist on my team and help them navigate this red tape by dabbling with their code. If this costs me the Next Big Thing, so be it.

This modern mindset, that we're always interviewing for the next job, even between HN comments, is exhausting and just funnels us further into exhaustion.

There is nobody else who could have written good code, except developers. There is nobody else who kept rewriting X-Screensaver clones insecurely for 17 years[1] except developers. Nobody else who has knowledge or experience to standardise on tools for the greater good. There is nobody else who wrote Jira but developers. There is nobody else who only wants to do Electron, or who refuses things like UAC because security is fine on their OpenBSD ThinkPad.

Reddit blames capitalism, HN blames managmenent, 4chan blames 'Pajeet' Indian stereotype, Slashdot blames Microsoft, very few developers take a look in the mirror and say things like "we need less powerful languages"[2] or "ignore the firehose of new technologies"[3] or "If I want to ship my software, as opposed to just write it, I need to use tech that's a couple of clicks back from "bleeding edge," and spend a lot of time, "polishing the fenders. B O R I N G [but I do it]"[4].

Civil engineers have legal duties and responsibilities to make sure the things they build are fit for purpose and sign off on them before they get deployed, and can be personally fined or imprisoned or lose licenses if they weren't fit for purpose.

Want to make a text editor at home? Knock yourself out, pick any language you want, dabble all you like. Want to make something that handles millions of people's data, sign your name to it and put your professional reputation on the line before every release. And it may well make salaries go up for the people willing and able to do that. The world runs on a lot more code than buildings these days and professional developers with bleeding edge MacBooks Pro and six figure salaries complaining that all the software we all suffer under is shitty, is like civil engineers complaining that buildings fall down and it's all management's fault for demanding blueprints before construction and inspections during construction to try and stop the company buildings falling down so often, ugh all that red tape, can't we still use wattle and daub it works fine on my garden shed.

[Edit: just seen[5] comment from "Jon" "if you think 'function will crash if given invalid parameters' is a "defect" you should switch to Java". Nice sneer, right?]

[1] https://www.jwz.org/blog/2021/01/i-told-you-so-2021-edition/

[2] https://lukeplant.me.uk/blog/posts/less-powerful-languages/

[3] https://www.joelonsoftware.com/2002/01/06/fire-and-motion/

[4] https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...

[5] https://stackoverflow.com/questions/8477965/is-kr-c-still-ap... comment from "Jon"

It's the red tape blocking developers from actually working on fixing the problems you describe.

Yet curiously, there doesn't seem to be any red tape blocking them (us) from pushing out broken changes that no one wanted in the first place?

This seems to be an increasingly common theme these days. Some harebrained thing is released seemingly with no review or testing whatsoever, just because some dev (or worse, a "UI/UX expert") decided they wanted to. It breaks some existing use case and suddenly we need a 2, 5 even 10 year discussion about how difficult it would be to fix -- nevermind if no one wants or uses the new thing even after all that time.

exactly because delivery experts put in PR processes and QA processes in different teams to do this

complete abdication of responsibility

> when my laptop takes 10 minutes to start moving the mouse cursor smoothly after waking from a weekend suspend

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.

Takes 2 seconds on my Mac, just like on any regular Tuesday.

This.

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.

most of what developers have to ship is not in their control - very often teams are not responsible for defining what they do or how they do it now.

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'm quite positive ChatGPT wrote this to troll us.

r/confidentlyincorrect

I was strongly against coding outside work. But now I spend some after hours coding just to keep the spark going. Main job is working in legacy code. It is fine most times but sometimes it is just soul crushing to work on such a restrictive paradigm.

Could folks be optimizing for the wrong thing? I feel like there are plenty of 3 person startups where you can code your face off without red tape or human interaction. However, such gigs come with lower pay and worse work life balance.

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.

I think this passes the buck a little. There are a lot of problems created by software engineers and software engineers alone.

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.

I'm curious about your opinion on Git. It's actually a tool I'm excited to teach to non-developer people who deal with text documents and the need to keep a history, multiple versions etc. I'm aware that now these features are integrated in some common offices apps so there's less of a need for Git there.

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

its like using the army to watch over kids crossing the road to school Many other source control systems with far simpler systems

this whole branch and pr into merge process didn't exist 10 years ago like it does now. It started from open source and low trust - but nobody stopped to ask what problem it solves.

If somebody needs to check your code as part of a formal process - rather than some arbitrary invitation you issue in special cases - you shouldn't of been hired with the job of writing code.

Source code control is important, but Git is not the only source code control system.

> Git is the most overly complicated software ever for its purpose

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

Git is complicated. I or others didn't make it so. The fact that someone didn't tip-toe around Git's complexity in just the right way isn't on them. It's on Git.

I also didn't name Git's commands, like the unfortunate `blame`, or design its interface such that there are several examples of `git <command> --<flag>` doing something wildly different than `git <command>`.

This sounds like it's the tyranny of the bureaucracy. Here's an example of what I mean:

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

> My wife's dev environment VMs are 'remediated' at 8pm

What does remediated means in this context?

That doesn’t sound like you’re falling out of love with programming. It sounds like you’re frustrated with the red tape at work.

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.

+1 on game development. This is where I always find the most engaging and fun programming puzzles.

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.

Totally. I find that seeking a true MVP (like, really paring the idea down to truly minimal) is part of the fun. Making something really tiny that explores an idea is really inspiring and sets you up (mentally) for taking on something slightly larger next time.

What libraries or engine do you recommend to build on for fun of programming?

Unreal engine is pretty fun, I like the ease of adding models and physics by mouse without writing complex collision detection logics.

If you're _totally_ new to game programming (like me), I found tic80 [0] or pico8 [1] (I think the latter is more popular) a really nice introduction to game programming. They are simulated "fantasy consoles" that come with a whole wack constraints, so you're somewhat limited in what you can build, but it leaves a lot of room to grok core concepts that you could then take over to Unity or Unreal or the like.

There is a third one too, I can't remember what it's called though. I think it has "Love" in the name.

[0] https://tic80.com/

[1] https://www.lexaloffle.com/pico-8.php

It is literally called Love (or LÖVE): https://love2d.org/

Ah, thanks! I thought so—I searched for "love console" and did not come up. "Love game engine" worked a little better.

I found Godot[1] to be a nice, mostly consistent and cohesive gaming engine and editor. It has a Python-like native scripting language, and the whole thing feels much more approachable compared to Unreal and Unity.

1. https://godotengine.org/

I've had some success banging out quick ideas with Godot

The only time I coded anything in the last 3 years (been a manager) was during a hackathon -- I made a videogame that integrated our technology in a novel way to expose a new market segment. It was by far the most engaged I have ever been to the extent that I booked weekend nannies around the clock to get more time put into it, probably 130 hours spent that week. The end result was something I was actually proud of, which is something slinging ads has never been [for anyone]. Afterwards, I fell into a depression, told my manager I was switching to an IC role, and even debated quitting entirely to pursue indie game dev (just about financially independent, would easily make it to a supply-side-favored environment should I wish to return to corp nonsense). Unfortunately, it's difficult to give up mid 6s for what would most likely be 0 income ever even if it meant being content.

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.

I would strongly recommend starting with an engine like Unity. You can prototype and get something functional SO fast. It's extremely rewarding and keeps in the dopamine loop. There's not sense in struggling through OpenGL to build an engine from scratch unless that's what gets your rocks off or you have an explicit need for it.

I worked in WebGL without a game or graphics engine sitting on top, because I'm both a masochist and egoist. If you haven't ever dipped your feet into RTR before (or don't have an interest in "doing everything yourself" / flexing or have a desire to be productive without building your own tooling), I have to recommend Unity or Unreal.

OP is frustrated with flaky and constantly changing tools, silent breaking bugs, poorly documented libraries that change capriciously, and unhelpful IDEs, all connected to and reliant on badly behaving services. Why is game development different? My experiences with the larger or more popular publicly available engines available haven't suggested that.

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

I don't disagree with any of this, but I've read OP's comment again and again in light of the discussion in the comments here and I don't see anything in there about process. It's not just one paragraph:

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

- "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. ... Oh and every 10 minutes there is a new tool that pops up that does things differently."

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

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

I apologize; I may have explained poorly.

I was trying to convey that burnout is (IMHO) a result of putting a lot of effort into something and not getting enough back out of it. It’s like a defense mechanism to stop wasting energy. This may be a result of processes, tools, compensation, treatment by co-workers, or any number of other factors.

And my suggestion on how to resolve burnout is to find a way to feel productive and capable again. Personally, game development worked for me. But I also mentioned mobile app development as a possible avenue, but obviously this list isn’t intended to be exhaustive.

Just find something that helps you remember why you loved programming in the first place. You probably haven’t stopped enjoying the act of writing code. It’s just that something at work is making you unhappy, and you’ve started to associate those negative feelings with programming in general.

2010: edit html button

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

In other words, set up your dev environment? And if you were just setting up your dev environment your working tree wouldn't be dirty. Your impossibly pessimistic scenario is sadly impossible.

> smug

There literally is not a problem on this list I have not run into in my real life career.

If setting up your environment requires all this, your environment is too complicated. But unfortunately, many production projects require environments this complicated.

Software has a multitude of tools. All scattered and disassembled.

I'm getting close to 2 decades working with software, every shop I worked that had at least some investment in streamlining tooling/developer experience has been invigorating. They are too few and far apart though.

Larger companies tend to develop layers and layers of tooling when striving for streamlining the dev experience. Unfortunately they become opaque boxes to obfuscate the complexity of the machinery. Leaky abstractions are inevitable and you will end up having to debug some internal tooling, going into the deep rabbit hole of figuring out how the machinery actually works to fix your issue.

It can be frustrating but a little rewarding the first few times, later it just becomes extremely boring as the knowledge isn't even transferable.

The smaller companies with good automation are some the most fun places I worked at. It's easy to be more creative when you aren't debugging a strange error code and the last mention to it is in some lost chat of 4 years ago. Always a fun time...

Ha! thanks for the laugh.

I'd argue the current culture is set up to create this very scenario.

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.

> (Nobody asks why there is such a need to onboard people so often, or so quickly.

Very good point

I really wish there were more non-web dev remote coding jobs. Web development is never-ending and super thankless. Plus there seems to be a brand new language popping up every 2 years now. With C I just needed to study the Kernighan-Ritchie book and that was it. I think my quality of life was a lot higher as an embedded dev, web stuff is just too easy to get into in order for companies not to treat you as disposable.

Yep. Once you start getting to intermediate-level dev, I really think more devs should think about specializing if only to start accumulating leverage by virtue of expertise and authority on a subject.

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.

Specialization is a trap though too. You can make it work (and lucratively!) for 10-15 years, but that's nowhere near a full career, and then at some point you wake up to find out you've specialized in OS/2 or Smalltalk and the only jobs around are in defense or gambling kiosks.

Good point. And it can be hard to bootstrap yourself into specialized jobs. Once you're there you have a different set of problems: smaller job pool, more qualified candidates in general, and no guarantee that your specialization will always be needed.

Beats the race to the bottom that is endemic to mainstream tech though!

> I'd argue the current culture is set up to create this very scenario.

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.

web dev is the worst, things change so frequently but they almost always change laterally so you feel like you are learning a lot but it seems like you most can do the same things after all these learnings.

> Now contemplating specializing in another domain to spice things up again.

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.

You have to put the study time in to be competent enough to do an entry-level-ish in said domain and luck into the right opportunity.

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.

> Any project I work on is connected to a million different tools, workflows and services,

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 do the same but Go can't help me with frontend, right? What do you do?

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

Or remember that there are actually frontends other than web browsers.

Yes, there are web browsers and then there are electron ones.

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.

[upvoting solely for your username]

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.

This is been the sanity-saving solution for me. I roll 100% of my own stuff in TS and web components. It sounds awful -- unless you compare it with fighting someone else's dragons.

This way, the only dragons I have are ones I created and ones I can slay. The more I write my things in functional style and build only exactly what my application needs, the company's "framework" continues to evolve AND our apps continue to work!

No one is going to change any of the "ecosystem" out from under me because there isn't one. Everything is compiled in Vite (automatically and hot reloaded) and I only ship a minified, static, single index.html file with my entire app in it. There are no globals that I didn't make, no functions that are required unless I required them, etc. It's a HUGE timesaver when debugging or adding new things the team requests.

I'm able to continue to write new, cool stuff in both our public-facing web app and in our internal web tool (game dev), both on the same framework.

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.

Any Go WASM solution will come with big performance costs and complexity that are worth considering:

1. Since WASM doesn't yet expose a feature to share GC with the host, the GC functionality with necessarily be bundled with your outputted code, making your WASM size larger than ideal.

2. All calls from WASM have to go through a JS layer in order to interact with the Web APIs anyway, so now you actually have _two_ GCs to run.

3. The developer experience is going to be poor unless you write a shit ton of wrappers for the existing DOM API.

I say the above not to dissuade you, I find WASM an attractive value proposition and use WASM in all sorts of ways in personal projects. Good luck

I'm not bothered about GC's - the size is a problem, but I've never had to worry about GC performance issues yet.

Everything else is spot on, that's the pain!

You probably know about this, but it might be worth trying TinyGo[0] for WASM, given that WASM is basically an embedded environment.

0: https://tinygo.org/

No viable alternative to JS/TS for web (client side) unfortunately.

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?

Getting proficient with Go has been the best move of my career to date. It's such a productive language, and you don't have the same drowning in dependencies problems whatsoever becuase the stdlib and a few packages around it are just so strong. I like being able to show off a very small go.mod to a boss who's been putting up with NPM hell for the better part of a decade.

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.

You're just lucky to work in a company with a good codebase. I'm sure there's plenty toxic environments with shitty codebases written in Go where you wouldn't like working there at all. You're giving too much credit to how much the programming language matters imo.

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.

> 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

If the company is doing anything web related it will have JS people somewhere right? And it might also choose to make everyone full stack (so doing both Go and JS) or making some of the teams hybrid. That's quite common. I don't really see much difference between a company that chooses Go to a company that chooses Node (or Ruby, whatever), they both have their pros and cons and it doesn't tell me that much about the people I'll be working with.

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). It just works! There is also a huge eco system of good quality open source libraries compared to some of the newer backend languages.

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.

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 think we have different ideas about what a good development environment is, and that is ok. We have our preferences and we can't argue with that.

I would like to comment on how you feel Java compilation is slow. Incremental compilation while developing is fast and doesn't affect my productivity (your experience may differ).

Triggering a single threaded full build with one of my services (1000+ files and 80k lines) took less than 30 seconds on my laptop (18s with parallel compilation). But I never do that locally, as incremental compilations are almost instant.

If you need to download dependencies and run tests, the number is higher, but that is not specific for Java

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.

Take this as constructive advice: stop expecting your job to be fulfilling.

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

Great advice

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

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.

I’m sorry you got laid off and i understand you may feel down right now, But there are a few things in your comment that are concerning.

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.

What you're describing sound like the challenges that come from working at a big company. In my opinion you have a few options; each better suited towards different levels of burnout, which I believe you might be experiencing.

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.

I'll contribute by telling an anecdotal story.

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.

You can write in JavaScript without any frameworks and libs. The language itself is pretty self-sufficient.

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.

You hate work, not programming.

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.

Are you willing to share any more details about how you made this happen? A lot of what you wrote really resonated with me. There's a side project I've been working on for 2 years (and hope to monetize soon) and even though the honeymoon phase of "new project" is well past, I still am so excited to work on it every day.

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.

The trick is to get lucky once. There's nothing more to it. It was a work of love that panned out.

If I had to start again tomorrow, I'd probably really struggle to reproduce that success.

That's a very honest assessment, thanks. Hope to be in similar shoes to yours one day.

And I hope to stay in those shoes until the soles fall off. Once you have a taste of that life, I don't know how you can attend another Scrum meeting.

> Should I just switch careers?

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.

Switch to work for a small company where you can focus on your code and choosing your solutions. I've seen a lot of people around me working for large companies being well payed but also really unhappy with their jobs. Money will not buy you happiness.

Explore switching development focus away from front-end.

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'm an older developer and I do feel much of the pain of what you are talking about, especially with regard to frameworks/libs getting so abstracted as to be painful to learn and deal with effectively.

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.

This reads much like "I like welding, but I hate working on an assembly line". Those things you find annoying are things that help make the process streamlined, trackable, repeatable, and you fungible. Of course things are more fun when you are guided by your own flow and direction... but how does that scale to hundreds of employees? It's the independent flow of programming that I fell in love with, and that I now realise I'll never really get in a workplace.

Assembly lines are for robots/automation...if you need more time to organize the assebly line then to weld...well better then dont use a assembliline.

Over all your example is flawed.

Sorry but you are the robot, just with wetware instead of firmware. The robots on the assembly line spend more time moving than they do welding.

A robot would go forward a makes something that brings money/energy and not wasting time by answering my comment ;)

If you think humans are robots then tell me why we have feelings and not just laws/rules.

Harari and his "Homo Deus" has a bit of your mindset, and i think he is totally wrong (for the future).

>The robots on the assembly line spend more time moving than they do welding.

Yes and humans spend more time breathing than programming, again your example is flawed.

I feel you on the pain of coding. It's a big reason I shifted to management. And it turns out, after a few years of getting my feet under me, I quite enjoy it.

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'm in a job now that mostly involves bare Linux network programming in C. The only dependencies are CMake, VS Code with C/C++ plugin, and the regular Linux libraries. No "sprints" or "Agile" or "tickets" or cruft like that - just delivering incremental value to customers at a reliable pace. Gosh I love it and it brings me straight back to my happy place. I once worked a job adjacent to modern web development and front-end stuff and man, that stuff just sucks and is not fun.

I don't have exactly the same problems - our dev stack if pretty old fashioned but works well (dotnet). I don't enjoy it as much either though, most business problems are either easy + tedious to resolve, or involve making a complexity tar pit even worse. Naturally you'll end up spending almost all your time on the latter. Add on top a lot of interpersonal tension from there being a bunch of almost equally good ways of doing any one thing and it's easy to see why programming can stop being fun (while still being a decent profession).

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?

I think it's perfectly normal to want to do something else after you've been doing one thing for decades. Humans like variety, the "mid-life crisis" is a thing for a reason. I think IT work in particular is tricky to escape, because it's such a large step down in pay to switch to another career. People end up stuck here for longer than they ought to and burn out or coast, because they don't want to take the pay downgrade to find a new career path.

You're right that it's normal to feel that way, and it's all true that IT is a trap in some ways.

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.

Consider that "being in love with programming," is an odd thing to say. Love is an emotion best reserved for the people in your life that you could never live without. The act of programming is a means to an end.

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?

I agree with you when it comes to programming-as-work, but hard disagree about not being in love with a process/activity. People fall in love with playing/creating music, writing, gardening--whatever it is that nourishes their creative and nurturing spirit. In fact I would say that if you don't love the process and are only interested in the outcome, you're doing it wrong. "The journey is its own reward" and etc.

I've been programming since I was a kid. My professional career is more than twenty years long so far (and counting!). I still program every day. I stream myself programming once a week. I enjoy programming.

Sure, there are those who enjoy programming from a purely intellectual point of view just as their are mathematicians who focus on pure mathematics. It can be rewarding in and of itself.

But I still reserve love for relationships. I don't believe you have to love programming to be good at it, to enjoy it, or to do it properly. It's a technical skill, there is plenty of research to do, etc: but it is something you do because you choose to.

Framed in this perspective, when you are not satisfied with programming, it is not because you are, "falling out of love." It is something else: the work, the process, the tools, the project: something is not giving you a sense of satisfaction, reward, etc. Not enjoying it is not a moral failure or a breakup. It's because the tools are crap, you don't believe in the project, or you simply enjoy programming different things than what you are being paid to develop.

No need to go off into the woods with these romantic visions of becoming a cabinet maker in a small commune.

If you want to continue to enjoy programming you have to compartmentalize your feelings, manage it, and nurture it like a skill for the long term.

Sure, I remember programming on the Amiga 500 in the late 80s. It was neat. Fun. But also severely limiting, frustrating, and lonely. It took a lot of work to get machines from that era to do basic things we take for granted today.

The first programming language I learned was not the first language I used professionally. The first language I used on the job is not the language I use today. The technology changes. Things develop and programming today is a lot more open, free, and accessible than it was when I was growing up!

If you fall in love with programming and it doesn't reciprocate those feelings for you, you'll be waiting around forever. You may end up frustrated or hurt. Annoyed even. Jealous when it seems like it comes more naturally to others!

You aren't fed up with coding, you are fed up with implementing someone else's idea of coding. Frameworks are helpful. They allow you to get up and running; to leverage other people's work. But you aren't solving anything. That's why it isn't fun.

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!

I doubt you hate coding. You probably just hate your job, I know I do. In fact, while it has taken me 8 years, I have come to the realization that I hate all jobs. I hate that someone is getting richer off my back while at the same time destroying any passion I have for something that I have always been passionate about. I hate the entire industry. I hate working with other software engineers. I hate having a manager. I hate having OKRs. I hate everything about having a career.

That’s why I’m going to get out of it, I’m going to make sure of that.

I used to have that feeling too. Getting out of the work loop was the best thing I did, luckily in Finland it was possible due to the support system here, so I was not left all on my own.

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 work at a small software business run remotely and staffed mostly by older workers (50+), myself included. There are very few processes to speak of. We meet a couple of times a week, we have one application to hand out tickets, and another to clock in hours worked. That's about it. The pace is leisurely, the tech stack is a bit old-fashioned, but we build solid products, and the company stays afloat. And I get lots of freedom to build things the way I like. Not perfect, but good enough.

It only addresses one part of your concerns, but I seriously think in javascript/web land the pendulum really is starting to swing back the other way.

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!

It's okay. Soon it will all done by A.I. /joke

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.

Actually I agree that AI could solve a lot of these problems, no joke. That's on the roadmap for InventAI (https://inventai.xyz).

>I now understand why there’s a trend of developers who want to go live in a farm or take up woodworking

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.

"I code in the winter."

I applaud you. I sleep in the winter.

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

you're like a bingo card rolled up into a single person. I recently used my circular saw, multi tool, and drill for my first real project(mounting a hangboard on my ceiling joists) and it was immensely satisfying... I see the allure but I'm definitely wearing gloves next time. my hands are all cut up from driving the screws

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.

> I work mostly with Javascript — and that doesn’t help.

Yup. I would even say it's probably the root cause. Stop working with JavaScript.

I can't personally say with any sort of authority if JavaScript is the root cause of OP's dilemma because beyond a brief stint coding in JavaScript for Yahoo Widgets on early "Smart TVs" (due to a rather unexpected series of events) I haven't used JS regularly for any extended period of time, but I can say that I'm 49 and still really enjoy coding (these days mostly in Kotlin/Android and Go), so I can say falling out of love with coding as you age isn't universal.

The day I opened my own business and started doing C2C work was the day I was able to deal with the whole "red tape" thing.

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.

I don't live in the US nor work in tech, but I am wondering - have the big tech firms been doing much juniorization lately as part of the recent recruitment spree?

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.

This is how I felt until I started doing functional programming. Not FP like category theory and such, just working with simple data and functions. Less powerful languages like Elm or more pragmatic languages like Clojure are great for this.

Are you sure it's the code and not the organization? I love coding but everything about shipping software makes the programming feel so devalued. Coding is an art and companies don't care about art, they care about money. Mix that in with Agile and office politics and everything seems to be about the act of shipping instead of the software itself.

I'm 40+ yo, work for a faang, and feel the same.

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.

One of the things that bothers me lately is that the "tools" (libraries, frameworks, documentation, toolchains, baked-in enforced brogrammer conventions, questionable service lock-ins, etc.) are usually in many ways poor-quality, poorly-designed, and inferior to what I've used in the past.

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.

> so many open source projects now base much of their communities and support around Discord

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?

Moving to a farm or giving up on the industry for this is basically saying the tools are hurting more than helping.

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’ve completely been there. I burnt out hard, not from overwork, but from this type of stuff. I started to think maybe I enjoyed software engineering but not the business of software engineering.

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 recommend doing "minimalistic software engineering" - an approach when you use as few technologies as possible and prefer something simple (that is easy to accommodate in your intuition) that works out of the box.

I've made a presentation about this approach at FOSDEM 2023: https://presentations.clickhouse.com/fosdem2023/

(the video will be published soon)

"Beware of looking for goals. Look for a way of life. Decide how you want to live and then see what you can do to make a living WITHIN that way of life." —Hunter S. Thompson

There are plenty of ghosts in woodworking, some will ruin the piece you're making, and some will ruin your day and send you to the hospital :)

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

About 6 years ago, I was in a very similar place and it motivated me to get into management so I could focus on cutting through that red tape for my devs while escalating the problems caused by it to higher ups. I realized that if I could help people work 5% more efficiently at even a small company, it would outpace the value of me trying to work 24 hours a day as a single programmer.

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

You are anxious about things constantly breaking, and you work in Javascript. No surprise.

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.

This is my approach to solve this same problem for myself.

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.

I do feel like technology has let the public down. Ransomware, identity theft, fake news, social media, etc. Things like memory safety used to be discussed in the most technical of circles. However computer security is impacting society as a whole, seems like the entire planet has had their identity stolen. Now Congress, NSA, CISA, and even Consumer Reports are discussing memory safety. Sure Rust is a small piece of secure computing, but it's a step in the right direction.

That's a stupid piece of advice floating around "Choose a job you love, and you will never have to work a day in your life". That's the problem.

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.

I hear you! Transpiling, bundling, CSS in JS, image imports, hooks, dependency hells, huge stack traces, the list goes on and on.. Such a mess.

I can totally relate to "keeping up with the Joneses" when it comes to new tools, frameworks and trends. JS world is full of new crap to "compensate" for the lacking of older crap. I wish there was some sort of a consortium or standards body to review and sponsor new initiatives. If you have a new idea for "better" JS anything, great, apply to the consortium first to get grilled and polished before being able to release your thing. Sometimes red tape is a good thing.

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!

Hello mate. I learned to code at 13 like 20 years ago as hobby. 15 years ago I started building digital product/startups but sadly no one took of the ground. 10 years ago I started my first job in software development and yesterday was my first day as pizzaiolo. It was a hard take, my income is now cut by at least 5 times but my happiness is higher than ever before. I closed down the door no to coding but working on tech. I need to shut down the computer for a while to feel back the love for programming/building digital stuff. I ll be back to coding to work on some side hustle while having fun and not for a f*cking salary.

I feel so happy reading this. I hope you enjoy the new job and find contentment!

I remember vividly the times when I was so much impressed of every single line of code I've written that day. I would stay up late at nights just to make the perfect piece of code, the perfect UI, the perfect architecture diagram, etc etc. To me, that feeling was life-giving.

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

I'm currently fighting with poor README instructions on how to get a project up and running locally. It's been a couple of hours already and I just want to code, not fight with these tools.

I moved back to an IC/Architect position at a BigTech co and I now have the opportunity to code again if I so choose but I honestly can't stand to work through the boundless configuration and plumbing hell it is. If I decide to take on a personal project in my free time, I feel 100-1000x more productive than I would ever feel in the corporate setting. I would say I fell out of love with enterprise code years ago and I would almost certainly have remained a manager if that was my only option as an IC.

Honestly try out dotnet, especially on Windows VS (which actually works really well with Windows Subsystem for Linux these days, so you can run it easily on Linux).

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.

Yeah I felt the same way working on Angular 4 or 5 years ago. .NET though is just freaking easy and works well.

It seems like the SPA trend is slipping away which I think is a good thing.

I met a guy in the forests of Canada who was riding around on an ATV with his dog close behind.

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.

You're mixing coding with industry. Coding (aka "happy hacking" - RMS) is so much fun you can't fall out of love with it. Industry often boring. Once you make this distinction you won't go back.

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.

> I feel like I have to jump so many hoops and spend so much mental bandwidth just to get the permission to code.

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.

There's always the risk of losing that passion when you do something for money. It's an old cliche. It's especially difficult in an organization with all the red tape and other constraints.

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 work mostly with Javascript — and that doesn’t help.

I read it really quickly, but different language, different org that's more flexible? Try out a few different ones?

We're all suffering from vendor-driven-churn. That is, Apple or Microsoft or $BIG_DOG says you have to do $THING. Somehow your early stage business got caught using $COOL_FRAMEWORK and now, rather than coding logic you're fighting the framework. Some folk blindly follow the "never build what you can buy" but then spend so much time fighting what they've bought.

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!

> Nowadays, I feel like I have to jump so many hoops and spend so much mental bandwidth just to get the permission to code.

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

Been there, felt that. Have you tried learning a new technology just for fun? When I got tired of PHP, switched to Ruby and the love and feel of wonder was there. When I got tired of my corporate job tech stack, I looked for a freelance side gig where I now spent most of my time and weekends because the challenge is fun.

Maybe finding a side project you actually like and understand can help.

I had that feeling about a year ago, sat down with some fun hobby project and the love was there instantly.

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.

It seems like the type of coding you do at work is the problem.

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.

As a solo founder with a TypeScript/Next.js site I feel the opposite. Going from coding to production almost feels like cheating. Edit, test, publish. No red tape, only facing direct feedback on success or failure. I realize you probably cannot debloat your stack or procedures but there is still joy and productivity in web development.

Something shifted in the last ~5 years in a big way and devs are infantilized in a big way. Product and project managers trying to over plan and over control has been something I have dealt with.

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.

Have you tried consulting? There are tradeoffs but when you get to make your own decisions about the tech being used it at least lets you have a sense of agency and control, and you can pick whatever makes you happy and gets the job done.

I feel you though, it seems more and more frequent that I dream of moving to Montana and living on a farm.

Programming is tedious when your implementing someone else's vision, thats why I stopped doing it professionally. I still write a ton of code to make my life easier but since I'm not a developer by title I can pick whatever language and tools I want. I often use SQLite just to keep the DBAs out of the picture also.

What do you do now? Are you happier?

Also interested.

There's a big swing back and forth between software as an empowering tool and software as a tool of control. I think in the age of big platforms we swung hard into institutional control, and the swing back to individually empowering tools, if it's started, hasn't reached momentum yet.

I've completely detached coding for fun and coding for a client/employer. For fun? I write (almost) everything in a single file or however I seem fit, git commit -am "asdf" and use a bare-bones deploy script on a 10$-or-so VPS on which I can ssh and update an nginx config manually if I want to. For work? I jump through whatever hoops the latest CI/CD Kubernetes configuration expects from me, combined with a multi layered microservice architecture and write enterprise-grade Java with Amazon Managed Grafana monitoring in HIPAA ISO SCAMPI compliant environments.

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.

The comments have covered red-tape/bureaucracy pretty well - and I agree that could be a big part of the problem for any programmer.

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 :)

Find a side project. Something not involving web stacks and Javascript. I recommend one of these platforms, which trade off complexity for power to varying degrees:

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

Imagine you want to build a City

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.

More like, you come to C, rebuild a worse C because reasons.

A couple of simple suggestions:

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.

[1] https://projecteuler.net/about

[2] https://store.steampowered.com/app/1812820

From the sound of it the problem is less about making software and more about your job. A piece of advice that I have seen crop up a few times on this subject is to figure out how to distinguish what you do from where you do it. Programming can be a job and and it can be a hobby. In this context it is easy to let your hobby become your job and then your job become your hobby, which can quickly lead to burn out once your job starts to suck.

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.

Nowadays, I feel like I have to jump so many hoops and spend so much mental bandwidth just to get the permission to code.

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.

This is exactly why I can't work at a job in the industry.

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

[2]: https://news.ycombinator.com/item?id=34662666

How do you sustain yourself in the meantime? Or do you already have a business?

From his comment it sounds like he does jobs driving commercial vehicles (such as trucks or passenger transport). I got this from the mention of a "CDL", commercial driving license.

That's just my backup plan.

My wife is currently the breadwinner, and I'm the housekeeper, gardener, handyman, etc.

My man out here living the life we all want.

Heh, it's not as great for me.

It's actually depressing for me that my wife is the breadwinner. I want to be able to do something.

Join a start up or start your own company.

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.

Others have mentioned this being a Javascript-specific problem, but it really isn't. I think there's probably a lot of money in building realistic software models for learning. Maybe not full-production but at least realistic use cases beyond todo apps and author/book examples.

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.

"I’d rather fight with my brain than with the tools I use."

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.

You haven't fallen out of love with programming, you have grown disenchanted with The Love of the Toolchain. The almighty toolchain, long and powerful, and you Cannot Program Without It (nevermind actual history). The check-in, check-out. The issues and the Jira boards, or any kind of boards. And then there's probably a lot of Agile junk to go with it.

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.

You're describing a set of problems that are very narrowly about Enterprise IT and the React ecosystem, not about "coding" writ large. If you want to build things instead of integrating SaaS, go work for a cashflow-constrained startup where engineering time is an easier constraint to flex than buying expensive multiyear SaaS licenses. If you feel like your JS tools are too opinionated, try working with Angular where there are stronger guardrails about the "right" way to architect things.

And if you try that and still hate coding, I highly recommend plumbing!

I became a manager, and my company actively tried to get me to stop coding, when that happened.

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.

I am self-taught and have been working as a software engineer for about a decade. I have this feeling come up a lot as well. I miss the days of when I was working on projects for myself, learning new stuff constantly, spending hours trying to figure something out and the mental rush you get when you finally get something working.

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.

Not forcingly. You may switch to a different language, not plagued by what it is called Fragmentation. Give yourself this chance. I am experiencing your same feelings since long time. And I found a new job that will bring me back to my lovely days of IDE and coding. Good luck

Middle management usually doesn't grasp this complexity and apart from safety critical applications things are usually not tested enough. Being an embedded C programmer I didn't have this feeling at all, where every small feature was tested for 3-4 months in a simulated setting and another few days in-car. Being a web dev is completely different mentality (management and testing wise), since generally there are no real-life consequences. Add monitoring, and test some more on your own.

Get out of javascript and start enjoying life again. A different language would be a different community / different types of jobs.

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.

This is one of the reasons I have stayed at my company for 21 years. Many times I have been tempted by the greener grass on the other side of the fence, but it seems to be such a random crap shoot if a company is going to be a good experience or not. Is my company perfect? Of course not. They do allow me to actually focus on "real work" without an excess of ritual. I am able to work 8 hours and have a clear mind at the end of the day.

You're at the very top of a deeeep stack that reaches down through the browser, out to system libraries, into the kernel, out through proprietary firmware to hardware devices. There is a lot of diversity in tech, maybe it would help you to explore the full depth of that ocean and reach down to the sea floor and up to space. Most of the stack now has open alternatives that explorable by individual developers.

I feel the same way when I'm in a position like that.

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.

I feel the same and think that globally no industry is the same even compared to 5 years ago. But most importantly programming became from a niche job to a mainstream one which translates to more bureaucracy, less freedom, less ideation, more following the rules. At the same time dev tools became new business niches so rather than following standards its now a commodity.

I know its difficult but we should all try to appreciate our jobs and look at the bright side of things. I know its not all roses but consider that with the tech recession, budget cuts, offshoring and now tools like ChatGPT/AI one cannot take for granted being hired as a developer and getting a decent salary (in some parts of the world way more than decent).

If you're American, and getting only 2 weeks vacation a year, all you might be in need of, is a month or two road-trip and a new role (whether a new coding job entirely or just move team). Maybe ask for a short sabbatical in that case? So many Qs like this on HN, it often sounds like people just haven't had the right , decently long, vacation in ages.

It might be good to decouple the work coding environment vs. the coding activity itself.

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.

Maybe try to transition into a different corner of the industry. E.g. Something like embedded programming. The tools there have become much better over the years. And it is not as much of a moving target as JavaScript. Totally possible to understand every aspect of a microcontroller (or at least know where stuff is in the documentation).

I left frontend engineering for similar reasons. There was a lot of hype in a culture that seemed obsessed with the next big thing to what end I couldn't quite figure out. I blame webpack.

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.

> ...spend so much mental bandwidth just to get the permission to code.

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.

Maybe you want to try out Assembler programming/assembler-alike-freedom or write your own prog lang

I would suggest to switch career to embedded or mobile development. As a mobile dev, I feel like my environment is quite solid, and will not change that fast, and I don't have to track that many external tools, yet, I code daily, and mostly think about code and architecture.

You should try to dive into Math and Statistic. Maybe you can find comfort in the beauty of simple and elegant. To be honest, programming is a lot more interesting after you learned maths.

if i were to read a bit between the lines here, i would say i detect a code smell and that the real problem isn't so much that developing, testing, and deploying code requires multiple services, not to mention gathering analytics, but that the basic code structure is unmaintainable. you have a lot of badly structured legacy code that has broken before? that causes developer anxiety.

as a freelancer i have fled from one project due to code base complexity, consistent need for hot fixes, and developer anxiety

Hey there, it sounds like you're feeling the burnout from being a software engineer, which, after working with lots of engineers in the past, isn’t that uncommon. It's totally understandable, given how fast the technology and tools are changing and the amount of time and effort you have to put in just to get things working.

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

If you don’t like the JavaScript vibe, why not try a different domain? Work for a bigger company, or a much smaller one, doing something else. Maybe get into data engineering?

Well you should probably start by running far and fast away from shops that use languages like javascript :) The "tooling" around javascript is just horrendous.

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

Then go do that bro. Life is short.

DevOps does this with me. Code = happy. DevOps = disgust.

Try JIRA, once you implement JIRA in your org and set-up some company wide policies on fields and tags, your will to live will return.

I absolutely agree and feel the same, but you sound like you still enjoy programming, and I think you should not switch careers.

Those sound like problems specific to big corporations. Maybe you'd better enjoy working for smaller companies.

What you are experiencing is the post-2000 tech world metastasising into enterprise. But now in Corporate Memphis.

Sounds like you need to work for a smaller company. Why don't you look to get hired in a startup?

It happens in ALL industries and fields, from art (music, design, painting) to software development.

I don’t think so; these things you name but also physical jobs like electrician etc don’t have this ‘new shit to learn every day’ while it doesn’t actually help getting anything more done (the opposite actually). There are plenty industries and fields including art where you can do your job with the same tools (physically the same tools even) you were using 40 years ago. In software I am getting berated by strangers when I want to do that (‘it is morally wrong to use C in 2023’ and crap like that).

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.

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.

Do some fun projects on the side. Or switch to a small company. I did both and am much happier now.

I was working on my own project. Medium-sized, a full-stack web application that I'll release somewhere this year. It's a Next.js front-end, I did all my own CSS and optimisations, semantic HTML, accessibility, load performance, TTI optimisations. The CMS is a headless one that I use Next.js to connect directly to the database with. It's hosted on a server I manage myself, and I set it up so that a git push to the main branch would build and deploy the entire thing.

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.

Coding has been embraced and extended. Has it been extinguished?

The likes of chatGPT seem to bridge the gap between the last two steps.

tl;dr you probably just work on projects you don't like, not that you don't like coding. Been there, done that. Nothing new under the sun. Those people who say that you will never work a day in your life if you do what you love are foll of crap because having an option to do something and having to do something are two very different things. And having to do something you like doing is the fastest way to hate it. My advice is switch company and look for work that interests you nowadays. Like instead of working for a company doing e-commerce, go work for a company doing IoT, banking, healthcare or anything like that. Just change the type of work you do.

Go work for an (early stage) startup?

A few scattered thoughts:

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.

You don't dislike coding, you and all your coworkers work at a shit-tier company.

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.

Reply on news.ycombinator.com