We don’t know what we don’t know. Clearly. But, sometimes the keys to a project exist in the unknown. Yet many of our project planning and execution tools don’t take this into account. If you just do the same thing over and over again, you will probably get better at performing that sequence, but you won’t learn anything new. That’s a quote from “Introducing Deliberate Discovery” by Dan North 1. #
Hello. My name is Alex Kessinger. I'm a principal engineer @ Stitch Fix. I write about what I'm reading, researching, and thinking. Find me on twitter @voidfiles.
Welcome to my webpage.
There will be commit messages. Many. Of. Them. Your team will read them. Your boss will read them. Strangers will read them. You will read them. Future self is skeptical of present self. You owe it to everyone to try and write better commit messages. I’m not suggesting that I always do, it’s a lofty goal, but here is some help: Separate subject from body with a blank line Limit the subject line to 50 characters Capitalize the subject line Do not end the subject line with a period Use the imperative mood in the subject lineWrap the body at 72 characters Use the body to explain what and why vs. #
I am a fan of tests, but my testing journey was long and fraught. One of the hardest ideas for me to understand was where do you draw the line. How much is enough? I tried many different ways to understand this, but it wasn’t until I read this quote from Kent Beck that a key idea crystalized. I get paid for code that works, not for tests, so my philosophy is to test as little as possible to reach a given level of confidence 1 #
During the course of my work I find my self rubberbanding between two extremes - universal truth and exacting, excruciating detail at a specific moment in time. Those many not seem like they are on the same continuum, but that’s where todays suggesting reading comes into play: The Three Ways by Gene Kim 1. I’m a sucker for bit of wisdom that is seemingly inscrutable, but reveals it self to be universal. #
But, how do they work? 1 Platforms are about leverage. When done well they increase value superlinear rate compared to the amount of resources available. They are also hard to define, hard to see, and hard to build. Today, I’ve got a one two punch. First an article from Frank Chimero, “Platforms as Tables, Tables as Platforms” 2. In it Chimero finds that Design and Jazz are both platforms, but also: #
Whatever it is that you do, if you have wondered about increasing productivity, improving outcomes or creating more long lasting value, you owe it to your self to learn a little about the study of systems. Okay, starting with the most banal definition of a system: A system is a group of interacting or interrelated entities that form a unified whole. A system is delineated by its spatial and temporal boundaries, surrounded and influenced by its environment, described by its structure and purpose and expressed in its functioning. #
There must be a large and storied body of literature when it comes to curation, but I am unfortunately not familiar. I might have a chance someday, but for now, what I do have is this article from Frank Chimero “Sorting A Mass” 1. Up till this point, I had bookmarked anything and everything that came close to piquing my interest. But after this article, I remember bringing more of a critical eye to my reading. #
Being a child of the 80s I can recall a time before the internet permeated my entire reading experience. It was a happy accident for me and my career when I was able to access the internet on a daily bases. Before the internet, Wired came once a month. When I had enough money I’d buy 2600 (it’s hard to convince parents to subscribe to a “hackers” quarterly). Between publications, I’d dwell on the information. #
Gonna start out the month with a fun and simple one. MP3 Blogs and wget by Jeffrey Veen. When I read this, I had a VPS, that I could barely keep running. I blindly ran the command in this post. The next morning I found that I had downloaded almost 30 gigabytes of MP3s. It forced me to learning about things about linux, and wget. This was important, because I got one of my first tech jobs because I knew about wget. #
500+ articles to read. That backlog took years to build. Years of, “Yea, I’ll totally read that”. Then not reading anything. While I was able to trash part of the backlog. (No, I don’t need to read “4 spaces are better then 2 when formatting code”). I still had a healthy backlog. To not keep anyone in suspense, I read it 1. Reading it reminded me of my favorite articles from years past. #