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.
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.
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.
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."
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.
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.
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.
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).
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.
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)
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.
In these companies you still have to hire developers for reasons beyond excitement for The Idea.
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.
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.
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.
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.
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.
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.