[leonardteo]

Getting vulnerable here for a sec and hoping that others can add their thoughts. I struggle with this. As a small-ish, bootstrapped business, the issue I commonly run into is developer retention. If we stand our ground and choose boring technology because we have limited innovation tokens and can't afford to waste them, there's the flight risk of those devs who really want to work with those new technologies. And this is real. I have dev friends who have left great jobs just because they wanted to move to some new tech and their company simply wasn't ready for the change yet.

In the past I have been told that I "don't trust developers" (despite being one myself), and it has nothing to do with that. It's that some of us are left with the consequences of those decisions and having to maintain those NIH-riddled skeletons in the closet when those individuals leave - and the next person comes along, finds the skeletons and we end up having to rewrite/reimplement that whole part of the system.

Creating an environment where we can thrive and be creative is really challenging. We've implemented the 20% time now where everyone in the company has 1 day a week to just experiment and do whatever they want, just to give the breathing room to be creative and try some of these new technologies. We finally got there. But for years, we just couldn't afford to do it as we were in survival mode.

But the retention issue is still a big one. I feel the tension between having to empower people to make decisions that are for the greater good of the business, while balancing that those people can (and will) leave at any time and not face the consequences of those decisions.

Curious to hear thoughts.

[aphextron]

>"If we stand our ground and choose boring technology because we have limited innovation tokens and can't afford to waste them, there's the flight risk of those devs who really want to work with those new technologies."

That's fine, let them go. There are plenty of great developers out there who just want to come to work, build the product to spec in some 'boring' reliable tech, and go home. The stack doesn't really matter. The "mission" doesn't really matter. Even the product barely matters. I've found that people who are leaving a job for the new shiny thing are either very early career, or the dilettantes who leave behind messes to be cleaned up by professionals.

Massive companies have been built around a Spring/Rails/Zend monolith with a few jQuery plugins on the frontend. Anyone who thinks they need more than that is probably wrong.

[rubber_duck]

>There are plenty of great developers out there who just want to come to work, build the product to spec in some 'boring' reliable tech, and go home.

No there aren't, in fact there aren't plenty of "great" (or pick any adjective related to competent) devs in general, so if you're a small shop and can't compete on wages, work conditions (tech stack included) is your only competitive edge. Because you know what there is plenty of ? Enterprise gigs that need competent people to maintain a legacy cash cow or business backbone - and working in those environments has competitive advantages compared to working in small companies - corporate pace is usually 1/2, company stability, climbing the corporate ladder - if you're a 9-5 guy these things mean a lot. Even those places need to mix in flavour of the day tech to keep their devs from leaving the mind numbing work they feed them.

[tomnipotent]

> No there aren't

Yes, there are. Such a ridiculous statement to think people can't be great at something just because they don't tick some arbitrary box you came up with for evaluation.

If that's the case, then there are no great 9-5 anything... but the odd thing is, I've met plenty of them.

[rubber_duck]

You aren't getting what I'm trying to say - the market for competent 9-5 is also missing developers - it's not that there aren't any - it's that demand > supply - which is why OP is worried about his employees leaving - it's not like he can go out there with a job posting and have 5 competent applicants in a week. You will have to pay recruiters serious money and hope to get lucky on competent leads - so "there are plenty" argument is BS.

[tomnipotent]

> so "there are plenty" argument is BS.

Just like your argument, which pulls claims out of thin air. You haven't made any points at all, simply rambled about competence without backing anything up.

I've learned more often than not, that when someone claims "competence" what they're really saying is "I'm not finding the exact skills I'm looking for, which are hyper-contextualized around the problem I'm currently facing, at the exact moment I need them at the cost I think is best. Which will change in six months, at which point a different cohort of people will be labeled incompetent."

[tomc1985]

Can I be honest? I fucking hate developers. We're like magpies of the worst variety. How many times have I had to argue against bringing in ${NEW_TECH} or ${NEW_TECHNIQUE} because it would be more trouble than its worth. No, it doesn't look as cool engineering-wise, and yes, our work may be a little harder because of it. But then they win the argument and we implement it and hey! Those problems I told you about? They're real! And if they had done it my way we could have moved on to the next thing and not had to worry about this.

Fuck the latest thing. Fuck resume driven development. Fuck magpies. Choose the boring path. Fuck developers!

The worst thing we do is obsess over the latest, coolest tech. Everyone is stepping on their brothers and sisters in this field because they want to be the loser that invented ${NEW_TECH}. We spend so much time optimizing for 'developer happiness' (a.k.a. the new shiny thing) that we forget about architecture.

I am so sick of this field.

[metrokoi]

Why would you say something so controversial yet so brave?

Developers may be the least humble type of engineers. There are many great things that we do, but we need to be taken down a peg every once in a while. Many developers are forced into this mindset out of fear of our marketable skills being made obsolete so I understand why many do this, and it is a compounding problem. Developers seek out jobs with the shiny new technology or push for their company to adopt it to be able to show that technology on their portfolio, then there are fewer positions with the boring but reliable technology and even more are forced to adopt the new technology.

[tomc1985]

Is that fear real though? I mean there are still job listings for VBA or ColdFusion engineers if that's really your thing.

I think our problem (and my our, I mean American) is that we are too obsessed with tech. This is coming from someone who grew up obsessed with computers, and not just writing code. You can tell this is true from looking at our ads, which are always touting the shiniest newest technological marvels. Even beauty products -- they sound so sciency without actually saying anything. Tech is our dogwhistle.

[splintercell]

My father-in-law who is a 58 year old software developer feels stuck at his current job because he has spent so much time on old and archaic technology that he doesn't feel confident enough to be able to go out there and get a new job in case he's laid off.

Personally speaking I spent far too much time working on a certain technology for four years and I felt trapped because getting a new job was difficult in new technologies.

There are clearly some Evergreen Technologies such as C/C++, but there are a lot of Technology switch don't land in that category and they evolved fast (js ecosystem for instance).

[mbrodersen]

I am thinking it but not saying it out loud :-)

[foobarian]

I went through this recently when I joined a company and a small team to do a particular overhauling project. One of the developers was relatively junior, but smart, driven, and in love with shiny new tech. For the particular piece he worked on he chose modern solutions that went a bit out of the companywide envelope. I figured it's fine since if we forced the "boring" company-standard set of technologies he might get bored and leave. Well guess what, he left anyway and now we're left holding the bag. All custom stuff that could have easily been reused: scheduler, base container, code generation, language. So I guess my big takeaway is, regarding retention, they may leave anyway. If you're going to open the "new tech faucet" to slow that down, keeping it sequestered may be worthwhile.

I've seen an internal tool at a previous company that seemed to be built similarly by developers who wanted to try new tech. A pretty fancy RoR with a lot of custom changes and integrations. I am sure they had a ton of fun building it, but again, guess what, they were all already gone by the time I started there. And those who stayed hated that code base with a passion because it was near impossible to upgrade, so now we were stuck on an ancient RoR version, and since it was integrated with a lot of other systems it blocked those upgrades as well. Cautionary tale I guess.

[cutemonster]

> he chose modern solutions that went a bit out of the companywide envelope.

Did he ask if his tech choises were ok before he started?

Or informed you what was on his mind, although maybe didn't ask explicitly?

(I suppose maybe it's not so easy to say no, if one is worried that he'll then leave)

[granshaw]

IMO giving Engineers “space to learn” and “work with new tech” is one of the greatest challenges any Engineering leader faces. I have a pet theory that the soa/micro services trend has in large part been driven by this problem - giving a space to work with such new tech with a limited blast radius, also at the expense of overall velocity and maintainability.

[praveen9920]

If you are early stage start-up, all your employees including engineers should be onboarded with the idea rather than technology choice. If you have someone joined you for any reason other than the excitement for idea, there is higher chance that you will find them going off track too often and it will drag you back

If you are mid-size company, I will assume that you can afford giving some breathing space for everyone to explore but still focus on the goal. You should ideally retain them with the culture.

These are the suggestions based on my experience. I may be wrong.

[nlitened]

There are also small software companies that are not VC-funded startups with flashy ideas — e.g. small bootstrapped consultancies and niche software shops.

In these companies you still have to hire developers for reasons beyond excitement for The Idea.

[praveen9920]

Services companies are different breed altogether. I am a co-founder of such services company, struggled a lot with attrition.

I realised that having people who love your culture will always have your back irrespective of what they do.

Also, Being a niche software shop, one could potentially become contributors to that technology which is exciting in itself.

[yashap]

You’re already making the right decision.

I think introducing new tech is fine as long as it solves a new problem for your business. If you haven’t yet used a cache, but have a need for one, introducing Redis or Memcached makes sense. If you have a new need for pub/sub workflows, introducing Kafka or a webhook dispatcher makes sense. Same with Elasticsearch or whatever if you’re building out your first search feature, etc.

What rarely makes sense is introducing new tech that heavily overlaps with existing tech. You don’t wanna end up on MySQL and Postgres and Mongo. Python and PHP and Go. Django and Flask. EC2 autoscaling and Mesos and Kubernetes. Even worse, you definitely don’t wanna start building your own versions of tech that there’s a good off the shelf solution for. If someone tries to build their own UI framework, ORM, service discovery system, etc., kill that IMMEDIATELY.

Introducing new tech that overlaps with existing tech should only be done if you’re going to migrate OFF the existing tech. Obviously this is often a major effort, so the new tech has to be a HUGE win.

My current company was pretty immature for a long time in terms of tech decisions, and the costs are massive. For service-to-service communication we use REST, gRPC and this terrible in-house re-implementation of HTTP over ZeroMQ, complete with hand written clients and server frameworks in multiple languages. We’ve been trying to migrate off that for ages, at massive cost. We’re almost done, but even then will still be stuck with both HTTP and gRPC, when we only need one. Similarly, we use PHP, Scala, Go and Python on the backend. With multiple server frameworks for each. We use MongoDB and MySQL. Redis and Memcached.

The cost of all this is massive. Developers have to learn SO much to be productive in our stack(s). Every time we want to write some middleware, tooling, etc., we have to write like 15 versions of it, because we have about 15 unique combos of backend language/network protocol/framework. Losing a few immature devs who care more about using shiny new tech than solving business problems is a very, very small cost to pay to avoid this situation.

[michaelbrave]

Ironically I was watching a talk on youtube yesterday by Richard Feldman of NoRedInk[0] that was basically explaining why and how they implemented Elm in production. The most interesting part of the talk to me was how he said it shaped their recruitment pipeline, going from needing recruiters to basically having it full and they can take their pick, and this mostly due to the fact that they were willing to use newer technology stacks. So the long and the short of it is I think you're right, this would affect retention and probably recruiting as well.

I'm a new developer looking for my first job and so I'm making side project to learn in the meantime and what I primarily want from a job is the ability to increase my skills, to get better and to improve, I feel like the kinds of places that are willing and able to experiment will not only have more of a learning culture but will attract others like that as well, so they are more attractive to me as a developer. I imagine this could be countered by things like proper mentor-ship programs or side project time like you've already implemented.

[0]https://www.youtube.com/watch?v=5CYeZ2kEiOI

[mbrodersen]

Be happy to see them go. They are the wrong developers for you to employ. Their focus is all about self-indulgence and not on creating a viable long-term business. Don't ever hire anybody who calls them self a "ninja developer" or equivalent. Instead, ask them to send in their CV again when they are grown up.

[rubber_duck]

I'm against letting juniors or random devs introducing stuff you don't want to maintain in to your codebase for the sake of using the latest fad tech, chances are they will leave anyway and you will be left holding their mess. If they know what they are doing (ie. you hired someone with experience in stack Y and they want to help you migrate) then I'd say go for it if you can afford it. But picking a "safe but boring" stack puts you in the same hiring pool as everyone else picking that stack - can you compete on other terms to attract employees ?

Let's say you decided to write a webapp a few years back when RoR and AngularJS/CoffeScript was the popular stack. You wanted to write it in Clojure but you though "I can't hire Clojure devs reliably and RoR is popular so let's go with that". You are a small business/not high growth - you grow your app steadily - you now have a sizeable codebase on a legacy code stack that nobody really wants to touch or learn, there are plenty of job openings on that stack you have to compete with. Meanwhile people enthusiastic about Clojure were probably above average developers who would be happy to take below market rates just to work on a stack they enjoy and you could easily find people even today.

In a market where demand outpaces supply I'd say the "safe stack" is not a correct choice for small companies - if you have the know-how to pull off something more cutting edge. If you don't then ofc. use what you can to get the job done.

[hinkley]

You cannot ignore all progress, but not all motion is progress.

Technology selection is a very underappreciated and largely unreported skill set.

I think it relates to the Principle of Least Surprise. You can pick tech that has a lot of upside and isn't riddled with gotchas or demanding of eternal vigilance, or you can pick stuff that makes you feel like you're alive all the time.

The latter is risk-taking behavior. It's thrill-seeking. Several other replies exhibit disdain for this behavior, as I think we all should. These people are risking your company for cheap thrills. As one responder puts it, fuck 'em.

[drwiggly]

Ask them live support your app, esp code they didn't write. Or some kind of dev log from the ops people hunting down their bugs. Tricky fun frameworks then become a pita.

[satya71]

I am in the same situation as you. My plan is to build the best personal growth organization that I can. Developers who value that and long-term growth should want to stick around. Developers who want something shiny can look elsewhere.