Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

news.ycombinator.com

Post reply on HN
Print view View original

91–100 of 107 posts

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

#91

Post by ElevenLathe »

anon7725 wrote: post #62
jupp0r wrote: post #27

Earlier quoted context omitted.

A great mentor once told me about the poker analogy method of coping with situations you describe. Let's say you are a great poker player. When you get dealt a good hand, you play it and end up loosing - does that make you a worse player? Turns out even the best of all players loose quite frequently. What distinguishes them from others is that they make the best choices with the limited information they have at the t…

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 w…

In other words, you gotta know when to hold 'em, know when to fold 'em, know when to walk away, and when to run.

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

#92

Post by Rabidgremlin »

I've had an "architect" job in some form or another for 20+ years, so have learnt plenty of things that would have greatly surprised my younger self...

My day job is basically to be a "force multiplier" and it boils down to:

- cat herding = meetings, discussions, negotiation, "shoulder to cry on" = way more soft skills then I ever thought I'd need

- Big picture stuff = "town planning" for tech, second order thinking, pulling together cohesive plans/strategies, principles, constraints = way harder to effectively communicate this stuff than my younger stuff would have thought

- 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, "business" language, operating models along with keeping my technical skills sharp

In terms of resources:

- Anything around learning to story tell and communicate effectively

- The "97 Things Every Software Architect Should Know" essays

- Your tech skills - write PoC apps, side-projects, try out new tech, learn to quickly grok strengths & weaknesses of tech

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

#93

Post by ftkftk »

mickeyp wrote: post #63
P5fRxh5kUvp2th wrote: post #59

Earlier quoted context omitted.

hard agree with everything you've said here. At my current company it's actually a fight as it's not necessarily the architects themselves that want to shit out diagrams all day. It's a part of the job, for sure, I'm just pointing out it's not always the architect. but your points about hands-on, respect simple, and having a wide base of experience is 100% spot-on imo. I do agree with your point about the diagrams, j…

Agreed with the diagrams. But, if your job is to convey information, and non-techies prefer that method, then... well, you abide. And charts _are_ useful for sure.

In my experience a few boxes and sticks usually communicate more effectively to more constituents (both technical and not) than the most well-written document. The trick is to know how much detail is necessary to include at the time.

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

#94

Post by danielmarkbruce »

angarg12 wrote: post #69

A little offtopic, but some people might find it interesting. My company doesn't have a "Software Architect" job title. Instead the closest thing is "Staff+ Engineer", which does pretty much the same things. However there are some key differences. First, these aren't "Ivory tower" architects. They still write code (although in practice not much) and stay connected to implementation details, mostly via code and design…

Is there any modern (let's define it as "started in the past 10-15 years") product company that has this "architect" role? I was under the impression it's antiquated.

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

#95

Post by azangru »

thrashh wrote: post #74
azangru wrote: post #46

Earlier quoted context omitted.

> React's been around for a long time now and it's got a lot of momentum and people who know it. That was true for jQuery as well; and yet, it is clearly no longer the right thing (tm) to choose for a project. Not because it's no longer cool; but because the underlying technology — the web browser — has gotten so much better it is no longer relevant. Same fate may await React. At least, with jQuery it's pretty straig…

It wasn’t a change in web browser tech It was that someone put in the time to write a JS preprocessor that went along with their framework. That was React’s novel addition Without a preprocessor, users of your framework either use plain JS to generate HTML (i.e. jQuery) or you use templates. Both of them always looked really ugly on frontend With React’s JSX preprocessor, you can write HTML by… writing HTML. And you…

> Does React use a shadow DOM? Yes

No. You must be confusing it with virtual DOM.

As for React, what we are currently observing is that 1) it's a fairly large library in itself (~50kB of minified gzipped javascript); 2) it has a relatively slow DOM update mechanism; 3) it rerenders too eagerly, making it too easy to further degrade performance; 4) it's a lock-in into a non-standard jsx syntax, forever tying you to preprocessors.

What conclusions an architect would make looking at all this, I do not know.

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

#96

Post by weard_beard »

azalex wrote: post #14

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…

Same. This is a great depiction of a healthy practice.

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

#97

Post by jslakro »

DoingIsLearning wrote: post #87
angarg12 wrote: post #69

A little offtopic, but some people might find it interesting. My company doesn't have a "Software Architect" job title. Instead the closest thing is "Staff+ Engineer", which does pretty much the same things. However there are some key differences. First, these aren't "Ivory tower" architects. They still write code (although in practice not much) and stay connected to implementation details, mostly via code and design…

> My company doesn't have a "Software Architect" job title. Instead the closest thing is "Staff+ Engineer" Not off-topic at all, this is aligned with what I see. In older or 'regulated industry' companies the role and career path of Architect still exists. But more and more I just see senior roles that are flavours of Principal/Staff/Fellow and they still have normal Engineering duties but then in early greenfield st…

Training sphere also reflects this trend and nowadays is less common to find content focused on "Software Architecture" roles. It seems more like a thing from the past. Agile, horizontal teams and even distributed systems are motivating that specific role to disapear

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

#98

Post by ycombobreaker »

0xbadcafebee wrote: post #88
azangru wrote: post #20

Earlier quoted context omitted.

> 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 architectu…

> I am constantly agonising over choices I'm about to make You cannot predict the future. It is impossible know which choice will result in better outcomes. Whatever you choose has probably about equal chance of success or failure. So just make a choice, with a general idea of what you will do when the choice fails. Most choices are not make-or-break, so you should really not be agonizing over most choices.

> It is impossible know which choice will result in better outcomes. Whatever you choose has probably about equal chance of success or failure.

It's a common fallacy to assign 50/50 probability to unknown distributions. Furthermore, many choices are not binary, or may not be as simple as right/wrong in hindsight.

But I agree with the idea of amortizing your perspective over many choices.

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

#99

Post by dr_kiszonka »

ftkftk wrote: post #93
mickeyp wrote: post #63

Earlier quoted context omitted.

Agreed with the diagrams. But, if your job is to convey information, and non-techies prefer that method, then... well, you abide. And charts _are_ useful for sure.

In my experience a few boxes and sticks usually communicate more effectively to more constituents (both technical and not) than the most well-written document. The trick is to know how much detail is necessary to include at the time.

Not having this skill is the bane of my existence! There is always a person who complains* that I provide too little detail ("you need to be more rigorous/specific/careful how you define") or too much of it ("we are getting too much into the weeds here" or they just tune out). I asked a much more senior person for feedback and it is always too much or too little when go from one revision to another.

* Yes, it is better that they articulate what they don't like than just completely ignore it and leave me in the dark.

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

#100

Post by rcarmo »

azalex wrote: post #14

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…

This. This is the “right” answer.
Post reply on HN