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…
Ask HN: Software architects – what’s your typical day look like?
101–107 of 107 posts
Re: Ask HN: Software architects – what’s your typical day look like?
#102Earlier 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…
Re: Ask HN: Software architects – what’s your typical day look like?
#103The 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…
Re: Ask HN: Software architects – what’s your typical day look like?
#104Noticing 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 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?
#105Earlier 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…
Really enjoying the Code Opinion videos so far.
Re: Ask HN: Software architects – what’s your typical day look like?
#106Earlier 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.
Re: Ask HN: Software architects – what’s your typical day look like?
#107The 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…
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.