3 ms·

Scott Adams has a way of thinking about this that he casts as "Systems vs Goals", where he advocates developing a talent stack of skills that work well together

Scott Adams has a way of thinking about this that he casts as "Systems vs Goals", where he advocates developing a talent stack of skills that work well together towards unspecified, undefined future goals. He says his talent stack is comedian+cartoonist, he's not amazing at either individual skill but he's one of the best at the combination which allowed him to create Dilbert. 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).

paulpauper 6y ago
This is good advice. the hard part is finding the skills you can intersect
- hndudette2 6y ago
  I think Adam's approach is mostly lacking deliberation, it's only after the fact that the synergy is realized but it's hard to intentionally engineer it. 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).
  - stevesimmons 6y ago
    > 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.
- WalterBright 6y ago
  Skills one might think have nothing in common can have surprising intersections. 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.
  - stevegalla 6y ago
    Can you please comment on the advantages and the effect on your programming? Do you think these advantages are common among those who have (mech/electrical/chem/etc.) engineering education and training who move into software development?
    - WalterBright 6y ago
      Some principles: 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 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 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.
      - 6y ago

paulpauper 6y ago

This is good advice. the hard part is finding the skills you can intersect

hndudette2 6y ago
I think Adam's approach is mostly lacking deliberation, it's only after the fact that the synergy is realized but it's hard to intentionally engineer it. 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).
- stevesimmons 6y ago
  > 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.
WalterBright 6y ago
Skills one might think have nothing in common can have surprising intersections. 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.
- stevegalla 6y ago
  Can you please comment on the advantages and the effect on your programming? Do you think these advantages are common among those who have (mech/electrical/chem/etc.) engineering education and training who move into software development?
  - WalterBright 6y ago
    Some principles: 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 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 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.
    - 6y ago