Friday, January 2, 2015

What I Wish I Knew Before I Started Learning to Code

  1. This is really hard and takes a lot of time

    I am probably between 400-500 hours into learning to code. According to code ‘bootcamps’ like General Assembly, if you complete their 12-week immersive course you should be employable full-stack developer at the end of the period. This implies that it takes 12x40 = 480 hours to become a full stack developer. Of course, not all hours are made equally – there is a big difference to learn with a number of teachers and others learning around you and spending all your mental energy on the problem. So this probably represents a lower bound. So I probably have another couple hundred hours before I qualify as ‘competent, entry-level’. This has been really great for my ego. Who would’ve thought I’d learn humility while in business school? There is probably some amount of time that it takes to be a competent full-stack developer


  2. The learning curve is flat at first and gets steeper over time


    Initially, I knew very little. Thus, when I confronted a new piece of learning, I had not pattern recognition or intuitions to fall back on. Learning coding is like learning a language in that all the intuitions are stripped away. I remember in high school Spanish class being tremendously frustrated because I wanted to write papers about the Cuban revolution and Zapatista rebels and neoliberal economic policies in Chile and all sorts of good stuff I was learning in other classes. But I was barely beyond “donde esta el bano?” and was in no position to put together complicated papers about abstract concepts. In the same way, when I started I wanted to make really slick looking apps that I could envision and wireframe. But I was in no position to think about how a front end framework like AngularJS parses the JSON output of a Rails API backend to enable side-loading data (I’m still not really sure what side-loading data is, frankly). In fact, just getting Rails installed and working properly took a month.


  3. Get the right tools


    Sublime Text is awesome and getting a clean command line tool is helpful. I would have bought a Mac if I could afford it – in addition to the standard crappy build of my $800 Toshiba computer (I’ve had to send it to Best Buy for repairs twice - wasting weeks of time), Ruby is not totally compatible with Windows in that a lot of gems are Linux-only. So some things I have to do remotely via Heroku which wastes a ton of time.


  4. Get help – real help


    You can teach yourself HTML and CSS because they are ‘markup’ languages. It is easy to make a change in a file, refresh your browser and see the result. Even better to learn to ‘inspect element’ in the browser and identify how the element inherits its styling. But once you get into ‘real’ coding, as opposed to text markup languages, there are roadblocks which can be rapidly overcome with some help. I chose Thinkful, which I liked because you get an hour a week with a mentor via Google Hangouts, plus video office hours (which, like normal office hours, I never attended). It isn’t cheap, at $500 per month, but I learned a lot and I’m glad I took the course, which samples the best of other services and puts it into a cohesive whole which mostly introduces concepts in the right order. With Thinkful, I built a Wikipedia clone, a Twitter clone, and go help on my ‘capstone’ project. By working with my mentor, I learned how to debug database issues with the interactive ruby console and got a lot of practical advice on what to worry about and what to overlook (E.g., don’t freak out about getting a page to look just right until you know exactly how the feature is going to work – it might not even include that page in the final form!).


  5. Non-technical people value different things than technical people


    I remember sitting in the MBA lounge, plugging away at the Twitter project. Finally, after hours of trying to figure out this API, I get a proof of concept to work – I can display an array of three usernames on the page. A blank screen, three names, that’s it. I show it to a friend who nicely says ‘so what?’ But I just put so much work into this! I thought. I showed another friend, someone with a CS background. ‘Oh man, that’s the best feeling in the world, huh?’ ‘Yeah’. The flip side is, of course, also true. A great looking app can be riddled with bugs and performance issues. And so, the quality of a web product is evaluated in vastly different ways by different people. A user evaluates it by its visual appeal, intuitive layout, ability to enable the user’s goals, and speed. An engineer evaluates it by its scalability, the ability to maintain and extend the application, its test coverage, its conformance to norms, Etc. A product manager needs to take some blended approach, to achieve optimal business outcomes.


  6. In some ways, writing code is like any other kind of writing


    That is an overstatement, but, at its core, writing requires planning and revision. Tell an MBA that you expect them to produce a full DCF model on a private equity target and they will complain it will take them 10 hours to do. Why? Because you have to design the model, research the assumptions, create the model, create sensitivity analyses, play with the numbers, etc. etc. But ask that same MBA how long it takes to build a simple CRUD app, they will vastly underestimate it. Ask an engineer, and they will describe the need to sketch a wireframe, design the database model, consider alternative technologies, write tests, create some features, refactor, etc. etc. The process of creating intellectual output is not fundamentally dissimilar, but the concerns and specific tools are.


No comments:

Post a Comment