Thiel's 2x2's
I've really been really enjoying CS183 notes by Blake Masters. One of the biggest take-aways has been Peter's insightful 2x2 look at the world. The technique itself is nothing new, and probably litters countless number of blogs and powerpoints. For example, last year, I talked about 4 kinds of people in a hacker matrix.
Difference is that Peter's thoughts are quality, and his matrices are actually useful. One of the key ways it is useful to me right now is to serve as an underlying motivation for learning, and for designing a learning roadmap.
Optimistic & Deterministic
One of the several ways Peter views investment opportunities (and hence a mental view of the world) is along the optimistic-pessimistic axis and along the determinate and indeterminate axis. Optimistic-pessimistic is self-explanatory. Determinate means that there's a specific path that will unfold. Indeterminate is what lot of us has been doing ... future is uncertain but there seems to be lot of choices, so you do what you can and trust things will turn out okay.
That's indeterminate-optimism, by the way. Since the indeterminate-pessimism would be just saying everything will go to hell anyway in an unpredictable way, so you might as well just stop stressing.
Applied to Careers and to New Programmers
I find that this is reasonable map for career strategy. It also provides a good mental-model for someone new to software engineering. That matters, because with things as non-linear as careers today or when you have a small field of vision due to inexperience, it's helpful to have map. (Think of sailing across the Atlantic in a pre-Columbian world vs. post-Columbian world.)Soft
.png)
What about as applied to software engineering.
As a learning map - analyzing the optimistic quadrants
The main focus for me is to motivate and determine a sensible path for learning and growth. I can rule out pessimistic quandrants outright - it's just not a good way to live.
The optimistic quadrants are telling. To me, it's clear that determinate-optimistic is appealing and should be the goal. Yet, in practice, I live an indeterminate-optimistic life.
Why is that? What might it be tempting in concept and necessary in practice to understand little bit of lot of things even within the narrow confines of software engineering? To stay relevant, should you know hadoop and noSQL and bunch of other things in addition to growing your knowledge in TDD/BDD, frameworks, optimization, etc, etc?
And determinate-optimistic isn't trivial either. Clearly, if you had a very specific problem to solve - let's say you want to make data analysis easier in the big data cloud - you still end up with bewildering requirements as to techniques, tools, and technology. More to point, how did you come up with that specific goal in the first place?
Making the choice to step into the light - focus
Yet, that last quadrant seems sensible, because only then, can one be specific about what to learn. If you want to confine your (near-term) interest to databases, let's say, then you can begin to concretely list what steps you can take to get there ... it is the power of focus.
More
Somewhat unrelated, I saw this post on Startup Digest on the topic of focus by Brad Feld. Something to chew on, for sure.
There's no time like today to start getting more technical. If you are a non-technical MBA like myself and want to become more conversant in software, I am posting relevant posts on techproductmanager.com.
If you enjoyed this piece, and want to support my writing efforts in promoting technology in business and personal development, please checkout my gittip page.
I've really been really enjoying CS183 notes by Blake Masters. One of the biggest take-aways has been Peter's insightful 2x2 look at the world. The technique itself is nothing new, and probably litters countless number of blogs and powerpoints. For example, last year, I talked about 4 kinds of people in a hacker matrix.
Difference is that Peter's thoughts are quality, and his matrices are actually useful. One of the key ways it is useful to me right now is to serve as an underlying motivation for learning, and for designing a learning roadmap.
Optimistic & Deterministic
One of the several ways Peter views investment opportunities (and hence a mental view of the world) is along the optimistic-pessimistic axis and along the determinate and indeterminate axis. Optimistic-pessimistic is self-explanatory. Determinate means that there's a specific path that will unfold. Indeterminate is what lot of us has been doing ... future is uncertain but there seems to be lot of choices, so you do what you can and trust things will turn out okay.
That's indeterminate-optimism, by the way. Since the indeterminate-pessimism would be just saying everything will go to hell anyway in an unpredictable way, so you might as well just stop stressing.
 |
| Copy of the chart from Blake Masters Thiel's CS 183 class 14 |
Applied to Careers and to New Programmers
I find that this is reasonable map for career strategy. It also provides a good mental-model for someone new to software engineering. That matters, because with things as non-linear as careers today or when you have a small field of vision due to inexperience, it's helpful to have map. (Think of sailing across the Atlantic in a pre-Columbian world vs. post-Columbian world.)Soft
.png)
What about as applied to software engineering.
As a learning map - analyzing the optimistic quadrants
The main focus for me is to motivate and determine a sensible path for learning and growth. I can rule out pessimistic quandrants outright - it's just not a good way to live.
The optimistic quadrants are telling. To me, it's clear that determinate-optimistic is appealing and should be the goal. Yet, in practice, I live an indeterminate-optimistic life.
Why is that? What might it be tempting in concept and necessary in practice to understand little bit of lot of things even within the narrow confines of software engineering? To stay relevant, should you know hadoop and noSQL and bunch of other things in addition to growing your knowledge in TDD/BDD, frameworks, optimization, etc, etc?
And determinate-optimistic isn't trivial either. Clearly, if you had a very specific problem to solve - let's say you want to make data analysis easier in the big data cloud - you still end up with bewildering requirements as to techniques, tools, and technology. More to point, how did you come up with that specific goal in the first place?
Making the choice to step into the light - focus
Yet, that last quadrant seems sensible, because only then, can one be specific about what to learn. If you want to confine your (near-term) interest to databases, let's say, then you can begin to concretely list what steps you can take to get there ... it is the power of focus.
More
Somewhat unrelated, I saw this post on Startup Digest on the topic of focus by Brad Feld. Something to chew on, for sure.
There's no time like today to start getting more technical. If you are a non-technical MBA like myself and want to become more conversant in software, I am posting relevant posts on techproductmanager.com.
If you enjoyed this piece, and want to support my writing efforts in promoting technology in business and personal development, please checkout my gittip page.
