Sep 29, 2013

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,, and similar resources.
  • Curation - Good news! Someone else already has done the hard work for you! Just checkout something like 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:
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

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.
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 -  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.

12 days 12 apps - an experiment in building and teaming

What is 12 days of coding?

It is 12 projects in 12 days. Each project would be started, finished, and shipped in a given October day.

It is an experiment in coding and learning. It is an experiment in teaming and creating a culture of doing. I will be blogging about our experience in my blog, starting with reflections about attitude over aptitude and critique of learn it quick mentality.

Appy days are Happy days

Why 12 days of coding?

Josh and I both had time to kill. But, not too much. We wanted to do something fun, build up our coding skills, and our portfolios. (The project will not always take place over consecutive days - but basically we are saying a half a month is low-risk enough to invest in an experiment ... whatever may come of it.)

And we wanted to learn: learn to be better coders, learn to be better builders, learn more about our interests. And that was it. We don't want to get ahead of ourselves.

We thought a good way to do this would be to create a set of constraints around our efforts. Constraints are key to discipline and focus.

  • One of the first choices we made was to keep it short and simple (KISS principle).
  • We are devoting around 2-weeks to this experiment.
  • We are keeping this to 2-person engineering team.
  • We are doing projects we can reasonably finish in a day.


What about the process? No ground-breaking principles here:
  1. Build on strength - for speed, use familiar technology (for us, mostly Ruby on Rails)
  2. Prepare - for new technologies (e.g. a Node app), do some advance reading/tinkering
  3. DRY - Do not repeat yourself - look for gems wherever possible
  4. Best practices - we will use TDD; red-green-refactor; frequent commits
  5. Pragmatism - product should work; function over form (i.e. it doesn’t need to be pretty)
  6. Modularity - we will try to build templates we can reuse on subsequent days
A lot of these ideas are well-known to software engineers from works like Rework and The Pragmatic Programmer.

How you can get involved

You should join with your own mini-rapid-project(s). Do it solo. Do it as a pair. What would you like to get out of a process like this? How would you structure your efforts? Write about it and send us a link to your post or project.
Project & resources

You can find full-project page/link here - 12 appy days!

Please let me know your thoughts about attitude over aptitude and the get-rich-quick mentality that makes one-month-rails type of marketing so tempting.

Attitude over aptitude: why "I know enough code to be dangerous" is BS

"I know enough to be dangerous"

[Topic - this post relates to my thoughts about learning to code, about careers, and about attitudes people have about picking up new skills - see related post 'can you really learn to code in a month?']

"I know enough [choose your subject matter] to be dangerous" is something I never heard while living in North Carolina. It is something I often hear in and around the San Francisco.

As someone who had built a career in roles like business development and finance, I have been tempted to say similar things. However, whenever I heard someone else say it, it always seemed glib and shallow.  Call me silly, but I don't want to be shallow. Somehow, I felt I need to genuinely learn to code before I could say things like "I know enough to be..."

I'm sure you know it as well as I do. People who say things like 'I know enough to be dangerous' are either full of BS or insecurity.

Please spare us the platitudes
Attitude over aptitude

I get hung up on the details. It is my left-brain pre-occupation for patterns. I have been brainwashed for decades to learn from textbooks, or pay tuition to go to school, or to think that getting an A in a class means that you learned something.

(I reflect a bit more about this observation in 'can you learn to code in a month')

I recently shared my frustration with a mentor, Quincy: how is it that some people can seem to learn to code and start building in 3 months, while I still struggle with building more than half year out?

Quincy's advice.
Attitude over aptitude. If you take a leap and tie all your self worth in your ability to code, you will do what you need to do to get good at coding.

Of course, you are probably good at a number of other things. The key is dismissing all these other things as unimportant. During my transition, I kept justifying to myself, "I'm good at Chinese", "I can fall back on a career in operations", or "I have a business background - I'm pretty good at coding for some guy with a business background". These are traps! You have to do without an ego safety net.
Wow! It's true. The glib things we say are crutches. They are the ego's way of protecting itself for being too lazy to learn, or too afraid that we will fall and fail and look like fools trying.

Look for good people, not good tutorials

This isn't really an advice column. Instead, I hope that the experience I share here will help you learn something more about yourself and enable you to have more clarity or confidence in your walk.

So, don't take this so much as an advice as a personal observation. I found that in really learning - not just skimming over a topic, but really learning - some things are more important than others. For example, good tutorials count, maybe paying someone to give you will help. But, as I observed above, the right and sincere attitude trumps these. What else counts? People. Good books. Good ideas.

So, by all means, keep using those free tutorials, but next time also consider these:
  • Look for good people - Quincy shared an invaluable advice, because he cares. Another friend, Robert (mockdeep), has graciously been sharing his valuable time as a code reviewer and mentor on his open source project. Not all experienced professionals take interest in junior developers, or take time to invest in them. Good people do.
  • Good books / good ideas - I recently read Rework by DHH and Jason Fried (folks who built Ruby on Rails). I probably learned more about career (not just about coding) from this book than I did in two years at Darden MBA school. And at $10 a copy, it was orders of magnitude cheaper than the $100K I sunk into MBA education.
  • Right attitude - as we talked about above.
What good books and ideas are you absorbing today?

Start building

We are all apprentices in life. If you want to start learning today by building, join me and Josh as we try a 12-day-long experiment in coding and producing products.

Feel free to check out our 12days github page, contribute torepo, help us by sharing suggestions, etc.