Live data from Hacker News

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

news.ycombinator.com

101–107 of 107 posts

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

#101
post #93

Earlier quoted context omitted.

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

One strategy that may help is to have two pages in your diagram, where one includes more detail. I don't do it often, but when needed I will create the more detailed version first, then duplicate it and reduce the detail by just deleting boxes and maybe rerouting some sticks. You end up with more whitespace but this can be used for a nice "enhance!" effect when flipping between pages. This can however end up with an unreadable version of the high level diagram, and it may need to be reorganized. And of course there is more effort in maintaining multiple versions, if maintenance is required.

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

#102
post #101

Earlier quoted context omitted.

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

One strategy that may help is to have two pages in your diagram, where one includes more detail. I don't do it often, but when needed I will create the more detailed version first, then duplicate it and reduce the detail by just deleting boxes and maybe rerouting some sticks. You end up with more whitespace but this can be used for a nice "enhance!" effect when flipping between pages. This can however end up with an…

I will give it a try. Thanks!

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

#103
post #20
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…

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

Can you comment on why you regret about choosing React and graphql? I'm asking because my Director is kind of pushing us to move from current server side rendered stack to react or some other js framework with graphql just because everyone is using it.

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

#104

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…

Oh yeah, the fun! Not making business deadline because the code base is unreadable due to over engineered solution using non-documented brittle, but cool, libraries!

Oh boy we have fun in the 5w and retrospectives when changing one corner of the app crashes everything else and the legal team now is in deep conversation with insurance to cover claims from customers.

/s

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

#105
post #72
post #43

Earlier quoted context omitted.

Can you list some recommendations? For podcasts and some articles/authors to follow.

Here are some of my current material: - I have a great time listening to "Software Unscripted" podcast. - On youtube the channel "code opinion". Although I don't like or use DDD and C#, I think that it has high quality and rewarding content. - I am currently finishing "A Philosophy of Software Design" by John Ousterhout. - Regarding articles, I read stuff related to my day's obsession or problem. I can't point you ou…

Thanks this is helpful. I have the Philosophy of Software design on my to-read list.

Really enjoying the Code Opinion videos so far.

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

#106

Earlier quoted context omitted.

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.

She also mentioned how sick she was of hearing that song played when she took to the stage at various events and how Poker Face was a welcome change :)

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

#107
post #20
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…

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

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...)

I have invested in some of these technologies. The biggest commonality is that they ALL have their faults and weaknesses. The key is ensuring everyone makes best use of whatever framework/package/tooling that you have invested in via a set of best practices and standardised processes. Over the last 20+ years, i've found you should only switch to something else if there are significant gains to be had. Otherwise it rarely offers more value.

Post reply on HN