3 ms·
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 te
by sub7 7y ago
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.
- cyode 7y agoIf 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.
- fest 7y agoConsider 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.
- dharmab 7y agoMy team has a rule- if it's not in writing at a permalink it doesn't exist. A simple 2-3 line github issue is often enough. what and why.
- jugg1es 7y agoI 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.
- navyad 7y agoI 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.