> People are increasingly getting into the field for the pay rather than for a love of programming,

> the quality of the software being produced is decreasing

I feel these two are related. I mean, one could say the same looking at companies like Boeing post McDonald Douglas merger.

> Honestly, I think it's time for me to find another line of work.

Count me in when you find it!

What I miss from technology is the group of people I used to collaborate with during my university years. We used to work on one thing and one thing only (UNIX Philosophy anyone?) and there was no way we would not master our craft back then or the subject we were given to work on.

Nowadays everything feels like work on bleeding edge and don't care about the quality of code nor the security of your own libraries.

I feel so awful with myself for choosing such a wrong direction.

It sounds like you're in webdev. :p (I stay away from it for an ineffable mixture of feelings I get from it that are similar to yours even though my programming career is too new to have your memories or preconceptions.) How true is this for work with legacy codebases or embedded?

From friends that work or have worked with both legacy codebases and embedded systems I can say this: those who worked or still work with embedded systems love it, because they are working on a single thing only.

Those who work with the legacy codebase, it really depends of the type of legacy infrastructure.

If it's a mad chaos, they prefer not to discuss it with me because they get anxious knowing they will work on that monstrosity the very next day and don't want to ruin their evening lol!

Else if it's rather clean comparing its legacy status, they don't mind, but worry about their future; they don't want to stay outdated from a tech point of view, in case they need to look for a job.

There's nothing wrong with programming for the pay. Your motivations shouldn't have an effect like that on the quality of your work. Even if you love programming, do you really love the programming you do at work every day?

There are lots of great reasons to pursue work in computers, and not wanting to clean toilets for a living is a perfectly valid one.

I'm not saying that there's something wrong with being motivated by pay, although I do think that is one of the factors that has led to a decrease in software quality over the years. (If you're doing a job just for pay rather than because you enjoy the work, you're much less likely to go above and beyond to produce the finest work you can do.)

It's just not what motivates me, and I'm commenting about why I don't feel like there's a role for me in the industry anymore.

> If you're doing a job just for pay rather than because you enjoy the work, you're much less likely to go above and beyond to produce the finest work you can do.

Just spitballing, but I wonder if that’s in part because theres not much monetary incentive to go above and beyond.

Companies don’t seem to give out raises or promotions for good work as much as they do for more political reasons. And I’m sure we’ve all heard stories about the new guy getting hired on for much better pay than the loyal veterans. Personally, this is why I think job hopping and resume driven development are so popular.

If I’m someone primarily motivated by money, and there’s no monetary incentive to go above and beyond, why would I waste my time trying?

More money won't make me do much more. I already get enough, and my dislike of something and the added stress of slogging through it isn't worth it. I'm not a frycook desperate for more hours to make rent this month.

Genuine interest in the technology? That'll boost my competence leaps and bounds (through the experience I have pre-cached from my time off of work alone) for no extra pay!

In other words, at dev level,

> someone primarily motivated by money

is likely far too up Maslow's hierarchy for extra pay to make up for the problem of having pure "hired guns".

> [...] the most visible parts of the industry have some serious ethical issues that nobody seems worried about enough to even start to talk about addressing them.

Thanks for sharing. What kind of "ethical issues" are you referring to?

There are all sorts of ethical issues -- just take a look at the industry news over the past couple of decades for a taste.

But the ones that bother me the most are the ones where we abuse our customers for the sake of profit. Issues like data collection and use, "move fast and break things", removing customer autonomy, etc. are all things I struggle to be OK with, but are all things that are heartily embraced by the industry these days.

And don't even get me started on the acceptance of overt law-breaking. Companies like Uber (only an example, they're not the only ones that have done this) achieved success by breaking the law, and overall as an industry, we tend to accept this and even celebrate it -- as long as a successful, profitable business is the result.

I like to think of it as "move fast, don't be afraid to break things, and fix them fast". I've been in workplaces with months long release cycles with multiple versions at various stages of testing and it's incredibly slow, difficult and problematic. I've also worked at places where if code touches the main branch, it's in production in about 5 minutes. In the latter production was broken about half a dozen times in the first year. And it was always fixed in about 10 minutes. In the former, there are bugs that take months to correct. I'm not convinced the latter option isn't the better one.

Much like you put up hand rails on stairs, you will put guardrails on your CI/CD pipelines and processes. Do you do this from the start, or along the way. It really depends on what state things are in. Most industries cannot tolerate the development of software as more of an engineering discipline. This is disappointing when the likes of the auto industry doesn't. But it's largely expected otherwise.

Software development is a craft discipline, not an engineering one more often than not. Most systems are not life and death critical. It's more akin to making a dog house than a sky scraper most of the time.

"Move fast and break things" was originally meant to refer to agile development methodologies that encourages developers to iterate quickly on their implementations and to encourage a development culture where developers are not afraid to make changes to the codebase. However, I believe the quote "move fast and break things" has unfortunately been used by some people to justify and encourage reckless, socially-damaging behavior by companies and individuals. I believe that's what the poster was referring to when critiquing "move fast and break things."

Oh, I definitely get it... I also remember an Alt.Net movement (people that liked C#, but didn't like the MS "enterprise" patterns) that had a motto of "running with scissors."

Of course, there's also times where intentionally breaking something is the best solution to getting the fix done. From literally deleting the code/class/library that you are replacing and dealing with all the compiler errors as part of the fix. Or similarly, actually shutting off the non-secure protocol servers when the company decree has been to only use secure channels (TLS or similar) for communications, and breaking the systems that are still using the insecure channels after remaining up for years, "just in case."

> I believe that's what the poster was referring to when critiquing "move fast and break things."

Yes. The original sense of the term was fine and expressed a reasonable thing. Since then, it's been taken much too far and has been applied far outside the development process itself.

This attitude is, in my opinion, one of the things that has turned the software industry from being mostly a force for good into a very mixed bag.

Thanks for sharing. If you could share also, what was the field like for you when you first came in?

I think the main difference is that the field has effectively turned into a kind of factory work.

An analogy to the car industry holds very well, I think. Early in the automotive days, people built cars because they loved to build cars. As it became an industry, and then a mature industry, that was largely lost. Now, the people who "build cars" are factory workers, punching a clock and putting in their hours. The industry stopped being about excellence and started being about maximizing profit.

That's where software is now.

I'm not saying that's a bad thing. It's clear that's a natural progression of new industries. However, that's not the sort of work that I want to do, and not what fulfills me.

I'm increasingly suspecting that there is no longer a role for the likes of me in the software industry.

It depends... you could always start your own project or work on tooling. Whatever you do, needs to have some market to survive, but there are options. Even if less well paying, less secure and/or less stable. Or, harder to break in to.

> you could always start your own project or work on tooling.

I've been successfully doing that for most of my career, actually! But even as a small independent, you can't ignore the nature of the industry. Especially if you're selling to the industry. So it doesn't shield you from the market forces very much.

I fantasize about there being a market for high-end, boutique tools, libraries, and such -- but I don't think it exists. I'm not sure that it can exist given the nature of the industry overall.

I was mainly meaning, working for a company that already provides some kind of tooling. :-)