As an undergraduate, I wondered how it was possible to write code professionally, because I could only barely fit the semester-long programming assignment in my head. When I asked my professor about it, I got an independent study credit to learn about UML.
UML (as a representative example of thoughtful documentation) is a partial answer. But actually a much larger part is that with practice I can hold a lot more code in my head. Today, that semester project seems trivial and if I see a stack trace I can tell you how to fix the bug that caused that exception to get thrown.
As a senior dev, I’d answer “how do you remember what your code does?” with
As you work, you get better at just remembering
As you find patterns and follow them, you’ll have less to remember (I bet I know what the downloadUnpackUpdate() method does!)
As you do the first two, you’ll learn to recognize when comments are helpful
I’m still waiting for the day I see UML in a professional context. My undergrad teachers were all about it.
Similarly, I don’t design software using design patterns, and I’ve had to discourage juniors from forcing them into projects where they don’t add any value. But that’s not to say design patterns aren’t useful. They do exactly what you say, allowing your brain to recognise a pattern so you can remember or communicate it without having to go into details. Most of the time it won’t be an exact fit for the ideal pattern implementation, but it’s still easier to remember the variation.
I wish they were taught more as communication and cognitive tools than silver bullets for good software design.
In the real world there aren’t even that many patterns. On a very large project you’re likely to see the same patterns repeated throughout the system, because a good architecture doesn’t add variation and complexity unless there’s a lot of value to gain. You learn the default way, and then the diffs.
Actual UML-according-to-some-books is old and unpopular now. I think C4 is taking its place, in that I’ve seen architect-types ask for it. More generally, I really like PlantUML and the prettier-looking Mermaid which both allow me to code diagrams using a text document.
Yeah, I agree: academia gets people expecting to go, “give me 2x Visitor Pattern, then 1 Builder Pattern, then as many Divide and Conquers as you need to reach the end”. It can be nice to have a name for things, but most of the time I’m asking for, “see how the setup, actual work, and cleanup are nicely divided up? Do like that.” Or, “let’s put all the related endpoints in the same file.”
As an undergraduate, I wondered how it was possible to write code professionally, because I could only barely fit the semester-long programming assignment in my head. When I asked my professor about it, I got an independent study credit to learn about UML.
UML (as a representative example of thoughtful documentation) is a partial answer. But actually a much larger part is that with practice I can hold a lot more code in my head. Today, that semester project seems trivial and if I see a stack trace I can tell you how to fix the bug that caused that exception to get thrown.
As a senior dev, I’d answer “how do you remember what your code does?” with
downloadUnpackUpdate()method does!)I’m still waiting for the day I see UML in a professional context. My undergrad teachers were all about it.
Similarly, I don’t design software using design patterns, and I’ve had to discourage juniors from forcing them into projects where they don’t add any value. But that’s not to say design patterns aren’t useful. They do exactly what you say, allowing your brain to recognise a pattern so you can remember or communicate it without having to go into details. Most of the time it won’t be an exact fit for the ideal pattern implementation, but it’s still easier to remember the variation.
I wish they were taught more as communication and cognitive tools than silver bullets for good software design.
In the real world there aren’t even that many patterns. On a very large project you’re likely to see the same patterns repeated throughout the system, because a good architecture doesn’t add variation and complexity unless there’s a lot of value to gain. You learn the default way, and then the diffs.
Actual UML-according-to-some-books is old and unpopular now. I think C4 is taking its place, in that I’ve seen architect-types ask for it. More generally, I really like PlantUML and the prettier-looking Mermaid which both allow me to code diagrams using a text document.
Yeah, I agree: academia gets people expecting to go, “give me 2x Visitor Pattern, then 1 Builder Pattern, then as many Divide and Conquers as you need to reach the end”. It can be nice to have a name for things, but most of the time I’m asking for, “see how the setup, actual work, and cleanup are nicely divided up? Do like that.” Or, “let’s put all the related endpoints in the same file.”