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

The essence of my job as an architect is commonly described as a &#x27;professional negotiator&#x27;, implying that my primary responsibility is convincing people into doing the right thing (tm). My time is typically split between two main things: meetings and research&#x2F;design work.<p>On a typical day, I have 4-6 meetings with different groups of people. Some will be solution design discussions with engineering teams where we try to figure out how a particular challenge will be solved together. Others will be with product managers, talking about feasibility, cost and time estimation. Yet others will be with senior directors about long term strategy and infrastructure. Finally, a very important part of the meetings is mentoring. Knowing something is valuable, sharing that knowledge is invaluable.<p>While this may sound like a lot of meetings (and engineers typically abhor meetings) they are typically very useful and very rewarding.<p>The remaining time I typically spend on doing preliminary research, design, documentation and every now and then even coding, which I thoroughly enjoy.

A little offtopic, but some people might find it interesting.<p>My company doesn&#x27;t have a &quot;Software Architect&quot; job title. Instead the closest thing is &quot;Staff+ Engineer&quot;, which does pretty much the same things. However there are some key differences.<p>First, these aren&#x27;t &quot;Ivory tower&quot; architects. They still write code (although in practice not much) and stay connected to implementation details, mostly via code and design reviews.<p>Second, architecture is every dev&#x27;s responsibility, at different levels. So Staff engineers might oversee the architecture of entire systems spanning a whole org, while senior engineers oversee a single team. A mid level dev might design the &quot;architecture&quot; of a small service integrated in a larger system.<p>Staff+ engineers usually report to senior leaders and aren&#x27;t part of a team. They might hold office hours and break disagreements within or between teams.<p>I&#x27;m not one myself but in a conversation a Staff eng. told me this was the first job where no one tells him what to do. Instead he spends his time proactively looking to solve business problem. This might be top down (e.g. take a business problem and try to find how to solve it) or bottom up (e.g. take some new tech or tool and figure out how it can be used to achieve some business goals). Often problems can also be solved without tech at all (e.g. aligning stakeholders).<p>Lastly at this level engineers are expected to be leaders as well. Mentoring, sponsoring, etc. is pretty much a requirement. They should be force multipliers, making other engineers around them better. They might also scale themselves by producing content, such as tutorials, talks, training, etc.

- Always on a state of mind of redesigning and simplifying everything<p>- Spending a lot of time trying to figure out the business better<p>- Studying a lot of books, articles, codebases and discussions on software architecture<p>- Inspire the team and younger devs to avoid complex tools and solutions and stick to the basics<p>- Balancing everyday and urgent business needs while leading towards a more simple, boring and maintainable system.<p>- Trying to persuade people to avoid technical debt at all costs

My view as a &quot;full stack&quot; architect and developer.<p>Depends on the size of the firm. Very, very large ones will see you write little code -- generally to the detriment of the company, the architect, and the teams they interact with.<p>Good architects are hands-on. They write proofs of concept implementations before recommending a tool or technology.<p>Bad architects dream up nothing but gormless and inscrutable charts and diagrams that, like crap ink on vellum, slowly fade into illegibility in a remote Sharepoint server.<p>Good architects clarify and explain. Their job is to assist teams in melding disparate technical viewpoints with that of the business -- who themselves often lack focus. A good architect facilitates that: they&#x27;ll rarely look at lines of code, per se, but more the general trend and direction.<p>Bad architects dream up complications that serve no one but their own ego. I once worked with an &quot;architect&quot; who spent most of his time mapping out some data, represented in JSON, using eBNF -- a tool used for specifying formal grammar for computer languages. It could&#x27;ve been solved with an example + some data typing in the margins. Don&#x27;t be like that dude; people struggled to make sense of the trivially simple data we had to store. For larger things use a schema-like structure; for smaller things, trust that people and teams are not stupid.<p>Good architects are skilled at everything. They&#x27;ve hacked up CI systems in batch or bash files, before the current tooling even existed. They&#x27;ve built all manner of systems, in a range of environments and possibly languages. They&#x27;re pragmatic, and can spot trouble a mile ahead.<p>Bad architects envelop themselves in what ever the buzz du jour is: like microservices, which is never an opening gambit for 99.9% of problems you&#x27;re going to encounter in a greenfield project. They&#x27;re the ace up the sleeve when all other performance and scalability efforts have failed. Good architects know when to tell a tech lead to lay off the technobabble: chroming your CV is not in the interest of the business as a whole.<p>Good architects prefer plain, old working tools. That usually involves a RDBMS. Sometimes many; and often times you need to make existing ones talk to other things. Bad architects thing old means bad. XML is not bad; what people did with it was, for example.

In my current employer &quot;architect&quot; are people that do (exclusively) drawing. The preferred tool is IBM Rhapsody. Once somebody suggested to use PlantUML, he was directly laugh at his face; and they explained how much better Rhapsody is. To be fair, they had some good points...<p>But once I suggested they should do some back and forth with the people actually writing code... they told me &quot;I cannot understand code, and it is all right so. I do not need to. I&#x27;m the architect, not the carpenter&quot;<p>Another time I asked the chief architect --we were working in an embedded system-- &quot;I have to program this function, what is my RAM, ROM and CPU budget for it?&quot; His reply shocked me: &quot;I&#x27;m architect here, I do not care about that little things, I do only the architecture, look here&quot; and he proceeded to show me lots of boxes connected with lines. Then he added &quot;that here is what is important, the real architecture is here&quot;.<p>Needless to say, those projects failed miserably, with no hope for recovery...

I’m not an architect, but used to closely work with one and it was a pleasure.<p>The key role that our architect played that brought immense value to us was being the integrator of teams. Teams had a high level of autonomy when it comes to implementation details which meant there could easily be “reinventions”, incompatibilities, and even narrow minded choices. Our Architect always had the big picture view across teams, almost always sat in our feature grooming sessions with valuable inputs, worked closely with product owners who bring in feature requests that may need integration of multiple services etc.<p>Above all, he was very active, and approachable to all teams instead of hiding behind barriers and occasionally bringing out UML diagrams. Several times, when we were debating which technical choice to make, held chime in with valuable points about what would be better if we were to integrate with another service, or something like “that team did this because blah, which might be relevant to you”.

I&#x27;ve had an &quot;architect&quot; job in some form or another for 20+ years, so have learnt plenty of things that would have greatly surprised my younger self...<p>My day job is basically to be a &quot;force multiplier&quot; and it boils down to:<p>- cat herding = meetings, discussions, negotiation, &quot;shoulder to cry on&quot; = way more soft skills then I ever thought I&#x27;d need<p>- Big picture stuff = &quot;town planning&quot; for tech, second order thinking, pulling together cohesive plans&#x2F;strategies, principles, constraints = way harder to effectively communicate this stuff than my younger stuff would have thought<p>- rapid altitude changes = dropping from the 10000ft view down to helping a team troubleshoot some production issue, helping a junior dev with a code issue, solving a dispute between devs, hands on evaluation of some new tech, then jumping back up to talk to a leadership team about some new grand strategy, or to planning out a multi year program of work = a ton of skills that my younger self would have never have guessed at, finance, budgets, &quot;business&quot; language, operating models along with keeping my technical skills sharp<p>In terms of resources:<p>- Anything around learning to story tell and communicate effectively<p>- The &quot;97 Things Every Software Architect Should Know&quot; essays<p>- Your tech skills - write PoC apps, side-projects, try out new tech, learn to quickly grok strengths &amp; weaknesses of tech

- It&#x27;s typically a journey up and down the stack in terms of frontend, backend, and DevOps, and a journey in and out of solving inherently complex problems (where the seams of your services are, authentication) and incidentally complex problems (frameworks, machine-specific issues, Docker hell etc.)<p>- 80% what needs to be done today&#x2F;what fires need putting out, and 20% planning for the future and seeing how the bleeding edge can legitimately help us (e.g. WASM coming soon...). This is part of the general keeping up with advances in industry<p>- Mentoring, jumping on pair programming calls to unblock other teammates.

I believe that the job description differs a lot from company to company.<p>From my experience, the best architects spent most of their time focusing on these things:<p><pre><code> 1. Always understand what the current business priorities are. 2. Design the overall system architecture so it covers all of the business needs, and nothing more. Always focus on keeping it as simple as possible. Even when people argue &quot;lets do this some other way, because we might need it in the future&quot;. 3. Fight the urge to use &quot;latest and coolest&quot; technology. Don&#x27;t listen to consultants selling you unnecessary tech. Stick to what works. Even when it&#x27;s boring. Explain it properly to your team. 4. Maintain proper documentation. Focus on making it as simple as possible, easy to adjust and up to date. Otherwise its value will be close to 0. 5. Use UML diagrams. Think about where the complexity of the given system is, and use only the most relevant ones. For example, if the complexity lies in complex workflows, use sequence diagrams or state diagrams. If the complexity lies in complex datamodel, use ERD diagrams. </code></pre> But more often than not, architects also have to focus on other things, mostly related to DevOps, Platform Engineering and overall developer workflows.<p>[shameless plug] That&#x27;s one of the reasons I founded <a href="https:&#x2F;&#x2F;stacktape.com" rel="nofollow">https:&#x2F;&#x2F;stacktape.com</a> - AWS-focused &quot;internal developer platform&quot; that allows developers to do this sort of stuff on their own, without involvment of architects, DevOps or others.

Noticing a theme already.. architects are fun killers!<p>“Good architects prefer plain, old working tools.” <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=33880398" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=33880398</a><p>“Fight the urge to use ‘latest and coolest’ technology. (…) Stick to what works. Even when it&#x27;s boring.” <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=33880978" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=33880978</a><p>&quot;Inspire the team and younger devs to avoid complex tools and solutions and stick to the basics” <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=33880224" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=33880224</a>

I&#x27;m an influencer.<p>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.<p>This implies analysis and compromise, having meetings, mentoring engineers, and quite a bit of coding and research.<p>My work is less guided that when I was a junior engineer, in the sense that I&#x27;m meant to discover opportunities for improvement and give guidelines. This leaves time to pick what I should be doing next, where I&#x27;m adding the most value.<p>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.<p>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.<p>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.<p>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.<p>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.

Well I work for a small government and my responsibilities tend to be a little less structured or more fluid in nature. I have to adapt at times and crunch code just as much as I scope requirements and write technical documents.<p>Meetings here and there, lot&#x27;s of talking to people and lots of reading. Currently I&#x27;m working on a digital transformation strategy and I can definitely see myself writing a whole lot in the next few months to gather traction on the implementations that are needed.<p>I would say that at least for me, becoming a Software Architect has meant that I need to split my time between groundwork and strategising with an added layer of complexity that stems from the fact that I work for government, so there are a number of policies and internal bureaucratic barriers to get used to.

Other related and recent question with useful comments <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=33713075" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=33713075</a>

I am architect on the sales side. That&#x27;s little bit crazier, I would guess.<p>In the morning I look over our github&#x2F;mail&#x2F;slack queue to see whether someone needs urgent help.<p>Then, if there are customer meetings scheduled on that day, I frenetically try to re-create customer&#x27;s infra in our lab (be it Anthos Cluster, AWS Systems Manager, Azure Arc, or istio). If there are no customer meetings I try to improve our stuff on github. Sometimes, I publish new blueprint, kubernetes operator, or a terraform module, or try to create new CFT resource.

First up: having total visibility of the org is really important. We have a hundred engineers and I see everyone’s changes at the point they make them public (in whatever form they are called today: pull requests, merge requests, diffs, eh.) Unless I engage then that’s the first and last time I see their stuff but it’s enough to stay on top of everything everyone is up to. It’s a surprisingly low volume &#x2F; high value channel of information.<p>Leave the code review to the experts in each codebase — most changes will be on point and need only a small or large amount of alignment before they can land. (By contrast, very few things need to have the brakes put on them.)<p>Some changes though will correlate with other problems across the codebase and this is where you should be stepping in to spot future patterns or current anti patterns and <i>providing solutions and directions forward, or at worst, road blocks</i>.<p>Once you have enough of these under your belt you can start proactively spotting hot spots in the eng org that need focused effort. More mypy typing for a core library. Two libraries that should be one. One library that should be two. Vertical slices of functionality in two products that should be horizontal slices pulled into a separate service (or, my preference, library.)<p>Processes are important too. You’ll see what people are repeating and or finding hard, and which could benefit from some love. Build infra. A testbed for debugging a process that is otherwise too heavyweight with production data. Teams that don’t talk enough pre-PR. Managers that need help managing consistent poor performers.<p>I think many people wanting to go into an architect career think it is highbrow design work. In reality, I’ve found you end up doing much more support &#x2F; boiler room &#x2F; janitorial work. It’s very satisfying, and very much reminds me of my career sidetrack as a school teacher. Above all, you are there to help people and teams reach their potential and get the most from their jobs.

I&#x27;m not sure that I&#x27;d qualify as a software architect. I work in a small software company and basically I do all important IT decisions. I&#x27;m kind of architect and full stack developer and devops at the same time.<p>So sometimes we do some design meetings. I suggest how to better design database, etc. I&#x27;m trying not to dictate everything but rather catch mistakes which are obvious from my experience. Avoiding mistake early is very important IMO.<p>Recent months I designed Kubernetes cluster. We have plenty of small and medium services and environments thrown around in a few dedicated servers. It&#x27;s a giant mess. I dread when I need to untangle it. So it was unavoidable to redesign devops from the scratch and I decided to go with Kubernetes. I basically tried few approaches, some turned out to be too complex, e.g. I built a complete automation on terraform, shell scripts and flux and ditched it out, because nobody but me would understand it and I don&#x27;t need that kind of job security. I ended up with a simplest setup possible. Terraform provisions servers (we use hoster with OpenStack), then I manually run kubeadm with prepared configs, then I run few shell scripts to install important stuff with helm, then I install our services with kustomize. I think it was very nice outcome. Simple and approachable for everyone who knows basics of Kubernetes. Not full-fledged GitOps, but I decided that we&#x27;re not ready for it yet. That was one example of project that I did myself because we didn&#x27;t have necessary expertise.<p>Right now I&#x27;m adapting our projects to work with Kubernetes, improving builds, adding health checks, writing yams, etc.<p>I also made a foundation for some important core projects which I couldn&#x27;t trust others to design. Then people continued my work. It seems to work fine so far, I oversee those projects to keep them in a good condition.<p>Also I chat a lot with developers who stumble upon hard issues and struggle to resolve those or they can&#x27;t make some decision.<p>And I have some vision how our system as a whole should look like in an ideal world. We don&#x27;t have resource to implement that vision and probably never will, but I consider it a good direction so I&#x27;m trying to point important decisions to that direction.<p>Also I sometimes walk over repositories and fix stuff I don&#x27;t like. Usually devops stuff, like bad dockerfiles, missing dockerignores, outdated dependencies.<p>Sometimes I feel like a janitor, LoL.

I end up doing all the BA &#x2F; PO &#x2F; Scrum work and go to a lot of high-level meetings where POs give me some vague requirements they wrote down in 15 minutes between taking their kids to school and soccer practice. Then I cover for the scrum master who takes off on critical release days.<p>Then I go to meetings and track down people to clarify requirements and do an architecture diagram or two and write stories from it and get it &quot;approved&quot; by the PO.<p>I also pick up stories the team doesn&#x27;t want, since I feel responsible for them not being clear &#x2F; easy &#x2F; broken up enough. In the evenings, I study for cloud exams.<p>Resources I have found useful is really understanding flowcharts, and the difference between flowcharts and high-level architecture diagrams.

Usually have differing work depending on which phase of project lifecycle.<p>Early stage days are estimating + research. Often sitting with users and figuring out system complexity (from a usage and implementation perspective). Most important part of any project&#x2F;transformation. Can never know enough. This is usually 2-3 hours meetings per day with users&#x2F;technical groups, 3-4 hours documentation pieces.<p>Later stage projects are process heavy. 3-4 hours with support, incident managers, networking, testers, devs, SLA stuff, NFRs all that fun stuff. Rest of the day writing.<p>Overall it can be busy with long presentation prep and discovery&#x2F;planning work or it can be quiet (something gets delayed) where I just go play with some new tech for a few days!

I was a software architect at the end of the 90s before becoming CTO and then going on my own so it is a bit rusty.<p>Most of my time was spent on high level design of complex business and B2B products and making sure that managers, business analysts and programmers do their jobs. Also selecting technologies etc. I still had about 50% of my time left for actual work so I would always pick some particular chunk and create design documents with diagrams given to programmers and would also code some chunk. I could have avoided doing any &quot;productive&quot; stuff but I did not want to loose touch. Being converted to a pure manager was not in my nature.

A lot of meetings across many teams and a lot of powerpoint for those meetings. It&#x27;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.<p>I&#x27;m also the last point of escalation for a handful of dev teams. That&#x27;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&#x27;ve learned. It&#x27;s very fulfilling.

I&#x27;ve been doing architecture since 2003 and I&#x27;ve written down the things I do regularly as an architect -<p><a href="https:&#x2F;&#x2F;www.wittenburg.co.uk&#x2F;work" rel="nofollow">https:&#x2F;&#x2F;www.wittenburg.co.uk&#x2F;work</a>

Doing non architecture stuff. Reviewing designs, troubleshooting issues nobody else could solve, mentoring juniors. I wouldn’t say there are any particular resources I consult when thinking about architecture, but being well versed in design patterns and knowing how to make standard diagrams is key - it’s all about communicating ideas and outside text, those are the tools.

If you flex the title &quot;architect&quot; to include &quot;staff engineer&quot;, <a href="https:&#x2F;&#x2F;lethain.com&#x2F;what-do-staff-engineers-actually-do&#x2F;" rel="nofollow">https:&#x2F;&#x2F;lethain.com&#x2F;what-do-staff-engineers-actually-do&#x2F;</a><p>By the way, I highly recommend his book <i>Staff Engineer</i> if you&#x27;re interested in delving deeper.

Sitting on Zoom with a permanent facepalm wondering how the outsourcers delivered a monkey when we carefully specified a lion.

There is much diplomacy involved as the wider the scope of the project, more teams are involved, resulting in even more &quot;right&quot; ways to do X.<p>Although I&#x27;m not an &quot;architect&quot; by title, things I build do impact many teams as we move towards standardising how to do X.

I&#x27;m not an architect at the moment but when I have been I spent most of my time negotiating with stakeholders to work out what they really need rather than just planning what ridiculous nonsense they believed they wanted.

I&#x27;m responsible for both hardware and software to a degree<p>Most of my time is meeting. Either other teams or my own.<p>Between these, I&#x27;m either building proofs or managing services we never found owners for with a reorg

Maintaining time for a good amount of coding.<p>Good architects write code or become more disconnected and more similar to management.

When I was an architect, my job was to scale my knowledge and save others time. Not 10 minutes of googling, but several weeks or more for a team who would need to sound out a solution. An example would be spending an afternoon designing a slide that represented the main transactions we were building for as an M&#x2F;M&#x2F;1 queue (or other queue) so that devops could decide in a couple of seconds how many VM instances we were going to need, and the likely compute costs - instead of scheduling several meetings where they needed to sort out their internal power struggles of who was right to move the decision forward.<p>I might spend several days (or more) going through code and interviewing developers about how they implemented an authentication protocol so that I can draw it in BAN logic on a slide, which other projects can use to integrate their code with, and our certification&#x2F;accreditation&#x2F;infosec people can reason about so the project doesn&#x27;t get spike stripped at the production gate and delayed a quarter while a post-hoc security analysis gets done on it.<p>I would meet with our vendors and tech service providers and establish whether they in fact provide the services they said they would, and what that physically means. A great example is whether an o365 tenant supports OAuth2 federated logins with non MSFT tenants or not, and how we are going to enroll users based on the amount of friction the realization of this feature causes(or not). Another one would be pushing standards down into development so nobody would roll their own protocols, and so I could have a short answer to what we implemented. You might see it as ticking a box, but an enterprise is like an airport, and some people get to fly while others don&#x27;t. The ones who don&#x27;t are usually stewing over some counterfactual.<p>I would meet with external consultants, often security and regulatory people, and provide them with the technical details and assurances that would keep them from taking a pound of flesh from the project in the form of a 6 week analysis engagement.<p>What makes an architect something different is they recognize that when there is direction or demand for a tech project, that creates opportunity for a lot of other very sophisticated technical people to inject themselves into the critical path of the project and use their leverage to extract money, management authority, and other concessions from it. As an architect, you see these people coming, and make sure they do not derail your tech.<p>I enjoy it because it&#x27;s solving problems at a higher level of abstraction. I also like doing product, but the architecture urge sabotages that, as in product, solutioning comes at the cost of listening and scaling your listening out to architects to solution stuff.

20% hands on code<p>20% mentoring<p>60% facilitating consensus between teams&#x2F;orgs

Meetings. Endless meetings.

- First thing in the morning, standups followed by coaching sessions (basically pair programming or code review) for sticky problems<p>Then it varies.<p>- 1:1s<p>- project or program (in the sense of both code type programs and long term direction programs) planning or status meetings with various stakeholders, especially POs, PMs, and execs<p>- digging into particularly difficult or odd code or set up issue that&#x27;s lead to it being escalated<p>- meetings with vendors and doing a write up of their product&#x27;s potential and costs<p>- creating rough project or program outlines with rough budget estimates for execs<p>- creating design documents on projects or programs that have a bit of traction<p>- meeting with other architects to collaborate on wider designs or just share items of interest<p>- going on HN to tell strangers about my day-to-day life<p>- create fully functional POCs or reference implementations<p>- doing post-mortems<p>- examining code from a potential acquisition or quizzing their engineers<p>- getting on meetings with clients or potential clients to give them a warm fuzzy that a tech person with an impressive sounding title is listening to show we&#x27;re taking something Very Sersiously and find them to be Very Important.<p>- regular Open Office Hours for anyone in the company to drop by and chat about anything (lots of good stuff comes from these -- highly recommend)<p>- fielding various requests and questions from Security and Ops other teams and whatnot.<p>- Having What-If meetings with sales or execs (danger! There be dragons here! But, with Sales especially, a really good way to figure out what customers are clamoring for)<p>- Preparing talks and technical outreach<p>- Exploring New Shiny Things (though I tend to do this more on off-hours just because there are fewer interruptions and urgencies).<p>In terms of microservices in particular, I tend to ask a lot of questions about data and work flow, how someone has defined a domain or domains, making sure they&#x27;re not falling into the myriad anti-patterns, making sure what they&#x27;re doing is going to be visible, tractable, and play nice with the rest of our services including following our common patterns and idioms (and when I run into idioms that they might not know about I document them and make them easy to find) and not create any unpleasant surprises down the road, and that they have given appropriate thought to evolution of the service and forward and backward compatibility during that process.<p>Martin Fowler is by far my most influential resource on microservice architectures and doing domain driven design well. But I would strongly suggest literally reading everything you can find on the subject. Mostly because it&#x27;s many subjects in a trenchcoat. Seeing it all from a few different angles will better arm you for whatever comes your way.

I&#x27;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.<p>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:<p><pre><code> 1. Writing code 2. Reviewing code 3. Responding to feedback in our Slack channels 4. Impromptu meetings to help other Engineers get &quot;unstuck&quot; </code></pre> On Tuesday and Thursday I&#x27;m open for recurring meetings. Most of this time is spent:<p><pre><code> 1. In 1:1s with other engineers or team leads 2. In miscellaneous recurring meetings like our &quot;Architects Chat&quot; or &quot;Leadership Meetings&quot; </code></pre> 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 &quot;individual contributor&quot; track. IMO, if you aren&#x27;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.<p>Reviewing code is a close second. I review roughly 50 PRs every week which is about 2x what our closest &quot;non-architect&quot; 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&#x27;m understanding correctly and actually providing useful feedback. Since other people are working in my code-bases, its also important to see that &quot;the ideas are coming together&quot;. If PRs into our Circuits code are frequently breaking patterns, its likely a problem with my patterns rather than other engineers.<p>I don&#x27;t have documentation on the list as it isn&#x27;t something I write in an ongoing way. Instead, I prefer to write documentation at the beginning and end of large projects. I don&#x27;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:<p><pre><code> 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 &quot;state of the world&quot; </code></pre> If anyone is interesting in joining Rec Room, we are hiring :)<p><a href="https:&#x2F;&#x2F;recroom.com&#x2F;careers?gh_jid=5382144003" rel="nofollow">https:&#x2F;&#x2F;recroom.com&#x2F;careers?gh_jid=5382144003</a>

meetings I imagine

Feed stuff to chatgpt, feed it to build pipeline

Writing powerpoint with the intention of fucking up the actual developers of S&#x2F;W...