Hacker News Reader

Comment by FlacoJones | Hacker News Reader

- 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 bleeding edge can legitimately help us (e.g. WASM coming soon...). This is part of the general keeping up with advances in industry

- Mentoring, jumping on pair programming calls to unblock other teammates.

View on HN

This reflects my experience as well. Roadmap plannings and API designing between systems, communicating and enforcing best practices within the time constraints, meetings with different service developers/designers to solve the upcoming features...

Less coding, more meeting and reviewing, overall clear view of the big picture is a must.

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 architecture as a desk exercise.

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

Seems like a lot of ongoing o&m and sustainment of an existing product, similar to any other day-to-day.

Do you have insight on what the proposal, design review, and first commits look like when architecting a brand new project? Like what do the first 30-60-90 days look like from product idea up to those o&m and sustainment activities?

What’s Docker hell?

This is basically my own experience as well.

Reply on news.ycombinator.com