Per my previous post, I’ve left Stitch Fix after six years to find something that fits my strengths and experience a bit better then the public going concern that Stitch Fix now is. This page will serve as a way to articulate what that might be, in particular what experiences I have that it might be worth sharing with you or your team.
This is about me and if you don’t care about that, there’s no sense reading this page. I just need a URL to point
I’m no longer working for Stitch Fix (this was 100% my choice to be clear :).
It’s been an amazing six years, so this post is a hopefully short one about why, and the next post will detail what I’m looking for at the moment.
In reference to my last post, someone pointed me to the Eventide Project, and my response was
that I could not understand what the project was, what it did, or how it worked, despite volumes of documentation.
Rather than detail out that project’s documentation failings, I thought it might be interesting to see a rubric that walks you through the information you need to give new and existing users the best information about an open
I’ve been fascinated by event-sourced architectures and wanted to get some real experience with it, but I also didn’t want to set up massive infrastructure inside AWS, find 100 developers to test it out on, and potentially ruin a business by doing so.
So I created an application that I believe mimics the developer workflows and architectural decisions you have to
make in order to add features to an event-sourced architecture and want to share what I found. Anyone who has done this in
the large, would love to hear if this tracks with your experience.
My takeaways are that it encourages some good practices, creates handy de-coupling between components, but
introduces some friction, as well as complication for building a UI.
Choosing technology has a huge impact on a team’s performance, and when you are starting out, you have a lot of
decisions to make. We often get hung up on technical features, or weather we should use a framework or a bunch of
libraries. The reality is you have to gain a deep understanding of the business realities coupled with your
team’s values. From there, you then evaluate your startup cost (opportunity cost) against the cost to maintain
the system over time (carrying cost) to arrive at the best decision. Technical features are a part, but a small
Martin Fowler recently tweeted a link to his blog post about Kent Beck’s four rules of simple design,
which I think could be improved upon (and, which can lead programmers down the wrong path at times):
I take GitHub’s new security vulnerability notifications seriously, and try to patch my apps whenever something
management of NPM modules is, and how difficult it must be to manage vulnerable packages. And I’m left wanting.
I’m also left more concerned than ever that the excessive use of the NPM ecosystem is risky and dangerous.
In the imagined Timeline Programming Language, there are some unusual restrictions on the type of code
you can write. I thought might be worth seeing if they can help us with real code. I find that when you apply
constraints to your work, you often get forced into novel solutions, and occasionally even superior ones. So
let’s take Timeline’s restrictions on expressions. In Timeline, you cannot have a compound or nested expression,
and the only thing you can do with an expression is assign it to a variable. You cannot use them in control
structures, return statements, or method invocations.
I gave a talk at Pittsburgh Tech Fest that I’d been wanting to do for a while, which is a talk about how to program a time machine and what the programming
language for it might look like. I re-recorded the talk.
Rails Conf just posted my talk from the conference on Database Design for Beginners. If you want a 40 minute intro to database normalization with
practical examples and almost no mathematical notation, this is the talk for you.