I spent the better part of the past decade+ pushing for more microservice approaches. Breaking things much more apart than they had been. Embracing event driven approaches.
Now, computing power has caught up with the scale that most systems actually need. It's no longer necessary to scale an app to hundreds of servers. We have servers that can run hundreds of simultaneous threads. We have languages like rust that give incredible performance with a low overhead.
It's time to take a half a step back and think about the complexity we are creating and the cost those systems will be to maintain a decade down the line.
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'd it just me, or is anyone else struggling to advocate for balance? 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?
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.
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.
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 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.
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.
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 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!).
[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"
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.
Are you getting paid for this type of decision leading to your frustration ?
Are you applying to correct role ?
Or something like that
- 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
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.