Hacker News Reader

Comment by kaesar14 | Hacker News Reader

If you have at least one or two engineers familiar with the language it is not hard to teach the rest of the team good practices.

View on HN

I don't think good practices is enough. It's all the little bits of knowledge about what works and what's the right way to do things that you pick up over years of working in and around a framework. Could an excellent C++ dev become and excellent developer working in React with Redux and Typescript and NextJS and Material UI? Of course. And probably less effort than training someone who's never written code before. But that's way, way more than just learning some good practices. It could be _years_ of collective effort (or more likely, just slowly written not-so-good-code) to bring a team up to an advanced or expert level.

Hire for your stack is absolutely a good idea, unless you have no other option.

Most of the benefit of hiring smart people in a startup is not that they do brilliant things, but that they don't do stupid things. So not really necessary that they be domain experts in most cases.

The thing is that even good engineers but inexperienced with some language or environment are exactly the sort of people likely to do "stupid things". People will shoehorn patterns that work well in X into Y where it doesn't really work, they misunderstand things, or don't know something exists, or use things incorrectly leading to subtle bugs, etc. And then a year later you discover "oh, in hindsight now that I know more about this language that was silly, but now we're stuck with it",

If we're talking about startups, then you often don't really have time or staff to spend on training. You want to be able to say "we need X!" and be confident it gets implemented in a reasonable way that's not going to bite you down the line. If you do have the money and staff to train people, then by all means do so, but "super early stage" startups (quoting the article): you're setting the foundation of what the entire business will be built on for years to come and typically have a limited budget to do that. You need people who can get things done reasonably fast but also do it in a way that's not going to cause a lot of headaches in 2 years down the line, and this takes a certain level of experience.

My advice for startups is exactly the opposite: use tools and languages you're already familiar with, unless you have a very good reason not to. Maybe there's some other language that's a somewhat better fit, but being familiar and experienced counts for a lot. I've seen a number of startups really suffer from using $new_tech a few years down the line simply because they used it badly on account of being new to it.

I agree with most of what you're saying. I think at least the first 2 engineers in the team should be experienced in the stack. And nobody inexperienced should ever be making initial design and architecture decisions.

The commenter I was responding to was saying it takes years to learn that stuff and I disagree with that. Smart engineers can get up to speed in a few months with an experienced team.

In a more established company that works well. In very early stage startups? It can, but it's more of a risk. Most early-stage startups are not well organised and the typical situation is that you can do whatever with fairly little oversight. The 3rd, 4th, or 5th engineer can still make a right mess of things.

This applies even more so if your country has fairly strict labour regulations by the way, where it's hard to fire people; bit of a different discussion, but not completely unrelated here.

That's why for me having a strongly technical / expert-level co-founder is really important. I'm lead engineer and the first non-founder coder at at tiny startup, and I just spent several months rebuiling the entire application after spending several more months of grappling with the mess made by the weakly-technical CTO. This is very much not what a super-early startup should be spending it's time on, but there was no way forward with what we had.

If you're a senior engineer joining a startup where the initial application has been built by a non-technical (or weakly-technical aka junior-dev level) person then beware! It may be much, much more of a mess than you are expecting. Go in with your eyes open. You might not have the luxury of fixing it properly, as I have just had. So it better be a promising startup.

I quit my last job due to a situation like this.

The person that built the entire application was very weak technically. I'm pretty sure the motivation for bringing me in was that I would "fix up" the entire mess. There was no documentation, no tests, and tons of code copy/pasted everywhere.

I spent a year trying to improve it, but for every thing I'd clean up, the original engineer would write twice as much new code without consulting me. I tried to get them to do architecture reviews and code reviews, but everything was always an emergency that needed to go live immediately.

If I ever thought about joining a startup that small again, I'd make sure I got to look at a representative chunk of their code base first. And if it looked like it needed a lot of work, I'd grill the existing engineers hard to make sure I can actually do what they want me to do.

Sorry you had that experience. I was also planning to quit if I didn’t get my way on having a rewrite (though I never told anyone at the company my plans). I was lucky that the CTO was not unaware of the weaknesses, and listened to me. And now they mostly stay out of the codebase. It could have gone the other way.

I've been at a startup where this was the case, but they didn't start over, and it was a disaster that, at least partially, was the cause of the failure of the company. Props to you for making the difficult, but correct, choice.

Going "up levels" or side to side is very easy compared to "going down" it's a pain to teach and get people to truly understand stuff like pointers if they've never touched them.

Anyone could paint-by-numbers a Monet. But only Monet could create a new one.

You don't need painters, you need artists.

This is unbelievably condescending.

I'll follow up on your false analogy to try to get you to your mistake: even Monet had to learn before he became Monet! Even Monet had to fight before he became Monet. He even got rejected and created an art salon because he and his peers were misunderstood by art intelligentsia.

So by rejecting engineers that you deem not worthy of being artists, you're just putting yourself in the position of the bourgeoisie that rejected Monet in the first place.

You're ignoring potential for talent. And really am I glad you're doing that because I then get to train and hire them.

You've missed my point and made incorrect claims about how I operate.

You could elaborate on your point?

It may be effective shorthand for your approach, but without more specifics it reads like fortune cookie wisdom to others (i.e. could be very wise, or very unwise, depending on specifics that you have not given).

Actually, you want a team of painters who work well together.

Hiring only Monets doesn't scale. Could the dude have even worked with himself?

https://www.mysanantonio.com/entertainment/arts-culture/book...

You don't need a team of people as skilled as Monet to make a working software product. Incredibly condescending. And good lucking ONLY hiring absolute masters for your engineering team as you scale beyond like, one or two hires. How many people in the world do you even think are that skilled?

Plus people require and deserve investment. It's okay to take in people who need development and turn them into solid engineers.

Truth, though I would argue very few areas in CS still need that caliber of dev - surely most (middling) shops would prefer the paint-by-numbers dev for most roles as it shows they're likely reliable and able to work within the team's existing framework than a maverick who may run circles around the rest (in both good and bad ways).

Ofc you need both, would be interested to see how a full 10x team would operate with no 'grunts' there to slog through all the tedious parts of the SWE process.

If the new hires do not reject the stack (or do the "this would have been so much better if it were written in Y") - in general, yes.

Reply on news.ycombinator.com