[ElatedOwl]

Writing is really beneficial for exploring the problem space.

Many times I’ve confidently thought I understood a problem, started writing about it, and come away with new critical questions. These things are typically more visible from the abstract, or might not become apparent in the first few release milestones of work.

I’m reminded of a mentor in my career, who had designed an active/active setup retroactively for a payment gateway. He pulls up a Lucidchart and says “this diagram represents 6 months of my life”.

They’re not always necessary or helpful. But when they are you can save weeks of coding with a few days of planning.

[appleiigs]

I had a boss who had a math degree. He'd map out the flow from start to finish on a whiteboard like you see mathematicians on TV/movies. Always had the smoothest projects because he could foresee problems way in advance. If there was a problem or uncertainty identified, we'd just model that part. Then go back to whiteboard and continue.

An analogy is planning a road trip with a map. The way design docs most are built now, it shows the path and you start driving. Whereas my bosses whiteboard maps "over-planned" where you'd stop for fuel, attraction hours, docs required to cross border, budget $ for everything, emergency kit, Plan A, Plan B.

Super tedious, but way better than using throwaway code. Not over-planning feels lazy to me now

Sure, everyone has a plan until you get punched in the mouth; however, that saying applies to war, politics, negotiations, but not coding.

[jnsaff2]

I the book How Big Things Get Done they analyze big and small project failures and success and end up with something along the lines:

1. Spend as much time in planning as necessary, in the context of mega projects planning is essentially free, maximize the time and value gained in planning.

2. Once you start execution of the plan, move as fast as possible to reduce likelihood of unforeseen events and also reduce costs increases due to inflation, interest paid on capital etc.

[0] https://www.goodreads.com/book/show/61327449-how-big-things-...

[huijzer]

Yes I have to second that. MLJ.jl is also written by a mathematician and the API is excellent. Truly well thought-out.

(If you think “why does MLJ.jl have so few stars?” please keep in mind that this library was written for the Julia language and not for Python. I honestly don’t think the library is the cause of low popularity. Just wrong place wrong time.)

[ozim]

First you have to have smart people who will be able to foresee design issues.

That’s a bit uncharitable but following this line of thought - you also need those smart people to be confident and communicative.

[sevensor]

> however, that saying applies to war, politics, negotiations

It’s not even an argument against planning. You’d be a fool to go to war without a plan. The point of the saying is that you’d be a fool not to tear up your plan and start improvising as soon as it stops working.

[DidYaWipe]

I had to do this for a patent application, and likewise found it very useful for identifying holes in my thought process or simply forcing myself to do the functional design work up-front and completely.

It was also great for brainstorming about every feature and functional aspect you can imagine for your product, and making an effort to accommodate it in your design even if it's not MVP material.

[bayarearefugee]

> but not coding.

In my experience it applies to coding when you have any reliance on third party libraries or services and don't have an extensive amount of actual real world experience with that technology already.

[bryanrasmussen]

>Sure, everyone has a plan until you get punched in the mouth; however, that saying applies to war, politics, negotiations, but not coding.

hey, the EU just introduced this new regulation is the software version of getting punched in the mouth.

[lmm]

> Super tedious, but way better than using throwaway code. Not over-planning feels lazy to me now

How was it better? I think a lot of people plan precisely because it feels virtuous, but that's true regardless of whether it's effective or not.

[PittleyDunkin]

> Super tedious, but way better than using throwaway code. Not over-planning feels lazy to me now

Certain projects have too many unknowns to overplan and you need to collect data to construct the assumptions necessary to evaluate the approach.

[bravetraveler]

Man plans and executives laugh

[softwaredoug]

I agree writing is beneficial. But I also find this works with coding. And they go hand in hand for exploring in my experience.

And in the end a good PR has a lot of writing too and has this effect. IMO this sort of well documented draft PR serves as a better design proposal because pure writing causes you to forget important constraints you only remember when you’re in the code.

[__MatrixMan__]

Agreed. You can write prose or implementations or tests beforehand and I don't think it matters too much which you choose, just as long as you give yourself a phase 2 for incorporating the learning you did in phase 1 and put a reality check of some kind in between them.

The only problem with having the draft being implementation is that maybe you'll get pressured into shipping the draft.

[patrickmay]

"Writing is nature's way of letting you know how sloppy your thinking is." -- Dick Guindon