<Blank> Driven Development
Published 📅: ....
Last modified 📝: ....
Location 📍: Boston, MA
Share this status update on BlueskySee discussion on Bluesky
I've been collecting a personal note of various "____ Driven Development" patterns, I figured I'd share them here to help others adopt them!
Hint - I don't actually strongly recommend some of these patterns 🤣
- Domain (name) Driven Development
- Buying a domain name to motivate you to actually build something
- Rarely ever works
- Meme Driven Development
- "Building it for the meme"
- Readme Driven Development
- Outlining how the thing should work in the readme, and then implementing it from there
- May actually work really well
- CI Driven Development
- Slinging code changes to remote to see if the CI passes or fails
- It usually fails at least couple of times, don't worry about trying to find the root issue locally, just keep pushing changes!
Tags:
Bluesky Post and Comments:
Loading comments...
Related Posts
micropost
Published: ....
Published: ....
Published: ....
Published: ....
Published: ....
Published: ....
Published: ....
Leveraging service monitors properly to improve service observability.
Published: ....
It's fine for a library to express some opinions about how it should be adopted and how the overall workflow/application in which it is adopted should function. However, it's false advertising to say that it is unopinionated.
Published: ....
No I don't mean those Milano cookies you keep taking from the office snack wall either (although you should probably stop snacking on those as often as well).
Published: ....
Low/no process workflow wasn't actually no process, it was only an "invisible" process. An implicit contract with everyone on the team to do that async workflow on their own time.
