great to read - enthusiastic positivity, "no enemies" approach, educational and participatory results self-organized..
but the ending? Is this a "no good deeds go unpunished" story in sheep's clothing? perhaps young engineers are being conditioned to sudden and unexplained unemployment as if that is normal ? that's a different kind of sheep. Are there grownups in this story ? just kind of awful at the very end after all that positive detail.
The senior engineers should have been more honest ("screw you and your pet language, we won't be using this garbage here") instead of getting the author to run various useless side quests.
They love PHP and Python. Good for them, I don't like those languages but why would I get a job there and try to get them to use a language with a pretty much completely opposite philosophy?
It would be like getting a job at a vegan restaurant and suggest they should have wagyu beef on their menu because it's so tasty and everyone loves it.
I largely agree with you, that rather than introducing Rust into your workplace it's easier to change workplaces.
I currently work in a Go shop. Why Go? Did it win some business value delivering contest? I don't think so, it's just the initial team lead liked Go the most of the languages they knew and made everyone else learn it.
If you read my comment history you'll see I think Go is a mediocre choice. But, it's here to stay in this company and it doesn't matter what new language comes along it won't have the inertia or acceptance of the status quo language. The expected improvement has to be large enough to overcome the associated costs to sell the business case.
This idea of the status quo being somewhat arbitrary, and difficult to change, applies to more than just languages. It applies to everything else, your architecture, your work processes, your culture. A blueprint is set early on by some founding members, and perpetuated potentially forever.
In this world, rather than trying to change a company you change employers. Innovation is change, and to achieve that the individual changes, but leaves their company to remain the same.
Personally, I seek to improve in what I do, to innovate. And I think what we do can be done better and that the tools and systems in-place play a part in that. But will I introduce them at my workplace?
Perhaps not, I think I'll find a new job, and both my old and next company can pay the rather high costs of someone leaving and someone joining. This makes me a little sad, since I like my company and leaving would be a significant amount of institutional knowledge walking out the door.
> I currently work in a Go shop. Why Go? Did it win some business value delivering contest? I don't think so, it's just the initial team lead liked Go the most of the languages they knew and made everyone else learn it.
By this logic either language keep changing when new people join and desire some different language.
> This makes me a little sad, since I like my company and leaving would be a significant amount of institutional knowledge walking out the door.
You shouldn't be. If company you are leaving is any good they would have documented important stuff. If not, they'll get what they deserve. Better to join place where you are part / lead of initial team. Because anything less you would simply be following someone else's language choice or even when language is preferred still their product design decisions.
Yeah this is definitely a leadership mistake. It's hard to say no to people that are really enthusiast about things like this (which obviously the author is), but its doing such a disservice to the business and their career by letting them spend so much time on this.
It seems obvious from the start this is never going to go anywhere. You already are using 4 languages at this company (PHP, Go, Python, JS/TS) ? Adding another is essentially a waste of time and a huge distraction away from the core function of a engineer which is delivering value to the customer.
Often companies that are in need of more bodies will hire people and tell them they can certainly help change the culture and help adopt a new language. Everyone there wants to believe it but it'll probably never happen.
There is probably a fun math problem here: count up the number of engineers, sum up their time in the language. If the average is X or more, they will never switch away from the language they've earned their keep in. It's too hard once you get past a point. Maybe that is already a rule. But I'm sure it is stronger for certain languages, probably PHP especially.
Agreed. I think the author took the wrong lesson, while you are sensing the real deal. There was a lot of rust advocacy time that ultimately had little clear business value -- a couple of bugs that may have been prevented, and rust may have cost different problems instead. If you're getting paid 6-7 figures and supposed to supporting 2-10X that in revenue, that's a real responsibility.
When an infra investment makes sense (lang, DB, ...), especially for 40+ engineers and who knows how big a workload, the multiplier should make the benefit clear. GPU computing speedups, k8s for easier elasticity, something, and ideally obvious like some sort of 10X. We certainly have quite a queue internally like that ("platform X unlocks property Y that has lift Z"), as do many. Conversely, with time wasted, that's a person distracting themselves and everyone else. Getting aligned with the business isn't about pushing a language that might help but identifying what is the most thing you can do to solve the company's/customer's problems, and going for that one.
but the ending? Is this a "no good deeds go unpunished" story in sheep's clothing? perhaps young engineers are being conditioned to sudden and unexplained unemployment as if that is normal ? that's a different kind of sheep. Are there grownups in this story ? just kind of awful at the very end after all that positive detail.