I'm not really sure, but the thing I do most different is that I don't really trust anything. For example, in a mathematics class I wouldn't trust what they taught, instead I always tried to disprove it and I didn't use formulas I couldn't derive myself.
This is a lot of extra work, but it meant that I always had an extremely strong foundation to stand on. When I know something I really know it, and having learned this way since early school I have spent a really long time doing it so it covers quite a lot.
Also when you learn this way you don't forget, so it just compounds. There is no way a person who "cheated" by implementing for example algorithms and data structures without deriving things themselves can compete. They have spent their entire lives learning how to apply things without understanding, they would have to redo all of that to catch up.
When you know things this well then being much faster than others is not very hard. Also creating original solutions is not something scary or time consuming, it is something you've done throughout your entire life.
Anyhow, I am not sure if others can learn this way, I just know it works for me. I've tried teaching others to do it, but it didn't work that well. It might be that it was too late, I just naturally learned mathematics this way from early school so I already knew how to think about algorithms before I even started programming. I mean, calculating things by hand or in your head are the original algorithms so if you can confidently alter those as you wish then you already know the basics of programming.
- Know your foundations, deeply. Don't memorize design patterns and algorithms: instead, learn how to arrive at them organically and how to analyse and understand them.
- Avoid overengineering like the plague and stop seeking perfection. I've seen lots of teams of "1x" engineers fail because they're too worried about peer approval, so they end up trying too hard to arrive at the "perfect" solution. And then business changes its mind and they have to rearchitect everything.
- Accept that business people will change their minds and design your software around it. The world doesn't revolve around your precious codebase. If the higher ups want to change something, you have to do it. Your codebase should have been malleable enough for a 180 degree pivot.
- Stop chasing unicorns. Yeah, maybe Vim will give you that extra 10% edge you need, but if you're comfortable with Atom, why change?
- Keep it simple, don't be clever. Only use the subset of the programming language that is free of "gotchas". What's the output of `[].push(1)` in ES6? Who gives a shit? Keep that stuff out of your code.
- Learn to evaluate if using an external dependency is actually faster than writing something from scratch or just copying some code. Sometimes it isn't, and people miss out on having simpler code, simpler interfaces AND learning new stuff because of that. Of course, you're not going to do that with a crypto
- Avoid things that might slow you down. The CI taking 30 minutes to run or the compilation taking 10 minutes are a sign that you're doing something very wrong and too complicated.
--
As for practical recommendations:
- A single integration test is better than multiple disconnected unit tests that have the same coverage. It allows you to change your code without changing the tests.
- Avoid transitive dependencies in your classes/functions by using simple Dependency Injection. Just pass those dependencies as a parameter or whatever. This will help you have units of code that are more testable, more flexible and don't require maintenance. Also you don't need those mock-in
- Make code simpler to read and to debug. Avoid reflection, metaprogramming and stuff like that. Don't do things that require magic.
This is a lot of extra work, but it meant that I always had an extremely strong foundation to stand on. When I know something I really know it, and having learned this way since early school I have spent a really long time doing it so it covers quite a lot.
Also when you learn this way you don't forget, so it just compounds. There is no way a person who "cheated" by implementing for example algorithms and data structures without deriving things themselves can compete. They have spent their entire lives learning how to apply things without understanding, they would have to redo all of that to catch up.
When you know things this well then being much faster than others is not very hard. Also creating original solutions is not something scary or time consuming, it is something you've done throughout your entire life.
Anyhow, I am not sure if others can learn this way, I just know it works for me. I've tried teaching others to do it, but it didn't work that well. It might be that it was too late, I just naturally learned mathematics this way from early school so I already knew how to think about algorithms before I even started programming. I mean, calculating things by hand or in your head are the original algorithms so if you can confidently alter those as you wish then you already know the basics of programming.