This article first appeared in issue 236 of .net magazine – the world's best-selling magazine for web designers and developers.
Coding is a high-leverage activity. It enables two kids in a garage to upend an old industry. It empowers a 17-year-old working out of a dorm room to invent a new one. There’s no need for an expensive degree or accreditation – just intelligence, sweat and luck.
Frustratingly, the way we talk about coding remains stuck in industrial-era notions of professions. Learning to code is different to learning to do many other things. Coding isn’t about achieving expertise in a single thing: it’s about learning to do lots of little things. In effect coding is more akin to literacy. We all have mental concepts like: “I’m not fluent in Spanish, but I can get around Madrid with a phrasebook.” In short, we know how to describe shades of literacy in natural language. I want to encourage people to think of coding in the same way, and understand that it’s OK to walk around with that guidebook.
Literacy is good
How does that help in the real world? Code literacy, even at non-fluent levels, can boost any team. In every project, there is a whole class of corrections that are harder to explain than they are to do. Designers already know why the type hierarchy is broken: because the developers weren’t really thinking about it, and many don’t understand white space anyway. But if designers can go in and fix it themselves, instead of just explaining which margin to shift by 10px, it’s a massive speed boost for the entire team.
This is tech literacy’s sweet spot. It leads to a dramatic increase in horsepower in the Lean Startup engine via its think-make-check speed. Sharing competencies raises your ‘bus count’, helps to avoid resource bottlenecks – and helps build camaraderie within teams.
But how can we become literate?
Most of the resources out there are for the kid wanting to become a full-time programmer. This can be overwhelming when you’re starting out, but don’t let the information density discourage you. Your path is not the same as that kid’s.
Most of learning to code is just a matter of doing the work – there are no shortcuts or universal principles. But along the way, I’ve picked up a few tips. Spend time within earshot of other programmers, and learn the rhythms of what’s important and what’s not. It’s also critically important to do things, not just read about them. Videos and tutorials may give you basic information, but going to a monthly hack night in the language of your choice (check www.meetup.com) or a weekend hackathon is key to developing a network of resources for when you’re stuck – just as you’d seek out language partners when learning a natural language.
A personal literacy story
As a self-taught designer, when I started at Pivotal Labs I was using Adobe tools for mocks while two pairs of developers sat nearby, discussing the problems they were solving and periodically expressing their solutions as code. We developed strategies for in-browser mockups using basic CSS, HTML and a templating framework (ERB). That led to test-driven development and story-writing using Cucumber. Then I found myself needing tools such as Bundler and Rake – things that let me run the development build locally.
Soon I learned version control (Git). Now I could contribute small fixes, mostly copy and CSS, but I was breaking a lot of tests. So I learned Rspec and Capybara, in order that I could commit code without breaking the build. After that, I learned about jQuery and the DOM, which helped me create better in-browser mocks. By now I was elbows-deep in this stuff, and learning more Ruby, which led to ORMs and REST and HTTP verbs. But because it all happened organically, in small steps, it never got overwhelming.
Let’s not think of coding as a monolithic thing you either have or don’t have, but as a set of many small skills. Approached this way, you can become a lot more powerful as a designer, and you’ll contribute to a much healthier team.
Discover 20 inspirational examples of CSS at our sister site, Creative Bloq.
