quoteinvestigator.com/2014/02/26/lazy-job/ (archive):
I will always choose a lazy person to do a difficult job because a lazy person will find an easy way to do it.
See also: effortless effort.
This is one of Ciro Santilli's most important principles.
Steve Jobs has a great quote about this. He's totally right on this one!
You've got to start with the customer experience and work backwards to the technology. You can't start with the technology and try to figure out where you're going to sell it.
Steve Jobs Insult Response excerpt from the 1997 WWDC
. Source. TODO understand the context of the question a bit better. It is something to do with an OpenDoc thing and Java.Decide your goal first, and then do whatever is needed to how to reach it.
Don't start randomly learning tech, because that means you will waste a lot of time learning useless stuff.
There is of course some level chicken-and-egg paradox in this, as highlighted by Dilbert, since choosing an achievable goal in the first place requires some level of technical understanding.
Dilbert cartoon about designing a nuclear power plant from user requirements (2002)
Source. This cartoon illustrates well how when doing deep tech and fighting against the laws of physics, you can't just start from user requirements, but you also have to also think "what can we actually get done at all with this new technique".
The best research engineers are able to identify what is just on the cusp of the "possible", but which has the greatest value. This is the endless dance between the tech push, and the market/need pull.
However, it is much more common that people will get way too involved in learning useless stuff and lose sight of the useful end goals.
Rather, take an iterative approach:
- start with an ambitious end goal
- learn a bit of tech to try and reach it
- realize that you can't reach your end goal and pivot a bit to a related end goal that seems more realistic: the side effects of ambitious goals are often the most valuable thing achieved
- loop
There is some truth to the counter argument that "but if you don't spend a lot of time learning the basics, you can never find solutions".
However, these people underestimate your brain. The brain is beautiful, and human intuition is capable of generating interest towards the things that are actually useful to reach your goal. When you feel like learning something related to your goal, by all means, give yourself the time to do so. But this still be much more efficient than just learning random things that other people tell you to learn.
Bibliography:
- Ciro Santilli and many many others believe that backward design is a fundamental principle that should be considered by the educational system rather than wasting 90% of everyone's time with the 90% of mandatory curricula they don't care about:
- notably that school should be personalized and project driven:
- www.cartalk.com/content/rant-and-rave-36 "The New Theory of Learning" by Thomas L. Magliozzi section "Premise III: THE BACKWARDS LEARNING THEORY" says the exact same thing. Ciro actually found this when writing Cool data embedded in the Bitcoin blockchain.
- several well known teaching methods:
- a Coding Horror software specific take on this issue: blog.codinghorror.com/please-dont-learn-to-code/
- x.com/7etsuo/status/1784787045157900697: George Hotz
Everyone I've met who can program well learned it the same way: they had an idea, and then they built it.
Repeat this mantra:
Only decentralize when inevitable.
Only decentralize when inevitable.
Only decentralize when inevitable.
Some anecdotes.
Ciro Santilli never splits up functions unless there is more than one calling point. If you split early, the chances that the interface will be wrong are huge, and a much larger refactoring follows.
If you just want to separate variables, just use a scope e.g.:
int cross_block_var;
// First step.
{
int myvar;
}
// Second step.
{
int myvar;
}Ciro has seen and had to deal with in his lifetime with two projects that had like 3 to 10 git separate Git repositories, all created and maintained by the same small group of developers of the same organization, even though one could not build without the other. Keeping everything in sync was Hell! Why not just have three directories inside a single repository with a single source of truth?
Another important case: Linux should have at least a C standard library, init system, and shell in-tree, like BSD Operating Systems, as mentioned at: Section "Linux".