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

71–80 of 107 posts

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

#71

Post by throw1234651234 »

moris_borris wrote: post #26
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…

> "Trying to persuade people to avoid technical debt at all costs" - put in a linter and concrete rules (even if a rule is loose, note that in writing) or devs will get upset and think you are singling them out. I went from a company with no linter or style guidelines and PRs were an absolute nightmare. Eight devs, eight completely different styles, each insisting theirs was right. I wasn't able to turn stones into l…

I think that's the main benefit by far - avoid useless debate. The icing on the cake is that I can write code in my style (tabs instead of double spaces, parens on new line, whatever) and then have my IDE or a CLI command refactor to the team style before putting up a PR, so it's really not an issue.

I usually default to some large company's style guide so it's difficult to argue against. For example, for .NET we use Microsoft's style guide for React we use Facebook's, etc.

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

#72

Post by lexx »

nateee wrote: post #43
lexx wrote: post #15

Earlier quoted context omitted.

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.

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 out to one. I mean, what do you need to evaluate/learn?

If you need something more specific topic-wise I am glad to share with you

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

#73

Post by jvalencia »

azalex wrote: post #52
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…

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…

It's probably a good thing if you're not too expert. If you were deep into it, you might be impressed by the choices, but miss the glaring red flags: e.g. The git repo for this cool API has no adoption, no stars, no commits in the last 6 months, etc.

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

#74

Post by thrashh »

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…

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 can mix custom components without doing some weird and ugly syntax

Does React use a shadow DOM? Yes, but so could have jQuery or Handlebars.js too, and it wouldn’t have mattered. People don’t care how it works as long as it works. As far as libraries go, what gets adopted is what looks and feels the nicest — as it should be

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

#75

Post by ryandrake »

juancn wrote: post #70

I'm an influencer. I have no formal power in the sense that people are not supposed to do what I say, so I have to be convincing, and influence others behaviors to make the software better. This implies analysis and compromise, having meetings, mentoring engineers, and quite a bit of coding and research. My work is less guided that when I was a junior engineer, in the sense that I'm meant to discover opportunities fo…

I think "influencing/leading people who do not report to you" is one of the hardest, most underrated part of mid-level people's jobs. When you're a low-level Individual Contributor, it's easy: You're not expected to lead anything or influence people. Take your ticket, do a great job at it, then take the next ticket. You're given a task, design it, and implement it, and job well done. On the opposite end, if you're a director or senior manager with a big org of people who report to you, it's also easy (or seems easy from my vantage point): You simply say "we must do this thing" and people do it. In the middle, we don't have direct reports, and nobody has to listen to us, yet our job is to convince people to do the right thing. Very difficult. You need to be political, cognizant of perception as you say, you need to gather favors and then call them in, prioritize and horse trade for things that are important, and so on. Difficult job.

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

#77

Post by nrawe »

throw1234651234 wrote: post #12
lexx wrote: post #10

- Always on a state of mind of redesigning and simplifying everything - Spending a lot of time trying to figure out the business better - Studying a lot of books, articles, codebases and discussions on software architecture - Inspire the team and younger devs to avoid complex tools and solutions and stick to the basics - Balancing everyday and urgent business needs while leading towards a more simple, boring and main…

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

Those approaches are not “fluff” or overly complicated if the problem-space warrants them. There are of course limits.

If you want to write a script for use once or twice, worrying about coupling and cohesion is probably not worth your time. If you are building a system to last 2-5 years out, it absolutely is worthwhile.

If you have a dead simple CRUD problem with very little business rules/operations then DDD isn’t right either. But if you have a complex set of interactions, state, and policies it’s the right call. (The big red book of ddd has a great table on exactly this)

But there are problems out there that are suitable to those approaches. The devil is in the detail; unfortunately a lot of strategic design goes by the wayside to cargo-cult zeal.

But the same can be said for the other way of thinking. I’ve worked/work with engineers who think any form of abstraction is abhorrent and that they don’t need to care about quality because they’ll delete it all and start again (they’ve not tended to care about the opportunity cost of that to their employer, either). Any database interaction looks like ActiveRecord and all technology choices are immutable.

The key in all things is balance. What is simple vs overwrought is almost entirely down to what the framing of the problem is.

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

#78

Post by stcroixx »

Doing non architecture stuff. Reviewing designs, troubleshooting issues nobody else could solve, mentoring juniors. I wouldn’t say there are any particular resources I consult when thinking about architecture, but being well versed in design patterns and knowing how to make standard diagrams is key - it’s all about communicating ideas and outside text, those are the tools.

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

#79

Post by ryanlitalien »

mrweasel wrote: post #7
FlacoJones wrote: post #2

- It's typically a journey up and down the stack in terms of frontend, backend, and DevOps, and a journey in and out of solving inherently complex problems (where the seams of your services are, authentication) and incidentally complex problems (frameworks, machine-specific issues, Docker hell etc.) - 80% what needs to be done today/what fires need putting out, and 20% planning for the future and seeing how the bleed…

It sounds like you're very good at what you do. Sadly I've seen "architects" being more focused on drawings, crude prototypes and fluffy ideas. Basically dreaming up ideas and concepts, throwing them over the wall to developers and SREs to pick up. A previous boss of mine had to callback a candidate for a job, telling him, that despite us hiring pretty much anyone, we had no need for someone who thought of software a…

These fluff and idea types are typically called "Ivory Tower" architects (from my experience).

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

#80

Post by doctor_eval »

throw1234651234 wrote: post #12
lexx wrote: post #10

- Always on a state of mind of redesigning and simplifying everything - Spending a lot of time trying to figure out the business better - Studying a lot of books, articles, codebases and discussions on software architecture - Inspire the team and younger devs to avoid complex tools and solutions and stick to the basics - Balancing everyday and urgent business needs while leading towards a more simple, boring and main…

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

> 90% of the job is NOT overcomplicating.

I totally agree with this, but

> Most patterns like CQRS, DDD, fully event-driven etc are complete overkill and a sign of a BAD architect unless there is a real cause for it.

Once your application gets to a certain size, DDD, CQRS, and events will make your life far simpler.

Avoiding these patterns is a bit like saying that the solution to moving a piano is to get a bigger bicycle.

Post reply on HN