For a few years it has felt so difficult to start something - perhaps a curse of “experience” is that you see the failure modes ahead of time. I think I’m overall more efficient, but my motivation to just strike out there and try something has been wrung out of me.
Lately I’ve been trying to trick myself into working through that feeling and learning on the side. A desire to “finish” (i.e. write up as a blog post, publish software, send to a friend) is what gets me to overcome this bias to inaction. But it still shocks me how much more creative energy I had as an 18 year old than I do now.
A lot of hobbies, crafts, and activities really only start to become fun (rather than "rewarding but tiring") when you start to get good at them, because you have to think/work less hard to achieve basic satisfying outcomes.
Learning how to play the guitar was frustrating for me, but my stubbornness to be able to play the music I listened to is what kept me going. I'm constantly listening to music and I knew I would enjoy it in the long run so I'm glad I stuck with it, but man, the first hundred hours or so of learning honestly wasn't enjoyable to me. I love it now but it felt like a chore at the time.
I think this "making it look easy" is probably most relevant for ballet, where high level dancers still train very "basic" movements or use a lot of muscular effort to create the illusion of lightness etc.
I tried taking salsa classes once. Was going to 4 classes a week. The instructor told me it would be a year before I'd be able to lead. Of course that was one instructor's opinion. I stopped after 4 weeks and feeling like I was making zero progress. It was not fun to feel like I was in everyone else's way not being able to keep up or not being able to transition from one move to the next. Also not really a fan of salsa.
I've taken maybe 10 swing dance classes as well but zero progress. Bad teachers maybe.
Also, find a place where the partners swap / dance around, ideally during the lessons as well, you'll learn more and won't feel like you're boring everyone. You'll also recognize more people and possibly be more willing to ask people to dance.
I did much better when sticking to one style, getting it down, then starting the next. I found that mixing them just got them muddled.
I also found I greatly preferred swing, both the music (former sax/clarinet player) and the crowds. Swing dancers seemed more focused on having fun and generally less snobby.
As for leading, I improved greatly when I: 1: found a few partners who could back lead to show me what I was doing wrong. Its generally poor technique, but it greatly helps with getting the strong connection needed to telegraph the moves. 2: Understood the connections and flow enough to vary the patterns on my own.
It's a great way to make up for all the time stuck sitting a computer.
That doesn't mean I won't try again though
It’s nowhere near enough time to become say a short order cook, but plenty of time to learn to make bacon and eggs for breakfast in whatever specific way you want it.
I think even 100 honest hours learning something will get you further than you probably need to go, e.g. basic home maintenance stuff that is just 1. find the right youtube video, 2. have the tools, 3. don't be a moron.
god knows that my far beyond satisfactory level of dotfile / config tweaking has probably paid fewer dividends than I'd like to think...
I know a lot of seemingly "talented" people. How do they pick up a new instrument in 2-3 months? Or be able to balance on a skateboard after just a little while? Or get kills better than me with only 200 CS GO hours clocked?
The answer is always that they spent a lot of focused time earlier in life, or that they spend a lot of time that I wasn't aware of -- like I find out that they have 2500 hours in CS:S on another account... yeah that makes a lot more sense.
I don't believe innate talent exists. Other than that some people are mentally quicker, or have faster reflexes, or are physically more capable -- "general" things. But talent exists only from both hard work and time, which for many things can start at age 2 or 3.
I don't understand how this distinction is supposed to work. If someone has exactly the 'general natural inclinations' that fit to a certain activity, it seems asinine to not call them talented in it. Sure, they won't be skilled in it unless they actually put in the work, but they'll comparatively have an easier time with it.
Like when one person says "A natural born musician" they are usually not just suggesting the person has general traits good for music. They often just believe the person was born with musical talent pre-programmed somehow.
There is a time, early in life, during which traits are more plastic, for a variety of reasons (for height, nutritional interventions are more likely to be successful early in life than during the teenage years), but you won't make a genetically slow phenotype into a top 1% 100-m specialist.
How are you assessing that?
In the Picasso example it seems you are confusing "practiced extensively since early childhood with extraordinary external support and training and unusual personal motivation" with "innately talented" (whatever the latter is even supposed to mean). I would imagine that some of the people you know have some similar (probably less extreme) background.
Watching my 2 small kids learn and grow, they can over the course of a few months go from not wanting to try something at all because it seems impossible or scary to performing competently, with the only thing in the middle being occasional short attempts (like 10 minutes at a time), spaced weeks apart. Then once they feel basic competence, they can continue to improve very rapidly, while having a better and better time.
Just before the pandemic we had gathered 4 3-year-olds together. Kid A was embarrassed at being a beginner riding a balance bike and refused to even try because kid B was already skilled at it (kid A is now also a pro 1 year later), neither of kids A and B wanted to try going across the monkey bars while kid C had no problem (because his dad had been encouraging him with candy placed further and further away along the monkey bars for a few months), kid C who didn't do much daily running compared to the others felt bad that he was much slower at running.
And the same can be seen for drawing, throwing a ball, reading, playing a musical instrument, speaking a second language, solving simple logic puzzles, building with construction toys ....
At this level, none of these differences are primarily due to "innate talent". There are multiple orders of magnitude difference in skill to gain in a very short time, with fast returns to small amount of spaced practice.
1) time is limited
2) the map is huge
3) the topic might be totally unknown
You have to devise ways to explore neither too fast nor too slow.
I got value from this way of thinking but I also think specific goals are necessary (e.g. as a startup founder targeting a specific market, product or vision) and that there are some domains that demand you to be the best in a single talent vertical due to a winner take all tendency (e.g. athelete, musician, professional gambler - although in any of these we can still distinguish systems & talent stacks from goals).
For example, my training as a mechanical engineer and 3 years spent working on a gearbox design for the 757 have had a significant positive effect on my programming and the design of the D language.
It gives me a unique advantage.
Do you think these advantages are common among those who have (mech/electrical/chem/etc.) engineering education and training who move into software development?
1. Code that looks right should be right, code that looks wrong should be wrong. (I know this sounds trite, but there are many examples.)
2. When a program self-detects a fault in its logic, it must stop immediately, as it no longer will be in a known state. (It's still common practice to imagine one can recover from an assertion failure. I've spent many, many hours trying to convince other programmers of this.)
3. Better education will not prevent programming bugs. Better process and mechanical checking will. (This notion has been gaining a lot of momentum.)
4. Reliable systems can be built from unreliable components. https://www.digitalmars.com/articles/b39.html
> Do you think these advantages are common among those who have (mech/electrical/chem/etc.) engineering education and training who move into software development?
Heck, they haven't even trickled into the nuclear power industry (Fukushima), the oil business (Deepwater Horizon), or the automobile industry (Toyota surging problem). Those disasters taught lessons learned by the aviation industry decades earlier.
See also:
https://www.slideshare.net/dcacm/patterns-of-human-error
Perhaps I should amend my earlier statement that it's experience in the aviation business that I've taken over to software. My engineering training was mostly about math, not cutting metal and the nut behind the wheel.
I started my career in automotive manufacturing before becoming a business analyst on a team developing in-house business automation tools. The program I studied did cover an engineering design process. We were taught to quantify design requirements (subject to a static load of this much, must be within these dimensions, and so on) and use a combination of calculations, simulations, and prototypes to check we are meeting those design specifications.
I am assuming that you would have done something similar in aerospace. If so, have you carried over any of that into software development? Do you have any guidance or D design documents you can point to? The D specification is the final product, but I’m trying to gain a better understanding of how one gets to that final specification.
Thanks for your time!
Software development, on the other hand, lends itself very well to iterative development. You don't have problems like sinking a new forging die costing half a million bucks, so work really diligently to not need to scrap a die. Keep making mistakes like that, and Boeing will move you to a position where you get to design ash trays.
D is very much an iteratively developed product.
I don't know if this is what you meant by mechanical checking, but I highly rate two things to reduce bugs:
(1) Checking that the output of the entire system is 100% (and I meant 100% literally in every sense of the word) accurate, not just that the smaller unit tests pass or that the output "looks right".
(2) Scrutinizing the logic of the code line by line at least 2 times after you've finished writing it.
As a dev with a data science background, I'm always impressed how many bugs pure devs are able to smuggle in whenever the task involves any kind of data, despite extensive unit testing. I check out their code, run it once, and immediately see the output is wrong and then they have to go back and debug. If we just check our output that wouldn't be the case!
int[10] a;
a[10] = 3; // Error, array index out of bounds
The idea is to allow powerful metal code, while providing constructs that make errors much less likely. For example, if (a < b < c)
is allowed by C, but few C programmers can tell you what it means, and the appearance of it in code is almost always a bug. Instead of educating programmers with "don't do that", D makes it illegal. (If you really want it, you'd have to write it as: `(a < b) < c`. But notice you have to make an effort to write code that way, it is highly unlikely to be accidentally written.)> Scrutinizing the logic of the code line by line at least 2 times after you've finished writing it.
I find it useful to go back through the logic a couple months later. I usually find a lot to improve :-)
I can definitely see the validity in the other school of thought though; i.e. that we should deliberately seek out synergistic talent verticals. I know this is Conor Mcgregor's approach, he's very much systems over goals (in Adam's vein, and explicitly so) but is deliberate about the specific talent stack he's working towards. Ironically it is all done towards a specific goal (to be the best fighter) although the path towards that goal is underspecified.
Here's a very common talent stack here on HN that works pretty well: math + CS + data science + one domain (e.g. finance or biology).
Nice formulation! The domain expertise is key, I think. And often underappreciated by people at the start of their career.
As you get older and more experienced you get exposed to many things that appear to be "easy" but you then find out how much work it is (after you've sunk a bunch of time and effort into it). After enough of this exposure you realize that any skill that isn't realized by a majority of the population takes an immense amount of dedication and opportunity cost. So after a while you tend to stick with what you already know (sunk cost).
Of course your life satisfaction can improve with more skills you have, especially if they are skills that don't become too obsolete. For example being able to do some maintenance on your car (brake job, oil change, tire rotations, radiator flush...) can save money at a mechanic. And being able to take apart a sewer trap under a sink to clean out the hair clog is better than pouring a strong alkaline solution down the drain and hoping it works.
So it is really important to learn enough life skills while you are young to help build up a health and satisfying life later.