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

81–90 of 107 posts

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

#81

Post by Too »

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…

Jquery got squashed from two directions. One being react and other data binding frameworks, the other side being browser tech modernizing and aligning, such that bare js could be used, without a thick compatibility layer in between.

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

#82

Post by stronglikedan »

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

CYA. Send an email to the higher up stating the negative impact that their decision will impose, and ask them to confirm that they would still like to proceed. Then don't do anything related to that decision until they respond.

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

#83

Post by gautamdivgi »

e12e wrote: post #60
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…

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…

My personal take is I would go a level higher and define data consistency and availability requirements. Provide them to dev teams and if the teams need help meeting them I provide recommendations.

I generally try to keep design out of architecture. It’s what you need to satisfy product or service needs. The technology gets into how you want to implement. I try to leave that to the tech lead for the team.

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

#85

Post by doctor_eval »

vbezhenar wrote: post #49

I'm not sure that I'd qualify as a software architect. I work in a small software company and basically I do all important IT decisions. I'm kind of architect and full stack developer and devops at the same time. So sometimes we do some design meetings. I suggest how to better design database, etc. I'm trying not to dictate everything but rather catch mistakes which are obvious from my experience. Avoiding mistake ea…

The thing is that in computing, the “janitor” stuff is the hardest, and needs to be done by the best people. Keeping things clean is really tough, and only people who understand what “clean and simple” means, can do it.

Outside of actual system design and writing code, I have spent a huge amount of my time over the last few years doing things like setting up CI/CD, E2E testing, writing templates, etc. Because it’s really hard to get this right, to have a vision for how things should be.

My point is that it sounds like you’re doing an awesome job. I’m sure you qualify as a software architect.

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

#86

Post by SgtBastard »

throw1234651234 wrote: post #24
sidmitra wrote: post #18

Earlier quoted context omitted.

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

Definitely nothing against what Lexx said. I did want to call out that most architects over-complicate in my experience. What we do just isn't as profound as people make it out to be unless you are genuinely working on some latest ML for billions of revenue or stabilizing SpaceX's landing thrusters, sequencing DNA, etc.

Having a broad and deep understanding of a range of design patterns in an otherwise banal enterprise environment is critical when the existing technologies you work with are numerous, decades old and have built up like layers of sedimentary rock.

>in my experience

Friend, you're making it clear that you don't have much.

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

#87

Post by DoingIsLearning »

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 stages of projects act as Architects, just not as a full time role.

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

#88

Post by 0xbadcafebee »

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…

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

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

#89

Post by gorgoiler »

First up: having total visibility of the org is really important. We have a hundred engineers and I see everyone’s changes at the point they make them public (in whatever form they are called today: pull requests, merge requests, diffs, eh.) Unless I engage then that’s the first and last time I see their stuff but it’s enough to stay on top of everything everyone is up to. It’s a surprisingly low volume / high value channel of information.

Leave the code review to the experts in each codebase — most changes will be on point and need only a small or large amount of alignment before they can land. (By contrast, very few things need to have the brakes put on them.)

Some changes though will correlate with other problems across the codebase and this is where you should be stepping in to spot future patterns or current anti patterns and providing solutions and directions forward, or at worst, road blocks.

Once you have enough of these under your belt you can start proactively spotting hot spots in the eng org that need focused effort. More mypy typing for a core library. Two libraries that should be one. One library that should be two. Vertical slices of functionality in two products that should be horizontal slices pulled into a separate service (or, my preference, library.)

Processes are important too. You’ll see what people are repeating and or finding hard, and which could benefit from some love. Build infra. A testbed for debugging a process that is otherwise too heavyweight with production data. Teams that don’t talk enough pre-PR. Managers that need help managing consistent poor performers.

I think many people wanting to go into an architect career think it is highbrow design work. In reality, I’ve found you end up doing much more support / boiler room / janitorial work. It’s very satisfying, and very much reminds me of my career sidetrack as a school teacher. Above all, you are there to help people and teams reach their potential and get the most from their jobs.

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

#90

Post by jononor »

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…

Realize that a perfect solution is not feasible (it does not exist). Not even an optimal solution for your particular problem is feasible (too many unknowns about both the problem and potential solutions, impossible to uncover and analyze them before hand).

Realize that if you had chosen another solution, you would have other issues. Not "no issues". Probably not even "fewer issues" or "less severe" issues - just as high a chance

Realize that most technology choices actually have very little impact on the business. If one uses A or B, it does not matter much to do whatever it is your company does. Very few tech choices have the potential to kill the company/unit/product.

Realize that once a choice has been made, worrying about it does not help anyone.

So the goals are not perfection. Not anywhere close. Just something that:

1) lets us move forward now (avoid decision paralysis)

2) not worse than before (if so, just stick with what you got)

3) good _enough_ to deliver the needed business value

4) does not paint ourselves into a corner. Then we can always fix and improve things later

Post reply on HN