Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Architecture diagrams enable better conversations

unravelled.dev

Post reply on HN
Print view View original

11–20 of 141 posts

Re: Architecture diagrams enable better conversations

#11

Post by sarchertech »

jrimbault wrote: post #4

I failed a number of technical interviews because I can't make architecture diagrams. I come out of the first tech interview, coding/debugging, with praises. But then comes the second, the architecture interview, and I can't for the life of me draw the architecture of anything. I don't know how people learn to do that, I've learned to code/debug by being obsessive about it. But I don't see how that happens for system…

Do you know how to design systems, and you just can’t draw them? Or do you need to learn how to design systems.

If it’s the former, just practice drawing something you’ve designed with boxes, labels, and arrows.

I’d it’s the latter I’d recommend https://www.goodreads.com/en/book/show/54109255 as a good intro to the kind of “systems design” they do in interviews.

Re: Architecture diagrams enable better conversations

#12

Post by kzhen »

sarchertech wrote: post #11
jrimbault wrote: post #4

I failed a number of technical interviews because I can't make architecture diagrams. I come out of the first tech interview, coding/debugging, with praises. But then comes the second, the architecture interview, and I can't for the life of me draw the architecture of anything. I don't know how people learn to do that, I've learned to code/debug by being obsessive about it. But I don't see how that happens for system…

Do you know how to design systems, and you just can’t draw them? Or do you need to learn how to design systems. If it’s the former, just practice drawing something you’ve designed with boxes, labels, and arrows. I’d it’s the latter I’d recommend https://www.goodreads.com/en/book/show/54109255 as a good intro to the kind of “systems design” they do in interviews.

Hi jrimbault, article author here, like any skill this needs to be developed. As sarchertech says if you already know how to design systems but struggle with the drawing then practice is the key. When I started out the diagrams I produced were messy and not very presentable, but I kept refining them. Take the opportunities you have before you, for example, if you're building a system at work then take some time to try and draw up some architecture diagrams and run them by some people who you think will give you good feedback. Then keep refining them. If it's the later then there are some videos on youtube that introduce the C4 model - the key thing is to pick a method and try to stick with it, whether that is c4 or arch42 etc, try to learn the underlying principles and apply them.

Re: Architecture diagrams enable better conversations

#13

Post by politician »

jrimbault wrote: post #4

I failed a number of technical interviews because I can't make architecture diagrams. I come out of the first tech interview, coding/debugging, with praises. But then comes the second, the architecture interview, and I can't for the life of me draw the architecture of anything. I don't know how people learn to do that, I've learned to code/debug by being obsessive about it. But I don't see how that happens for system…

The ask is to flatten a multidimensional space into a 2D plane, so out of the gate you're going to have problems. A really good architectural diagram doesn't have a lot of crossed lines, but you can only really do that when you have a small number of nodes or when the dataflow is broadly unidirectional.

The interview is inherently unfair - when you use a drawing tool to build diagrams the work is iterative, but erasing marker during an interview looks like you've made a mistake.

Start with a small top-level diagram, then build a hierarchy of increasingly detailed diagrams. Use the opportunity to steer the interviewer ("which area would you like to see in more detail?"). It also helps to have an understanding of how small bits of code map to graphical sketches, so that you can compose them later.

Also, keep in mind that issues like poor handwriting and sloppy lines are exacerbated by large detailed diagrams.

Re: Architecture diagrams enable better conversations

#14

Post by swozey »

jrimbault wrote: post #4

I failed a number of technical interviews because I can't make architecture diagrams. I come out of the first tech interview, coding/debugging, with praises. But then comes the second, the architecture interview, and I can't for the life of me draw the architecture of anything. I don't know how people learn to do that, I've learned to code/debug by being obsessive about it. But I don't see how that happens for system…

I work in platarch and I'll fully admit that my diagrams aren't the best, pretty ugly tbh. The people who do great diagrams typically have a lot of experience drawing them on whiteboards during meetings. It just hasn't been something I've done much and do it even less now that WFH. If you want to improve I'd recommend getting a whiteboard for your office and just start using it, then also learn mermaid or whatever language/app you want to use.

I did use to make diagrams all the time when I was a field engineer for a distro company. Getting one of those small wacom tablets is really helpful in that case. I could draw in whatever app I was using at the time like draw.io or diagramly, I forget.

I guess if we're all WFH now the latter is more important.. not sure if I'll ever have to whiteboard again..

Also, I ran across this today, making diagrams as gifs. Really interesting. Way too much work for me, though - https://aws.plainenglish.io/aws-architecture-in-motion-creat...

Re: Architecture diagrams enable better conversations

#15

Post by kzhen »

politician wrote: post #6

One of the areas I would like to see addressed in guidance for drafting both architecture diagrams and specifications is in the documentation of the basis for design decisions. Which risks catalyzed a particular design or approach on a particular feature and to what degree? In my own work, when I need to revisit a spec months afterwards, I often have trouble because I've forgotten parts of the context that I had at t…

Hi, article author here, we supplement our architecture diagrams with Architectural Decision Records (ADRs) https://github.com/joelparkerhenderson/architecture-decision... in the ADR we capture: - options considered - pros/cons of different options - chosen option - who was involved in making the decision

there are a few other fields like component, product etc these are very useful for capturing decisions and something I should have mentioned in the article.

Re: Architecture diagrams enable better conversations

#18

Post by Veuxdo »

samsquire wrote: post #3

I've had the idea that graph diagrams (including architecture diagrams) can be paged - you show a different set of links/vertices on each page of the same graph (show the same node but different enumeration of edges). Many codebase visualisations I've seen were too complicated to understand because the diagrams were so large. (I've seen some visualisations generated from code that were so small when panned around you…

> I've had the idea that graph diagrams (including architecture diagrams) can be paged - you show a different set of links/vertices on each page of the same graph (show the same node but different enumeration of edges)

You're describing something very similar to Ilograph[0] with its multiple perspectives.

[0] https://app.ilograph.com/demo.ilograph.Ilograph/Request

Re: Architecture diagrams enable better conversations

#19

Post by buro9 »

https://c4model.com/img/c4-overview.png

That's what the argument is... and I'm in favour, there used to be such great architectural tools that were mostly UML but they did this well.

I miss Visio, it was awful but everyone used it and it improved communication.

I feel Google Suite is missing an equivalent, it's now draw.io, there's a real gap here.

Post reply on HN