My approach to building large technical projects
mitchellh.com
My approach to building large technical projects
1–10 of 29 posts
Re: My approach to building large technical projects
#2Being 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 to do the thing for long enough to generate big ROI.
Optimize for something usable. Go one step at a time. If you get discouraged or lose motivation it's game over, you gotta prevent that at all costs.
Re: My approach to building large technical projects
#3Note 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.
Re: My approach to building large technical projects
#4Note 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.
Describes basically all of my large technical personal projects. Definitely the happiest I have ever been writing code and building things.
Re: My approach to building large technical projects
#5Note 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.
My impression is that the article's advice is more fundamental than all of that (e.g. it could just as easily apply to personal passion projects), yet can easily be integrated with it (e.g. iterative work->demo->feedback phases).
Re: My approach to building large technical projects
#6Note 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.
He mentions something far better: getting the product into the hands of users ASAP so you can iterate on it.
Re: My approach to building large technical projects
#7Note 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.
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 “eat healthy and exercise” of business: Everyone knows they should do it, yet few actually do.
Re: My approach to building large technical projects
#8Cool that he's still writing code. Not sure I would if I became a billionaire.
Re: My approach to building large technical projects
#9Note 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.
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…
It's not like the users know what they really want though. You talk to a bunch of Salesforce users and they'll tell you that what they want is Salesforce+. This may not be what you want to be building as your product.
Re: My approach to building large technical projects
#10Earlier 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…
It's not like the users know what they really want though. You talk to a bunch of Salesforce users and they'll tell you that what they want is Salesforce+. This may not be what you want to be building as your product.
Base on my experience (product leadership role) when talking to customers it's most important to focus on their problems and challenges. They will obviously suggest solutions but you will want to be super careful with following these - think your Salesforce+ or the famous "faster horse".