ESSAYS, HOW-TO ARTICLES, AND GENERAL MAKERY BY BRUCE ALDERSON.
I was looking at buying a set of PFEIL carving tools this year, but was holding off as they're pretty pricy. I expanded my search a bit and found a similar set from a local Canadian company, Lee Valley Tools. They're hardened steel with a comfortable wooden handle. They sharpen easily (and keep their edge well), and feel like they will last a lifetime. They're also ⅓ the price of the PFEIL tools.
When my sketchbook is stale and I'm not feeling inspired, I look to pop culture for inspiration and ideas. I'm also a fan of other artists, and channeling some of their works through my own hands is immensely satisfying. It's an exercise that pushes you to analyze and rethink a thing that's interesting to me, and I always end up learning or discovering something new in the process.
A Super Mario Star (single colour, carved in EZ Cut)
No Face (2 colour, Quick Kut)
Jake the Dog and Lady Raincorn (single colour, Quick Kut)
Tortoro (single gradient, EZ Cut)
One of my favourite reads is Kottke.org, a blog by Jason Kottke. Calling it a blog is a bit of a slight: it's more of a magazine, like a proto-New Yorker. It's thoughtful and relevant, weaving current events, artsy things, various interesting edges of tech, and topics about general humanity.
Kottke has been killing it since '98, about as long as WarpedVisions has been around (though Kottke is better in every way). One of his regular columns is his Media Diet, a post I look forward to reading whenever it appears. There is something great about seeing someone else's obsessions and indulgences: there's a bunch to learn and inspiration to be had. So I'm in, here is the best of my media diet from this dank Vancouver Winter.
Books and other things in print. I don't read as many real books and magazines as I used to. Much of the good stuff has moved online, though there is a bit of a void for great fiction and ridiculously deep reference on the web. When I do sit down with a great book, it's an event, with headphones, a glass of wine, and is one of those things that makes the muse happy.
I spent a weekend re-reading The Short Stories of Ray Bradbury, while buried in my back catalog of Zeppelin, Queen, and other 70s greats. I read most of these stories as a child, as there were so many Bradbury collections at the time. His writing evokes memories of the early days of home computing and popular science, even though they were mostly written a generation before my childhood. The book is a meaty 1100+ pages and beautifully bound. While my original hardcover is pretty worn, it's one of the coolest things in my collection.
I bought myself The Flavour Bible over the Winter break. This book was perfect for where I'm at in the kitchen: it fits somewhere between an encyclopedia and thesaurus for how food pairs, relates, and what it all means to various cuisines and cultures. It's exhaustive and somewhat exhausting to read, but one of the most important references I've seen for food, ever. It's also full of tidbits and quotes from chefs from around the world, including Vancouver's own Vikram Vij.
Lucky Peach ceased publication with their Fall double issue. The magazine was a collaborative effort between chefs David Chang and Peter Meehan (initially published by the great McSweeney’s, later going solo). It was a sort of Wired Magazine for food: weird, wondrous, and fantastically laid out. I re-read my last few years of the magazine on a snowy Saturday with some mixed beverages.
Essays and long reads. Most of my media diet these days can be found online. Until recently, I wasn't sure what I thought about the shift. I've made peace with it, even though publishing and typography in the browser are still in their early evolutions. The writing is there, and the rest is improving steadily.
The Wire, 10 years on plays on the nostalgia for one of the best shows in history. It succeeds, too, as I want to re-watch The Wire again.
The Lottery Hackers is one of those Huffington Post essays that gives me hope for long form writing on the web. It covers the incredible story of Jerry and Marge and their epic lotto hack, in a way that feels like the writing in Wired Magazine from the 90s. It's worth the time to read, and (I hope) is a sign of how great magazines can exist on the web.
Does Recovery Kill Great Writing? is a story of addiction and creativity. I have a soft spot for stories about addicts and their struggle, and the question of how it affects the creative process is crucial to helping people out from under their monsters. The NYT is another example of how great writing and publishing can exist on the web. There is hope.
Speaking of Wired Magazine from the 90s ... The Curse of Xanadu is one of the great essays of their print magazine. It follows the story of Ted Nelson (who is also interviewed in Lo and Behold below), a pioneer in computing as well as a sort of philosopher of tech. The essay follows the frustrating path of his vision for better ways to structure information, and how even a brilliant vision isn't enough to ship working software. And to think that it's another 20 years later should be enough to break any software developer's heart (if they have one).
One of the things the web brings us that didn't exist much in print is the whole teardown phenomena. Ken Rockwell (the somewhat cantankerous photography pundit) does a thorough analysis of the new Apple Lightning Adapter Audio Quality. I can't vouch for the accuracy here, but the analysis made me smile, as I love to see people dive into the details and talk about it.
For a more complete list of (most of) the essays I read, you can follow my Instapaper feed.
Streaming movies and series. I don't see many new movies these days, or at least when I do it's from the comfort of my living room. It's not that I don't like the theatre, rather I think that a great movie deserves to be savoured and repeated (and why pay for it more than once?). Streaming is an amazing shift in consumption, as great media can be binged and repeated as often as desired. This is mostly good, I think.
Blade Runner 2049 was a beautiful film. It stitched together dreamy visuals with a relaxed story that was interesting enough. I've only seen it once, so I won't rate the story further, except to say that I think it's worth a watch for the visuals alone.
Edgar Wright's Baby Driver was a clockwork movie, pushing the art of heist movies to a new level. I have to admit the music wasn't quite my jam, but the movie is so well constructed that it didn't really matter. I saw it twice, hoping I'd enjoy the story a bit more, but in the end the details, the beats, and the timing are enough to make this well worth watching.
Burnt is a slightly slower paced Chef, telling the story of an obsessive chef's quest for his third Michelin star. The movie is much better than its ratings, though it lacks some of the quirk and redemption of Favreau's Chef. The photography is superb, showing the exacting beauty that is possible in a well run kitchen. There's inspiration to be found in Burnt, so I strongly recommend it for a quiet Sunday afternoon.
Shameless is a dark comedy based on Paul Abbott's Shameless (originally on Channel 4). Shameless (US) is directed by John Wells, famous for his work on ER, The West Wing, Trinity, and more recently Burnt (see above). I found Shameless the best dark drama comedy since Californication and Weeds. Shut up and watch it already.
Queer Eye is a surprisingly adorable “reality” show. It will make you smile and is best watched with a glass of wine and your SO. You'll learn something, you'll smile, and you may even ~no-I'm-not-crying-shut-up-there's-something-in-my-eye~ enjoy it.
The best thing I've seen in years appeared on Netflix last month: Ugly Delicious. It's David Chang's new docu-series, a sort of Lucky Peach meets Mind of a Chef. It is the perfect way to get excited about food, travel, and film. And while I've seen a few critical reviews complaining about the underlying agenda of the series (that Asian food is awesome), I felt it was more about Chang's journey of realizing that truth for himself. The series has inspired me more than Lucky Peach, to both eat and cook more, as well as to travel and look at film as an important path to inspiration.
Lo and Behold, Reveries of the Connected World (Netflix). Werner Herzog tells a story in a series of interviews with technology and philosophy greats of the 20th century, covering topics around the impact of the huge leaps of the last several decades: things like the internet (and ridiculous IoT), AI, robotics, and where they intersect with humanity. It's an important exploration intended to make us pause and to think a bit more about what and why we're creating these things.
It's interesting to me that WarpedVisions started as a very raw link log in the 90s, and that it's really part of what it should have been all along. Sometimes it takes those persistent and successful peers to remind us of that.
A coworker was asking me what I used for linocut, so I made a chart of the blocks on my desk. There are several types of blocks that I don't have in my supplies (like mounted block and clear blocks), but the ones I use are a pretty common set of hobbyist materials.
Occasionally I like to sketch and carve things around our lemony brand. It's fun to think sideways around our polished brand marks, dreaming in colour and texture. These prints don't represent anything we would ever use, but the exercise was a good stretch for me (and good practice).
This is a second print of the plate with an attempt at layering a textural plate over top. I still need to work on this technique, but I do like the extra texture it adds to a print.
2017 was a good year for JavaScript. The newer language features are now part of our daily routine. Tightly integrated CI and packaging scripts are the norm, and we have a huge sea of libraries and tools available to us. The core JavaScript frameworks have settled down and matured to the point that we can be confident in JS as the base for large-scale commercial projects.
Here are a few of the main JavaScript things that impressed me this year:
GraphQL for Node.js is the most exciting library of 2017. GraphQL (the QL stands for query language) is a natural evolution of APIs: it makes it easier to ask a web service questions without having to work as hard for the answers. While RESTful APIs provided a clean way to publish and present data, building APIs based on static object definitions force a lot of work on the things that need the data, which is wasteful and complex (as you end up with much more data than you need). And while including the concept of server-side queries isn't new to APIs, GraphQL does it with a simple syntax that fits nicely into the JS world.
React had a great year as well, with a major feature release and some sweeping licensing changes. I think the combination of these changes and the vitality of the React ecosystem have pushed it well past AngularJS this year. Redux has gained a bunch of ground over Flux this year too, though Facebook could undo that in 2018 with their partial-kinda-sort-of replacement QL/Flux hybrid Relay. The next version of React Fiber has already landed in v16 and will be core to significant improvements to React applications in 2018.
One of the ways to gauge the success of a UI framework is in what gets built with it. This Fall I found a solid spreadsheet component. I've also been using SemanticUI and its React bindings, though I am a bit worried about their slow pace of updates. There are a few commercial UI kits, like ExtReact and Webix that have some legs, though I'd love a richer open kit that we could all contribute to.
I've worked to improve how we develop software this year with things like deeper CI, better Lint and formatting tools, and better practices. In our quest for improvement, I found Prettier, a JavaScript code formatter that is pretty smart about line lengths and readable code. You can use it in your build scripts, CI, or your favourite editor.
Speaking of editors, I switched to Visual Studio Code this year, which is built on Electron (Node, Chromium, and V8). VSC replaces both Atom and Sublime, as well as my older favs Coda and Espresso. Visual Studio Code plays well with all of the recent linters, CI, build tools, and other gizmos. It performs well for coding tasks in JS and the various web formats I use regularly. When I work with larger text files, however, I'll still switch to the Vim of Mac (TextMate), or actual Vim (though I'm getting pretty rusty with that these days).
There was a time when I couldn't imagine Microsoft as a leader in OSS or web tech, but they've found their mojo with VSC and have a steady release cadence that's downright impressive.
One of the best things about JavaScript in 2017 was the huge selection of mature and featureful libraries.
Formatting dates in JavaScript, for example, has always been a bit of a pain, but libraries like date-fns make it a breeze. Similarly, CLI apps have always felt a bit clunky to build with NodeJS, but I found that by using Ink, a React-like library and components for CLI apps, I write a lot less fiddly console.log() code. Ink also makes it easy to write more complex CLI tools, which could be especially good for the ecosystem.
In terms of packaging tools, I haven't sided on a single bundler this year. That said, I do find webpack easy to set up and use. It's one of the current generation of build tools, and has simpler, clearer configuration than its predecessors. ParcelJS is on my radar as a simpler way to bundle JS applications, but I haven't had a chance to use it on anything big yet.
And while there are too many JS libraries to mention, the exciting thing is that there are huge communities and tools for recommending great libraries, like MicroJS and JavaScript weekly.
Storybook is one of those unexpected tools: it's a mature UI builder for ReactJS, that feels about the way a UI builder should feel these days. I didn't find myself getting lost in a tonne of automated code generation (i.e., it felt surprisingly lightweight). I haven't used it in production yet, but I'm looking for ways to make it part of my prototype toolchain for early 2018.
And finally: as JS matures past ES6 and ES7, the language is getting easier to teach (and learn). Here are some resources to help you learn more about the evolution of JavaScript:
this in JavaScriptSome of my most productive business tools are the simplest. Take the triage board. It's a whiteboard that hangs over my desk that has a list of my current projects, with magnets marking what I'm working on next. Weekly I erase the board and re-prioritize my projects, and daily I scribble notes and move the magnets as I work.
These concrete tools are about focus, flexibility, and the least amount of investment possible. It's critical to work on the most important things, and important to know what's next. Seeing the list of clients and projects helps me understand where I stand in terms of bandwidth too, using the simple, physical limits of the size of the board and legibility of my writing at smaller sizes.
I also use other real world hardware and the occasional piece software for other aspects of the business of software, but the board is big, and bold, and in my face.
I also use PostIt notes for lists of tasks that need to be done next. The notes stick to the whiteboard beside projects, so I can rotate work around. These are not detailed notes or TODOs, rather they are lists of key tasks that need to be done next, as well as notes from conversations and discussions related to the project.
When detail notations are required, I rely on formal specifications, issue tracking, and project management tools. These are the endpoints of the process, rather than the crux. This allows me to use tools that fit the job rather than forcing all problems into a single method.
What I've found is that there are a few simple principles that are critical for small business tools and processes.
I've seem businesses spend disproportionate amount of their profits on automation tools, processes, and other organizational objectives on systems that failed to deliver.
A set of tools should be grossly pragmatic, vastly improving profitability and quality. Anything less is irresponsible to the business and the businesses purpose.
#Software Engineering
“A common example is process as proxy. Good process serves you so you > can serve customers. But if you're not watchful, the process can > become the thing. This can happen very easily in large organizations. > The process becomes the proxy for the result you want. You stop > looking at outcomes and just make sure you're doing the process right. > Gulp.” (Jeff Bezos)
This is a quote from a Jeff Bezos letter to the board, talking about internal metrics and improvements. Sometimes when you add a process to a problem, the process can become the focus and not the outcome.
In PM land we use tools and techniques like burn down charts, sprints, and spikes. You can get obsessed over getting these things right, and fail to ship effective, quality software. The special language used in and around these processes adds to the problem too, as the language ends up feeling like an accomplishment in itself. Too much focus on the pomp and circumstance of a process takes away from actually building great software.
e.g., Let's put a pin in this ...
The real value isn't in the process or lingo, it's in doing things better and making better software within profitable budgets. It's something that's been rolling around my head for a while, and Bezos describes it nicely.
I was talking about basic project management principles with a friend the other day, when I came across this Bezos quote. It sparked a discussion about software development processes, including hitting a few topics that I think are especially distracting in software development.
Yes, these are fairly common software management tools now, and I use some aspects of them. Now of course we don't say “spike” ever, or “tent pole”, but we do plan sprints of flexible durations, and we're always aiming for minimum viable steps and frequent releases.
I think it's a common mistake to set fixed durations with sprints, as it can shift the focus to succeeding at the sprint versus shipping something viable (i.e., both useful in the short and medium term). It can really deflate the team if sprint durations make no sense, as developers pick up on goals that aren't about useful or quality software.
Fixed duration sprints can also force poor decisions, as your primary goal is time and not the other factors important to software. If you relax your use of sprints a bit, you can pick sprint times that fit the underlying problem better. The real goal with sprints is to focus on scoping the project, and improving the overall tempo of development. Sprints shouldn't be truncating quality for minimum viability, nor should they be pushing teams to burnout faster. Really, all we want from sprints is a framework to keep us focused on the right features and a strong speed of development.
No, it shouldn't.
This is a great question. My friend is coming from another domain, specifically small-scale custom manufacturing. He's not fully familiar with software development terminology (though he's vaguely familiar with how software is generally developed). Conversations like this are a great reminder that the language we've developed in this industry is insular, even though it is based on what we think are clear metaphors. When you think about if from an outsider's perspective, you can see how arbitrary the language is, and how the imagery doesn't fit perfectly.
This is especially true with terms like sprint. You can't literally sprint all of the time, as it suggests expending the maximum amount of energy over short distances. Software projects are anything but short, and the idea of sprinting through the entire thing is absurd. The PM concept of sprints doesn't match the real world use of the term very well.
A sprint is like a focused mini project. To some degree, it's like having a personal trainer guide your workouts and push you a bit. The idea is to use the mechanism to help you push to a clear goal.
More traditional PM structures projects as very long, boring wanderings through the desert. Waterfall projects, for example, don't produce workable software until much later in the process.
We might say, “we're authorizing blanket overtime” which tells the > guys we need as much effort as we can get right now. There are some > tasks on the shop floor which simply can't be done faster, so we > would add more hours. Or worst case a second shift. There's huge > inefficiency in adding a second team.
That is a common manufacturing practice for increasing bandwidth, but sprints aren't only about increasing output (though the term strongly suggests that). A sprint is more like setting up a smaller shop, with a special, focused project.
Ahhh. We would job things out to other manufacturers ...
That's not quite it either, though I do find using sprints for special ops is especially useful, as you push the focus of the tool to problems that need special focus.
The concept of project sprints was really to make things feel more focused and tactical. It was a backlash on the traditional waterfall planning (i.e., requirements, design, implementation, and testing).
But after using sprints a bunch, they can become empty words for traditional project management things. The trick is really to keep sprint projects focused on smaller, but useful deliveries.
Sprints really just become project phases like those in the waterfall model, except that you've organized the deliveries differently. You try to partition design into things you can deliver on shorter intervals, rather than aiming to deliver one giant thing at the end. There is a huge advantage to delivering these small and useful pieces early on, as you learn a lot about what works (and doesn't) well before the end of it all.
I was saying earlier that the concept of sprinting suggests running fast, which if you think about it is so expensive in terms of long-term motivation and energy. It's an odd side-effect of the name itself, as running fast isn't part of the definition of a software sprint, yet the term implies it so strongly.
There's this pattern of making special languages for our formal processes, based on the ways we approach building software. It's difficult to find ways to describe processes that don't eventually become ideology or warped in some way. The simple act of naming the parts can change how we think of them, if we lose focus on the real goals.
I can't think of an analogue in manufacturing ...
It eventually boils down to the same set of problems as with projects in any industry. I've seen special-ops style projects in manufacturing before:
One re-manufacturing mill I worked with started a finger-joint mill. They took their best staff and had them design and built the new plant in stages, apart from their traditional management techniques. They split the work into smaller chunks, and had something up and running early.
Ahh, I see!
They treated it like a special thing, which helped them escape their traditional planning techniques.
Of course sprints aren't really just special-ops anymore, but that's where the concept started from. We used to say “Let's push hard and get this out by next week”. We used this push mindset well before Agile methodologies were well-defined, and sprints were really an extension of that.
Yeah we did that too, but I guess we were so unfocused that it was > normal to work on random projects.
In the end it's just different words for the same things. The mindset of making projects smaller and focusing them on early and useful releases is the best part of sprints. The concept of isolating design to reduce scope is also great.
Really, sprints cut across the grain of the old waterfall style planning, repackaging a lot of the risk to earlier deliverables. It really only works if your sprints produce production quality deliverables though, which is why it's so important to avoid serving the process over the goal of building something incredible.
Sprints are a good example of allowing the process to become the focus, instead of obsessing over what you're making. This is what frustrates me the most about software development methodologies: when great concepts become ideology and the underlying intent is lost. You start spewing the bullshit terms without even thinking. They become bullshit when the term is the focus, rather than the outcome.
e.g., Let's spike this feature for the next sprint.
Or, Our sprints are only 1 week, so that story is too much for us right now ...
It's disingenuous to use these words all the time. It allows a lot of passive-aggressive behaviour too, as you can use the noble act of following the process as a way to beat down legitimate concerns about what customers or the business needs.
What I see happen is that smart people can control production and planning by using the process language in clever ways. Arguing things for the sake of process can be a sign of that problem, i.e., elevating the process above the intent.
The problem isn't in the process, however, it's just a reminder that it's easy to focus on the wrong goal. Sticking to your process is often a much clearer path than figuring out what your users really need, or how to design that thing in such a way that it's a viable business. And because the process can be easier to succeed at, it becomes an easy target for people on a career path.
As software leaders we just need to remind our people to apply the process and tools for the outcome. We want to build useful things for our fans and users, and we want these projects to serve the needs of the business. The processes and methodologies are just tools to this end, and not the end itself.
Sometime over the last year I stopped paying attention to Twitter. Between the political cacophony of 2016 and a growing list of people I was following, the noise ratio was just too poor to hold my interest. Twitter had become like LinkedIn to me, a service I used to have a professional presence, but not one that inspired or taught me anything. I had given up.
A friend recently challenged me to find the interesting in Twitter again. He suggested declaring bankruptcy and starting over. While I liked his suggestion, I decided to apply another minimalist principle to my feed. Instead, I've been scrutinizing the people I follow looking for the “spark of joy” in what they post, things that make me grin, things that inspire me, or things that challenge me in some way. Anything that's disingenuous, caustic (for no reason), or just consistently unintelligent can go.
Every week or so I read a few hundred Twitter posts and un-follow things that don't have that spark. Slowly, my feed has improved. It's almost at the point now that I'm consistently seeing interesting things.
I've found a few patterns in how people use Twitter, things that just tend not to work or be interesting.
There are also a few hints in the body of what people post that affect how I feel about them:
There are a few details that make people stand out on Twitter, things like:
It's amazing what a bit of whitespace can do to a Twitter post, even though not all clients show it. A small amount of attention to detail shows that an author cares (and is knowledgable).
The best thing about cleaning out who I follow is that I've re-discovered some really interesting people, who write things that change how I think. It also has me weighing what I post more carefully, as Twitter doesn't really allow you to demote or segregate content well. For what it's worth, some basic categorization for feeds would allow for people to segment their streams a bit, allowing followers some choice of what aspect of a person you read about.
I made a quick print this weekend based on a few drawings I was working on last week. The idea was to make a block print look like a sketch, and to use background lines as a textural element.
