So, on this day, Casey Muratori reiterates one of his central advises that we must just write the simplest thing that works first, and then let the code and the problem guide us into figuring out the design of the final program. This works wonderfully for him. And for me when I'm programming alone. However, at work I have often been asked to tell a bunch of people what to do in order to deliver a feature at the end of next sprint or the end of next 2 sprints. When this situation happens I find myself scrambling to come up with something that I can ask them to do which would add up to what is going to get shipped.
I have slowly worked myself out of being in such situations by constantly asking to be assigned big tasks that I work on alone. And I pass off any work that needs to be done by a group to other people who want to lead teams. I have made this choice to not become a programmer that leads a team and be held responsible for work that the team has to do. And this comes with the price that I can never reach certain positions (which I don't care about so its fine).
But, what if at my next job I can't get out of this kind of work and I have to still dole out pieces of work that I cannot first sit down and program on? How does one tackle the problem of being asked to design something out of thin air which will only be worked on once till it works for the first time and has to be shipped?
Even on a shipped piece of software, sometimes I will be asked to tell someone else "how to do it" and then they will do it so Im "free". However, again I find that only when I program it myself can I actually see the real solution. So, how can we not do design upfront when that is the thing that someone is asking us to do and expecting that design to be the correct thing?