I am a tech nerd before I am a marketing person, but still equivocate about identifying as either one. For me technology is a literacy, a tool used to get a variety of jobs done. So saying I am a “programmer” seems beside the point. What problems do I solve? For what purpose am I programming stuff?
Event producers don’t say, “I am a hotel-room-renter.”
At the same time, saying, “I work in marketing” doesn’t seem specific enough. Do I leave paper flyers underneath car windshields at shopping malls? (Ain’t no shame, game recognize game.)
I solve marketing problems with technical tools. And not from a distance. I get my hands dirty. As more people can + should.
I truly believe there is no special type of person predisposed to programming or system configuration or data analysis any more than there is a special type of person predisposed to reading and writing.
Below is a blog post by a “marketing guy” who outlines some of the tools he learned in his journey to become technical, as well as his favorite resources. He’s not trying to be prescriptive about stuff. He knows what he had to learn might be different from what you have to learn. So don’t take notes about the specifics here. This stuff changes fast. (Except maybe VIM. VIM was here before us, and it will be here after us. #nerdjoke)
But do be inspired + motivated.
If you work in a small team, especially a startup, knowing what’s going on and how your product works is valuable also to a non-technical business co-founder. It gives you a wider vocabulary for working across issues, which makes communication more efficient. It also hedges team risk: if you are two people, and the techie changes for whatever reason, you’ll be much better equipped finding someone and telling them what’s going on if you know your product technically. Finally, technical product understanding across the board of startup founders is just respectful towards your product, and ultimately, the end-users of the product.
Based on the stuff I have run into (head-first), here are my recommendations for non-techies wanting to build a solid foundation for more learning. The examples are Mac-specific.
1. How to use the command line. You will need this sooner rather than later. You’ll need to get to invisible files, system files, config files. You may install Ruby Gems or need to use SSH. You may need to see what version of Java you’re running, or Python, or Maven. And later on, you just do things faster this way.
Here is a quick intro to Terminal commands:
A great longer tutorial series is Lullabot’s Command Line Basics:
2. Using vi / vim. This is where it gets geeky. When you run into those invisible config or system files, they’re much easier to just open in the command line and edit and save right there. vim is a total headscrew if you have to dive in without knowing what’s going on. Learn it first. Here’s a good video to get started from the Lullabot series:
3. Learn Git or SVN. Depending what your project uses for version control, you’ll need to understand what version control is and possibly how to use it. GitHub being the most popular, that’s the place to start. There are GUIs for Git (Github for Mac for example), but the command line stuff pointed to above will serve you well. Here’s a good 11-minute video, which also goes over branching (learn that before you screw up there):
4. Power-usage of your chosen code editor. Especially for beginners, a code editor is primarily a code reader. You want it to have syntax highlighting. This is must - it teaches you the structure and rhythm of whatever code you are looking at.
You also want it to support you on both a macro- and micro-level of reading the code: it should have built-in tools for projects and documentation, respectively. You want project support, because that teaches you the structure of programs on the level of where the files are organized (you want to tackle this early on, too - organization helps avoid confusion, and confusion is the #1 killer of motivation). Documentation gives you context and explanations to the code snippets you are reading. I recommend you look into for example Aptana Studio (heavy, full-featured) and Chocolat (light, streamlined). Perennial favourites are also TextMate and Gedit. This list could go on.
5. Understanding MVC. Finally, this isn’t about specific tools but basic architecture. It is about structure that you’ll do well to understand before as early on as possible. The MVC isn’t the only way to understand functional websites, apps and programs, but it will get you pretty far. Coding Horror’s* short post on MVC is a must read - also excellent comment thread.
EDIT: in the Hacker News comments, wamatt and troels pointed out that the MVC example above is misleading. The Ruby on Rails MVC architecture is a better way of thinking about Model-View-Controller. Separation of Concerns is what I was more after, and the Wikipedia article provides great examples of that.
I think that you’ll be much better equipped for starting to learn coding with the above. Now hit those courses. Good luck.
* And speaking Coding Horror… I strongly disagree with the recent post “Please don’t learn to code”, which assumes ‘learning to program’ means ‘becoming a programmer’. That doesn’t have to be the case. Learning coding is like learning another language. Even a little bit can tremendously broaden your understanding of the world. If you’re going to Italy, you want to learn a few things in Italian. Say ‘well, I can’t be a native Italian speaker, shouldn’t bother at all’ and you’ll miss out on a lot.
Did I miss out on anything? Let me know. And follow me on Twitter here.