Learning to code is worth it

Someone recently shared this great talk by Chris Allen from lambda conf 2017.  The title of the talk is “Why Johnny Can’t Code Good,” but the content is more about how to grow as a programmer.  His points are true whether you’re just starting out, or have been coding for years.

My notes from Chris’ talk are below, in the order they appear in the presentation.  My thoughts are in parentheses.

He’s not talking about people who can’t code, but rather those who haven’t learned to code.  They usually work in the industry, but only know just enough to get things done.  They aren’t super-independent, and may have trouble taking on new things.  All of us have been here before (often multiple times in different disciplines; whenever we start something new).

The problem is when you get stuck working on pre-defined tasks in a well-defined space.  The computer science industry’s priorities are now wrapped around accommodating people who are comfortable staying there.

For example, nodejs, Go, and other new languages optimize for “zero-to-blog”, not for something maintainable, or that allows people to build useful abstractions.  There’s more focus on what is marketable in a short blog post.

(An interesting point on hiring:) you can’t “hire only the best”, unless you’re able to attract talent. You can’t select for it, because other employers trying to “hire only the best” too.

Using new tools is not learning new skills.  Learning how to learn, without someone feeding you pre-digested material, is how you grow.

Don’t say something is easy. It’s always going to be harder for some, it depends on their context. Either something is worth learning, or it’s not. There may be some return-on-investment cutoff point, but it’s either worth trying or it’s not.

We’re an amnesiac culture. We don’t remember 5 years ago (and we don’t like learning history).

Don’t train how you play. Train harder, be more focused and structured.  (This is a sports analogy. The idea is that you work harder in training than you will work during a game.  That makes the game seem easy.  I have a habit of doing harder things when I’m doing something of lesser consequence.  People often asked me how I learned something, and the answer is often “I broke something and learned until I understood what I broke and what was needed to fix it.”  This is sub-optimal at work, when a faster solution that isn’t fully understood is preferable to a slower solution that is.)

If you love using my open-source work (e.g. quantmod, TTR, xts, IBrokers, microbenchmark, blotter, quantstrat, etc.), you can give back by sponsoring me on GitHub. I truly appreciate anything you’re willing and able to give!