[soorya3]

This first 3 hit me very hard,

1. The best engineers are obsessed with solving user problems.

I think this problem is rooted in early education: students learn languages, frameworks, and tools first without understanding what problems they actually solve. Once engineers have experience building a few products for users, they begin to understand what matters to the user.

2. Being right is cheap. Getting to right together is the real work.

- Sadly most of the arguments are won by either someone in power or experience. Right decisions are made with consensus. You build consensus during creative process and leverage power and experience during crisis.

3. Bias towards action. Ship. You can edit a bad page, but you can’t edit a blank one.

- Every decision is a risk management. The smart people convert higher risk into lower risk. Most people struggle here to take the risk because of the fear of failing and just waste time arguing, debating and winning over each other.

[dartharva]

The problem with point 3 is that once you start with a bad draft and everyone starts working on it you're kind of locked in to its trajectory, even when it'd be a lot better if you were to do it another way. You can't start from scratch even if you're feasibly within the window to do so, because now the work has started.

[afro88]

But that is still better than nothing at all, which is the point.

The people you want (or want to be) are the engineers who are smart and experienced enough to get a first draft down that is pretty much right without a long drawn out process of figuring out the best way to do X, Y and Z with all the lengthy ADRs, discussions, debates, POCs, revisions etc. over and over again. That may be necessary if you don't have people in the room who know what they're doing and have the intuition through deep experience to choose good tools, patterns and abstractions at the start. Begin closer to the target, rather than far away and iterate to it.

[judahmeek]

Tell that to Facebook's Metaverse team

[FridgeSeal]

I think it depends on the team.

Some teams I’ve been in, we could go “this is shit, we must be doing this wrong” and we’d go back to the drawing board without blinking.

Other teams, just getting _something_ going, even if it was garbage, was a enormous achievement, and saying it was bad and that we should start again would be a recipe for disaster.

[thisOtterBeGood]

Thinking back, there really should be some lessions that send students off to solve user problems after having learned a programming language, where there is a much easier solution without having to program something. Some refinement sessions that teach them how to understand the problems.

[gedy]

Internships should be for that, but that's fallen by the wayside in many places.