Absolutely this. When facing a tough problem it’s a great tactic to write out what you’re trying to solve and how you plan to solve it in prose-style English.
I’ve done it often without ever sharing my writings with anyone at all, and always felt that the code turned out relatively good as a result.
I’d also add that a very prototype that you throw away also helps line up your thoughts.
The key is having something reasonably concrete in front of you that forces you to think of the invariants, compromises, etc in the system. Before making all those decisions concrete by writing loads of code
I agree with this to a large extent. A new codebase in the latest Java/whatever can be OK. But most of the time I feel like it's dealing with the same bad code, with just a smattering of nice syntax on top.
I started learning Perl in 2007; after it was no longer popular, but also around the time that the principles/practices that became 'Modern Perl' were becoming popular in the community.
I think there is a difference between the two though. Java was always a language which required a lot of ceremony and typing to get anything done at all. Perl was always focused on expressivity. Modern Perl was a case of learning from past mistakes and consciously avoiding some of the more egregious code the language easily afforded. Modern Java is more a case of Java playing catch-up to the more expressive languages out there.
One is applying constraints on your coding style, the other is trying to lift constraints. Both are trying to reach some middle point.
But! I agree that no company writes purely 'Modern Perl' - you will have to deal with some terrifying code at some point.
So. I agree with the concept of the 'Modern X' fallacy, but I would say that dealing with non-modern code is pretty normal, and people who are OK putting up with the pre-modern code may be some of your best employees. I suffer from rewrite-it-all syndrome myself sometimes, but it's something I try to avoid. Code that frustrates me, isn't necessarily bad.
(If it helps contextually, I'm - at heart - a Clojure programmer.)
I’ve done it often without ever sharing my writings with anyone at all, and always felt that the code turned out relatively good as a result.
I’d also add that a very prototype that you throw away also helps line up your thoughts.
The key is having something reasonably concrete in front of you that forces you to think of the invariants, compromises, etc in the system. Before making all those decisions concrete by writing loads of code