This year, let your resolutions look back

A Story Year-ending

With a new year around the corner, people make resolutions. At year-end, people also look back and reflect. It occurred to me that one can't be prepared for the new until at peace with the past. If you are chained to the past with heavy chain, you can't run forward.

In fiction writing, resolutions aren't about making a todo list for the future. Instead, resolutions wrap up the tensions and struggles the characters experienced throughout the narrative. Whatever disappointments or complications one suffered from, there's comfort and light at the end. That's what a resolution is - to make peace with the past.

With that in mind, I don't want to make plans for the future yet. I want to remember the past year in summary and reflect whether it means a beginning or an ending.

Resolutions

1. About this time last year picked up an online Python programming tutorial - since then I explored other materials (Udacity is awesome) and learned to program. 

• What I learned - I learned to program, which helped me appreciate technology in a different way, which helped me understand our Zeitgeist a bit differently. 
• I also learned that the really valuable skills relating to code may not even be coding. It might be problem-solving, learning to abstract, learning to manage complexity, and learning to create re-usable modules. 
• It taught me patience: you really can't get good overnight. All good things takes time.

2. During the last year and a half, I built a bunch of products with a friend with hopes of launching a business.

• What I learned - I suck at building stuff. But, it was fun and I got a lot better. Failure teaches you things about yourself (related post) as well as about a new craft. There's huge value to simply trying ... you'll suck in the beginning.

3. Read a whole bunch of stuff that I never read in business school or in my past life - Martin Seligman and Gretchen Rubin on Happiness, Thiel's essays (mind-blowing!), Paul Graham's articles, Andreesen's blogs, Noah Kagan's newsletters, Amy Hoy's Unicorn Free, Chris Gullibeau, Ferris's 4-hour book, etc.

• What I learned - there are lots of smart people, and the possibilities for making a living in the world are really endless. In the short-run, options may be limited (because of expenses), but if you can begin to think what your passions are longer-term, rich and rewarding life-career is within your grasp. It helps to be working with smart, successful people. But, usually, you have to become smart and successful yourself to attract those people. Catch-22.

4. Wrote some cool blog posts about my experiences across business and coding in SF.

• What I learned - I learned to communicate with readers. I'd spent a ton of my life sending email back and forth in a corporate cube. None of that stays with you. No one cares. But for the first time, I learned how to build an audience and a following; to communicate.

5. Became an author! Wrote my first e-book about Coding Bootcamps based on my insider-view experience of having worked for one and knowing bunch of people in the space.

• What I learned - You can productize just about anything. It doesn't have to be software.

6. I tried a coding project with someone.

• What I learned - You don't have to be an expert or have talent in the field (though it helps). The only talent you need is talent for action and energy. If you start, it is possible to bring others to contribute to the effort. It is the first requirement of team building.

7. Built meetup communities - Ruby Rookies and SF Product Management FastTrack (the latter with a friend, Ritu).

• What I learned - learned what it is like to start something from nothing, how to create resources, identifying and tapping into unmet need of anonymous others, and how that leads to a community of like-minded folks.

8. Family. My younger brother got married to a wonderful wife, and my parents' cat is adorable. 

• What I learned - We go through ups and downs. Friends sort of come and go ... and it's hard to know who is a friend until you fail. Those that are real stay with you. Family on the other hand is family. They love you and support you no matter what. They are more important than all the rest, so remember that.

What I learned - Cats are cute!

Sharing

This seems good enough place to stop. Everyone is busy, and I'm too old to keep making lists. Would love to hear from you - what your resolutions are; what you did and what you learned.

Happy New Year!

New Project

One of the things I decided to do for 2014 is to put up a new website with my own URL (since I had always used someone else's url - like this blogger.com blog). I'm going to do something constructive with it by getting non-technical MBAs more familiar with some of the tech stuff I'm playing with - sort of web101 for non-technical MBAs. It will go up on http://techproductmanager.com/. Would love your readership and support!

(If you enjoy these thoughts and would like to support my writing efforts promoting personal learning and understanding of technology, please consider supporting me through gittip.)

What hackers (and you) can learn from the Pope

Are you thirsty for knowledge?

How will you recall 2013? Did you want to do something great? How far did you get?

One of the hallmarks of a great hacker (not just in programming, but great leaders, great teachers, great anything) is thirst for knowledge. That trait is a cornerstone of greatness.

What is a clear evidence of genuine thirst for knowledge? Learning. If you are learning with intent and consistency, it might be driven by an underlying thirst.

Why you learn

And why are you learning? Why are you thirsty to do something great? It is because we are human beings with capacity to do more than simply copy and paste spreadsheets or make sales calls all day. Here, I want to reference a well-known hacker manifesto called "How To Become A Hacker" by Eric Raymond. Raymond asserts, "hacker attitude" includes the following beliefs:

• The world is full of fascinating problems waiting to be solved.
• Boredom and drudgery are evil.
• Freedom is good.

If you think about it, education isn't simply about learning facts to obtain a degree, in order to be employed. Rather, learning is a means to knowledge and wisdom, such that you can become free. So that you can avoid drudgery, but most importantly, to elevate beyond personal freedom to solving interesting problems (interesting to you individually, but also with the potential to help many around you). That is why you learn.

How you learn

Steven Raymond's exhortation is more specifically about programming. He notes that:

"Learning to program is like learning to write good natural language. The best way to do it is to read some stuff written by masters of the form, write some things yourself, read a lot more, write a little more, read a lot more, write some more ... and repeat until your writing begins to develop the kind of strength and economy you see in your models."

So how do you learn? You learn by waxing on and waxing off around the master.

Learning Mr. Miyagi style

Apprenticeship is quite powerful. I don't know the full history behind it (and may be interesting for someone to write about it), but it is plainly a model widely adopted across human disciplines - from medicine, academia, computer programming, politics, the list goes on.

How else can you learn apart from apprenticing and tireless practice? You have to be curious. You have to tinker. Otherwise, you'll never surpass the master.

• Step 1 - stand on the shoulder(s) of giant(s)
• Step 2 - copy/master everything they teach you
• Step 3 - try a variance, try and fail, and learn

Along these lines, the person who most refreshed my attitude about learning to program wasn't a programmer, but the Pope. And I'm not even a Catholic.  And I think there's a lot that other hackers (in any discipline) can learn from his example.

Personal Dilemma: Enter the Pope

The "Cold Call" Pope

So, one of my personal frustrations and dilemma has been picking up a new field of knowledge.

Frustration comes from feeling like teachers in past disciplines have failed me or failed to save me time by pointing me in the wrong direction - teaching me such useless things like spelling or accounting.

Dilemma. Now that I have an aim, I still have to learn. It's time and energy-consuming to 'wax on, wax off.' I'm lazy. Is there a short-cut? How can I do it without the hard work, without the 10,000 hours?

And it would be far better if I were still in college. But those years have been squandered. I'm now in my 30's and I feel I have less luxury with time. The thought is frustrating.

Enter the Pope. He taught me the following.

One: You're never too old to be New

The man is almost an octogenarian. That doesn't stop him from breaking thousand year traditions (like washing women's feet on Holy Thursday or inviting former Pope as an equal to the alter).

Pope Francis also warmed millions of hearts when he embraced and kissed a severely disfigured man suffering from pain.

Confirming the humanity of all human beings

There were many other incidents that demonstrated the uniquely human iconoclasm of this man from Argentina. (We are all human, so why aren't we all as human as he is?)

Truly, you're never too old to do something new, to do something amazing.

Two: To be yourself is to be Great

At this point, let me note that I'm not Catholic. I just admire this man, because he teaches me much. Apparently, Pope Francis is so humble, that when he became the pope, he called his newspaper delivery man to cancel subscription.

Now, that's ridiculous. And amazing. Amazingly humble. Amazingly himself. This is not for show (apparently), not a pretense. The newspaperman, he knows the Pope well. When he realized what was happening, he apparently broke down in tears. The story relates that the then Cardinal used to collect and even "return the 30 rubber bands around the newspaper."

Cardinal Bergoglio is just being himself. There are thousand such stories among the parishioners who fondly remember this man's kindness.

In the end, greatness isn't about being good at something. Rather, it's about being good. About letting the goodness in us shine forth.

Three: To fail is to Learn

But the most revealing thing I learned is that the path to this kind of greatness - of goodness in life - is never smooth.

Sure we may read of the touching stories of the Pope before he became Pope and think he was always like that. Sure we may see stories of startup success and 20-somethings who have become CEO's of corporations.

"Surely, they have known nothing but success," we think.

Not so. James Carroll recently wrote a piece about the Pope in the New Yorker. The former Cardinal had had some difficult periods of leadership during violent "Dirty Wars" years of Argentina's military dictatorship. Some priests might have lost their lives because of the Cardinal's misjudgments.

What sort of pain and frustration might such difficulties leave on one's memory? The experience, apparently was "searing," according to Carroll's article.

Failure is absolutely necessary to growth. Failure. Mistakes. The trick is not to dwell on it. The trick is to learn from it.

And what is learning? Learning is a sign of desire for thirst for knowledge. And why do we thirst for knowledge and wisdom? So we can be free and solve the world's problems.

And you're never too old to do that. You just have to be yourself and learn from your past. Like the Pope. Then, in a manner of speaking, you'll be great. You'll be a hacker.

What's Next?

There aren't many days left. Before the year ends, I'd like to write two more posts.

• One summarizing how I spent my time - what I learned, achieved. 
• Another, I'd like to remember all the wonderful blessings of the year - people I met, lucky breaks, those who helped me, celebrations.

Ubuntu espeak Merry Christmas!

Linux is so cool, especially Ubuntu, which makes Unix and programming accessible to anyone - not just the technically-trained, but anyone with some initiative, desire to learn, and willingness to overcome some fears of technology & fears of getting stuck.

I remember I actually tried programming on the web, tinkering with Sun's Java toolkits, configuring Apache servers. Perhaps I should have stuck with it. It was hard, but it didn't occur to me that others may also have struggled, and at least I would have been among the few. Still, I remember all the random scripts and verbosity of Java ... it was not very approachable. Today it's much different.

Anyway, I digress. I'm not writing about learning to program. I'm just exclaiming how cool Ubuntu is. If you have a linux terminal open, then try this ... type:

$ espeak "Merry Christmas"

espeak is an old-school speech synthesizer, and if you want to hack, you can check out the source for espeak.

Watch what you're saying!

Really neat, right? Merry Christmas, everyone from me and Ubuntu!

If you liked this, you might also like to know how to partition your Windows machine to boot unix, and for further reading, get comfortable with your command line.

The Linux Command Line: A Complete Introduction

Merry Christmas!

JavaScript typeof vs instanceof

Reading is good

And I assume almost no one reading this post would disagree that reading is good. And once you agree with that, then it follows that good books are valuable. Good books alter our thinking. Good books can be life-changing.

I have been reading Professional JavaScript for Web Developers (3rd ed). It find many little details of the JavaScript language that I almost never comes across when simply learning to code or following a tutorial or a newsletter.

Theory and Practice in the world

I suppose this is the dichotomy between theory and practice that many professionals experience, whatever their profession might be. For example, a good trader may be familiar with modern portfolio theory, and be able to outline the efficient frontier. Then, on the trading floor, find that day-to-day, she never really applies that theory or knowledge. However, there maybe a longer-term project, or a strategic shift in investment for which that knowledge may make the difference between success and failure. Likewise, when scaffolding a JavaScript app using a tool like Yeoman or Meteor, many programmers may never think about memory management or garbage collection.  Do you know how it's done in JavaScript? And how will you apply them in your application, even if you were familiar with those concepts?

We live in a world of changing contexts, between clean theoretical Platonic concepts, and a messy practical application where little details could matter, or may be totally immaterial.

It looks quirky for now - typeof and instanceof

For now, the details look very quirky to me. I'm sure it will change over time as I see other contexts, and find cases of the theory applied in practice. With that statement of faith in mind, it's time to play on the console (Using a Chrome browser, F12 key on a PC brings up the developer tool, which includes a console).

According  to the book, typeof is used to determine if a variable is a primitive type, whereas instanceof operator is used to determine the type of an Object. Here are some examples - play with other variations in your console.

typeof "anything"  // "string"
typeof 3           // "number"
typeof null        // "object"
typeof [1,2,"3"]   // "object"
typeof {}          // "object"

So, lots of things are object. Let's move on. Keep in mind that primitives are not objects.

var array = [1,2,3]
array instanceof Array    // true
array instanceof Object   // true
Array instanceof Object   // true
Array instanceof Array    // false

So, an array is an object, not an instance of another Array.

Check out other technical things I am learning on http://pleaserefactor.com/.

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.

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.

Methodology

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.

• Josh Wilborn - joshua.j.wilborn@gmail.com
• David Kim - daviddarden11@gmail.com

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.