Masters-Thiel's 2x2 model applied to learning to program

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.

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

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.

day5 - beef jerky, culture, and why performance reviews are toxic

Reflections on beef jerky day - feeling like my colleague was a jerk

I'll just share the video I recorded at the end of the day. I basically felt like there was some gap in the engagement and accountability in the team.  You can tell I'm a bit pissed off in the video.



We are delusional as people

So almost immediately after recording, and feeling discouraged about lagging engagement, and thinking back on the day, I had a realization.  It's interesting the two of us incorrectly perceived our contribution and role in the team. Who was who's apprentice?

And we're just freaking two people! We are delusional.

Good intention to help people not be delusional
I can now better appreciate why organizations create measurements and performance reviews - so as to check members from becoming 'delusional.' For example, if my manager and I agree that I was a 4 out of 5, and have it on paper, then I can't come back and say 'but I delivered more revenues than he/she who also has a 4 rating!'

Performance reviews are used to avoid perception of unfairness.

But it's wrong
While I can now appreciate first-hand the organizational leadership's position in defaulting to performance reviews, I also believe that it is the wrong step to take.

What you really want are individuals to become more self-reflective, self-aware, and self-sufficient. You can't enlighten people by banging them on the head with 360 reviews. That only makes them less engaged and bitter and resentful. It is a sure sign of distrust at a deep level among the team members. Instead, focus on dialogue and communicate your grievances.

Instead, focus on dialogue and communicate your thoughts. Support each other and help the counter-party see the reality. Difficulty conversations aren't supposed to be done through mind-numbing written performance reviews using sanitized words. (Didn't you always love that guy who had no filter in his mouth and said whatever the hell came to his mind?)

Talk to each other. Know that hard is good.

Yet there's a tension
I can also appreciate the tension present here. It is the tension between having great people, and being able to scale growth. If you had to hand-pick and cultivate great people one by one, you might spend too much time recruiting for the team.

How are you resolving this tension in your organization?

Learning by doing

To see what this overall project is about, see the original 12appyDays entry.

Today was project 5 - a skeleton eCommerce site for beef jerkys.  On the previous day, we built a simple and simplistic site using google map api to show the path back to the car. And on the prior day (project 3 pickr), I wrote about the experience of how knowing what's hard is ... hard.

And I'm learning so much, because I am building. Lot more so than I could by thinking and reading. 

day3: ActiveRecord, Pirates, and knowing what's hard is hard.

Appy Days

This is a day 3 reflection for 12 days of coding projects. We also have link to source code and other info on github pages at http://12days.github.io/.

Prior blog about this project and its rationale are:

• Attitude over aptitude - calling out BS, and
• Can you really learn to code in a month?

Day 3 Reflection

step 1 - User Stories

We decided to build a Flickr clone with a pirate theme, hence Pickr (source code). What I learned was not that mind-blowing. Nonetheless it is worth capturing. As usual, we started with user stories.  Something like the following:

• As a user, I want to be able to upload my photos and delete them (paperclip gem)
• As a user, I want to see a livestream of recent uploads
• As a user, I want to see a stream of my friends uploads

Once we understood the expected behavior, and the general idea that it's a photo application, we were ready to build.

step 2 - Survey Existing Tools

First, it's great to leverage existing technology. For example, we used a gem called paperclip for photo upload. It saved us a ton of time to be able to use this technology.

Since we wanted to be able to see friends uploads, we needed to be able to make friends, etc., and that means we needed to authenticate a user. It also meant that for the first time in three days, we would be using a database. Thankfully, there is also a gem called devise, which makes authentication quite easy - it gives you almost on the fly the ability to get users to sign up for an account with password.

step 3 - Mapping Data

So the next step is invariable mapping the object model relationships. In Rails programming (and more generally in the model-view-controller (MVC) paradigm of programming), "model" is the business logic of data object. So for example, in this case, we would have something like the 'user' object, which would have 'photo uploads' and also have 'friends.'

Rails abstracts these types of relationships via Active Record associations. Using this convention, one uses syntax that writes out model relationships in more or less plain English, like user has_many uploads. Or photos belong_to user.

step 4 - have fun
And pirates ... well, we just want to have fun while working. Arrrrggghh!

What we learned

So, using gems like paperclip and devise, we set up the initial authentication and photo upload in no time. Before noon, we had a running app.

Then, even after sketching out database table relationships, we found that it was not very straight-forward to build the many-to-many relationships between users and friends, especially since we wanted to be able to allow users to interact on a permission-based flow of first receiving a request, and then deciding to accept or reject a relationship. It was pretty late in the night when we had all the models hashed out, and it fell to the more experienced among us (Josh) to do most of that coding and validation.

As someone less experienced struggling through the associations and related validations, what I learned was the following:

• As a new web developer, we probably don't spend enough time thinking about database design and data associations. Frameworks like Rails has encouraged this by abstracting database queries. You no longer need to write SQL to look-up data. But, it is still necessary to build the right relationships, meaning one needs to get into the mindset of thinking about how data is stored, and what the relationships between data tables might look like. It's easy for those experienced, and yet very abstract and difficult to handle for those inexperienced.
• Development time is hard to estimate. This is a truism. But, part of the 'hack' of placing a one-day constraint on building a product is to limit the error in estimation. Even so, it seems, we are notoriously bad at estimating our progress and estimated time to finish. We are often mislead by early success (as we were with a skeleton of a working app by noon). The harder pieces happened to come later, and took quite a long time to build.
• Unless you've built it before, it's hard to know what's easy and what's hard. This is a catch-22. I would think that this insight is useful from hiring point of view. Why does one hire a senior developer vs. a junior developer and what does senior mean anyway? It means that the developer has built the very piece of technology you want, and knows exactly how hard it is. It is not to say that senior developer is better ... but just an important observation that knowing what's easy and what's hard is ... hard.

I think these were the main points, and the rest are probably not worth mentioning. If you enjoyed reading this post, you might also enjoy reading about my observations from attending a local meetup event called RailsBridge, and how I started to go down this road of web development after working in business as a MBA grad.

Finally, if you're interested in engaging Josh or me to help you with your web development projects, please feel free to reach out.

Pickr was hoisted up in a day and could use some love. Please fork it and contribute. Once again, you can get all of the posts, lists of projects, and source code links at the project page.

Can you really learn to code in a month?

[Topic - this post is about learning and coding, and relates to the post about 'attitude over aptitude' observation.]

Can you really learn to code in a month?

It has taken me a hell of a lot longer than one month to learn to code. Am I just dumber than other people? Or is this a marketing gimmick?

Who am I to talk about this?

As I have been learning to code for a several months now, I've become quite familiar with various tutorials and resources about coding. For example, I worked for a few months at a local coding bootcamp, and ended up writing a short e-book to help people think about choosing a full-time program.

And I am fortunate to have experienced mentors who give me good advice about my progress - as I highlighted in attitude over aptitude.

Are we brainwashed as a society?

More recently though, I realized that many of us (including myself) have been conditioned to rely heavily on others for our education. We have limited time; it is wise to use existing systems for our education. (In his book The Black Swan, Nassim Taleb points to neuroscience research and points at that this is part of how our brains work (primarily our left-hemisphere). We reduce complexity by overlaying patterns and order. We need structure to keep things simple and be able to absorb information.)

So, it's not surprising that we often rely on others to make things easy for us.  For example:

• Textbooks - Why do we use something called textbooks in schools?
• Teachers - Aren't we our best teachers ... how can someone really know how we learn and what we find interesting?
• Schools - Why are we paying an ungodly sum of money in tuition to attend schools? Are we trying to stoke our ego by paying for a piece of paper? Or are we genuine about what we want to learn inside of walls of some remote institution?
• Tutorials and courses - Again, rather than determining how best to pick-up a topic based on our own learning patterns and need for structure, too many people simply "pay" for content or a course, in the hopes that it might lead to accelerated learning.

I realize these are simplistic questions. I simply make the observation that many exhibit a behavior of dependency and fail to think independently and originally. And the reason often is: we are lazy!

This is 'Murica. Get rich quick!

The polar opposite of paying someone to help you learn is the Do-It-Yourself learning. I think the term DIY was popularized by home owners making fixes and home improvements on their own. One can apply it to education as well. Today indeed is a good time in history to do things yourself.

• Internet & accessibility - Internet has made niche knowledge as accessible as common knowledge. Just google it.
• Commoditization of knowledge - With that accessibility, things like tutorials and online courses have proliferated. These days, you could take an entire career's worth of education on the web using Udacity.com, Coursera.org, and similar resources.
• Curation - Good news! Someone else already has done the hard work for you! Just checkout something like superherojs.com to get started on JavaScript.

Even so, there is this thorny issue of time. We don't have enough of it. And capitalizing on the accessibility of knowledge, DIY attitude, and need for effective use of time, I have seen various offerings that promise learning quickly.  Just check out the claims of "I learned to code in a month" genre:

• Taught myself in 8 weeks - http://lifehacker.com/how-i-taught-myself-to-code-in-eight-weeks-511615189
• Learn Rails in one month - https://onemonthrails.com/

But, is it true? Does it work?

As I shared above, I feel dumb. I certainly couldn't learn Rails in one month. (Yeah, I could generate a rails app on day 1.  But, it was just monkey-see-monkey-do. It took me a while before I felt comfortable writing code and understand what was happening. And I'm still learning.)

I don't mean to gather the case here against learn quick programs. However, I am sharing my skepticism about learn quick in the same way you should be skeptical about "get rich quick from home" claims. I saw this blog post of someone who tried one month rails and still couldn't program.

The truth is that good tools, good books, and good communities help us learn. No doubt.  For example, I respect and consider Daniel Kehoe's RailsApps to be a valuable resource that builders can use to kick-off rails projects. (In particular, check out http://railsapps.github.io/rails-composer/)

That said, my life experiences convince me, that there are no short-cuts. There are no free lunches in life (unless you work at Google). In the end, you have to invest the time and effort to learn.

Learn for yourself.

On education and schooling

There is a Mark Twain aphorism: I have never let schooling interfere with my education. And this points a finger at the culture of dependency in learning that I didn't know until I got older and wiser.

http://www.npr.org/2010/12/01/131703237/on-publishing-mark-twain-s-autobiography

We have been conditioned to rely on others to make things easy. We want a short-cut. We want to be a programmer in one month. Well, good luck! At some deep level, schools, degrees, and courses are a hoax that prey on our insecurities or fear to tread into the unknown. You need good mentors in life, but certainly no diplomas.

Think of it this way. Did the first climbers of Everest get certified or take courses to get to the top? Hell no! It was just blood and sweat and years of training to prepare. Today, of course, you can pay a guide to essentially take you up to the summit - it has become a tourism destination.

I think this guy gets it - http://learnpythonthehardway.org/.  See? The "hard" way. The right way.

Let's get edumacated!

Good! Let's get started then, and start building! Or try Code School and start learning by doing.

Like what you read? Check out my other posts on Medium.