Ask HN: Software architects – what’s your typical day look like?

I ran into an interesting point about poker in a recent episode of EconTalk[0]. Really good players play slightly more hands than they should (ie on a tournament table with 9 seats, a good player might play 15-20% of hands). Amateurs play way more hands than they should - like 50% or so. Translating to this thread, I’d map “playing a hand” to committing real resources to a project (switching tech stacks, etc). Pros will be somewhat conservative and only take that bet when they have a higher expectation of success.

[0] https://www.econtalk.org/annie-duke-on-the-power-of-quitting...

What’s Docker hell?

I'm the software architect for Circuits at Rec Room. Rec Room is a multi-billion dollar UGC-driven online game. Circuits is our in-game programming language.

On Monday, Wednesday, and Friday I have large no meeting blocks in my calendar to discourage recurring or pre-planned meetings. Most of this time is spent:

  1. Writing code

  2. Reviewing code

  3. Responding to feedback in our Slack channels

  4. Impromptu meetings to help other Engineers get "unstuck"

On Tuesday and Thursday I'm open for recurring meetings. Most of this time is spent:

  1. In 1:1s with other engineers or team leads

  2. In miscellaneous recurring meetings like our "Architects Chat" or "Leadership Meetings"

Writing code is _by far_ the largest place I allocate my time and also what I would recommend to other engineers who wish to stay on an "individual contributor" track. IMO, if you aren't writing code, you are slowly getting worse at writing code which damages your ability to make recommendations to others. There is no replacement for real experience.

Reviewing code is a close second. I review roughly 50 PRs every week which is about 2x what our closest "non-architect" engineers review (usually Engineering Managers). Many of my impromptu meetings and Slack feedback comes from what I see in code reviews. If I leave anything beyond a trivial comment, I like to have time to discuss with the individual to make sure I'm understanding correctly and actually providing useful feedback. Since other people are working in my code-bases, its also important to see that "the ideas are coming together". If PRs into our Circuits code are frequently breaking patterns, its likely a problem with my patterns rather than other engineers.

I don't have documentation on the list as it isn't something I write in an ongoing way. Instead, I prefer to write documentation at the beginning and end of large projects. I don't make a ton of edits as I go because the code is in flux so it can be a waste of time to update both code and documentation. Instead I like to:

  1. Start a project with a plan of how everything fits together

    a. Planning takes anywhere from 1 week to 2 months depending on the size of the project

  2. Get approval on the plan

  3. Write code... if it has to contradict the plan, so be it

  4. Update the documentation at the very end so other engineers can use it as a nice reference for the current "state of the world"

If anyone is interesting in joining Rec Room, we are hiring :)

https://recroom.com/careers?gh_jid=5382144003

A lot of meetings across many teams and a lot of powerpoint for those meetings. It's not unusual for an entire week to be completely booked back to back with meetings. The upside is I get to meet and work with lots of different people regularly so I learn a ton as well as contribute. The downside is lots of powerpoint.

I'm also the last point of escalation for a handful of dev teams. That's the fun part, getting to work on problems, mentor, and help out. I really enjoy mentoring and watching inexperienced people blossom and start mentoring others and passing on what they've learned. It's very fulfilling.

I'm an influencer.

I have no formal power in the sense that people are not supposed to do what I say, so I have to be convincing, and influence others behaviors to make the software better.

This implies analysis and compromise, having meetings, mentoring engineers, and quite a bit of coding and research.

My work is less guided that when I was a junior engineer, in the sense that I'm meant to discover opportunities for improvement and give guidelines. This leaves time to pick what I should be doing next, where I'm adding the most value.

This changes from time to time, it may be figuring out a new architecture, fixing a bug, getting involved in product development or handling an incident.

An important part of the job is getting involved in production incidents, this helps grasp where are we struggling and opens the opportunity to guide development to a state where customers are happier and operational costs are lower.

You also start to be more conscious about company finances (how much it costs to keep the lights running) and start thinking in ways to get more from the same resources.

Even if I have no formal power, people tend to pay attention to what I say and suggest, so I need to be careful, because an off-hand comment can have a lot of impact.

Architectural roles live and die by their word. We lead by influence, so be cognizant of perception and careful when you communicate with others in every interaction.