10 ms·

I think devs often make bad decision makers because in some sense tech is often an addiction rather than a pragmatic choice. The cycle of picking a tech, jumpi

I think devs often make bad decision makers because in some sense tech is often an addiction rather than a pragmatic choice. The cycle of picking a tech, jumping ship to it, religiously evangelising it, riding the wave and then jumping ship to the next related tech is typical in my opinion. I try hard to correct for this bias but sometimes struggle with exactly the same thing. There's just something about wanting to have a uniform "world-view" with fewer explanatory variables that never stops being motivating.

pjmlp 7y ago
It helps working for big corps. The job might not be as interessing as riding every tech wave, but on the plus side there are plenty of tech waves that you save yourself from riding on. Plus one gets to rescue projects that ended up betting on the wrong waves, getting back to boring old tech.
- Juliate 7y ago
  You mean, Kubernetes is the COBOL of 2050?
  - pjmlp 7y ago
    I mean that Kubernetes is the NoSQL, CoffeScript, BigData, Grails, SOAP... of 2019. It is a bit unfair for Cobol, given that its latest revision is from 2014, and while verbose as it might be, it supports most of the nice features of any modern multi-paradigm language.
    - apalmer 7y ago
      I think this is a bit unfair to SOAP. SOAP was\is a pretty stable technology that did exactly what it promised to do, without too many releases or breaking changes for about 10 years. Even today it has a good utility for the situations it is designed for... RPC over a well known standard format, for tightly coupled endpoints, that require metadata, enforced schema, security, and perhaps transactions. big problem for SOAP is it was the default for web services for a long time, when in reality a big shift happened in about 2008 where webservices were most likely NOT going to fit into those constraints. just my 2 cent
      - pjmlp 7y ago
        CORBA and DCOM certainly felt easier to use than all the headaches I had with SOAP interoperability. And neither of them were selling "magic" stuff like BPEL and BizzTalk.
sieabahlpark 7y ago
You could say that to pretty much any technical abstraction though.
- usgroup 7y ago
  I entirely agree... in fact it applies to me more with maths than it does with tech.
  - nighthawk648 7y ago
    Which maths are you doing? Unless you’re talking about already well defined formalizations.
    - usgroup 7y ago
      Bayesian stats.
tannhaeuser 7y ago
Additional factors I'd want to add: Confirmation bias (where you've spent some time on k8s or whatever, and now you just want to cash in on your time loss, objective criteria be damned) Generational churn (where you find yourself in a field where everything has been said and done, and you just need a new buzzword on your resume to start over; this goes hand-in-hand with corporate IT longing for fresh and cheap staff and their stack in need to look sexy) Big media (where extremely large infrastructure runs on k8s or whatever, and gets disproportional airtime, because cloud providers want to sell you lots of pods, and people not checking whether the proposed arch is a good fit)
- jnty 7y ago
  Decision fatigue and opportunity cost aversion is a big factor too, I think. When comparing consumer products where there's lots of choices, I find myself finding an OK options and 'falling in love' with it - when I reflect, it's basically a way of cutting through all the reviews and deciding that one is the best and I've no reason to regret buying it or need to do any more trawling through reviews and comparisons. I'll just buy this one and be done with it. This strategy often works, to be fair!
goatinaboat 7y ago
The cycle of picking a tech, jumping ship to it, religiously evangelising it, riding the wave and then jumping ship to the next related tech is typical in my opinion. It is typical for devs. Meanwhile ops have to support every half-arsed tyre-fire technology until the end of time, because a dev wanted to try it once, and now it’s in prod with users relying on it. Kubernetes is in a sense the pushback against that “do what you want, as long as k8s is up, what you run in your pods is your problem, not ours”.
- meddlepal 7y ago
  I worked for someone who had mindset that whatever technology developers wanted was always good and ops should just shut up and put up with it because devs are the ones that make the money for the business. Very infuriating mindset to deal with.
  - dagw 7y ago
    And I've worked at companies where the devs where expected to know their place and not question ops, because ops was seen as the serious adults in the room keeping things running and devs where seen as easily distracted children chasing after the shiniest thing that most recently caught their attention. Made perfect sense when I was on the ops side and was super annoying when I was on the dev side :) Imagine if people could all just get along.
    - arethuza 7y ago
      Smaller companies I've worked for don't really seem to suffer from this problem although once companies are larger and have separate teams (and, perhaps more importantly, managers who are incentivized in different ways) this problem always seem to arise.
      - dagw 7y ago
        once companies are larger and have separate teams The real problem always starts when they become separate cost centers with separate budgets and have to independently show a 'profit'.
watwut 7y ago
I think that larger reason is that devs who don't act like that or at least don't pretend to be like that are considered less capable by many. Somehow pragmatical decision making that is seen as not being passionate. There is also such a thing as being sleepy old. And there is reasonable in between.
deleted 7y ago
[deleted]
thewarrior 7y ago
I think jumping on new tech and marketing yourself is a good decision for a developer as its a good way to increase their compensation and market value. If you're a developer stuck maintaining a Java spring app at some unknown company the best way to make a shift is to pick up Go or something and move to a startup. Else your career will stagnate. The best way to get promoted at many companies is to write a framework. The best way to get noticed is to write an open source framework. And so on.
- xena 7y ago
  Stagnate by what standard though? There is a certain joy in just maintaining the status quo.
  - oblio 7y ago
    By financial standards :-)
  - dragonwriter 7y ago
    > Stagnate by what standard though? Range of employment options. Possibly salary, though that's more variable. There are some jobs keeping the lights on with legacy tech long after it is done being the hot thing, but typically with any particular stack it's a shrinking numbwrt of jobs often with shrinking average real pay unless it hits a phase where the decline in people able to do it exceeds the decline in work. If you are riding out the last few years of your tech-focussed career (whether that's before retirement or before moving out of hands-on tech into, e.g., management) that's maybe not so bad, but if you planning being in tech for a longer period it's potentially extremely career-limiting not to adapt to current market focus.
    - madhadron 7y ago
      > Range of employment options. Possibly salary, though that's more variable. I'm not sure this is true. Most of the shops I've been in don't care about whether you know this or that language or library. You're expected to learn that as you need to. Most of what I've seen cut people from interview loops is missing fundamentals.
harimau777 7y ago
The other side of the coin is that there are very real improvements in newer tech and companies, in my experience, are only willing to support continuing education that is directly related to the tech stack that they are using. So a developer that doesn't want to deal with already solved problems and who wants to advance their knowledge is incentivized to push for jumping to the newest tech.
skohan 7y ago
> I think devs often make bad decision makers because in some sense tech is often an addiction rather than a pragmatic choice. I also think this has a lot to do with how devs spend our time: with the tech itself. Whether your application is running on Kubernetes or a box in your garage matters to precisely zero customers as long as it performs well, but as developers we spend our whole day dealing with various APIs and technologies, so we develop an outsized sense of the importance of those things.
- pjmlp 7y ago
  Which is why I think it helps a lot to work in domains where shipping software is not the core business, just a cost center to keep real business going on. One quickly learns that business has a complete different set of priorities and dealing with software as little bonsai trees is not one of them.
tomxor 7y ago
> The cycle of picking a tech, jumping ship to it, religiously evangelising it, riding the wave and then jumping ship to the next related tech is typical in my opinion. To balance this with a counter example from the quieter group of people not "hot for the latest tech": I'm a "dev" and i've never had this problem, however I work for a small company, where everything I make and deploy I also have to maintain in some form or other. This gives me a strong bias towards operational simplicity and trying to essentially eliminate dev ops... New tech which is both complex and opaque in solution without clear cut advantages is basically repulsive to me, because trust and reliability without constant attention and tweaking is important.
- oblio 7y ago
  You're not eliminating "dev ops", you're doing it right.
  - twic 7y ago
    Eliminating dev ops is doing it right! The whole entire point of devops, as it was originally formed, was that making developers bear the load of operations would encourage them to simplify and automate it.
    - oblio 7y ago
      I should have added scare quotes around "eliminating", too, it seems :-)
- pbourke 7y ago
  I’m curious which technologies you’ve ended up working with.
- merb 7y ago
  well even in a small company you might need: - non downtime deployments (yes you can have a downtime, but everytime you deploy an app?!) - schedule more than one thing (no company has a single product that only has a single binary or at least nearly no company, there are some unicorns tough) - some kind of automation (this is complex, no matter what you use)
Double_a_92 7y ago
I think maybe it's easier to blame an external framework in hindsight, than to take the blame for some smaller solution that you personally created in-house.
collyw 7y ago
Part of the problem is the hiring process (plus attitudes seen on here). Your resume needs to have lots of fashionable buzzwords rather than pragmatic good enough / keep it simple choices. You must keep on learning (lots of things rather than mastering any one thing). I can write a really nice site in standard Django with some JQuery, and it will take me half the time that adding React to it will. But adding React will make me much more employable and get me a better wage.
- xena 7y ago
  The real trick is to make your site load so fast people swear it's magic. I use a combination of serving things from ram and https://instant.page https://instant.page to do this with a fairly boring plain old HTML rendering on the server app. I even have a Progressive Web App out of it too.
  - ConfusedDog 7y ago
    Are there any side effects from preloading pages when hovering over the link?
    - xena 7y ago
      Probably? I don't have side effects on hyperlinks though.
      - wlesieutre 7y ago
        The "Pages not preloaded" page notes that it excludes addresses with query strings just in case they run some action that you might not want to trigger on hover. You can override the default behavior if you know it's not an issue. I'm reminded of a post from a few years ago where someone's website had a table of items with [delete] links and would take database actions based on GET requests to those URLs. Who cares? It looks the same to a human browsing it. And then it got crawled by a search engine which followed all the links to see where they went. But if you're not doing anything unusual like that, I don't see how prefetching HTML would cause any problems.
tempguy9999 7y ago
Not just devs, it's really a management problem all round. Management (top bosses) often seem want the latest ie. Big Data . It doesn't mater it'll cost a fortune and you'll get better results on a single server. And if the devs are out of control and pushing for %tech% and getting it, that's management at fault. To be a good manager you need to understand what your employees are doing. I've met too many that don't.
chasd00 7y ago
I've been around enough to see a couple iterations of this. Being able to spot when something is about to fade away and something else come into focus is a valuable skill for consultants. I suppose it's necessary for tech. progress but, man, a lot of money gets spent chasing the new thing.
J-dawg 7y ago
I've suspected this to be the case almost everywhere I've worked. Another reason it happens is that anyone questioning the adoption of a new tech risks looking like they don't understand it. However going the opposite way (sticking to one reliable tech stack and refusing to change even when something better comes along) could be just as damaging to a business. How then, do you build a culture where people are open-minded to new tech without feeling obliged to jump on every bandwagon? I don't think I've ever seen an organisation get the balance quite right.
asdfman123 7y ago
Actually trying all promising new technologies is another full time job, or at least take 20 hours a week. Most developers just don't want to be left behind, so they pick up whatever is trendy at the moment. It's completely rational, because knowing what is trendy getting you hired. However, implementing what's trendy, without carefully weighing pros and cons*, is what's dangerous.

pjmlp 7y ago

It helps working for big corps. The job might not be as interessing as riding every tech wave, but on the plus side there are plenty of tech waves that you save yourself from riding on. Plus one gets to rescue projects that ended up betting on the wrong waves, getting back to boring old tech.

Juliate 7y ago
You mean, Kubernetes is the COBOL of 2050?
- pjmlp 7y ago
  I mean that Kubernetes is the NoSQL, CoffeScript, BigData, Grails, SOAP... of 2019. It is a bit unfair for Cobol, given that its latest revision is from 2014, and while verbose as it might be, it supports most of the nice features of any modern multi-paradigm language.
  - apalmer 7y ago
    I think this is a bit unfair to SOAP. SOAP was\is a pretty stable technology that did exactly what it promised to do, without too many releases or breaking changes for about 10 years. Even today it has a good utility for the situations it is designed for... RPC over a well known standard format, for tightly coupled endpoints, that require metadata, enforced schema, security, and perhaps transactions. big problem for SOAP is it was the default for web services for a long time, when in reality a big shift happened in about 2008 where webservices were most likely NOT going to fit into those constraints. just my 2 cent
    - pjmlp 7y ago
      CORBA and DCOM certainly felt easier to use than all the headaches I had with SOAP interoperability. And neither of them were selling "magic" stuff like BPEL and BizzTalk.

sieabahlpark 7y ago

You could say that to pretty much any technical abstraction though.

usgroup 7y ago
I entirely agree... in fact it applies to me more with maths than it does with tech.
- nighthawk648 7y ago
  Which maths are you doing? Unless you’re talking about already well defined formalizations.
  - usgroup 7y ago
    Bayesian stats.

tannhaeuser 7y ago

Additional factors I'd want to add: Confirmation bias (where you've spent some time on k8s or whatever, and now you just want to cash in on your time loss, objective criteria be damned) Generational churn (where you find yourself in a field where everything has been said and done, and you just need a new buzzword on your resume to start over; this goes hand-in-hand with corporate IT longing for fresh and cheap staff and their stack in need to look sexy) Big media (where extremely large infrastructure runs on k8s or whatever, and gets disproportional airtime, because cloud providers want to sell you lots of pods, and people not checking whether the proposed arch is a good fit)

jnty 7y ago
Decision fatigue and opportunity cost aversion is a big factor too, I think. When comparing consumer products where there's lots of choices, I find myself finding an OK options and 'falling in love' with it - when I reflect, it's basically a way of cutting through all the reviews and deciding that one is the best and I've no reason to regret buying it or need to do any more trawling through reviews and comparisons. I'll just buy this one and be done with it. This strategy often works, to be fair!

goatinaboat 7y ago

The cycle of picking a tech, jumping ship to it, religiously evangelising it, riding the wave and then jumping ship to the next related tech is typical in my opinion. It is typical for devs. Meanwhile ops have to support every half-arsed tyre-fire technology until the end of time, because a dev wanted to try it once, and now it’s in prod with users relying on it. Kubernetes is in a sense the pushback against that “do what you want, as long as k8s is up, what you run in your pods is your problem, not ours”.

meddlepal 7y ago
I worked for someone who had mindset that whatever technology developers wanted was always good and ops should just shut up and put up with it because devs are the ones that make the money for the business. Very infuriating mindset to deal with.
- dagw 7y ago
  And I've worked at companies where the devs where expected to know their place and not question ops, because ops was seen as the serious adults in the room keeping things running and devs where seen as easily distracted children chasing after the shiniest thing that most recently caught their attention. Made perfect sense when I was on the ops side and was super annoying when I was on the dev side :) Imagine if people could all just get along.
  - arethuza 7y ago
    Smaller companies I've worked for don't really seem to suffer from this problem although once companies are larger and have separate teams (and, perhaps more importantly, managers who are incentivized in different ways) this problem always seem to arise.
    - dagw 7y ago
      once companies are larger and have separate teams The real problem always starts when they become separate cost centers with separate budgets and have to independently show a 'profit'.

watwut 7y ago

I think that larger reason is that devs who don't act like that or at least don't pretend to be like that are considered less capable by many. Somehow pragmatical decision making that is seen as not being passionate. There is also such a thing as being sleepy old. And there is reasonable in between.

deleted 7y ago

[deleted]

thewarrior 7y ago

I think jumping on new tech and marketing yourself is a good decision for a developer as its a good way to increase their compensation and market value. If you're a developer stuck maintaining a Java spring app at some unknown company the best way to make a shift is to pick up Go or something and move to a startup. Else your career will stagnate. The best way to get promoted at many companies is to write a framework. The best way to get noticed is to write an open source framework. And so on.

xena 7y ago
Stagnate by what standard though? There is a certain joy in just maintaining the status quo.
- oblio 7y ago
  By financial standards :-)
- dragonwriter 7y ago
  > Stagnate by what standard though? Range of employment options. Possibly salary, though that's more variable. There are some jobs keeping the lights on with legacy tech long after it is done being the hot thing, but typically with any particular stack it's a shrinking numbwrt of jobs often with shrinking average real pay unless it hits a phase where the decline in people able to do it exceeds the decline in work. If you are riding out the last few years of your tech-focussed career (whether that's before retirement or before moving out of hands-on tech into, e.g., management) that's maybe not so bad, but if you planning being in tech for a longer period it's potentially extremely career-limiting not to adapt to current market focus.
  - madhadron 7y ago
    > Range of employment options. Possibly salary, though that's more variable. I'm not sure this is true. Most of the shops I've been in don't care about whether you know this or that language or library. You're expected to learn that as you need to. Most of what I've seen cut people from interview loops is missing fundamentals.

harimau777 7y ago

The other side of the coin is that there are very real improvements in newer tech and companies, in my experience, are only willing to support continuing education that is directly related to the tech stack that they are using. So a developer that doesn't want to deal with already solved problems and who wants to advance their knowledge is incentivized to push for jumping to the newest tech.

skohan 7y ago

> I think devs often make bad decision makers because in some sense tech is often an addiction rather than a pragmatic choice. I also think this has a lot to do with how devs spend our time: with the tech itself. Whether your application is running on Kubernetes or a box in your garage matters to precisely zero customers as long as it performs well, but as developers we spend our whole day dealing with various APIs and technologies, so we develop an outsized sense of the importance of those things.

pjmlp 7y ago
Which is why I think it helps a lot to work in domains where shipping software is not the core business, just a cost center to keep real business going on. One quickly learns that business has a complete different set of priorities and dealing with software as little bonsai trees is not one of them.

tomxor 7y ago

> The cycle of picking a tech, jumping ship to it, religiously evangelising it, riding the wave and then jumping ship to the next related tech is typical in my opinion. To balance this with a counter example from the quieter group of people not "hot for the latest tech": I'm a "dev" and i've never had this problem, however I work for a small company, where everything I make and deploy I also have to maintain in some form or other. This gives me a strong bias towards operational simplicity and trying to essentially eliminate dev ops... New tech which is both complex and opaque in solution without clear cut advantages is basically repulsive to me, because trust and reliability without constant attention and tweaking is important.

oblio 7y ago
You're not eliminating "dev ops", you're doing it right.
- twic 7y ago
  Eliminating dev ops is doing it right! The whole entire point of devops, as it was originally formed, was that making developers bear the load of operations would encourage them to simplify and automate it.
  - oblio 7y ago
    I should have added scare quotes around "eliminating", too, it seems :-)
pbourke 7y ago
I’m curious which technologies you’ve ended up working with.
merb 7y ago
well even in a small company you might need: - non downtime deployments (yes you can have a downtime, but everytime you deploy an app?!) - schedule more than one thing (no company has a single product that only has a single binary or at least nearly no company, there are some unicorns tough) - some kind of automation (this is complex, no matter what you use)

Double_a_92 7y ago

I think maybe it's easier to blame an external framework in hindsight, than to take the blame for some smaller solution that you personally created in-house.

collyw 7y ago

Part of the problem is the hiring process (plus attitudes seen on here). Your resume needs to have lots of fashionable buzzwords rather than pragmatic good enough / keep it simple choices. You must keep on learning (lots of things rather than mastering any one thing). I can write a really nice site in standard Django with some JQuery, and it will take me half the time that adding React to it will. But adding React will make me much more employable and get me a better wage.

xena 7y ago
The real trick is to make your site load so fast people swear it's magic. I use a combination of serving things from ram and https://instant.page https://instant.page to do this with a fairly boring plain old HTML rendering on the server app. I even have a Progressive Web App out of it too.
- ConfusedDog 7y ago
  Are there any side effects from preloading pages when hovering over the link?
  - xena 7y ago
    Probably? I don't have side effects on hyperlinks though.
    - wlesieutre 7y ago
      The "Pages not preloaded" page notes that it excludes addresses with query strings just in case they run some action that you might not want to trigger on hover. You can override the default behavior if you know it's not an issue. I'm reminded of a post from a few years ago where someone's website had a table of items with [delete] links and would take database actions based on GET requests to those URLs. Who cares? It looks the same to a human browsing it. And then it got crawled by a search engine which followed all the links to see where they went. But if you're not doing anything unusual like that, I don't see how prefetching HTML would cause any problems.

tempguy9999 7y ago

Not just devs, it's really a management problem all round. Management (top bosses) often seem want the latest ie. Big Data . It doesn't mater it'll cost a fortune and you'll get better results on a single server. And if the devs are out of control and pushing for %tech% and getting it, that's management at fault. To be a good manager you need to understand what your employees are doing. I've met too many that don't.

chasd00 7y ago

I've been around enough to see a couple iterations of this. Being able to spot when something is about to fade away and something else come into focus is a valuable skill for consultants. I suppose it's necessary for tech. progress but, man, a lot of money gets spent chasing the new thing.

J-dawg 7y ago

I've suspected this to be the case almost everywhere I've worked. Another reason it happens is that anyone questioning the adoption of a new tech risks looking like they don't understand it. However going the opposite way (sticking to one reliable tech stack and refusing to change even when something better comes along) could be just as damaging to a business. How then, do you build a culture where people are open-minded to new tech without feeling obliged to jump on every bandwagon? I don't think I've ever seen an organisation get the balance quite right.

asdfman123 7y ago

Actually trying all promising new technologies is another full time job, or at least take 20 hours a week. Most developers just don't want to be left behind, so they pick up whatever is trendy at the moment. It's completely rational, because knowing what is trendy getting you hired. However, implementing what's trendy, without carefully weighing pros and cons*, is what's dangerous.