21–29 of 29 posts
Note he doesn't mention a user story. Large technical projects apparently let you ignore what the user wants, use cases, dependencies, stakeholders, design reviews, feature changes. Instead you just decide what you want and wait to see if the user wants it too.
unlike the recent story of a developer trying to disrupt coffee delivery
The one caveat I'd add to this is to make sure to panic (throw an exception or assert false) at all unhandled edge cases in the good enough subcomponent. It's often easy to write conditionals for the happy path without a corresponding else for the unhappy path. You don't need to implement all branches initially, but you will likely be glad you added those panics, which have the bonus side effect of showing you exactly where the unhandled edge cases are, as you expand the sub-component to handle those edge cases.
> My goal with the early sub-projects isn't to build a finished sub-component, it is to build a good enough sub-component so I can move on to the next thing on the path to a demo. The one caveat I'd add to this is to make sure to panic (throw an exception or assert false) at all unhandled edge cases in the good enough subcomponent. It's often easy to write conditionals for the happy path without a corresponding else…
Getting deep into details/code when you aren't quite sure of your surroundings can be extremely dangerous for the health of a fledgling project.
How to Achieve Your Most Ambitious Goals | Stephen Duneier | TEDxTucson https://www.youtube.com/watch?v=TQMbvJNRpLE
Cool that he's still writing code. Not sure I would if I became a billionaire.
Note he doesn't mention a user story. Large technical projects apparently let you ignore what the user wants, use cases, dependencies, stakeholders, design reviews, feature changes. Instead you just decide what you want and wait to see if the user wants it too.
Two, he IS the user! His example is the terminal emulator he is writing for himself. He says to write something that you will use yourself, as a good way to generate your own interest and involvement in it. Also, it seems like good practice to write something for the user you probably have the best communication with!
I used some of these ideas to get over the hump on a project today. Just get the simplest thing going to give a useful result, and that helps break the log jam!
Being able to prioritize building projects like this is a skill in itself, and I think it's a really important one. People seem to chronically undervalue optimizing for shipping something. Mitchell does say "I don't talk about shipping", but shipping a demo for yourself is still shipping! It doesn't matter how good you are if you can't stick at something for a long period of time. You're probably not going to be able…
Definitely true. That's something my co-founder talks a lot about. If you just stick at it for a few months, projects get huge. It's incredible how much code gets written when you look 6-months back. If you had to look forward and try to guess, you'd never imagine this much would have happened.
Earlier quoted context omitted.
What users want and User stories (in the agile iterative software sense) are different things. At their best user stories represent problems to solve for the end user, but rarely have I been able trace back a user story to something that an end user actually wanted because nobody bothered to ask them. Not talking to customers is extremely common . Everyone’s just too busy, including the customer. It’s kind of the “ea…
> At their best user stories represent problems to solve for the end user, but rarely have I been able trace back a user story to something that an end user actually wanted because nobody bothered to ask them. This is such a universal problem in the industry. It's also the source of the endless reinvention cycles we go through. Everyone hates user stories now because no one actually does the other work involved - tal…
By the way, user stories are an iteration of that. I remember:
- when user stories were a novelty, everyone hated actors and use cases,
- when actors and use cases were a novelty, everyone hated functional requirements.