Hacker News Reader

Comment by 999900000999 | Hacker News Reader

How big is your team?

One person writing a stack in 6 languages is different from a team of 100 using 6 languages.

The problem emerges if you have some eccentric person who likes using a niche language no one else on the team knows. Three months into development they decide they hate software engineering and move to a farm in North Carolina.

Who else is going to be able to pick up their tasks, are you going to be able to quickly on board someone else. Or are you going to have to hire someone new with a specialty in this specific language.

This is a part of why NodeJS quickly ate the world. A lot of web studios had a bunch of front end programmers who were already really good with JavaScript. While NodeJS and frontend JS aren't 100% the same, it's not hard to learn both.

Try to get a front end dev to learn Spring in a week...

View on HN

Very much this. The concerns with running a six person team are quite a bit different from the concerns of directing hundreds to thousands of developers across multiple projects. No matter how good the team is and how well they are paid and treated, there will be churn. Hiring and supporting folks until they are productive is very expensive and gets more expensive the more complicated and number of different stacks you have to maintain.

If you want to have efficient portability of developers between teams you've got to consolidate and simplify your stacks as much as possible. Yeah your super star devs already know most of the languages and can pick up one more in stride no problem. But that's not your average developer. That average dev in very large organizations has worked on one language in one capacity for the last 5-15 years and knows almost nothing else. They aren't reading HN or really anything technology related not directly assigned via certification requirements. It's just a job. They aren't curious about the craft. How are you able to get those folks as productive as possible within your environment while still building institutional resiliency and, when possible, improving things?

That's why the transition from small startup with a couple pizza teams to large organizations with hundreds of developers is so difficult. They are able to actually hire full teams of amazing developers who are curious about the craft. The CTO has likely personally interviewed every single developer. At some point that doesn't become feasible and HR processes become involved. So inevitably the hiring bar will drop. And you'll start getting in more developers who are better about talking through an interview process than jumping between tech stacks fluidly. At some point, you have to transition to a "serious business" with processes and standards and paperwork and all that junk that startup devs hate. Maybe you can afford to have a skunkworks team that can play like startups. But it's just not feasible for the rest of Very Large Organizations. They have to be boring and predictable.

I've seen a grown man nearly start crying when asked to switch programming languages. It would of at most been a few weeks to help with some legacy code.

He starts mouthing off about how much more he can make somewhere else. Management relents and he got his way.

>If you want to have efficient portability of developers between teams you've got to consolidate and simplify your stacks as much as possible.

Amen!

I'm often tasked with creating new frameworks when I come to a new company. I always try to use whatever people are already comfortable with. If we're a NodeJS shop, I'll do it in NodeJS.

Unless you have very unique challenges to solve, you can probably more or less use the same stack across the company.

On a personal level I think it's a good idea to be comfortable with at least 3 languages. I've worked professionally in NodeJS, Python, and C#. While building hobbyist stuff with Dart/Flutter.

I don't have strong opinions either way, but if my boss expected me to learn Rust I'd probably start looking elsewhere. Not that Rust is bad, I just don't think I can do it.

> This is a part of why NodeJS quickly ate the world

And the other part is you can share, say, data validation code between client and server easily - or move logic either side of the network without having to rewrite it.

ie Even if you are an expert in Java and Javascript - there are still benefits to running the same both ends.

Excellent comment. What you raised are two important aspects of the analysis that the article didn't bother thinking about:

- how to best leverage the team you currently have

- what is the most likely shape your team will have in the future

Jane Street has enough resources and experts to be able to train developers on OCaml, Nubank and Clojure also comes to mind. If one leaves, the impact is not devastating. Hiring is not straightforward, but they are able to hire engineers willing to learn and train them.

This is not true for a lot of places, that have tighter teams and budgets, whose product is less specialized, and so on.

But this is where the article fails and your comment succeeds: actually setting out parameters to establish a strategy.

Most of the engineering advice tries to be as general as possible.

The issue is nothing is general in software. What a solo dev, a 10 person startup and a FAANG should do are 3 different things.

For example, a hobbyist dev who spends all day writing unit tests and calculating their own points in Jira, that doesn't make sense.

But I'd be horrified to see the same dev not use any task tracking at all at work.

For myself I take long breaks on my side projects, particularly when it comes to boring stuff like authentication.

If course I can't do that at my full time job. I can't just stop and do something else.

Jane Street is making billions in revenue per year and all their software needs to be as optimized as possible. If making the software 1% better nets you another 100 million dollars, you can hire a dozen people to specifically write internal tooling to make it happen.

Verses a smaller team probably just has to be do with off the shelf solutions .

The other thing this article misses is this is going to drastically depend on your industry. It doesn't really matter if you're selling special cat food and need an e-commerce website for that.

It's a completely different story if you're developing a low latency trading system

Reply on news.ycombinator.com