If you flex the title "architect" to include "staff engineer", https://lethain.com/what-do-staff-engineers-actually-do/
By the way, I highly recommend his book Staff Engineer if you're interested in delving deeper.
Ask HN: Software architects – what’s your typical day look like?
11–20 of 107 posts
Re: Ask HN: Software architects – what’s your typical day look like?
#12- 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…
"Studying a lot of books, articles, codebases and discussions on software architecture" - like what? 90% of it is "write clean code", "put in a cache", "normalize your db", "use a queue if the service is really spotty/unreliable".
"Fundamentals of Software Architecture" is 95% fluff. So is "Clean Architecture". Most patterns like CQRS, DDD, fully event-driven etc are complete overkill and a sign of a BAD architect unless there is a real cause for it. 90% of the job is NOT overcomplicating.
"Trying to persuade people to avoid technical debt at all costs" - put in a linter and concrete rules (even if a rule is loose, note that in writing) or devs will get upset and think you are singling them out.
Re: Ask HN: Software architects – what’s your typical day look like?
#13My view as a "full stack" architect and developer.
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.
Good architects are hands-on. They write proofs of concept implementations before recommending a tool or technology.
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.
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'll rarely look at lines of code, per se, but more the general trend and direction.
Bad architects dream up complications that serve no one but their own ego. I once worked with an "architect" 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've been solved with an example + some data typing in the margins. Don'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.
Good architects are skilled at everything. They've hacked up CI systems in batch or bash files, before the current tooling even existed. They've built all manner of systems, in a range of environments and possibly languages. They're pragmatic, and can spot trouble a mile ahead.
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're going to encounter in a greenfield project. They'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.
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.
Re: Ask HN: Software architects – what’s your typical day look like?
#14The 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 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.
While this may sound like a lot of meetings (and engineers typically abhor meetings) they are typically very useful and very rewarding.
The remaining time I typically spend on doing preliminary research, design, documentation and every now and then even coding, which I thoroughly enjoy.
Re: Ask HN: Software architects – what’s your typical day look like?
#15- 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…
"Studying a lot of books, articles, codebases and discussions on software architecture" - like what? 90% of it is "write clean code", "put in a cache", "normalize your db", "use a queue if the service is really spotty/unreliable". "Fundamentals of Software Architecture" is 95% fluff. So is "Clean Architecture". Most patterns like CQRS, DDD, fully event-driven etc are complete overkill and a sign of a BAD architect un…
Apart from those best seller books, the are great podcasts and articles that people discuss their experiences in depth. It helps me a lot, to compose a more holistic thinking.
Technical debt does not increase only for technological reasons but also from business expectations. You can't just "build" a new garden and leave it be. You have to maintain it also. Keeping the system clean and well oiled before building more is important. But these concepts need to be reminded everyday to survive
Re: Ask HN: Software architects – what’s your typical day look like?
#16- 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…
"Studying a lot of books, articles, codebases and discussions on software architecture" - like what? 90% of it is "write clean code", "put in a cache", "normalize your db", "use a queue if the service is really spotty/unreliable". "Fundamentals of Software Architecture" is 95% fluff. So is "Clean Architecture". Most patterns like CQRS, DDD, fully event-driven etc are complete overkill and a sign of a BAD architect un…
Also, I agree with you about over-complicating with all those patterns. But before I am able to dismiss a solution, I have to understand it. Trying to keep it simple is hard
Re: Ask HN: Software architects – what’s your typical day look like?
#17In my current employer "architect" 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...
But once I suggested they should do some back and forth with the people actually writing code... they told me "I cannot understand code, and it is all right so. I do not need to. I'm the architect, not the carpenter"
Another time I asked the chief architect --we were working in an embedded system-- "I have to program this function, what is my RAM, ROM and CPU budget for it?" His reply shocked me: "I'm architect here, I do not care about that little things, I do only the architecture, look here" and he proceeded to show me lots of boxes connected with lines. Then he added "that here is what is important, the real architecture is here".
Needless to say, those projects failed miserably, with no hope for recovery...
Re: Ask HN: Software architects – what’s your typical day look like?
#18Earlier quoted context omitted.
"Studying a lot of books, articles, codebases and discussions on software architecture" - like what? 90% of it is "write clean code", "put in a cache", "normalize your db", "use a queue if the service is really spotty/unreliable". "Fundamentals of Software Architecture" is 95% fluff. So is "Clean Architecture". Most patterns like CQRS, DDD, fully event-driven etc are complete overkill and a sign of a BAD architect un…
Also, I agree with you about over-complicating with all those patterns. But before I am able to dismiss a solution, I have to understand it. Trying to keep it simple is hard
@lexx, i think most of the things you put in your answer were very reasonable and non-controversial and probably what most good senior-ish engineers do. I think the parent comment is slightly in his "local minima" and he's generalizing his experience to everyone else
>"Trying to persuade people to avoid technical debt at all costs" - put in a linter
This for example does not make sense to me. This would mean all tech debt is just static analysis. There is no linter for figuring out the correct abstraction and using them correctly. Eg. no linter yet will tell you "hey you should have used a state machine here!"
You need a width range of experience before you can develop "better" taste in what's good and bad in different scenarios. Some of it can be gained from years of experience, and some from exposure to books/code.
Re: Ask HN: Software architects – what’s your typical day look like?
#19The 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…
[deleted]
Re: Ask HN: Software architects – what’s your typical day look like?
#20The 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…
> convincing people into doing the right thing (tm).
How do you deal with the burden of knowing/predicting what the right thing (tm) is / will turn out to be? I am constantly agonising over choices I'm about to make, and almost invariably come to regret some of the choices that I, or our team, have made (which include, but are not limited to, React, Gatsby, Flow, Stylus, Enzyme, Jest, SCSS, single-page app architecture, possibly graphql, etc. etc...). Not that I'm an architect; but still. How do you cope?