High Performance Individuals and Teams • Hacker News Board

Re: High Performance Individuals and Teams

#71

Post by Viliam1234 » Wed, Nov 18, 2020, 2:06 AM UTC

username90 wrote: post #46

fctorial wrote: post #32

Earlier quoted context omitted.

Can john carmack build 10 crud apps in a week?

Pretty sure he could if he got to practice writing crud apps for a month beforehand and the apps were no more complicated than what a mediocre engineer can write in a week.

Also, one engineer making 10 crud apps would probably share a lot of code between the apps. Which would allow him to make the new ones even faster. And the result would be easier to maintain.

If you instead hire 10 engineers to write 1 app each, you often end up with 10 apps using 8 different frameworks in 3 different languages. And then you will need 10 engineers to maintain them.

Re: High Performance Individuals and Teams

#72

Post by Viliam1234 » Wed, Nov 18, 2020, 2:09 AM UTC

AlchemistCamp wrote: post #51

username90 wrote: post #42

Earlier quoted context omitted.

If you do hire them but your process can't tell the difference between them and the bad engineer they work with they will get frustrated and quit soon. The most important part to keep good engineers is to ensure they don't have to work alongside bad engineers.

I can't imagine a situation where I couldn't tell the difference between either of them and a bad engineer. I'd either be pair programming with them and learning a lot or be pairing with a "bad engineer" and suffering.

Sometimes people making the decision about hiring are not programmers themselves, or happen to be the bad engineers. In both cases, the difference between a good and bad engineer can be invisible for them.

Re: High Performance Individuals and Teams

#73

Post by gen220 » Wed, Nov 18, 2020, 5:18 PM UTC

coderintherye wrote: post #4

"If you find a project where only one person know what is going on, chances are that person is not good at writing code for humans, not that is a coding god." This is hard for many to grasp, but if you get the opportunity to lead enough teams it will become clear. And it makes sense, if you think about it. An individual who ended up owning a particular piece of a codebase will be incentivized to obfuscate and obscure…

IME, this isn't so black and white.

In some situations, that engineer has a very strong mental model of the business domain they're modelling in code. It's a model forged by years of experience in the domain.

The model has complexities, but they are generally a minimal set necessary necessary to span the domain.

At first sniff, new engineers might find the code overengineered. It's a Chesterston's Fence dilemma. Except, in this circumstance, you have the builder there to explain the fence, and IMO it's wrong to assume malfeasance (obfuscating for control), when there are other contributing factors.

IME, the way to resolve this ambiguity is paired programming and communication. After the 2nd or 3rd session, the mental model should prove to be transferable or not.

Re: High Performance Individuals and Teams

#74

Post by cutemonster » Fri, Nov 20, 2020, 10:52 PM UTC

NhanH wrote: post #18

usefulcat wrote: post #13

> Even more important than finding great engineers is to avoid bad ones. After reading that sentence, I thought to myself, "How long did I go from the start of my career before meeting someone of whom I genuinely thought, 'this person is so bad they should definitely be fired asap'?". In my case, I think the answer is somewhere around 20 years. My takeaway from this is that at even with ~18 years of experience, my fo…

My take away from your comment is that bad engineers are genuinely so rare to meet that false positive from following the advice should heavily outweight any advantage of it.

> false positive from following the advice

Is that accidentally not hiring someone who would have been a good fit?

Re: High Performance Individuals and Teams

#75

Post by cutemonster » Fri, Nov 20, 2020, 10:56 PM UTC

AmericanChopper wrote: post #43

NhanH wrote: post #18

Earlier quoted context omitted.

My take away from your comment is that bad engineers are genuinely so rare to meet that false positive from following the advice should heavily outweight any advantage of it.

I think that strongly depends on the environment. I’ve worked in a lot of big corporates, and negative value engineers are exceedingly common there. I’ve also seen them in quite a few early stage startups that don’t have particularly strong technical founders. In those situations the first technical hire will often become the technical leader, and if that person is useless then the technical direction of the company…

> the first technical hire will often become the technical leader, and if that person is useless then the technical direction of the company is doomed.

It'd be interesting if there was somewhere to read about such companies.

Maybe they don't realize themselves -- if the founders aren't technical enough to realize that the technical leader is the very wrong person

They might never realize why things didn't go their way, and blame other things instead

Re: High Performance Individuals and Teams

#76

Post by cutemonster » Fri, Nov 20, 2020, 11:01 PM UTC

eyelidlessness wrote: post #66

usefulcat wrote: post #13

> Even more important than finding great engineers is to avoid bad ones. After reading that sentence, I thought to myself, "How long did I go from the start of my career before meeting someone of whom I genuinely thought, 'this person is so bad they should definitely be fired asap'?". In my case, I think the answer is somewhere around 20 years. My takeaway from this is that at even with ~18 years of experience, my fo…

I was probably 6-7 years into my career before I encountered such a person. It was my first formally titled “software” role, having spent the years prior making software and calling it “websites”, for a mostly brochureware design firm. I had terrible impostor syndrome. But I recognized that a member of my team was simply not up to the task. And was very well liked by the team, so no one had spoken up. But I was gaini…

> I feared alienating everyone

It seems you didn't alienate them in the end? When looking back?