hanszarkov

> A lot of development jobs can be simplified into a web endpoint that hits a database.

This doesn't ring right. It might (maybe) be educational to do this, but I'd say that any "development job" that is about software development is not trivial like you say.

An "endpoint-to-database" job doesn't exist [1] - I think you're making a simplification here and the real argument is if its educational.

[1] find a job description that says REST or GQL endpoint directly to database, and doesn't have a long wishlist of other skills, experience, or design - I'll gladly take 100 of those and be on my merry way (!)

I'm a software architect, I write code every day, I design every day, I write documents every day, and I report to the VP and CTO every day.

I have met other architects that claim they "don't code" and honesty don't understand how they can make decisions and reduce risk without that background. Most of the time I have a solution because I've been there and done that.

I view my role as one that has the expertise to bring the engineering team to the next level, because if I did all the work - it would just be one person instead of many. I constantly try to unblock, solve hard problems, and reduce entropy - and let the creativity flow to the rest of the team.

This has worked for me, as a software architect, for almost a decade.

Agreed, the one thing I really think Simon [1] got right about visuals is the information they relay. Seeing a box diagram is one thing, e.g. boxes, arrows, names of tech (omg, @see AWS diagrams - they're really unexpressive deployment diagrams).

Compare that to a C4 Landscape or Context diagram - and its just night and day - so much more meaningful information and the ability to express not just structure, but to provide hints at data flows, actors, and externalities. In the end, I've found the most value for C4 in communicating architecture to upper management and new hires. These diagrams really make more sense than boxes and lines.

For arc42 I find the document content really appealing - its like engineering thinking. There is no standard template/model for design docs, perhaps this could start a baseline or trend to do something similar. I do still prefer Structural and Behavioral classifications.

[1] Simon Brown, creator of C4 https://simonbrown.je/

Many of my documents do indeed have a similar layout for design and it is nice to see efforts like this to create more rigor in SW architecture. As a practitioner (and being opinionated), I have these observations:

- The "Building block view" is really the high level Structural Design. I tend to use structural decomposition to relay this information, iteratively breaking down into subsystems, components, etc. For this reason I prefer the term Structural. - The "Runtime view" is really the Behavioral Design of the system, the sum of behaviors of a system is what you see at runtime.

I wonder if the terminology chosen for arc42 comes from a more academic or earlier time in SW architecture and design.

I'm also a fan of the C4 Model[1] for visualization. So I think I'm going to try to incorporate the two together, like, utilize arc42 for a formal and disciplined approach to architecture documentation coupled with the informative visual paradigm of C4 Landscape, Context, Containers, and Components.

[1] https://c4model.com

if you don't value human life, gtfo of texas

I have fond memories of my semiconductor physics classes. The were not easy whatsoever, rather intense.

As cvccvroomvroom had mentioned, I had my VLSI chip fabbed at the MOSIS facility in Westborough MA, during my EE tenure at UMASS Amherst in the 1990s as part of a state-wide chip design competition (yeah - didn't win..). There was much activity on VLSI and computer system design at that time, things have certainly changed in the US.

I recall many entries were implementations of various (and obscure) mathematical algorithms, mostly in the frequency domain (hence DSP chips), that tried to solve problems that are now trivial in SW today.

My school did win occasionally, others were mostly MIT and WPI - I think in a large part due to the excellent professors at all competting schools and the work ethic of the students.

My final submission was the design for an Arithmetic Fourier Transform processor - trying to remove the need for expensive ROM by aliasing the signup up-frequency - which I did the barrel-based ALU for, and thank the grad students for including me in the project.

cvccvroomvroom: https://news.ycombinator.com/item?id=31756704#31760353 MOSIS: https://en.wikipedia.org/wiki/MOSIS Barrel ALU: https://en.wikipedia.org/wiki/Barrel_shifter (my ALU did much more than multiply/divide..)

(edit - remove double paste)

Borg... sounds swedish?

ST first contact