Tim Ewald - Clojure: Programming with Hand Tools

Good article! Two things popped into my head when reading it. First the talk "Programming with Hand Tools" by Tim Edwald[0]. It's a very cool, entertaining talk with emphasis on the craftsmanship side of things and provokes thinking about which parts to automate (or maybe abstract away) and which parts to craft by hand when we're building stuff. Aside: also reminds me of Casey Muratori's Handmade Hero project [1]. He is a strong advocate for structuring things bottom up and building them ourselves. [0] [this video] [1] [link] --- Secondly when reading this: > Regardless, the basic idea is that companies are often faced with the decision of doing N units of shitty work or far fewer than N units of great work. This is obviously oversimplified, but there is an important point that wants to emerge from this line of thought. As someone who grew up on open source, standardized technologies and the Web, I have been empowered to build a livelihood on Web development, mostly "self-taught" (or rather self-directed). All of this Web stuff is very accessible and gives you actual _leverage_. You can build something useful very quickly and the community around it is happy to share so much knowledge and work. I'm _very_ thankful for that. But I think as the wider web development community we're losing sight of what that essence is. We started to think of the Web as merely a vehicle for pure scale as in "how to reach the most people and annoy them with notifications" and "how to produce cheap sof

Time Ewald makes a case for "Programming with Hand Tools" in this talk he gave at Clojure/conj 2013. He too makes a connection with wood working. [this video] Summary: For most of human history, furniture was built by hand using a small set of simple tools. This approach connects you in a profoundly direct way to the work, your effort to the result. This changed with the rise of machine tools, which made production more efficient but also altered what's made and how we think about making it in in a profound way. This talk explores the effects of automation on our work, which is as relevant to software as it is to furniture, especially now that once again, with Clojure, we are building things using a small set of simple tools.

It's funny, even as someone who knows js really well, having worked with it for a decade (actually, longer!), the explosion in the ecosystem took me by surprise. I left my web agency role over a year ago to work on my start up with a friend so I've been in relative developmental isolation (lots of python and js, not so much keeping up with the latest trends). I came back to help out on a project recently and had to spend a day researching all the new tools. Particularly around package management, bower, grunt, yeoman, node, npm etc. A year ago a js lib was generally delivered as a js or min.js file. Now there's the whole system to sit around it; every project on github now seems to include the config for each of the different package managers. Even a vagrant file so you can get it all up and running on a brand new vm. Something as simple as adding bootstrap to a project. It's not totally obvious when you first look at it. Where does the code go? How do you compile it in such a way that you don't touch the vendor src itself but you can customise it etc. I have a method that works for me, but I had to play around a little to figure out how to fit it to my needs. Once I got through that stage I was really happy with where things were at. JS libs are nice and easy to install and version control now, dependency management with bower has worked really well for me so far. Grunt makes the automation side of development nice, contained and easily shared. All in all it's a really good

The "wat" is a good first step in identifying problems. However, I see is people getting stuck on "wat" and not moving forward. People would rather win an argument than advance knowledge & the practice. Lot's of ego, programmers have. In the mean time, one can learn to appreciate & use javascript strengths. It can be quite fun, liberating, & useful. Anecdotally, I have not run into these crazy issues, and I program in javascript everyday. I also have a large app and the framework I built is custom. I liken this to using C++, Unix, & bash as a base. Yes, you could say these tools suck and spend time creating, marketing, & community-building for a new tool. Or you can iterate & improve upon these existing tools. There's no wrong answer. What do you want to accomplish? > Sushi knives don't decide to cut you because the rice came from a different origin. That analogy seems like a stretch. Care to explain? Javascript works with different locales. There are many international websites that use javascript. Also, javascript does not "decide" to create a bug in your program. You create that bug by misusing the tool. You will get further if you take some responsibility and improve your practice. > And I'd guess that most craftsmen, outside of a ritual and tradition would love for their tools to have less disadvantages. I agree with that. Usually the improvements are iterative. One could use a laser cutter (which does not need sharpening) to cut sushi, but that would also burn it. Here'