3 ms·
I hit upon a pretty simple process a couple decades ago and it seems to work pretty well and doesn't require any fancy books, titles, lingo, paradigms, papers,
by mkramlich 16y ago
I hit upon a pretty simple process a couple decades ago and it seems to work pretty well and doesn't require any fancy books, titles, lingo, paradigms, papers, etc.:
1. observe/listen/read/question/collect-information
2. think (analyze, hypothesize, decide, etc.)
3. code (techically it is 'do', and the actual action varies by field, context and goal)
4. goto 1
- newt 16y agoNice. What percentage unit test coverage do you generally get? How do you deal with regressions introduced by bug-fixes? With technical debt? With requirements change and scope creep? How much refactoring do you do? How big a team does this approach scale to?