Hacker News Reader

Comment by yafbum | Hacker News Reader

No amount methodology is going to make gold come out of a team that doesn't deeply understand the reasons for building what they're building.

I work with a small-a agile team, and the devs who "get it" just make it happen without a waterfall. The ones who don't get it get a super detailed spec to minimize the chances they'll mess it up, and still mess it up. The ones in the middle know when to reach out to ask for an out-of-cycle product clarification before building a useless pile of code.

The main difference is, do they understand why they're building what they're building? Or do they show up, punch through a bunch of tickets, go home? Really hard to fix that with process when that's not working. It starts with good hiring, building a vision together for what we're building, and communicating it repeatedly.

View on HN

Assuming a team of all at least proficient developers, one who's living a peaceful life outside of work is going to be put into the first category, and people with more chaos in their lives (not by their choice) will fall into the latter category. As their life situation changes they have a bigger chance to lose context, forget who's who or miss out on word of mouth; or conversely, become a sponge for company culture and leave the office with energy for fulfilling projects outside of work and get involved with, for example, open source where they gain insight that they take into work later, for example perspectives on business specific knowledge or some analogues.

I think some developers are just not proficient though. You make a fair point about life circumstances, but not everyone can be prescribed to this track.

Also it's a matter of skill fit. To take extremes I worked with engineers experienced in mobile app game engineering, who were thinking about UI latency in obsessive detail, and engineers skilled in thinking about ML ranking problems, who had deep knowledge about the strengths and weaknesses of various ML approaches. You could've swapped their roles and it would've been a disaster, not because they're not proficient, but because it would've taken a long time to ramp up on what's important in the other's area

I think this pretty much sums it up.

If you have a skilled team with deep domain knowledge, you can afford to not be as detailed in the planning process as the team is most likely already aligned.

If you have a skilled team without deep domain knowledge, you need that sense of unity and alignment, that usually comes through more detailed planning.

It's not one's correct or one's wrong, it just depends on the team composition.

Reply on news.ycombinator.com