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

41–50 of 107 posts

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

#41

Post by rr888 »

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.

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

#42

Post by atom_arranger »

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…

  - Keep your code reasonably clean
  - Use strong typing
  - Make sure your tests don't test implementation details if possible
    - e.g. using more integration like tests written with react-testing-library
    - e.g. using visual regression tests
  - If you sense something is off about the tech stack make a POC of partially migrating to something else as soon as possible
  - If the thing you tried is better come up with a plan to migrate and do it as soon as possible
  - If you've followed all the bullet points above then switching to a better solution shouldn't be that difficult
That's how I try to deal with it. Also if you're not sure which thing is better do POCs with both solutions. Alternatively if you're working on a greenfield project and a week in things don't feel right don't be afraid to try rewriting it with one of the alternatives you were considering, it'll be a slight hit to productivity for a day or two but it'll pay off long term.

By following these guidelines I've never felt on a project that I've painted myself into a corner with the tech stack, or chosen something very bad that is not reversible.

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

#43

Post by nateee »

lexx wrote: post #15
throw1234651234 wrote: post #12

Earlier quoted context omitted.

"Studying a lot of books, articles, codebases and discussions on software architecture" - like what? 90% of it is "write clean code", "put in a cache", "normalize your db", "use a queue if the service is really spotty/unreliable". "Fundamentals of Software Architecture" is 95% fluff. So is "Clean Architecture". Most patterns like CQRS, DDD, fully event-driven etc are complete overkill and a sign of a BAD architect un…

Apart from those best seller books, the are great podcasts and articles that people discuss their experiences in depth. It helps me a lot, to compose a more holistic thinking. Technical debt does not increase only for technological reasons but also from business expectations. You can't just "build" a new garden and leave it be. You have to maintain it also. Keeping the system clean and well oiled before building more…

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

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

#44

Post by comprev »

There is much diplomacy involved as the wider the scope of the project, more teams are involved, resulting in even more "right" ways to do X.

Although I'm not an "architect" by title, things I build do impact many teams as we move towards standardising how to do X.

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

#45

Post by FpUser »

I was a software architect at the end of the 90s before becoming CTO and then going on my own so it is a bit rusty.

Most of my time was spent on high level design of complex business and B2B products and making sure that managers, business analysts and programmers do their jobs. Also selecting technologies etc. I still had about 50% of my time left for actual work so I would always pick some particular chunk and create design documents with diagrams given to programmers and would also code some chunk. I could have avoided doing any "productive" stuff but I did not want to loose touch. Being converted to a pure manager was not in my nature.

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

#46

Post by azangru »

mickeyp wrote: post #30
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…

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 straightforward to gradually wean oneself off of it. I don't know how firmly we are going to be stuck with React when its time comes.

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

#47

Post by zerkten »

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…

>> architects are fun killers!

I strongly disagree with this. Fun killers are working late nights to remedy poor planning, or getting paged multiple times every night because people didn't make informed choices. It kills the fun for the employees as well as others they interact with.

A good architect includes someone who understands the needs of the people in terms of growth and satisfaction. They'll push back on schemes that introduce toil and try to align around good bets that contribute to your skill set. That may involve blocking use of technology X which has Y long term consequences. The consequences of that long-term choice need to have counters to keep the people engaged, so the good architect considers how to manage that. They don't always get that right and we have some less well-rounded architects, but we should aspire to doing this.

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

#48

Post by comprev »

jupp0r wrote: post #27
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…

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…

Similar to management roles in the armed forces - those on the ground have to make split second decisions based on the latest information they have to hand. Getting it wrong usually has fatal consequences and it takes a certain personality trait to continue making those decisions.

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

#49

Post by vbezhenar »

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 early is very important IMO.

Recent months I designed Kubernetes cluster. We have plenty of small and medium services and environments thrown around in a few dedicated servers. It's a giant mess. I dread when I need to untangle it. So it was unavoidable to redesign devops from the scratch and I decided to go with Kubernetes. I basically tried few approaches, some turned out to be too complex, e.g. I built a complete automation on terraform, shell scripts and flux and ditched it out, because nobody but me would understand it and I don't need that kind of job security. I ended up with a simplest setup possible. Terraform provisions servers (we use hoster with OpenStack), then I manually run kubeadm with prepared configs, then I run few shell scripts to install important stuff with helm, then I install our services with kustomize. I think it was very nice outcome. Simple and approachable for everyone who knows basics of Kubernetes. Not full-fledged GitOps, but I decided that we're not ready for it yet. That was one example of project that I did myself because we didn't have necessary expertise.

Right now I'm adapting our projects to work with Kubernetes, improving builds, adding health checks, writing yams, etc.

I also made a foundation for some important core projects which I couldn't trust others to design. Then people continued my work. It seems to work fine so far, I oversee those projects to keep them in a good condition.

Also I chat a lot with developers who stumble upon hard issues and struggle to resolve those or they can't make some decision.

And I have some vision how our system as a whole should look like in an ideal world. We don't have resource to implement that vision and probably never will, but I consider it a good direction so I'm trying to point important decisions to that direction.

Also I sometimes walk over repositories and fix stuff I don't like. Usually devops stuff, like bad dockerfiles, missing dockerignores, outdated dependencies.

Sometimes I feel like a janitor, LoL.

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

#50

Post by ARandomerDude »

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…

Nevertheless the point is the same. Some technologies are more stable and broadly adopted than others. A slice of the total risk management pie entails selecting a tech stack that is less likely to die soon than its competitors.
Post reply on HN