Need some advice, feeling depressed about the direction of our industry | Hacker News Reader

Need some advice, feeling depressed about the direction of our industry

61 pointsclouded131 comments

First post here. It's 2 AM and can't sleep. I'm 40 and the majority of my experience has been in Java. Spring, Spring Boot, Hibernate, what you'd expect. I'm pretty much at the top of my game (which I know is specifically Java, but bare with me).

We all know technology constantly changes and progresses, and I've always thought that's fine, I'll be happy to learn whatever replaces Java because it will be better, right? I've seen Go coming along, Kotlin too. But I've been hit like a brick in the face to realize where we're headed. AWS. The cloud. I'll get to the point. I hate it. I've seen it happen personally at two companies now. The transition to the cloud. Where we throw away everything we've spent years learning to reinvent the wheel. We throw away relational databases for MongoDB. I love SQL. I'm good at it. But no one cares. MongoDB is "in" now. I'm good at Java. Years of experience and I finally feel good in my abilities and speed with the frameworks, ORM's, best practices, etc. We're just throwing it out like it's nothing. For AWS products. Lambdas written in Typescript (why Typescript, I don't know, the same reason I don't know why MongoDB). Files of YAML configuration, and Kubernetes and a lot of other things I don't care about, just to create the same CRUD apps we've always been creating.

I've been buying power tools and learning how to use them. I've started taping and patching drywall. I've cut down trees. I want tools that won't change every 5 years. I want tools that I can master and will be relevant in 50 years. Maybe I'm too old to be a carpenter, or tradesman. I just need some advice. The worst thing is, developers are embracing this AWS trend and seem to love it. No one seems to mind. Software engineers are cursed. Just when we've established a best practice and it's a solved problem, we throw it out and reinvent a new way to do it.

Please let me know if I'm not alone, or if it's just me and I need to adapt or get out of the way. I will predict this though: AWS is a mistake. It's not fun. It's not "software engineering" and it won't be here in 10, 15, 20 years. All your mastery of Kubernetes will be for nothing. It will be tossed aside like trash. And the worst part is when that day comes everyone will act like it was never that great all along. They'll also embrace the next trend like it's the greatest thing ever. Because software engineers are cursed.

View on HN

First of all: You have deep knowledge. That is good and valuable. The Java ecosystem is not going anywhere and it will stay relevant for years to come.

But there are also other technologies that have their merits. I understand that you find it frustrating to look at them and you feel like it's a huge wall to climb to also learn these technologies after you have invested so incredibly much time in mastering the Java ecosystem.

My advice to you is: Don't stress out over it. Explore these other technologies without having to think about how you will use them in your professional life. Take away the pressure and focus on the enjoyment of learning something new. Eventually you will learn enough for it to be useful. And as stated previously: The Java ecosystem is not going anywhere.

You might also want to check out Clojure. It's a very different language but it uses the Java ecosystem, so you will still feel at home. https://clojure.org/

I'd recommend Kotlin instead of Clojure because it's very useful for making mobile apps.

Clojure has multiple hosts, I think there's at least 3 platforms that can make mobile apps under Clojure

ClojureScript -> React Native

ClojureDart -> Google Dart

Clojure -> GraalVM

Four if you consider Unity via Arcadia on Clojure's .net implementation

Most businesses I come across use React Native via CLJS

I don't think it has to be "instead". Both are good languages which use different approaches. And both can be fun for different reasons.

Clojure seems like the better choice for learning new stuff, coming from Java. A paradigm shift, which includes necessary learnings for understanding a lot of "new" technology.

I hate inappropriately used MongoDB, Lambda functions, and microservices. I also don't think they're "in" anymore: the pendulum has swung back towards the middle and SQL with an actual schema, code that isn't scattered all over a web UI, and monoliths are all back to being defensible choices.

Software engineering isn't just knowing the tools, I think it's also seeing the patterns. Consider a queue. It doesn't matter if you're using Kafka or SQS or a jobs table in PostgreSQL read by a monolithic application, you're still going to wrangle with similar concepts: dead-letter queues, at-least-once delivery and idempotence, updating the schema of your in-flight messages, timeouts and retries, transactional all-or-none message delivery, large replays if your consumer went down, physical capacity running out. Knowledge around these problems won't expire, although it might become more niche or less useful.

I disagree, I think we just got caught up in a whirlwind in 2015 that people still haven't recovered from.

There actually hasn't been any real trend away from current tech since about 2015. People are still using the same TypeScript/Node/Python/Go and GraphQL/MongoDB/Postgres stacks, still using Docker/Kubernetes, and still using React/Vue for frontends.

The trend towards cloud-based services was also started around 2015. People are still using Heroku despite it largely being considered stagnant. Cloud services like AWS are just more convenient for teams that don't own hardware.

I don't see any of this tech going away or being replaced because I don't think anyone can think of any better abstractions right now. Hardware and platforms would have to fundamentally change in order for software engineers to start thinking up new ways of abstracting them. Current tech stacks will of course be endlessly tweaked and "improved", but I don't think anything major will change for a long time.

The newest thing that I can think of is just a CSS class library called Tailwindcss. That's literally the only change in my basic stack in the past few years.

I also don't believe any core tech is being thrown out. As others have said, the initial excesses of the web tech whirlwind are receding back quite a bit.

Based big thought here. It's curious that industry tooling is arguably plateauing around then, but it's also amazing that the database, er, SaaS is on such a long run, like from a diffusion of innovations way.

When I was a kid I learned Logo and Basic and then Pascal, later C, and a bunch of other languages. In the late 1990s, there was this huge trend where a fancy 'new' language was embraced by everyone and their mother: JAVA.

I thought Java was bullshit, it's basically just some strange dialect of C running on a poorly written virtual machine. Everything you wrote was dog-slow. (I can't remember if the security problems were there from the beginning or were a 2000s thing.)

I was sure it was a passing trend and in 10, 15, 20 years it won't be there. And - compared to the great fanfare and hype of 1999 - it really did quiet down A LOT since then.

I hope this helps at least with some perspective. I agree with you that "the cloud" is a dead-end. I wish you the best of luck.

>I agree with you that "the cloud" is a dead-end.

Really? I feel like it's the inevitable meta...

Too many stakeholders, from users to companies to governments, have their interests aligned in using cloud tech, and the biggest barrier to viability for any application is bandwidth.

But I hope you're right since I would consider using some hypothetical cloud OSaaS dystopian. :p

AWS is so huge that you shouldn't generalize like that. If you want to, AWS is just a bare metal box in some data center. You don't have to write lambdas in typescript that talk to MongoDB to use the cloud. You can write Java that runs on EC2 and talks to Postgres. So I wouldn't blame the shift to the cloud, I would blame whoever in your company is advocating for doing things in a way that don't make sense for your application.

Of course, but that's not how I've seen it play out now, twice. They're eerily similar in going all in, full cloud mode kubernetes docker yaml hashicorp trendy product soup. Complete with architecture teams who try to wrangle it into a best practice starter repo for all engineering teams to use. I have no say in it otherwise yeah you can deploy on a bare ec2 instance but that's too simple for a serious enterprise software developer.

Having a starter repo is a good sign. What should be happening is that such architecture teams (or platform teams as they're usually known now) hide all the complexity of how and where things run, beyond a simple set of guarantees handed to developers.

As much as I love setting up single instances and deploying directly on it, it does not scale and the quality of the deployment is very dependent on the developer. The quality and even existence of documentation for the same too.

architecture teams, platform teams or core teams as they are usually known have incentives that are misaligned with those of normal teams and more importantly with the business.

And the reason is indirection. They are two layers away from the business, shielded first by product people, then by product developers. As a consequence, they live in a bubble where nothing matters except a good starter repo or a new standard to push onto all the recalcitrant idiots that work on _products_.

I know that this notion of my job exists, but I don't agree with it at all. Making it easier to use your platform than building things from scratch is really the only way to sustainably build a platform people don't work around all the time. Being able to bake policy into that platform is just a nice bonus.

You are right about one thing though, I've seen enough undocumented deployment crap held together by hot glue prone to cause the next incident whenever someone hits the wrong button that my relationship with developers that dabble in ops is at least somewhat adversarial.

Note that this is different from developers that have a need they don't immediately know how to solve (and is not covered by a platform team) and either ask an architect (those are different from platform for us, by the way) or invest the time. That still often leads to cognitive overload or eternal temporary fixes, but it's still better than "why do you care, it works, I only had to punch 10 holes into the firewall and commit one service account key to git" type developers.

My personal experience with core teams has often been a disaster. The only successful core team I saw adopted the servant leadership approach, letting product teams make choices and staying pretty much out of their way while codifying existing practices and moderating discussions. It also served as interface to external infrastructure and engineering.

This core team was busted after a few years, its head fired and replaced by an oppressive junkie that started spewing corporate standards and imposing frameworks with the speed of an office printer.

You really have to have a special mindset to be willing to join a core team, and this mindset is opposite to what people that deliver a working product have.

There is a reason why "premature optimization is the root of all evil" is the motto of many generations of programmers. From their perspective, core teams are personified evil, because their only purpose is to optimize, prematurely.

My first experience on such a team was a team that started out improving a lacking standardized deployment process (including changing the target from a very bad slow scaling prone to errors AWS product - yes beanstalk - to k8s). The biggest benefit here was that the team was on the same floor as most developers, and the entire company was really small. We knew the challenges that developers faced.

We then eventually rewrote the platform from an "everything is implicit" approach (branch leads to deployment with stable URL x, logs end up at Y, metrics get scraped at Z) to "everything is explicit but we have a second component that emulates the old way unless overruled". Nothing changed for developers, except that they got a lot more levers.

Then that company was merged back into the mothership (it was a "moonshot startup make an online shop for us" kind of company) and everyone there that could be enthusiastic about technology was excited about the stack, considering they were stuck in the 2000s before. The tech turned out to be flexible enough to accomodate the needs of modern Scala/Node services and legacy PHP alike (with the help of a base image that included a little go proxy to add standard HTTP metrics).

Unfortunately there was a change in leadership to someone who wanted to essentially recreate a tech stack they had used elsewhere. Akamai to Cloudflare, AWS to GCP, Slack to Teams... unilaterally. The team imploded within a year and a large Kubernetes vendor came in to get developers on "standard tooling".

As far as I can tell, 2 years later, our infrastructure survives though. We built it pretty tough and I guess none of the other "standard tooling" solutions really fit. The vendor even ended up asking if they could open source the system. Unfortunately nobody in legal cared enough to figure that one out. I'd have liked it to survive somewhere.

It's a very unique story of a platform that actually evolved mostly organically, and I realize that most attempts at platforms don't work that way. I always try to take learnings from this into new attempts, and it has been working pretty well. Getting someone from platform to work in development teams is probably the most useful thing I'd recommend.

Yes.

There are two types of problematic teams in these companies. Those that never want to change anything, and those that chase new technologies for the sake of it - maybe they want to learn something relevant for the future. If you're unlucky, your leadership is too far in one of these directions too.

I can, for instance, tell you that Kubernetes is a worthwhile investment if you're large enough and you never have to touch 99% of it. People often get it wrong and throw a kubernetes endpoint at developers and then wonder why there's cognitive overload and everyone just does the most minimal thing that works without taking any advantage of the new environment.

There are plenty of places that do Spring now and manage to let developers do the things they're good at without constant interruption. You just need to find one. You also may need to learn Kafka, since that is where most of the data in large constructs ends up in now.

Is MongoDB really "in" now? From what I've seen it was popular for a while a few years ago with the MEAN stack and all that but it didn't stay popular, every job I've looked at was still SQL. I did work somewhere that went NoSQL but it wasn't MongoDB, it was DynamoDB.

In companies stuck in the 2000s it happens quite frequently that only a few people care in the first place and get a lot of reach with their notion of "hot newness", even if that newness was hot a decade ago.

I've heard some interesting takes in sister companies. Just a few months ago someone explained how continuous delivery is a pipedream and nobody does it because it's unfeasible, but they would like to not have every release (literally) signed off by management. I guess my work in the past 4 years was all a lie.

Mongodb still comes up a lot, if you hire a team in South Asia for instance it's very likely to be based on the mean stack. It works great when you're doing demos and beta testing small customer sets but it has a lot of trouble scaling. In fact, I've made a bit of a career catering to that exact situation. I just happen to have taken a dislike to SQL so I hopped on the nosql bandwagon early. Now, I'm an expert at creating complex indexes and helping people enforce schema and rationalize their operations. Often times, postgres is brought into the mix as a hybrid solution and over time dependency on mongodb can be reduced or eliminated.

Look, the alphabet soup of technologies that we read about here on Hacker News don't really represent the reality of what gets put into production and actually works. There are really only about four or five stacks that really matter, I'll leave it as an exercise for the reader to figure out which ones they are.

MongoDB has been put to shame by Aphyr. OTOH, DynamoDB is the tool of choice for Java developers doing greenfield projects on AWS.

Yes, I thought the NoSQL hype in general peaked around 2015. God no, MongoDB is out there. And they've realized that in fact data does need a schema. And transactions. So they did that. They'll probably just tack on SQL query ability at some point. It's the biggest disgrace to our field I can think of. From the people promoting and selling it by implying that relational databases just aren't good enough anymore to the developers embracing it with open arms, willingly throwing out however many years of SQL knowledge they've built up.

Relational databases are the result of 50+ years of computer science research. They're beautiful, focused, precise. They're pretty damn close to perfect. They are a solved problem. They're one of those few stable tools I was talking about wanting so badly. So what do we do? Throw it away. I'm too disgusted to continue.

You have been able to do SQL queries in MongoDB since 2018. Just this month we launched AtlasSQL, a new SQL query interface purpose built for MongoDB Atlas.

I’m going to be less sympathetic than others here and say this is a “you” problem.

Technology does change over time, as you say. Some of these changes are good, and some bad. Some useful technologies and techniques develop. Identify the ones which offer you a benefit, and reject the ones that don’t. This is one of the core competencies of a good software engineer.

If you find yourself thinking “everyone is an idiot except for me” then it’s a signal to take a step back and reflect. There are reasons that engineers embrace various different technologies. Some of them are good - technologies that provide some great benefits and which are applicable to the work you do. Others are bad reasons - including trendiness or ignorance of existing solutions.

Finding yourself dismissing popular technologies out of hand—rather than being genuinely curious about how they can be used—is a sign that you have stopped thinking with your engineer’s hat on. And I understand that this can be hard to overcome at times. There is nothing wrong with you having deep knowledge in a set of reliable technologies; there is something wrong in assuming there are no benefits to other approaches.

I will also point out that:

1. Many engineers in the early 2000s would have accused you of being a “cursed” software engineer for picking up a trendy new pointless technology like Java. Reflect on that.

2. Amazon has been providing cloud services for 20 years already. AWS as a distinct entity has been around since 2006. It most likely will be here in 20 years.

3. If you think the trades remain static you’ll also be surprised there. Tools, building materials, and techniques also change over time. Not to the extent that they do in newer industries, but also way faster than you’d think.

I appreciate the comment. I believe it is mostly a "me" problem as well. I don't think everyone is an idiot. I do think we have a bad tendency to get bored and want to chase new exciting technologies. Sooner or later anyone would just get tired of it. I'm trying to identify if I need to fail fast and move on, if it isn't already too late.

Developing software for 40+ years, I feel you.

"Lambdas written in Typescript [...] Files of YAML configuration, and Kubernetes and a lot of other things"

Building my next side project with https://www.radicalsimpli.city/

I would love to simplify everything and happily do request-server-db-server-client for the rest of my life, unfortunately "work" inherently brings "worker" which inherently brings "queue" which inherently brings "messaging" which is an "async" concept and I end up with distributed computing no matter what I do.

You feel depressed about the direction of the industry, but how do you feel about the direction of Java? I think Java and spring boot has improved by A LOT the last couple of years. And I enjoy that direction.

We are still running java+spring boot, even though we are moving from on-prem datacenters to GCP. We are moving from VMs to kubernetes/containers, still using java. We are using SQL, but managed CloudSQL databases from google. We are also moving to more asynchronous programming using events with google PubSub.

The developers are now responsible for setting up their databases using terraform, aiming for more DevOps. We used to throw things over the fence, but now the developers create their own infrastructure instead of relying on other teams. They create their own metrics and alerts and have a lot better insight and overview of their applications.

To me, as a java developer, I think it has grown more interesting, and I feel like I am in more control of my environment. The majority of development is still in java, the business logic is in the java. That won't go away.

I'm not sure if my comment is helpful, but I actually like the direction where we are going. Maybe you can try to find the nice parts and focus on those?

Direction of JVM, Java and the other guest languages (Kotlin and Clojure mostly) is probably the bright spot of tech right now.

I'm sorry to be negative but people who think like you is what I was referring to. I can't relate to your embracing of us being asked suddenly to do a second job that isn't software development. I don't care about the infrastructure from a setup or configuration sense. It's too much for me. Isn't it enough if I actually manage to be a pretty damn good developer? That's not easy. Why isn't that enough, unless you are the company then you'd love to have me doing the job of two people.

I do like where Java is at, that's why I hate AWS. I feel it invalidates the need for Java. Just script to the AWS engine. I could be way off, but I see AWS being what kills Java.

Maybe you're not a darn good developer, if you just want to throw whatever code over the fence. Code isn't just a PR in a vacuum, a closed ticket, another class. A good developer knows how their code runs and behaves in the real world, and cares about it.

Good point. It's maybe hard to see when you yourself aren't very good at something. Even harder when you really like doing it.

The downside of DevOps is that you now have to spend time on something that's not writing code. The upside is that you suddenly have a lot more power. You can add and remove pieces of infrastructure without having to get approval and waiting for some other "sys admin" team.

Cloud providers are very proprietary and specific in nature, which is very off-putting to me personally. Putting some abstraction over it, like terraform, makes it much less specific. It seems less like "wasted niche knowledge".

I have never used MongoDB, just watched it fail spectactularly in other teams. I don't get it. If I know my data structures, relational is obviously the right choice. If not, I won't expect any meaningful document queries either. A simple key/value store should be good, whether that's in my RDMS or something like Redis.

Go is just a fresh Java, without all the cruft. Also dumbed down, which is a bit sad, but on the other hand very quick to move around in. I don't get how anybody can stand all the crazy tooling and configuration and setup around Java, Spring, etc.

You definitely have more power, you're right. With great power comes also great responsibility, which wasn't there before. Example: instead of the experienced DB guy who was checking the logs to tell you exactly which query goes too slow and what you could do on your side to improve it (and do things on his side to scale the DB better), now you must build the knowledge to do all this properly by yourself.

I don't think it has ever been enough to JUST look at the java. You said you were pretty good at SQL, so you must think about the performance of your queries, what indexes you use and such.

You can try to improve your java performance as much as you want, but if your database can't handle the load, then you need to look at the database. In my opinion it is NOT enough to look at just the code, you need to look at all of the parts of the system.

Just declaring that you want a database instance in code, using something like terraform should not be an overwhelming thing. Most of the management would be handled by the cloud vendor, you would just need to make sure that it has enough cpu/ram for example. There are probably even easier products where you just store data with some kind of API and you don't even need to bother with the performance of the data store.

But if you just want to write your java code and not care about anything else... Then yeah, maybe the direction of the industry is not aligning with the direction you want to go.

I love relational databases. I think they are among the greatest products to come out of the entierty of computer science, ever. You're right, I do care about application performance and index tuning and query optimization. But it would make no sense to ask me to be a DBA.

What would the role of the DBA be if you are the one creating tables, tuning indexes and optimizing your queries?

I thought about how to reply to this, but database roles vary so differently from company to company, it's a bit of a rabbit hole to go down. Whether you call what I described being a DBA or not, I don't think it's reasonable that a software developer would now "own" the database and all that entails. It just so happens that the database fits nicely into being "owned" and managed in AWS. And it also may neatly obviate the need for the DBA role. Although, I think that's debatable too.

Yeah developers are now responsible for things formerly taken care by professionals in their area. The memory space i could use for better learning my framework is now used to store K8 tricks. The time I could use to fix some user reported bugs is now used to figure out Elasticsearch query parameters so it works properly over shards. No really, I can't imagine why this is such a good thing, diluting the programmer/dba/devops skills.

I don't see how your example of querying elasticsearch has anything to do with the above. I do agree that it requires the developer to at least understand the basic concepts of kubernetes, if you are running your application in kubernetes.

I rather like to think of it that certain things that was handled by other professionals are now managed or automated with cloud technology. Take Google PubSub for example, a message bus with pretty much zero operational overhead. You simply create your topic and subscriptions and it just works. Compare that to running and maintaining a system like Redis or Kafka on your on-premise hardware.

As a developer you still need to understand the interfaces of the products you are working with, regardless if it is a database, a messagebus, a REST api or kubernetes.

Ok here's the short version: as a programmer I'm also now responsible for maintaining and upgrading all that environment around my program. Which I wasn't before, a time when understanding its interfaces was enough. Can this be denied?

For managed products, upgrades are often automatic and there is almost no maintenance that needs to be done. At least that is my impression when running stuff in GCP. For example:

* CloudSQL Postgres, automatic minor/patch upgrades, they working on seamless major upgrades. Automatic disk increase. You would only need to make sure that you have enough resources in terms of CPU/Memory. * PubSub, no maintenance or updates required.

It is more work to keep java and the related dependencies up to date. We use renovatebot to help us automate things like that.

In my experience it is very easy to change and setup the managed products, I declare them in code using terraform and then I don't have to do much at all. This is what is so awesome with the cloud managed products.

If you are trying to be cloud agnostic, then you are just treating the cloud as another datacenter, and then you don't really get any of the benefits of using cloud specific managed products. Then you need a professional to keep maintaining your infrastructure.

Agreed same shit at my work. We have a maintenance problem but the other devs are wanting to solve a scaling problem that we don't have and are unlikely to have in the foreseeable future. Talk of microsevices and one database per service, which will only complicate things and put a load of unreliable network call into our already buggy system. Dev environments that take forever to set up and are incredibly fragile.

You're not alone in this feeling. I left the industry because of the "trendiness" or "shiny object syndrome". Then put on top of that the change from serving people to spying on people and that was all for me.

It's happening everywhere, not just computing. E.g. there was a thread about the decline of the quality of dental care a few days ago:

https://news.ycombinator.com/item?id=31790226

Greed is taking over.

It’s not about the decline in the quality of dental care. It’s about dishonesty. There’s no implication that things were better before and people used to be honest. Things weren’t better before. We just know they suck now.

I agree with the other post here, sounds like you need to find a new job. The cloud isn't your enemy; it's just a bunch of machines. The decisions that are being made at your present gig are orthogonal to the fact that it's in the cloud.

However I would add that sticking to one technology stack for your whole career is probably just not possible in today's environment. There's still plenty of places that are using Java, but they won't be the cutting-edge startups. Frankly, you may not want to work at a startup anyway, the pay is lousy, the equity is usually worthless, and job security is low.

I encourage you to methodically look at your skills, which Industries and segments they're valuable in, and what you need to learn going forward depending on which segment you end up focusing on.

(un)fortunately, even the Java shops do have to follow Java trends - let's not forget the Java world is quite a big world with many islands. Example: I develop lambdas in Java. It's just those trends are less seasonal than other (Javascript?) trends, maybe also because they aren't usually startups but rather enterprises.

Software tends to get thrown away after a few years. Nothing I've written as a professional programmer has survived the test of time. No regrets, though. Why would I carry the burden of self importance to even be bothered about this? Do we really need to cast our work in stone? It's just work and you probably got paid a bunch. Nothing wrong with that.

My advice would be to find whatever motivates you in your life. What makes you happy? Challenge yourself and everything you've got.

To be fair he is coding Java. He has literally been chilling in an ecosystem that has not only stood the test of time but is seeing a big resurgence... Unless you count J2EE falling by the wayside or SOAP not being hot anymore most of Java has just seen steady improvement rather than replacement for the last ~10+ years.

This is just the nature of the tech industry. This board openly celebrates "disruption," "move fast break things," etc. If you work in tech, expect to constantly be updating your skills and learning/adapting to changes.

As a frontend dev, I can tell you that at my last company we started to circumvent/replace the backend team because they insisted on using things like Java for simple CRUD apps. I write TS, so to write a REST API that reads from a DB and serves to a frontend is trivial to set up (including tests, security, etc). A business customer needs a dashboard by next week that combines five different sources of data into something intelligible? - that will take a day or two. Asking the legacy backend team for the same thing (a backend API to serve this data to my frontend) - "we'll put it on our roadmap - six months." And that's not even the worst - they absolutely refuse to create any kind of internal deployment to host our already-built solution. It MUST be in Java and conform to their standards. Of course we're going to change the stack, these teams are blocking meaningful work because they refuse to move faster or use tools which allow us to move faster.

Do you think those teams are blocking you just for fun? Or is it possible that they actually know a lot of things that you don’t, and all of that “wasted time” is actually being used to provide safety, security, and proper architecture for apps?

THIS is the problem in tech. Every hotshot programmer thinks they know better than everyone else; that nobody else brings value to a company except the developers.

Nope, not for fun. Rather, they come from enterprise backgrounds where everything moves at a snail's pace and their methods - which they refuse to update - are wholly unsuited to a fast-moving company.

> Or is it possible that they actually know a lot of things that you don’t, and all of that “wasted time” is actually being used to provide safety, security, and proper architecture for apps?

I handle safety/security and architecture and have been for over a decade. I know what I'm doing. I would expect that any mid-large tech company in 2022 would have a way of quickly spinning up new, basic CRUD apps - if you have to write a REST API in Java from scratch over the course of two quarters every time someone needs to deploy an internal dashboard, you're doing it wrong.

> "wasted time"

Your words, not mine.

The problem in tech is a bunch of grumpy sysadmin types gatekeeping the stack and preventing people who are trying to solve business problems from doing so. Then when we introduce new technology to actually enable us to solve these problems, "oh this is a fad, I hate this language, why can't we keep things the way they were." Because you refuse to adapt, and we have stakeholders/paying customers who expect results.

Java has nothing to do with what you described. Its modern frameworks are extremely productive and performant. Just because you might have had a bad experience with one team that moves slowly (who may very well have their reasons), does not mean that the language or ecosystem caused them to be that way.

I can write a Spring Boot app from zero to a fully functional API interface to the database in one day. Really less time, but that includes unit and integration testing. The front end that will consume that API is another matter so I won't pretend I could do that. Obviously getting this to production won't happen in a day or two. Are you saying the nature of Java itself makes this impossible, and something about Typescript makes it doable? The thing is, a REST API is a solved problem. If you let me use what I know, it'll get done quite fast. If I believed you and went all in on your stack, will you be happy then? Can I master it and feel some kind of self worth in what I do for a living, or will it all be thrown out the window when the next Typescript comes along?

The business customer wants the dashboard now. Today. If they could push a button and have it, they would. I assume "I want it now" sounds unreasonable to you. So why does "I want it next week" not sound unreasonable? If you can do it by next week in Typescript, you can stay up an extra hour or two every night and have it in three days. I'm guessing you draw the line somewhere.

You're right, this has nothing to do with Java. Spring Boot and other modern Java stacks are quite great and very productive actually, as you already know quite well.

> I want tools that won't change every 5 years.

I know this is an unpopular opinion with high-level developers, but if you want stability, go down the stack.

I, for one, write firmware, kernel modules, etc. for embedded, in C. And C barely changes. I know there are a lot of opinions about this (new "ISO standards", etc.), but for the day-to-day operation I survive with what I learned 20 years ago plus some little "updates".

You are at the base of everything and every little change you make has a very high impact on upper layers (someone add a exploits comment here).

I see the same feeling you have in my fellow app developers. One day is Java, or Xamarin, or...

"But, @scoutt, you surely work with 'old' stuff". Not necessarily. Today I'm working with a new 5G Android SoC.

Go to the root, go low level: C, C++ (modern C++ is not my taste, but very valid), or maybe Rust in the future; everything is more stable down here.

What's the market like for embedded engineers working on cutting-edge hardware?

Is asm still relevant as an employable skill?

How much of your work requires heavy EE knowledge?

Assuming that you're at Qualcomm/Samsung/Mediatek, do you do any microcoding or is that handled by other teams?

> What's the market like for embedded engineers working on cutting-edge hardware?

Where I work we are always looking for engineers. We struggle to fill positions. And other local companies are facing this very same problem. There is high demand and little supply. Universities here are all focused on theory and most fresh EE don't know how to blink an LED with passive components. Just a few wrote some lines of code or actually produced a PCB.

We have some "cutting-edge" applications, and we have to maintain/update old projects too. You never get bored.

> Is asm still relevant as an employable skill?

It's a plus. I rarely write/maintain asm (like at least for the last couple of years).

> How much of your work requires heavy EE knowledge?

Not much. I mainly code, but I have to know the basics, like being able to use an oscilloscope to find a noisy power supply or a missing pull-up giving me headaches, know how communication busses work, reading datasheets, etc.

> Assuming that you're at Qualcomm/Samsung/Mediatek

I work at a mid-size automotive company in Italy.

There is a big movement starting in the Linux project to get kernel modules written in Rust now.

Probably for some sub-system. None of the suppliers for the peripherals we use (and HW in general) are giving modules written in Rust. Just C.

Consider that for some kind of project, kernels are fixed at a certain version. Producing just Rust modules for new kernels leaves behind a lot (if not all) projects done so far. So if a HW manufacturer has to choose to write and support a driver module then I guess it will still be C, for at least the following decade (maybe?). Unless there is an effort to backport Rust infrastructure for older kernels.

As an old Java / SpringBoot developer doing manual work full-time since a few months, I can relate pretty much to this experience.

I think the root cause of your troubles is lack of involvement in the business you are working for. Try switching for a lower-paid PHP development job. These are often closer to business. Sign up with a freelance platform and take on short down-to-earth projects. If nothing helps, pick up a parcel delivery job for a while. Go volunteer for Ukrainian refugees.

In any case, be ready to cut your revenue by half before you start feeling better.

P.S. I did all of the above and more. Still recovering.

P.P.S. The ultimate solution for your would be to open a business. I tried that as well, but mine failed, dragging a few years of my life with it.

As someone adjacent to software but not really a dev in that sense, it's stuff like this I rant about all day here and (unforunately) to my friends and family is how devs can't just embrace things that work but have to reinvent everything every couple of years and how that attitude makes life worse for everyone, both users and those downstream from software like me.

I don't know how to fix it because it seems like an industry wide problem, a very deep cultural problem that absent some outside force will not change. Just as a note, the curse was called "CADT" by jwz back in the late 90s to early 2000s so it's been a part of the industry for a while and likely won't dissipate any time soon.

I wonder if the problem is that so many of my generation, including myself (I'm in my early 40s), learned programming as kids because it was fun, and we (including myself) never fully outgrew that childish mentality. Maybe the industry would be better off if more programmers were like my uncle who learned programming in college as a job to make a living, and treated it as such, and nothing more.

If not there at the very least should be a balance, where code can be "fun" and you can have all the innovation you want while at the end of the day, tried, true, and boring solutions don't get thrown out for no real reason.

As a code developer, there is no reason to not keep coding. You don't have to deal with infra or packaging/deployment. It sounds like bad management on your company's part. In the few large companies I've worked at, software architects, programmers and DevOps were responsible for the different parts of what you mentioned. The architect designs and directs the "engineers" (software/DevOps). For example, "Java guys, please read all config from env vars", as part of good microservice design. Naturally, the service implementation itself should be part of a larger whole; most likely multiple small microservices. And you, the coder, just follow the design. DevOps take care of infra, ci and cd according to the same design. Overlapping domains are discussed and brainstormed.

Having said that, you are wrong in thinking you can learn something that'll last more than 5 years. It's possible but the field isn't about doing the same thing for a long period of time. The job description is better put as "quick learning capability". Which you said yourself; you need to adapt as time goes on. That doesn't necessarily mean AWS. It means Java WebFlux, in your case. AWS and k8s are, each, huge huge topics. They can each employ a team. You shouldn't dive deep into it unless you want to change career paths. AWS to become a cloud architect or k8s to become whatever-cool-name-that-hat-has. You can't be top gun Java dev and cloud architect. It's too much. Select few gurus could exist that excelt in both. But it's simply too much information to keep up with and not a realistic job description/requirement.

Bottom line is you need to continue to adapt in your field of choice (Java or AWS or k8s) and turn your critical eye to your own company. Something there sounds off. The DevOps guy should be the one to tell you lambdas can be written in Java. And the vprnd should be the one to choose Java, seeing as most of the company already knows Java. The architect can give you guidelines how to design your implementation to be compatible to cloud architecture. And you can just learn a few basics about AWS lambdas to be able to debug.

Anyway, sounds like a midlife crisis. Hang in there. I got myself a sports car.

> As a code developer ... You don't have to deal with infra or packaging/deployment

This is false (and wrong). As a software engineer, you must understand and own what you do end-to-end, including:

* how to write your code

* software/hardware that your code relies on (databases, k8s, aws, whatever)

* protocols your software uses for communication

* 3rd party libraries that your software depends on

* how to build and deploy your software and environment for it (bare metal, clouds, mobile app stores - whatever necessary)

* setup testing + write tests for all of the above

* setup monitoring + monitor all of the above

at any company, at any scale.

I can tell you I'm far less productive as a developer when I have to waste hours figuring out errors to do with AWS cloudformation or various managed service issues, or play/app store certificate expiring or what not. I have the necessary analytical skills to figure out stuff as I need to, but it's far more efficient to let others who are used to dealing with it all the time and seem (perversely) to enjoy what I would admittedly consider the unsexy part of maintaining software and ensuring its availability to customers. I'd even argue it requires (esp. for operating production systems) a different sort of mindset. Sounds ultimately like a debate about where the boundaries of specialisation should be. Some programmers are happy (and very productive) being extraordinarily specialised (knowing only a single language and working only on very particular components), others are used to wearing a very wide variety of hats, that even includes people and project management. I'd probably consider myself somewhere in the middle, but recently I've been painfully aware of spreading myself too thin trying to handle both feature development, CI/CD maintenance and DevOps-related tasks ensuring our cloud-based environments are deployed to and operate smoothly. On top of various other tech-lead/staff-engineer type responsibilities of course.

How can you write code if you don't know where and how it would be running? For me it's extremely uncomfortable to know that there are "they" who will do the "unsexy" "dirty" work to make _my_ code run.

> I've been painfully aware of spreading myself too thin trying to handle both feature development, CI/CD maintenance and DevOps-related tasks ensuring our cloud-based environments are deployed to and operate smoothly.

Reduce complexity.

I never said I don't know where and how it would be running - I just don't feel the need to spend time dealing with that layer of things most of the time.

As for reducing complexity, what are you suggesting exactly? Most of the actual complexity I have to deal with is in our codebase to build the core application (which can run almost anywhere), which is independent of any issues with CI/CD and DevOps/cloud deployment. They're not complex, they're just frustrating.

Thanks for this post, I'll be rereading it, may even point this to some guys I work with. I appreciate it.

> Anyway, sounds like a midlife crisis. Hang in there. I got myself a sports car.

Getting an EV sports car is like being a kid again. But you can still commute in it. How great is that!

No advice, I feel the same. The industry has gone to shit and it's crossed the point of no return. The only real innovation has been with AI. Everything else is an endless reinvention of the wheel. Most of the skills I've learned are equivalent to underwater basket weaving. OOP was supposed to manage complexity but it actually creates more complexity. Imagine going back to the 70s and talking to a developer learning C and Scheme. How depressing to tell them no improvements will be made over the next 50 years and languages will actually get much worse.

I don't agree languages have got worse, it's much easier to build anything today than in the 70s, not just because of tooling and libraries, but the languages themselves are just easier and help build structure.

What makes development 'worse' today I think, is much more of it is just integrating with myriad other systems, tools, etc, which can be dull and frustrating, and I'm sure no-code will just make it much worse.

And then there's scrum.

It's not easier to build anything. It's easier to build web applications and video games but we already have way too many of those. If you're doing something innovative you will find things have indeed gone backwards in a fundamental way.

How can this be true? You still have the option of installing a K&R C compiler or whatever.

What has changed is that the complexity required of software has vastly increased. And perhaps there's an argument that the tools and languages have not kept up.

But try developing anything today with an old version of any language or tools, and it's not better, else obviously that's what everyone would do.

People choose what language they learn based on what jobs are available. Companies choose what language they use based on what FAANG companies use. What you're saying is not obvious, it is a naive assumption. Popular does not equal good. If that's what you think you can go ahead and explain why Java is superior to C++. I don't think you even know why it rose to prominence.

I have felt and feel a lot of what you are saying. Realizations I've made:

1) Constant change is a huge part of the software industry - we have to accept it, or become a craftsman focused on potentially moribund tech, or get out (and do construction or become a career less prone to change). I'm in favor of the latter two as I don't want to constantly be learning new tech that I don't like.

2) Not all new tech is good. So much of tech is the result young kids re-writing a solution that already exists. A lot of the times the new solution is worse or not any better than what exists. Occasionally it's better - but I think that's rare. I see it as a law of nature - the kids want ownership and maybe they're right that something about the old way of doing things is bad or cumbersome - thus new tech is born (even if not terribly better than what had existed).

3) AWS has been around forever - my company has been using it for over a decade now, so I don't think of it as novel or new. Yes, it's a pain in the arse in some ways, yes it's clunky, yes IAM sucks to configure - but it does have its advantages - scaling/replicatability. I suggest making friends with it, OR committing to not 'doing devops' or being 'full-stack' and being OK with that. It's not going away!

Most important message: - focus on tech you enjoy (however narrow or broad) - because that's what will keep you passionate - and most likely will lead you to being good at it (and thus employable).

I agree that things started changing some years ago, but I'm on the other side of the boat.

I love serverless and typescript (but still prefer sql over nosql for most use-cases). It's just so easy to setup a cdk cloudformation stack with a few lambdas that run basic CRUD stuff behind an api gateway, no messing around with JVM tuning, server maintenance, SOLID and a 1000s of other patterns when using basic functional programming. It'll just work, and when it doesn't, the solution is usually pretty straightforward (unless aws is down globally), rollback are easy, reading logs is aws native, metric as well, async operation with native resources (sqs, SNS, event bridge, etc) are a breath of fresh air and multi region deployments are just a few configs away infrastructure wise.

It's not all easy mind you, but still a heck of a lot more accessible from what of remember back in the day.

Despite all that, I can imagine this all going away in 10 years and leaving me desperate for life because that's all I know. I feel it even now, all I know is nodejs and serverless. A few days ago I spent a whole weekend just to deploy some containers onto an EC2 instance, didn't even add any waf or any type of bot protection on top of it, just basic infra and server setup with ansible, two whole days on it. I can only imagine what will happen to me when the industry moves to the next big thing after the cloud. Hopefully I'll still have the mindset to relearn everything and the courage to completely rewrite my brain with new tech.

This probably didn't help you much, but either way, best of luck to you.

It helps to know you feel similarly even while you're on that same tech that I fear. Thank you!

Good to know!

Ok. As a fellow Java fan I think you need to stop painting everything new with such a broad brush, that is a recipe for depression.

Sure there is lots of rubbish out there.

You probably shouldn't touch Lambda with a 40-ft pole, Go is mostly just C v2, Node.js will make you question the life choices that led you to using a jank scripting language on a server. MongoDB don't even, just no.

However not everything in the last ~10 years is useless. AWS EC2 and S3 are awesome services. k8s is actually good, assuming you have competent administrators (otherwise stick to GKE, or EKS if don't have ability to go to GCP).

There is nothing wrong with building a modern Java app on k8s and PostgreSQL. You might even come to like the standard runtime environment that k8s provides. It integrates fairly nicely into the Spring way of doing things. You can also do containers in Java better than pretty much any other language, take a look at Google's jib tool.

I think k8s (or something like it) is here to stay because it transitions to the runtime to be declarative. i.e it's the SQL to the Mongo-like (not entirely true but close enough) in the infra world.

Cheer up mate. You will find places/people that respect your knowledge and aren't rushing to upend good solid boring tech for no reason.

I work at a very popular company (which is a great one to work for) but the stack is pretty old, and eve worse, they are pretty old fashioned in everything tech-wise. Any kind of modernization or major improvement is usually faced with a lot of friction.

I think your problem is more or less the opposite of this, but still seems like the underlying problem is the same.

First, I think if that trend you mention is a real thing, there are a lot companies that are not changing "that fast". And probably if you've been around for 40 years, you'll need a job for the next 20 at most, why care where the industry will be in 100 years from now? It won't affect you for sure. Find a company still doing things in a more traditional way, and enjoy life. There's plenty of them, and they're not going away before we go away.

Then, coming back to my own situation, I disagree with a lot of things we do at work....but I usually just mention it when I see them, and propose how to do it in a better way...most of the times I face a lot of resistance... So I say to myself: that's fine...I saw a problem , I propose an improvement, they want the same old ways and not fixing it. Fine, I'll do it this way even if it takes 3X to do it and will run worse and cause troubles. No problem, go for it (imagine in your situation being forced to use mongo).

And then I have my side projects, where I do everything as I think it should be done. That's my way to not go rusty in the "good practices" and building them in an open source way is also a way to show other future employers how I really like to do things, if you give me freedom to improve stuff. If not: all good, I'll do it your way...as long as you do the OnCall and not me, I'm fine, you're the boss..

Hope it helps.

I think you are right w/regards to "reinvention of wheels". We're doing the same things, in slightly new jackets, not always, hell, not often for the right reasons.

What I do want to point out is that this has been a property of computing almost since its inception. We started out with a bunch of hyper-proprietary, non-compatible, no-operating-system-even, write-machine-code-directly systems, followed by a proliferation of assembler languages. Then a huge amount of languages (algol, fortran, lisps, schemes, modula, rpg, b, c, ,d! haskell! it goes on), lots of conceptual aspects (oo, functional, logical, imperative, etc).

My point is, the waters never have been calm. You maybe got in when Java was becoming a defacto standard (I think it is today actually) but as you're in the water a while longer, having grown experience, you're seeing the enormous floods of change/innovation/ideas/chaos, still flowing along.

It is not efficient, it is chaotic.. but maybe it is also organical? evolutionary? messy? I would encourage you to embrace it. It's an inherent property of our field, maybe more generally speaking of a lot of other things in our reality too.

This is how I'd like to be, but my personality or my nature constantly fights it. It doesn't want to go with the flow, it wants to push back.

I's very funny: i can not proprer explain my similar feeling to you because all major translator services are down right now (due to cloudflare)...

so, yeah, like you i hate everything we do because we are not truly doing anything "new" (plus no research, no optimization and enormous -near absolute- wasting of space and bandwidth) and everything is layer of shiny bloat over bloat

I don't have answers but you are not alone, OP

you are not alone. 1973 Ivan Illich wrote 'Tools for Conviviality'[1], 1995 Niklaus Wirth 'A Plea for Lean Software'[2] just to name two.

As to the industry, it has to stop before it eats up the planet. All it knows is exponential growth ever since (Moore's law underpinning all decisions) and eating up all resources (energy in the end). It tries to replace reality with virtuality, it's own mock of the former where it plays puppet master. It may not stop by itself but crash. Take care to not overly depend on it. The idea of permacomputing or the 'Low Tech Magazine'[3] may lead forward individually. Not for the industry, however.

[1] https://en.wikipedia.org/wiki/Tools_for_Conviviality [2] https://cr.yp.to/bib/1995/wirth.pdf [3] https://solar.lowtechmagazine.com/

Although computer science is not software engineering, the theory underlying design and analysis of algorithms will outlive any specific programming language that implements them.

Perhaps it would be good to get more into the theory of the algorithms rather than specific implementations.

It is why computer science undergrad education does not emphasise programming as much as the theory, in 50 years the theory will stay.

So, yeah, your right.

You are now asking about the bigger picture, which means you've mastered your area and you see that it's just a big wheel. Pick another area and master that too. Learn Clojure along with Java to expand your knowledge into functional programming. Nothing you ever learn will be for nothing if you try to see the bigger picture in the small things. Those that only solve real problems will throw out (and they are probably correct to do so), code and solutions that are no longer economically viable or that free up mind space for employees. Some choices are plain stupid, but as we all know there's a lot of really bad management around, but that's a management problem, not a software engineering problem. Plenty people hit brick walls trying to solve that problem with the wrong expertise or mind set. Keep your spirit up! There are plenty fun problems to solve still though!

My wife actually put it quite well. I was referring to the idea to open a flower shop instead of working with computers, because, working with computers all day pretty soul crushing. She said that the world is focusing on depending on software and internet now. At the same time as that space expands, the 1% of people of have the slightest chance to actually understand how it works, are still 1%. We need you to keep the world running. There are people that don't have the opportunity, time or mind to understand it, but their whole life is still dependent on the fact that it works. You've managed to understand it, keep it up, for all of us. Keep mastering your tools, in the end it might be a dauntless task, and your SO keeps bashing at you for making everything so HARD. But yeah, most things are complex and takes a lot of time to really get a good grip about.

Also, there's the whole debacle that we are just dipping our toes into what will eventually become the solutions in the next generation. We will turn this giant wheel for a while until when you write software that is not just server-less, but maybe even code-less. No CPU existing today solves the problem in a good way, this is also about to change. On that kind of scale our journey as software engineers has just begun. But all is good, because there will be plenty work for a long time ahead... Until things are even more complex to understand, and the next iteration is starting.

All in all I want to thank you for making an effort in making the world a better place. You're expertise and will to solve things is greatly appreciated. Go back to sleep :)

I embrace AWS for business usage but I don't like the cloud either and I will yell at it too. I think it is a bad long term business strategy for that matter, similar to what was done with outsourcing IT. You pay much more for IT today and you have no way to retain knowledge of specialized systems. But now IT workers don't want to go back because they make more as consultants now. No more getting yelled at by employees that are frustrated with software, they are highly valued and expensive professionals. Pay for my meal if you want to get your problems solved and I do take the lobster, thank you very much.

AWS isn't all bad, it certainly has usages and some services are reliable and do what they promise. But in general software degrades from professional applications to candy crush lego apps without significant value. I wouldn't think too much about lambdas or typescript. These are useful for applications that actually use cloud services. Voice assistants, mapping services, some parts of the security infrastructure... But for anything relating to business logic they are usually a maintenance hell that also makes you dependent on the service provider. More than three lines of code in such a function is a mess, it is good to quickly adapt data to make it compatible with some arcane interface.

In the end you cannot replace applications with some magic serverless architecture. It is just a virtual systems for running a few lines of code. Can be practical but it is certainly no revolution and there are alternatives. Look at ActiveMQ for example. It is a far more solid solution than any serverless function for 99% of use cases. It isn't as hyped or popular like its streaming brother kafka, but certainly used very often. It can easily blow anything serverless out of the water for professional information exchange. Given, there is no guarantee that the best tech wins. So it is important to be critical of consultants trying to sell you expensive cloud services that look easy at first.

I think you're correct to recognise obvious problems like mongodb and yaml etc

In your time you would have seen more reliable solutions to the same problems

The reality is that good teams can make good products and codebases with a bad stack, yes certainly hampered but still good

It's ignorant to think your point of view should be the only one of merit, in a team you have to consider the developers who want to use mongodb

As the senior on the team you should be on board with your team and try your best to steer your team away from foot guns

I don't think it's enough to say X is bad without having used X long enough to really know how and when things will break down

Otherwise you might just be labelled the grumpy old man on your team who hates everything, your team need to trust your opinions based on genuine experience

Based on what you've written so far I would not respect your opinion on much outside of Java

My advise is that you need to earn the trust and respect of your team when it comes to talking about new tech

Companies switching to cloud? It makes sense why they do it - that layer of problems was solved for you, and solved well enough. Your company should focus on what it does best, theres surely tons of other challenges in the interesting parts of your stack, the ones you cant just grab off the shelf. There is plenty of fun to be had there.

Take some perspective, what you are saying is "Where I started was the good place". Ask 60 year olds and they will tell you C++ is where we should have stopped.

There is a reason you will have a very hard time to find those 60 year olds to ask about their perspective, it is because the common wisdom about how hard it is to keep being an engineer as you age is actually true.

Saying "I'll do it in the future" is easy, the realities of having to keep up with technological progress for ever and ever and ever and ever ad nauseam are catching up to you.

Software engineers are the construction workers of the software world and in both professions you rarely see old people for similar reasons, it can be done, but very few people survive. So if you already getting sick of it, I would either start thinking about when to switch roles to product/sales/cs/management or about saving very aggressively for early retirement :)

Good luck!

Hey can we at least say construction workers are still using hammers and they don't jump on the noHammer fad or other nonsense :)

I feel you, but the cycle will continue. We have been using terminals (centralized computing) before, then switched to PCs and back to cloud. If you can wait about two to three decades its gonna fix itself :)

My friend, in my opinion "cloud" is a temporary trend, soon enough whole AWS/Google Cloud will fit into your pocket because of Moore's law and miniaturization of computers. Cloud is a money pomp and it's managed by admins and marketing people mainly, not by real computer scientists which conduct research and draw conclusions from the history.

I can recommend you to watch YouTube videos and watch people like Alan Kay (watch all the videos), Hal Abelson, Jerry Sussman and others pioneers of our industry. You should quickly notice that what we have now is a local maximum of some trends and much much more is waiting to be (re)discovered.

Hint: AWS and K8s are poor attempts to create real Object Oriented system. There will be much more like them in the future, but of a higher quality and based on some real rules, not accidental connections with HTTP messages.

> Moore's law and miniaturization of computers

But isn't that slowing down?

Yes, until there is a breakthrough and the game starts overs.

I think you got lucky with Java and were able to stay doing similar stuff for a long period of time. This is constantly happening in every part of software and has been for for 50 years or more. I "got lucky" with Oracle development and have pretty much done that since 1998, but I've also done a bunch of SQL Server, Java, .net and web and mobile stuff as well as cloud. I've also got learning fatigue and so I'm more on the business and architecture side building solutions at a higher level in large companies. It's frustrating sometimes, as I sometimes think it would be faster to do it myself but I don't have to learn the details of everything anymore and may be able to sustain that a little longer. I still read code most days and do bits of sql and scripting. I'm a little older than you too. You are not alone.

I think this is basically right. I'm not a FAANG level developer. I'd like to at least say I'm average and sometimes good. Mostly because I like programming and tend to care about doing a good job. But I got lucky to come along when I did. The point of my post is that I feel like I've made a mistake it may be too late to recover from. I feel a bit too old to start over in another career.

> The worst thing is, developers are embracing this AWS trend and seem to love it. No one seems to mind. Software engineers are cursed. Just when we've established a best practice and it's a solved problem, we throw it out and reinvent a new way to do it.

I don't think AWS is a particularly loved ecosystem, it's just a well bundled set of tools.

On the other hand cloud architects or whatever are like a modern day Pied Piper with so-called visionaries following them and burning money until their business runs out of runway. Once they realize they should have spent way their resources on diversifying their partnerships and creating a non shitty product instead of investing a gazillion on splitting a smelly monolith into 13 smelly parts, it is often too late.

Have a plan B at all times and you'll be able to sleep well.

I feel you. I hate this field these days. The churn is largely unnecessary, but comes from people cargo culting what they see coming from a handful of super successful companies that aren’t at all representative of what most development is. Add to it the glut of web developers that are generally disinterested in actually learning how systems work and insist on unbelievably deep and fragile layers of crap to insulate them from thinking while they glue programs together as fast as possible. I wouldn’t say the field of software engineering is cursed, but we do have a signal to noise ratio problem if you follow sites like this one. I recommend my approach: avoid this site as much as you can, and avoid the comments when you can’t resist visiting.

I'm very much in the same boat. I'm in my mid-30s. Been doing Java for 10 years. I'm finally catching my stride and feeling like I'm really mastering it and suddenly we're building services with Typescript because we didn't learn from Perl that spinning off an entire process for "parallelization" wasn't a good idea. In a similar vein, we used to just deploy Spring to EC2 and it was rock-solid...now we spend more time managing k8n and explaining Lambda cold-starts than actually building software.

That said, we sound more like old fogey complaining about modern cars being "all digital" while our 1980 Ford Ranger is still kicking. (pardon the analogy, it doesn't scale and EVERYTHING needs to scale now right?)

The cloud's just hosting through. You can still built with Java and it's still in the top 3 languages for a reason and in HIGH demand.

All we have now is more options...and yes, less experienced folks are going to not always pick the best option. A teenager wants the car on the showroom floor; an adult knows you buy a late-model sedan or pickup. (Hey, this analogy is working.)

Your career wisdom is aligned. While I don't think AWS will go away in 30 years, it will evolve. Picking what to master (Java or Kubernetes) will always be a judgement call. I'd say you're right that Java is a good call and Kubernetes is a bad thing to "master" (the latter will and has already been abstracted away with things like Fargate).

But some things are really awesome. Have you tried out Elastic Beanstalk? It's SO easy to go from start.spring.io -> Elastic Beanstalk -> a real working, hosted, and scaled public web service in like 1 hour.

With wisdom comes the knowledge to distinguish the "fads" and the "future." There was a time when Java was "too slow" and applets were everywhere. Even Java had its fads.

Honestly, I'm very hopeful for the future of Java. With Project Loom and GraalVM, we'll be able to better compete with Go (with virtual threads) and TypeScript (with native startup times).

The most important lesson I ever learned, and it was due to the biggest mistakes of my life:

Don't expect that what you are suffering from today to be constant forever. Essentially, "This too shall pass". All things ebb and flow.

I was lucky, in a sense, to be bitten by this rather earlier than late. But it's relevant here just as much. So while you aren't wrong in fact, you're wrong temporally, and in degree. Man, there's COBOL programmers still making more than decent bread to this day.

Technology stacks change over time. Problem solving techniques don't.

Take a deep breath, continue to focus on what you are good at, and don't worry. What you think is a 5 year horizon is more likely 50 years, and so on.

We all know technology constantly changes and progresses, and I've always thought that's fine...I want tools that won't change every 5 years

Look dude, I've been doing this for 40 years - yeah, since you've been in diapers! It's always been this way. You can't say I love change! Bring on the change! and then when it happens be all like, wait! that's not the change I thought would happen!

The change that happens is never the change you thought would happen! That's the first thing everyone here had better understand when considering this industry for the long haul. Change is going to happen and it's not going to be the change you expected. A lot of times it's going to be the same "stuff" in new packaging.

Having said all that, I started my career building real-time kernel extensions. Now I'm managing a company's transition to AWS. Yes, AWS. Lambda functions, RDS, SQS, S3, Lex - it's all server less. We're not using Typescript though, have no idea why you guys thought that would be a good idea unless you're building Node.js apps. We use Python. So yeah, I've moved from x86 assembly (the first 4-5 years of my career!) to C, to C++, to Java, back to C++, back to Java, to C#, back to Java again but now with some JavaScript, and now to Python. Looks like I need to do some work in K8S using Go for my upcoming project. That doesn't even include all the languages I've used for side projects such as Lisp, Clojure, Scheme, Haskell, and a teensy bit of Rust.

Honestly though, compared to where I started 40 years ago where we are today is awesome! Basic gave way to Python, C gave way to Go/Rust, and C++ - well we learned a lot of anti-patterns from C++, didn't we?! :)

Add in AWS and now I'm able to deliver solutions that were practically inconceivable just five years ago - and I can deliver those solutions in a handful of sprints! Who gives a rat's behind if it's here in 10, 15, or 20 years? I've seen software that's 15-20 years old and nobody wants to touch that stuff, let alone make any enhancements. My 40 years of experience has taught me trying to envision anything beyond 5 years is a fool's errand.

Maybe you're having a midlife crises and are now realizing everything you've ever made is destined to be tossed aside and forgotten. Even the human race is going to be extinct one day and the Earth is going to be subsumed into the Sun. Who cares? Doesn't mean I can't have fun under that sun today!

You're not alone.

I'm 36 and am experiencing the same syndrome of buying power tools and wanting to become a carpenter so that I can "log out" and make something real and so that I can achieve physical tiredness from working.

Switching away from software, for me, would mean a big impact on salary, and that has always kept me from learning something new to a degree that is profitable.

If you want to learn to build things, you can do that; go down in time on your full-time developer job and spend time learning how to build physical things, and assess if that's something you could see yourself doing more than 50% of the time. Building real things can pay well, too.

Just because what's popular changes over time it doesn't mean that you have to follow it. I totally dislike most directions tech is going in, serverless, kubernetes as you said and I use mongodb and javascript.

What's popular now is more expensive, takes more effort but also makes a lot of companies more money and therein lies the clue to solving the mystery.

Forget about these tech that you don't care about, in time things will turn around and what was once unpopular will become popular again. That's the way things goes.

IT isn't the only field that has popular culture, everything does more or less.

Hmm.. mongo might be hip or whatever but sql as a whole is not going anywhere. Perhaps some businesses will switch but half the world has already been built on sql, and new things are being built on sql all the time.

My speculation is a Bit more differientiated. The majority of the hype Tech will bei trash while a few will stick. I.e. i think kotlin is an objectively improved Version of Java and will compete against new iterations of Java and might come Out as Superior.

Public Cloud computing by itself will Take over although i hate it too.

But yeah for some reason our industry has a completely ridiculous amount of entropy in Terms of technology which Others crafts doesnt. Maybe because it's still Young. Maybe we have a Set of trusted Tools in 50 years.

That is the curse of experience. In any field, I’d imagine. The trick is to be able to share your experience in a way that it get heard, watch people hit the fall when it is not and then help pick up the pieces without going “told you so”. I cannot do that sustainably and thus do not work in corporate environments. But it is my fault, not theirs, as such is the nature of the beast

Here's a different take. I'm a technological optimist as well as an uncompromising critic. This big-tech cloud nonsense, what I call Mainframe 2.0, will blow over eventually. It always does. Now you're 40 you'll surely agree the only constant in tech is change.

I am also a "Technological Patriot". In other words, I'll fight for what's mine.

Allow me make the point by re-writing what you said in a different voice;

"It's 2 AM and can't sleep. I'm a doctor with 40 years of experience in oncology. I've saved many lives. We all know medicine constantly changes and progresses. Lately I'm feeling depressed at the state of the "industry". Cosmetic surgery, over-prescription of antibiotics and morphine, privatisation of public hospitals...I don;t know what's going on anymore. I've been buying power tools and learning how to use them."

You can walk away. Or you can realise that you are important, valuable and perhaps that you even carry a responsibility to what the industry means to you. What it means to Google, Microsoft, Amazon... that isn't your industry, that's theirs.

Take it back from them. Or just make yours better and let their brittle, ephemeral vision evaporate. Become an activist. That doesn't mean lying in front of a bulldozer. It just means saying what you really think, and not working on projects that make the world a shittier place or hand more power to the powerful. Change doesn't have to be something that happens to you, it can be something you imagine and create. It might also mean spreading the word and helping your fellows understand. Now you are a "senior" engineer people will listen to you.

Have you heard of "cloud repatriation" and "degoogling" and the "on-prem renaissance"?

Post 2013, after Snowden, there was a movement called "IntelExit" - to try to convince people in our intelligence organisations to quit and disrupt recruiting. I thought this was the worst idea ever. The people most likely to leave are those with a conscience, those older and influential, leaving only the worst, pliant and unethical behind.

On the contrary - people in a corrupted industry who are disaffected should be encouraged to stay and fight. One good egg inside enemy lines is worth ten loud voices shouting from the sidelines.

no, you are not alone, I was laid off when the pandemic started, and I got a job doing web dev, I won't go as far as to say I "hated" it, but I didn't like it, I since did a software engineering internship, where I did automation stuff library dev, and went back to finish college, and specifically applied for a job where I won't work in "web stuff"

also, jobs that aren't about doing cloud stuff config do exist, if you really dislike that, you can change jobs (unless you can't? what with financial stability, depending on your situation)

if you're skilled at programming, even if you've only ever used one language, you should be able to program in another, you might not be as skilled as your preferred language, at least initially, but that shouldn't be a problem in the long run

You are just afraid that your java skills will be useless. Instead of panicing and depressing you could save that energy for learning new skills already. And really i dont get that. You know that tech is changing and you still are trying to reject that. Just embrace the change and go with the flow.

Yes, I'm afraid of that. But the tech is changing into something I don't recognize and that I don't like. It's not a change of syntax or type system. If I'm right AWS will replace Java as the enterprise standard. I know that doesn't make much sense on the surface, but I see AWS as a scriptable engine. Just not something I'm excited about. It doesn't look like programming at all. Just product soup configuration.

If AWS is a product soap, Spring Boot is a library soap. This is not fundamentally different.

Are you sure that you are suffering from technological change and not from lack of interest in what problems your code solves?

> But the tech is changing into something I don't recognize and that I don't like.

Get out of your comfort zone then.

I've had the same realization as you and it one of the reasons why I'm heading over to UX. Obviously UX isnt without its industry issues but it is very refreshing to be in a field where the underlying tools don't change every year or so. Plus the people are much nicer.

Stop doing web stuff with databases. CRUD is boring whether or not it’s at scale or a ToDo. Find work where you code something you find interesting/challenging and that isn’t repeating the same patterns over and over.

I kind of accepted and came to terms early on that what we do (most of us?) is basically boring CRUD type stuff. Somehow, I've come to like being able to go into a big, old code base that no one wants to work on and actually learn it and be able to successfully fix a bug or add a feature. Something about it feels like being a plumber or "blue collar" worker of the programmer world. This is probably related to why I like Java, and why I made this post. It feels like a tradeoff I made (only in my mind): "Okay, I'll work on this boring stuff no one wants to do, but at least I'll get to use boring, stable tools that I can become good at and my experience will count for something." This is the lie.

I agree with the sentiment if you are creating things that can only be run in AWS. You're setting yourself up for vendor lock-in. However Kubernetes should be cloud agnostic, make sure you use it that way.

You don't need to marry AWS, there's plenty alternatives out there. I think this is the best you can do because those companies with your help will grow.

Devil's advocate: the "state of the art" tech will always be what's fastest to implementation for high-travel use cases, and that's not a totally bad thing. If you got good at machining or injection molds, would that prevent you from buying a 3d printer? No. You wouldn't stop practicing the other tools after learning the 3d printer either.

Why I pull the devil's advocate here is because I completely feel your sentiment in my bones, but I rationalize it against a stack that's later and in opposition to yours. I began 10 years ago from Objective-C and Ruby on Rails on Heroku. I was slinging early iOS apps and websites like a mofo. My shit was air tight inside and out. Then suddenly everyone wanted Swift. And Node. On AWS. For no fucking reason, they didn't even code. So I kinda took a break and flew planes.

Then a side project app of mine got some public attention and I had to suddenly become an growth eng, data eng, web dev, Chrome Extension dev, and make quick changes to my site and app to have a chance at capturing the traffic that was giving me an opportunity for success. I brought on 2 friends who just got a CS degree but didn't know what git was, and we worked 14 hours a day "squeezing the rock" trying to keep shit on the rails as we got more traffic. Saving time meant we'd allow ourselves out of the house for a moment. By the end, we had a spaghetti trail of Reacts and Reduxes, Swift, Kotlin, Firebase databases and Cloud Functions, Python Notebooks, paying a ton for simple analytics visuals... but we got the job done, and on time, which usually never happens. We've since learned how to write it more affordably to scale the Firebase backend on budget, and it's pretty easy to hire devs to service it.

Now I'll probably never rebuild that tech stack, ever. But on my most recent project where I needed to have a rich web app and mobile apps like ASAP, I StackOverflow'd a bunch of NextJS, Vercel, and React Native stuff. I'm using some CSS thing called Tailwind because it's easier to look up than plain CSS. I jammed that into some other thing called Styled Components so I can just put CSS/HTML in the same file. I'm hair-on-fire productive. I can whip up a fully featured multi-platform app in 72 hours by myself (that's free until a like 100+ users), then spend the next few months iteratively widening bottlenecks. I know this might not work for 100k+ requests/sec (although it definitely does) or legacy businesses, but the point is: if your tech is getting replaced it's because something else has a faster 0-60. Your skillset is still totally necessary for so many applications, but if you want to stick with your tools, you will stick with companies from the time that tech had the fastest iteration speed.

That sounds good, though. Do companies exist that will actually let me master my craft in exchange for maintaining their old code bases and not pull the rug out from under me every few years? Those are the companies I thought I worked at, but even they are susceptible to the trends. Or maybe AWS really is proof that god exists and his name is Jeff Bezos, and literally every application written now needs to be in "The Cloud". It's like one day they just say "Hmm, we have this 20 year old code base. Boring, predictable. Makes us the money. I know what's missing. Some cloud. Hey Java guy, you're a cloud developer now, you already know what that is, right? That's what you do now." Then before I finish thinking that maybe our SQL Server or Postgres in AWS is no big deal, they interrupt "No. MongoDB now. For reasons. It's just better, okay?". "Well, I need to figure out how to get Java to work in Lambda and how Spring Boot fits into the pict..." "No. Typescript, it just makes sense and it's easy, you can pick it up in about an hour." "Wait, what is happening."

MongoDB is "in" again? AFAIK, the best NoSQL DB is actually shoving JSON into PostgresSQL and has been for about the past 8-10 years or so.

I don't know, I work for the kind of companies that have 20 year old Java codebases. In these companies, they are only relatively recently migrating to AWS. They're at different points along this path, but they seem to converge on the same idea to give all their money to Amazon. And if Amazon is selling a product that does something, then they're going to find a way to use it. I mean, the old application still has to keep doing what it's always been doing, just with more cloud, and with some kind of NoSQL database. That part seems especially important. A few more very important buzzwords are terraform, hashicorp, and kubernetes. I don't know what they are, but apparently without those, software isn't possible.

I worked at Amazon from 2001 to 2006 (and I'm older than you are by a decade).

I made an $8M mistake in 2006 selling all my AMZN stock options because I figured that AWS would never go anywhere because the costs were ridiculous and self-hosting should always be cheaper.

The only thing that Amazon did was do everything cheap as fuck. They didn't use fiberchannel or SANs and didn't pay EMC or VMWare a dime. The engineers and managers that gave of a whiff of trying to empire-build were generally fired.

Doing things cheaply and simply is magic is that the industry does not seem to understand.

And now what Amazon has built on top of its own simple infrastructure is grossly complicated, which makes people feel like its impossible to compete with them since they'd need to build something grossly complicated as well.

It should be simple to run your own in-house "cloud" by doing things very simple and cheap and scalable and responsive to the business. Just have a CTO with a vision and the willingness to aggressively fire the fuck out of anyone spending too much money or putting up barriers to getting shit done (ITIL).

Apparently doing this is more difficult than quantum gravity though. So everyone uses AWS.

Don't get me started on containers and Kubernetes...

definitely try clojure. try clojurescript with shadow-cljs and reagent as well!

Here is my take on this whole thing.

You want tech, that doesn't change every 5 years -- Wait, till you get in contact with frontend/web development, where people adopt new frameworks every couple of months, rehashing the same ideas over and over again, often piling on more and more overhead, so that apps become slower to respond than static rendering templates on the server side and sending a rendered template to the browser at each click of a link. OK, OK, some approaches are novel, sort of. Not all of it is bad, but a lot is utterly hyped up for no technical valid reason. Most of the hype is centered around the believe, that "<Big company x> does y, so y must be good and you are insane, if you do not adopt this last week!"

That said, the whole lambda thing is an idea, which has been around for decades. It is always the same principles under the hood, that drive this kind of tech and seems, that only the recent years or decade they have been paid more attention to. Pure functions, functional programming, and things like sending the function, not the data, to a place, where the computation needs to happen. None of it is new. In Java some of it might be "new", because after decades of foot dragging, they finally added lambdas. But then again you were able to achieve the same thing using anonymous inner classes in the past. Just more verbose and not as encouraging to use.

Basically the whole AWS lambda thing is a branded name for how distributed systems were build for decades, just using different provider and tech stack, but the same principles apply. Watch some talks of Joe Armstrong about Erlang or look at the book "Learn you some Erlang for great Good" for comparison. Joe had some excellent metaphors for lightweight processes and how they enable distributing computation. Recently there was some story here on HN about Klarna using Erlang for example. Not a small business.

You are right about something. Many people think the cloud will magically make everything better. While sometimes it might be a good solution for some problems, many companies could well work without it. Often there is some FOMO involved in having to move to the cloud. But they will lose independence that way as well.

> All your mastery of Kubernetes will be for nothing.

Yes, unless these people entrench Kubernetes in sufficient setups, so that the companies running that cannot simply migrate away and choose to stick with it, to avoid a migration.

> And the worst part is when that day comes everyone will act like it was never that great all along. They'll also embrace the next trend like it's the greatest thing ever. Because software engineers are cursed.

Yes, this is a trend. You can observe this behavior best in web development, where the cycles run faster.

Still, with mainly Java experience (and I am making assumptions here), I guess I would recommend looking at at least a language of the functional paradigm (even if only in free time) and then perhaps other paradigms, because they are the foundation of many new tech, enabling them. I mean, all of that is possible in Java, but Java is not encouraging it at all and usually existing Java projects will not be written in a style, which lends itself to writing in a functional style. This could also be a breath of fresh air, to ignite the fire again and learning many interesting things.

Chill out. Go and get laid.

Are you saying I can actually get paid for that? Wait, I really am in the wrong field.

Reply on news.ycombinator.com