Live data from Hacker News

Behaviours to avoid in a software architecture role

danielwatts.info

51–60 of 174 posts

Re: Behaviours to avoid in a software architecture role

#51
post #49
post #10

Earlier quoted context omitted.

Even when they have indefensible positions? When the idea doesn't hold up to ~2 hours of research?

More like when you've been at the company for about 3 weeks

What about the inverse? The CTO is the new person in my situation.

Re: Behaviours to avoid in a software architecture role

#53

Software architects is a critical role. Need someone with higher level knowledge of the system to make sure every decision makes sense.

Software architecture is a critical responsibility.

There is more than one way to get that taken care of, and it tends to work better when the people who are responsible still have their hands in the code.

I've seen too many pure architects spout off about how the system works and not notice the meaningful glances among everyone else at the table. That's how you wanted it to work. We couldn't make that work (possibly because Information Theory or physics) so we did something else.

Re: Behaviours to avoid in a software architecture role

#55
post #38

Earlier quoted context omitted.

Hard disagree. Thinking you can separate form from function is the evergreen mistake of our industry.

But you can. The separation is critical to the entire computing industry. The entire reason why higher level programming languages exist is to separate the form (assembly) from function. Usually there are "costs" to doing this and much engineering work is done to reduce this cost as much as possible. Either way, what you say is categorically wrong. Separating form and function is not a "mistake" given that it is so f…

Ah, but I would argue those are better described as form and function being part of the designs. Done wholistic, it is why the new apple hardware is able to take some very impressive gains.

You can argue that some interfaces are separate products from the services. I agree with that. But each has its design and each is targeted on form and function to something.

That is, you don't separate them. You make a new product, that has its own form and function.

Re: Behaviours to avoid in a software architecture role

#56

Is software architecture role the end game for SWEs?

When I'm managing junior folks, I generally advise them there are three main paths: 1. Keep focusing on IC/software work. You keep growing and having larger impact, capping off with an architect type role. 2. Lean into project management, full stack, and business a bit. Become a tech lead for increasing large/important projects. This is a great general path that still lets you be pretty close to the code. 3. Focus on business & people. Gain experience mentoring teammates, then interns, then become a people manager. At some point you're going to be trading cutting edge coding skills for mid level management skills. You can branch off to focusing on CTO or engineering leadership from here.

There are definitely a lot of other paths, but that above three are the most "well worn" and achievable in my experience.

Re: Behaviours to avoid in a software architecture role

#57
post #12

People downplay software architects but I've found it's a critical role. You have to interface between business and stakeholder requirements, modeling the domain effectively, engineering management, product processes and then reality. A lot of business logic ends up encoded in the software so you really want to isolate it as much as possible so that when change is needed you know where to look. That and you have to c…

> You have to interface between business and stakeholder requirements, modeling the domain effectively, engineering management, product processes and then reality This is the Technical product managers job. The architects role is suppose to be an extreme high level view of purely the technical side of the business. From my own anecdotal experience "architects" who try to fulfill the role to the definition end up bein…

I've had my worst experiences in teams where the Product and Engineering were completely siloed. Things go a lot more smoothly if there's a bit of overlap. Also, many orgs don't have a TPM role, so that falls on Staff/Principal engineers and engineering managers. In fact, roles should be fluid and slightly overlapping, as every team and every org will have different needs.

Re: Behaviours to avoid in a software architecture role

#58
post #7

21 years at Microsoft led me to have great disdain for "Software Architects". 5 years at Amazon led me to fall in love with the concept of a community of Principal Engineers. The Amazon Principle Engineering tenets are amazeballs. Exemplary Practitioner - Principal Engineers are hands-on and lead by example. We deliver artifacts that set the standard for engineering excellence, from designs to algorithms to implement…

This is a bit too buzzwordy for me. > Resounding Impact > game-changing technology choices. > aligning teams toward coherent architectural strategies. > lead by example > pioneer new spaces > inspire others as to what’s possible. > pragmatic problem solvers > bring clarity to complexity > illuminate pitfalls > probe assumptions and foster shared understanding. This perfectly illustrates why ppl dismiss software archi…

There was one key entry there, actually coding. Non-coding architects are rife with the possibility (but not certainty) of being too disconnected from the reality of the systems they are working on.

Re: Behaviours to avoid in a software architecture role

#59

Earlier quoted context omitted.

The console is a UX/UI issue, not a "architectural" one. Most "architects" nowadays are just mere users of what was built by the engineers and principal engineers of amazon.

To be fair, most of AWS's services are also mere users of other AWS services

Naw. The term "mere" was to de-emphasize the importance of the term "architect" which doesn't apply to other AWS services.

The parent poster declared that AWS needed some "architects" which I think is kind of arrogant given the fact that most "architects" don't even have the ability to engineer the tools built by AWS. They are just "mere" users of the tools.

Re: Behaviours to avoid in a software architecture role

#60

Earlier quoted context omitted.

I think FIRE is the end game for SWEs.

with the housing cost I think it is impossible to do FIRE even with SWE salary.

This is not a rhetorical question:

Do you still want to live close to SV when you're not working there anymore?

Your burn-down rate for your retirement fund is predicated pretty substantially by the standard of living you maintain after you retire. If a lot of your day to day activities become indefensible once you can't justify it based on work concerns, then your costs may be lower.

Look, for instance, at all the fancy cars that real estate agents have to drive to exude competence. They end up leasing a high end car, when maybe all they want is a 2013 Subaru Outback for activities and half a closet of clothes from Duluth and Patagonia that last forever. Once you pull on that thread, then moving to an exurb might make sense too.

Post reply on HN