On March 30th, I gave a 5-min Ignite talk at the Product Insights conference. This time around, I shared a personal story about my winding journey to become more code literate. I am including the slides and basic story here. (p.s. I love Ignite talks, not just for the speed and discipline it brings, but because they give me an excuse to break out the Wacom tablet and hand-draw my slides)
My journey to code literacy, still ongoing, started back in my senior year of college when I took a C programming class. My joke is that I got a D in that class, and have spent the last 18 years in tech trying to make up for that fact.
The truth is that I loved this jump into programming. As a liberal arts and fine arts person, I was amazed by the sense of flow that comes with coding. I think that comes from the mix of creativity and demanding constraints. Segue: I actually was getting an A in that class until I decided to drop everything as I obsessively chased my first job at a startup in Texas (Trilogy). I got the job. I also royally pissed off my professor (hence the grade — enough to say “screw you” but not enough to keep me from graduating). I can’t really blame him, but I’d make that same trade all over again.
It is 1994 and I find myself working at a client/server software company and I’m seeing how production software is made, but my role is primarily on the business side even if am collaborating with the dev team a lot.
I’m learning a lot, but every time I try to dig in (picking up a SQL book, for example) there is always another emergency… a product to launch, a deal to close, etc. Even a few years later when I bootstrap a startup with two other friends (Ithority), and I’m doing a lot of the product design work, as CEO I find myself too busy dealing with all the business and customer development issues to get really hands-on with the code.
This doesn’t really change until the early 2000s during what I call the “neutron bomb” phase of the New York tech scene (where all the buildings were still standing but all organic life had been vaporized). I find myself doing a bunch of consulting projects and get the opportunity to code up an object-oriented visual basic application. It is a marvelous learning curve but unfortunately once done, I jump on to the next project and leave it behind. Without re-use, the coding skills don’t really stick.
A few years later I find myself managing a 12-person product team (programmers, product manager and designer), and I’m hating this feeling of helplessness. I’m doing a decent job of managing, in that the team is focused, motivated and getting stuff done, but I can’t actually do anything with the product or custom reports without asking someone for help.
Now it is the end of 2009 and I start another Web company (Aprizi) with a marvelous tech co-founder and my lack of technical skills really bites me. I convince two friends to help out with graphic design and our front-end implementation, which is incredibly generous of them, but our pace is really held up by their available time. We are trying to be really “lean” with rapid validation and iteration, and our speed is way too slow.
So I take over the graphic design and stop everything for a week while I learn CSS. Then I dig into the codebase and implement and iterate our front end. We speed up dramatically, and it feels awesome.
Why did it take so long for me to get here? Well, I always had the desire to become more technical, but that wasn’t enough. Aprizi gave me the necessity, but I also needed the repetition of execution.
I’m not trying to become entirely fluent. I don’t expect to become the world’s best programmer, but I do think literacy is really important and here are a few reasons why.
First, the details matter. In every new application, there are always these little things that are really important but it becomes very hard to distract the dev team from bigger, more gnarly problems that only they can do. I love being able to do these things myself, whether it’s a front-end change or creating an admin interface.
Second, you can get serious speed improvements by being able to be more hands on. For example, this week [of the talk] I had a user test on Monday. We saw a recurring problem rear its head again. After the test, I rolled up my sleeves, made a bunch of changes to the front-end, fixed the code tests and pushed to staging then production in time for the user test the next day. All without disrupting the team’s weekly iteration!
(note: given that I have been trusted with the power to push to production, I try to make sure I keep that trust by not getting cocky with my technical abilities)
Sometimes it is hard to know when to delegate versus execute, but I try to take overall team speed into consideration. If it is faster for me to “do” than to write a story and explain, I’ll often do.
Third reason: if you are familiar with jquery and CSS, you can whip up real-feeling prototypes to test ideas and validate their efficacy before investing time in building the feature. Win.
You also get team benefits. “Us vs them” issues start to go away. I’ve always had a good rapport with my engineer/CS colleagues but I think the more technical I get, the more respect I get and the better communication gets.
Even beyond respect, when you actually get in the mud with the team — when you are there in the trenches together — I think you build a stronger camaraderie that is really useful and rewarding in early stage projects.
Finally, there is the personal affects of all of this. I love the feeling of getting to hold the paintbrush, rather than just managing the process. I’m feeling like a craftsperson again, and it gives me a great sense of accomplishment and a higher degree of work happiness.
I still have a ton to learn and a lot to put into practice, but the more I learn, the easier it gets to learn more, and the more empowered I feel.
That concludes a fast-paced tour through my personal journey to becoming more code literate. My journey continues – onward and upward!