This post serves as a permalink to accompany my talk from EmberConf 2021. Mho The demo of the service-worker-based build tool is available here [https://github.com/ef4/mho] with instructions to run both the prebuilt binary (currently compiled only for OSX, sorry!) as well as how to rebuild everything
When Google set out to measure what makes their best software development teams successful, they found a strong correlation with psychological safety [https://www.nytimes.com/2016/02/28/magazine/what-google-learned-from-its-quest-to-build-the-perfect-team.html] : > A shared belief held by members of a team that the team is safe for interpersonal risk-taking.
> “A lot of beginners under-appreciate the degree to which googling things is part of a programmer’s job,” says @steveklabnik [https://twitter.com/steveklabnik] #wednesdaywisdom [https://twitter.com/hashtag/wednesdaywisdom?src=hash] pic.twitter.com/FnXo3rBfPb [https://t.co/FnXo3rBfPb] — Glitch (@glitch) May 31, 2017 [https://twitter.com/glitch/
Lots of software projects struggle when they try to implement search-related features. I was reminded of this by @trek's [https://twitter.com/trek] reaction to this Algolia [https://www.algolia.com] marketing tweet: > Development teams often delay building search due to lack of confidence in getting it
There is a strain of thought in the web development community that believes there's a tension between having comprehensive developer tools and delivering good user experiences: This is exactly backwards. At the scale of the entire web, better tools are the only way to deliver better experiences. The
There are two very different kinds of simplicity in software engineering: simple interfaces and simple implementations. Simple interfaces are absolutely critical, because the budget for interface complexity is paid out of your head. But simple implementations are far less important. The budget for implementation complexity is paid out of an
An inflammatory anti-Rails post [http://solnic.eu/2016/05/22/my-time-with-rails-is-up.html] has been getting lots of discussion lately. The author's frustrations are legitimate, but his articulation of the problem takes an absurd turn: > The really challenging part in this discussion is being able to explain that
Drupal [https://www.drupal.org] project lead Dries Buytaert recently launched a community discussion by asking "should we decouple Drupal with a client-side framework? [http://buytaert.net/should-we-decouple-drupal-with-a-client-side-framework]". My high-level takeaway from the discussion is that the Drupal community is serious about finding shared solutions to common problems.