Still only myself

Two quotes about the experience of life. The first from NYT’s Magazine “I’ve Always Struggled With My Weight. Losing It Didn’t Mean Winning. “

Suddenly, I was slim. It was, by any measure, an incredible weight-loss success story. Even my great friend Alan texted about how good I looked. (“Did I say that?” he wrote, with a facepalm emoji, when I reminded him of the time he squeezed my love handles. “Sam, I was very inappropriate. But I still think it’s funny.”) I had achieved the great transformation — I had turned myself into the “AFTER” photo.

And now that we have that out of the way, I can tell you what I consider the most interesting thing about my weight-loss journey, a secret that you will never see in any banner ad. As the months passed, as I stuck with my healthful habits and got used to my new trim body, as the line on my Noom weight graph stayed low, I felt something amazing: I felt pretty much exactly as I had always felt my whole entire life. I was, after all that change, still only myself. My big epiphany, if I could put it into words, would be something like: “So what?”

And the second from Gawker’s ‘Failure to cope “Under capitalism”’ (newlines added by me for emphasis):

[Anne Helen] Petersen’s most acute insight is perhaps in identifying a link between relentlessly optimized childhoods designed to prevent downward mobility, and the professionally competent but profoundly enervated millennials overwhelmed by the prospect of canceling plans, of keeping plans, of cooking food, of texting their mothers. I think she is correct.

I think it’s possible that for many, considering the shape of your life and then living it with vigor is so difficult because it cannot be externally validated. Unlike education and work, it offers no socially obvious meritocratic path. The moments where, like sourdough, it proves, are largely invisible — in cooking, in walking, corresponding with a friend, in chatting with a neighbor or registering to give blood. They cannot be tallied up and put on a resume. They are never “finished.” The progress you make is spiraling rather than linear; circling steadily, slowly, around your weak points, taking two steps forward and one step back, building habits so slowly that only in retrospect can you see your life become different than it was. And there is no one who can tell you that you did it right.

But this is not the condition of life under capitalism, this is life itself. And it is a sad irony that though the fear of life may be produced by class imperatives within capitalism, the impulse to restrict it to a problem of capitalism is itself part of the same fearful rejection of the task of living.

Which also reminds me of an aside from a Bruno book, whose authorship is an American author writing about contemporary Southern France, that the French are tryhards even when contributing to a weekly dinner at home with their friends.


Hate and sarcasm

Two things I read recently were commentary on forcefully-weak communications.

The first, from a r/rails thread in which the poster wrote “I hate React as it’s not using MVC pattern and It’s not organised + I hate JS.” A response:

You mentioned that you’re looking for junior positions which implies that you’re relatively new to the industry and have limited programming experience. Despite this, it seems that you’ve developed a lot of strong opinions.

There’s nothing wrong with having strong opinions and some of the best engineers are very opinionated. However, one of the biggest things you learn as you gain more experience is that you don’t know what you don’t know and that while forming opinions is important, one should understand why we may form certain opinions and whether those reasons are actually valid enough to hold those opinions strongly enough.

For example, you say that you hate JS. Hate is a very strong word for junior developers. Why do you hate JS? Is the hate that you have for the language actually for the language itself or rather code that you’ve written in it? If you’ve been forced to work on an awful codebase, then the language itself isn’t to blame.

You mentioned that you hate React as it’s not using MVC pattern. What is it about the MVC pattern that you like? There’s a lot of advantages with the MVC approach, but other approaches also have merit. As you gain more real-world experience, you’ll realize that there are many ways to do things and each approach has its own merits/disadvantages. You mentioned that React is not organized, but React is not a framework - it’s a library. You can organize it however you want which can be a double-edge sword if you’re inexperienced. Any disorganized React project is not React’s fault nor is it a fault of JS.

Unlike React, Rails is a framework and a very opinionated one. It can be beginner friendly as things will just work out of the box as a lot of decisions have already been made for you. However, it can also be difficult for beginners to level up as Ruby is a lot less explicit and a lot of the behind the scenes magic can be very confusing to figure out why things work the way they do. There is also a lot more ways to write your code in Ruby which means there’s a lot more syntaxes and patterns you may need to be aware of to be competent. (e.g., there’s only a certain number of ways to write a loop in Python but a multitudes of ways in Ruby). This flexibility may seem like a blessing to be able to write expressive and elegant code, but for beginners, it can make the process of leveling up a lot more work.

You should be open to the possibility that you may also not end up loving Ruby when it actually comes to working on production code. Many of us here love Ruby, but it should be stated that there’s a difference between tinkering and using Ruby for toy-projects and maintaining a Rails app. Also, Rails does not make JS go away. You may find yourself writing plenty of JS in Rails to get the desired UX on the frontend.

At the end of the day, I do love Ruby and there are plenty of Rails opportunities in the market so I do think it’s worth learning. But if you want to pursue Rails, you should jump in with both eyes open. You may find that your criticisms of JS & React may not actually be as valid and be specific to the projects that you worked on. If there are a lot more opportunities for you in JS/React than Ruby/Rails, it may be worth continuing down that former path.

And Andrew Bosworth “On Sarcasm”:

At first being sarcastic was incredibly satisfying. Whereas previously I might have made an earnest argument or asked a question, I now seemed to be able to jump right to the part where the group appreciated me and my contribution. What is even more impressive is it required very little thought to execute. I could often get a positive reaction even on topics I knew almost nothing about.

It was when I noticed this last point that I decided that sarcasm was not for me.

Sarcasm “works” because it alludes to a critique without ever actually making it. It shifts the burden of substantiating the criticism as an exercise for the audience and further suggests that if they don’t already understand it then they are deficient. Making a critique implicit is an unassailable rhetorical position. The most socially acceptable response for the group is to go along with it, as you have given them nothing specific to challenge. And if someone does challenge it you can simply demur and say it was “just a joke.”

Sarcasm does nothing to advance our understanding of the world around us or help us improve it.


Four dumb-cringe tech interview stories

In my previous write-up about NodeTiles, I said that I had dumb interview stories to share. They are also cringe. Here they are.

“Oh yeah, me too.”

I failed my very first professional job interview.

I was 21 and it was 2004. It was my last year at the University of California, Santa Barbara. I was graduating early, in three years, with a BS in Math Sciences, with Honors, and I was looking at Summer internships as something to do because the last credit course I needed was only offered at the tail-end of Summer quarter, right before my AmeriCorps*VISTA service began in Boston. I had never done a college internship before, mainly out of ignorance of their importance; this would be my first (and only) attempt at landing one.

UCSB is gorgeous, it’s on the beach; it is a bare-shouldered, sunny, surfy beach town. I was boring. Yes, I surfed and swam and sailed and hiked and ballroom danced and tended a community garden and worked on my 1973 Porsche 914 through Santa Barbara High School’s vocational auto-shop. But I wore a lot of cargo shorts, I didn’t drink or party, and I mainly loaded up on math and writing courses and worked in the campus library’s Map and Imagery Lab pulling and shelving topos and ortho photos. Santa Barbara!

My internship interview was with a local military contractor that was creating sensor fusion software. I thought it was pretty cool because it was maps and spatial and lined up with my honors research project, using statistical sensing methods to probe physical topologies, albeit of knotted proteins, not the Middle East. Also, I had not yet untangled for myself the distinctions between patriotic service and imperial militarism. I was 21 and it was 2004.

I don’t remember a lot of the details of the interview. There was a primary interviewer who was maybe a year or two graduated from UCSB himself. He walked me around between cubicles I was given the chance to briefly chat with various people, including the CEO. At the end, we sat down for more formal chatting, and he said something like:

“You know, we don’t like to work very hard around here. Do you?”

And me, just trying to fit in, was like “Oh yeah, me too. I try to take it easy.”

Ded. I was declined. I’ll never know if that was a trick question, or like they knew I was not actually a good fit. But it was fine. I took another writing class.

“Code is our craft”

It was 2012, and my Code for America Fellowship was coming to an end. Having moved the previous year from Boston to the Bay Area for the fellowship, I now retooled my resume to downplay my decade-ish career of “community media and technology leadership” and instead highlight my “web applications and freelance software development” experience. I was trying to land my first official Software Engineering job.

There were a number of companies in Code for America’s orbit, so multiple fellows were interviewing at the same place. Us fellows were more collegial than competitive, so there was lots of helpful backchanneling and suggestions and level-setting that some of the jobs were faintly ridiculous, but sure, why not. It was the Bay Area in 2012.

I got a face-to-face interview with a company that I’ll vaguely describe as “a social network for baristas”. It was a Javascript company. There was a tech-screener project I apparently passed, so I came into the office. I can say this, with more hindsight and experience: there were some red flags.

  • I was introduced to the lead engineer and we chatted for a minute. I asked them something like “How do you see the business growing? I mean, where do you think the value lies in the product?” This was the wrong question for them. The lead engineer explained that “Code is our craft” and that well, who knows what the future will bring, but they want people who really are interested in the software.
  • One portion of the interview was reviewing my tech screener project. There was one part of the screener where I was unsure of the situationally best way to accomplish it, so I did the most direct unoptimized way and left some comments about different optimizations and their pros/cons. I was asked about why I hadn’t just picked one, and I explained that I wanted to treat this like real life and talk through it with a more experienced colleague who could represent the actual business needs and not prematurely optimize at the expense of readability and openness to change. That was the wrong answer for them. They explained that “Code is our craft” and they’d expect me to make the best call on my own.

I was declined. I want to admit that I did mostly fail a different part of the technical interview: it was a whiteboarding exercise along the lines of “solve this problem using only pipes”. I think everything may have been built with pipes, but it was Javascript in 2012, so I probably should have known how to do it to be qualified.

Sidenote: Huge props and respect that the company successfully socialized and operationalized a core company value. Even if I think it’s dumb.

“Focused on the code”

This was 2016, my professional circumstances were different, and I want to assert that I had become a real catch of an engineer. I was leading a fullstack web UI and CLI team at a B2B platform-infrastructure startup, and also moonlight solopreneuring a successful consumer web and cross-platform mobile native app too. Professionally, maybe, kind of, a big deal 💅

I was courted. I was reached out to over LinkedIn by someone I had only known of to that point. We got coffee and walked around San Francisco and they shared their vision. They invited me, and several other engineers, some of who I also knew of to a fancy private dinner. It was nice.

And there was a standard interview too. We talked about developing high-performant, early-adopter, power-user consumer interfaces, and our shared history and respect for Ruby and Rails and Javascript. We pair programmed on a problem, and I think I was nailing it.

And then there was a question, like “Ben, I know that you’ve been a manager in the past, and you’re currently leading a team. Is that something you really want to do in your next job?”

I replied saying something like “I’m happy being an IC. And I think a strength is my flexibility to help where it’s needed. If that’s what you and the business and the team eventually need, I’d feel confident and comfortable stepping into that role again.”

That was the wrong answer for them. I was declined. I received a reply later saying they wanted someone “focused on the code.” This is one time when I do wonder if I should have like, followed up and clarified my message, but interviewing is like bizarro-world dating so who knows.

Sidenote: If you’re reading this as flat advice, you should follow-up, because the worst that will happen is they’ll say “still a no”.

“Should we go back in there?”

In this story I was one of two technical interviewers, along with a hiring manager and the director of engineering.

We were debriefing after a week of interviewing candidates. There were two finalists. None of this may have actually mattered, or everything mattered, but I want to paint the picture. Both engineering candidates were women; we were all men along with the entire engineering team of 15 or so; not great!

  • Candidate 1 was very outgoing, had a ton of analogous Bay Area tech experience, lots in common to talk about… and did not pass our technical interviews.
  • Candidate 2 was a kinda awkward, their experience was weakly adjacent sorta kinda… and they totally aced the technical interviews, like finished in half the time then schooled us. Which made it even more awkward because we’re all awkward engineers truly and now we had like 30 minutes of dead time to fill trying to chitchat. I heard something similar happened in the manager interviews: the candidate answered too succinctly.

Ok, so the debrief. We went around the table, shared our experiences. And Management wanted to hire Candidate 1, the candidate that didn’t pass our technical interviews. For real! But this is business, and we have to be collegial, and they’re the managers, so my other engineering colleague and I disagreed and committed and rolled our eyes but left the meeting like yep, this is business, we’re all business here.

And we were walking down the hallway back to our desks and we both said to each other at the same time “What the fuck was that?”

“Should we go back in there?”

“That wasn’t right.”

So we kind of treaded water out in the hall for a minute, and worked up the courage to… gently go back and knock on the conference room door and politely ask if we could say one more thing.

“We should hire Candidate 2.” Seriously.

To management’s credit, they listened and I think correctly read that we were distressed and this wasn’t just our standard grumpy-engineer bikeshedding bit. Management agreed to make an offer to Candidate 2. Mission accomplished.

Ok, so I want to say there are two possible futures here:

  1. We hire Candidate 2, and they are a solid if unremarkable engineer. They do good work, meet and occassionally exceed expectations, and are an incremental contributor like everyone else in pushing out our startup’s runway toward some brighter future and shared equity event.
  2. We hire Candidate 2, and they are an absolute-based 100x engineer. They frankly save the company in my mind, bulldozing through any problem you throw their way with a nonchalant “alrighty then”. They exhaust the backlog leading them to entirely rewrite the product twice over better/faster/more-maintainably as a distraction while the backlog is rebuilt then they plow through it again.

It does not matter which future actually happened (though one of them definitely did!), because they were qualified, capable, and if we removed the fucking bias of our otherwise reasonably designed interview loop, the best candidate in our pool.

In the previous story when I played the role as befuddled candidate I was like “I dunno, bizarro dating”; but if you are ever in the position as an interviewer and there are some bogus soft-no’s or bogus soft-yes’s, speak the fuck up and use your power to the extent you safely can. Seriously, you can do this, even in business.


"What the fuck are you talking about?": The story of NodeTiles

NodeTiles' trippy demo image that says "NODTILES" written across a map ofthe globe

I recently lost access to my 10-year old Code for America email address when I changed jobs. I tried to preserve some of the good stuff and this is one story.

During my time as a Code for America Fellow in 2012, I created a Javascript-based slippy map tile renderer called NodeTiles (kinda sorta like Mapnik). Several colleagues helped vastly expand it, we presented at NACIS, and I know of at least one successful company that is still powered by forked version of it today.

Jessica

During our Fellowship, Jessica Lord gave a tech talk on building custom map tiles and first introduced me to TileMill. I couldn’t find a record in my email of when that happened, but know she planted this seed 🌱

Tom

On April 25, 2012, I sent this email to Tom Carden:

This week I came across a gist of yours and eventually made my way to nodemap while researching how to generate server-side map tiles. Thank you so much for putting those pieces together; they’re fantastic! I matched your code with node-canvas-heroku to get it running in the cloud and it’s pretty fantastic:

http://morning-spring-2292.herokuapp.com/

Anyways, just wanted to send you a big thanks for the code and inspiration. I’m working on building a node-based utfgrid renderer to bootstrap an entire wax interaction layer… all without Mapnik (though maybe I should just work on packaging that for Heroku).

Cheers, Ben

Tom gave some helpful advice and caveat emptor about JS performance and data caching. He continued to follow up with node-canvas and cairo suggestions for getting stuff running on Heroku. Tom ended up being a Code for America mentor for a different project and he was the source of us using the Toner map style in demos and also a nice leaflet clustering plugin.

Rob

Rob Brackett was the first person I explained what I was doing to create a tile render in Javascript. His reaction to my explanation was “What the fuck are you talking about?” Rob is one of my best friends, and I don’t remember how I explained what would become Nodeiles initially, but I’m sure it took 20 minutes and was a non-linear train of thought.

On May 2, 2012, I sent this email to “Fuzz”, Code for America’s random-nerdsnipe list:

Last week Rob and I built a heroku-compatible map-tile renderer (and UTFGrid generator) that can quickly (and with low bandwidth/client-processing) serve interactive maps and markers comprising tens of thousands of points and polygons—and unlike TileMill, the final map can be connected to a live database and updated on-the-fly. It’s kind’ve badass.

Here are 2 examples:

  1. Static map of San Francisco streets and Parks:  http://morning-spring-2292.herokuapp.com/

  2. Map of all ~1.5k Occupy sites worldwide (I did this in about 15min, so it’s a little clunky): http://occupy-map.herokuapp.com/

In terms of why it’s badass (from less to more geeky):

  1. It’s fast. Nothing is rendered in the browser, instead all of the tiles are rendered and streamed to the browser as PNGs.
  2. It’s small. No shapefiles are sent to the browser. Each Map (the entire initial pageload) is less than 500kb.
  3. It can do dynamic data. TileMill makes beautiful maps, but once you export them to MapBox (or your own mbtile server), you can’t change them. This can be hooked up to a live database (right now it parses geojson).
  4. It runs on Heroku. It uses node-canvas (not Mapnik) so it is fast, lightweight and has few dependencies.
  5. It renders UTFGrids, which can provide mouse-hovers and other straightforward UI stuff that most maps don’t (way less clicky)
  6. It’s not a tileserver, it’s a tile renderer. Seriously, all those maptiles are being generated on on-the-fly (we should probably cache them, but hey, this is bleeding edge)
  7. It’s nodejs and all the code is on Github:  https://github.com/bensheldon/nodetiles  

I’m still working on it, so if you have a big dataset that you’ve had trouble mapping before, let me know since I’m looking for more/better use cases.

Prashant

Prashant Singh, another Code for America fellow, was excited about the project and gave me lots of feedback. Prashant was using my project to generate large static maps from the commandline, and he gave some feedback on his experience doing similar work with Mapnik. Prashant and two other Fellows, Alicia Rouault and Matt Hampel, would subsequently build a business on top of it.

On June 5, 2012 I sent this email to Eric Gundersen at Mapbox:

I haven’t done a big writeup yet. I’m hoping to submit to NACIS for their October conference, but I’m still trying to clean up the code, modularize it, and write tests and documentation.

General backstory: I had been playing around a lot with TileMill and Mapnik and trying to programmatically generate map tiles; at CfA we have a lot of big, dynamic data and I was trying to set up an automated tile renderer. Then I came across a Tom Carden project where he was use Node-Canvas to render tiles… and then I discovered a node-canvas module that would run on Heroku… and by that point I was in love with the idea of a low-dependency (compared to mapnik) on-the-fly tile rendering implementation.

From there, I wanted to see how close I could get to a full-blown TileJSON implementation. I had my coworker Rob Brackett write me a Javascript UTFGrid implementation and I hooked that up to the tile rasterizer. And bam. It’s clunky as hell, and sort’ve slow (it’s rendering an entire shapefile then cropping it down for every tile rather than spatially indexing the features), but I think it has potential. 

I think the next step (in addition to cleanup and documentation) is loading up some OSM metro data and actually seeing how the performance compares to Mapnik. Also, while I can’t foresee implementing something like Cascadenik, node-canvas gives you direct access to the graphics renderer and it might be useful for creating boutique maps with graphical flourishes that Mapnik hasn’t implemented… and of course for creating layers with dynamic data.

Let me know if you have any specific questions or ideas you’d like me to try to implement or use as demos. Thanks for the interest!

Alex

Alex Yule, another Code for America Fellow, and an actual experienced cartographer, was also interested. Alex would build a proper database adapter layer and the actual spatial indexing functionality that all of my previous emails yolo. Alex joined Rob and my presentation proposal at NACIS. This was our abstract:

NodeTiles: Joyful Map Tile Rendering with Node.js

Mapnik has become the de facto open-source standard for rendering map tiles. While Mapnik is extremely powerful, it can be difficult to set up and deploy. We present NodeTiles, a lightweight, JavaScript-based, open-source map tile renderer that is easy to deploy, use, and extend. Built to support applications with dynamic data, NodeTiles offers an accessible and cloud-friendly alternative to Mapnik. While still in early-stage development, features on the road-map include styling with the CSS-based Carto language for compatibility with MapBox TileMill, UTFGrid generation for client-side interactivity, and data adaptors for PostGIS and Shapefiles.

NACIS

The NACIS (North American Cartographic Information Society) conference was October 17-19, 2012 in Portland, Oregon. Alex and Rob and I had gotten an AirBnB and I mostly remember us doing a lot of last-minute implementing. Alex built a really nice Postgres Adapter plugin and Rob was reimplementing Cascadenik (“CSS for Maps”) somewhere between Javascript and Cairo; there was a deep-dive into blitting. We presented at a breakout called “Slippy Maps”.

Afterwards, I remember riding BART back from the airport when we arrived home in San Francisco. I was talking with a maybe-a-big-deal person from the map-tech community, and they asked me something pointed like “But how much did you really contribute to NodeTiles?” I said something like “It was a team effort” and then it got really quiet. In hindsight that was probably a job interview. And also fuck that, it was a team effort.

That’s it

During Fall of 2012 Code for America Fellowship was ending and interviewing as an inexperienced engineer is freaking hard (and also incredibly dumb, but those are different stories). So I mostly put down NodeTiles. And also:

  • Going from something that’s a tech demo to something understandable (“What the fuck are you talking about”) and usable by outsiders is hard.
  • The sheer difficulty of spatial work. That dumb NodeTiles logo took me hours just to get the tooling together to just like, draw straight lines on a globe to say “NODETILES”.
  • Maps are a commodity, and also if you need to dynamically map a billion+ polyons (I’ve been informed that today there is Postgres MVT) and you need a pipeline for auth and anti-scrape and billing and raster and…. well, god bless you.
  • I leaned into some questionable architectural decisions to make NodeTiles more Javascripty, splitting up the front and backends, and modularizing all the different pieces into their own packages. In hindsight that was a lot of valueless work that only introduced friction into building the tool and delivering the value. That’s on me; never forget.
  • Given that this is an email-based retrospective, I will admit I found some emails from kinda big deals like Stamen that I didn’t respond to. I dunno why I didn’t respond; probably burnout. If that was you, it wasn’t personal, and I’m happy with the path I’ve taken, and I hope you are too 🤗

NodeTiles is still up on GitHub. If you can get node-canvas linking to cairo (memories of this seems like a fever dream), NodeTiles is really cool. Maybe you’ll do something neat with Nodetiles ❤️


We're all just people here, even platforms

In my presentation of how my small engineering team helped deliver food stamps to millions of Californians, I talked about a common pathology of engineers: a desire to build the equivalent of thousand-year clocks that will run self-contained without human intervention. You see it crop up in different forms, the good ways of “working yourself out of a job” and the bad ways of platinum plating and astronaut architects.

And I’ve become become aware of that pathology affecting how engineers perceive the labor of other people: they don’t, not the people part. And that’s bad.

To be fair, not seeing the people isn’t just an engineering pathology. We talk about products, and services, and value, and how capitalist corporations are simply slow AI. And I’ve been working with a leadership coach and spending a fair bit of time contemplating what it means to do something larger than myself but within the realm of human endeavour. So please go with me here.

Platforms. I’ve spent a lot of my career working on X-as-a-Platform. Which is the idea that it’s a good thing if the things in our lives become analogous to vending machines, or FedEx status pages: we press the button on the machine, and we get what we want, and if not now, then the machine will tell us exactly when.

But this idea of platforms, the machine, break down when the machine… breaks down, or just changes. When the good sandwich cookies are out, or they get replaced with the bad sandwich cookies, or when there are no sandwich cookies at all because it’s Tuesday morning and deliveries normally happen on Monday and Monday was a holiday. Then we’re confronted with a reality: you, and I, and the people who stock the machine, and build the machine, and the people who make the decisions about what to stock it with, or when, and how, and why….

We are all simply harried, overworked bags of dirty water that are winging it and doing our best balancing conflicting business needs, and complicated lives and health and families and concerns and motivations completely unrelated to the good sandwich cookies and your obtaining them. I’m sorry.

We can agree: it sure would be nice if the machine had the sandwich cookies you wanted.

Or not: my agreement could also be the pathology talking. The machine is not the human endeavor here… though my sympathy for your situation (and our shared pathology) could be.

This particular line of thought was triggered by reading this passage from James Bennet’s “Yes, I have opinions on your open source contributions” about some drama going on around the situation of the people who run the PyPI Python package repository wanting to add additional security requirements on the people who publish packages to said repository to protect the people who download packages from said repository and thus reduce support demand on said repository maintainers by preventing packages from being compromised (analogus some drama is playing out in my world of Ruby too):

If you believe nobody has the right to ”demand” an open-source maintainer do something or abide by some policy or restriction, then that ends the argument in more ways than people are appreciating. If you just want to say “nobody can demand I do this”, then OK, but you also can’t demand PyPI — which is an open-source project, too — do any particular thing or abide by any particular policy you’d like, which more or less removes any grounds you might have had to criticize their account security approach. They don’t owe you anything and don’t have to do what you want them to do, the end.

But a lot of people in comment threads are trying really hard to figure out a way to impose requirements and standards on PyPI’s maintainers but not on anyone else, which then contradicts the “it’s open-source, you can’t demand anyone do anything” basis of the whole argument. Somewhat amusing are people who try to argue that PyPI has a lot more power to affect people and so should be restricted more, which is an equally good argument for imposing on people who maintain major packages.

And there’s a lot more.

To follow my thread of before, there’s a lot of demanding going on that the people, who are inseparable from the package repository, be vending machines. And what, to me, sounds like a fair and reasonable counterpoint being that people are not vending machines. And we should go with that.


Worknotes: Week 9

Two months! In my last update I wrote about an overwhelming sense of normalcy. That has continued, in a good way.

I am making good pace at completing my Engineering Manager bingo card. So far I have:

  • Worked with team and directors to write out quarterly OKRs, and close out the previous quarters
  • Gone through (well, shadowed) the half-yearly performance review process
  • Worked with a report through their departure from the team
  • Participated in the candidate interview loop, though not yet as a hiring manager

Something I’m inspired by

Writing OKRs with my team, boss, grandboss, and peer managers has been really, really, nice.

  • My team has been open within the OKR writing process, and creative, and participatory. I fumbled a bit trying to design an async but consensus Enthusiasm/Complexity matrix, but it’s been a great resource for me to understand the backlog and the team’s interests.
  • My boss and grandboss have been understated , but driving the importance of OKRs. I’ve particularly appreciate them say “Let’s get it right, but it’s also just a Google Doc and we can change it”
  • My peer managers as bar raisers in the process. We write OKRs for the department within the same document and I’ve appreciated getting comments and questions about consistency and measurements and categorizations.

I think planning is a fun challenge, with the two things that I focus on being:

  • Strategic Planning vs Operational Planning. In my sideline as a strategic planning consultant, separating out these threads is the work.
  • Team participation. I wasn’t surprised that participatory OKR planning was a stretch. At my previous jobs it’s not uncommon to have coworkers go from griping about long participatory planning meetings, to then asking “I don’t understand how the team prioritizes work.” Sometimes that can mean “I don’t agree with what came out of planning” but it frequently can mean “I didn’t see that planning as the venue for what I want to advocate for.”

I’m still uncomfortable writing essays in Slack, but I did write this for the team:

OKR thoughts: It might be interesting to explain how I view the OKRs in case it changes your feedback about them.

I write OKRs is that they’re a summary of what the team wants to do, to be communicated upwards. And then we expect management/leadership to protect/fund those activities over the duration of the quarter.

So they’re things that we believe (hopefully, feedback wanted) :

  • we’re enthusiastic about doing (most importantly)
  • AND we think we can reasonably accomplish during the quarter (maybe with a bit of stretch, but that should come from us)

And then that gets sent upwards, and (usually, in my experience elsewhere) Leadership says “great! let us know how we can help.” And if there is feedback, it’s usually of the form of “do you think this falls more into X or Y bucket?” (because they have to write their OKRs) and then maybe it’s a conversation. I’ve seen Leadership start meddling when a team doesn’t put forward a confident set of objectives, not usually in opposition to them. They’re part of a team umbrella ☂️

I have never seen OKRs be inflicted on a team; if it feels that way, I think that sucks. Hence why I’m wanting to explain my perspective in case that’s new.

Bring thoughts to our Sync Meeting next Tuesday, or add them to the OKR chat above, or DM me.

Thank you for coming to my TED Talk 😃

Something I’m challenged by

One way you might design a performance review process is to combine:

  • Evaluative feedback, simple quantitative metrics (does not meet, meets, exceeds) expectations, grounded against a career ladder or functional job description.
  • Coaching and appreciation, qualitative narrative about past contributions and future opportunity and explains the gaps between the true work and the ideals of the career ladder.
  • Unifying economic model for salary adjustments (and bonus, new to me) and promotions that answers what the company “recognizes” (“recognition” is how across my career I hear ICs talk about their perceived match between personal/team contributions and compensation/hierarchy)

The challenge of these systems (like my essay on OKRs above) is keeping them simple enough to be transparent, while recognizing that the map is neither the landscape, nor the expedition. I think there is room for improvement in all things, and I haven’t yet seen any of the worst pathologies of my past (like a long ago director who pushed back against a transparent career ladder because of their fear people would “game it”). I’m hoping I remember all this 6 months from now when it kicks off again.

What’s next

I get to see how the team executes on our OKRs and how our quarterly engineering rotation kicks off. I’m excited for both.


Laws of Spacecraft and Software

Lots of similarities between Akin’s Laws of Spacecraft Design and software management; via AJ’s weekly email:

  1. In nature, the optimum is almost always in the middle somewhere. Distrust assertions that the optimum is at an extreme point.

  2. (Shea’s Law) The ability to improve a design occurs primarily at the interfaces. This is also the prime location for screwing it up.

  3. A bad design with a good presentation is doomed eventually. A good design with a bad presentation is doomed immediately.

  4. Capabilities drive requirements, regardless of what the systems engineering textbooks say.

  5. (McBryan’s Law) You can’t make it better until you make it work.

  6. If there’s not a flight program, there’s no money. If there is a flight program, there’s no time.


Worknotes: Week 5

I just had my 1-month anniversary. The new job feels…. normal 🤷‍♀️ It’s 1:1s and sensemaking (dot-connecting, aligning, stortytelling) and gently holding and sharing and developing opinions about how people should collaborate in the worksplace and engineering the infrastructure that supports that. I dunno, given that I’m still working from home, it’s all still people stuff just different people. One of those Boasian “variations within groups are greater than variations between groups” things. People are great!

Something I’m inspired by

I’ve observed a lot of reinforcement of goals and values. I’ve been impressed seeing my team jump on an issue and not just say “I can help” but also “Our team’s purpose is to help.” Or seeing my Director hop in a comment and not just say “Great work” but also “This is a great example of our group’s charter”.

I think the majority of the feedback a manager should be giving is shining a spotlight on the things someone is already doing that are good and meaningful, and I’ve been inspired to see that in action from others.

Something I’m thinking about

I’ve been working through Lara Hogan’s “Questions for our first 1:1”, which is part of my personal manager runbook.

The question “How do you prefer to receive recognition?” gets spicy answers! I’m managing a very high level team and the answers closely line up with my own high-level friends and high-level former coworkers and myself: people are uncomfortable with recognition.

Which is… a not unreasonable reaction. In the words of a close friend “This is total shit, but… thanks, I’m glad you like it.” When I think about my own reaction, I attribute it to navigating a lot of intersecting supremacy cultures (conscious and unconscious) which are complicated: perfectionism, humbleness, honest practice, a desire to recognize all contributors (which has its own recursive sympathy).

I get it. I think about how much self-work I’ve done in my own life to reply to “I like your X” with simply “Thanks!” (and not “oh, and I like your..” or “oh, it’s not that great”).

What’s next

Two quarterly activities are upcoming that I’m excited to be organizing for the first time: engineering rotations and OKR setting. I’m sure I’ll learn a lot.


Weeknotes: Week 0

I started a new job midweek this week at GitHub, managing their Ruby Architecture team. I love the team’s mission:

Making it easy for our engineers to create, deliver, and operate best-of-class Ruby and Rails applications, and sharing the best of it with the world.

I also took about 2.5 weeks in between leaving Code for America and starting this job, so I’m feeling fresh and ready for several weeks of official onboarding, and several months of growing into the role.

Something I learned

GitHub is heavily into written documentation. “If it doesn’t have a URL, it didn’t happen.”. And not just cross-referencing, but emoting and emoji-ing, and being, well, extra. Writing and communication has been reinforced a lot during onboarding, more even than the content itself. Which makes sense: if you understand how the organization communicates, you can seek answers independently.

Something I was inspired by

Despite formal onboarding being my number one focus, I’ve been having casual 1:1s with my team. They’re great! I’ve been inspired by the nuance and understanding they bring to the work. On its own, being a service team is hard, and corporate open source is hard. I’ve found myself heavily nodding along hearing them discuss the challenges of moving people forward. It’s brought to surface a few thoughts and memories:

  • Of being a frontend lead at Pantheon and the challenges of getting platform-team resources to build up to the outcome and vision we all agreed on, but that had some uncomfortable zigs and zags to get there. A case of make the change easy (which can be hard), then make the easy change.
  • My falling out of the Drupal ecosystem as it developed more in line with the needs of full-service agencies than of solo devs and configurers like myself. As one of my colleagues admitted this week, our developers aren’t running “rails new” a whole lot and that’s something to be mindful of how it shapes the contributions.
  • “If you’re leading and no one is following, you’re just out for a walk.”

Working the problem

From An Astronauts Guide to Planet Earth by Chris Hadfield:

Feeling ready to do something doesn’t mean feeling certain you’ll succeed, though of course that’s what you’re hoping to do. Truly being ready means understanding what could go wrong – and having a plan to deal with it. You could learn to scuba dive in a resort pool, for instance, and go on to have a wonderful first dive in the ocean even if you had no clue how to buddy breathe or what to do if you lost a flipper. But if conditions were less than ideal, you could find yourself in serious danger. In the ocean, things can go wrong in one breath, and the stakes are life and death. That’s why in order to get a scuba license you have to do a bunch of practice dives and learn how to deal with a whole set of problems and emergencies so that you’re really ready, not just ready in calm seas.

For the same sort of reasons, trainers in the space program specialize in devising bad-news scenarios for us to act out, over and over again, in increasingly elaborate simulations. We practice what we’ll do if there’s engine trouble, a computer meltdown, an explosion. Being forced to confront the prospect of failure head-on – to study it, dissect it, tear apart all its components and consequences – really works. After a few years of doing that pretty much daily, you’ve forged the strongest possible armor to defend against fear: hard-won competence.

Our training pushes us to develop a new set of instincts. Instead of reacting to danger with a fight-or-flight adrenaline rush, we’re trained to respond unemotionally by immediately prioritizing threats and methodically seeking to defuse them. We go from wanting to bolt for the exit to wanting to engage and understand what’s going wrong, then fix it.

Early on during my last stay on the ISS, I was jolted to consciousness in the middle of the night: a loud horn was blaring. For a couple of seconds I was in a fog, trying to figure out what that unpleasant noise was. There were four of us in the American section of the Station then, and like prairie dogs, we all poked our heads up out of our sleep pods at the same time to look at the panel of emergency lights on the wall that tell us whether we should be concerned about depressurization, toxicity or some other potential fatal disaster. Suddenly all of us were wide awake. That deafening noise was the fire alarm.

A fire is one of the most dangerous things that can happen in a spaceship because there’s nowhere to go; also, flames behave less predictably in weightlessness and are harder to extinguish. In my first year as an astronaut, I think my response to hearing the alarm would have been to grab an extinguisher and start fighting for my life, but over the past 21 years that instinct has been trained in, represented by three words: warn, gather, work.

“Working the problem” is NASA-speak for descending one decision tree after another, methodically looking for a solution until you run out of oxygen. We practice the “warn, gather, work” protocol for responding to fire alarms so frequently that it doesn’t just become second nature; it actually supplants our natural instincts. So when we heard the alarm on the Station, instead of rushing to don masks and arm ourselves with extinguishers, one astronaut calmly got on the intercom to warn that a fire alarm was going off – maybe the Russians couldn’t hear it in their module – while another went to the computer to see which smoke detector was going off. No one was moving in a leisurely fashion, but the response was one of focused curiosity; as though we were dealing with an abstract puzzle rather than an imminent threat to our survival. To an observer it might have looked a little bizarre, actually: no agitation, no barked commands, no haste.

The next step is the gather, so we joined the Russians in their part of the Station to start working on the problem. How serious was the threat? So far, all the signs were reassuring. We couldn’t smell smoke of see flames. Maybe one little wire had melted somewhere, or the detector was responding to dust. We talked to Mission Control in Houston and in Moscow, but as we investigated, checking the module where the detector had been triggered, it seemed more and more likely that we were dealing with a simple malfunction. Finally, everyone agreed that it had been a false alarm, and we headed back to our sleep stations. An hour later, when the fire alarm sounded again, we repeated the warn, gather, work protocol just as before. The response was similarly calm, though not perfunctory – possibly something had been slowly smoldering for the past hour. As it turned out, nothing had. The detector was a lemon, that’s all. I remember thinking, “That was a little like a sim, only better, because now I get to sleep.”

I doubt anyone’s heart rate increased by more than a beat or two while we were dealing with those fire alarms, even during the first minutes when the threat of a raging inferno seemed most real. We felt competent to deal with whatever happened – a sense of confidence that comes directly from solid preparation. Nothing boosts confidence quite like simulating a disaster, engaging with it fully, both physically and intellectually, and realizing you have the ability to work the problem. Each time you manage to do that your comfort zone expands a little, so if you ever face that particular problem in real life, you’re able to think clearly.