My one word of caution here is that it's often hard to fully understand a problem before you roll up your sleeves and start writing some code. IMO, the quickest way to come up with a solution is often to come up with a wrong solution first, then throw it away. Similar to how we build prototypes to come up with product/ux solutions.
In my experience, the longer I spend thinking about a problem before I take any action, the more paralyzed I become. Code is never perfect, it's always going to need to change. Sure, try to minimize the amount of fundamental changes you're going to need to make, but in the end I think simplicity is your best bet against future pain. Margaret On Tue, Apr 19, 2016 at 8:05 PM, Richard Newman <rnew...@mozilla.com> wrote: > This is Rich Hickey, the creator of Clojure, which is right up there as > one of the best-thought-through pieces of software I've ever seen. > > If you haven't read through Clojure's approach to managing mutable state, > it's worth the time. > > http://clojure.org/about/state > > and also its particular set of tradeoffs, particularly being a JVM-hosted > language: > > http://clojure.org/about/rationale > > > > On Tue, Apr 19, 2016 at 4:44 PM, Michael Comella < > michael.l.come...@gmail.com> wrote: > >> Hey friends! >> >> Today, I sent Sebastian a talk that's made me rethink my development >> style and I realized I should open it up to a wider audience: >> >> https://www.youtube.com/watch?v=f84n5oFoZBc >> >> Note: it's development-centric, but not development-specific. >> >> The presenter provides an explicit problem solving strategy to take when >> solving hard problems and provides some important questions to ask – e.g. >> what are the facts surrounding the problem? What are the constraints? What >> don't you know yet? Even if you disagree with the approach of the >> presenter, I think it's beneficial to have an explicit problem-solving >> strategy. >> >> In this or another talk, the presenter mentions that he feels many bugs >> come from having a poor-conception of the problem. After applying an >> explicit strategy to problem solving, it's been insightful to have a better >> concept of what I'm building before I start trying to build it and >> (granted, it's still with a small sample size) I feel it's produced better >> code with fewer bugs. >> >> Here are some notes on the talk [1] but it's unclear how helpful they are >> without watching the video. Personally, I've copied this document, >> simplified it, and have been adapting it for what approach what works for >> me. >> >> Enjoy! >> - Mike (:mcomella) >> >> [1]: http://willchen.me/hammock-driven-development >> >> _______________________________________________ >> mobile-firefox-dev mailing list >> mobile-firefox-dev@mozilla.org >> https://mail.mozilla.org/listinfo/mobile-firefox-dev >> >> > > _______________________________________________ > mobile-firefox-dev mailing list > mobile-firefox-dev@mozilla.org > https://mail.mozilla.org/listinfo/mobile-firefox-dev > >
_______________________________________________ mobile-firefox-dev mailing list mobile-firefox-dev@mozilla.org https://mail.mozilla.org/listinfo/mobile-firefox-dev
