3 ms·
Author here. Fun to see this come up on HN again, every so often. Readme Driven Development still serves me well (that’s how we drove RedwoodJS early on) and we
by mojombo 6y ago
Author here. Fun to see this come up on HN again, every so often. Readme Driven Development still serves me well (that’s how we drove RedwoodJS early on) and we even expanded that into Tutorial Driven Development, where we wrote the RedwoodJS tutorial to show what we wanted to be possible from a DX perspective, and then figured out what code we needed to write to make it possible. It’s been an efficient way to focus on what’s important and not make usability sacrifices for the sake of easy coding. It’s really just the design-first approach, applied to a framework!
- snypox 6y agoGreat article. Btw, you’re the guy who invented TOML, right?
- clashmeifyoucan 6y agoyes, he is¹ [1] https://github.com/toml-lang/toml/blob/master/README.md#L8 https://github.com/toml-lang/toml/blob/master/README.md#L8
- zrkrlc 6y agoI like how TOML was the first thing that came to your mind and not 'co-founder of GitHub'.
- mojombo 6y agoTOML is my true legacy. =)
- deleted 6y ago[deleted]
- p1necone 6y agoUX is the only thing that matters, it just happens that the guts of your software have to do something correct and useful as one of the prerequisites to great UX. This is a great way to design software.
- mojombo 6y agoI think this is true for any specific moment, but as we are creatures of the 4th dimension, we must also care about how we change our code over time. When code complexity is managed, users can enjoy better versions of a piece of software more quickly and more often. If we let our code deteriorate into an inscrutable pile of tech debt, it will eventually affect the user experience, so the guts need to both do something correct (and useful) and also be amenable to change over time.
- frobisher 6y agoAbsolutely agree. At my workplace, we often have to balance immediate UX requirements with longer term reliability, extensibility and security.
- guinness74 6y agoGreat post, something I'll share with my team. Thanks.
- ishcheklein 6y agoThis is excellent! You put into words all those benefits I was trying to communicate a while ago (https://twitter.com/shcheklein/status/1325978612378423297 https://twitter.com/shcheklein/status/1325978612378423297) but didn't find the right term . Documentation is an overloaded term (means everything from readme to man pages) and I guess, that's why it makes it hard to explain DDD since a lot of engineers perceive it as something like `man` pages, or even doc strings.
- zhoujianfu 6y agoI like it. I try and design whatever I’m building from the user goals perspective (“user want to buy a ticket” “user wants to change a seat” “user wants a refund”), and I know from my perspective as a user I always hope the readme has been written more like a tutorial (a list of examples on how to do what I want... not a list of command line options!) This feels like a good way to combine both things!
- mmahemoff 6y agoReadme Driven Development must be working well because Redwood is the most exciting thing about web and API development right now. I've been working through the man tutorial and Redwood's the best attempt I've seen to bring the poweful principles behind Rails to Node and JAMStack.
- agumonkey 6y ago> Tutorial Driven Development I had a nickname for this: whishful thinking design
- davidwf 6y agoI missed this article in previous rounds, but during your interview with the Changelog regarding RedwoodJS I remembered the anecdote about "writing the tutorial first" and it really stuck with me. I find this especially useful when I'm building complete solutions from lots of other technologies -- it's easy to fall into the trap of "well my API will behave like API X because that's what I'm using under the hood". Readme driven development really encourages thinking harder and producing something that's greater than the sum of its parts.