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.
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.