Why everyone should learn to program (and where to start)
I’ve previously said that the problem with attracting new programmers is not in explaining how to program, it’s in helping people understand why to program.
So why learn to program, aside from the life lessons mentioned in the last post? A lot of reasons, actually.
It really is a form of “digital literacy”. Even if you decide programming isn’t how you’ll make a living, having these skills is like knowing how your car is put together: you will often know how to fix problems yourself, but even when you have to take it to the mechanic, you’re more likely to be taken seriously.
You’ll run a better business. If you have an entrepreneurial bone in your body, learning to program is going to return rewards to you many times over when starting your own company. I’ve seen many startups fail because of poor technical leadership by founders, and many succeed due to good communication between management and engineering.
You’re uniquely set up to succeed. Whether your background is as a writer or a pizza maker, it will likely help bring a completely different perspective to programming, which benefits everyone, including you.
Don’t let your subconscious lie to you
One life-impacting lesson I’ve learned recently from Paul Graham is that we too often let our subconscious make the decision to steer away from things that seem difficult. We mentally file it under “impossible” and let our conscious mind plan our goals around the perceived roadblocks.
Let’s run through some of those:
“But doesn’t programming require a formal education?” No. Next question.
“Isn’t it hard?” Yes. But not in the way you’re thinking. It’s hard in the way that playing an instrument is hard, in that it is merely a matter of practice. In fact, learning to play a musical instrument is the most direct parallel to programming of which I’m aware.
“Isn’t it just for antisocial, nerdy guys?” Oh dear, let’s dive into that one.
First off, it’s time to let go of the programmer stereotype from the 1980s, because it’s not useful and no longer accurate. We have a whole new crop of stereotypes for you to choose from.
Most distressing is the fact that most women have had a lifetime of exposure to the idea that “programming is for boys”, and from a young age, mentally wall that area off. This costs us in software quite dearly, both in sheer numbers and in the diversity of perspective that smart women bring to the activity.
Don’t let a lifetime of people trying to intimidate you (even subconsciously) prevent you from realizing that you have all the capability they do.
Programming is a special ability, akin to a superpower. It transforms you from a consumer into a maker. But it’s not for special people.
Some programmers feel otherwise, that programming is something you need special skills for. Instead of punching them in the face, just remember that a few hundred years ago, these are the types who thought reading and writing should be reserved for clergy. Learn and make all you can, so that these code hipsters can someday complain that they were programming before it went all mainstream.
Starting on your own path
Learning to program isn’t as hard as it sounds if you’re working with people who know how to ramp up the difficulty properly (and speak English instead of jargon). The Learn to Program (Ruby) book I used is a tried-and-true introduction to programming concepts, and I recommend it highly.
Because I evangelize programming to non-programmers, I am often asked, “What language should I learn?” That actually does matter, but mostly because the quality of materials available varies greatly from language to language. This is why I’d say Ruby, Python, or Javascript are great first languages: the quality of instruction materials available for all three is quite good, and they’ll have you actually building things relatively quickly.
Plus, with those languages, there are communities of people who are knowledgeable and generally helpful. There’s simply no substitute for personal, interactive feedback with experienced mentors. Even as a brand-new programmer, I found the pattern of showing up to local Ruby User Groups and following the attendees on Twitter to be incredibly valuable. It helped me create a support network of people who could answer questions or buoy me up when I felt like I was underwater.
Finding a local User Group, following helpful people on Twitter, joining related IRC channels (I use the fantastic IRCCloud service for this), and generally trying to grab the attention of people who do this for a living are all good ways to help luck start to fall in your favor.
Later this year, my understanding is that Mendicant University will be holding classes for newer programmers, and that may be a great time to start. If your local programming groups don’t offer workshops for new programmers, I bet they’d be open to the suggestion.
If you’re interested in learning to program, find me on Twitter and I’ll do my best either to help you or line you up with people who can.
If you knew half of the doors it’d open for you, you’d be starting one of these books or tools tonight and beating down the door of your local programming community leaders to build an initiative for new programmers. If you give learning to code half a chance, I can promise that in some significant way, opening your mind to it will have an impact on the course of your life.
In the last post, I talked about how I learned to program. This process has had a profound impact on the way I think, the way I approach problems, and my outlook on life in general. Here are just of the few of the lessons this process has taught me:
Unknowns are not bad. I used to work from a place of fear. If I didn’t know how we’d solve a problem, the risk was unacceptable and we’d abandon the effort. Programmers almost never know exactly how they’ll solve a problem, only that historically, they’ve been able to solve them. This is a much better place from which to start thinking if you want to change the world.
Breaking problems down is my job. Along with the last point, if a problem looked too complex, it was easy to get overwhelmed. But programmers know they’re the last line of defense: the enzymes whose job it is to break complexity down to manageable chunks. This is the key mindset difference that makes programmers so damn special.
Sharing is good. Previous jobs, Marketing in particular, taught me each and every idea is a trade secret and must be protected. Programming leads the way in thinking that “none of us is as smart as all of us,” which is part of why software is moving humanity forward at an astounding pace.
Black boxes are stupid and harmful. I used to think that if I didn’t understand how something worked, I probably never would. Programmers don’t allow “black boxes”: they have to tear everything apart to know how it works. It’s okay to not care how something works precisely, as long as you have a general idea of what’s going on. My friend Dave Brady calls it “Leaver’s Law”: “Anything that a system does for you, it also does to you.”
Sleep is amazing. Programming has taught me that your brain will chew on things for you and often bring you the answer after a good night’s sleep (or even a long walk). Letting your subconscious process things for you is a gift and a curse: I’ve had horrible code nightmares where I couldn’t solve a problem. But more often, I’ve awoken to find last night’s unsolveable problem quite easy to untangle.
You’re a free agent. I used to feel chained to my employer, completely subject to the ups and downs of the company. I felt if I lost my job, I might just die. Programmers tend to think in projects, and an employment contract is just that: a contract that needs to be mutually beneficial, or they’ll find somewhere better to spend their time.
Develop, then trust, your intuition. Programming is a surprisingly intuitive process. Things that just “feel wrong” or “feel right” typically are. You can then find the principles that define and back up these intuitive feelings.
People get paid to do this? If you don’t marvel at that from time to time, chances are your work isn’t aligned with your passion. Even on rough days, programmers generally have a sense of how fortunate they are.
Don’t give in to the overwhelming temptation to quit. The highs are high, but prepare for soul-crushing, ego-obliterating lows. It’s important to build a network of people who know exactly how you feel.
They’re not going to eat you. You will embarrass yourself. You will write hideous code. You will ask stupid questions. But all the embarrassment you’re conditioned to feel is unwarranted, because 99% of the time, sharing things you make with other makers is a safe thing to do.
It’s not as hard as it looks. There are a number of reasons that programming looks hard from an outsider’s perspective, but it’s only hard work (there’s a big difference). Things that appear to be a cliff to newbies actually have a gentler slope on the other side. It’s still a hike, but it’s doable.
Feeling dumb is normal. We’re trained like seals to bark the right answers back at teachers, bosses, etc., and to feel awful with anything less. Programmers get really comfy with not having any answers upfront, and finding fulfillment in the discovery process.
Your capabilities are limitless… eventually. Programmers are special because they tend to look at ignorance on a topic as a passing phase. Because they have to re-learn their own profession as it’s reinvented every few years, they know that given sufficient time and attention, you could become an expert on anything you want.
Show me the code. Years ago, I figured I had to try to play political games to get ahead. I even tried to learn to golf to get in my boss’s good graces (shudder). Not so with programming. Coders either deliver a result, or they don’t. Next to sales, it’s difficult to imagine a more results-driven culture. It’s basically impossible to BS your way through, because you either make things or you don’t.
Feedback is feedback. It’s better to move forward on the wrong information or without permission than to sit still and wait for the perfect opportunity. Being proven wrong is always an acceptable outcome, because it means you’re moving, and the “perfect opportunity” seems to prefer a moving target.
It’s about the journey. This is probably the lesson that’s had the biggest impact on my life. It’s too easy to become so focused on chasing some big reward while missing all the wonderful experiences in between. If you can’t enjoy the journey you’re taking, you probably won’t love the destination either.
Above all this, I’m generally a much happier, more patient person. I’m infinitely grateful to all the people who taught me these lessons and encouraged me to keep pressing forward.
Learning to program has changed my life in vastly more ways than listed here, and it’s why I’m so passionate about making the onramp less steep for new people. In the next post, I’ll talk about why you should learn to program and how you can get started.
Quite often, when I tell people I left a career in marketing to teach myself to program and develop software, they react with surprise or even amazement. As much as my ego wants it to be, it’s really not all that special, and it’s something I believe anyone can do, and many should.
Here’s how I learned to program, how it changed my perspective, and how you can do the same without falling into some of the same pitfalls I did.
The spark of interest
After spending nearly 5 years learning online marketing for the startup I worked at, I had become profoundly unhappy in my job. The only path forward I saw for myself was “marketing guru” (ugh), and I was constantly depressed.
Several people, including my dad, suggested that I pick up programming, and that I might enjoy that more than my present career. I perceived it as a serious affront to my abilities as a marketer and fumed at the advice.
But eventually, I decided to take a few minutes to talk with our lead developer and brought the idea up. His response surprised me and sidestepped all my concerns: “Everyone should know how to program. It’s a part of living in modern society. It’s like knowing how to change your oil or change a tire.”
We talked late into the night, and he wanted to show me how amazing programming was. He wrote a little program in Ruby that would create different animals, give them stats, let them fight, and see who would win.
I watched the strange symbols dance around the screen and was totally fascinated and thoroughly confused.
He handed me Learn to Program by Chris Pine and suggested that I start reading it. He said that I’d know whether I had any interest within two weeks, and my response would be either “this isn’t for me,” or “people get paid to do this?”
Learning to program
I started in on the next night, and asked the second question within hours. Captivated, I spent every night for the next few weeks working through the exercises in the book.
Each day I’d run into the developers’ room to talk about concepts, check my code, or get help on the tougher exercises (looking back, a recursive algorithm for parsing an array of arrays is a bit much for beginners).
Clearly, it was a stroke of luck that I worked with wonderful, knowledgeable people who were too happy to help me along the path.
I continued this pattern of learning new concepts through several more books, the best of which was Beginning Ruby, by Peter Cooper. I then picked up Agile Web Development with Rails and started building Rails apps along with the tutorials. I was actually making stuff, and felt like I could take on the world.
Getting overwhelmed
From there, the books thing was working so well that I kept rolling with it. I picked up several advanced books that started to take me off track. Somewhere between Design Patterns in Ruby and Test-Driven Development, I started to feel like I’d gotten in over my head.
To make matters worse, I couldn’t separate what I was learning about Ruby from Rails. I didn’t understand where the language ended and the framework began. Did I have to read the whole “Programming Ruby” book? What about Rails books? What was MVC? I had to learn Javascript too? And CSS? And HTML?
I confided in my friend and admitted that I’d failed as a programmer. I couldn’t do it all at once, and there didn’t seem to be a way to break it up. He told me, “That’s enough, your problem is too many books. You need to write some code and go from there.”
My first projects
My friend was right: it was time to just start making things. I got tiny assignments from the dev team: small copy or functionality changes, or bite-size features that were low-risk if I failed.
The things I built were embarrassingly elementary, but it’s an amazing feeling to ship code, and I felt back on track.
I tried and failed at a few more side projects. I was wholly unprepared to build the square-foot-gardening app I wanted to make, having underestimated its difficulty.
It was about this time that the company started to go under and I was shown the door. I suddenly lost my support network, and it became more difficult to practice my coding skills.
Luckily, just a few months later, I discovered Ruby Mendicant University. Started by Gregory Brown, it’s a free online school for intermediate programmers with a strong focus on building stuff for real-life situations.
Going full-time
After completing the core Mendicant University course, my projects became slightly more ambitious: A video upload site that limits you to 1 minute (a terrible idea, if you’re considering it), then a lunch-voting app, ToDoGroove, and now Hashbadges, which is mostly under wraps for the time being.
Even with all that, I still had a mental block about becoming a full-time programmer. I was more comfortable hanging back a bit and helping manage programmers than trying to write code that would actually be used in the business.
Luckily, I had a friend call me out on this and tell me that it was do-or-die time. I either needed to start coding and stop making excuses, or be happy with a non-technical role. We spent the next week pair programming, and I realized that I really am capable of programming full-time.
That week, I moved my desk into the programmers’ area and decided to become a full-time developer. (Kudos to my employer for not firing me for that one.)
I’ve only been a full-time programmer for about 5 months, but it’s been the most fun and interesting few months of my career thus far.
I have no idea where the future is taking me, because I’m having so much fun with what I’m doing now. No matter what I decide to do next, the act of learning to program has taught me lessons that completely altered the course of my life.
November 10th, 2009 marked a pretty dramatic turning point in my career. The startup I worked for was in a tailspin, and a friend who’d escaped invited me to visit his new workplace for a meeting of the Utah Ruby Users Group.
This was the first time I’d attended URUG, or anything like it, and it was scary as hell. There were smart people talking about things I didn’t understand, and a guy in a fez who seemed to be asking lots of annoying questions.
Mike Moore showed off a fascinating new technology called Ruby Version Manager by a fellow named Wayne Seguin. People talked about the dramatic changes in Rails that would soon take place due to the work of people like Yehuda Katz.
I was literally incapable of processing about 90% of the conversation in the room, and terrified someone would ask me to say something and expect me to do anything but make a fool of myself.
Even though I was so bewildered that I literally cannot remember who was at that first meeting, I’ve since learned that at several of the people were there are now some of my closest friends. Over time, I became a part of this community that literally saved my career.
Here’s why I think the URUG community’s been so important to me:
1. It’s consistent.
It’s easy to forget now that there were moments where I very nearly gave up on breaking into software development. It would have been so easy for me to go back to marketing, and I had several opportunities where I could hang up my still-new coding spurs and have a long, prosperous career with the word “product”, “process” or “manager” in the title.
But I got to associate with the people at URUG every month, and I was able to keep my eyes on the prize. It repeatedly connected me with me the kind of people I wanted to emulate, and the kind of work I wanted to do.
Just having a single night where I knew I’d be around great people was an anchor when becoming a software developer still seemed like a distant goal.
2. It’s accepting.
The guy in the fez may have been irritating, but nobody chased him off. I was irritating, I’m sure, and nobody chased me off. It was the only time I was able to have a face-to-face discussion with experienced Rubyists, ask my stupid questions, and come back next month with more.
Never once have I seen behavior at a URUG meeting that I felt embarrassed by, nor do I hear people say negative things behind others’ backs. I’m very proud to say that the kind of people who show up to user groups seem to be the kind of people who are interested in building one another up.
3. It’s a chance to contribute.
I once wrote a blog post about why I don’t contribute to open source, and now I realize I missed the point entirely. A friend pointed me to an old talk by Chad Fowler, one of my heroes, where he mentioned that people should contribute in their own specific ways.
My problem was that I was trying to contribute to the community in exactly the same way as people who are the best coders can contribute. So contribution felt like an obligation that I was failing.
That’s why one of my favorite things about the URUG is that everyone is, at some point, asked to participate. Even as a brand-new coder, I was given a topic to research and come back to share the following month. I mangled it, I’m sure, but the group interacted with me, applauded, and I gained the confidence to do it again later.
User Groups are a wonderful way for people to ease into contributing to a community without feeling like they’re competing with ninja-coder strangers on the other side of the planet. In fact, it’s so sneaky that you may not realize that you’re contributing just by being yourself and showing up.
My opportunity to help
Last week, I was asked if I’d be willing to handle the responsibility of organizing the Utah Valley Ruby Brigade. It’s intimidating, as I haven’t done anything like this before, but I am so grateful to be getting a chance to contribute the best way I know how.
At lunch with Mike Moore this week, we briefly talked about what sort of “outreach” programs we might offer to newbies. I do teach a programming class to non-programmers and think that’s a fun and noble goal. However, the most valuable thing is what URUG already offers: consistent meetups with friendly, smart people who are actively invested in one another’s success.
I can’t begin to thank Mike Moore and Jake Mallory for their work in maintaining URUG, and hope I can put at least some of the value in that I’ve received over the last two years.
For now, the best I can hope for is to bring my newcomer’s enthusiasm, not break the things that are working, and learn the rest as I go along.
I spent a good chunk of my Sunday pair programming with a friend. It was sort of a TDD bootcamp, and I wondered what, if anything, he was getting out of it.
My guess is that he’d been mentored in the past by smart, patient people, and felt compelled to help another person along the path. Or maybe it’s just because he’s a cool guy. Either way, I’m grateful, and I can’t wait to someday be in a similar position to pay this forward.
Programming, especially in languages like Ruby and Python, is a heavily mentorship-driven activity. There are no colleges that I know of that place a focus on learning these languages. Few develop these skills in a total vacuum. (And you don’t typically want to work with those who did.)
Here are a few things I’ve learned about mentorship, especially of late:
Advice for Mentors
If you’re even marginally interested in acting as a part-time mentor, these are some fantastic behavior patterns to follow. I observed many of these while working with several people whom I see as top-class mentors:
Be patient, they learn slower than you do and will often be flat-out wrong
Ask questions you already know the answer to and let them come to a realization
Give them space to screw up. That means their hands are on the keyboard, at the whiteboard, etc.
Ask if you can be candid. Sugar-coating your feedback is a great way to make sure they don’t make progress.
Advice for Mentees
Ya’ll better recognize that you need a mentor. It’s easy to get stuck in a rut when surrounded by books and your own problem-solving skills. A few hours with someone at a higher experience level can change your entire perspective on some key concepts. Do this often enough, and you’ll grow by leaps and bounds.
You’ll probably have to build a “patchwork mentor”. You’ll likely have to stitch together a semi-cohesive mentorship out of hundreds or thousands of little interactions over the course of time.
Some people are better at mentoring than others. You will probably work with some people who simply don’t have the patience to teach you. Don’t get frustrated, they have a job to do, and you may be better off seeking help from people with a deeper well of patience, at least for now.
Some people are better at being mentored than others. Being mentored is a skill that requires just as much patience as mentoring. You have to work at developing your own patience.
Don’t take it personally. Being wrong is fine. You’re going to get honest feedback, which you need desperately right now. Your mentor may even get frustrated with you. Don’t use that as an excuse to quit.
You’re going to get directly conflicting advice. Just pick the advice that feels right and go with it for now.
Take the wheel. Don’t be afraid: you’re in a bumper car, not a Ferrari. Butt in and ask if you can drive.
Get some alone time. Go ahead and make a mess on your own, then set up code reviews to point out how you could have done better.
Be grateful. Humility is the only weapon you have to keep your mentors around and to actually learn from them.
Building your own mentorship:
Here are some ways you can build your “patchwork mentorship”. I can vouch for all of these, as they’ve all benefitted me:
IRC: Hanging out in IRC chat is how a lot of experienced people stay in touch, and they can sometimes spare a minute to answer a question.
Blogs & Twitter: Reading good blogs or following smart people on Twitter is like having access to a factory that manufactures insight. I don’t have room to point out all the programmers who have influenced me through blogs & tweets, but they are numerous and I am grateful.
Books: Books are great. I’m a big fan of Pragmatic Programmers. Though, at this stage, I’ve often found it more productive to try and write code and then get feedback, versus the one-way communication a book provides.
Learning from a mentor is hard work. Piecing a mentorship together can be even harder, though it doesn’t need to be.
I hope this is somehow helpful to you if you’re looking for a signpost on the road to becoming a better developer.
“Your problem is not at all what you can and can’t do, but rather your expectation that things should come easy to you.”
Gregory Brown earned his spot in the Ruby Heroes roster more than a year ago, but he’s earned a central spot in my personal constellation of heroes (and friends, if I can be so bold as to claim him).
It’s been about a month since he wrote this to me, after I came into the IRC chat room, feeling like a complete fraud and failure as a programmer. Tonight, I’m rolling that sentence around in my head, and it cuts so deeply to the heart of one of my most cherished beliefs: that I am a smart, talented person who catches on to things quickly.
“You think things should be easy for a ‘real programmer’, and get frustrated when they’re hard for you.”
This belief in my inborn intelligence/talent backfires hard (and there’s a lot of science to back this up) when it comes into conflict with personal experience. When I face a problem I can’t solve alone, I’m stuck. Either I’m an idiot or the problem is so hard as to be unsolvable.
“So you work extra hard, thinking that will help you catch up.”
Historically, I’ve let my ego tell me the problem is unsolvable and I’d give up. Over the last year or two, I’ve discovered that I can throw extra effort at a problem, work day and night, and get some of the same results that more experienced people get in half the time.
But this is a hack! It’s unsustainable, and only temporarily props up my belief that I can accomplish these “out of my league” problems alone. Sooner or later, I’ve vacuumed the joy out of the problem-solving process and learn to fear and avoid it altogether. I believe this may be one of the primary sources of that complex state we call “burnout”.
“Just get the help you need from those who will spend time teaching you.”
This is the ultimate ego smasher: asking for directions. It’s so simple, so why don’t we do it more often? If you’re a programmer, you almost certainly know programmers smarter than you who know the lay of the land and would be happy to help.
Men famously hate asking for help, while most women I know find the “I must persevere alone” mentality ridiculous. This point of gender differentiation is one of the reasons I think it’s an absolute crime that we don’t have more women in programming.
“Most ‘easy’ programming things are only easy because you’ve done them 100 times and learned them years ago, not because they were easy to learn.”
Ultimately, patience with yourself is at least as much a virtue as other forms of patience. It may perhaps be the sigle most important kind. Dave Hoover, in his excellent Apprenticeship Patterns book, really tries to get you to reframe, moving the camera back so that you can take a view of your skills in terms of decades, not weeks or even years.
Lastly, it’s important to find that person or group you can turn to in the moments you feel stuck and inept. I am fortunate to have an awesome support structure through friends I’ve met in the Utah Ruby Users Group and Ruby Mendicant University.
Thanks Greg, for the advice and for giving me a place to go when I feel stuck. If you can be as patient with yourself as Greg has been with me, you’re going to turn out just fine.
Greg Brown, creator of several open-source projects and the free online Ruby Mendicant University that I participate in, put together an incredibly thoughtful video addressing my most recent post, point by point.
Thank you Greg, it’s incredibly enlightening. I still plan to collect the best of the responses to that post, but by and large, this pretty much covers it.
Since then, I still haven’t really participated. On Twitter, I commented that OSS looks like a shark tank to newbies, and I need to back that up.
The fact is, I actively contribute in some fashion or other in several open source projects. But I still feel very much like an outsider, as my contributions aren’t typically code-related.
So why am I (and I assume, many others) still an OSS wallflower?
At the profound risk of projecting my feelings onto other people, I would like to share some objections that I feel may cause new(ish) devs to shy away from contributing to open source software.
It’s not obvious where to start. From what I hear, a lot of OSS contribution comes because a person needs functionality in a piece of software that isn’t there, or finds a bug. They can submit a failing test case or even a patch. In my daily use, I don’t run into many of these situations. There aren’t many devs sticking their hands out asking specifically for help on a project, and fewer still who would be willing to take a newer developer under his or her wing.
Guidelines often make a maintainer’s life easier, and mine harder. Yes, maintaining an open-source project is an arduous, thankless task. But I’ve looked at contribution rules/guidelines that turn a simple idea for a fix into a bureaucratic brick wall worthy of Microsoft. A notable contradiction to this would be Wayne Seguin’s welcoming contribution page, complete with tutorial video.
Open source is for people who are better at this than me. I realize this is probably a copout for not shipping, but I am just not comfortable that I’m at a place where I could release software that’s good enough for actual developers to use.
Trying to contribute and failing makes me feel stupid. I’ve submitted several pull requests now and had 0 accepted with no comments as to why. It’s like the universe is confirming that yes, I am an idiot, and my “help” is not helpful. What a profoundly embarrassing waste of time!
There’s no time. I have a kid, a new gig, and a mounting set of responsibilities. It takes me 3-10 times the amount of time to write code as a more experienced developer. Now, my non-code-related contributions are now eating up my former “coding time”. Yes, it’s the universal excuse, and one that I think melts away when the other excuses are removed, but it bears mentioning.
It’s pretty lonely. I think most people figure this stuff out on their own, and so maybe expecting a hand to hold is too much. But is this really some spirit walk, where no one is allowed to accompany you, lest you learn nothing?
So yes, OSS can feel daunting, even like a shark tank. I don’t have all the answers to these issues, but I’d like to see more maintainers seeking contributions with some specificity, and then actively responding to pull requests. A call for additional test cases. Bug fixes. And yes, documentation.
For all the openness of Github, there’s no Quora/StackExchange-type system to let you know which projects are in need that you might be a match for. Seems like that’d be a good feature.
While the previous post was about the tools I learned to use, this post is more about my successes, my failures, and the philosophical things I’ve picked up in this session.
My successes & failures:
Styled website WIN.
While I wouldn’t say I could jump in and whip up raw CSS from scratch, with the toolkits provided within Compass, Sass, and Blueprint, I can kick out a decent web stylesheet pretty quickly and without a lot of fuss. Most of the intimidation I felt about CSS was groundless, though it can still be punishing at times.
Web Fonts FAIL.
I tried several things, but couldn’t figure out how to replace my default font (Helvetica) with a font using Google Font Directory. Web fonts became a fight that I’d just have to have another day.
Overlapping styles FAIL.
One thing Compass lets you do is cleanly separate your stylesheet partials on a page-by-page basis, which seems to be how Jordan does his. I opted instead to create partials on a per-type basis (one for forms, etc.), and this bit me badly later.
I altered the styling of my form partial for an entry form, only to go back through my app just as I thought I’d finished to discover I had completely broken my file submission form.
This added lots of extra work when I felt utterly done with the project, and actually led to my epic Git FAIL.
Git FAIL.
This was the second major time I severely frustrated myself with my lack of Git knowledge. I didn’t realize git -rm actually deletes a file, rather than a reference to a file, and I did a git revert to before I’d fixed a bunch of broken stuff.
In the end, I wound up swearing at my computer a lot and ultimately re-doing a lot of work.
At my next convenience, I’m going to go through Jim Weirich’s Git Immersion, it’s an open tab in Chrome right now, waiting for me to learn how to suck less at Git.
Learning jQuery FAIL.
I had planned on learning jQuery as a part of this course, and it just didn’t happen. I watched a few screencasts and read up a bit, but didn’t find occasion to even dip my toe in the jQuery pool.
GeoKit WIN.
GeoKit is just awesome. It’s one of the nicest, simplest, and most useful web API tools I’ve used so far.
Google Maps FAIL.
I had assumed that someone would have written a nice Ruby API for Google Maps. The answer is “no, go learn Javascript and do it yourself.”
To embed a map, you have to stuff a lot of Google-specific code in your <head>, which doesn’t play nice with the concept of a layout page. It really doesn’t play nice with Haml, so it was back to ERB for me.
Even though I could look up an address and make a map display, wiring them together required a lot of work from Jordan to fix my mistakes.
On confidence:
This was a big confidence booster for me. The only thing standing between me and getting a website done is making the time to do it. If you want something, just do it.
On pacing:
The September session taught me that when you have 3 projects to accomplish, don’t wait until you’ve finished Project 2 to move on to Project 3. Start planting the seeds for all your projects early on, so that you’re not rushed to do 100% of anything in the last couple of days.
Or it *should* have taught me that. Instead, I tried to accomplish my projects serially, spending a few days on Project 1, then more than 2 weeks on Project 2, and less than 48 hours on Project 3. Needless to say, Project 3 was a bust.
On sleep:
Toward the end, I was working until at least 2 or 3 AM every day trying to get my app styled, and sleeping an average of 4 hours a night. Greg told me to ease up, that RMU isn’t meant to upset someone’s life balance. He was right that I was pushing myself too hard, as I have a tendency to fixate on a goal and not let up until I’ve finished, even when that isn’t the wisest course of action.
However, I like the idea of “excess, in moderation”. I pushed it really hard, but not so hard that I’m burned out from further work. Maybe in another 6 months or so, I’ll do another sprint where I immerse myself in learning some new thing or breaking some perceived barrier.
If I could go back and change things, I’d probably have scaled back my ambitions somewhat and pushed the average up to 5 or 6 hours a night. I think people were starting to notice that I was cranky.
“No heroes”
Greg added that RMU isn’t about elevating heroes. I hope my crazed ambition is not perceived as any kind of heroics, because RMU is a pretty personal journey for each student. There is no Honor Roll, there are no gold stars, and there’s no valedictorian. It’s not for one person to try to set a high score. I was striving for a very personal goal, to conquer my hesitance to design a website, and I feel like I (barely) achieved it.
Finally, thanks
Lastly, I want to reiterate my gratitude to Greg for running RMU and to Jordan for his inordinate amount of work in helping me achieve my goal for the session. I still have a long way to go before I’m a “real Rubyist” or a “real web developer”, but I’m much closer than when I got involved in RMU.
This post is more about the process and technical challenges I faced in creating a full layout for the first time. In my final post on the topic, I’ll share more of the general lessons from this session.
For me, the process went as follows:
1. Mockups
2. Backtrack & fix (set the stage)
3. Create assets
4. Implement styling on page-by-page basis
This, with a lot of reading and learning about tools & technologies I needed to get the job done.
The mockup stage: Balsamiq, etc.
I cannot tell you how critical this is. The mockup stage is the part where you think through all the user’s paths through a site, what they’ll expect, and what context they’ll need to get what they want. You get a sense for visual priority and information design. All before writing one line of code.
The visual context simply cannot be guessed at or thrown in during implementation. My opinion is that if you’re not doing a thorough mockup before coding, you’re probably going to screw something up pretty badly.
I’ve used a lot of different mockup tools, including sharpie/paper, Mockingbird, HotGloo, Keynote UI templates, and iMockups for iPad. Balsamiq is my personal choice. You can learn it in 20 minutes, and cloning your mockup and then exporting a bunch of tabs to .png will save you lots and lots of time. My 2nd choice would be sharpie/paper.
Once it came time to actually style the pages, designing to a mockup didn’t tie my hands at all. It actually liberated me to work within the framework to offer the best presentation possible, without worrying about fundamental questions like whether to choose a 1, 2, or 3-column layout.
It took a few hours to think through properly, but I got those hours and more back when it came time to turn those mockups into styled pages.
The “Fix the broken pieces” stage
So far in my work at the office and in RMU, one consistent theme is that the thinking you put into the mockup stage will reveal flaws in the existing plan or implementation.
In this case, there were unfinished pieces of the app; features that were clearly intended but not built out, like an Announcements feature and a Puzzle Details page. The lesson here (intended or not) was that in order to move forward, you’ve often got to move back and clean up a little bit.
Once this was done, the stage was set for some actual design.
The “create assets” stage
This one seems optional, and Photoshop skills are not necessarily required, but I was sure glad I had them. I didn’t do any high-fidelity mockups or anything, but I did create my logo & background images, and tweak icons.
I also used a nifty little site called Stripe Generator to create repeating stripes, which is usually a laborious process involving Illustrator and/or Photoshop.
Last stage: Styling
OK, enough playtime. Now it was time to jump in and get my hands dirty. And then–
Haml, WTF?
I jumped into the project and immediately came to a screeching halt. Instead of my more-familiar ERB syntax, the views were in Haml.
Immediately, I was faced with 1) converting all the views to ERB, or 2) Learning enough Haml to get by. I figured that converting the Haml to ERB would require nearly as much research as just keeping it, so I decided to stick with Haml.
This was itself a crash course, and I came away both impressed and frustrated with aspects of Haml.
What makes Haml so great?
There are no closing tags. It has a Ruby-esque syntax, and it’s much easier to drop in native Ruby than in ERB. It uses CSS-style selectors. It’s terse, clean, and easy to read, once you’ve got the hang of it.
There apparently used to be serious performance issues, but they’ve since been ironed out, and Haml is about on par with ERB for speed in compiling to HTML.
What makes Haml frustrating?
There are no closing tags. That means that you’re in the realm of “significant whitespace” in your views. Personally, I don’t like having my views fall apart and spit an error at me because of my indentation.
Haml is optimized for cleanliness, not flexibility. Perhaps the most damning thing about Haml is that you can be almost certain that you’ll need to fall back to ERB (or have Haml interpret HTML via plain text, ugh) eventually for some edge case. If it works in HTML, it works in ERB. Not so with Haml. You’ll either wind up twisting something straightforward into knots to fit into Haml’s syntax, or fall back to ERB.
Would I use Haml again?
Basically, Haml is a lot more fun to work with than ERB, right up until it’s much, much worse. One surprising thing is that you don’t have to choose; you can use Haml most of the time and use ERB for your edge cases.
Yes, Haml did add a significant amount of time to my project. But depending on the project, it’s likely I’ll use it again in the future.
Once I got the hang of the markup, it was time to start styling my project. I wasn’t sure where to start, having never styled a page from scratch before.
But after my first go-round with CSS, I started getting really frustrated.
**Does CSS Suck?**
That’s a total troll question, so I’ll rephrase:
How did people do layout before Compass & Sass?
We had a pretty heated debate in the #rmu IRC room about whether CSS sucks. The sticking point was that an educational context basically isn’t a place to say that any given tool sucks.
But it’s a good question: Does CSS suck? Greg Brown has created a layout framework for PDFs in Prawn, which taught him that creating a flexible layout is a hard problem, and CSS has spent 10 years doing a pretty good job of solving that problem.
But Ruby developers used to having a universe of capability and spoiled on the “principle of least surprise” get a rude awakening. CSS is a crappy programming language, if that’s what you’re expecting.
With CSS, I kept having the experience of “tweak, tweak, tweak, KABOOM”. A small change may mean nothing, or that your layout collapses entirely, or your signup form is wrecked because of a seemingly unrelated change for another page.
That said, there are some frameworks that turn CSS into much more of the programming language that developers expect.
In fact, when it’s all working together well, I’d say that Haml/Sass/Compass/Blueprint combo is a pretty friendly way for developers to do design. Here are the pieces, broken down:
Sass: CSS, but like, for programmers. It adds some powerful features to CSS:
Variables (e.g. $light-gray: #f7f7f7)
Mixins (e.g. @include bordered-table)
Nesting & Inheritance (I didn’t use these much)
SCSS: It’s Sass but with CSS syntax. Basically, Sass is for people who really hate braces and semicolons, and SCSS is for people who want CSS compatibility. SCSS seems to have become the de facto standard for new Sass projects.
A very minor gripe is that because of the syntax change, a lot of the tutorials you’ll see will be hard to understand in SCSS, as Sass was the preferred syntax at the time they were written.
Compass: Compass doesn’t do a good job of delineating its role from that of Sass. The fact is, the majority of the benefits they claim come from Sass, but the additions Compass brings make it absolutely indispensable to me now:
The ability to define and mix in partials
Auto-compiling for Rails projects
A whole bunch of pre-defined (and easily configurable) mixins.
Compass gives you a nice framework to start from, and a project folder that is relatively easy to keep clean and organized (though I did manage to mess that up later).
For an example of the benefits of Compass/Sass, if I wanted a drop-shadow and border-radius on a div, first I’d import the partial:
@import "compass/css3";
Then I’d include the predefined mixins in the style for that div:
Combined with the ability to define your own mixins, this is a huge time and sanity saver.
Auto-compiling stylesheets is also awesome, because it means every time you save a change, you get real-time feedback, as if you were editing the CSS directly. It also recompiles each time the server is restarted, so every time you push an update to Heroku or it spins up your instance, it throws an error while the stylesheets compile. I’m not sure how to get around this, but it’d be irrelevant if you had a dedicated box that didn’t spin up/spin down like Heroku.
Blueprint: Blueprint exists independent from Compass, but it almost seems like they were destined to be together. It includes some decent defaults for a Grid system, forms, and typography.
960gs vs. Blueprint Grid
Basically, a grid system is a way for you to define the horizontal layout of your pages so they don’t look crappy. They pick a default column count of 24, so you can cleanly split a page into 2, 3, 4, (or 6, or 8 ) columns. It’s configurable, but the default seems like something I wouldn’t be likely to change.
Brian Hogan (PragProg author of “Web Design for Developers”) recommended I choose 960gs over Blueprint’s grid due to 960′s better documentation. However, I hadn’t realized that Compass includes mixins for Blueprint’s grid system.
So I chose Blueprint grid.
To demonstrate how awesome Compass is, I’ll go back to Compass mixins:
Let’s say I want to create a simple 2-column layout with a header, footer, main area, and sidebar. This is a pretty basic request, but handling this in CSS requires a lot of careful pixel calculation and repetitive typing.
Here’s all you’d need to do it with Compass/Blueprint:
What amazed me is that I was able to get the project completed despite the initial uphill battle of learning these tools. I’ve only scratched the surface of all the amazing things you can do with Sass, Compass, Blueprint, and their associated mixins, but I look forward to using them more in the future.
Seriously, how cool is it to be able to take something from a thought to full visual execution?
or: How RMU is teaching me to stop making excuses and get stuff done.
Note: I’m going to break this into several posts about the philosophical and technical learnings from my Ruby Mendicant University Web Development course:
Much like the mafia, one doesn’t graduate RMU, you just get pulled in deeper. There are course offerings for alumni that range from more advanced Object-Oriented design practices, writing skills, statistics, and more. After a few months of relaxing mixed with a little bit of mentoring and casual participation, it was time for me to dig back in for the first Web Development course.
This time Jordan Byron (@jordan_byron on Twitter) ran the course, and it was his first time teaching. Anyone who has endeavored to tutor, advise, teach, or mentor knows that this is about an order of magnitude harder than you’d expect.
It was clear that Jordan cared deeply about helping us succeed, but that didn’t change the fact that everyone involved was biting off a bit more than they could chew. But for my part, Jordan’s help meant the difference between success and failure, and I learned a great deal thanks to his oversight and involvement.
For me, I’ve been learning Ruby and web development mostly by myself in my spare time for the last couple of years, and the sudden boost you get by having guided, time-bound projects is staggering. Even having been through it twice, it’s tough to imagine learning so much in less than a month.
Where I started from:
I had zero experience with CSS or true web design before this course. While RMU students must pass a Ruby-oriented challenge to get in, setting a baseline for Gregory Brown to work from, no such bar existed for the Web Development course.
This put Jordan at a bit of a disadvantage compared to the other courses offered within RMU. I showed up with no existing skills, expecting to be tutored in the most basic aspects of styling web applications.
The course:
The course itself was tough. Here were the requirements, roughly, in my words:
1. Submit an existing project for peer review, and review at least 3 classmates’ projects. Keep the discussion relatively high-level, more about frameworks, challenges, etc. rather than implementation details.
2. Take an existing project from barebones functionality to a fully styled site.
3. Create a geo-oriented project using Google Maps or similar geo API.
For me, step 2 took the lion’s share of the time. As it wound up, this list was a little *too* tough, and relatively few (or perhaps none?) completed all the requirements. The session was deemed a good pilot for future sessions, and a lot was learned on all sides.
“Uh oh, I’m gonna drown.”
There wasn’t a lot of additional instruction. There was a goal, and a list of potential resources and tools (put together by Jordan and augmented by the students). Jordan’s work is also open-sourced, so it was possible to go see how he solved similar problems if you were willing to dig into the code, though I discovered this a bit too late.
I quickly realized that I was already in over my head, and this “sink or swim” course would likely see me fail unless I drastically upped my output. For a relatively experienced web developer, this would have been 5-10 hours a week.
But like the core course, I found myself far enough behind that I required about 20-25 hours a week to catch up to where I should have been in starting the course. I’ll talk about why that may not have been such a good thing in the final post.
First assignment: Peer review
The first assignment was straightforward, simple, and fun. Our job was to post some work we’d done, ask questions about it, and comment on the work and questions of our peers.
I wound up commenting on all but two of my classmates’ projects, and hoping in vain that I’d get back around to the other two. I learned a couple of things that I was immediately able to do to improve my site, and saw some cool implementations that others came up with.
I did have to run out and research a little before I felt comfortable answering a lot of the questions. All in all, the first assignment was a bit time-consuming, but not particularly difficult.
Second assignment: Style a website from scratch
I’ll cover this at length in my next post. Basically, it took all but the first few and last couple of days.
Third assignment: Geo-aware application
I basically flubbed the final assignment, having left myself with less than 48 hours to complete it. After Jordan cleaned up my messy code, I got a basic mapping tool running using GeoKit to geocode an address, and Google Maps to display it. All in all, not my finest hour, but I’ll cover a bit of what I learned in the final post.
In Part 2, I’ll go through some of the implementation details, and what I had to learn in order to take a webapp from a barebones implementation to a fully-styled, “invite your friends” site.
I’ll also ask the flame-baiting question, “Does CSS suck?”
“You’re obviously talented and sharp. But I have no idea how to use you”.
About the third time I heard this from different bosses, I felt like an utter failure. Why would someone as capable as I felt be so woefully misunderstood and underutilized?
As it turns out, it was 100% my fault, and the fix isn’t all that hard.
As I outlined in another post, a coworker shared the secret of his relatively stress-free work environment (the same environment that stressed me to the point of physical illness). He was a free agent. He was only there because he wanted to be. He woke up every day and made the decision to come to work because it was what he wanted to do, not what he had to do.
But I couldn’t just be a free agent. I didn’t know where to start to develop that sense.
As it turns out, a different piece of advice he gave me later was the missing piece, the building block that earns you that free agency. I was going around in circles worrying about how I, a brand-new programmer of less than 6 months, could contribute to our large and intimidating project. He told me this: “I’m looking for people who will just grab a shovel and get to work. If you can do that, great.”
On the marketing side, I’d spent so much time trying to convince people that I had good ideas that I never bothered to just get things done. It didn’t help that the department didn’t have any clue of what we should be getting done. We just knew we needed big ideas that could recoup our ever-expanding millions in losses.
But in my interactions with the development team, they weren’t interested in ideas. They were interested in execution.
This flipped my whole world upside down. Actually, it had been upside down my whole life, and this flipped it right side up. I realized that I could simply “grab a shovel” and start helping the customers by adding small improvements to the code. I would just dig in and add copy changes in one place, fix small things in another, or add features.
I had needed decent e-mail support as a member of the Marketing team for years. So I set about adding it in myself, and had it done in a matter of a couple of weeks. I asked our lead developer, “This was so easy. Why didn’t we have this sooner?”
His reply was a bit coy: “Because we didn’t have you to build it.”
That was the most liberating feeling in the world, because I was proving value to myself and to anyone who cared to pay attention.
The same fear that kept me from achieving at work now holds me back from contributing to open-source projects: I spend so much time being intimidated or hoping someone will tell me what to do that I would rather wait than start trying to contribute any way I can. I still let this happen too often, but from here, I plan to just dig in, find something to fix, and get it done.
In my new day job, I come in every day and try to grab a shovel and get to work. No one has expressed a lack of knowledge of what to “use me for”. Rather, they know that I am going to be digging, so now the only concern is to make sure that I’m doing so in the right place.
The process isn’t complex: I keep a list of the things I want to get done. I check in with my coworkers and tell them what I want to do for the day. At the end of every day, I know how I feel about what I accomplished. There’s no technique, I just know whether I feel good or bad about a day’s efforts, and so I strive to push a little harder so I can feel good at the end of every day.
I also keep my eyes peeled for places I can get things done and just go for it. I spent so much of my life waiting for permission that it’s a bit jarring to just start doing.But here’s what I learned: if you require permission for everything, I can guarantee you’re going to waste your talents and your life waiting.
So now, I try to take a risk, go out on a limb, and do something good without permission once in a while. It gets my heart racing to know there could be some negative reaction, but it seems like those are the times where I get real traction on the most important things.
If I’m hiring someone, I’d rather pick up someone holding a shovel than someone with a sign that says “I have some great ideas about digging if someone will just give me a chance.”
Stop talking about it. Grab a shovel and get to work. I promise you’ll be happier.
It’s been nearly 2 weeks since I completed my Ruby Mendicant University course and joined the growing ranks of RMU alumni. I’d hoped to put together my thoughts earlier, but the exhaustion has just worn off.
Being on the extreme “novice” end of accepted students, the experience of RMU was more trying (and tiring) than perhaps some others. But experience or no, it’s pretty intense. On the other side of the crucible, I find myself with several lessons I’d managed to escape until now. I thought they’d be worth sharing.
Lesson 1: When you see opportunities, don’t forget opportunities to help.
For those who aren’t familiar, Gregory Brown is a profoundly skilled, pragmatic, and good-hearted developer who saw a big hole in the education of Ruby developers: too many reach an intermediate level and are unable to make further progress.
I must admit that the conniving marketer in me would have seen a very easy way to extract money from the wallets of these budding developers. But Greg’s instincts being more of the “change the world” variety, he saw an opportunity to experiment with the idea that open source ideas can change the face of education.
People that join RMU are taking advantage of one of the best learning opportunities available in the world of programming, and it’s completely free to participate. I hope with that opportunity comes a sense of a longing to help. You may have earned a spot in the program or alumni status, but it’s humbling to think that the community has bought your way into a first-class education.
I think Greg’s passion for contribution to a larger cause is inspiring and contagious. RMU is slated to launch over 100 open source projects in the next year, and there will be ample opportunity to contribute (financially, by volunteering, or on the projects themselves).
Lesson 2: Find an excuse to take the first bite of the apple.
I don’t know if it’s just me, but I imagine that many new programmers are intimidated by the world around them. It sometimes reminds me of what it feels like on the first day of high school. The projects are big and solve complex problems, other programmers are megageniuses, and established community members seem as if they had been assigned that status by deity. Also, some of them have moustaches.
It was a fellow student, Anita Kuno, who worked with me to crack open a relatively complex project and dissect it. At first it looked impossible, and alone, I would have given up. Anita’s advice was to find something I understood and latch on. I did, and was surprised to find a piece I could get my brain around. Then, working my way outward, I figured out the purpose of the program and got to understand its architecture.
That’s the nature of programming, I think, and RMU was the first to bring that out for me. There’s no reason to be intimidated: it may take a little extra work, but it’s not hard to find a way to get your foot in the door.
Whether facing a difficult problem with a blank sheet of paper or a complex project that seems impenetrable, the big revelation for me was “OK, so I can’t solve this. So what can I solve?” After that, it’s just a matter of time and work before the solution unfolds, and it’s profoundly gratifying.
Lesson 3: A working product comes first.
I’ve heard it pontificated, but RMU drilled this into my brain: Priority 1 is to ship. Before RMU, I had 3 or 4 half-products pushed in a mutant state with no ability for people to interact with them.
During RMU I shipped 2 functioningproducts. They’re proto-sites with no CSS and limited capability, but I learned an incredibly valuable lesson. You should be in a big hurry to make something that sees the light of day, solves a problem, or makes someone smile.
That’s not to say that sloppy code is OK in shipping products; that’s just douchey, especially to newbies like me. But prettifying beyond the point where someone else could read, interpret, and contribute on your project seems a lot less valuable than getting another awesome feature or product shipped in that same timeframe.
Lesson 4: Do not underestimate the power of community.
RMU is not a solo gig. The people I’ve interacted with have taught me nearly as much as Greg. I believe it’s actually engineered that way.
However, I don’t think even Greg anticipated the quality or quantity of response he’d get from community members. The people that have gathered from around the world actively participate in IRC chats, cross-project contribution, impromptu projects, and even contributing to the core of RMU itself… it’s staggering to me.
It’s also been great to see the alumni stick around to help the incoming group with questions and moral support. The community is the culture and the brand of RMU. Ultimately, this community will surpass Greg as the “owner” of RMU (and he’s no stranger to this concept after running several open source projects).
The idea and pitch for RMU was strong enough to attract a passionate group of people, but it’s the people that bind to each other and to a shared goal. These are friends from all over the globe that I plan to stay in touch with indefinitely. How cool is that?
I don’t know what I’m going to do with the rest of my life, but I hope it leverages the good that a passionate, engaged group of people can do.
Lesson 5: Don’t listen to DHH.
OK, that was a blatant poke in the eye. But DHH and Jason Fried would tell you never to launch a product without a business model, and I imagine they’d tell you never to launch a community initiative without a sustainability model.
But if Greg had waited until he had a solid “business plan” behind RMU, it may never have gotten off the ground, leaving the situation in the world exactly as it is. Or it would be drastically different, scaled down, or less ambitious in its goals.
Instead, RMU has already helped dozens of developers “level up”, and created an incredibly tight and productive global community, with tremendous upward momentum.
Sometimes you just have to take a breath and jump, and figure out how to land safely on the way down.
Greg’s fearlessness in tackling the problems that RMU confronts is inspiring. By nature, I’m a cautious cat. I measure two hundred times and cut once. I would rather not participate than risk rejection or looking stupid. I was almost too afraid to become a father. Why should I be afraid of any of that? Being afraid is not how you change the world.
So I guess that’s the real lesson 5: Not just ignoring, but obliterating fear is the only way I’m going to make a dent in my life or in the world.
Thanks to Greg, Jia, Jordan, and everyone that’s contributed to RMU so far, and I hope to pitch in when and how I can.
There’s a nebulous space in courtship, where “casual” becomes “serious”, and words like “dating” give way to heavier terms like “relationship”. Remember the first time you called someone a “girlfriend” or “boyfriend”? Remember the awkwardness of saying it? It’s like trying on a shirt that doesn’t fit right.
In that same vein, I’m a Ruby programmer. That’s the first time I’ve ever said or written that. It feels just as awkward and forced as the first time my now-wife rolled her eyes at me when I tried to label her as “my girlfriend”.
So as a sort of follow-up of my last 2 posts, I want to express utmost gratitude to the people who do the hard work of remembering the inner turmoil of the newbie and creating help, handholding, and support for the profoundly intimidating process of learning to program. Some of them have been friends and colleagues, but many have helped by publicly sharing their knowledge.
It took me 18 months to assemble this list. I hope that by collecting these resources in one place, someone out there that’s struggling like I did (and still do) will have a shorter path through the inevitable tough parts of learning to program.
As a very green Ruby developer (dabbling with C# and Python), this list is going to be pretty heavily biased. If you want to see anything added, hit me up in the comments or on Twitter and I’ll try to keep the list updated.
Zero Experience
To people with no programming experience, it looks like a black box, and the number of people that holds true for saddens me. Anyone who wants to someday run a business should understand the basic precepts of programming, just like anyone planning to drive across the country should know how the basic components of a car work together.
Learn to Program by Chris Pine: When my friend Jarom showed me this book, it was the start of a new, happier course in my life. I can say without hyperbole: everyone should read this book. You’ll know after a couple of weeks of reading and coding whether it tickles your fancy. The book is free online, but buy a copy. I’ve given two away to people who are happier because of it.
Learn Python the Hard Way: Zed Shaw (@zedshaw) is a controversial figure, because like me, he’s got a big mouth, and his intentions are often misinterpreted (sometimes, I think that’s his actual intention). But there’s no question that he’s given and given to the programming community, and really understands and cares about new programmers.
Python for Non-Programmers:It’s a bit of a cheat to post a list inside a list, but like Ruby, Python is a great language for new programmers, and this is a great place to get started.
Ruby in 20 Minutes: It’s not the best tutorial out there, but it is lovely to look at and should give you a hands-on feel of what it’s like to write code in Ruby.
Humble Little Ruby Book: Jeremy McAnally, who is a dog that wears glasses, wrote a delightful book for Ruby beginners. It’s a great supplement to Chris Pine’s book, and chock full of quirky personality.
Newbies
I still count myself among the newbies, but that protective cocoon won’t hold me much longer. This is the time when you can write and read straightforward, simple code, and ask questions like “what the heck is a lambda?”
Ruby Koans: The brilliant, incomparable Jim Weirich came up with a way to train semi-new developers on the joys of Test-Driven-Development. The Koans comprise an incredibly clever, fun interactive programming puzzle. I failed to complete the last full exercise, so I need to go back and try again soon.
Ruby Inside: Peter Cooper’s blog is the definitive Ruby news source, and I’ve discovered many, many helpful tips and articles. Plus, Peter is an amazingly cool guy who wrote the book…
Beginning Ruby: From Novice to Professional: This is the book that helped me take the step beyond Ruby’s scripting capabilities. Peter Cooper’s writing style is delightful, and the book came highly recommended, with good reason.
Roadmap for Learning Rails: If nothing else, Wyatt Greene’s Techiferous blog reveals how deep the rabbit hole goes when learning Rails. Most people learn Ruby to get into Rails, and this is a good plan to get your first project built if that’s your goal.
Railscasts: Ryan Bates is the Karl Malone of the screencast world: he just delivers. There are few meaningful subjects he hasn’t yet covered. He’s no-nonsense, giving you just the short-and-sweet facts, then moving on.
Teach me to code: Charles Max Wood is an up-and-comer, with well-done screencasts (as well as podcasts and interviews) for coders of all skill levels. It’s nice to get a different viewpoint, and he tends to inject more depth and personality into the topic at hand than Railscasts.
Pragmatic Programmers: What can be said about PragProg? It’s the best independent tech publishing house on the planet. You can very, very rarely go wrong picking up any book out of their library.
Rails Dispatch: Engine Yard has spun up a great Rails blog with posts and screencasts by Rails luminaries like Yehuda Katz. It’s not always newbie-friendly, but the screencasts are worth a watch.
But who can I ask for help?
The programming world is full of people who, while busy, are happy to help new programmers. Here are a few places to find them:
Google: Google is the king of the hill, and answers about 80% of my questions. Please, don’t bug people with questions that a quick Google search would have turned up. More importantly, don’t be embarrassed to ask questions that Google doesn’t answer for you. Where do you think Google got those answers in the first place? Your question could help future newbies get out of the same jam!
Stack Overflow: Don’t get sucked into the BS “communities” that charge to answer questions. Look for solid, community-driven Q&A sites to get your programming questions answered.
User Groups: Aside from Google, joining a local User Group is the most valuable thing you can do. They’re filled with people who have struggled just like you. Even if you work with other developers, it’s extremely helpful to get outside of your own circle once a month. And someday, you’ll be able to contribute back to the group.
Hackfests: I went to a Hackfest and felt so out of place that I snuck out the back. Don’t do this! Say you’re new and ask if you can pair with someone (likely, this will just be watching them code). Better yet, bring a dinky, sad project of your own and don’t be embarrassed to ask questions about why it’s not working!
Conferences: If you fall in love with programming, be prepared to attend 3 or more conferences a year, and not corporate-driven booth-babe-fests like CES or Macworld. Conferences run by and for the community are so packed with insight, I’m still absorbing lessons from one that I went to 6 months ago.
Mailing Lists:Historically, mailing lists are a nightmarish, labyrinthine mess. But then Google came along and helped them regain sanity. For most projects, you’ll find answers (eventually) in Google Groups.
Freenode IRC: Sooner or later, every programmer has to become familiar with the “crazy old grandpa” of the Internet: IRC. It’s dated, painful to set up and use, and oozing with geek credibility. Hackers love it because it can’t be regulated, controlled, or put out of business, and it’s a key form of communication for many open-source projects. Have a question you want answered? Get to know Freenode.
Rails Mentors: RailsBridge has created a place to learn and eventually, to teach. Pick a topic and find a mentor who will help you, at no cost.
Twitter: I’ve curated what I think is the world’s best list of Twitterers. Rather than list them here, just follow everyone I do and gradually unfollow the people that annoy you. You’ll connect with some astonishingly bright, talented, and helpful people.
Ruby Mendicant University: Lastly, Gregory Brown’s RMU has been like strapping a rocket engine to my learning process. The community has been unlike anything I’ve ever seen. I cannot thank Greg enough for dedicating time to educating people through the hardest phases of learning to program. Please support this endeavor when he’s accepting donations again.
If I’ve missed anything, and I assuredly have, leave a comment below or hit me up on Twitter (I’m @tehviking).
About 18 months ago, I had a life-altering conversation with someone who showed me the magic-wand-like powers of Object-Oriented-Programming, and it didn’t take very long for me to fall madly in love with writing code and making things. It was like writing, but then making the words literally dance.
Since then, it’s often been a bit of an uphill battle, requiring all my fortitude to stay on the learner’s path instead of retreating into places where I can feel competent again.
While I now feel like I’ve made it across the most difficult chasm, I think we leave a lot of people behind somewhere along the way, or intimidate them out of starting at all.
I believe this is a cultural problem that is going to start repairing itself as programming becomes more mainstream, but there are things you and I can do right now to help.
From a newbie’s perspective, here are 3 reasons why programming culture is frightening, and some ways to make the culture more welcoming:
1. No one seems to be able to remember the embarrassment of being a newcomer.
It’s not that experienced coders don’t care, it’s that most people either live and breathe code, or they have zero interest in it. I think most programmers and non-programmers assume that if someone has an interest in coding, they started in junior high, and were fully onboarded by a CS program in college.
That’s no longer true, and it shouldn’t be a surprise that many are now cross-training from backgrounds of all kinds, especially those that have a lot of contact with programmers like designers, writers, and entrepreneurs.
Sadly, it’s still somewhat rare for someone to start learning to code out of the blue. So those of us that are new are far enough between that it can be easy to feel like the dumb kid in class, and that it’s best to keep quiet lest we be found out.
When I have asked questions, I’ve often immediately regretted it, feeling like an idiot. I ask the wrong question or in the wrong way, and the experience is deeply embarrassing.
I believe if every experienced programmer dedicated one blog post a month to a “newbie question”, or one evening to seek out someone new and answer their questions, we’d have a profoundly different culture.
Most importantly, when stupid questions are asked, be patient and perhaps share that you were once where they are now. Help them undertand that there really isn’t anything to be embarrassed about, and if asking the wrong question exposes some underlying misunderstanding, take the time to correct it.
2. Newbies can’t understand a word you’re saying.
Programming, more so than almost any other profession, is almost completely opaque to outsiders, due to a high level of insider jargon, even for people who work with computers. A year and a half on, I often run across conversations that make my head spin.
Generally, programmers are looking for something interesting. And many, in looking for new tools, technologies, or boundaries to push, don’t realize how intimidating it is for new programmers to see or hear these conversations whizzing by six or seven levels above them.
I’m convinced that this fortress of jargon is one of the reasons there are few women in programming. It’s great for guys: you suffer the paddlings of stupidity for a while, and then make it into the fraternity of coders.
But this “red rover” mentality doesn’t jibe with the mental models of most women I know, and it requires a very special kind of adventurer to be willing to defy this tradition, like the girls on my high school wrestling team.
This is a tricky one, because speaking in programmer’s jargon is a huge timesaver. But every once in a while, remember that many people don’t know what you’re talking about, and take a moment to explain, include a footnote, or even link to a Wikipedia article about one of the arcane things you’re discussing.
3. The truth is out there (somewhere), but so are a lot of other things.
One of the most frustrating things as a newbie is that it takes an incredibly long time to find answers to simple questions. I wind up using a hodgepodge of various methods found via Google to solve almost every problem.
Often, I’ll get so stuck that I get profoundly discouraged, feeling as if I’ll never catch up and acquire the knowledge to be decent at this. If only there were someone to ask!
Nine times out of ten, I’ll eventually stumble on the correct answer and the victory is that much sweeter. But most of my struggles are small enough to an experienced developer that having someone to ask questions would have accelerated my learning dramatically.
Ultimately, “shut up and code” is a great (and sometimes the only) way to brute-force through problems. But for many, having someone (preferably multiple someones) around to ask can make the difference between giving up and seeing it through.
Be that someone. Be the one to welcome new programmers (and entice non-programmers) to the joys of coding. Join a local Users Group. Jump into online discussions. Put a note on your website that you’re happy to take questions, even if you can’t answer them all.
You’ll enrich the lives of others, because programming, as you know, is an incredibly rewarding creative pursuit, and having more people at the party is good for everyone.
Who knows… maybe that new developer will wander into Hollywood and help make a movie that doesn’t portray programming in a completely ridiculous fashion. And in the end, isn’t that all programmers are asking for?
@rowleypress K, I'll check in tonight. It'd also be great if you can add me as a contributor on the Heroku app but I can show you how later.
8 hours ago
@rowleypress Paperclip is set up to handle it easily. Check out the docs I linked to. I'll be out of touch while I drive to Vegas today.
8 hours ago
Apparently emailing documents to Kindle now works for iPad, yay!
8 hours ago
November 10th, 2009 marked a pretty dramatic turning point in my career. The startup I worked for was in a tailspin, and a friend who’d escaped invited me to visit his new workplace for a meeting of the Utah Ruby Users Group.
or: How RMU is teaching me to stop making excuses and get stuff done.
“You’re obviously talented and sharp. But I have no idea how to use you”.
It’s been nearly 2 weeks since I completed my Ruby Mendicant University course and joined the growing ranks of RMU alumni. I’d hoped to put together my thoughts earlier, but the exhaustion has just worn off.
There’s a nebulous space in courtship, where “casual” becomes “serious”, and words like “dating” give way to heavier terms like “relationship”. Remember the first time you called someone a “girlfriend” or “boyfriend”? Remember the awkwardness of saying it? It’s like trying on a shirt that doesn’t fit right.
Recent Comments