3 ms·

In my view, the path to mastery is to first learn the rules, follow them and then learn when to break them and then transcend all of that: https://en.m.wikiped

by prerok 3y ago

In my view, the path to mastery is to first learn the rules, follow them and then learn when to break them and then transcend all of that: https://en.m.wikipedia.org/wiki/Shuhari https://en.m.wikipedia.org/wiki/Shuhari TBH, I don't know if I will ever reach the transcendence stage, but my two cents are (after 20 years of professional programming) that breaking the rules is sometimes desired but not when the person has not even reached the first stage. The example from OP, as explained in the post, seems a clear case of never reaching stage one, following the simple rule of no duplication. The conclusion in the article is kind of good and bad: it seems the OP has reached stage two but for all the wrong reasons and there is no telling whether they now actually posses the knowledge or that they just discarded one rule to follow another, both of which can be wrong or right based on the situation.

ChrisMarshallNY 3y ago
I agree. Also, that "unnecessary optimization" thing, can be a form of "bikeshedding." Maybe the app is too slow, and the junior engineer knows Swift, so they spend a bunch of time, doing fairly worthless UI optimization, when they should have just gone to their manager, and said "The profiler shore do spend a mite of time in the engine. Maybe you should ask C++ Bob, if he can figure out how to speed it up."
Mawr 3y ago
That's not just a view or opinion, it's how learning works. Thanks for the link! When starting to learn a domain, you lack deep understanding of it, so you cannot make sound decisions without rules. But rules are always generalizations, they never fully encompass the complexity they hide. Through experience, you should become able to see the underlying reason behind the rules you've been given. Once full understanding behind a rule is ingrained, the rule can be discarded and you can make your own decisions based on its underlying principles. Then you become an expert through deep understanding of several aspects of a domain. You are able to craft solutions based off intricate relationships between said aspects. Let's take `goto` as an example. The rule you will commonly see is "don't use it". But if you're experienced enough you know that's unnecessarily constraining, e.g. there's nothing wrong with a `goto` in C for the purpose of simplifying error handling within a function. It only becomes an issue when used liberally to jump across large swathes of code. But your advice to juniors should still just be "don't use it", otherwise your advice will have to be "use `goto` only when appropriate", which is meaningless.

by prerok 3y ago

ChrisMarshallNY 3y ago

I agree. Also, that "unnecessary optimization" thing, can be a form of "bikeshedding." Maybe the app is too slow, and the junior engineer knows Swift, so they spend a bunch of time, doing fairly worthless UI optimization, when they should have just gone to their manager, and said "The profiler shore do spend a mite of time in the engine. Maybe you should ask C++ Bob, if he can figure out how to speed it up."

Mawr 3y ago

That's not just a view or opinion, it's how learning works. Thanks for the link! When starting to learn a domain, you lack deep understanding of it, so you cannot make sound decisions without rules. But rules are always generalizations, they never fully encompass the complexity they hide. Through experience, you should become able to see the underlying reason behind the rules you've been given. Once full understanding behind a rule is ingrained, the rule can be discarded and you can make your own decisions based on its underlying principles. Then you become an expert through deep understanding of several aspects of a domain. You are able to craft solutions based off intricate relationships between said aspects. Let's take `goto` as an example. The rule you will commonly see is "don't use it". But if you're experienced enough you know that's unnecessarily constraining, e.g. there's nothing wrong with a `goto` in C for the purpose of simplifying error handling within a function. It only becomes an issue when used liberally to jump across large swathes of code. But your advice to juniors should still just be "don't use it", otherwise your advice will have to be "use `goto` only when appropriate", which is meaningless.