31–40 of 107 posts
“Good architects prefer plain, old working tools.” https://news.ycombinator.com/item?id=33880398
“Fight the urge to use ‘latest and coolest’ technology. (…) Stick to what works. Even when it's boring.” https://news.ycombinator.com/item?id=33880978
"Inspire the team and younger devs to avoid complex tools and solutions and stick to the basics” https://news.ycombinator.com/item?id=33880224
Noticing a theme already.. architects are fun killers! “Good architects prefer plain, old working tools.” https://news.ycombinator.com/item?id=33880398 “Fight the urge to use ‘latest and coolest’ technology. (…) Stick to what works. Even when it's boring.” https://news.ycombinator.com/item?id=33880978 "Inspire the team and younger devs to avoid complex tools and solutions and stick to the basics” https://news.ycombin…
The essence of my job as an architect is commonly described as a 'professional negotiator', 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/design work. 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…
Noticing a theme already.. architects are fun killers! “Good architects prefer plain, old working tools.” https://news.ycombinator.com/item?id=33880398 “Fight the urge to use ‘latest and coolest’ technology. (…) Stick to what works. Even when it's boring.” https://news.ycombinator.com/item?id=33880978 "Inspire the team and younger devs to avoid complex tools and solutions and stick to the basics” https://news.ycombin…
* Experienced devs who have "seen it all"
* Have to deal with the consequences and have more responsibility
Then it varies.
- 1:1s
- 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
- digging into particularly difficult or odd code or set up issue that's lead to it being escalated
- meetings with vendors and doing a write up of their product's potential and costs
- creating rough project or program outlines with rough budget estimates for execs
- creating design documents on projects or programs that have a bit of traction
- meeting with other architects to collaborate on wider designs or just share items of interest
- going on HN to tell strangers about my day-to-day life
- create fully functional POCs or reference implementations
- doing post-mortems
- examining code from a potential acquisition or quizzing their engineers
- 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're taking something Very Sersiously and find them to be Very Important.
- 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)
- fielding various requests and questions from Security and Ops other teams and whatnot.
- 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)
- Preparing talks and technical outreach
- Exploring New Shiny Things (though I tend to do this more on off-hours just because there are fewer interruptions and urgencies).
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're not falling into the myriad anti-patterns, making sure what they'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.
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's many subjects in a trenchcoat. Seeing it all from a few different angles will better arm you for whatever comes your way.
The essence of my job as an architect is commonly described as a 'professional negotiator', 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/design work. 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…
How do you personally deal with designing solutions where you haven't been able to convince people to do the right thing? For example where there are limitations imposed on you or someone higher up makes a call that doesn't sit well with you
Most of my time is meeting. Either other teams or my own.
Between these, I'm either building proofs or managing services we never found owners for with a reorg
The essence of my job as an architect is commonly described as a 'professional negotiator', 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/design work. 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…
How do you personally deal with designing solutions where you haven't been able to convince people to do the right thing? For example where there are limitations imposed on you or someone higher up makes a call that doesn't sit well with you
- 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 main…
> - 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
This is literally my job everyday now as a principal. I enjoy it, but it's quite grueling, tbh.