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

51–60 of 107 posts

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

#51

Post by ilikerashers »

Usually have differing work depending on which phase of project lifecycle.

Early stage days are estimating + research. Often sitting with users and figuring out system complexity (from a usage and implementation perspective). Most important part of any project/transformation. Can never know enough. This is usually 2-3 hours meetings per day with users/technical groups, 3-4 hours documentation pieces.

Later stage projects are process heavy. 3-4 hours with support, incident managers, networking, testers, devs, SLA stuff, NFRs all that fun stuff. Rest of the day writing.

Overall it can be busy with long presentation prep and discovery/planning work or it can be quiet (something gets delayed) where I just go play with some new tech for a few days!

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

#52

Post by azalex »

azangru wrote: post #20
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…

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

In my opinion, the fundamental difference between an architect and a staff/principal engineer is that architects are more generalists and principal engineers are more specialised. It does not mean, of course, that architects don't or can't have deep knowledge of specific areas or that principals can't have a wide understanding of their ecosystems, but an architect absolutely must understand the ecosystem they work in and a principal engineer absolutely must understand the specific technology stack of their choice. Understanding that every choice is a trade-off and comes at a price, that someone at some point will have to pay.

You chose the latest and greatest web framework? Great! How many developers at your company will know how to use it? How long will it take for them to learn it? How big is the talent pool you can hire from? How much time will it take to migrate your products to it? Who will support it, is it "wild west" open-source or does it come with commercial support? How does it fit with your deployment model? Has it gone through rigorous threat modelling? There are about a billion factors that may affect your choices and finding the right solution will always be a central part of the problem.

To actually answer your question about how I deal with this, this is why I do research. Let's say our product people come up with a brilliant new product idea that we don't have an existing solution for, then I'll spend some time on finding information about the available options and take notes on the benefits and drawbacks. I will try to find people who are experts in the subject and get their opinions.

What I can not do, is to actually go and gain a deep understanding of every single language/platform/framework/library there is, I'm just a human after all.

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

#53

Post by azalex »

gardenhedge wrote: post #33
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…

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

It does happen, quite often, to be honest. The single most important thing in this case is to understand why it happened. A typical example is when we come up with a design proposal that I think is a good one, but turns out to be that the estimated cost of building and running it outweighs the projected revenue the product will generate. Another example would be when I want to have a particular design implemented by an engineering team but they don't have enough capacity (people, time, etc) to deliver it the way it was intended. There have been cases when it was all about politics (sadly, I must add, but it does happen), i.e. someone in higher places of power want to push their own agenda and you get overruled.

These are cases when the previously mentioned 'professional negotiator' role gets really important. These are the cases when you need to go to the people involved and try to understand their priorities and their constraints. Once you have the information necessary, most of the times you'll be able to come up with an alternative solution that is acceptable for everyone. Sometimes you can convince others to give way, sometimes you'll need to.

And then there are times when you just can't do anything because, for example, you get overruled by an overzealous CTO. In these cases, as sho_hn also pointed out, the best you can do is to make them understand the implications and brace yourself for damage control, because the fallout is going to be on you anyway :)

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

#54

Post by bcrosby95 »

azangru wrote: post #46
mickeyp wrote: post #30

Earlier quoted context omitted.

That ecosystem moves very fast and... reinvents itself all the time. Here's another way of looking at that problem: How many of those tools and technologies existed 1, 3, 5, 10 years ago? Would you trust a six month-old tool on github to form the nucleus of your -- probably mundane, in the good way! -- project? Would you risk it all for the chance to have a slightly different way of rendering CSS or generating HTML?…

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

jQuery has existed for a long time, still gets updates, is still used in greenfield projects, and has a large body of expertise around it.

The concern is abandoned projects that no one knows how to use, not that something is a bit old. React is beyond that point. It's not just the tech junkies hopping from the latest fad using it. There's been enough widespread adoption that there will still be React projects in 20 years.

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

#57

Post by djmips »

rr888 wrote: post #41
marifjeren wrote: post #31

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…

That is what it should be. From what I've seen most architects aren't like this, they play with whatever is cool then move on to the next company while the rest of us try to untangle the mess.

Let's say 'Good architects are fun killers' - but really there is still a lot of fun to be had - and if not maybe one should move to a more mentally challenging job haha.

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

#59

Post by P5fRxh5kUvp2th »

mickeyp wrote: post #13

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

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, just wanted to point out that's sometimes due to pressures rather than wants.

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

#60

Post by e12e »

azangru wrote: post #20
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…

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

Many good responses here already - but I'd say that eg choosing between react and vue or svelte isn't an architectural decision. But choosing between server rendered php and react is (is this a series of web "pages" with some forms, or is it an "app"?).

Choosing between mysql, sqlite and postgresql may be (do we need row level security? Would mysql multimaster benefit us? Do we expect to deploy many, small instances where the simplicity of sqlite will shine) etc.

There are many decisions to make building a solution - the architecture part has to do with fulfilling the requirements.

The tech-lead/senior developer/team lead part has to do with implenting the architecture - our team knows vue, so we go with that to implement the app. We're invested in ms sql so we prefer that to postgres - but sqlite would be a poor fit.

Post reply on HN