New Year, New Company

I’d like to officially welcome into the world the newly legal entity known as Full Stack Research. I’m launching this little company with no more fanfare than this blog post, but I look forward to pushing out more news in the coming months and years as it gains momentum. While my consulting business has been doing just fine, I am very aware of the flaw in that business model, which is that my time is a finite resource that does not scale.

I’m not expecting Full Stack Research to be too much of a departure from what I’ve been doing as an independent consultant, but I feel like a new name is warranted given my desire to focus more on creating scalable research products, and the fact that I am doing so in partnership with some of the smartest people I’ve had the pleasure to work with.

If the best way to achieve success is to start with modest expectations, I consider this a triumph from day one!

Coding Bootcamp: The Best Terrible Decision

When yet another friend asked me “is coding bootcamp worth it,” wondering whether they should learn to code too, I found myself giving a very long and convoluted answer that I realized would probably be better off written down. I know that before I signed up for bootcamp, I had trouble finding a straight answer myself. So, my answer is: Yes, but…

1. Upon graduating, be prepared to be a specialist of limited use or a master of little

Building a decent software app is kind of like building a house. The electrician knows very little about installing plumbing or sewage. The roofer probably can’t lay the foundation. A software app combines lots of independent skills. As a developer, you have to make a choice whether to be a decent plumber right away (focus on one thing) or be a general contractor, and know a little bit about everything, but not really be expert at anything for a very long time.

2. It takes a huge amount of time

This may seem laughably naive to long-time software developers, but I don’t think regular people realize the sheer volume of information a person needs to absorb in order to be even a mediocre developer. To be a decent coder, you need to learn three to six code languages and be able to read and write them with some fluency. Code languages are just as hard to learn as, say, a European language. If you wanted to learn to speak French, German, Spanish, Italian, Greek, and Portuguese all at once, would you try to learn them all in four very intense months? No? Because that is essentially what I tried to do.

Too many screens!
Too many screens!

My bootcamp was four months, or sixteen weeks long, with five hour classes every weeknight (fridays too). To keep up with the pace of the class, I had to read coding books, do online coding exercises, and write code for my class projects outside of class. When you add in all that study/coding time outside of class, it added up to about fifty hour weeks spent coding. In other words, it’s about as difficult as a mentally demanding full-time job.

I was freelancing and working part-time, and I was completely brain-fried and had no social life during those four months. I felt incredibly sorry for my fellow students who had full-time jobs on top of school. I watched them put on weight and grow increasingly haggard by month four. We all agreed we were seeing ones and zeros in our dreams.

3. It’s expensive

I’ve heard people say that coding bootcamp is a waste of money since you can teach yourself everything online for free. The thing is, even in coding bootcamp you’re still teaching yourself to code, and you’re still using those free resources. The difference is that in bootcamp you have an experienced developer guiding you and a structure that limits the complexity and chaos of coding. Realistically, a coding bootcamp is just going to take months 6-18 of your coding education and compress them into months 6-10. What is the price for 8 months of your life? That’s really up to you. I spent $3,400 on tuition, and that seemed like a bargain to me. If you have more time than money, by all means, figure it out on your own.

4. The hard way is probably the only way

Zed Shaw’s “Learn Python the Hard Way” is generally considered the best course for those trying to teach themselves Python. He intentionally makes the course difficult. When a piece of code doesn’t work, his answer is “Google it”. Realistically, learning to code is as much about rote memory as it is about training yourself to be patient and resilient. You have to first spend lots of time practicing writing code so that you can memorize and internalize the patterns. However, that’s the easy part. The hard part is figuring out what to do when you think you’ve done everything right and your code still won’t run correctly. It’s easy to copy and paste someone else’s code. It’s hard to know why it isn’t working in the context of your project.

I heartily recommend going all-in. The more time you can invest, the better. I spent 50 hours per week, but I recommend spending 80 hours per week the first few weeks you’re learning. Mix it up, and read books on coding, then go to online practice sites like or, then write some actual code. Every program does something different, so when you’re done with one, write another one. Tear apart an old program you wrote and write it better. Like playing the violin, the more you practice, the more you’ll internalize the skill. If you want to learn quickly, the only way to do so is to devote yourself.

5. Pick your language carefully

Back in high school I decided to learn Italian. In college, I took Japanese. Not to knock these languages, but I use them so rarely I’ve forgotten most of what I learned. In retrospect, I really should have learned a practical language I can use all the time like Spanish. Picking a coding language works similarly.

Before you pick a flavor, know that everyone needs to learn HTML and CSS. Before you even think about enrolling in a bootcamp, teach yourself these languages. Once you can construct a static HTML page writing raw HTML and CSS code and get it up on a server, you’re ready to pick a path.

Python, JavaScript, and Ruby are currently the most common open-source options offered by bootcamps, but they are by no means the only languages out there. You can write software using any of these three languages, but committing to one is sort of like choosing Apple vs. Microsoft. They can work in parallel, but for the most part are incompatible, and the software written for one won’t work on the other. As owners of Microsoft Phone users know well, none of those awesome apps that work great on iPhones have been written for their Windows phone. Code generally works the same way. Personally, I deal with a lot of data, and much smarter people than me have written great libraries for handling data in Python. I decided to code primarily in Python to take advantage of libraries like iPython and Pandas, which do complex math for me. It’s sort of like plugging in a calculator app into your raw code.

You will need to figure out what you want to do with the software you write, and which language will best support that task. If your primary goal is to make a lot of money right away, you could learn the languages that high-salary finance companies use, like Scala, Java, and .NET. If, on the other hand, you want to work at a hipster start-up, learn Ruby, Python, or C++. It’s not a bad idea to look at the job postings for the companies you want to work for first to see what they’re asking for.

Once you pick a language, then you have to pick a version of that language. New versions will be relevant longer, have cleaner code and do some cool new stuff, but old versions are more stable and have more libraries built for them. Every choice is a trade-off, and nothing will work 100% of the time.

6. Get used to frustration

One of the most profound things my teacher told our class is that we weren’t really learning to code, we were learning to debug. As normal consumers, even tech power-users, we’re used to stuff just working. Restarting a computer once a month to update some software seems like a huge hassle. Well, guess what, programming is about 10,000,000x more annoying. The code you write that works great locally won’t run on the server. Why? Who knows. And to find out, you’ll need to individually tweak each of the fifty things that could be causing a glitch until you figure out the cause, and when you finally fix that thing, your fix will probably break something else. That is coding.

Have you ever punched a hole in a wall, thrown your phone across the room, or (egads) sent a computer tumbling? If so, coding is not for you. But if you’re still with me, you must be a mellow individual that can handle frustration without smashing a screen. You have the calm demeanor to simply copy error messages, paste them into google, and spend thirty minutes reading five different and contradictory suggestions, trying three to find that the first doesn’t work with one of the drivers your app has running in the background and produces new errors, the second actually does the wrong thing, while the third sort of fixes your problem, but forces you to update some other seemingly unrelated part of your code for it to work.

When I was learning to use git and github, I was stoked to find out about the ability to clone projects in github and add them to my own. Similar to code libraries, you can just grab someone else’s code and incorporate it into whatever you’re working on. Sounds easy, right? So after weeks of work, customizing the clone with all my own code, I decided I would create a git repository and upload my project back to github, so other people could see my work. But, when I tried, there was a weird error telling me I had duplicate repositories. I hopped on stackoverflow, followed the directions I found, and… erased all my work. Yes, while attempting to back up my project, I erased it, all by following directions. It turns out, when you clone code from github, it automatically creates an invisible repository. This is just a thing you’re supposed to know, and since I didn’t know I had created a repository at the time I downloaded the clone, I didn’t understand that by resetting my repository, I would wipe out all changes made over the weeks since I added it. Want to know what I did? I sat down, and calmly spent the next three days recoding all my work from memory. And THAT is what coding is like.

7. Get used to very little help

I had a boss who once described his management style as “handing you a fortune cookie, then leaving you alone in the woods.” It turns out this was good training for coding. Most tutorials tend to fall into one of two types: those meant for week 1 beginners that are far too simplistic to be of much use, or those that are written by experts for other experts. These experts have been coding for decades and will intentionally leave out steps they find to be obvious (you will probably not find the missing steps so obvious). This is actually a big reason why I signed up for bootcamp, and why I recommend it. It is incredibly helpful to have someone around to fill in all those missing pieces for you and help guide you during that intermediary phase.

Much to my surprise, living a mostly digital life, coding books (made from trees!) are actually extremely helpful once you’re done being a beginner and get to the novice/intermediary phase. They provide a coherent level of structure that is hard to find online, and are good for reference when you forget something specific. However, they still assume a basic level of know-how that will constantly trip up the novice developer.

8. Bootcamp is just the beginning

Coding languages are constantly changing and evolving. Code you wrote a few years ago may not be supported in another few years. The code language you learn first may become out-dated or go out of fashion. A new code language or library may make a lot of the old code language obsolete. For example, JQuery is just a better, more condensed way of writing certain kinds of JavaScript, Rails does something similar for Ruby.

The point I’m trying to make is that bootcamp is a great way to kickstart a career change, and really a life change, but your first job out of school is probably going to be entry level, because your skills will only be entry level. If you make less than $50k now, you’ll probably be able to make that much or more with an entry-level software job after going through a bootcamp program. However, expecting to be a full-fledged software developer making six figures and signing bonuses after a four month program is sort of like expecting to be a successful novelist after a summer creative writing program.

9. Learn to learn

The most important thing bootcamp taught me was how to teach myself. Learning to debug, see patterns in my mistakes, and knowing where to go for answers was absolutely worth the time, money, and effort. I am continuing my education by taking classes through Udacity, Coursera, Codecademy, Udemy and whatever other books or online tutorials make sense. I also continue to meet with my bootcamp teacher for mentoring. I’m still doing difficult stuff, but the pace of my learning is continually speeding up. While it may take a novice coder months to learn a language, an experienced coder can probably pick it up in a few days (or so I’ve been told). This virtuous cycle will continue the longer you code, but you have to keep at it for years.

10. Always be building

The best way to learn, and to keep learning, is to keep building. Pick a project and go for it. Start small with HTML and CSS. Tear it down and rebuild it better. Add something dynamic using JQuery or JavaScript. Make your CSS responsive for mobile devices. After a few months, your old code will look as dated and silly to you as the bad poetry you wrote in high school. Rewrite it. Learn backend languages and try incorporating dynamic forms and data. Then tear that down and make it better. Pick a backend framework and drop your old code into that…

You get the idea. Now go code something.  And remember…

The best time to plant a tree is 30 years ago. The second best time to plant a tree is today.