Hacker News new | past | comments | ask | show | jobs | submit | page 2 login
I no longer build software (github.com/docker)
1287 points by tagawa on Sept 21, 2020 | hide | past | favorite | 856 comments

Totally on board with not building software any more. In fact, at 55 this is my last week of it. For real. Basically, everything sucks more about building software nowadays more than I remember it sucking before, from the mere mechanics of navigating through an obscenely large pseudo-object-oriented codebase to the WRONG constructs/idioms people use to build distributed systems to the way software is packaged and deployed to the horrific attitude toward testing or documentation to the biased interview processes to ... I could go on forever. I know some of that perception is mere nostalgia or other effects of my own age, but by no means all and I honestly feel less than half.

Building software was never simple or easy. We've gained a lot of knowledge that makes it easier because you don't have to build quite as much from scratch, but we've more than made up for that by making it unnecessarily hard in every other way. Taking the simplest change from idea to production involves so many steps, and not even the steps that assure it's correct or maintainable. It's feeding the beast we built ourselves rather than the one born of necessity.

I sincerely feel bad for people who have to stay in it. Some day most of you will get over the dollar-induced Stockholm Syndrome that seems universal among junior developers, but by then you'll be stuck on that train to hell. Good luck to you.

It goes without saying that your feelings are personal ones, totally valid, and nobody can really question them.

I'm 20 years behind you, and I don't know what effect that will have on my views. But I don't really recognise the picture you're painting. Compared to the first steps I took as a developer about 15 years ago, almost everything about software development seems better to me. I find developing software to be easier, more consistent, and less frustrating than it used to be. Good development practices—things like testing, CI, coding standards and so on—seem more prevalent than they used to be. It's easier to get code out to production than it ever was. Everything in the ecosystem—like tooling, libraries, and services—feel far more open, consistent, and accessible than they used to.

I am almost certain that on the whole I spend a far greater proportion of my time now actually writing code that does interesting things, as opposed to code that hacks together some junk to try and make it work with other junk.

I think I'd draw the conclusion that everybody's opinion on how the industry works is going to be heavily influenced by their individual experiences. Maybe I just enjoy software right now because I've now got the technical competence and confidence to avoid some of the frustrations that I experienced earlier in my career, and in another 20 years I'll be right there with you lamenting the state of the industry. Who knows?

I think you are right to say that the methods are vastly improved, but the ends to which those methods are applied have become ever more uninteresting (for a lot of people), and often morally suspect. We have built exquisite tools, but we use them to extract profit, to manipulate behaviour and often for no discernable purpose at all.

Programming has become joyless.

There are ever-shrinking spaces where a developer gets to build something novel - something that's state of the art, that's creative, that taxes their intellect and brings the pleasure of achievement forth. It seems that for every developer working on rocket guidance systems or self-driving cars there are a hundred toiling away on yet another CRUD app, or wrestling with a hydra of microservices. It pays well, but fun it is not.

Not to mention that those CRUD apps have been done, exactly the same, 10000s of times before and 10000s of people are doing the same work you are doing now at this moment.

Everyone thinks they are productive but value is being burned all day, every day in most companies all over the world. The level of reuse is depressing and people, especially here, firmly believe we need to use the latest frontend and backend crap to rebuild what was working perfectly fine before.

More and more everything appears resume driven and to extract more hours billed or even higher LoC or commits per day. It is a nightmare and I refuse to play more and more. The over architecting for shit one off projects burning 10000$s a month ‘in the cloud’ so it probably, maybe it won’t crash with the 5 users per day it has using it.

Yes the tooling is better but the drive to use every latest tool and tech really makes no sense for almost any project.

Fitting anecdote; a company from LA was contracted to build a crud app for a big corp; they used react, typescript, node, express, aws, aws lambda, redis, dynamo and rds. For a crud app. They got $50k for it. For a crud app. Costs were through the roof running it as you need actual good people to run it. It failed a lot of times for such a setup as it was all the latest of the latest architecting wise. Brittle as hell even with all the tests and resume driven busywork. I rewrote it 1 php + bootstrap and jquery file in 1 day with a perl script to migrate the data and running on a 1.99$/mo server. Cheap, easy and no worries; handles a lot of traffic for the cost of a cup of coffee, does not need devops and they paid $2k for it to me. This is not the only story; microservices + serverless + the cloud really are excellent for making money, but as you say, no fun and in my experience, no benefit. Just added complexity.

Unfortunately there are a lot of people around these parts who have arrived at the conclusion that the only way to build software today is using all those services and more (I mean, where's kubernetes in that stack?). They will aggressively defend their role which is no longer about creating software but instead entirely about weaving together a myriad of components.

Playing with legos is easier then delivering value.

Playing with legos is delivering value. Reinventing the same wheel over and over again is not.

What's often missed here is that the problem the lego is slotted in to is often subtly different each time. So you have a guy building an 8x2 lego brick that slots perfectly into his mansion and then someone else really needs to cut a corner off of it to fit their problem. But the original designer never gave you the option to do that so now you have to write an adapter to plug the 8x2 into an 8x2 without a corner.

It only looks like reinventing the wheel every time if you're completely ignorant of the subtle differences of each problem domain. And if you make a bunch of changes to create arbitrary lego bricks then now everyone has to learn your brick framework before they can make an 8x2 brick.

I agree. You have to know your lego blocks well and understand where they fit and where they don't. But if you choose to remain ignorant of the available lego blocks, and instead write everything from scratch every time, you're wasting a lot of effort.

> But if you choose to remain ignorant of the available lego blocks, and instead write everything from scratch every time, you're wasting a lot of effort.

That's a good seam upon which to filet this analogy. A quick Google search turns up uncertainty as to how many different bricks there are. It could be in the 3000s, 6800s, or over 12000. We are all ignorant of the available lego blocks.

I'm not entirely sure what you mean. But if we're talking about AWS cloud services, there are certainly AWS experts who know how to develop software in a cloud-native way and utilize most or all of the relevant services. That knowledge is what we are paid for. It's also true that there are a lot of AWS services available and expertise is divided into different specialty areas, like ML, IoT, etc. Hard to be expert at everything.

Agreed but that is not what is happening though ; people do both; they use legos and reinvent the wheel. Making everything, imho, worse.

The authentication thingy you got as lego block did not quite fit and now you are using more code than the module has in it to add what you need for it to do, making the original module probably impossible to upgrade without a lot of work and creating a problem for maintenance. Now you can fix this by telling your client; ok, I won’t do this because your idea of auth is wrong. But then the client might kick me out (probably not a bad plan if they are doing trivial things significantly different than the rest of the world). I can just implement it like I mentioned above and make money maintaining it (risking having also to maintain the original lib). Or I can just make a new lib and for which I know it does what it was.

Then, my favourite option, is just take something that just works already, deploy that and adapt a few people their habits around it. It fits 95%, stop whining. The least popular option ofcourse, so there we are, creating slightly different wheels with millions of almost the same LoC and unused andor unmanaged libs that should not have been written or used, again, imho.

I have different experiences. My "lego blocks" are AWS services. Each service is a black box that maintains its API backwards compatible forever. My custom stuff is built around the API and keeps working forever. ( * ) In my view AWS has been very successful in maintaining this backwards compatible model even when they often add new features to services.

There are sometimes edge cases that are not possible to implement, but they are rarer and rarer as the service portfolio grows. In those cases the only option is to write your own container and deal with the usual package-level dependency issues in whatever programming language you use.

( * ) The only thing that doesn't work forever is Node.js, which is deprecated every few years and needs to be upgraded to a new major version. I'm looking forward to the possibility of WebAssembly/Deno replacing Node.js as an "evergreen" application platform.

What are you paying though? The most common reason I get pulled in is because of exorbitant aws bills which eclipse dev bills... This sound expensive.

In the past 5 years all my projects have been based on AWS Lambda, API Gateway, S3, DynamoDB and other serverless technologies which are only billed for actual usage and network traffic. So they don't cost much unless they actually get heavy load from users.

I love how the justification of numerous AWS services is always "so it can scale" but if and when that scale ever happens, a new architecture is necessary because the costs become untenable.

I haven't seen this happen myself. In projects that I've been involved with, the justification of using serverless services has been to reduce development costs, because you don't have to setup and develop everything from scratch and spend effort maintaining the infrastructure. The ultimate goal is to avoid doing anything else than define the business logic that is unique to the project.

Is it the same wheel? It sounds like you wanted a Honda Civic, but you used the wheels from an Abrams tank. So obviously the solution is to invent a tank wheel <> Civic chassis adapter layer?

>They will aggressively defend their role which is no longer about creating software but instead entirely about weaving together a myriad of components.

Same thing is happening with mechanics. Young mechanics repairing parts less often, more handing off parts in need of minor repair to specialists and a focus on fitting parts.

Kubernetes is amazing when engineers need it.

Kubernetes sucks when managers need it.

Never underestimate the number of engineers that convince themselves they need something because it is trendy and sounds cool.

I'm so tired of React being thrown into every single web stack as of late. You don't need some large React boilerplate mess, that could've been done with some simple PHP+Jquery stack. It's caused this SPA nightmare also, where you have a large delay in page loading, when it's a site with basic functionality.

> Not to mention that those CRUD apps have been done, exactly the same, 10000s of times before and 10000s of people are doing the same work you are doing now at this moment.

And yet now OP is making wood furniture, which has been made before the same thousands of times. Some people need originality some don't. Some just like the work for its-own sake. For those who need originality they should find a job working on something that's not a CRUD app. Not everything is a CRUD app. That's on them.

Sure that is true, but then again I have written many of employee directories, cms’s, erps, social networks, running apps, banking fronts and backends, insurance fronts and backends which were all exactly the same except forced in a different tech because of the taste du-jour. We wrote a massive insurance monolith system in c# and my new client wants it microservice and in TS/node. We will be doing exactly the same as 2 years ago and make a boatload of money while we have a working and tested solution. Almost all of this is CRUD with some calc sheets in excel which we did in the 80s, 90s, 00s and again now. The functionality is completely the same; even the screens have the same ux; ui is a bit updated. But the MS foxpro version was fine almost 30 years ago. Not my money though so what can I do.

Not sure how it fits wood furniture; you cannot copy a chair in a nanosecond; you can software. I am not saying there is no space or need for bespoke and unique software but if you are doing LoB apps for/in a big corp, as many of us do daily, chances are there is a) a perfectly fine version already running in your corp somewhere and b) a completely identical product in all the companies around the block.

> chances are there is a) a perfectly fine version already running in your corp somewhere

You and I have very different experience with big corps :)

My experience is closer to "There's a half-finished version running somewhere that was cut short because of budget/deadline constraints. The team that worked on it is long gone, and it has been maintained by an outsourced team of junior resources for 3 years".

Re-writing a customer-facing system to be closer to the "modern" web experience they're used to on their everyday apps and sites _can_ make a substantial difference to customer experience, and ultimately the bottom line.

> Not to mention that those CRUD apps have been done, exactly the same, 10000s of times before and 10000s of people are doing the same work you are doing now at this moment.

I recently worked for an org that had quite a large software suite (internal system) that was 99% CRUD. For every single CRUD operation, there was a front-end call, to a back-end service, that called a specific stored procedure. So pretty much 4 stored procedures for any construct stored in the database. No ORM, very little dynamic building of queries, thousands of database tables. Releases were a nightmare, change management for database objects is its own complexity, especially with so many objects. I think people were open to change, but with a decade of existing data structures+data, and a long list of projects, nobody wanted to make a change...

My one regret, with respect to that org, is not driving the necessary change.

The recent (modern startup, hip and happening and VC invested company) I built a CRUD frontend for has a lovely system: mysql but the db is not relational: 1000s of tables matching the Objects in their OO code. I have so many scripts and generators and, especially for mysql, introspection tools it was not that much work but what a horror show.

> The level of reuse is depressing and people, especially here, firmly believe we need to use the latest frontend and backend crap to rebuild what was working perfectly fine before.

This seems overly cynical to me; the reason software developers are well-paid (overpaid, some would argue) is that what they build is measurably better that what was there before (at least in dollar terms. I'm not getting into the moral quagmire of automation replacing human jobs ATM)

Code reuse is often a red herring, when taken to extremes. Here's a thought experiment: all software developers are now required to implement all CRUD software in SAP or Peoplesoft (pick one). How much of the code do you think will be re-used, and how much will be in the customizations?

$50K is kind of cheap actually. I've seen people pay $200K and more for basic CRUD websites with a little extra this or that.

In fairness, if your web app does more than CRUD, or if you expect it will in the future, then PHP and jQuery wouldn't be my first choice. I'm very familiar with how much of a mess an app can become when pursued that way -- a nasty soup of callbacks and conflicting states. As tooling around React improves -- and it's already quite good -- it will be easier to cost-effectively write a React CRUD site.

If you just want a CRUD site that works, and you want it fast, a Rails site with scaffolding will probably give that to you in an hour or two -- with almost the whole hour being spent thinking about your data model.

Unfortunately I agree with this. A great quote I saw a while ago:

“The best minds of my generation are thinking about how to make people click ads.” –Jeff Hammerbacher

Every paying software job I've ever had was in some way involved getting people to click on ads. Either directly making a product where ad click rate is a measured metric, or products that helped people make products where clicking on ads was a metric...

I have usually been able to find a lot of joy in solving the problems in the smaller areas where I was focused, but whenever I took a step back and looked at what I was helping work towards it felt very meaningless.

I think finding a job today where you feel like the work you do does genuine good for the world is an incredibly rare and difficult thing...

Have you tried... looking for one that isn't?

I've been in the biz for coming up on 25 years and I've never tried to make anyone click on an ad.

It also may help to downgrade "doing genuine good" from "solving the world's biggest problem once and for all" to "helping people get food reliably" or "keeping this industrial process that provides value to thousands of people going" and so on. Sometimes I do lose a bit of track of what I'm doing, but in the end the jobs I've worked still end up helping people do useful things, or protecting people, not making them click on ads.

There's a lot of jobs in programming that don't involve making them click on ads. Even in the heart of Silicon Valley, there's going to be a lot of jobs that don't boil down to that.

But you may have to, you know, change jobs.

I've never had a job convincing people to click ads either in about the same amount of time. But when I look at the salaries being paid by those companies trying to get people to click ads I think I must've made a mistake somewhere. Not that I want to have a job getting people to click ads, but those jobs pay like 2X to 3X the highest salary I've ever made (or more).

You haven't made a mistake. Those jobs pay highly because they have to. The phenomenon of soulless, not-great-for-the-world jobs being really highly paid is not a new one, and not at all unique to software - compare a celebrity plastic surgeon versus a doctor who saves lives after disasters, or a corporate attorney at a weapons company versus a pro bono lawyer who works for virtually nothing.

Full disclosure, I'm doing OK (not living in SV helps a lot), but, yeah, I'm not pulling down half-a-mil a year.

But I don't want to hate my job. I don't always love my current job... as I like to say, they're paying us precisely because this isn't what we'd be doing of our own free will... but I don't want to hate it.

Because it's more than just the hating the job. It's coming home every day to your family in a bad mood. It's your children associating you coming home with the guy in the bad mood coming home. It's being on hair trigger all the time despite your best efforts. It's living in a place I don't want to live.

The funny thing is, I look at that and I don't feel like I should be willing to pay $300,000/year for that... but apparently I am.

It's neither rare or difficult, exactly. The problem is how you look for the job.

Most corporations in the US that are for profit aren't about doing good, they're about making money, and publicly held corporations are even legally encouraged by US law to put the shareholders' bottom line first and foremost.

Non profits can care a lot more, but they generally (at least the ones that exist not) don't focus on something abstract like software, they generally serve an immediate need like affordable housing or surplus food distribution or job training.

Until the business climate in the US changes, about all anyone can do if they want a job where work actually helps people is either work somewhere they get paid enough to use surplus cash to help people or work for a non profit.

I think an idea that hasn't really been tried yet is building a non profit for software... not fitting a non profit base to an existing package, but building a corporation that is made to produce software for the public good.

> I think an idea that hasn't really been tried yet is building a non profit for software... not fitting a non profit base to an existing package, but building a corporation that is made to produce software for the public good.

Mozilla? Unfortunately, they weren't successful at creating new things of value (with maybe Rust being the exception).

I'm going to take a wild guess that you are a web developer.

I'm a happy low level systems developer. I solve hard and interesting problems that have nothing to do with ads.

Who are your customers? There are plenty of low level systems developers at Facebook and Google and so on. The solve the same hard and interesting problems that you do, probably at greater scale so they're even more hard and interesting. Often they're many layers removed from the people who directly get others to click ads. Being a low-level developer, or being at a separate company, doesn't necessarily put you at any greater remove from the advertising octopus.

I work in Fintech, our customers are banks and the like. They actually buy our software because it generates value directly instead of trading in human attention.

Maybe you think banks are just as bad as advertisers but I tell myself I am enabling the tens of millions of Americans who have retirement accounts. The day-to-day is enjoyable nonetheless.

> Maybe you think banks are just as bad as advertisers

Banks as in consumer banks? Maybe not. Commercial banks, brokerages, hedge funds? Welp. I admit that some of those have made my imminent retirement possible, but from a broader view I don't see much good about how large the US financial sector is compared to the overall economy or the preferential treatment they get from our government.

> I tell myself I am enabling the tens of millions of Americans who have retirement accounts.

I'm sure many at Facebook would say they're enabling small businesses and non-profits directly through advertising, and many more "little people" through the platform(s) that those ad dollars pay for. They're also enabling some very unsavory people and behaviors, as are most in fintech. Read the news lately? ;) Everyone likes to dump on ad-funded businesses. I've done so myself. It's not entirely unjustified, but sometimes it seems disproportionate and even hypocritical.


Interesting point you make: there is definitely selection bias going on because of this, but I've honestly never thought about it that way before!

> Every paying software job I've ever had was in some way involved getting people to click on ads.

That's an amazing fact.

May I ask how old you are?

I've been designing SOCs, DSPs, Control Systems and a lot of software for various systems since 1985, and I can only recall one that might have been close to "clicking on ads" (it was a personalized "on hold" system for dial-in to major retailers (like JCP), to replace Muzak with offers and information and stuff). I was the VOIP-to-Enterprise-Telecom integration guy, so not directly tied to the ad-part, but the company pushed couponing to their clients pretty hard.

Same. I am in the industry for 20+ years and thankfully none of my jobs have involved anything close to ads.

I'm 35. Luckily I'm now running my own manufacturing business where I get to work on a much wider range of stuff!

The quote should be

"The best minds that I know are thinking about how to make people click ads."

There is a considerable number of exceedingly intelligent people in pure mathematics and (theoretical) physics that don't work for Google, Facebook etc. and never would. Those that do often have nothing to do with Ads even three to four edges removed (think Martinis or the people at MSR).

This is true, but don't overestimate it. I know first rate math & physics types who gave up on academic work and now work at a FAANG or similar; and I know second rate ones who stayed. So it's a mixed bag.

>Unfortunately I agree with this. A great quote I saw a while ago: “The best minds of my generation are thinking about how to make people click ads.” –Jeff Hammerbacher

They're not really though. Ads may be the revenue stream but it's not like the top engineers at Google were on ads. They were building the search engine.

It's an amusing quote in the sense that it gets used by two people on opposite sides of it, and they're both wrong.

People that hate ads love that quote because they like using it to lambast the tech industry (in general, and advertising in particular), even though only a small percentage of engineers or other tech industry employees work on ads.

People in the ad space love that premise. You know what's worse than that premise? Admitting to themselves that they're not the best minds of their generation and they're still stuck doing work trying to figure out how to optimize ad clicking - the worst combination. At least they get to pretend they're the best minds of their generation, if they buy into the quote, that's a consolation prize.

The best minds are largely not working in advertising (maybe a small share of them are). They're figuring out how to leverage CRISPR to cure and prevent disease, or trying to figure out a therapy for Alzheimer's disease, or working on immunotherapy. They're the kind of minds that were working at Pharmasset figuring out how to save tens of millions of lives by curing hepatitis C. They're designing and building the next generation of semiconductors at ARM, Apple, TSMC, Samsung or Nvidia, pushing against the boundaries of what's physically possible. They're working on electric cars at Tesla or VW. They're trying to solve our battery problems. They're launching rockets at SpaceX or Rocket Lab. They're designing the next airplanes for Airbus. They're at NASA, ESA, JAXA, CNSA, heading to the Moon and Mars, or working on James Webb, figuring out if Venus contains life, and so on. They're designing the next generation of nuclear reactors, ITER or maybe working at LHC. They're working at Illumina, Boston Dynamics, Intuitive Surgical. They're in national and university labs all over the world, trying to solve very hard problems on a daily basis. They're even working on hypersonic weapons, military drones and designing nukes. And that's not meant to exclude the rest of this giant world, as the world is filled with examples.

>> were

If you meant to say that Google's top engineers _used to_ work on the search engine but nowadays they work on making people click on ads because that's were the money is, then I wholeheartedly agree with you

No, it's like saying the best athletes of our generation use their gifts to get people to buy stuff. That's how they make their money, but ultimately it's not what they spend their gifts doing. They work to be at the top of their sport and other people figure out how to make money on that.

Successful/rock star athletes spend 99.9% of their time honing their athletic skills and the rest on advertising deals. Google on the other hand spend 99.9% of its time on making people click on ads. Because that's their athletic skill? No. Because money.

The search engine built to make people click on ads (/tongue-in-cheek)

> Every paying software job I've ever had was in some way involved getting people to click on ads.

This is interesting, thanks for sharing that.

Of the nine organizations that have paid me to write software since 1993, only one of them would fit in your criteria.

Note: I am in no way doubting your claim, and I actually appreciate your perspective and the quote you cited.

I will more deeply consider that when categorizing companies in my mind going forward.

I have been lucky enough to work with a lot of great people, and I definitely found a lot of enjoyment in a lot of the work I've done, but I definitely wish that time had been spent doing work with more of a positive impact... Luckily there's still lots of time and I'm working on more impactful stuff now!

I sort-of know Jeff, and I think he comes here sometimes, so: hi! Funny thing: the same company "inspired" both of us. The best minds of my generation are figuring out how to get two broken systems to talk to one another.

Ads are only the way of making money, or are you saying it only matters what the end result is? It's possible to sell ads and also do good with the work.

Businesses have a tendency to optimize for making money so if the only way for them to do so is by having people click on ads, guess what they'll eventually become great at.

I had a great amount of fun working on my debug visualizer extension for vscode that was trending on hn a couple of weeks ago. And on other open source extensions and projects. I felt visionary and proud. That is what I want to do.

But it pays for nothing. I make more money as a street musician than with my open source projects that have more than 100k users. But I got paid a lot for improving some online gambling site. This is how it is.

There are some economic theories about non-monetary compensation that try to explain this. Basically:

Total Compensation = Salary + Benefits + Intangibles

Those Intangibles can be things like working environment or commute, but they can also include your affinity for the organization’s mission. People are willing to take smaller salaries when they’re working on something they love & respect. It takes more money to convince people to work on boring or undesirable things. It’s the exception to be paid well for something you like.

I think the word you’re looking for is “utility”. People maximize for utility, which includes all of the terms above. Utility of money also has diminishing returns, etc.

I think you need to call out bonus and RSUs/long term incentive plan here, too. Many places don't have them; talks of salary invariably leave them out, but they are what makes the FAANGs TC particularly compelling. And other companies do have them, but oftentimes it's hard to figure out which do, and for what roles (since it sometimes is dependent on seniority and perceived importance).

I disagree, one of those intangibles is the easiness to learn, so most of the time you get paid less for working on boring or undesirable but easy to learn things like one CRUD app after another. And you get paid better for more difficult and interesting things, because there are less people able to do it.

i find the contrary to be true, largely without exception. the boring useless stuff that no one wants to touch generally pays alot better.

work that I actualy care about is difficult to get paid for

There are ever-shrinking spaces where a developer gets to build something novel

I think it might be possible to say that relative to the entire industry the space for novel or interesting work is shrinking – possibly. But I don't think that actually means there's less interesting stuff to work on. If anything, the spaces for that are growing – maybe more routine work is growing faster, but I can't really say. I'd wager that the majority of software for its entire history has been pretty boring.

I agree. Though because of the growth of the industry, these spots where actual cutting edge work is happening are insanely competitive, and I would bet that many of the programmers (not all of course) who worked on the cool stuff 20 years ago would not make the cut for the cutting edge today, or are simply not interested in the particular niche of that edge.

How much of it is actual competitiveness and how much of it is the artificial barriers people put in the form of technical interviews?

There's a big gap between software craftsmanship and the algorithmic trivia interview expectations nowadays, and it seems to keep widening.

Working on the cutting edge implies some sort of combination of greater talents and ability to work harder than others (hence increased competition), which means that the artificial barrier is a mere pittance.

The people interested in doing cutting edge work will find a way to be there no matter what. The vast majority of people overestimate themselves.

"The brightest minds of our generation are working on making people click ads".

Every time I hear this quote, I remember all the small businesses and ventures that only exist because of Instagram, Facebook and Google Ads. Housewives baking cakes, a leatherworker making custom backpacks, a blacksmith restoring antique knives - those are just personal friends of mine who wouldn't be able to build their businesses if not for what those brightest minds of our generation are doing.

Is all of this really worthless to you?

(Copied over my recent comment on this exact topic, I hope it's OK with the mods).

I think what has changed is the expectation that work should always be 'joyful'. I don't the majority of employees working in any industry have ever been involved in cutting edge or creative work.

Can you imagine what the medical field would be like if the majority of general practitioners started complaining about the fact that they don't get to work in neurology research?

At least for me, this is exactly why I do personal projects. E.g., here's something random I did a couple weeks ago. It's so simple that it's almost embarrassing to post, but it's:

    100% vanilla Javascript
    no dependencies
    no cookies
    100% client side; no server side state, no ajax
    state is stored entirely in the URL
    state is correctly maintained across page loads (i.e. page edits its own URLs to maintain state)
    Javascript is 100% local, so it's instant and doesn't require any data fetch
    correctly detects a potentially spoiler-full page load by looking at the referrer (so it doesn't annoy you as you navigate around the site)
    ... and the entire thing is less than 100 lines of code
And it was surprising to me how genuinely fun this project was. I work on compilers/runtime systems for a living and I often get stuck in large code bases. I enjoy what I do, but working with a small codebase that's not massively overabstracted is just so fun.


The other thing that stuck me, as I was doing this, was how much the Javascript ecosystem has improved over the last 10-15 years. It was possible to do this in a very small amount of code with no dependencies precisely because of the all the bells and whistles that have been added to Javascript over the years. Maybe this isn't so obvious to someone who has been neck deep in Javascript for 15 years, but as someone who has been mainly in other languages, it was a very noticeable and dramatic improvement. The web platform is way, way nicer to develop for now than it used to be when I first got started.

Now I'm trying to figure out what other small projects I can get involved with.

The joyless is across the west culturally. It'll take 20 years to build up again.

> Programming has become joyless.

Over the next year or two I hope to develop a mobile app.

After 15+ years of big messy corporate server programming I think this might be the place joy is hiding.

I accept that I will probably not make the money I have made gluing clouds together the past couple years. But maybe I can make something useful that people like to use.

This whole dillution would be worth a book or two. How culture, economy, technology all evolved to both progress and regress oh so subtly.

check out crypto, especially the “defi” space

building there is a creative process and it pays better than big tech

The onchain codebases arent that big because they cant be.

I can't judge whether the actual programming there is fun, but I can't imagine an environment where bugs get exploited to the tune of tens of millions of dollars can be all that fun, and the entire field seems to be built on fraud, scams, and finding greater fools.

I suspect a nontrivial number of programmers in that field will find themselves making license plates or exploring harbors with concrete shoes a few years from now.

The bugs don’t affect the programmer or the company, assuming there even is a company

And the programmers have easily translatable skills, so nice try at making a point but it doesn’t make sense when there is a real conversation to have

But you werent actually here to debate the differences in how that could affect programmers in that industry vs other industries

Your preconceptions are a random incoherent mixture of things that are oddly excusing bad actors or bad companies by ignoring them and conflating it with blaming a specialized skillset or sector

You could have kept all that in your head because this was clearly a copypasta rebuttal prepared for any conversation about crypto

Thank you for sharing your perspective. It honestly warms my heart to see that some people believe the trajectory is still upward.

> Maybe I just enjoy software right now because I've now got the technical competence and confidence to avoid some of the frustrations that I experienced earlier

Just as some but not all of my (mostly negative) perception is surely personal, might I suggest that some but not all of your (mostly positive) perception is not? Perhaps the industry really has improved in some areas that you care about during that interval. Yay! OTOH, that doesn't necessarily put your perception and mine in opposition. There are other areas and other intervals, and other priorities as well. It's great that your experience has been positive. I hope it remains so.

The issue isn't so much the trajectory, but the people in the industry. I've been repeating for a while now that there are too many people who are not team players, who are basically still cowboy coders, looking to scratch their own personal technical itches rather than working together to build good software. This has been my experience for the last 5 years at least. It definitely reminds me more of the 90s, when the industry was a mess because it was new and growing. My issue is mostly with the people though, not the actual work. Lots of self-righteousness. Lots of people wanting everything to be on 'hard mode.' And as someone else commented, there is definitely a Stockholm Syndrome with the money involved since I now can not do anything else and maintain my life. Nor has this industry made it easy to change jobs. Nobody wants to train, everyone seems very cheap, but they want to hire Kobe. I am counting the days before I get broken.

I think that's a good way to think about it. Everyone's individual perspectives are valid, and they're a mix of real things that have happened in the industry and their own experiences.

I'm very much aware of how bad some parts of the industry can be (particularly having recently dipped my toe into some machine learning work and discovered an entire sub-field in which nobody has ever heard of documentation, testing, coding standards, or things like releasing software that actually works).

> Compared to the first steps I took as a developer about 15 years ago, almost everything about software development seems better to me.

If you mean this is better, I hardly agree with you:


Honestly, this IS better.

Separating the HTML, JS, and CSS is an approach that works up to a certain size/complexity app. When I’m working on some functionality, I need to be able to understand the relevant parts of the HTML, JS, and CSS. With a smaller app, one person can more or less grok the code base well enough to find everything they need. With simpler apps, you might have fairly uniform or boring styling and not a ton of CSS rules. If I’m setting something up with Bootstrap and just getting it working, I can probably ignore CSS for a LONG time.

If you’re working on something larger and more complicated, you really want to have all of the HTML, JS, and CSS for a particular piece of functionality right in the same place so you don’t have to go searching for it. It’s how you survive in large/complex apps. You’ll think, “The margins in this box are too large” and you want to be able to fix that without trying to grok some massive set of CSS rules, and when you do get the CSS rules that you want, you want to know that they’ll be delivered to the client—something that is easy if you deliver all of your CSS rules to every client, but hard if you want to split your CSS.

I think the only real tragedy here is that too many people are copying “the way Facebook does it” without wondering if Facebook might have a completely different set of priorities than they do.

I agree. I came to realize a few years ago how arbitrary the HTML, CSS, JS separation is. It makes sense if you think of the web as simply a set of documents (with progressive enhancement and all that), but we've gone way beyond that metaphor. If you're building a web app, separating the three is cargo-culting.

I don't think that this absolutely microscopic slice of the overall software development ecosystem is really representative of anything interesting.

But yes – I do think React is a pretty good approach to UIs compared with many things I've used in the past. There are good and interesting discussions to be had about the different possible techniques that can be used; this isn't an entry into one of them.

Thats actually clean. Throw in some PHP, more JS transpiler code, and CSS frameworks into that screenshot and were talking.

I completely agree. Docker, amazing frameworks (Laravel, Django, ReactJS etc.), git, CI, amazing IDEs, etc. It's absolutely magical compared to what we had 15 years ago. Entry level is much higher though for sure, you definitely need to learn and know a lot. But once you do know certain things at a certain level, you become a very powerful individual.

And here it lays the paradox. All the tools you have mentioned have little to do with programming (one individual solving problems by writing code). The tools you mentioned have to do with software engineering (a bunch of individuals solving problems by writing code, plus a bunch of constraints).

The joy is in programming, not in software engineering. At least that's how I interprete the GitHub comment (and all these stories about developers that cannot take it any more and burn out).

I think it's easy to forget that modern tooling (+AWS/GCP/Azure) let's one dev match or exceed the productivity of 15 developers and a couple of PMs in 2005.

It's a laughable claim to say one developer has replaced 15, and obviously not true. The vast majority of code was business logic and still is.

Today's 'process' is no more efficient than, say, deploying rails to heroku in 2007. And even before that, you'd spend half a day writing an automatic deployment script, and then deployments would take a couple of clicks and you'd never think about it again.

I'm not sure if you think all devs 15 years ago where stupid or all devs today are awesome, but either way I'd say you're wrong.

He means that tools have improved.

If tooling means a 15+x improvement then it seems like it is one or the other.

That's a very specific meaning, like in terms of scaling maybe? But in terms of actually meaningful problems solved for end users... But there very nature large scale systems aren't very common, but everyone is chasing that unicorn startup which can serve 10 million users; so scalable APIs are more "practical" then simple workflows

Scalability seems overhyped. If you write small efficient systems they can handle a lot of work. If you use big clunky frameworks that convert simple things into map-reduce style problems of course you're going to care about scalability and how much your AWS bill is going to be.

I could not agree more.

In many technical interviews, they want to talk about "scalability", using fancy big data software for horizontal scalability etc

But I also know from experience that many, many of these problems would be more elegantly solved by more traditional tools like Postgres, especially since servers have gotten more powerful, the cloud service options more plentiful and reliable, and the software more optimized. The "scalable" approach can lead to massive amounts of wasted person hours unless you're sure you really need it. But if you say, "just use RDS or CloudSQL, or maybe BigQuery", you get perceived as a newb by the 24 year old who just got his MS doing Spark work on toy problems.

I spent all day today and Friday just trying to get a Google Cloud Composer project to run locally. I'm still waiting for that increased productivity that modern tooling supposedly grants me.

I don't need to worry about many many trivial things I had to worry about before these tools, and now I can actually work on the problem I'm trying to solve almost immediately.

For some people solving business problems is boring. But tinkering with those things that you're calling trivial is what brings joy.

You and me both.

Is that true tho? I mean, I love programming, but I hate React. I love thinking about data structures and their relationships, but I don't like Docker. I spent hours thinking about how can I solve a problem (just for fun) and I absolutely don't need GCP nor Azure. I like coming up with cool algorithms (or reading about them) but I find Laravel (or Django) really unelegant and not worth my time.

It depends on the problem you're solving of course. All of these tools are built to be able to solve larger, more complex problems more effectively. You are still welcome to ignore all of them and write a cool program for yourself for fun, just don't expect to get paid for it.

Ultimately, we get paid to solve business problems, not to have fun with programming.

This is of course true. But is a particular fashionable technology the best way to solve that business problem, or is yet another layer of fun? I suspect that being able to deliver simple scalable solutions without bandwagon dependencies is going to be a differentiator, in _business terms_

I'm 20 years behind you

Me too. And all I can do is point at Javascript in webpages. Which, as a Java dev (if I can still call myself that 15 years into doing all sorts of other stuff too), I want nothing to do with but somehow get dragged into all the time.

I can really relate with the idea that we're feeding the beast we built rather than the one borne of necessity. Unfortunately, which I'm sure the latter still exists, it's the former that always seems to pay the bills.

I'm at the end of my software development life cycle, but I've got the opposite perspective on java vs javascript. There's just so much boiler plate and unnecessary typing to implement solutions in java relative to javascript. The amount of stuff I can accomplish per line of code is significantly higher than any other language I've worked with, with possible exception being python.

I'm ~23 years behind GP, and I feel the same way as them already. Goes to say, this may be a matter of personality.

There were few and brief moments in my career as a software developer when I was truly happy at my work. Most of those involved implementing an architecture or algorithm I figured out from scratch, or took from scientific literature - either as prototype or directly in the product. Sometimes as "hold my beer, I got this" moments. But as you can imagine, this is maybe 1% of the things I've been doing at various jobs.

From where I sit (a backend developer, thoroughly burned out by webdev a couple years ago), most of coding I do is software bureaucracy. Turn this data into that data, ensuring module X and Y get paged in the process. Oh, half of the code I'm about to write is implemented elsewhere - quick, figure out how to juggle the dependency graph to somehow route control from here to there and back. This data I want to convert is not of the right colour - oh, I need to pass it through three sets of conversion layers to get back essentially the same, but with a correct type tag on it. Etc.

It's utterly and mind-numbingly boring, unless you architectured the whole codebase yourself, at which point it's somewhat fun because it's your codebase, and who doesn't like their own Rube Goldberg machines?

At this point, I've learned a coping strategy: just forget the project scope and focus on your little plot of land. Doesn't matter that the software I wrote half of is going to help people do exciting stuff with industrial robots. What matters is that the customer changed some small and irrelevant piece of requirements for the 5th time, and I now have to route some data from the front to the back, through the other half of the code, written by my co-worker (a fine coder, btw.). So a bunch of layers of code bureaucracy I'm not familiar with, and discovering which feels like learning how to fill tax forms in a foreign country. If I start thinking about the industrial robots I'll just get depressed, so instead I focus on making the best jump through legacy code possible, so that I impress myself and my code reviewer (and hopefully make the 6th time I'm visiting this pit easier on everyone).

Maybe it's a problem of perceptions. Like in the modern military - you join because you think you'll get to fly a helicopter and shoot shoulder-mounted rockets for daily exercise. You get there and you realize it's just hard physical work, a bit of mental abuse, and a lot of doing nothing useful in particular (at least until you advance high enough or quit). And so I started coding, dreaming I'll be lording over pixels on the screens, animating machine golems, and helping rockets reach their desired orbits. Instead, I'm spending endless days pushing people to simplify the architecture, so that I can shove my data through four levels of indirection instead of six (and get the software to run 10x faster in the process), and all that to rearrange some data on the screen that really should've been just given away to people on an Excel sheet with a page of instructions attached.

(Another thing that annoys me: a lot of software I've seen, and some I've worked on, could've been better and more ergonomic as an Excel sheet with bunch of macros, and the whole reason they're a separate product instead is to silo in the data, the algorithm, and to prevent the users from being too clever with it. Also because you can't get VC funding for an Excel sheet (unless you're Palisade).)

Got a bit ranty here, sorry. I guess my point is: I accept the industry is mostly drudgework, but I refuse to accept that this is all essential complexity. Somehow, somewhere, we got off track, because all this shit is way harder than it should be.

I like how you describe focusing on your plot of land as a positive coping strategy. I had been doing it instinctively (or necessarily), but had thought of it as some kind of failing. Your comment makes me feel better about it.

The end goal of software I work on is to help airplanes land safely. But actually, I work on the software which presents the user interface that displays and sends configuration settings to a device on the ground that helps achieve that.

So my day to day is figuring out whether two bytes in a serial buffer an ad hoc protocol are actually transposed, or if the comments are in 20 year old code are lying about which is which. Or trying to figure out whether a Win32 font setting command from two decades ago is still interpreted the same on Windows 10.

The rabbit holes and yak shaving just go on and on. I have it in me to enjoy doing the work, but when I think about how many steps I am removed from the actual airplanes and I feel badly for filling my brain and my workday with trivia.

Thanks for sharing your story!

Yeah, I also initially felt this is some kind of failing (I'm usually the "big picture guy"), but ended up accepting this as a coping mechanism. It's not that I forget about the purpose completely - just learned to think about it more when planning and designing, where the wider perspective also affects the task in a meaningful way. When deep in the codebase, I try to put it aside, so that I don't get in a depressive session of thinking "why do I have to shovel this garbage back and forth to satisfy some low-level requirement, instead of, I don't know, talking to people who'll use this on-site and getting some real feedback from them?". Rationally, I know that shoving garbage is an important part of getting quality software that helps others do exciting things. Emotionally, I just wish I was in their shoes (probably just as much as they wish they were in mine).

You seem a bit more positive than me when facing this reality, so I'm glad you have it in you to enjoy this. I almost have it, so I find ways to cope, and enjoy the opportunities to do something less mundane that come every now and then in such projects.

> but had thought of it as some kind of failing. Your comment makes me feel better about it.

I do it as well; I think organizationally it's a failure, but it is an effective personal coping mechanism. In other words, it's bad for the organization that their codebase isn't really a melting pot of different developers' ideas but instead, if you zoom in enough you notice that it's really a series of hundreds of small fiefdoms each with their own slightly different customs and semantics. This is what creates that software bureaucracy.

For employees though, it works. It's about the only way that I really derive any sense of satisfaction from software engineering. When I can stand back and say yes, this package is mine, I made it and I will take care of it. With the melting pot packages it feels more ambivalent; some portion of the code is mine. Probably not the clever bits, they're probably bugfixes. So I don't have enough mindshare to get satisfaction from achievement, I don't have the satisfaction of at least solving one of the hard problems. No, those people have come and gone, and I'm left with the shale oil of satisfaction: fixing bugs, writing unit tests, and adding documentation. Like shale oil, the joy it brings is very close to the effort it takes to extract it. This isn't the "I accidentally hit an oil vein while digging a garden" joy of really getting to solve something.

Some people derive a lot of joy from doing things that help others (like unit tests, bug fixes and documentation); I'm unfortunately not one of them. Sometimes I wonder if it isn't at least partially because it's so hard to feel the impact. I know HN hates the idea of gameification, but I wonder if it couldn't be applied to good effect here. If someone could make an integration with CI, and with major editors, we could scrape data regarding how many times your unit tests have caught bugs, and how many times your function/class documentation has been viewed. There could be a leaderboard for people that are into that. But for me, just the raw numbers is enough. "Unit tests you have written have exposed 137 bugs in PRs, and documentation you have written has been viewed 138,476 times" would be a huge motivator. It gives me that warm and fuzzy "I actually productively contributed" feeling. Right now I get nothing back; I have no idea if anyone has ever read the documentation I spent hours writing, or if my unit tests have caught any issues.

Oh man. I’ve dealt with so much legacy code I avoid reading comments as long as possible, they lie more than I’d like. Sadly something like bit fields are the one place I feel I have to trust the comments god help you if they’re no longer accurate.

> who doesn't like their own Rube Goldberg machines?

Love that. Yes, the 1% (of which I've been a part) often get to control both the structure and rate of change for a large codebase, and in perfecting the fit to themselves they almost inevitably make the experience worse for everyone else.

Right. And I'm not angry at the person who drives the shape of the codebase; working with code designed around a different philosophy than your own is something that one can get used to. But I do feel that the large codebases I've been dealing with were often way too large for what they're doing - even though I couldn't always pinpoint what was superfluous. It's probably just entropy at work, but I can't stop thinking - there must be a better way!

I definitely agree. It's quite easy to look at a large codebase and feel like it's way more complex than it needs to be. That line of thinking often leads to rewrites, and in my experience rewrites often lead to newfound understanding of why the codebase was complex in the first place.

True. I've learned to resist the urge to rewrite code just because it feels too ugly/complex to me - except in the cases where I know I can get tangible benefits (performance, better API) and the scope of rewrite is limited and guarded by extensive tests. It's true that some of the cruft accrues because of changing requirements and the ongoing process of learning that is a good chunk of our work.

And yet accepting that, I still can't shake the feeling that things are more complex than they should be. That also applies to the code I'm writing myself (which is immune from the "rewrite because I could do it better" urge)!

I suspect it is all about perspective - I entered software development out of desperation for any career tract job out of grad school 8 years ago, experiencing 2.5 years of a desperate job search while enlisting in the Marine Corps Reserve in the interim. I was ecstatic that I entered a profession where I can solve problems, and I’m still very happy I can do so today, even while having grinded up to senior at a FAANG.

I no longer code outside of work though & found a happy balance of learning on the job with my productivity. I find the amount I do get to spend coding also has gone down - a lot of my time is spent mentoring, in meetings, writing planning docs, and just thinking about projects, or occasionally researching what’s the best paradigm for my problem. I am ok with this, as I am taking more joy in being a leader than directly coding necessarily. I recognize not everyone shares the same perspective though.

> I've learned a coping strategy: just forget the project scope and focus on your little plot of land.

I get what your are saying and you are getting a lot of positive reinforcement about this. I would suggest to you a caveat.

I've worked in some orgs where this mentality becomes entrenched. In these new-fangled tech startups with people changing roles and even companies every two years this probably happens less. But I've seen people entrenched into their own kingdoms for decades. An individual, or small team, creates a moat around their "little plot of land" and they become intransigent. This leads to two bad outcomes: they resist any change to their systems or process, going so far as to obfuscate it to protect it. They also don't pay attention to holistic concerns, caring only about maintaining some idyllic vision for their own "plot of land" to the detriment of any larger objectives.

I think this is a real concern when divisions within a larger org compartmentalize around code or system boundaries. It is not something to shrug off as if it couldn't happen to you.

Thanks for the warning.

Honestly, I've used an unfortunate turn of phrase in my original comment. "Your little plot of land" indeed implies a fixed, entrenched moat. What I meant was something different - the area of code I'm currently working on. That may be a different place with every new task. My coping mechanism isn't building little kingdoms - just focusing on the code a given task involves while purposefully forgetting about the global context of the application, in order to not think about how minuscule and irrelevant the task is to the exciting things the company is doing. That context is usually not useful when doing the changes I've already planned beforehand, and it is emotionally distracting.

I resonate with this rant very strongly!

I started programming on an amateur basis in 1984, professionally in 1997. I'm 52 now. My experience is that coding has become more and more interesting and pleasant. In the early days, I had to deal with under-powered languages that either couldn't do certain things or that made them very difficult. Then I encountered languages that were much more pleasant to use, but had other problems such as not scaling well to team-level development -- sometimes even I couldn't figure out what I had been doing. Languages are clearer now, they make thinking about problems easier, and while this issue has not disappeared, it's less bad for me than it used to be.

For me, tools, including languages, do matter. I can well imagine that programming in Java would be soul-deadening (although Java is still better than some languages of the past).

Incidentally, I am not dunking on languages of the past. Lisp has been around for a long time, as has Smalltalk or Haskell or ML. Many of those languages were not accessible to anyone without a mainframe or expensive workstation. This situation has improved greatly in the past decades, which to me is another reason to prefer coding today versus the past.

Obviously, most of us are not able to cherry-pick our toolset for work. We use whatever our employer says to use, or whatever the demands of our project require. This may be part of why many people find coding to be an uninspiring experience. Also, the problems that people work on might be dull, it's hard to get motivated about a basically tedious problem.

Last, it's worth acknowledging that some people just don't love coding all that much. It's hard to imagine doing really well at something you don't deeply enjoy day in and day out. And your passion can change over time: you might really enjoy something in one part of your life, and not derive much joy from it at another part.

The challenge is that in most projects, the things that make things "better" also hide entire galaxies of technical debt. The MongoDB debacle is an example of that problem, as is the outcome of Docker (images full of vulnerabilities, difficulty in making even the most quotidian tools like strace, etc. run easily, converting a known and enforced-common production userland environment into a hodgepodge of 'whatever', etc.) and so on.

Supportability, risk-mitigation, debuggability, etc. are all thrown away in most of today's environments. An awful lot of tech companies are running mostly on hope.

I agree.

I think it's amazing to see CICD tools which make it super easy and quick to deploy web apps-- such as Vercel, for example.

Simply by booting up a github project, and starting from a template, I can deploy a SSL-secured site within minutes-- as a frontend example.

On the backend, using infrastructure-as-code solutions, to again, "templatize" a starting point, such as an AWS service or set of connected AWS services.

Whereas up until recently, I'd typically go rent a chunk of a server to run Linux, and setup NGINX-related security features myself. Not that tough, especially the more I learned NGINX. However the 3-click deployment via tools like Vercel take away so much headache. That said, at times, I think it's can be necessary and easier to simply setup a linux server, so as to have full control over the process.

It's just nice to have the additional options.

I love how much the software-supporting ecosystem has evolved.

It lets me focus more on development, and less on devops. And that what I want, as a developer-- To get to coding ASAP, and not worry about tangential concerns-- as a matter of specializing.

(Disclaimer: I only have about 2-3 years of professional experience, but prior to that, was teaching myself for about 5 years off and on. In that timespan of 7-8 years, I feel so assured and emotionally secure given the reduction of headaches due to the fact that I no longer have to learn so much ecosystem related stuff, and can focus more on programming)

> Compared to the first steps I took as a developer about 15 years ago, almost everything about software development seems better to me. I find developing software to be easier, more consistent, and less frustrating than it used to be. Good development practices—things like testing, CI, coding standards and so on—seem more prevalent than they used to be. It's easier to get code out to production than it ever was. Everything in the ecosystem—like tooling, libraries, and services—feel far more open, consistent, and accessible than they used to.

All true points.

As an individual developer, if you are working on what you want to be working, we are in a great time. You can pick from a selection of outstanding tools and we have, for all practical purposes, access to infinite hardware.

As a developer that's part of a team... it sucks. Expectations are getting ever more unrealistic - probably because so many things are quickly done, but other things are just as slow or even slower. Most people's jobs consist of wiring together 150 libraries across 30 'microservices' (which are rarely microservices, but often distributed monoliths) and that's after spending a lot of time bikeshedding on what the tech stack is supposed to be like.

At least the UML craze seems to have died down.

We're all on the great curve of programmer productivity through the ages. All we can see are the local maximums and minimums we've encountered.

From my journey on the chart, things have only gotten better since the time I crashed a C++ compiler just because I was using std::map.

> opposed to code that hacks together some junk to try and make it work with other junk.

I think you work for a better company than me :)

I believe the main thing that changed is that 10 years ago, "building software" meant you would work with (presumably reasonable) engineers. Nowadays, it means you do web busywork for some newly rich kid chasing a startup lifestyle, who may or may not have any idea about what's easy/difficult possible/impossible.

Also, the whole industry has been strongly commercialized. Before, people would share source code on the internet just for the fun of it. Nowadays, that is a surefire way for someone else to take your source code and sell it as theirs. I mean that's basically what Cloud providers do. They rent out access to open source software.

The insane pressure of money also makes sure that most software nowadays is not build to any reasonable engineering standard, even when it really should be (like Boeing MCAS). Instead, every piece of software nowadays is optimized for the sweet spot between sucking so bad that nobody buys it and not spending a penny more than what is necessary.

The goal of software development has changed, and I think $1 phone apps nicely illustrate the new commercial landscape. It's the bare minimum quality at the bare minimum price.

BTW, on a related note, most bicycles made in 2000 still had a much more stable frame than the 2020 models. The marked switched from costly steel to cheaper aluminum so that you can make $300 supermarket bikes. And obviously, the quality has suffered.

It appears that in general, there's always a race to the lowest possible quality in the hopes of reducing costs, thereby increasing profits. Does anyone have any suggestion how we could reverse this trend in general?

It was always like this except in the hobbyist world, and I think maybe you and some developers are confused because the corporate takeover of the web is relatively recent. When I think of software development in the past I think of Office Space (the movie), not some idyllic times.

Your overall tone is negative and elitist.

Thee $300 supermarket bike (I have one and put over 40 miles on it weekly and it's help up fine for four years) provides access to folks who otherwise can't afford the fancy $1,500 aluminium/carbon machines. Fancy bikes are still getting made and even getting better.

Newly rich kid or VC funded startups distributes money from wealthy people to an every growing software industry. It allows people like me to work in software; something that was previously only available to elite educated people who happened to live in the correct zip code.

tl;dr: The pie has increased in size and become much more inclusive. Yes, there is a lot of low-quality pie out there. But there is also plenty of high-quality pie for those who can afford it. This is good for everyone except the very elite entrenched class.

I'm not sure I deserve the "elitist" label, but yes, I find this development very negative.

While I agree with your point that hobby startups distribute money and enlarge the market, I was trying to point out that people working under management with no experience will probably not learn their craft well. In my opinion, the old apprentice system used for jobs like becoming a carpenter would be quite appropriate for software engineers. But it only works if there are enough master level programmers around to teach everyone else.

As for the pie analogy, I don't share your opinion. When the market moves towards lower quality, that usually makes high quality more expensive or even outright impossible to acquire. Case in point, I'm not aware of any bicycle that is rated for 200kg+ for driver and luggage. Not only are there no cheap bikes at that stability level, but also nothing in the $2000+ premium range. So something that used to be easy to buy for everyday folks 20 years ago is now too expensive even for rich people. And all that only to drive the price of the cheapest bikes down from $500 to $300, which I presume won't make much difference to anyone because a good bike will last you 10 years, so it's <$1 monthly in either case.

Xtracycle Edgerunner.

Not only will it easily take that weight, it's designed to comfortably carry a passenger and cargo. Or the Yuba Mundo, there are a few other brands. And you can get them in electric, if your thighs aren't made of steel cable.

Yuba Mundo is $1800, which sounds like a lot, but with inflation that's well under a grand at the time when more bikes were heavy and over-engineered. With the nice side effect that they could carry a lot of weight....

Thanks :) I had not heard of them before, but yeah that's kind of what I was hoping to find, but then didn't find.

Sorry about that, I didn't mean it to come across as a personal attack. I mostly agree with your paragraph about hobby startups. And I secretly lust after a nicer bike and might go for one soon :)

Yeah this doesn't deserve the downvotes.

If you don't like rich kids, don't work for them.

That's fair, but before I spent a lot of time in industry, I thought most tech entrepreneurs were genius engineer/business types.

I was shocked that a LOT of startup founders are well-connected rich kids who have no skills or ability to lead a tech company. I learned that, while saying that you have a huge trust fund isn't very cool, saying that you're a tech entrepreneur CEO is perceived as cool. So the rich family uses their connections to raise a few million (often indirectly) and suddenly the kid is an "entrepreneur", despite lacking any relevant skill sets. It's not like there's any expectation for these companies to make a profit anyway.

Yes, you can avoid these companies, but it's worth warning younger engineers that this is maybe 50% of tech startups. It's more of a problem with NYC based companies than SF based companies (as NYC has more old money and less emphasis on tech companies actually building real tech) but I've seen it in both cities.

This is kind of true. Young tech entrepreneurs are mostly either harvard/stanford/other top college grads, or theyre from wealthy families. But entrepreneurship has always been this way, its not a middle class career path, and arguably, tech has increased the number of middle class/raw talent trying to start their own companies.

If you were to look back at the early 1900s, or even 1980s, its much better today than back then

The downvotes are fun. I guess some people are just against inclusiveness?

I'm very grateful to be in this industry despite not having the "correct" background.

I don't get the downvotes.

You have a very solid extremely valid counter point and I think the person you're responding too created a false dichomtomy.

Cheaper does not eliminate the quality. They can both co-exist and indeed do.

The lower tier just opens the door for a group of people who never had access before.

Thank you for your input.

Ignore the downvotes. Initial votes are misleading, and if the comment is substantial, they'll stabilize to a reasonable value over the following couple hours.

> Cheaper does not eliminate the quality. They can both co-exist and indeed do.

It sometimes does, if it eliminates quality out of the market. Say a quality frame costed $500 before; then you have a new, cheaper technology that can achieve similar performance by cutting out more extreme loads / road conditions; as manufacturers jump at it to save money, suddenly the whole $100-$800 range uses just that, and the quality frame rises to $1500 due to collapsing demand. Can't say whether it's good or bad on the whole, but it annoys the hell out of me in cases where I could afford the quality product but I can't, because nobody is making it anymore.

Sure That's a good point. Things can tend to extremes.

Instead of middle range products you get low tier and high tier products and those absorb their different shares of the market from the middle.

This type of extreme seems to happen in all facets of human society over time including jobs, housing, cars, etc..

The middle becomes pushed out.

That's been a big issue for a long time.

Alot of access is given to people who previously had no access but the middle is somewhat eliminated.

What is the correct background? our industry is hardly one of those those where you have to go to a white shoe ivy or Oxbridge.

Open source as an art is inclusive. Or at least as a social model for developing software, has greater potential than startups, which are exclusive to those with financially viable skills

A working culture tuned to movement of a minority of capital “haves” isn’t much different mathematically than a monarchy and his lords and barons, etc.

There’s a gentler temperament, but “work the jobs we will pay for, while deflating your buying power to maintain historical human narratives” isn’t exactly fostering free flow of capital, labor, and ideas.

You won't find a higher percentage of "gatekeepers" within a community than the Hacker News community.

I think you might be experiencing what it's like to have, er, experience.

Like, I could make the exact same complaint except I'd situate it about 10 years earlier, around the first dot-com explosion.

And somewhat earlier than that, I remember grizzled programmers from the 1980s who hand-tuned their C and assembly and who thought we were flagrantly wasting computer resources on garbage platforms like the web.

(However, bringing it back to the 2010s and beyond, you're right that open source development has been completely co-opted.)

> I sincerely feel bad for people who have to stay in it.

I'm in my 50s, and I've been getting paid to build software for over 27 years now, and started programming on a near daily basis on a TRS-80 in the 1970s.

Please don't feel sorry for me. I still very much enjoy building software.

I won't necessarily disagree with the particular challenges you cite.

The total complexity is enormous now, but the tools and abstractions, which themselves have variable quality, and bring their own complexities, are tremendously powerful, and, though it often doesn't feel like it, effective.

Beyond the specifics, I acknowledge that 'the industry' has evolved in many ways and directions, not all of which are positive.

I face non-technical challenges today that, had I known about them 30 years ago, would have probably caused me to switch careers.

So, I acknowledge what you're saying, and to it I will only add this: each of us exerts a great deal of control over how we perceive the world around us. It's possible that the difference in the way you and I 'grade' the software industry is that I am, for no knowable or particular reason, more fundamentally optimistic about things than you. It's also possible that, primarily for reasons beyond our control, I've ended up working in more positive organizations.

To other people reading this far: two specific anecdotes about how the software industry has changed over three decades provides very little concrete indication for how your personal experiences are likely to go.

Another TRS-80 fan here. I learned programming by sitting in the back of a Radio Shack where they had a Model I Level II and a Model II with those big 8" drives. This was probably around '81 or so. A year or so later they eventually had a Model III in the front of the store.

Whenever I get burned out on software (in my case, Vue and React) -- and build complexity -- I always remind myself of those TRS-80 days. The only learning references around were the books for sale by the TRS80's -- a couple books on TRS80 graphics, Rodney Zak's 'Z80 Assembly Language', and William Borden's Z80 books. And of course the Tandy version of Zork in the little plastic baggie hanging from a wall hook beside 'Eliza' and 'Dancing Demon' -- and then the wall of brown folders of 'Scripsit' and 'VisiCalc' on TRSDOS 1.3 (?). Maybe the editor/assembler at the time, too -- 'EDTASM'. Don't remember if that was in a baggie on the wall hook or in a Tandy brown TrapperKeeper with the cassette insert and several tapes.

Those were great days -- and everything (for me, at least) was new and exciting. Nothing was ever too daunting or too complex -- even as daunting (and as complex) as Z80 assembly seemed to me -- a 13 year old at the time.

That's a feeling I always try to recapture in very deliberate ways these days. It's good remember how it all started.

This was my first computer: https://en.wikipedia.org/wiki/TRS-80_Color_Computer Got it for Christmas in 1980. Second computer was https://en.wikipedia.org/wiki/TRS-80_Model_100 and third was https://en.wikipedia.org/wiki/Amiga_1000 I have the Model 100 in storage, and it still works just like new, taking four AA batteries.

Complexity is daunting today. I believe, however, that the power available far outweighs the total difficulties.

I am still inspired by the basic possibilities that most anybody can, with nothing but access to a computer and the Internet, write some javascript and html in a simple editor and make it available to most everyone in the world.

Objectively speaking, that's simple and approachable, far more so than anything I ever did or was aware of.

The detail in the store description is wonderful. That's exactly where I grew up, learning to program on store equipment as the store manager let me spend the days there in exchange for showing potential customers what these things were.

I'm also in my 50s, and I can't imagine ever losing interest in programming.

A computer contains practically infinite possibilities, and people who lose interest in that are really just lacking creativity, and maybe some cognitive ability.

I don't only program though, I am creative in other ways and I build many things that have nothing to do with computers, but I do often incorporate programming into these creative pursuits, because it sometimes pushes the project to the "next level".

If someone only writes "glue code" then yeah, that will get boring. There are so many other kinds of programming though, that many never even explore. 3D is a whole entire interesting field that is far removed from "glue code". Home automation is one of my latest obsessions. The list goes on and on.

> but I do often incorporate programming into these creative pursuits

I'd love to hear a couple of examples if you have a few moments. (:

After having read the article Built to Last[1] from the latest issue of Logic Magazine over my morning coffee, and spending breakfast pondering my coming day of figuring out if we can disentangle some stuff I'm working on from the increasingly complex and inscrutable Big Data ecosystem, and if it's even going to be possible to get management to approve it when the requests to stick RSS feeds into DBMSes are forever piling up, and generally thinking about my own mid-career situation, and, this comment really hit me like a punch in the gut.

This quote from Built to Last is going to stick with me for a while: "... many people don’t even see the preference for complex languages for what it is: an attempt to protect one’s status by favoring tools that gate-keep rather than those that assist newcomers."

I'm not leaving the industry any time soon. At least in the abstract, I do like what I do for a living, and believe that there are still some habitable spaces left in the field of informatics. But there's a part of me that is beginning to wonder if the best and most comprehensive literary (sort of) analogy for modern software engineering culture isn't the Orks from Warhammer 40,000.


In case anyone is inclined to go read the article, let me (potentially) save you a click with the following excerpts from it:

> the last thing many male computer scientists entering the field wanted was to make the field easier to enter or code easier to read, which might undermine their claims to professional and “scientific” expertise.

> Take the C programming language: it was created in 1972, but as one of the current COBOL programmers I interviewed pointed out, nobody makes fun of it or calls it an “old dead language”

> There’s an old joke among programmers: “If it was hard to write, it should be hard to read.”

> it’s perhaps no wonder that a committee-designed language meant to be easier to learn and use

And, of course, the quote from the comment to which I'm replying:

> many people don’t even see the preference for complex languages for what it is: an attempt to protect one’s status by favoring tools that gate-keep rather than those that assist newcomers.

If any of these quotes even resembles something you _might_ think about this field, maybe you'll get something out of reading the whole article. Personally, these quotes are so backwards to me that the author could just as well have written "Programmers can breathe under water" or "grass is the cornerstone of a well balanced diet".

Alternatively, one could take the view that low-abstraction languages are designed to turn programmers into replaceable parts. This benefits the “low-quality for low-price” software vendor culture at the expense of programmer’s pay and status and also at the expense of the customer’s ownership and quality experience.

This attitude, both from the business side and from the developer side, has always struck me as an egregious misapprehension about where the value in software development lies.

It's never about the code. It's about getting the job done, and the code is just a tool for getting it done. And getting the job done is ultimately about domain expertise, or design skill, or engineering acumen, or any number of more abstract skills. When developers get all protectionist about complex technical tooling instead of focusing on perfecting their ability to get the actual job done, that's a moral own goal. It doesn't challenge the idea that developer skills are inherently low-value and replaceable, it takes the idea as a given, and asks, "OK, since we're inherently low-value and replaceable, how can we artificially make it harder to replace us?"

Me, I don't want to respond to the idea that I'm just a code monkey by trying to be the fanciest code monkey imaginable. I don't want to be a code monkey in the first place.

This is interesting, and it may be partially true, but I'm not convinced it's malice, as that statement seems to indicate.

Last year I wrote a small book called "Splash of Code", which teaches newcomers to code (in JavaScript) in a way that similar to the way I learned 30 years ago. I selected JavaScript because the barrier to entry is low, you just need a browser. Many programming ecosystems are daunting to setup these days but there are still some easy systems we can use to introduce newcomers without all the modern complexity.

Browsers have come a very long way in the last 10 years and are a pretty amazing platform for development. Once you learn a little bit you can start to write amazing software for a cross-platform worldwide audience.

> "... many people don’t even see the preference for complex languages for what it is: an attempt to protect one’s status by favoring tools that gate-keep rather than those that assist newcomers."

Don't forget the ones who jump onto a new language or framework so that by dint of experience they can be the gatekeepers for the next generation. This was staggeringly apparent with both Java and Go, each in their time.

Let's conjugate the whole thing, shall we?

I learn new languages for technical development and to stay curious and fresh. You learn new languages for job security. They want to gatekeep the next generation.

> Building software was never simple or easy

I think it’s gotten a whole lot simpler in the past 10 years. People used to have to rack their own hardware, install PDUs, check temperature gauges, plug wires, configure the switches, setup RAID and backups, make sure you have that serial cable plugged in so you can telnet in in case the switches don’t work, and lock the data center doors without forgetting their keys back in the day. And this is before actually developing and deploying your application software.

Now you can just buy a bunch of db cycles and scale to >10000 qps without batting an eye (though you’ve got to watch your wallet).

I think because some of the hard stuff got a lot easier, the easier stuff got unnecessarily complex. And there are so many ways to scale things that some of these constructs and idioms used over time stopped being used because they mattered less if you could just turn a knob to scale your crappy code.

> People used to have to rack their own hardware, install PDUs, check temperature gauges, plug wires, configure the switches, setup RAID and backups, make sure you have that serial cable plugged in so you can telnet in in case the switches don’t work, and lock the data center doors without forgetting their keys back in the day.

Yes, and other people did this job, not programmers. People that loved tinkering with hardware, low-level OS stuff, networking, etc. We even had a name for them: "system administrators" and "network administrators".

Nowadays everyone's expected to tweak CSS and configure kubernetes in parallel.

We still exist. Our job titles just changed and more responsibility was put on our plates. Now we do the above work, plus manage automation (Jenkins pipelines, Ansible playbooks, etc) among other work. Not that the increased responsibility is an issue, just that the title makes us seem fancier than we are. I think that is part of the problem, everyone needs some ridiculous title now, a “lowly” sysadmin gets looked at sideways.

Yes. Although I worn that and other hats before and often together, I disliked being a sysadmin. I don't like being on call, it causes me to wake up at two in the morning to check a website. I do not like worrying about when to install a new patch.

So when my job title switched away from programmer to some kind of DevOps thing and I was shoved back into the sys admin role, I was unhappy about it.

That does depend in some areas of technical /systems programming back then you normally developers where expected to know the basics and be able to do all that - the original full stack developer OSI 1-7.

Trouble is they tended to be interesting but poorly paid jobs

> People used to have to rack their own hardware, install PDUs, check temperature gauges, plug wires, configure the switches

What you describe is what used to be considered sysadmin work. I too did quite a bit of it, but most of it went to people who specialized in those things. And no, I don't do any of it now. On any given day I'll probably deal with machines in at least a dozen geographic locations across two continents, and if I tried to enter any of them I'd be stopped at the door - no, at the gate before I even got to the buildings. Instead, I write code to interact with the deployment system and the provisioning system and the multiple monitoring systems and the automatic remediation system and so on. Is it better? It scales better, but as a matter of personal satisfaction and avoiding fury at other people's crappy code I think I'd rather be plugging in cables and configuring switches.

> I think because some of the hard stuff got a lot easier, the easier stuff got unnecessarily complex.

There's a lot of truth to that, and I don't think we necessarily disagree on the outcome. However we got here, whichever specific things make modern software development more unpleasant, it seems that it is more unpleasant than it used to be.

Re: the sysadmin work, app developers have to worry a whole lot less about it, oftentimes not at all. In startups, that's a huge plus. I still remember servers going down because some workloads were destroying the RAID arrays s.t. that they were drawing down too much power and overloading the PDUs in their racks. I ended up having to hardwire the distribution of jobs to other servers while we (actually it was me, I was at a startup) got the PDUs upgraded by talking to a sysadmin on the phone. (Amusingly at some point we had to fix some DNS while restarting one of the boxes so I had to tell the guy what to do by dictating vi commands.)

But yeah it's like over time we ended up scaling the crappiness of software along with the software itself. At the same time, I'm inclined to believe that software development at large is in a much better position to solve a whole bunch of other problems than ever before. That keeps me motivated personally, though I get the frustrations for sure.

I think it is funny you mention 10 years because I would agree with you, in the last 10 years we corrected a lot of the sins that we did in early web dev, but I think the lament reaches further back. Move back 25 years ago and it was much easier. A kid in his room could singlehandedly write the next big thing. Things in a lot of ways where much simpler then, it's hard to not look back on that period without a lot of nostalgia.

I was around 25 years ago pushing bits around SunOS boxes and when people were still figuring out CMSes. FTP and BBEdit ftw. Definitely some things were simpler, but stuff would fall over in a heartbeat. I still think of the day of 9/11 when major websites couldn't serve their homepages because they were bombarded by traffic.

Kids in their rooms still do write the next big things. The difference now is they now raise a ton of money along with it. They scale a whole lot further, and much faster. There are more entering the engineering profession through Lambda School and bootcamps and what not. They also leave around a lot of shitty code that usually ends up building some business value. Much of this was true back in the day. It's just gained a whole lot more momentum IMHO.

I'm 56 and STILL love building software ... I started coding as a hobby when I was in 6th grade, built my first computer (a COSMAC Elf) when I was in 10th grade and spent 20 years doing a combination of electronics and software engineering. For the last (almost) 20 years, I've been only doing software development with a small amount of consulting on hardware design and hobbyist projects. (And the weirdly political intersection with these disciplines while working on a committee that wrote part of the DOCSIS cable modem spec). I have no intention of throwing in the towel and am really enjoying the Go language (and happy to see that Java is taking steps to reduce the complexity of the JakartaEE framework).

But ...

I used to code for fun in my spare time and more recently I'm finding myself working on "shop" projects. I sold my pocket-cruiser (a small yacht) and I'm building a couple of small wooden boats. I have a '71 Saab Sonnett III I'm in the process of restoring and a '71 VW Karman Ghia that's next on the list. I thoroughly endorse the idea of doing something with your hands - it's so much more satisfying than sitting in front of the TV.

I'm only 27 but I'm already dissatisfied a lot with most of what the software industry does and the decisions it makes. I've been 1.5 years without a job at this point and wherever I look for one I'm very disappointed.

- The arbitrary deadlines that serve no purpose. Example: we have to update our app every week/month because reasons.

- The utter lack of understanding of the concept of feature completeness. Example: operating systems that update every year for no good reason whatsoever. What's the point of updating from Mojave to Catalina as a user? What new does it bring? How does it empower the user in a way not before possible? No one knows because it does not. It merely moves things around for the sake of change.

- No one wants to understand what they're abstracting away. People keep piling abstractions upon abstractions yet can't answer the basic questions about how their operating system works at low level.

- Fashion. A lot of it. Basically, if you're doing Android, you MUST want Kotlin and Jetpack and Compose. Same for web — SSR is soooo 2010, gotta make that news website a single-page application because how come would we not use React. IMO, fashion has no place in engineering.

- This "we'll always be able to ship an update" attitude. This is the worst. No one wants to make high-quality software any more, they want to move fast and break stuff at the expense of the end-user sanity. I can't understand how this way of thinking came to exist tbh.

- Business incentives. They ruin everything, but it's especially felt in software engineering.

- Priorities in general. No one is considering what they're making a tool to help the user achieve something. They're making these monstrosities that always put their own interests before those of the user. Dark patterns, purposely inconvenient and awkward UIs, spammy notifications that don't correspond to real events, you name it. In my book, that's not the way to go.

To me, this sounds like developers who are too far away from the business. Either they don't understand the context, or they aren't given the latitude to express their concerns about product direction.

IMO "the business" is the root of the problem. Businesses tend to put money before literally everything else, and thus we end up with the awfulness that is the modern social media for example.

No matter how visionary, proficient, and user-respecting you are as a developer, if you aren't complicit in earning all the money in the world at all costs, you're gonna get replaced by someone else who is.

No offense but I think you're being dramatic and a bit naive.

There are plenty of small companies chasing a dream other than total economic world domination. Obviously if you look at Facebook etc that's all you're going to see.

Also, good luck running a business, any business of any size, without caring about money. Once you're responsible for the the livelihood of your employees and yourself (and maybe even SO and your progeny) your perspective changes radically.

> There are plenty of small companies chasing a dream other than total economic world domination.

That is until they are pressured to "grow" by their investors that they do have more often than not.

> Also, good luck running a business, any business of any size, without caring about money.

I've worked at a company that was alive and well without chasing profits. It did a bare minimum of monetization to cover its expenses and get a little extra, and that was it. Users were happy, we were happy too. Then the investors decided they've had enough of it, sold their shares to others and those forced the CEO to leave. It was then acquired by a big corporation. I quit in around two years after that when I realized there's no going back and it's only going to get worse over time. It took a lot of effort to make myself go to HR and tell them I'm resigning. I still miss the spirit that was there when I joined. And I'm not sure there are any more companies like this, especially in 2020.

If you had put a couple of millions into a company you'd probably expect to get your money back, no? Would you be happy giving your money away?

Another point you are missing is that not all companies work that way either. Many people start their own business with their own money and don't have to answer to investors. Look outside of tech: restaurants, design studios, stores, etc.

> If you had put a couple of millions into a company you'd probably expect to get your money back, no?

Yes and you will eventually get it back if your company turns profit — any profit. That doesn't in any way imply growth at all costs which is what the world is obsessed with today because stocks. Practically, it doesn't make much sense to earn hundreds or even thousands times more money than what you spend, yet most companies do just that. It ends up laying idle on bank accounts, not benefitting the end users and society at large in any way.

> Would you be happy giving your money away?

Yes if that meant making the world better.

> Many people start their own business with their own money and don't have to answer to investors. Look outside of tech: restaurants, design studios, stores, etc.

And those usually respect their users/clients.

I disagree with you. Today's scenario is certainly much more interesting than the post dot-com boom years, maybe not as interesting as the very early days of computing, but certainly ripe for innovation, and a test-bed for innumerable breakthroughs that are yet to come. We are currently living the post "Big data" age and advancing fast toward the pre quantum computing era, with a renaissance of AI and machine learning technologies. Cryptography is ripe for disruption and the past years have seen the introduction and deployment of novel concepts and semi-old ideas that have finally found application with cryptocurrencies and distributed systems. There are several projects at the forefront of technology with defined goals in mind, and definitely solving real world problems, like privacy in cloud computing, for example. Software stacks have matured intro fully fledged products and there is plenty of choice for every use case, one just need to delve into the enormous amount of information available and do his homework. Operating systems have also advanced a lot and I love, for one, how easy is to operate Ubuntu nowadays, and the level of freedom it offers to users. Maybe you need to think a bit outside the box? respectfully, have a great one!

> I sincerely feel bad for people who have to stay in it.

Truly? Or do you mean you feel bad for people who still have to work for a living? Because if you still have to work for a living I can think of 9000 jobs that suck more than working on software. Btw, I'm turning 60 next month and have been doing this for a living since about 1992, before that I did lots of other things, so I have several points of comparison.

Wow, that resonates quite a lot with me, though I'm not 55 yet.

I started my career as a software engineer with web development in the 90's. Everything seemed simpler. Literally.

Then, fast forward to 2020. I'll cite you an example of what happened EXACTLY yesterday. I have a web application which is complete and ready to be deployed. It's a backoffice application for one of our e-commerce sites. It's built using Phoenix, so there is a separate assets folder which contains a webpack config and its own package.json as well. The frontend updates require me to update the assets manifest as well. So, we've setup CI for it to automatically do that for each deploy. So, as usual, it simply runs npm install, but, suddenly, everything broke. Remember, this was fine until our previous deploy. It was some weird error from node about not being able to do something with Babel. I had to spend about almost an hour to figure out it was coming from some other package that was making use of Babel. (If you're interested the error is this one[1])). OK fine, we upgraded the babel version as indicated in that issue thread. However, it wasn't compatible with some other package on the OS we were running on. So, now I had to downgrade the entire node version itself to something we knew that worked.

We lost a good amount of engineering time simply because of this unwanted complexity. Remember, all I wanted to do was JUST deploy. Our backend code was perfectly fine. Just for one new added feature, we had to pay a price with our time. This is hardly an exception, this is becoming in the norm.

[1] https://github.com/nodejs/node/issues/32852

You may want to use `npm ci` instead of `npm install` on automated processes like CI. `npm ci` will install the package versions from `package-lock.json` that presumably worked while developing, `npm install` will try to install the latest that match the criteria in `package.json`

I saw this joke in a thread somewhere:

Junior engineer: thinks they know everything

Intermediate engineer: thinks they know nothing

Senior engineer: hates computers

I tend to agree but I think what’s driving this stuff lies in the changing software product- and project - culture, and the glue-like nature of modern work is an outgrowth of that.

On the engineering side we’ve fully embraced the ephemeral, disposable nature of code, which tends to run counter to business needs which may require hastily constructed code hack jobs to stick around indefinitely. Really makes taking pride in workmanship impossible. You’re allowed to feel good about what your company is doing, but if you feel good about your code then perhaps you’re indulging yourself on company time and could be more productive... so you end up feeling guilty about doing good work.

I also think over the last 20 years there’s been a concentrated movement to remove technical expertise from the product design process. Engineers are present to provide estimates and gauge feasibility, but aren’t granted much leeway beyond that. Decades ago, you needed dev skill to actively shape technical projects since there wasn’t even that much user-level experience with computers and technology to make judgements.

This loss of balance tends to mean software is driven forward almost exclusively by either new features or redesigns. Technical enhancements are rare, unless they exist to support existing features. Nobody wants to spend a few sprints on "Make this thing feel 30% faster" or "Deal with our memory usage issues in these cases" until it reaches crisis levels or customers complain. So you get bigger, bloated software that runs slowly because nobody is authorized to make anything faster or use less resources until a product market position is threatened because of such technical deficiencies.... although sometimes the answer by product leadership to such problems can be even more features.

I keep saying it. Building software in tech sucks. The process, the people who complicate everything, all the unnecessary features that bloat the code, spending all your day reviewing pull requests, etc. But building software in general is fun. For me it's also not so much about the software but about the business. When the business motivation is clear and I believe in it, then I'm motivated to build software. And when I say business motivation it can even mean me wanting to learn something.

I'm in agreement with you that it's about the business and having the passion and motivation to solve the problems of that business. When I look back on my software career and think about the projects where I didn't have an interest in solving that particular problem, I would always revert back to just learning the technology for the sake of learning. For me, just learning and not applying was never as fulfilling as doing both.


I think it's worth mentioning that I'm 27 and almost 4 years into my career in software. I am convinced I have the best job of any of my friends, or just about anyone I meet at my age. I make more money and work less hours than >95% of my (all college-educated) friend circle. I don't feel stressed at work ever. My team supports me, my manager encourages me to expand my skillset to whatever interests me.

My career trajectory is looking phenomenal, and I find software development generally fun & rewarding (although certainly not all the time!).

But who knows, maybe that will all change by the time I'm 55 and I'll hate that I spend my career in software dev. Seems unlikely.

Stop building web apps. A terribly wrong turn was taken about two decades ago. Your problem is you're building web applications.

Desktop development is the Once And Future King of computer functionality and personal productivity.

FYI, I have built a great many things in my career but not one of them was a web app. Mostly, it has been data storage systems, from single host to few hosts to many hosts to one of the largest three or four such systems in the world. But hey, great guess.

You sound super burnt out and taking a (possibly permanent) break sounds like just what you need. On the other hand I, at 50, am looking forward to another 25 years of programming with any luck. I think almost everything has improved since I first started with much improved processes (no more waterfall), new and interesting programming languages (with jobs using them), free software becoming firmly established, much better tooling, more interesting work (cloud and distributed systems have added much fun, including improving those distributed systems), enlightened views on testing and documentation being very important (I remember when simple unit tests were frowned upon as wasted time), nearly everything in the software process is automatable (CI, CD are great), etc.

I obviously am at a different place than you but I don't think everyone who enjoys the work has Stockholm Syndrome and needs to be pitied. Some of us honestly enjoy it and I plan on working as long as possible as I really like the external supply of ideas to create.

Though had my carrier taken a different path than it did I can easily see being as burnt out as you. I worked briefly at a large enterprise company (not software makers, think greek sneakers) which was so terrible.. if that sort of job was my only option I wouldn't have lasted a decade in this business. That place was seriously depressing.

> Some day most of you will get over the dollar-induced Stockholm Syndrome that seems universal among junior developers

We aren't working hard because we just want money. We want to save up enough money so that we can retire at 55 and stop working. Then we can start spending all our time complaining that the software industry is going in the wrong direction.

Because in any other industry, the effort:earnings ration isn't nearly as good, so we'd have to work into our 60s before we could do that.

> We want to save up enough money so that we can retire at 55 and stop working.

If that's what anyone takes away from my jeremiad, then I actually think that's pretty great. Except ... why not 45? Maybe if more people could use software development as a quick route to something else that created more personal satisfaction and/or social value, that would actually be a good outcome. A bit more "it's just a job" and a bit less "it's my holy calling" is a necessary ingredient in that formula.

Not everyone here works for FAANG companies in silicon valley. Retiring by 45 is possible in much of the rest of the country but one has to go hard to do it.

For myself, I simply wanted to be free from financial worries and financially independent. I hit that at 35, and yes, I'll probably be able to retire by 45, but I'm a bit too frugal for my own good. For someone living a more 'balanced' lifestyle I think 50 or 55 is a fine goal.

Have you ever worked as a manual laborer? I spent most of my life working as a lawn keeper, warehouse laborer, retail associate and construction worker. Building software is such a breath of fresh air. Even the bullshit that comes with it is still better than the day to day bullshit of any of those other jobs.

It may not be perfect, but man is it better than what so many people do.

I've been doing this for over 20 years and feel the exact opposite. The process for getting an idea turned into working software is faster, easier and better than ever. You are looking at it from the inside. All the mechanics have changed from how you were trained and now the process is no longer bottlenecked by the kind of problems you are used to solving. From a higher-level perspective, businesses are 100x smarter about how to think about digital problems and solutions, what kind of talent they need to execute and how much it costs. Nothing will stop executives from trying to squeeze budgets and timelines, but that's human nature. But now there's a chorus of experienced people who can speak the truth, who know when to build vs buy, who know what quality looks like, who know that user experience is paramount. Software development has become commoditized which sucks for developers, but it's great for software.

I totally understand people who are burnt out on building commercial software. The incentives are often to create systems that work poorly for both users and are hard to work with for developers. It's a miracle when that's not true!

However if you're really burnt out, and still want to exercise your skill, take a break and give open source software a try! I'm still having fun building http://www.oilshell.org/ after many years.

If you're building it for yourself, open source software can be fun, and it should have the side effect of being useful to some others as well.

How do you make money? Do you live on savings?

Yes, although I worked on open source while employed for 6-10 years too (sometimes it was my job, but usually not).

I'm not saying that it's the way to spend the least time at the computer :) I'm saying it is a way to avoid being burnt out.

If you are building something for yourself, and others incidentally get some use out of it, you'll be less likely to burnt out than killing yourself for a deadline made-up by a VP. And then the whole project gets through away, and no customer ever cared about it. I've seen that a lot.


Related story: Many years ago I got burnt out by my job, and I took a woodworking class at night (lol, definitely a programmer thing). It was great, and I'm typing on top of a desk I made in that class right now.

However I bought a bunch of magazines about woodworking, and I noticed that everyone had 8 or 9 fingers, so I didn't go further with it :) The thing that the OP pointed out is real!

Plus there's a massive amount of pollution, growing by the day. Everything is built on an increasingly shakey foundation and starts rusting right away. More time is spent on trying to figure out why X isn't working, less time on actually building.

A couple recommended talks about this subject.

Preventing the Collapse of Civilization: https://www.youtube.com/watch?v=pW-SOdj4Kkk

The Thirty Million Line Problem: https://www.youtube.com/watch?v=kZRE7HIO3vk

Your first paragraph nails it completely. The entire software ecosystem is like having infinite layers of train crashes to fight through every day.

The purpose of a lot of software is to make software, not to solve problems.

There's nothing stopping you from getting an FPGA board and rolling your own CPU, system, software stack from the ground. It's easier than ever before to walk in the footsteps of Woz or so if you like the idea.

I am not so old, but I also remember a time when software development was much more enjoyable. The difference is that at the time software engineers had more autonomy to decide what to do. Nowadays everything seems to revolve around fads. If you're not into the latest fad or have some ideas that differ you'll suffer resistance all the way around: in the job, online, when doing hobby projects, etc. Even open source nowadays has to conform to some well-supported online fad, otherwise people will complain of what you do.

Self-determination Theory predicts this. It’s my favorite theory on about intrinsic motivation.

I'm not far behind you in age, but I started crazy early in life.

Well, I think the big question is, are you /developing/ or /hacking/? Hacking is fun, developing is a job. Hacking is in a language and stack that's probably a bit unstable, that most shops wouldn't let you use in production. Developing is writing code at about 30% of your ability to express yourself, to avoid someone half-reading your code later from misinterpreting it.

Sometimes you can intermix the two to make the job better. Sometimes not.

>> I sincerely feel bad for people who have to stay in it

This seems a really sheltered perspective without a real idea of the kinda struggles that exist for a lot of other careers. Not unlike some doctor/lawyer/scientist/executive talking about the profession as a "train to hell" because it doesn't satisfy some sense of technical purity.

Before building software, I was stuck in dead-end sales jobs with a humanities degree that had no career prospects. Switching to software development has required a great deal of sacrifice, and I'm genuinely thankful every day I get to write code for a living I'm thankful.

- I'm thankful I can get paid well enough to live comfortably.

- I'm thankful I work in clean, climate-controlled offices.

- I'm thankful for a profession full of interesting people to work with.

- I'm thankful I can engage my mind and excercise a certain amount of creativity in my work.

I really hope 55 year old me can remember to be thankful.

That's a good point, and I am grateful. "Train to hell" was hyperbole. Programming is still a damn good profession compared to many others. It's also far less than it could be. These statements can both be true simultaneously. After some years of the particular issues that affect older programmers, made worse by the fact that they're almost completely ignored in a youth-dominated industry, 55-year-old you might be less sanguine about the whole thing. Don't be quick to judge when the other person has been where you are and not vice versa.

I've been able to, most of the time, work on (somewhat) novel problems, at least within the organizations I've been working, and certainly interesting ones to me.

But I've always enjoyed tinkering on non-productive personal projects more. Exponentially so. I'm with you on most of the things sucking in software development.

I spend so much time on shit. Politics, presentations to justify spending 0.000001% of our budget on things I need, convincing others that maybe we should leverage well established best practices, not even controversial or cutting edge kind, but the actual ones people everywhere use, rather than re-inventing the wheel every time.

Right now I'm expected to inventory our software catalog, again, because someone doesn't want to get that information from the place we are using to already document it.

And it's only Monday. This week will be long, so very long.

I think for some people building software became about making the most amount of money they can possibly make, it became about grinding leetcode to get that sweet package at FAANG.

Startups became about flipping crud apps that try to get users addicted to them.

There are still cool and honest jobs out there! Work in a space you care about and have fun, filter out anything with VC money or FAANG. Usually older companies can be more rewarding from a career perspective, you also get to work in bigger projects with more responsibilities as well as you aren’t competing against 50k’s of software engineers to climb the ladder.

I still build software. Every day. I delivered my first commercial product in 1978. I cannot recall a day that I've never written some form of code. Even if only a line or two. Made notes about writing code. Thought about how to solve a problem and the code involved.

I don't think I've ever worked a day in my life.

Well, not strictly true, I've had several jobs that start out with interesting problems to solve and then became "it's another CRUD app." I quickly left those jobs to find other work.

I'm not cheap but then I'm not well compensated. I don't make FANGMAN income, but I am financially comfortable. I've found joy every day in my work, even if there are many days where the work in utter frustration, by simply seeking out the kind of work that makes me happy. With an interesting problem I will work all the hours my mind and body can muster. With a 9-to-5 "what's the point/what am I learning/this has been done eefore" regular work-a-day job there is no amount of money on this green Earth that could get me to focus or be happy. Well okay, there would be a certain amount, at which point, after 12 months, I'd quit, take the money and go do a different job that pays less but is more interesting.

This course of action isn't for everyone, not everyone has the privilege of saying "F* it! I'm out." when they are doing something they don't find joy in. I've just made sure that I never put myself in a position where I couldn't choose that course of action. The road has been hard some days, and money has been tight more often than I want to recall, and I won't die a wealthy man, but I will have had adventures along the way that keep me still striving to build software every day.

Footnote: My job last year consisted of writing kernel drivers to speed up SSDs. My job at the beginning of this year was control a radio controlled car from your cellphone. Then I built a dashboard for my home that tracks my phones and my cats and the weather. My job, right now, consists of building a stupid simple app (with a lot of screens and moving parts) on a mobile device that talks to OpenWRT to put a pretty and simplified user interface on what is a complex piece of software. I've never had to build a mobile app that tries to simplify a complex router interface before. It is a learning experience. But once I've learned that lesson, I won't be building another one. I'll go find something else to do.

Life is what you make it.

How I miss the old days simplicity. One php File you just uploaded with ftp and that was the deployment. Now you need to know so many frameworks and processes to deploy a simple web app. It’s overwhelming and I get anxious because It’s so hard to choose what to learn.

My current project is one file with html,css,js all in one. I am using Vue, stripe, and three.js. To deploy I git push and then render handles all the rest (including provisioning a free certificate).

Honestly it’s easier now to do things like that than 15 years ago when I first started.

You can still do that. There is no need to use a complicated stack when the problem is simple.

> an obscenely large pseudo-object-oriented codebase

It shocks me, just how often OOP is just not nearly the best approach to something. I certainly still lack in experience though. But why use OOP for something like putting data from a sensor onto a bus? And stuff like that.

A younger developer might think the tools that suck. A younger developer might think that the older developer's reluctance to embrace change or recall the time when they were beginners is part of the reason why they suck. Like git. Git sucks.

If you think git sucks, which VCS sucks less? I've only tried TFS and SVN myself, but I find git the best option among them.

I think this is precisely the problem. Sure, you can make incremental improvements to existing systems, but what if all existing systems are bad? Once in a while, you have to design a totally new system based on concepts and metaphors that everyone understands.

Mercurial is a contender

I guess I'll have to try it out one of these days, thanks!

Nice. Best of luck in your future endeavors.

Me, I'm about to turn 50, and I don't see being able to retire until... well, ever at this point.

I might change careers some time, but I doubt I'll entirely give up on software. Maybe just do it for fun.

What are you moving on to ? And can I come along (52) ?

I'm sorry you don't enjoy it anymore, but this being your last week is pretty great. Enjoy your next endeavors!

Software development is like building a house with a hammer that continually change its shape and hence how it’s used.

People used to really hate farming too. How do I know this isn't more of the same?

How did you escape?

Asking for a friend.

The grass is always greener on the other side. Let's see.

I have 3 degrees in unrelated field (Industrial Eng, Theology, and CompSci), and worked in on a few careers, white collar jobs like being a sales engineer at a biodiesel company, helping running a cafe for a family business, being a church administrator before the current software engineering. I also worked on low paid labor jobs such as laundry, dry cleaning, deli, restaurant. All with their own physical risk, tiredness, stress from customers, etc.

The current job which is software engineering is far better than any other jobs that I had. It is pretty stable, great income, great benefits, stress free, not limited to space and time, can WFH, more flexible schedule, etc. I like software engineering a lot so I did side projects on the side, learning various programming languages, programming techniques, reading programming books, etc.

Now I am bored of all of those as well, and right now just focusing on my hobbies. I am focusing a lot on my musical skills right now, and that's the only thing that captivates my mind daily, not programming books, programming podcasts, etc anymore. Software is just another job. I'm not changing the world, not saving lives, not helping solving global warming or pollution or the declining flora and fauna that we have, or ending wars. It's riddled with churn mentality in this industry, politics, etc.

Somedays I dream of making it in the music industry, or creating a small cafe with aquascapes that I create as decorations, or not having to work at software anymore, or not having to work because I need income.

But in the end, I still work as SWE. The grass is always greener on the other side, and that depends on one's position in life like age, economic situation, etc. Right now I don't have the luxury of leaving my SWE jobs, and no I don't do this for myself, but for my family members.

wait... your software engineering job is stress free? That surprises me.

As I see it, it's mainly a question of what you look for when interviewing. If you look for money then you'll likely get more stress. If you look for calm then you'll likely get less stress. You'll also get less money but nothing in life give you everything. I've turned down multiple offers when it was visible they valued workaholism or had bad processes.


I am paid pretty well at my company right now, but there are always my colleague that I know get a higher offer for some other role. I can choose to get salty about it or just try to transition with that role but with less satisfaction and more learning.

There are more to life than just chasing money. No matter who you are, peasants or kings, you are only given a limited time to live. We trade 40 hrs of our life for some numbers on the computer that can go up or down, meanwhile the rich just gained a lot of money due to this pandemic.

Yeah. You don't need to make bad money if you want a lack of stress but generally the difference between good money and great money is going to be a lot of stress.

Yes in the another profession but thankfully not so much in SWE world.

Every software engineering job I've had was stress-free. In 10 years, I never had to do overtime. Quite frankly, if something can't get done in 40 hours per week, that's not my problem. That's the company's problem, and I will work on that problem in the hours I agreed to sell to said company.

Yeah it is. Maybe stress is relative for people.

I've been in software for a decade now and I would absolutely call my job stress free.

My broader family is almost entirely working class though, so maybe it's just a matter of perspective.

Software development is not your calling, it's just another job for you. A very good job, but still: just a job. I'm not critcizing you, just stating how I understood what you wrote.

Difference between something that's your calling (music, judging by what you wrote) and a job is that you don't invest emotion into the job.

When you invest emotion into what you do, when your craft is sacred to you - then you experience disappointment when you see other people in the field not caring as much as you do.

When you follow the industry and the trends and when you understand that most of what you get to read is fake - a huge pile of disappointment creeps up. I'm in the same boat as the OP, and oddly enough - I'm preparing for the same line of work - woodworking :)

Honestly, I can't wait to leave this world of software development where most of what's available is fashion or just pure bullshit sprinkled with lies, but I have to pay the bills and mortgage so I can't afford to leave right now.

It's not about grass being greener on the other side, it's about not having to put up with other people who are often dead wrong and completely impervious to any kind of reasoning. Leaving software development business does not necessarily mean one stops writing software. I can't see myself stopping writing code or thinking in code when I finally leave IT, but I can't wait when I get to stop to absorb fake content from linkedin and when I don't have to read emails that are 99% white noise and 1% useful information.

Indeed, it is not my calling. I think earlier in my career I thought that way. But I also don't know what my calling in life anyway for now.

I think I'm pretty good at my craft because I spent time after work honing it. I am in the same boat as OP and you, already went through the disillusionment, but I have other things that satisfy my creative side and physical side, besides I need the money as well.

In regards to social media, I stayed away from Facebook, Twitter, Linkedin (pretty satisfied with my current job I don't need other roles). I still use Reddit, Youtube, and probably other visual/audio social media for reasons related to hobbies.

This made me laugh, because I actually am planning on making a transition to woodworking. My house is paid off, and I can live on a fairly small income that I can probably generate mostly from passive income. If I can actually supplement that with building furniture, bonus. If not, then I still get to build furniture.

As a warning, you're eventually going to run out of places to put that furniture if you don't sell some of it!

I'm the OP on that github issue, and while my partner and still have some IKEA furniture I'd like to replace, we also have a couple of pieces of mine that don't fit readily into our lives that we just have around the house. The chandelier on my website[0] was a spec piece built for a show at the Wharton Esherick Museum[1]. It didn't sell at the show, and I don't really have a place for it. It's now sitting in a crate in a corner of our bedroom.

Likewise, the Federal period shelf clock[2] is without a shelf and is also sitting in a crate until I get a chance to mount a shelf for it. How hard can it be, you ask? Surprisingly difficult in a log cabin. If the pandemic ever ends and I get my workbench out of our living room, I might have a place for it!

[0] https://www.longwalkwoodworking.com/#/chandelier/

[1] https://whartonesherickmuseum.org

[2] https://www.longwalkwoodworking.com/#/federalclock/

The software developer turned woodworker keeps reading HN? :P

Yeah, it pretty reliably turns up interesting articles from the long tail (are the cool kids even still using that phrase?).

You can checkout anytime you like but you can never leave

You really missed what that songs about.

You might find that what was a hobby is not as much fun as a job.

I mentioned this to an actual "rock star" developer London session musician with a doctorate in music who moved to development after teaching themselves after an accident.

I have a job writing software, and in my spare time I write software as a hobby. The job is much less enjoyable than the hobby, because in the hobby I'm doing, by definition, only things I like.

I think any hobby is less enjoyable when you have it as a job, since you sometimes need to do things you don't like doing or aren't interested in.

There are lots of people who generate income from some type of cottage industry hobby. Woodworking, candles, jewellery, preserves, decorations. If you’ve got a bunch of equity to fall back on (in the form of your home plus securities), then you’re in a much better position to escape the pressure to do unwanted work.

The above is one of the major reasons I’m such a fan of basic income. I think we’d see a lot more cottage industry shops, used bookstores, cafés, and the like, if we all had basic income to cover our basic needs.

Heck, even software developers can get in on the game by working on their own passion projects. Whether it’s indie gaming or retro computing, a new photo editor or CAD software, or perhaps a new sort of application never before seen. There’s just so much cool stuff people can do with computers when they aren’t trying to build a startup aimed at a big exit.

For me its always a sign of that they have precarious finances or are posh enough to leverage that into high end clients.

Add me to the list of software developers who desires to switch to woodworking/machining.

Less machine learning, more learning machining?

Less training models, more model trains

Add me too. Somehow the joy of seeing things being built from raw materials in the real world equates that of complex software being created out of nothing. But the finite element of the real world has that extra satisfying element: no dependencies to update, (mostly) no security patches, generally less maintenance, and it lasts longer.

No undo button. CTRL-z is the thing you will miss most in the real world.

True, for immediate things having this ability is a godsend. But as software and bugs "dry up", it can get just as hard to chisel out as physical material.

Timber framing here. That's woodworking.

I too would love to do it. It irks me to this day that I was taught nonsense such as latin in school instead of woodwork or metalwork.

Serious question, didn't anyone else' school have shop class? I was a college prep, NHS, cross country, all AP core courses kind of guy, and I took it all four years of high school.

Or was there some kind of restriction on taking it at your school? Or maybe your parents didn't let you?

Genuinely curious as to why someone with a professed interest would not have taken shop?

Shop was heavily discouraged for college-track students when I went through high school, both by the administration in terms of guidance counseling and timing of the classes, as well as through heavy social reinforcement by peers.

Pretty much this at my high school as well. They had a shop class and auto repair class. I really wish I had taken those (I did take shop in middle school though).

Largely we had to choose -- take the college prep classes (AP whatever, languages) OR trades classes. There was definitely classism -- "trade classes are for poor kids". =(

I would much rather schools require things like: financial literacy, and building/repairs/cooking. They are lifelong skills and very useful. There's no reason its an either or proposition.

Perfect example of why so many people hate high school. "Avoid this thing you're interested in because it won't help your career prospects. Also it's a waste of time."

There was a special program at my school that gave you more shop classes. They did everything to discourage me from joining it, because it's where they shoved the struggling kids. I really enjoyed it, and really can't see why it was just for struggling kids.

This was the last year before the school reform. They ended that program. In fact they ended shop class altogether.

It was only offered in certain types of secondary school. Mine was considered 'posh' and so we wore blazers and learned latin, whereas other schools didn't have blazers and offered 'trade' subjects.

At my high school shop was at the same time as band and other music classes, so you couldn't do both.

Lots of schools don't have the classes though, probably mostly because of funding.

And insurance.

Mine did, but in my sophomore year, they were cut due to budget constraints that failed to meet a referendum. Industrial tech, foods, automotive, and welding all got the axe. Music and sports only stuck around because of the boosters. The Cisco and CAD classes stuck around because the local community college sponsored them, which is how I ended up where I am today I guess.

I don't think mine did. Maybe. I remember hearing one classmate mention shop once, but maybe I misheard him or he was joking or something. If we did have a shop class, it wasn't advertised, I don't know who taught it or where the shop was.

Primary school a little of pottery and woodworking. Secondary school sewing and cooking. High school nothing.

High school was 20 years ago for me and no shop classes.

It was over 20 years ago for me, and we had shop classes. It's amazing how heterogeneous the US school system has been, and continues to be apparently.

To be completly honest, we had a lot of classes of metalworking, woodworking, textiles, etc in our school before the '89 Revolution in Romania.

I really enjoyed it and it made me love working with materials and building physical things.

Still writing software...But renovating my house was a nice way to remember all that lost skills.

'Design & Technology' (woodworking, little metal, textiles, food, etc.) is on the curriculum in the UK, so I did that. Had to take one variant at GCSE, I did electronics. (Having waited practically my entire school life to have a lesson that was electronics and only electronics!)

But it irks me to this day that the language I opted for, Latin, was dropped that annus, because not enough others signed up.

You can't please everyone. (I did like wood/metal work though, just not as much by far as electronics. I'd be much more interested now though - I watch an awful lot of it on YouTube.)

At the end of the day, we're people who build stuff and problem-solving/analytical skills are transferable.

The draw to these seemingly not-so-adjacent fields is strong.

In my High School I didn't learn Latin, but I did learn some wood and metal working, and also a little bit about engines.

I wish I had taken anything but latin in HS. Only reason I did it was because of colleges requiring foreign language classes, and by the time I had graduated, I didn't have any plans of going to college.

How about robotics? It would allow you to combine mechanical engineering with CS.

A lot of modern mechanical engineering practice is building and using software.

Source: am a mechanical engineer who works on my industry's software

I like to build synthesizers.

Funny, I want to move to a farm and keep goats and chickens (I am a Systems Architect). I still want to code in my spare time, if only to just pass on the skills to my offspring.

The great thing about chickens is that they debug your farm for you :-)


the downside is you have to 'install' and continuously 'run' a shovel

Did this 25 years ago. Never looked back.

eta: Admittedly I did a bunch of design/architecture consulting and teaching tech courses for the first decade or so to pay for the farm. Consulting is a good way to keep your hand in, and teaching serves as a great marketing platform for the consulting work.

Have you ever worked on a farm? If not make sure you understand exactly what it entails. Most people who've never done it vastly underestimate how much work it is.

That said, a small hobby farm with goats and chickens doesn't take much work. But going on vacation can be problematic.

Damnit, that was my plan too, only I have no passive income, so customers (or contracting) would be important. Hopefully this trend doesn't continue to become a glut of Silicon Valley woodworkers...

I won't move away from my main job for a while, but I do want to move to a lifestyle where I grow all my own food. It's a very interesting problem, of whether a single person/family can be mostly self-sufficient on food while spending only a small part of their day growing the said food.

Lots of biology, perhaps a little bit of tech thrown in, if it helps.

I think you easily can, the difficulty comes with whether you can be happy with what you're limited to, so more a question of personal tolerance for lack of variety in order to be happy with your food, IMO.

I thought about this as well. I think that I'd be mostly okay on the vegetable front but I don't think that I'm up to plucking chickens or raising animals. I would also need a bigger yard!

I am pretty okay with it. I eat meat. I have done the dirty work in the past, and I am willing to do it again.

I'm pretty sure that the animals would become my friends.

> passive income

Just curious: is this income 100% passive?

There’s no such thing, there’s just varying degrees of risk vs leverage.

Of course there is, within a defined timeframe. If I bought 5-year government bond last year, then this year it's 100% passive income to me. I don't have to do absolutely anything in order to get it this year.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact