This is just your experience/maturity growing over time. Software development goes through cycles of hype, and it's all too easy to get swallowed by all the excitement. Over time you start realizing that there are no silver bullets, and it's all tradeoffs on top of tradeoffs. Solutions to most problems now start with "it depends", and you're slowly starting to resemble the gray-hairs whom you dismissed as cynical early on. The complexities have always been there, you're just getting wise to them. You're in good company, welcome :)

Oh I'm definitely full gray beard at this point... I'm 49yo and been at this since 96. At this point it's KISS and railing against unnecessary complexity.

It feels like this is working against me in some interviews and for me in others.

Stand up the whole thing with Bash scripts, add a README.md, call it a day. No includes; just long-ass Bash scripts like the good (bad?) old days.

Can't wait for this to be cool again.

> Over time you start realizing that there are no silver bullets

I hate to be that guy, but there is 1 silver bullet. Erlang. Whether you are writing code for a cluster of machines or a single node, the developer experience is the same.

I was working with erlang for around 2 years at Ericsson where of course it's used right.. I really miss it to be honest but advocating for it at my later jobs was just a nightmare !

That’s pretty much the destination I’ve arrived at though in my case via the Elixir route.

You can largely say similar things with go.

I don't think either Erlang or Go are silver bullets. You can't solve _all_ problems efficiently with either. Go may be useful in many many situations, as may be Erlang in some, but if all it take is one significant counter example to detract from something being a "silver bullet", then here's one: https://discord.com/blog/why-discord-is-switching-from-go-to...

I was recently thinking of posting a similar ask hn, but opted not to because if felt too complainy and I’m not sure if the issue is with me or not.

I mainly feel that the scope of a developer’s responsibilities is constantly growing and it’s becoming too much.

I started doing front-end ~20 years ago. At that time we got a psd file, cut it into pieces and created a clickable mock-up. Maybe you’d need to loop through some php of a templating language to make it more dynamic but the logic resided in the backend.

Today I’m still responsible for converting that design, but it’s no longer a clickable mock-up, it’s now an application with its own state and logic that needs to be managed. We now have auth in the client so OAuth comes into play as well.

Instead of creating an index.htm and style.css we npm init which throws cryptic errors about mismatched dependencies, use a bundler, typescript, eslint, … all with their own config. It’s crazy to juggle all this config he’ll.

We used to upload our files to an ftp and called it a day. Now I have to setup a CI/CD, configure our AWS setup and it should all happen in one sprint.

As a React developer it’s also assumed that you know React Native. So you don’t only need to manage node, npm, … you’re now managing Xcode, Android Studio and the entire ecosystem that comes with it. How can you possibly build something of quality under these circumstances?

So yes, we should take a step back and look at the complexity we’re creating. Or at least look into splitting up that complexity into more different roles so that a front-end developer can do front-end again.

The bar's been raised a lot since dotcom took off. Soon you'll need to know prob/stats and matrix algebra to troubleshoot your company's LLM that builds the frontends...and also all of that other stuff, since you're fixing that by hand anyway!

I agree to an extent. I've been relatively happy with the progress in JS. I'm not happy with the lack of attention to performance and bloated applications.

I think that spoke things in the horizon are interesting in terms of hybrid app tools from next, next, astro, Blazor and others.

I also find HTMX pretty compelling. I still like React a lot though.

With all due respect, these are your opinions about your experience. You may think you are ahead of the curve, but what objective measure are you using?

Someone else's decades of experience could lead to opinions that are the polar opposite of yours and be equally valid. You may have had "wrong" experiences and just got lucky that things worked out ok in the end - who is to know?

My advice would be, if you are interviewing, show humility - don't show ego.

Simplicity is underrated by a lot of people. I think engineers (myself included) like to overcomplicate things, and think that if something simple implies it not being an intelligent design.

As I mature, I realize that intelligence != complexity, and more often than not, a simpler approach is harder to design and much better in the long run.

I have noticed that there is a conflation between "simple" (i.e. not complex) and "easy".

Often simple is a lot of work (often times more than complex work). Easy work often just adds quick wins at the cost of tech-debt or unseen complexity.

It is tempting to take the easy path, or allow complexity to grow as systems evolve. Simplicity usually requires a conscious effort and deliberate design work to achieve.

See Hickey's talk on simplicity: https://thestrangeloop.com/2011/simple-made-easy.html

Sounds like have a big ego if you think your opinions are ahead of the curve.

By definition half the population will have opinions ahead of curve, if curve means the median opinion. Unless OP is brash or arrogant when sharing ideas with the team/management, there is not much to attribute to having a big ego here. He OP is thoughtful, considerate and understanding of the situation, then having opinions about the direction would suggest OP is a good engineer/developer/leader/whatever.

> By definition half the population will have opinions ahead of curve

Nothing about that definition tells us anything about the variance. It could be imperceptibly small.

> Unless OP is brash or arrogant when sharing ideas with the team/management, there is not much to attribute to having a big ego here

The OP just claimed to be ahead of the curve, to the team of people reading it on HN. I say that's pretty brash and arrogant.

> having opinions about the direction would suggest OP is a good engineer/developer/leader/whatever.

Opinions, which are common, are not strong evidence of quality (in my opinion)

> By definition half the population will have opinions ahead of curve, if curve means the median opinion.

You’re imagining a continuous distribution that doesn’t exist.

Most people are pretty extremely arrogant, but don't notice it in themselves or others. It's baked into a lot of things.

It's not so much about arrogance as a strong opinion on technical issues and direction. I'm also interviewing for roles at a level where guiding the direction is part of the job.

I've had a pretty good history of seeing shifts in technique and technology over time. Usually advocating a couple years ahead of broader adoption.

Being an advocate for change can be frustrating in and off itself. Especially when that change being advocated is in some regards a return closer to a previous approach.

I've been an early adopter several times. I've also resisted some shifts along the way. It's not always about change right now, but getting thoughts out in the wild.

No so much ego as a few decades of experience. With most situations it depends. But a lot of things come in cycles.

"Make things that are easier to reason with. Code that is easy to reason with and replace is the code that will run for decades."

I agree 100%, and, apparently many others did :

https://en.wikipedia.org/wiki/KISS_principle

When I started out programming in the 90s the KISS principle was mentioned, but I don't hear it so much these days. Maybe we all ought to start talking about it more.

Having been a developer for ages, ridiculous over-complexity of software has always been a problem. It comes and goes I think.

I would write microservices in Java without opening my big mouth if I had bills to pay.

If I already have a job or a comfortable money buffer, I wouldn’t join a software company with a stack I don’t appreciate.

In other words: not-so-micro services, or are you arguing for the return of monolithic architectures?

Somewhere closer to monolith, micro where it makes sense.

More RDBMS again over the likes of Dynamo

Sometimes it seemed to me the real reason people were interested in microservices, containers, etc. is that people want to run different applications in JDK 7, JDK 8, JDK 9, JDK 10, ... Instead of getting control of the Python they're running, data scientists can find a Python that uses Hungarian for the default charset. You don't spend the time to get in control, instead you can manage a larger system which is out of control which will waste a lot more time in the long term and maybe even before them.

It always seemed to me that you should standardize absolutely everything you can in a microservice architecture so that somebody who is working on microservice 7 can switch to microservice 35 and not have to learn a different build system, different web server, different system for loading configuration, connecting to a database and similar details. Not to say there isn't a good reason to use more than one language in some case (e.g. Python for training an ML model, Java for everything else.)

I think this is closest to the truth. Microservices allowed each team to own their own container/jdk and support what they wanted to from the frameworks they were using (mostly spring).

It was trivial then to supply the company with packages that made communication between services as simple as throwing a pojo over the fence. This was simplified again with messaging protocols like protobuf.

Just to add some infrared to an already colorful description of “how we got here”.

I find that small, separate, decoupled services make for easier, more complete testing. Designs like that also tend to minimize race conditions. Multi-thread all you like if there are no races!

I haven't heard anyone talking about new, safe ways to do threading to avoid those problems. Nor have I heard anyone talking about how to constrain individual parts of a monolith so that it can be reasoned about in any way other than a big ball of goo with potentially magical behaviors.

I'm also somewhat concerned that GraphQL is becoming the new monolith. Or at the very least, the new single point of failure.

So . . . I, for one, don't think "balance" is moving back to more tightly coupled code. And I worry that we don't know where to go from here so we'll revert to yesterday's problems (new again!).

Don't use static variables and shared state in service code and you won't have race conditions. Use rpc, cqrs or a number of other service oriented approaches. Go, as an example tends to embrace an approach that scales well and doesn't have the issues you mention.

Of course properly using mutexes and locking can help, so can serially shared state where state is mutated by a single process with request/response. Or you can use something like Nude, where there's only a single language execution thread. Most can leverage an RDBMS as the source of truth for state.

Tighter coupling doesn't mean ignoring ways to reduce certain risks and complexity.

A more monolithic code base doesn't have to be muddy.

As to the smaller services, what happens when you have literally hundreds of smaller services to orchestrate? Is that really reasonable for an application that will never have even a million users?

It comes down to balance and simplicity over complexity.

Micro services don't remove complexity, they only shift it. And if the same people are responsible it becomes more to try to reason with.

Software Development at companies is often like living on an alien planet. It takes information years to propagate to the company[1]. There's a multi-year delay between what you're doing and what you should be doing. Some, I'd imagine, try their best to predict what will happen to compensate for this delay, others may just follow along with the latest and greatest[2] even if there's a multi-year delay.

[1] Even if it reaches faster than speed of light, it may not be accepted or acted upon immediately. The analogy kinda falters here, but hopefully you get the point.

[2] perhaps "greatest" should be replaced with the word "popular" or "trendy"

That's fair, I've usually acted as an advocate for pushing forward. Usually, eventually things move in the direction I've advocated for.

It's just one particular interview yesterday and the feedback rubbed me the wrong way.

Without revealing anything you can't/shouldn't, can you share anything specific about the interview you're describing and what rubbed you the wrong way?

I knew in the interview when I lost one of the younger guys. He kind of looked at me like kind of an alien and shut down.

In the end, they are wanting to move to Los of micro services with a Kafka event bus... And my talking about mini monoliths seemed antithetical to that.

I don't even have a problem with micro services... I have experienced problems with lots of micro services. That being the orchestration complexity and difficulty reading with too many services.

So, my opinion has shifted with time and experience. As it generally does and has.

There are similar ways to get an application that deals with millions of users today. And I mean literally less than 10 million at a more than optimistic peak for the domain.

> I knew in the interview when I lost one of the younger guys. He kind of looked at me like kind of an alien and shut down.

It would be unfortunate, but not unheard of, for someone to reject someone because their world view doesn't match someone else's, even if it's not a personal attack on them and instead just a technical discussion based on experience and presented with context and reasoning.

People are funny and often irrational. Can't please everyone, I suppose. Hopefully you'll find something where your experience and suggestions are met with an open mind.

You are not particularly unique, many before you with exactly the same experience. Your work experience makes you above average at least and so you know what needs to happen.

Other people are not so lucky to have your experience and so they make bad decisions. You can fix this, but it means you have to give up 'doing' and become an evangelist for your beliefs.

Also like many before you, that's a personal choice and might not be a good fit for you. Only you can say.

I've been through it several times at this point... For example, React was a pretty hard sell the first couple years, then it just took off.

HTMX, Rust and even Go is pretty hard though as current points of interest. Let alone other paradigm shifts along the way.

Don't get me wrong, I'll work with things in place and don't generally advocate to replace working systems. It's more about green or forward looking projects.

You can also optionally don't care and get the paycheck.

Are you getting paid for this type of decision leading to your frustration ?

Are you applying to correct role ?

Someone said about software a long time ago: we don't stand on the shoulders of giants, we kick them in the shins.

Or something like that

Here's my heretical views. What's yours?

- the world is full of too many coders writing too much code

- most business logic should be in the database

- I blame the Apple II for the ORM quagmire

- I also blame it for the gender disparity in tech

- tech is littered with the tombstones of ideas that were ahead of their time at their time and still are today

- XML is one of them

- so is XSLT

What role levels are you applying to where you are advocating for a specific direction?

Principal, Staff and Architect mostly.

> Is it just me, as I'm in the middle of a job search as everything is shifting where I feel like I've progressed past?

It could be just you. Perhaps you're so far ahead of the curve that it will take years for the rest of us to catch up, and by then you'll have moved on again.

Not really... Usually a couple years in advocacy ahead of what becomes dominant. That said, there's lots of technologies to choose from.

The older I get, the more I advocate for KISS over any specific approach.