Respectfully disagree on the "write it out first" advice. I'd argue "think it out first" or "talk it out first" is sufficient.
I found while scaling my team tended to bury themselves in miles of docs that really did not serve the customer or the company. A janky kind of working prototype of a solution is worth a ton more than a well thought out doc.
Consider that a successful product will be maintained for years. It is highly likely that a people will come and go.
Documenting already running code will inherently have less priority (both in the eyes of upper management an developers- the temptation to jump on the next project is huge). So if you don't start documenting first- odds are you never will.
I disagree with this. Writing a set of "technical objectives" that say how a thing will work takes an hour at most and it helps you think through it better than a conversation. It also helps you pass information to QA. If someone asks what the thing does, you can just send them the link. Ultimately, taking an hour to write it down pays
dividends later on.
I would like to disagree here. Got into a team which has working prototype but not a single word on document.
Which makes this hard to follow up with prototype.
Being tech lead in current position, I am stressing "document-first" approch it is either for client or tech team.
If you have remote teammates or may have any in the future (i.e. if your company allows remote engineers), a culture of writing things down is imperative.
I found while scaling my team tended to bury themselves in miles of docs that really did not serve the customer or the company. A janky kind of working prototype of a solution is worth a ton more than a well thought out doc.