Posts about things.
While thinking a lot about dependencies and disaster plans, I started noticing the fire escapes that are a staple of New York City buildings. The result was a talk called The History of Fire Escapes.
Reference material: http://noidea.dog/fires
Being Glue originated as a comment on an internal Google Plus post when I worked at el Goog. I’d used the expression “glue work” in passing, and someone asked what I meant by it. The reply became a standalone post and then an internal document (which as far as I know is still being circulated). A couple of years later, I proposed it as a talk for Write/Speak/Code NYC. I’d left Google by then and wasn’t even sure it would resonate with folks in other companies. Apparently it did :-)
Athenahealth invited me to give the talk at their office and the video is on YouTube.
Abstract: Your job title says "software engineer", but you seem to spend most of your time in meetings. You'd like to have time for code, but nobody else is unblocking the junior engineers, maintaining the relationship with your sister team in the other office, updating the roadmap, talking to teams whose projects overlap with yours, noticing the things that got dropped, asking questions on design documents, and making sure that everyone's going roughly in the same direction. If you stop doing those things, the team will function less well. But now someone's suggesting that 'you might be happier in a less technical role'.
'Glue' work often lands on the only woman on the team, and it needs to be framed carefully. If you display this kind of leadership early in your career, there's a real risk of being seen as 'not technical enough' and getting pushed into a career path that wasn't your first choice. If you'd like to be a senior engineer, being good with humans does not close that door. If you'd prefer to do something else, you should choose your path deliberately.
Here’s a talk about how to get you recognised as the technical leader that you are.
A raspberry pi project to start and stop albums on my sonos using amazon dash buttons. Full blog post at https://noidea.dog/blog/sonos-jukebox. Code and documentation at http://github.com/whereistanya/sonos-jukebox
I like to code on long train journeys, usually with my small kid beside me asking what I’m doing. Here’s a game I made her over several train trips.
Anyone who does a bunch of public speaking will eventually do a talk about public speaking and this is mine.
Blog post about finding images to use: http://noidea.dog/blog/stock-photography
If you have more than a few microservices, their interdependencies get hard to reason about. I worked for a few years on a project to manage and control microservice dependencies and to make sure it would be possible to turn the company’s tech stack back on if we ever turned it off.
I also wrote a talk about it called “Have you tried turning it off and turning it on again?”: https://www.youtube.com/watch?v=xvk4RFGsrWo
USENIX review of the talk: https://www.usenix.org/blog/review-disaster-recovery
Graphviz examples: https://github.com/whereistanya/graphviz
And O’Reilly interviewed me about it: https://www.oreilly.com/ideas/creating-better-disaster-recovery-plans
In 2011 I travelled from one side of the Atlantic to the other — Coney Island, New York to Salthill, Galway, mostly by land. I needed to fly over the Pacific (LA to Tokyo) and the Caspian Sea (Bukhara to Baku), but for the rest of the time it was trains, boats, taxis, buses and my own two feet.