It wasn’t long ago that other developers not knowing the things I know was really frustrating. “How could they not know this?!” I thought that I didn’t have time nor should I be expected to train other developers. If I could learn all this stuff, they can too. (Older, wiser Adam: younger, more naive Adam was very wrong!)

At some point, my perspective on this did a complete turnaround. Now I’m eager to teach other developers things they don’t know. The major benefit is, now they know the things I know! A side benefit is now I know the thing better because I had to teach it.

I was completely wrong when I thought I didn’t have time to teach. Turns out, I don’t have time to not teach other developers the things I think are important.

So I did this thing where I wrote a newsletter. I’m going to do it again. The first iteration of this publication was a bit like a written late-night variety show. I wrote about interesting articles, or things that interested me. Each “episode” almost always closed with some kind of musically awesome thing I’d found on the internet.

The next iteration of this newsletter will be like a hand-delivered transmogrification of this weblog. I’ll include links to the articles I thought were most special or had a surprising reception. I’ll occasionally write “commentary tracks” on how an article came to be. Each edition will almost certainly end with a musical or pop culture find, because what fun is running a newsletter if I can’t annoy you with my pop culture tastes?

My hope is that you’ll find this interesting. You can take a look at what I’ve written previously and subscribe to this free internet email newsletter at your discretion. I think you might like it.

It's different from other towns. What's the Difference between Austin and San Francisco?:

Austin offers you more options, but greater variety means that, on the whole, Austinite’s don’t focus as intensely as in San Francisco.  Austin’s defining characteristic (part of it’s slacker culture) is a belief that intensity isn’t always the best thing. Austin believes in variety and moderation. This affects the startup community. Austin, the city, will let you pick and choose from its buffet line, and then admire the smorgasbord you put together. Your lifestyle is a work of art in Austin, and I think the culture rewards you for how you live as much as what you do, often moreso.

In my few visits to San Francisco, I’ve found that I cannot wrap my Texan brain around that town. Trying to really understand its startup culture with just a few visits to the city and Palo Alto is similarly folly. But I did notice the intensity that SF has. It’s not a bad way to describe the town.

That said, I think this is a pretty decent encapsulation of Austin. Austin is a slower town (slower even than Dallas) and revels in the variety of activities available to its people. The Austin tech community is more about smaller groups and individuals too. It’s not (always) about aim-for-the-stars startups or working for large companies using large technology from large vendors. It’s as much about a few people on a team or individuals hacking something out while enjoying their city, family, and friends.

Obviously, I dig that a lot.

Update: I should mention that, while it’s popular to write Austin off as a slacker town, there’s a lot of people dedicated to their work and craft here. It’s not all tacos and BBQ. The events I go to most often are frequented by people who using their evenings to learn something new or talk shop while they’re making something. That is, I think, the most important factor of a startup community: the more people who are putting their evenings into making things, the more likely those things will end up awesome and grow into a business-like organism.

On Being a Senior Engineer made the rounds late last year. Before I finished reading it, I felt it was pointing me down a path I hadn't realized was there but needed to go down. It's the kind of "yes, this!" writing that I often end up ineptly giving people a link to without the ability to explain why they should care or how amazing it is.

I chewed on the original article for a few months, following the links, re-reading it. Basically, I'm trying to completely consume this idea of the responsibilities and abilities of a mature engineer. Below, a bunch of quotes that struck a chord with me and follow-up ideas.

I expect a “senior” engineer to be a mature engineer.

Mature engineers seek out constructive criticism of their designs.

Here's an example of how I try to apply this: attempt to hold all the options (designs, causes, etc.) in your head. This is doubly important if you have identified a design or project plan as infeasible, but it appeals to those who don't have the whole thing in their head. Empathy and understanding of other points of view is crucial.

Being able to write a Bloom Filter in Erlang, or write multi-threaded C in your sleep is insufficient. None of that matters if no one wants to work with you.

A thousand times yes! I have often felt that internet culture lionizes those who are quick and merciless in cutting down those that don't agree or can't code as prodigiously as the original poster. A senior/mature engineer is not soley defined by typing the most code per day.

Be the engineer that everyone wants to work with.

Please, if you ever see me not being that engineer, tell me!

…they have a responsibility to others to make themselves interpredictable. In general, mature engineers are comfortable with working within some nonzero amount of uncertainty and risk.

This is from a section on making estimates. It's hard to make estimates, because they feel like binding contracts. If you're working with the right people, it's OK, they're not a contract. Make a guess and help others you work with understand the level of entropy involved in your project reaching a milestone at a specific date.

This code looks good, I’m proud of myself. I’ve asked other people to review it, and I’ve taken their feedback. Now: how long will it last before it’s rewritten? Once it’s in production, how will its execution affect resource usage? How much so I expect CPU/memory/disk/network to increase or decrease? Will others be able to understand this code? Am I making it as easy as I can for others to extend or introspect this work?

1. The only time is runtime, but a lot of developers focus on the static, build-time properties of their code.
2. As a corollary, developers become the experts at the "hypothetical" of their code, and the ops team become the experts at the "practical" of their code. This isn't a good division of labor.

Generosity of spirit is one of our core engineering values, but also a primary responsibility of our Staff Engineer position, a career-level position. These engineers spend the time to make sure that more junior or new engineers unfamiliar with the tech or processes we have not only understand what they are doing, but also why they are doing it.

I've found it challenging that I'm so far removed from the struggles of a junior developer that in some ways I don't even comprehend them anymore. Trying to help those who have come up through Hungry Academy, even just a little, has paid dividends in understanding "junior" programmers and more experienced developers who don't have my experiences.

They know that they work within a spectrum of ideal and non-ideal, and are OK with that. They are comfortable with it because they strive to make the ideal and non-ideal in a design explicit.

Again: hold all the things in your head, even though you take only one path. For now. It's software you can and will change your mind.

Further: write software such that doing the right thing is easy, the wrong thing is hard, and amending the shortcomings is possible at a later time.

Being empathetic in this sense means having the ability to view the project from another person’s perspective and to take that into consideration into your own work.

Hold all the people, and their conflicting goals, in your head too. Isn't engineering fun?

…never go to your boss with a complaint about anything without at least one (ideally more than one) suggestion for a solution. Even demonstrating that you’ve tried working the problem on your own and came up empty-handed is better than an empty complaint.

There will always be things that suck. Complaining about them feels good! Proposing, advocating, and working on solutions is better.

The issue with cognitive biases is that we can be blissfully unaware of when we are interpreting data with our own brains in ways that defy empirical data, and can have a surprising effect on how we get work done and work on teams.

For every time I wonder what cognitive bias I'm currently exhibiting, I'm sure there's two more times when I have no idea. His list of biases is well worth reading into.

Ten Commandments of Egoless Programming. Yes.

How people feel about technologies, technical decisions, and technical directions is just as important (if not more) than the facts about the details.

People are irrational. Work with it. People have scars learnt from bad experiences. Deal with it. Everyone has succeeded in different ways and made the right and wrong inferences from it. Listen when people talk and speak to what they are excited and concerned about.

I use Alfred because I believe that my computer should be practically unusable to other people who try to use it. My goal is to put the things I use frequently close at hand. Conversely, the things I use rarely should be accessible without cluttering my most common workflows.

Last week, I came up with a way to bring the two or three applications I use all the time very close to hand. Ladies and gentlemen, I present to you the double tap:

Since I use VIM inside a terminal several hours a day, I want really quick access to iTerm 2. My thumb just happens to sit near the command key all day. Ergo, assigning a key to quickly switch to the terminal makes a lot of sense.

But it gets even better! Alfred knows about double-taps of the control, alt, and command keys. So you can assign an application to each of those keys and really quickly switch back and forth between them. It’s pretty rad.

My experience is that this works exactly how I’d want it to 80% of the time. A couple times a day, I will start to chord a different key combo and mysteriously end up in iTerm. It’s not disruptive, just a little odd at first, and I keep going about my business.

If you use Alfred with the Powerpack and love your keyboard, you should definitely start using double-taps.

We tell ourselves, “a computer only does what we tell it to.” But, when it comes down to it, if we aren’t getting the result we want out of the computer, we often give in and do whatever it is the computer wants us to do.

I’m fascinated by this phenomenon. Novices do it when they’re confused, even a little afraid they may have done something wrong. Experts do it when they’re frustrated and upset that the computer is preventing them from doing whatever it is they actually wanted to do.

What’s it say about our increasingly dependent relationship with computers? At what point do we give up on our own goal and do what the computer wants so we can make progress? Is it really computers we’re giving into, or the dysfunction of the relationship between the designer, developer and the user of a computer?

A maxim you could conduct your modern life by: beware technologists bearing a solution, lest it become another chore you have to tend to.

As a remote developer, it's tempting to create an environment where all you do is focus on churning out the code you're paid to write. Minimal email distractions, no noise, meetings and chats only when you want it. Seems pretty ideal on paper!

I've found the exact opposite. Checking out of a team like that, even if I'm fulfilling all my duties, robs me of valuable context. It's handy to know what other people are working on, when they're succeeding, and how they're learning from failures. It might not directly relate to my work, but it helps to stay aware of the environment into which your work fits.

I recently "turned on the floodgate" for the development organization around me. In our GitHub install, I picked one or two projects from each development team to follow. Since most teams use a pull-request workflow, I get a few dozen emails per day that give me the chance to peek into the cadence of a team's work. This fills in context I miss in Campfire or your typical email broadcast.

My job as a developer isn't to know all the things going on; I'm not suggesting you keep close tabs on every project. Instead, I'm trying to keep my finger on the pulse of colleagues on other teams. I find myself better prepared to help them out and make my own projects fit in with where the organization as a whole needs to go.