I saw your smart home through the video on Smart Home Solver. I went to check out your site, hoping to find more info on your “baby monitoring” setup you did through your Apple TV, Unifi stack, and HA. I have the exact same setup, and my wife and I are about to welcome our firstborn. Could you point me in the right direction on how you managed to make all of that happen? Thank you. - Caleb L., Ohio

First of all, thank you for the question Caleb! Congrats!

While we do have an offline baby monitor for our baby sitter, we use Ubiquiti cameras as our primary monitoring setup, mostly via the Protect app on our phones. The motion event patterns help us see how the kids are sleeping, and we use the AI baby crying detection to turn on our bedroom lights overnight!

Unfortunately, you can only listen to the audio from multiple cameras using the Unifi web app. Also, we like to keep our phones put away whenever possible, so we were looking for a way to display the cameras on our TV and Apple Watches.

With those problems in mind, set out to 1) combine the two streams into a single feed and 2) get the feed into Apple Home.

To combine the two streams, I used the go2rtc Home Assistant Add-on/App. Under config, I added:

streams:
  combined:
    - "exec:ffmpeg -rtsp_transport tcp -i rtsp://CAMERA_A_IP:7447/xxx -rtsp_transport tcp -i rtsp://CAMERA_B_IP:7447/yyy -filter_complex [0:v]transpose=1[left];[1:v]transpose=1[right];[left][right]hstack=inputs=2,scale=1920:1080:force_original_aspect_ratio=decrease,pad=1920:1080:(ow-iw)/2:(oh-ih)/2:black[out];[0:a][1:a]amix=inputs=2:duration=longest[aout] -map [out] -map [aout] -c:v libx264 -preset ultrafast -tune zerolatency -c:a aac -f rtsp {output}"

This combines the two Unifi cameras (note the rtsp protocol, changed port number and no enableSrtp flag), rotates them to be vertical to fit in a single frame, merges the audio, and outputs a single RTSP feed.

Then, in the Scrypted Home Assistant Add-on/App, add an RTSP camera with the RTSP Stream URL of rtsp://homeassistant.local:8554/combined. From there, it’s simply a matter of scanning the HomeKit QR code for the camera to add it to Apple Home!

My wife and I love birding. Our interest in the hobby intensified during COVID, spending many mornings at our favorite birdwatching spot.

When Merlin Bird ID added Sound ID in 2021, we were hooked immediately! It felt like something out of Harry Potter to be able to have our phones tell us what bird we were hearing, even if we couldn’t see it. About a year later, the BirdNET-Pi project made it easy to run the Sound ID model locally. One of the audio sources supported was the RTSP output, which I used with two of our Ubiquiti cameras.

While it worked well at identifying birds accurately, the app crashed randomly. First, I tried installing BirdNET-Pi as a Home Assistant Addon, as my HA hardware was vastly overprovisioned compared to the Raspberry Pi. This reduced the crashes, but did not eliminate them. A few months later, a fellow birding and Home Assistant enthusiast recommended I try BirdNET-Go, which is a rewrite of BirdNET-Pi with improved stability and performance. This fixed the reliability issues once and for all and I haven’t had any crashes since then.

Sifting through the data

With the stability issue resolved, I had a bigger problem: what to do with all of this data? While BirdNET-Go provided a nice dashboard for viewing detections, I wanted to find a way to surface insights about the data that were interesting to me without having to comb through the feed. Around the same time, I was developing the latest version of Timeframe, my e-paper dashboard system. Caitlin suggested we highlight the most interesting detection of the past day.

After trying a few different algorithms, I ended up with a simple REST sensor. The sensor fetches the summary data from BirdNET-Go, filters it to only include detections from the past day, then sorts them by the bird most recently heard for the first time:

# configuration.yaml
sensor:
  - platform: rest
    resource: http://homeassistant.local:8080/api/v2/analytics/species/summary
    scan_interval: 300
    name: "Most Interesting Bird"
    unique_id: birdnet_most_interesting
    value_template: >
      {% set cutoff = (now() - timedelta(hours=24)).strftime('%Y-%m-%d %H:%M:%S') %}
      {% set birds = value_json
        | rejectattr('common_name', 'eq', 'Engine')
        | selectattr('last_heard', 'ge', cutoff)
        | sort(attribute='first_heard', reverse=true)
        | list %}
      {{ birds[0].common_name if birds | length > 0 else 'Unknown' }}

It’s been fun to see new species appear for the first time as an early spring arrives here in Colorado:

See https://news.ycombinator.com/item?id=47113728 for a lively discussion of this post.

When Caitlin and I got married a decade ago, we set an intention to have a healthy relationship with technology in our home. We kept our bedroom free of any screens, charging our devices elsewhere overnight. But we missed our calendar and weather apps.

Initial prototypes

So I set out to build a solution to our problem. First, I constructed a Magic Mirror using an off-the-shelf medicine cabinet and LCD display with its frame removed. It showed the calendar and weather data we needed:

But it was hard to read the text, especially during the day as we get significant natural light in Colorado. At night, it glowed like any backlit display, sticking out sorely in our living space.

I then spent about a year experimenting with various jailbroken Kindle devices, eventually landing on design with calendar and weather data on a pair of screens. The Kindles took a few seconds to refresh and flash the screen to reset the ink pixels, so they only updated every half hour. I designed wood enclosures and laser-cut them at the local library makerspace:

Software-wise, I built a Ruby on Rails app for fetching the necessary data from Google Calendar and Dark Sky. The Kindles woke up on a schedule, loading a URL in the app that rendered a PNG using IMGKit. The prototype proved e-paper was the right solution: it was unobtrusive regardless of lighting:

A more reliable approach

The Kindles were a hack, requiring constant tinkering to keep them working. It was time for a more reliable solution. I tried an OLED screen to see if the lack of a global backlight would be less distracting, but it wasn’t much better than the Magic Mirror:

So it was back to e-paper. I found a system of displays from Visionect, which came in 6”/10”/13”/32” sizes and could update every ten minutes for 2-3 months on a single charge:

The 32” screen used an outdated lower-contrast panel and its resolution was too low to render text smoothly. The smaller sizes used a contrasty, high-PPI panel. I ended up using a combination of them around the house: a 6” in the mudroom for the weather, a 13” (with its built-in magnetic backing) in the kitchen attached to the side of the fridge, and a 10” in the bedroom.

The Visionect displays required running custom closed-source software, either as a SaaS or locally with Docker. I opted for a local installation on the Raspberry Pi already running the Rails backend. I had my best results pushing images to the Visionect displays every five minutes in a recurring background job. It used IMGKit to generate a PNG and send it to the Visionect API, logic I extracted into visionect-ruby. This setup proved to be incredibly reliable, without a single failure for months at a time.

First customer pilot

Visiting friends often asked how they could have a similar system in their home. Three years after the initial prototype, I did my first market test with a potential customer. At their request, I experimented with different formats, including a month view on the 13” screen:

Unfortunately, the customer didn’t see enough value to justify the $1000 price tag (in 2019!) for the 13” device, let alone anything I’d charge for a subscription service. At around the same time, Visionect started charging a $7/mo per-device fee to run their backend software on premises with Docker, after years of it being free to use. I’d have needed to charge $10/month, if not more, for a single screen!

An unexpected pivot

In late 2021, the Marshall Fire destroyed our home along with ~1,000 others. Our homeowner’s insurance gave us two years to rebuild, so we set off to redesign our home from the ground up.

Around the same time, Boox released the 25.3” Mira Pro, the first high-resolution option for large e-paper screens. Best of all, it could update in realtime! Unlike the Visionect devices, it was just a display with an HDMI port and needed to be plugged into power. A quick prototype powered by an old Mac Mini made it immediately obvious that it was a huge step forward in capability. The larger screen allowed for significantly more information to be displayed:

But the most compelling innovation was having the screen update in realtime. I added a clock, the current song playing on our Sonos system (using jishi/node-sonos-http-api) and the next-hour precipitation forecast from Dark Sky:

The working prototype was enough to convince me to build a place for it in the new house. We designed a “phone nook” on our main floor with an art light for the display:

We also ran power to two more locations for 13” Visionect displays, one in our bedroom and one by the door to our garage:

Backend overhaul

The real-time requirements of the Mira Pro immediately surfaced performance and complexity issues in the backend, prompting an almost complete rewrite.

While the Visionect system worked just fine with multiple-second response times, switching to long-polling every two seconds put a ceiling on how slow response times could be. To start, I moved away from generating images. The Visionect folks added the ability to render a URL directly in the backend, freeing up resources to serve the long-polling requests.

Most significantly, I started migrating towards Home Assistant (HA) as the primary data source. HA already had integrations for Google Calendar, Dark Sky (now Apple Weather), and Sonos, enabling me to remove over half of the code in the Timeframe codebase! I ended up landing a PR to Home Assistant to allow for the calendar behavior I needed, and will probably need to write a couple more before HA can be the sole data source.

With less data-fetching logic, I was able to remove both the database and Redis from the Rails application, a massive reduction in complexity. I now run the background tasks with Rufus Scheduler and save data fetching results with the Rails file store cache backend.

In addition to data retrieval, I’ve also worked to move as much of the application logic into Home Assistant. I now automatically display the status of any sensor that begins with sensor.timeframe, using a simple ICON,Label CSV format.

For example, the other day I wanted to have a reminder to start or schedule our dishwasher after 8pm if it wasn’t set to run. It took me about a minute to write a template sensor using the power level from the outlet:

{% if states('sensor.kitchen_dishwasher_switched_outlet_power')|float < 2 and now().hour > 19 %}
utensils,Run the dishwasher!
{% endif %}

In the month since adding the helper, it reminded me twice when I’d have otherwise forgotten. And I didn’t have to commit or deploy any code!

Today

Since moving into our new home, we’ve come to rely on the real-time functionality much more significantly. Effectively, we’ve turned the top-left corner of the displays into a status indicator for the house. For example, it shows what doors are open/unlocked:

Or whether the laundry is done:

It has a powerful function: if the status on the display is blank, the house is in a “healthy” state and does not need any attention. This approach of only showing what information is relevant in a given moment flies right in the face of how most smart homes approach communicating their status:

The single status indicator removes the need to scan an entire screen. This change in approach is possible because of one key difference: we have separated the control of our devices from the display of their status.

What’s next

I continue to receive significant interest in the project and remain focused on bringing it to market. A few key issues remain:

Hardening for deployment

While I have made significant progress in handling runtime errors gracefully, I have plenty to learn about creating embedded systems that do not need maintenance.

Home Assistant integration

There are still several data sources I fetch directly outside of Home Assistant. Once HA is the sole source of data, I’ll be able to have Timeframe be a Home Assistant App, making it significantly easier to distribute.

Hardware cost and complexity

The current hardware setup is not ready for adoption by the average consumer. The 25” Boox display is excellent but costs about $2000! It also doesn’t include the hardware needed to drive the display. There are a couple of potential options to consider, such as Android-powered devices from Boox and Philips or low-cost options from TRMNL.

Conclusion

Building Timeframe continues to be a passion of mine. While my day job has me building software for over a hundred million people, it’s refreshing to work on a project that improves my family’s daily life.

TL;DR: Use the Home Assistant MacOS app to control smart lights based on video call status.

I often wear noise cancelling headphones to help me focus, but they make it difficult to hear a knock on the door. I’m also in meetings quite a bit, when a door knock is less welcome. While I try to keep my calendar up to date so my wife knows when I’m on a call, I’ll occasionally have ad-hoc conversations for pairing, etc.

I recently set up a system to indicate whether I am listening to music or on a video call, using Zigbee night lights from Third Reality, one in the hallway and another in my office so I can know what the hallway light is set to.

In Home Assistant, I created a helper called Office audio state using sensor data from the Home Assistant app running on my personal and work laptops. It returns input, output, or off (be sure to replace the sensor names with yours):

{% if states("binary_sensor.joelhawksley_audio_input_in_use") == "on" or states("binary_sensor.joel_audio_input_in_use") == "on" %}
input
{% elif states("binary_sensor.joelhawksley_audio_output_in_use") == "on" or states("binary_sensor.joel_audio_output_in_use") == "on" %}
output
{% else %}
off
{% endif %}

I then have an automation listening to changes to the helper (debounced for 5 seconds to avoid false triggers from momentary changes) and switching between scenes on the lights (blue for video call, yellow for listening, off otherwise):

alias: OFFICE Hallway nightlight audio input indication
description: ""
triggers:
  - trigger: state
    entity_id:
      - sensor.office_audio_state
    for:
      hours: 0
      minutes: 0
      seconds: 5
conditions: []
actions:
  - if:
      - condition: state
        entity_id: sensor.joelhawksley_audio_state
        state:
          - input
    then:
      - action: scene.turn_on
        metadata: {}
        data: {}
        target:
          entity_id: scene.upstairs_hallway_night_light_blue
    else:
      - if:
          - condition: state
            entity_id: sensor.joelhawksley_audio_state
            state:
              - output
        then:
          - action: scene.turn_on
            metadata: {}
            data: {}
            target:
              entity_id: scene.upstairs_hallway_night_light_yellow
        else:
          - type: turn_off
            entity_id: 068da57
            domain: light
          - type: turn_off
            entity_id: 46e8791
            domain: light
mode: single

As a bonus, the night lights also serve as Zigbee routers, extending the range and stability of our Zigbee network!

A couple of months ago, part of Amazon Web Services was down for a good chunk of a Monday, including the cloud backend for the Happiest Baby Snoo, a truly wonderful piece of baby-rearing technology that we’ve used with both of our kids.

Unfortunately, the backend outage broke notifications for the device, including those triggered when your kiddo needs attention. The notifications served as a backstop in case we didn’t hear our little guy fussing on the monitor or down the hallway. They also happened to be non-critical, meaning they wouldn’t break through focus modes on our Apple devices. I set out to fix all these issues and ended up creating a more useful integration than the existing implementation.

The foundational change I made was using a power monitoring outlet (I like the Third Reality Zigbee ones that are ~$10) that provides a real-time power usage sensor. I plugged the Snoo in and was relieved to see the following power data over 24 hours:

The data clearly shows when the device is turned on or not. As the Snoo powers down when your kid needs attention, this was all the information I needed to build out my automations without any dependence on the cloud. Here is what I ended up with:

---
config:
      theme: redux
---
flowchart TD
        A(["Snoo power level drops below 4 watts"])
        A --> B{"If nursery door 
        is closed"}
        D -->|False| F["Send critical notification"]
        B -->|True| D{"If time is overnight &
        bedroom door is open"}
        D -->|True| E["Turn on bedroom
        table lamps,
        turn off bedroom
        noise machine"]

Unlike the built-in Snoo notification, my local-only implementation is a critical alert, meaning it will always notify me regardless of my focus mode. Having the notification implementation under my control allowed me to also have it turn off the white noise machine in our bedroom and turn on our table lamps, making sure we didn’t sleep through the sound of the baby needing our attention! The automation only runs when the nursery door is closed, as we turn the Snoo off manually when we wake him up.

Conclusion

When I got into using Home Assistant, I didn’t appreciate the strong feelings folks had about using local-only integrations whenever possible, but now I get it. Between backend, internet, and power outages, cloud-based integrations are simply not reliable. Thankfully, Home Assistant gives us the tools to build our own automations without the need for cloud services.

Back in 2018, I installed an auto-refilling water bowl for our dog, mounting it on the wall in our laundry room. It worked well, but there was something disconcerting about having a water line under pressure, so when we moved to our new home, we didn’t take the auto-refilling bowl with us.

Recently, after we had our second child, I found myself forgetting to fill our dog’s water bowl to his liking. As part of my never-ending quest to automate any need for my ability to remember anything, I looked into options for an automated reminder.

I happened upon a Reddit post showing a setup using an Aqara leak sensor with wires attached to the leads going into the bowl. From my research at the time, this was the only leak sensor I could find that didn’t have a built-in alarm, which is important when being wet is the default state!

At first, I tried to just install the sensor right inside the bowl, but I couldn’t find a way to keep it attached reliably and it got pretty gross with all of the dog slobber.

I ended up attaching it to the wall behind our dog bowls using a velcro Command strip and running a pair of twisted wires down to the bowl.

After about four months, the battery has depleted by about 25%. Not bad! But most importantly, our dog doesn’t have to wait long for me to fill his bowl any more.

—

After receiving peer feedback that it wasn’t clear what I did as a staff engineer in my director’s organization, I began an experiment: I started keeping a daily, internally public work journal, riffing on Julia Evans’ brag doc technique. The effect was immediate. My manager and several peers were quick to praise and appreciate the transparency, and a couple other folks started their own journals too.

Having kept up the daily practice for a couple of years, I have an even greater appreciation for its usefulness. Here is why.

Motivation and reflection

Knowing I’m going to post something public to my colleagues at the end of every work day motivates me to do work worth posting about! It also serves as a point of reflection, forcing me to consider whether I used my time effectively, sparking conversations with my manager and peers about how to better allocate my time.

Accountability

Managers are busy dealing with HR and non-technical issues in addition to their technical leadership. Having a report “self-manage” makes their job easier, and my work journal is a big part of that. It also creates artifacts for sharing my impact up the leadership chain with skip-levels and beyond.

Linking the unlinkable

Not all impactful work results in a PR or issue, let alone one with my name on it. Pairing, reviewing code, and attending meetings can be just as or even more impactful than shipping PRs and writing issues. My work journal gives me a place to document these activities and describe their impact. For example, I might say:

• “Paired with peer on a tricky problem, recommending a change to their workflow to cut down on cycle time”
• “Reviewed pull request, catching potential security issue”
• “Attended team meeting, driving conversation towards an actionable plan for the team next week”

A holistic picture

My work often extends beyond specific projects, the typical nexus of coordination and reporting via issues or standup reports. For example, I might write about a new technology I evaluated for a potential future project. It is also a way to bring my whole self to work: I will occasionally include personal life entries with photos, especially when I am working across teams and don’t feel like sharing those kinds of updates with each group.

Permanent and central

While I often share some of the information in my journal elsewhere, such as on Slack (with limited retention) and in standup meetings, those forms are ephemeral. Keeping a record in a permanent and centralized format avoids link rot and eliminates the need to search for information later on.

Out of my head

I started my work journaling practice around the time that we had our first child, and thank goodness I did! These days it’s a lot harder to remember what I did the previous day, week, or before vacation. Writing my accomplishments daily reduces the amount I need to remember to almost nothing. This is especially important when switching managers, as it’s easy for context to be lost on what impact you’ve had. It’s more reliable to handle tracking your impact yourself instead of expecting others to do it.

When it’s time to write my performance self-reviews, I simply read my work journal and copy items into our review format.

Shutdown ritual

Having struggled to separate work from life as a remote worker, I’ve gotten in the habit of an end-of-day shutdown ritual. I finish and post my work journal, then power off my computer for the day. This has helped minimize how much I think about work when I’m with my family.

Conclusion

Keep an internally public, daily journal of snippets describing the impact of your work, written with the intention of adding them to your performance review.

Thanks to Tim, Jon, Matt and Siddharth for helping with this post and to the folks at Boulder Ruby whose discussion after my talk earlier this month inspired it.

Bio: Joel is a staff software engineer at GitHub, working on the health of the GitHub.com Rails monolith.

Abstract: You’re at senior, but you’re hungry for more. What’s next? In this talk, we’ll attempt to define the staff role and help you decide if it’s a good fit for your career.

Before I get started, a quick survey: how many people here would call themselves Junior? Senior? Staff? Something beyond?

The senior role is a crossroads. At many companies, it’s the farthest you can go as an individual contributor. You basically have one option for promotion: management. But it doesn’t have to be this way. Your journey as an individual contributor doesn’t have to stop at senior. There is sometimes another option: staff.

A little over a year ago, Jesse from Stripe gave a talk here about what it means to be a senior engineer. At the time, I took a mental note about doing a similar talk for the staff level.

A couple of months ago, I spoke at Rocky Mountain Ruby. It was great to see many of you there! The night before the conference, I was chatting with Bekki about our jobs as staff engineers and we quickly realized how different they were! To be honest with you, most conversations I have with other staff engineers go this way.

I am regularly asked: How did you get promoted? What is your job? That sounds scary, how do you survive, let alone thrive? Today I’m going to attempt to answer those questions, based on my experience and conversations I’ve had with other staff engineers inside and outside GitHub. My selfish goal is that you’ll poke tons of holes in everything I have to say so that you can help me improve this talk!

Of course, what I’m sharing here is just my opinion and not that of GitHub or any of my previous employers.

How did you get promoted to staff?

I got into software engineering through the side door. After a short but thrilling career as a news photographer, I started my career at MojoTech, a software consultancy, as a junior apprentice, back before code schools were common. From there, I was promoted to mid. Another year later, I was promoted to “lead developer,” which was more or less senior. There were no levels beyond that.

At my next job, a startup with three engineers including the CTO, I was hired as a senior. We had no level beyond senior.

I left for another startup, where my title was also senior. Six months later, I was promoted to Lead Engineer. There were maybe two dozen engineers and as a Lead, I reported to the VP of engineering. I had one engineer who reported to me, so I was basically a tech lead manager.

I joined GitHub as a mid, going down two levels. GitHub had maybe ~300 engineers at the time. We had a total of eight engineering levels: Intern, 1/2/3, senior, Staff, Principal, and Distinguished. Our system remains more or less the same today with ~1,000 engineers.

My path to a staff role at GitHub started a couple of months into the job. I had the idea for ViewComponent and I pitched it to my manager Zaid, who gave me 20% time to pursue it. After a few months, I had a working prototype, which was the basis of my first talk here at Boulder Ruby!

A year and a half after I joined, I was promoted to senior in large part due to the ViewComponent project. While at an all-company offsite, I pitched Diana, the leader of the design systems organization, on building out our design system in ViewComponent. A few months later, I asked to join her team to work on ViewComponent full time, and my request was granted.

As the summer of 2020 rolled around, there was a request for projects to address technical debt in our monolith. I proposed having folks build and adopt ViewComponents for our design system to increase the consistency and quality of our user interfaces. I ended up leading a “virtual team” of about a dozen engineers for half the year, building and adopting ViewComponents.

The following spring, I was promoted to staff for this work. I’ve now been at staff for about five years.

What is your job?

Beyond terminal

At many companies, the senior level is considered terminal, in that it’s totally OK to never go beyond senior for your entire career. At least at our GitHub, I’ve yet to hear about someone at senior being pressured to be promoted. The staff level is beyond terminal. It’s something you choose to pursue. And it can take a long time! Some folks spend a decade at the senior level before going for staff. It can be disorienting after getting promoted every two years for the earlier levels.

Scope

In general, staff engineers work at a broader scope than senior engineers, in breadth or depth.

While a senior engineer typically works at the team level, a staff engineer might work on problems that span multiple teams, potentially across different organizations. They might report to a director instead of a team-level manager, working across all of the director’s teams. That’s mostly what I’ve done.

Or, they might go deep. One analogy we use for technical depth at GitHub is about rope:

https://rewards.aon.com/en-us/insights/compensation-101/how-much-to-pay-rewards-program-design

Or, they go long. They might work on problems that take months or even years to solve, such as major product launches and migrations.

Archetypes

Perhaps the best definition of the staff role is the archetypes from Will Larson’s Staff Engineer: Tech Lead, Architect, Solver, Right Hand.

Tech lead

A Tech Lead “guides the approach and execution of a particular team. They partner closely with a single manager, but sometimes they partner with two or three managers within a focused area. Some companies also have a Tech Lead Manager role, which is similar to the Tech Lead archetype but exists on the engineering manager ladder and includes people management responsibilities.” I’ve done this four times now at GitHub, each time covering for the absence of one of my Director’s managers’. I’ve taken the Tech Lead Manager role, doing 1:1s with reports, serving as a hiring manager, and even helping with yearly reviews.

Architect

An Architect “is responsible for the direction, quality, and approach within a critical area. They combine in-depth knowledge of technical constraints, user needs, and organization level leadership.”

Most of my work on ViewComponent at GitHub has fallen into this bucket, such as when I organized the effort to migrate to Primer ViewComponents.

Solver

A Solver “digs deep into arbitrarily complex problems and finds an appropriate path forward. Some focus on a given area for long periods. Others bounce from hotspot to hotspot as guided by organizational leadership.”

My initial work on ViewComponent fell into this category. I worked with Aaron Patterson to develop a novel solution and wrote the upstream patch in Rails to make it work without a monkey patch.

Right Hand

A Right Hand “extends an executive’s attention, borrowing their scope and authority to operate particularly complex organizations. They provide additional leadership bandwidth to leaders of large-scale organizations.”

This is a role I’ve fallen into a lot. For example, I often write the initial draft of my director’s quarterly/semester/yearly/multi-year plans, surfacing ideas proposed by IC engineers. I also work on proposals for opening new engineering roles, hiring contractors, and work with third-party vendors to evaluate potential new tools and services.

So you get more scope, working in the four archetypes. Sounds pretty fun, right? I think so. Now here are some ways I’ve found to thrive in the role.

How do you thrive?

Align with archetypes

I like to use the archetypes to align with my manager to make sure our expectations are the same for a given project. I think this is useful at all levels, really. We should be regularly validating that our manager agrees with how we think about our work.

Something I’ve struggled with is seeing other staff engineers do impressive things in other archetypes and feeling like an imposter for not being like them. This is nearly always the case, as there is rarely a business need for two staff engineers that do the same thing. Continuously checking in with my manager on what I’m working on helps me overcome this worry and further define my specific version of staff.

It also speaks to a conundrum I’ve seen many seniors looking for promotion struggle with: there has to be a business need for a staff role. So if you’re on a team with other staff engineers, it’s generally harder than if no one else is at staff. I’ll be the first to admit that it was to my advantage to be the first staff engineer under my promoting director. This can feel unfair, and it is! At some point, you need to do staff-level work to be promoted to staff. There might not be any in your area, or even your company! Your manager should help you determine where staff opportunities might be, but it doesn’t hurt to ask around either.

Keep a public journal

A couple of years ago I adapted Julia Evans’ brag doc idea into a daily, internally-visible journal of what I worked on and what I listened to/read/watched. I was first motivated to do this to keep a record for self-reviews, but I quickly found that it was a helpful tool for guiding my focus towards things worth writing down, a.k.a. impactful work! It’s so easy to get bogged down in activity that has no impact. I’ve also gotten feedback that it has helped others in the organizations I work in understand my role.

Predict the future

Part of having an impact at a breadth and depth beyond senior is looking towards the future. What are the internal trends (technical and non-technical) that could affect our part of the company? What about external trends? Are there new technologies we should experiment with? What is our competition doing technically that could make our customers want to use their product?

To avoid drinking from the firehose that is Twitter/Bluesky/Hacker News, I subscribe to the Hacker Newsletter, Ruby Weekly, and other topic-specific newsletters (such as accessibility news). This was especially important when working on accessibility as the legal landscape is constantly evolving in that area. Successful staff engineers are often cited by colleagues as sources of knowledge. This even comes up in interviews: we look for staff engineer candidates to teach us something new during technical interviews.

Speak truth to power

As an IC, I’ve often had moments where I felt like leadership didn’t care enough about what I cared about, whether it was code quality, tech debt, or software craftsmanship. I see part of our job as staff engineers as representing the technical concerns of the engineering discipline to people in power outside of engineering. To be a check and balance on the product discipline by surfacing and justifying engineering-driven priorities. How to do this depends greatly on the situation, but using data is a way of creating a shared understanding of a problem.

Sometimes this is literally what you are assigned to do. I find myself being asked to weigh in on things a lot, often to settle a disagreement. It can be a risky proposition. You don’t want to parachute in and act like you know it all.

This doesn’t mean that you get to do whatever you want. In fact, it’s quite the opposite: you are expected to be in tune and aligned with the business. Being promoted to staff is a strong signal that the company trusts your technical judgement to align with the business.

Disambiguate, then delegate

I believe that a good staff engineer is continuously looking to downgrade the level of ambiguity in their work, with the goal of handing it off to someone else. Any time I’m handed a new problem, I ask myself: what will it take to have a senior or even a whole team work on this? Often, it comes through creating proofs of concept, reading papers, trying new technologies, and connecting with industry peers to validate the right solution to an ambiguous problem.

For example, I was given the ambiguous task of defining our strategy for prioritizing which parts of our application to audit and remediate first. I used our data warehouse to produce a report showing the distribution of traffic across our 2,000+ pages, highlighting which pages were used by the average user in a given week. We identified a few dozen product areas and prioritized working with those teams.

In another case, my colleague Jon was tasked with finding a replacement for our usage of Styled Components. He looked to see what others in the industry were doing, tried some new technologies (CSS Layers), and did several proofs of concept before leading a team of a half dozen engineers to make the migration to CSS Modules.

More generally, this can mean being the person in meetings who pushes for clear definitions of problems, proposed solutions, and success criteria.

Generate energy

Part of generating energy is taking the lead and initiating work, not waiting to be told what to do or given projects to work on. We expect staff engineers to be a source of creative energy. Succeeding in such a large scope of impact is very difficult if you can’t inspire others to join you on your quest. For example, when I was working on migrating our monolith to ViewComponent, a good chunk of my daily responsibilities were around motivating others, whether through pairing, hosting office hours, or writing case studies of our work’s impact.

Another big part of generating energy is building up others around you. As staff is a terminal role, there is an expectation that you won’t be hogging the opportunities to look good. In many cases, it’s the opposite! A big difference between senior and staff is how much you’re expected to focus on getting other people promoted, through mentoring and leveling up those around you. For example, I regularly help seniors write up internal and external blog posts on interesting problems they have solved.

Deliver success

We lean on staff engineers to come through when we need it most. Whether something has to ship on time, a critical project is stalled, or a service is failing SLA in a novel way, we rely on staff engineers to solve our trickiest problems. This pressure is not for everyone! I’ve only had a couple projects like this in my time here, but they have all been a thrill.

For Jon, examples of critical projects include migrating all of GitHub.com to be responsive and implementing dark mode, all with minimal regressions. Delivering success is the path to being promoted to staff. Do enough impactful things, and at some point you become so senior that it’s unfair for new seniors to have the same title.

A metaphor I like to use for this aspect is skiing: on a typical day, I ski blues. But on a powder day, I can handle the blacks. If it hasn’t snowed in a week and there’s ice everywhere, I stick to the greens. Software projects can take a similar shape: under normal conditions, you might be expected to do a typical Staff project. When the pressure is lower, you might be expected to stretch beyond your level. When under high pressure, you might be given a senior or lower project, but expected to deliver it in half the time.

Conclusion

So that’s how I got to staff, what forms my job takes, and ways I’ve found to thrive in the role.

But I have a secret to tell you: basically none of what I shared today is limited to being a staff engineer. Your path to staff should begin with these behaviors long before you go up for promotion.

I hope that some of what I’ve shared today will be useful to you in your practice, no matter your level. The staff engineering job isn’t for everyone. And it doesn’t need to be! It’s just fine to stay at Senior or move into management. But I think you should consider a path towards Staff in your career. I’ve found my years in the role to be the most fulfilling of my time as a software engineer. It might just be for you, too.

Thanks

Thanks to Sean, Jon, Matt and Marty for help writing this talk and to the dozens of folks who asked questions when I presented it.

TL;DR

Open up a Unifi G5 Bullet camera to adjust the manual focus distance for usage in close quarters, such as a bird nest.

Background

Before our house burned down in the Marshall Fire, we had a few families of house finches that nested in the pine tree outside of my office window. Their comings and goings were a nice form of entertainment while working from home.

During the process of rebuilding our home, the finches took up residence in our framed-out house in the spring, raising a few clutches. Once the building was closed in, we wondered where they would nest, as our neighborhood lost most of its trees in the fire.

As the finishing touches went on the house, we realized that we were creating the perfect nesting spots in the hollowed-out tops of the craftsman-style pre-fabricated corbels under our roof gables, of which there are about 20 on our home. On most of of them, the top was exposed:

While we didn’t want to deter all nesting, we had our builder close off all but the four that sit above windows on the main floor of the house. And sure enough, we were right! The finches took up the new spot with much delight, nesting in two of the four last spring.

Setting up a nest camera

Unfortunately the nests were basically impossible to observe, which I’m sure the finches appreciated. We wanted to give them their space but still be able to see the action, so I looked into setting up a camera for one of the nesting spots.

After some research, I found that none of the Ubiquiti cameras would focus as close as I needed (~1ft). Luckily, a helpful poster on the Ubiquiti forums noted that the Bullet cameras can be manually focused if you’re willing to void your warranty.

Here is how the camera focus looked straight out of the box:

Not even close. In most applications, a hyperfocal approach is likely preferred, so I’m guessing the out-of-box focus distance is around 6-10ft.

To open up the camera, I first removed the drip shield with a pair of pliers wrapped in painter’s tape. Then, I pressed a roll of electrical tape against the retention ring and unscrewed it to reveal the internals of the camera:

From there, it was only a matter of carefully turning the lens with the pliers to adjust the focus:

As it turns out, I ended up needing to further tweak the focus once the camera was installed, while at the very highest setting of my 20ft extension ladder:

This gave me a sharp image:

That did the trick! I was sure to complete the work in late fall so as to not scare the finches away from the nesting site.