A question for anyone out there working as a software architect (especially microservice architectures). What’s your typical day comprise of? Where do you find yourself focusing your time? What resources have you found to be most useful?
Ask HN: Software architects – what’s your typical day look like?
1–10 of 107 posts
Re: Ask HN: Software architects – what’s your typical day look like?
#2- It'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.)
- 80% what needs to be done today/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
- Mentoring, jumping on pair programming calls to unblock other teammates.
Re: Ask HN: Software architects – what’s your typical day look like?
#3I end up doing all the BA / PO / 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.
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 "approved" by the PO.
I also pick up stories the team doesn't want, since I feel responsible for them not being clear / easy / broken up enough. In the evenings, I study for cloud exams.
Resources I have found useful is really understanding flowcharts, and the difference between flowcharts and high-level architecture diagrams.
Re: Ask HN: Software architects – what’s your typical day look like?
#4- It'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.) - 80% what needs to be done today/what fires need putting out, and 20% planning for the future and seeing how the bleed…
This reflects my experience as well. Roadmap plannings and API designing between systems, communicating and enforcing best practices within the time constraints, meetings with different service developers/designers to solve the upcoming features...
Less coding, more meeting and reviewing, overall clear view of the big picture is a must.
Re: Ask HN: Software architects – what’s your typical day look like?
#5- It'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.) - 80% what needs to be done today/what fires need putting out, and 20% planning for the future and seeing how the bleed…
Seems like a lot of ongoing o&m and sustainment of an existing product, similar to any other day-to-day.
Do you have insight on what the proposal, design review, and first commits look like when architecting a brand new project? Like what do the first 30-60-90 days look like from product idea up to those o&m and sustainment activities?
Re: Ask HN: Software architects – what’s your typical day look like?
#6I am architect on the sales side. That's little bit crazier, I would guess.
In the morning I look over our github/mail/slack queue to see whether someone needs urgent help.
Then, if there are customer meetings scheduled on that day, I frenetically try to re-create customer'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.
Re: Ask HN: Software architects – what’s your typical day look like?
#7- It'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.) - 80% what needs to be done today/what fires need putting out, and 20% planning for the future and seeing how the bleed…
It sounds like you're very good at what you do.
Sadly I've seen "architects" being more focused on drawings, crude prototypes and fluffy ideas. Basically dreaming up ideas and concepts, throwing them over the wall to developers and SREs to pick up. A previous boss of mine had to callback a candidate for a job, telling him, that despite us hiring pretty much anyone, we had no need for someone who thought of software architecture as a desk exercise.
Re: Ask HN: Software architects – what’s your typical day look like?
#8- It'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.) - 80% what needs to be done today/what fires need putting out, and 20% planning for the future and seeing how the bleed…
This is basically my own experience as well.
Re: Ask HN: Software architects – what’s your typical day look like?
#9I'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.
Re: Ask HN: Software architects – what’s your typical day look like?
#10- Always on a state of mind of redesigning and simplifying everything
- Spending a lot of time trying to figure out the business better
- Studying a lot of books, articles, codebases and discussions on software architecture
- Inspire the team and younger devs to avoid complex tools and solutions and stick to the basics
- Balancing everyday and urgent business needs while leading towards a more simple, boring and maintainable system.
- Trying to persuade people to avoid technical debt at all costs