It’s been a couple of month since I built woodspotting.com. It grew out of the frustration of current RSS readers, and the tiresome aspect of opening 20+ woodworking blogs to see if they had new content. Today, the site tracks more than 100+ woodworking blogs, and hopefuly sends some more traffic to the blog authors and encourages them to keep posting fresh content. It also saves me a lot of time :)
Today, I made a change to make the site a bit more visual with a running ticker of thumbnail images from the blogs that’ll link back to the original site of the author’s. I’ll be making tweeks over the next few weeks, and hope folks like it.
Over the last year as I’ve dived into woodworking, I’ve discovered an overwhelming number of inspiring, entertaining, and beautiful woodworking blogs. Most are by hobbyists as an act of love, and sometimes they seem to whither with the authors wondering if anyones is reading or enjoying their documented journey.
As a software developer, keeping track of bookmarks, and not finding RSS readers up to par with most sites, I looked to Hacker News for inspiration. Using open source software, I made some changes and hope a reddit/HN site can help folks keep up to date to the best woodworking blogs out there and maybe even foster discussions. I call it Woodspotting and hope some of you have been searching for something like this as I have. If you are, please contribute and share :)
Writing the business logic component of software is one of the most harrowing parts of any project. Where a job queue is well defined, the monstrosity of a workflow that’s developed over a few decades in the back office of a cottage industry may lack any definition at all. From ill defined specs to ever changing exceptions to rules, business logic is the human modeling component of software with all the complexity it implies. I feel that the reason most business software sucks is that we software developers and managers keep underestimating this.
You can use all fashion of objected oriented design patterns or promising functional idioms, but at the end of the day you’re modeling human behavior and your assumptions will break, and you’ll have to change it.
The most painful part of changing business logic is first reading the code and understanding it. After a number of years, I’ve now learned that this is the part to optimize. Today, if I can look at business logic I wrote a month or year ago and understand it within a few minutes, I feel like I’ve succeeded.
Make your business logic the most simple, explicit, dumb, commented, unoptimized, least clever, configurable part of your software. Then, be joyful.
"It has often been the lot of craftspeople to be merely the ‘hands’, executing the plans and designs of others, and this is something I’ve brought up many times before on this blog - and railed against. What it boils down to, it seems to me, is to use one’s skill and knowledge to benefit the client, as it is not always the case that the client is intimately familiar with the technical details that can make or break a design, regardless of how attractive the design may appear to them. And some design ideas, regardless of aesthetics, are simply bad ideas, no two ways about it. One task of a craftsperson is to endeavor to educate their clients about the things which matter in terms of craftsmanship. It’s a case that needs to be made, though in practice it is not always an effective selling proposition. The hierarchy of needs with each client may mean that craftsmanship, sound building practice, wise use of materials, etc., can take a place several steps down their list of priorities. It’s not that those things aren’t important, it’s just that they may be invisible to the client and other things play larger in their minds. For me, those things are on the top of the list of what is important, and some projects must be turned down even if certain minimums cannot be met in a project, though saying ‘no’ can be hard to do in a lot of cases. Fortunately though, there is often some room for getting the critical details funded in most projects, if the matter is explained succinctly and persuasively. A craftsman-builder does no good service putting up a structure they know from the outset will have defects in its design that reduce the integrity and lifespan of a structure.”
The Carpentry Way, Chris Hall
Most software developers are familiar with Big-O/asymptotic notation. For those unfamiliar, it’s essentially a way to very roughly estimate how much time or space a piece of code (or algorithm) will take to complete a certain sized task (ex. alphabetizing the names of everyone you know). Even more to the point, it’s a way to help determine whether a piece of software will ever complete a job in a reasonable amount of time, or if one piece of code is more efficient than another. Big-O is a tape measure for algorithms.
Big-O, oddly enough, came to mind recently while I was struggling with a woodworking project. As a (very) novice woodworker, I was struggling with setting up my cuts and pieces at right angles. I was using a budget tri-square for the job, and even though it looked like 90 degrees, my projects never came quite together. My eyes couldn’t see it, but my fingers could feel the imprecise fits of joints and I could hear the wobble of the final piece on a flat surface. It was very frustrating because my intuition while building it was that my measurements were accurate enough, but my senses in the end were repeatedly told otherwise.
In software, many algorithms defy intuition in terms of their behavior when given non-trivial inputs. Big-O notation is one way to build an intuition on algorithmic performance and the limits to computation. It’s in fact one of the first things I was taught as a computer science student.
Software concurrency is another topic that at times seems to directly oppose one’s intuition. Whether I was fixing bugs in my own or someone else’s code, it always felt like wrestling with tremendous complexity that at times seemed to defy logic. Between race conditions and compiler optimization that led to non-deterministic behavior, I would at times question my own sanity. The solutions to these bugs usually ranged from ad hoc synchronization of data (not ideal) to more costly but cathartic refactoring of major parts of the code..
Concurrency and thread programming are usually taught in very academic or abstract terms, or in very elementary ways. Most developers usually begin to develop a real-world handle on it after several diseasters under their belt, and even then one can easily get rusty and revert to faulty practices without a solid intuition.
I think intuition for a specialized field can be learned in either an easy way or a hard way. With the growing importance of concurrent code, more can be done to help developers better internalize the nature of concurrency, exploit it more effectively, and avoid its many pitfalls without having to experience several disasters. There is need for innovation in this area.
(A couple good resources: Java concurrency in practice, and a list of talks by Rich Hickey)
Awesome images from the freely available classic book on woodworking using educational Slojd. I wish someone made a similar series of graphic panels for programming.