Recently, we came across the closing keynote at PyCon by Antonio Rodriguez. In it, he made what he called a “crazy proposition” that caught our attention. Here’s the main thrust of it:
I think every employee in a web startup— or in fact any company which depends on software in any meaningful way— should learn how to code. From the slickest sales guy to the most obstinate operations guy, from the laziest intern to the most professorial manager, if they don’t have their hands in the code, your startup is much more likely to fail.
AboutUs.org is built on Rails, not Python, but this declaration about culture and code in Web startups was very interesting to us nonetheless. We haven’t gotten everyone in our startup to code, but we certainly have had non-programmers dipping a toe into the codebase. Here’s our experience with such an endeavor, and the reflections of the staff involved.
Tip of the Iceberg
The first serious project that got non-technical staff involved in code was a smaller one, not our main site AboutUs.org. It was headed up by Julia and Ted, who work in operations, finance, and organizational development.
The work mostly involved simple front end development, but some of the facts of life for coders became clear to them quickly. One of these points was the need for good source control. Ward Cunningham took a little time to help them get set up with GitHub.
From then on out, they were largely on their own, using online help sources to work their way through it — coding by Google, basically. All of this has been relatively smooth sailing, and Ted said he thinks it could be the tip of the iceberg for us in terms of getting everyone playing with code.
A Little Knowledge
Ted stressed that it was “definitely” a good idea to have people start small and work on what amounted to a side project. Not working right away on our main product afforded us more room for experimentation.
“The idea of pushing into GitHub is in some ways a scary one,” he said, “for mission critical software, if I pushed something that was a mistake that devs didn’t realize was a mistake, it would still be my fault. That phrase, ‘a little bit of knowledge is a dangerous thing’, it’s true.”
Squashing Small Bugs
So now that some of our staff have tried some front end work and tinkering with code, what about the idea of say, pulling an offsite for non-technical staff to learn to write a simple program?
Ted said, “I think it’s a great idea for a lot of reasons. There are a lot of things that don’t get done because the devs are working on higher priority stuff, and it’s not dangerous. It’s changing wording, for an example. Non-devs can do that and it won’t be a big problem. I love the idea of going even further than that, and learning how the basics of the code work.”
“Even reading commits is a good thing, which some of us have done. We’ve read commits over a period of time, watching what the devs are doing. But if actually we had commit access, even if we didn’t have deploy access, to be able to find small bugs and things that are simple, that would free up quite a bit of the dev time.”
Ted got excited talking about how he and Mark, the AboutUs Community lead, were able to refer to line numbers and other specific features of the codebase when talking with AboutUs developers. Clearly it’s not hard to get some staff interested in learning more about coding.
Read Part II for more, including Ward Cunningham’s thoughts about getting everyone to code.
Related posts:
{ 3 comments… read them below or add one }
This is excellent. As a “non-coder,” who manages the client side – a little bit of code is invaluable for a quick fix or bug introduced with an update. It also helps to understand what really goes into a project. Even experienced biz-dev team members can over commit the development team if they haven’t “gotten their hands dirty” with the coding process.
“Why Designers Should And Shouldn’t Code” http://www.clagnut.com/blog/2315/ contains an article and discussion on this very issue.
I’d agree that *an understanding* of what coding involves can be very valuable for people in non-developer roles. However, one shouldn’t try to make everyone a competent coder, not least because coding is not the be-all-and-end-all of existence, even in a start up. To succeed, you need other specialists to do their jobs well, and they won’t be able to do this if too much of their time is taken up with coding…. even if they are producing half-way decent code, which is not always the case.
A very good point. Taking up the time of specialists who don’t handle code is a danger in all this, there’s definitely a delicate balance that needs to be struck if you want to experiment with this kind of thing. In our case, there was a clear business interest in letting some specialists expand their repertoire.