Taylor Clauson

Wrappers

Mon, 27 Jul 2020 00:00:00 +0000

SaaS businesses (particularly ones for technical users) sometimes have to deal with a vocal outcry that their product “is just a wrapper around” something. The implication is that ‘a wrapper’ is inherently not valuable, and it’s impossible to build a great business around such a product. This logic is a product of lazy thinking and myopia; ‘wrappers’ can be insanely valuable.

Here are a few examples that come to mind:

Dropbox is “just rsync”
Heroku is “just Linux containers on AWS”
Netlify is “just static hosting and a CDN”
Retool is “just MS Access reinvented for the web”
IFTTT is “just cron + APIs”

These statements are lazy thinking–they have elements of truth in them, but they aren’t complete. People are willing to pay for magic. This magic sometimes goes by names like “it just works” or “consumerized experience.” The thread that runs through the different monikers is that it accomplishes an otherwise painful¹ task quickly and delights the user.

Technical users want to be delighted, too, even if the interaction layer may not be a GUI. It might be a CLI, fantastic docs, or a clean API (or likely all of the above). So, if you can take something painful and move the interaction layer, the value proposition of the underlying tools grows.

Big cloud providers will likely offer a comparable service, but these aren’t often existential threats to the best-in-class original. Why? Because the interaction layer matters and a meaningful subset of users are willing to pay for the premium experience.

A few condensed observations about this ‘interaction layer’:

people want a ‘sensible defaults’ way of doing things … an opinionated way of starting out
UI/UX matters a lot (this includes docs and CLI)
rarely, the core value prop isn’t already being accomplished crudely by huge companies
modern open-source companies that are successful have to nail this in ways their predecessors didn’t²
consumerization of everything — i.e., how little of $PLUMBING can I get away with knowing?
there are a meaningful number of technical users who can do something, but don’t want to waste otherwise valuable time doing so

One could argue that the term for this is just ‘user experience,’ but that doesn’t seem quite right to me. Because it’s not about an experience of the underlying tool or process, it’s about creating an entirely new tool by ‘wrapping’ some of the original components.

pain usually equates to a measure of complexity, monotony, or slowness ↩
I suspect this is because we now have such a good base of open-source software that much of the opportunity is with higher-level products. Decades ago, the popular OSS products were things like operating systems, programming languages, and language-adjacent tools like compilers. Then, higher-level abstractions started moving open-source: webservers, web frameworks, e-commerce platforms, content management systems. The trendline is higher, and the interaction layer matters more the higher you go ↩

The Markdown Test

Wed, 15 Jan 2020 00:00:00 +0000

// NOTE: this post serves as an open request for feedback as I try to articulate the edges of a thesis I find compelling. I need to pressure test it, so please send me your thoughts!

As an investor, I am focused on what I think of as ‘technical tools.’ That is, tools that either help developers build or deploy code, or tools that help pseudo-technical users do developer-like things. There are some edges for this where it’s hard to delineate what is/isn’t a tool for a technical user, especially in the collaboration space. In fact, much of my thinking here stems from the question, “so does this include stuff like Slack?,” which comes up a surprising amount in conversation.

I have been working on a simple test to better define the edges of this thesis… To start, let’s put the world of users into some discrete buckets, ranging from obviously technical to less technical:

Developers - people who write code for a living
Code literate - people who don’t write code for a living, but understand what’s involved
Code aware - people who can wrangle a good spreadsheet, but are unlikely have never opened a text editor besides Word (this is the bucket that I have the most trouble with, so any thoughts are welcome!)
Obviously nontechnical - a large catch-all bucket for the widest part of the distribution, people who have a very limited technical understanding

Segmenting technical aptitude... you can't see it at this resolution but there's a tiny inner circle within the green where people are fighting the vim vs emacs flamewar

Using the visualization above as a mental model, I’d say that I am targeting products that cater to the inner two circles: people who write code for a living (self-explanatory) and those who are code-literate, are part of some software development processes, but don’t write code for a living (product managers, some project managers, some business analyst types).

The best heuristic I have come up with for tools that cater to these segments is what I have dubbed ‘the Markdown test’ and it’s very simple: does this product support Markdown input?

It feels like a pretty good marker; I don’t know anyone with zero technical chops that knows Markdown, but it’s also not so abstruse as to exclude those pseudo-technical users that are part of the design/build/deploy process.

Hilariously enough, using Slack as a case study even provides a recent example of what happens when you start out with Markdown support and pull it in favor of a WYSIWYG input:

HN discussion on Arthur O'Dwyer's November post

In summary: a revolt that led to Slack walking back the changes.

I’m not suggesting that developers or technical people universally love Slack, or really even Markdown. It’s just the simplest heuristic I have managed. So, for now, the edge of this thesis on technical tools covers collaboration tools as long as they support Markdown. Please reach out and help refine my thinking!

A possible alternative

Another vein I have explored was along the lines of what integrations a tool has. For example, was it designed with integrations to [ git workflows, Jira, Segment, etc ]? The problem with this logic is that it’s self-referential… the tools in the integration set have to be defined as to whether they are technical tools.

Tools I Learned in 2019

Thu, 09 Jan 2020 00:00:00 +0000

For the third successive year, I’m doing a quick digest of what tools I used for the first time in the past year. I subscribe to the idea that your capacity to be productive (as an individual, team, firm, or society) will asymptote relative to your ability to utilize (and build) specialized tools. And I think software is a microcosm of this; each layer of the stack has different components that are good at different tasks, and by composing a mesh of these tools, you can build high-quality applications.

Usual caveat: my goal with each of these was to learn just enough to see how they work at a basic level, and it’s safe to say that I am a noob at all of them…

Redis

I am late to this party, but Redis is delightful. To learn the basics, I was using the CLI, then added it in as a cache to a containerized Flask app. Redis could be a case study in how to build an open source tool that does its job really well and won over the hearts of developers. It’s some of the best user experience I have seen for developers: a beautifully-clean API, and awesome CLI, and great documentation.
Gatsby

Site generators and decoupled app architectures are really interesting to me. I’m extremely bullish on the JAMstack paradigm/ecosystem, and I have spent time with Jekyll and Hugo. Gatsby is very popular and I wanted to check it out. The good: React and GraphQL, along with Gatsby’s excellent documentation and generally easy-to-use CLI. The bad: I just don’t love the JS tooling world. It feels overly-complicated and bloated to me. That said, I wouldn’t bet against JavaScript.
A little bit of kubernetes

This was just enough to familiarize myself with it. At a 100k foot level, I find a lot of conceptual appeal in the idea of portable, scalable orchestration. But the devil is in the details here, and the current state of k8s feels like an interim step with too much complexity. Cindy Sridharan said it well:

Right now the cloud native ecosystem is a bit of an embarrassment of low level riches. As an industry we need to innovate, experiment and educate more on what the right “highest level abstraction” would look like.

I’m bullish on ideas that are pushing toward that higher-level of abstraction to make this process less painful while still realizing some of the benefits.
Power Laws

One of the things that I spent a lot of hours on this past year was understanding some of the more nuanced traits of a power law distribution. There has been extensive writing about how venture returns follow a power law (or perhaps lognormal) distribution, and I wanted to play with the math to better familiarize myself. I generally prefer to use Python for any numerical analysis, and the powerlaw package was where I spent most of my experimenting time. Investing in startups is a simple concept with a lot of nuance behind it, and the portfolio theory matters a lot. Jerry Neumann had a couple of great pieces on this topic, and AngelList just came out with an interesting study along the same lines.

Unbundling AWS

Wed, 11 Sep 2019 00:00:00 +0000

Over the past year, I have spent a lot of time digging into cloud infrastructure and technical tools as a space for investing. One of the emergent behaviors of technology trends is the accelerating advantage of being a winner, played out with network effects or scale effects (or both!). Since its mid-2000’s launch, AWS has obviously become a juggernaut, growing so quickly and throwing off so much cash that even Amazon can’t put it to work fast enough (!). Getting a new software product to market has never been as cheap or fast as it is today, despite the fact that the surface area of in-depth knowledge required to build high-performing software has never been higher.

Leveraging lessons from building Amazon’s existing infrastructure, AWS has amassed almost 50% market share of public cloud spending. It started out offering a small handful of services (S3, SQS, and EC2), but now has 170 discrete services spanning 23 categories (and these are only the public ones!) As an early stage investor, I’m hard-pressed to name any tectonic shifts that have had as much impact on startup formation. The availability of open source tooling and the ease of access to infrastructure on AWS and other IaaS providers, and infrastructure turning into software, which means it’s programmable and, increasingly, thinly-sliced.

Recently, when I opened the AWS Console, I had a moment of deja vu that called back to a 2010 post by Andrew Parker, then of Spark Capital, that focused on the startup opportunities of unbundling Craigslist. And it shifted a long-simmering feeling into focus for me: I am really excited about startups that are unbundling AWS.

AWS’s growth has started slowing a bit, perhaps due to saturation, perhaps due to competition. Or perhaps it is because [my theory] as they continue to expand into platform-type services, some of their offerings shift from being best-in-class to being very reliable and with a ‘just-ok-but-well-integrated’ user experience. This is a great way to make money, but it also leaves certain of the ‘categories’ on the homepage open to outmaneuvering by a best-in-class experience.

I need to map out something like the awesome graphics that the Spark folks produced for Craigslist, but for now, I have been exploring my intuition about where and why there will be pieces of AWS that will be subject to unbundling. Here are a few that have come to mind already:

Frameworks and deployment tools that make application software agnostic to the underlying infrastructure provider. Things like the Serverless framework, containers + orchestration, or IAC tools like Saltstack, Terraform, Ansible, etc
The overlapping areas of logging, APM, and monitoring. This is a hot area right now, with IPO’s like Dynatrace or Datadog, or acquisitions like SignalFX. Related: Cloudwatch is terrible!
Data science workflows – this is my subjective, anecdotal experience, but most data scientists I know have a preference for Google Cloud for a lot of their work, and custom hardware like TPUs likely play a role here
Authentication and identity – Auth0, LoginRadius, Okta, etc … where it may make sense to have a third-party handle
Paradigms that lead to different stack choices – I’m a big proponent of the JAMstack, and it’s a prime example of a paradigm where AWS may not be a natural choice for parts of this architecture. I believe that we will continue to see this and other new architectural paradigms evolve

There are obvious differences between Craigslist and AWS. The most important is that Craigslist (and each of the category spawn) is a marketplace, and so has the powerful advantage of network effects. Another distinction is that AWS has relative cost advantages over its unbundlers when it comes to the fundamental components of infrastructure (compute, bandwidth, storage, etc.), and I can’t see a parallel to Craigslist. So it’s not a perfect analogy, but the premise of unbundling certain categories still holds.

But what if Amazon launches a competing product?

This is one of those classical questions for any startup. In general, I don’t get too worried about $BIGCO being the reason that a startup dies. In my experience, it’s pretty far down the list of things that actually kill startups. That said, particular to developer-facing startups, there might be some reason for concern. AWS’s relationship with open source is … complicated. Notably, Mongo and Redis have both had to maneuver to combat AWS. The thing to note here is that in both of those situations, it’s a problem that those companies have had to face as they monetize, and was not a barrier to adoption. Put another way: we should all be so lucky to be at a scale and level of popularity where this becomes a problem. It’s hard for me to see a lot of cases where AWS will be competing with companies before they reach scale.

Back to the future

Thinly-sliced? Purpose-built, best-in-class tools? Sound familiar?

… elaborate computing tasks are typically composed from loosely coupled small parts, often software tools taken off the shelf.

The UNIX philosophy strikes back! The history of software development has a lot of patterns in it, and this trend toward tools and component parts that do one thing well is one of my favorite. If every part of our infrastructure is available in ever-smaller pieces, on-demand, then the long narrative arc of this philosophy ought to continue to win out.

There are already billion-dollar companies that focus on relatively narrow niches within the AWS offering space–and I believe there will be many, many more. If you’re building something that carves out a piece of AWS, I want to talk to you.

What are you optimizing for?

Fri, 26 Apr 2019 00:00:00 +0000

I have learned only a minuscule amount about machine learning; just enough to get under the hood and to build something very rudimentary. As I was learning some of the underlying concepts and methods, a couple of things really struck a chord in my brain–with how applicable they are to, well, everything.

When you turn a problem into code, you are forced to be explicit about things that you otherwise may not have been. Specifically, you have to be explicit about what you wish to optimize. Working with startups is inherently a question of what you are trying to optimize. As an investor, this includes things like portfolio construction and allocations. As a founder, this includes managing your product, how you measure success, and all the endless tradeoffs that you have to navigate when dealing with customers.

The Training objective

Beating a professional human at Go was considered a milestone for artificial intelligence because Go has many possibilities to evaluate for a given move when compared to a game like chess. But in 2016, AlphaGo (developed by Google) won four out of five games against Lee Sedol, an 18-time world champion. What was so interesting about this is that AlphaGo made moves that seemed like mistakes to most human players. In a 2017 match against the top-ranked player, AlphaGo had one move in particular was criticized as a mistake, when the computer gave up what seemed an obvious advantage that could lead to a large margin of victory. Andrej Karpathy, an AI researcher who had spent time working on AlphaGo, later commented on that particular move:

it prefers to win by 0.5 with 99.9999999% chance instead of 10.0 with 99.99% chance.
— Andrej Karpathy (@karpathy) May 23, 2017

This illustrates a critical point. Not everyone around the table is optimizing for the same outcome at all moments. I have been in tense boardroom discussions where this fact is thrown into sharp relief. The lesson I have tried to internalize from digesting this is to ask myself, “what am I optimizing for?” And once I have a suitably coherent answer to that, move on to, “what are the people around me optimizing for?”

To some extent, this is common sense that any book on human psychology would recommend (e.g. you have to understand what your customers need). But those Andrej Karpathy tweets continue to surface in my thoughts–especially around people whose behaviors I find confusing or when I have a particularly strong gut-level reaction to something going on with a portfolio company.

One thing to note: these different outcomes may not necessarily be adversarial, not completely in alignment. These can be the most subtle ones to debug. For example, imagine two cofounders measuring success using different metrics. Both the founders may be trying to build a company, but if one believes that user growth is the most important indicator and the other believes that ACV is the most important, they will have different opinions on what strategies to employ.

Often, and embarrassingly, I realize that I am optimizing for my ego. As I have noticed this in myself, I have started to also notice it in others. It goes without saying that this is not a good look. So when I feel like a situation has shifted out of alignment, and I’m struggling to put my finger on why… what am I optimizing for? And what are the other people here optimizing for?

A version of this post was originally published in Hacker Noon

Tools I Learned in 2018

Mon, 21 Jan 2019 00:00:00 +0000

This is a belated and probably too-skinny version of a post I decided I’d do every year, starting with last year. Usually, when I say ‘learned,’ I really mean I engaged enough to understand a little bit of what’s going on, and not that I am wizard-level user in any of these. In 2018, I spent time learning fewer new things than in 2017, but I probably went slightly deeper.

Working with FaaS

The first time I had ever completed an intro to programming course, particularly a Python one, I remember having this feeling of, ‘now what?’ I could script a game of hangman, but didn’t have any idea how to manage an environment, package something for deployment, launch a VM (at the time, containers weren’t a big thing) configure a webserver… honestly the entire stack was opaque and intimidating. That’s one of the reasons I find serverless to be an appealing paradigm–a developer can focus on writing code that actually has a job to be done, rather than the endless train of yak shaving that could otherwise be involved in launching something. I’m not trying to diminish the importance of well-orchestrated infrastructure, which is critical to scaling effectively–but more just love the idea that the number of hurdles to building something small has been reduced.

For this foray into learning, I started first with Lambda, but quickly grew frustrated with the complexity of the AWS dashboard and configuring API Gateways. Serverless was my next stop, and I really love it. It abstracts away a lot of the complexity and has templates with sensible defaults for a lot of different microservice structures. I played around with Netlify’s functions and I have it on my list to check out Zeit too. Decoupling code from infrastructure is a long-running trend, and this next evolution of it has a lot of promise for modularizing the ‘connective tissue’ of a lot of businesses.
JAMstack

Every so often, you come across an app or a development pattern that just intuitively feels right. I know that’s perhaps the least scientific way I could possibly characterize something, but JAMstack (Javascript, API’s, and Prebuilt Markup) is one of those architectural things that makes perfect sense and feels good. It fits neatly into the long-running trend of tool specialization and modularity that dates back to Bell Labs and Unix (‘programs that do one thing and do it well’.) The emergent JAMstack architecture from this trend opens up new ways for code to be deployed in ridiculously simple and uncomplicated (abstracted?) ways, further decoupling front-end web from application logic and infrastructure.

Netlify is a leading company in this ecosystem, and it was one of those rare products that made me say ‘oh, wow,’ the first time I used it for a static site deployment. This site is built in Jekyll (legacy from Github pages), but I also tried out Hugo for the first time. Some of Hugo felt less intuitive, but true to Go’s promise, it was blazing fast. I have Gatsby on my list to try soon.
Dabbling in Lisp

I have spent precious little time with any functional programming language, so I decided to start working my way through The Wizard Book and dabbling in Scheme, a Lisp dialect. Perhaps because I didn’t start out in OO rather than functional languages, or perhaps its just a lack of mental dexterity, I find a lot of the principles to be non-intuitive. In that regard, it’s been mentally rewarding even though it’s a challenge. I’m not done with the book and I intend to finish it this year.
A bit of Machine Learning

Perhaps more than the others on this list, I wanted to just build a baseline understanding of the moving pieces of machine learning. I went through Andrew Ng’s amazing Machine Learning class on Coursera and through fast.ai’s Deep Learning course. Each was spectacular in its own ways; Ng’s class focused on building into algorithms from the ground up, while fast.ai’s started with practical examples using their libraries and then dug into the moving parts.

I tend to prefer the fast.ai approach, but the Ng class was really a perfect foundation. Related to this, I had to brush up on some calculus and linear algebra that had been gathering dust in my brain for a decade. The only other thing I’d say about this is that Octave is horrible and was the worst part of the Ng course!

A founder's guide to conversations with Midwestern VC firms

Thu, 15 Mar 2018 00:00:00 +0000

I remember the feeling of meeting with prospective investors and wanting to make a good impression. The first few conversations with an investor are high-stress and full of subtle signals. Most founders have good instincts and navigate these situations well, but the points below comprise some of the nuanced issues that I have observed over the years from the other side of those meetings. Hopefully these apply to early stage VC conversations in general, but note that they are specifically biased toward founders in the Midwest.

Do: explain what you do quickly and simply

I can’t count the number of pitches where we get 10+ minutes into the meeting, and I have to ask them to stop and give me the quick, cookie-jar-level summary of exactly what the product is and who uses it. It leaves me wondering, is this what their sales pitches are like?

Don’t: assume that any female at the firm is an admin

It’s appalling to feel the need to write this one, but I have more than once been part of an email thread where the founder assumed that a female partner at our firm was an admin and asked her to schedule. I’m still speechless.

Do: court the firm

Cultivate a relationship. If you first meet while not fundraising, send them updates. Call your shots! There’s nothing more impressive than an entrepreneur telling me what she will accomplish, then following up a few months later to show me exactly how she did it.

Don’t: send someone other than the founder

I get it, this is a double standard because a VC firm is likely to send an associate or analyst to an initial meeting, but the startup needs to send a founder or CEO. An early stage venture investment is a bet on the team more than product or traction, so you need to do everything in your power to show why your team is the right team.

Do: be honest about the risks and challenges

Every once in a while, there is this weird dynamic where a founder or team seems like they are absolutely intent on selling me that everything is going to be a piece of cake and they know exactly what they are doing. This one may be a personal preference, but I find it intellectually dishonest and a bad sign. Yes, I want you to convince me that you know are the right person/team for this market, but I also want to see that you understand that magnitude of the challenge you are facing. It won’t be easy, and I want to feel assured that a founder grasps this and won’t give up at the first series of speed bumps. As a founder, if you find yourself on the receiving end of the question, ‘what keeps you awake at night?’ consider whether you are giving a vibe that makes it seem like you expect a cakewalk.

Don’t: channel your inner bro

If it’s the beginning of your relationship with a VC, then err on the side of being professional. No photos of yourself or your team in a swimsuit or with a beer. No innuendo. No videos of you gathering customer feedback on the street by offering them a ‘mystery shot’ (note: this also actually happened. Still speechless about this too.)

Do: sweat the details

Little stuff. On your slides/emails; punctuation, font, alignment, typos. In a meeting; name recall (don’t call me Tyler). I wouldn’t draw a hard line on not funding someone because of a typo, but the more organized and buttoned-up you are, the better I feel.

Don’t: downplay competition

Some founders seem to think that VCs want to hear that there is no competition. We don’t. It’s never the reality in the market and it demonstrates a lack of market understanding. Perhaps what you’re doing has truly never been done before, and the competition is non-consumption. Fine. But what I want to hear is what your competitors are good at (or how it’s being done today), and then why you have a special place in the market — your distinct competitive advantage that will allow you to win customers.

Do: assume firms talk to each other

The herd mentality present in venture investors has been well-documented. I’m not defending it, but rely on the fact that firms talk to each other. If you tell me that $FIRM is looking at investing, and I know them, I’m going to call them. And if the story they tell me is different than the one you told me, I generally ratchet back my enthusiasm. To be clear, it’s not that I am looking for another firm to confirm or deny my interest; it’s that I expect a founder to be honest about the level of engagement at another firm. If you tell me that $FIRM is about to send you a term sheet, and my conversation with a person at that firm lets me know that they met with you once and are nowhere near a term sheet… well, in the words of my man Marlin in Finding Nemo, “good feelings gone.”

Don’t: go answer-shopping within a firm

Yet another one that shouldn’t have to be said, but… it happens. If one partner gives you an answer you don’t like, don’t resurface one week later talking to a different partner. We talk to each other, and you’re going to burn a bridge.

Do: have conviction

Most VCs are curious and creative people. Too many times to count, I’ve seen an investor thinking out loud about variations of a product or market strategy, and suggest a change of strategy to the entrepreneur. Obviously, you should be respectful and try to be open to good ideas, but don’t roll over and accept the new ideas blindly. Show conviction about why what you’re doing is the right thing, the right way, at the right time.

Don’t: name drop

I’m not saying don’t tell me about your marquee, name-brand customer. Just don’t go out of your way to drop names and act like it’s no big deal. Related to this, don’t artificially pad your deck with an ‘advisory board’ full of big names who barely know anything about your company.

Do: keep it brief

Especially in the midwest, you’re not going to close a deal at the first meeting. All you really want is to get to the second meeting. Don’t show up for a 30-minute meeting with a 50-page deck, and don’t send a 10 paragraph email. keep it simple and brief. Capture imagination and let the investors digest it before you get into the weeds. Arm them with the facts they need to make a sensible decision about whether to move forward, don’t overwhelm them with details that may just muddy the waters. Have back-pocket info to support your high-level points, in case a probing question is asked.

Don’t: use an investment bank for an early stage round

Signaling is a word that comes up very often in the VC world. Using a banker or consultant to fundraise on your behalf doesn’t signal good things. My immediate question is: “did they try to raise money on their own and fail?” Not to mention, no early-stage investor wants his/her investment going toward transaction/finders’ fees.

Do: your homework on the firm

What types of deals does the firm tend to do? Are there specific partners that seem to attach to specific sectors or types of companies? Are you raising an amount that fits with the firms check size? Does the firm have a geographic focus? Read up on any of the investors’ blogs or tweets or anything you can find. Google and Crunchbase are your friends here.

Skills Learned in 2017

Sun, 10 Dec 2017 00:00:00 +0000

Following up on my post about tools I learned to use in 2017, I wanted to also touch on some of the soft skills and lessons that I have been learning over the course of the year too. I believe that being a well-rounded investor [person] is way more about the soft skills than the actual technical part of the job. Below are some of the lessons that I have been digesting over the past calendar year. None of them are rocket science and some may not even be particularly insightful, but they have been hammered home to me nonetheless.

Lessons learned

RTFM - Read the [Freaking] Manual

It seems like no matter how many times I learn this lesson, I need to be reminded of it on a continual basis. When I need information on how something works, go to the source. The formulas in the excel sheet, the language in the legal docs, the raw data used in the analysis; whatever the original source may be. Especially on something where there is complexity or lack of clarity in a group of people. Takeaway: go straight to the source.
The right person makes all the difference

When you have the wrong person in a role at a startup, everything seems harder than it should be. And startups are hard enough without that. In many cases at many companies, I have witnessed a dramatic shift when the right person fills a role. Suddenly so many things that seemed painful or complicated are less painful, even if there is underlying complexity. Takeaway: you can’t settle when it comes to finding the right people.
Don’t kick the can

This is another lesson I have been slow to learn and the awareness has built over time. My observation is that nothing good ever comes of waiting too long to make the hard decision–we all have a human tendency to delay the things we dread. In his book The Hard Thing About Hard Things, Ben Horowitz had a great line, something to the effect of, “if you’re going to eat sh*t don’t nibble.” He nailed it. If it’s time to do the hard thing, do it. No half-measures. No kicking the can down the road. Takeaway: resist the urge to delay a hard thing purely because it’s hard.
Pick up the phone

When I was younger, my tendency was to do as many things as possible over email or text. I like having the history and documentation at my fingertips should I need it later. Over time, I have shifted many things away from email, in particular, things that have any emotional content or sensitivity. Too many things are missing from the medium–depth of tone, emotion, etc.–and it’s far to easy to have something misconstrued. Maybe I need to apologize or take responsibility for something, maybe I am delivering bad news, maybe I am asking for feedback on something. Sometimes I will even call people to let them know about an email coming later. I can think of many times I have regretted using an email to deliver a message, but not a single time I regretting telling someone on call. Takeaway: phone > email for emotionally-charged things.
Asking the right questions

I will probably end up writing about this one separately because there’s so much to it. I have been thinking a lot about how I ask questions when meeting with a company. On its face, this sounds so easy, but there is so much nuance to it. It’s easy to ‘lead the witness.’ It’s easy to drag out the question in an effort to show off some domain expertise. It’s easy to ask questions that will focus on a risk or problem, when I should be asking questions that explore what’s possible. Takeaway: the questions I ask are a reflection of my posture toward the company.

As with the tools I have been learning, I’m not claiming mastery of any of these. I suspect I will continue to be reminded of these lessons for many years to come!

Tools Learned in 2017

Tue, 05 Dec 2017 00:00:00 +0000

In spite of doing an extremely poor job of keeping any writing up to date on this site, I am going to start doing annual recaps of what I have learned over the past year. I am not totally convinced that I will use the same broad categories year-over-year, but had to start somewhere. These are the tools that I have been learning to use over 2017. I have not mastered any of these tools, more just built enough of a baseline competence to accomplish my goals in each of them.

Some of the Python data analysis/visualization packages (pandas, Matplotlib, seaborn)

I have spent a fair amount of time using R for data analysis. Learning that was nothing short of painful. R is wonderfully powerful, has a large active community, and is perhaps the most inflexible and unenjoyable programming language I have used. Were it not for Hadley Wickham’s packages (ggplot2, dplyr, rvest, and others), I probably would have given up a long time ago. I have always appreciated the feel of Python, and wanted to learn to use some of the data analysis ecosystem. Long story short, I don’t think I will be using R for much in the future.
Docker – redeploying an app I had made using a docker container

Especially when it comes to software infrastructure tools, I don’t feel like I can ever really grok the concept and value of something until I have seen it in action and done something with it. I had a concept of what containers did, but wanted to see it in action. I built an eliminator pool app for pro football season, and I redeployed it using docker. It was one of the great ‘wow’ moments that happen every once in a while with technology. I’ll never have to configure a server for that app again.
Django – learning a python web framework

As I mentioned above, I have always found Python to be a satisfying coding experience. I mean, how many other languages have something like PEP 20. Dating back to high school, I had done a lot of scripting exercises in Python, but precious little in terms of applications. Having spent more time on javascript web frameworks, Django was awesome. It felt more thought-through.
d3 – wanted to make a chart interactive

Javascript is fantastic. And I hate it. Both. It’s ugly and slow, but is everywhere and can be made to do most anything I can imagine. That said, d3.js is so awesome. I’m a big fan of visualization tools, so I wanted to use d3 for the chart on my Reading page. I still have more I’d like to dive into on this, as I have time.

I am not sure yet what I will focus on what tools I will spend time learning next year. I think perhaps spending some time with Kubernetes and Lambda on AWS. Suggestions are welcome!

Abstracting Complexity

Wed, 30 Nov 2016 00:00:00 +0000

Near the end of last year, I came across this on HN and was mesmerized. Side by side screenshots of the desktops of some titans of software development, taken 13 years apart. The thing that was so fascinating was how little had changed. Throw in a newer version of a linux distro or OSX, Chrome shows up in a few places, as does Github (though doubtless git was being used previously, just without Github), but precious little else changed. In one sense this made me grin because ‘cutting-edge’ typically conjures up images of people with the latest gadgets or new shiny objects. But these folks are the people that make the things that have defined cutting-edge and their daily workspaces have barely changed at all. My own workspace bears almost no resemblance to my workspace of 13 years ago. I think it would have have had IE as the browser, hotmail as my email provider of choice, and winamp playing in the background while I farted around with BASIC and chatted with friends on AIM. The mainstream middle of the technology adoption curve has changed so much over that period of time, but change can be astonishingly slow at the edges. A few years ago, Chris Dixon had a great quote: “what the smartest people do on the weekends is what everyone else will do during the week in ten years.” So true. The interim seems to be all about layers of abstraction that must accumulate before it can have a step-function increase in adoption. I’m a fan of companies that do just that–abstract away complexity. It opens up new possibilities for their users to focus on the things that really matter.