And some developers bring this on themselves. They could use the boring conservative technology that they know inside and out from the last project, or they could use something that's new and hot this month, which they have never done or have much less experience with (but is exciting).
Double whammy if it's an unfamiliar domain and a cutting-edge tech stack.
There is a new significant technology released every week. Sometimes there are several in one day. When people seem surprised that I haven't heard of their new favorite tech it makes them seem inexperienced or dumb to me. Actually I think you can almost take any two random developers and there is a good chance they are each working on technologies that the other has never heard of. The thing is new technology comes out as soon as people think of it and type it in.
New doesn't mean they're not experienced, just means they're potentially using different technology than yours. In my case I admit the tech I use is outdated (LAMP) so if someone comes in and is like "Oh we should completely redo this in MEAN/MERN" which while it hurts (haha), I admit my code is probably garbage. But I'm also happy to the idea that I'm not going to be the developer working on this and underpaid as well.
It'll just be interesting because I built it from scratch, no frameworks, setup the server and everything, I briefly looked into running Node/Apache side by side or port directing... I don't know that's a hypothetical situation anyway. It's just that with web dev there are different ways to develop something and deploy it. I'm not the guy to fight so I'll just be like "Alright sure, sounds good, have at it, what do I know I've only been building this thing for the last 4 months." But I acknowledge that I'm behind/not great. Have an open mind I guess.
It's not a big project or anything either. But the person I "work for" is looking through UpWork for another developer and I'll have some say (provide specifics of the site/what it's using/running on).
I am going to make the transition into Node, at least to be able to do what I do with MySQL/PHP with JavaScript/Mongo. No particular reason on Node, but to not be stuck in LAMP either. There's also Go... ahhh. There's a reason I don't work full time as a web developer.
I have worked in tech long enough to see some common patterns. It's usually intermediate devs (though not always) who get excited by new tech. The same people are usually pushing to use shiny new tech in places where it isn't needed. You don't get cynical old school devs trying to replace working parts of the tech stack with tech less than 5 years old.
Personally i think developer skill has far more to do with maintainability than language choice. And I have worked with a lot of shit code.
That's overly broad. A lot of people jump on the latest trends, especially people who are simply new to development, because there's no way you can know stuff you haven't had time to learn.
My feeling from the article was that people just jumped on the hot new thing, because let’s be honest “new” or generally more interesting than “old”. That could easily be a source of projects spinning up, taking devs from other projects(dooming them), and then in a full circle leaving to join whatever new project had come up.
Eg, if the direction is always “work on whatever you find fun right now” you run into problems ever actually finishing anything. Which matches what happens in my ~/Projects folder quite well :)
I'm all for the wild explosion of new tech, that said when the time rolls around to pick a toolset for building a new application I'll invariably do a step back and I'll pick something that has been around for a couple of years.
The reason is fairly simple, new stuff usually contains tons of bugs and it remains to be seen if it is still going to be around a few years down the road.
I'm a coward that way, but when my income is on the line I don't want to be beta testing someone else's code without having a very good chance that the problem I'm trying to find is mine and not some bug in underlying code.
For hobby stuff and learning I love to play around with new things, as soon as it is 'business' I'm a lot more conservative.
I'd add that some programmers wish to build their exciting new technology upon a strong foundation rather than sand. Sometimes bleeding edge technology requires a non-trivial amount of work to keep up with breaking changes in return for something that can be obtained another way (isolation via docker vs traditional virtualization).
Sometimes boring technology choices are a sign that the programmers are innovating in their actual technology rather than blindly adopting whatever they see in blog posts.
There's so much cool stuff coming out for building web apps. If you started your project more than a month ago, it seems to mean that you're using old, outdated stuff which is going to make you less productive.
I console myself by realising that the lack of extra abstractions makes my application faster and lighter.
Seriously though, how does one take advantage of new stuff without rewriting too much or ending up with an inconsistent and messy codebase?
I don't think it's wrong to get excited about new tech. But from what I have observed it's mostly that one dev that pushes for new stuff and after they get sick/leave someone else has to take care of it and many times it means a rewrite of that functionality. Also many times with new tech, you can't really tell its bad sides, because it takes some time to know if it's solid or not.
Those are very valuable skills. Developers who have not had a relationship with an existing code base, or one that is less than a few years old don't know yet the difficulty of rebuilding your world every few years and not really progressing.
A lot of the new tooling is also maturing and lending itself to rewrites.. while tested boring technologies also let you focus on the solution instead of building a monument of orchestration to yourself.
You're absolutely right, many developers seem only to want to pigeon-hole a particular use case into the newest framework or technology they want to learn. I guess it depends on the developer.
I think the point here is some people like to tinker with new things. There is a balance to strike here. Some do live in a bubble. On the other extreme are people who jump from one new thing to the next. Understanding the tools available is great but becoming an expert at something is import too. Most important thing is creating great products no matter what you use to build it. Your users don't care what it was developed in.
I think the circular nature of tech is a good chunk of why older developers are seen as "stuck in their ways" or unwilling to learn.
At a certain point, you realize that people in tech are constantly promoting the holy grail. So you buy into it, learn it, and then see that it has different, or even very similar weaknesses to the old tech. Also, you begin to realize that domain experience is a very powerful thing.
So, I would rather be happy, operating in the 'zone' with the platform I know, doing 20% more work to hack around sub-optimal language feature, than spend time in distress, trying to wrap my head around a completely different platform, all because someone on my team is obsessed with the new flavor.
I carefully avoided making the statement you've just deconstructed. Nothing in my original post mentions newness.
The point I made is that enthusiastic and excited developers are valuable. Developers tend to find learning exciting. They could be interested in learning Rails or Django for the first time, trying out Sinatra when a full Rails app seems overkill, or exploring Node for a small and non-critical part of your architecture. Hell, they might be excited about learning PHP.
Allowing people to explore their curiosity brings material benefits. It doesn't have to involve new technology, and I didn't suggest that it does.
As an aside:
> The real market for technology adoption should fueled by demand for simplicity, rather than demand new-ness
I think part of node's mass appeal is that it has introduced an element of simplicity to a generation of developers who have grown up around bloat.
>I carefully avoided making the statement you've just deconstructed.
Perhaps you carefully avoid it, but you also strongly implied it. Consider:
>You're lucky enough to live at a time where there are numerous production-ready tools with which to do your job. If you choose a tool that you're excited to explore, with an active and fast-moving ecosystem, your excitement and enthusiasm will make you happier and more likely to do a better job.
You're optimizing for programmer excitement. There's a famous graph of programmer excitement curves floating around on the net, with a peak at "new and shiny" stage.
>Developers tend to find learning exciting. They could be interested in learning Rails or Django for the first time, trying out Sinatra when a full Rails app seems overkill, or exploring Node for a small and non-critical part of your architecture. Hell, they might be excited about learning PHP.
I'm not arguing the truth of what you're saying - it's obviously, painfully true that developers absolutely love trying out the new hotness (sometimes even if it's just new to them). I'm simply asserting that this is bad.
I agree, but I think the idea is “can they deal with the unexpected or new? How fast do they grok things” Which happens all the time with these new frameworks, tools, etc
“I worry that some programmers (and their employers) have this attitude, namely a focus on transitioning stacks to the newest. They pick companies primarily based on the framework, aiming for the latest instead of the best tool for the job. They spend their time playing with new libraries and frameworks, instead of improving their core technical skills. Let's call them stack chasers - those pushing for new technologies (or their own favorite technologies) in a startup's stack, with limited advantages for key outputs (software capabilities that users value, development team productivity).”
I find three key underlying factors:
1. Using marketing (including Hacker News posts), to make tech choices
2. Not having the historical context to realize how ephemeral so many current tools are
3. Software training programs stress DSLs and frameworks because they help you get jobs the fastest (same with job posts)
For practical advice, I always loved Dan McKinley’s concept of a fixed budget of innovation tokens:
Definetly not my experience. My view is that organizations are VERY reluctant to introduce new tech to their stack, and rightfully so in my opinion.
For example: moving a Java dev to a different Java project internally is much easier than convincing a Java dev to learn Go (especially seniors who already invested a lot of time in learning it), and is much cheaper than hiring a new Go developer (onboarding etc.)
Double whammy if it's an unfamiliar domain and a cutting-edge tech stack.
reply