Books for software engineers and managers
Categories:
Favorite,
Tech Lead,
Star Engineer,
New Engineer
How strongly do I recommend Hackers & Painters?
8 / 10
Paul Graham’s writing is highly readable and he’s someone I’ve enjoyed reading for years. In Hackers & Makers, Graham describes hacking culture and programming languages.
Graham celebrates elegance and flexibility and pithy disdain for complexity, which might put some readers off but felt comfortable to me.
Our field has professionalized titles from Programmer to Developer and now Software Engineer. Under the surface, we still have hackers.
Hackers and painters are both makers.
As much as I embrace the Engineering mindset, I enjoy hacking just as much. You can in fact do both.
In software engineering, we call this lead time and the goal is to reduce lead time.
There is a certain pessimism and sadness about planned work. Rather than thinking about how to structure our environment to more quickly deliver value, we obsess about prioritization and backlogs.
Hacking can break through the backlog. In most software teams, hacking requires slack in your production system. Slack and hacking go hand in hand.
You’re a startup and your competitor is larger and better funded, with many more engineers. How do you decide what to build?
Imagine this problem as a staircase. Being larger and better resourced, your competitor can run downstairs just as fast. You don’t want to get into a step-by-step race to build easy features because they’ll catch you and eat you alive.
Instead, you want to run upstairs and use speed to your advantage. They can’t run upstairs without wheezing. Tackle the really difficult problems that size and bureaucracy prevent your competitor from even considering.
For Leonardo to exist as we know him, you need more than ability. You need Florence in 1450.
So it is with software and America, or more specifically tech hubs like San Francisco, Seattle, and Boston.
Graham writes about the design of powerful languages, those which hackers want to use. Notably, Graham strongly advocates for Lisp while also recognizing languages like Perl, Python, and Ruby.
But Graham’s ideas on language design are also applicable to library design.
jQuery immediately comes to mind – the library which younger programmers know as antiquated and older programmers remember as revolutionary.
jQuery was the first library I worked with where elegance and expressiveness was immediately obvious. What might require dozens or hundreds of lines of code in vanilla JavaScript could be accomplished in just a few lines of jQuery.