Mentorship-Driven Development

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:

User groups: I cannot overstate how much these have helped me. They dot the land. Attend one.

Mendicant University: Free online courses for intermediate Rubyists. It’s close to my heart.

Screencasts: I recommend Railscasts (free) and PeepCode ($)

Remote pairing: Evan Light just created a site for this.

Stack overflow: I mostly just lurk, but there are a TON of smart people waiting to help here.

Rails core code: Don’t be afraid of it. Dig in and see some well-crafted code.

Test suites: This is my preferred method of seeing how you’re expected to work with a codebase.

Code reviews: Go make a mess. Then let an experienced dev help you clean it up. This is powerful.

Open Source Software projects: A patient maintainer can make a great mentor. OpenHatch is a neat place to find one.

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.

RMU Round 2: What I learned

Note: This is the third of several posts about the philosophical and technical learnings from my Ruby Mendicant University Web Development course:

Part 1: About the course & what it was like

Part 2: A first-timer’s process of styling a site

Part 3: What I learned from the course

 

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.

RMU Round 2: Process, Tools, & Techniques

Note: This is the second of several posts about the philosophical and technical learnings from my Ruby Mendicant University Web Development course:

Part 1: About the course & what it was like

Part 2: A first-timer’s process of styling a site

Part 3: What I learned from the course

 

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:

@include box-shadow;
@include border-radius(10px);

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:

.two-col {
#container {
@include container; }
#header, #footer {
@include column(24); }
#sidebar {
@include column(8); }
#content {
@include column(16, true); }
}

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?

That’s not to say the road was perfect. In my next post, I’ll talk about the rest of what I learned, including my EPIC FAILS.

Ruby Mendicant University: Round 2

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:

Part 1: About the course & what it was like

Part 2: A first-timer’s process of styling a site

Part 3: What I learned from the course

If you’ve been following this blog for a while, you’ll already know that I participated in the September session of Ruby Mendicant University’s Core Skills 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?”

Why it sucks to be a new programmer (and how you can fix it)

via UnconfessableIdeas.com

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?

Why the pundits are wrong about Google I/O

Google’s personality can be hard to peg. Which might be why pundits and industry analysts are keen to try to affix a label of “the new Microsoft” or “the new Apple”, or other such nonsense to the strange machinations going on at Google.

Yes, Google sprawls like Microsoft. Yes, they are driven by a nearly-religious zeal like Apple.

But this week, they came into their own, and it’s very exciting stuff.

Everyone seems focused on the thought that Google stepped out at I/O as an alternate-universe Apple, with charts of Google’s anti-Apple stable of products. TV! FroYo Android phones! Mobile Ads! Music stores!

But developers saw a different story unfold at I/O.

Even though Steve Jobs is convinced that Google is trying to steal Apple’s lunch money, they’re not even at the same playground. While Apple is busy making technology desirable and friendly, Google is about the work of making that technology smarter.

Google’s I/O conference highlights

Here are a few examples of company-defining developments at Google IO:

Chrome App Store

They’re serious about the browser as OS.

What it means: Google sees operating systems as a dying art. To them, the OS is just a means of connecting together hardware so you can access cloud-based services. Unlike Apple or Microsoft, Google’s betting big on the shrinking footprint of OSX, Windows, and even Android.

If Google gets its way, the OS is going to be as obscure and irrelevant to you in the future as the underlying operating system of your DVR is now.

Google Storage for Developers

Pretty much anyone I’ve met using Amazon’s S3 storage has also used EC2 computing. And it’s a huge pain in the ass. So, although Google Storage for Developers is not too different from S3, its ties to Google’s App Engine are going to change things. Getting an application up and running used to mean setting up a machine with an operating system appropriate for your dev environment, installing database software, getting version control, blah, blah, blah…

Often, this involved hours (or tens of hours) of work before it was feasible to even start coding. Google App Engine is the opposite: Just submit your Java app (for me, JRuby), or Python (hello, Django) and boom, live application. And scalable, unlimited pay-as-you-go storage means that Google can now play the role of IT operations. This concept is not new (Heroku provides a friendly layer between Ruby and Amazon S3), but it’s going to become the basis for thousands and thousands of new applications, since any developer can now afford to turn an idea into reality.

Google Web Font API

Ask any CSS dev/designer about web font standards, and you’ll get a :rolleyes icon (given that you ask over chat, of course). Between variations in user-installed fonts and licensing issues in others, you wind up with about 4 or 5 fonts that are truly safe to use on the Web. That’s insane!

The Web Font API is a no-brainer, but only Google has got the cash and chutzpah to put it out there. Designers get a wider array of safe web fonts without a ton of work. Font designers can get exposure if Google decides to add their work to the library. Users can (potentially) get better-looking websites. This is so desperately needed and immediately useful that my former employer went from “never heard of it” to “essential to our site” in one day.

Prediction API

People are calling this “Skynet v.0.1”, and there may be good reason: it’s basically API access to learning computers. (Aside: this makes me think of Arnold Schwarzenegger saying “learning computer” and “neural-net processor”.)

It’s so out there that I still don’t know how it works: but as I understand it, it’s this: You feed it “Red, yellow, blue, red, yellow, blue, red, yellow”, and it’ll come back with “blue”. Or “one, two, three,” and it’ll come back with “four”.

This is scary stuff to me because it seems to represent the first step toward domination by our Cylon overlords, but there are lots of immediate applications. Historically, recommendation engines have been the exclusive territory of deep-pocketed e-commerce sites, but now any developer can have access to the thinking of the human-computer hybrids that are suspended in goo at Google headquarters.

Latitude API

There are other location-based services. And there are APIs to those services. But the Latitude API is so powerful and dead-simple to use that even I can do cool stuff with it, and I’m a neophyte. It’s a REST API that lets me feed in (or ask about) a person’s location, and get back everything from direction to altitude.

Location-aware was already a big deal (Apple, for their part, is doing great location-based API work for developers on the iPhone), but Latitude makes it universal.

What does all this mean for the future?

No one knows yet, since Google has a habit of throwing things to the wall to see what sticks. But you can look at the services above and mash them up with other apps: Using my location info from Latitude & Google Maps, an app checks Yelp for local listings, then references my Foursquare history and runs the results through the Prediction API to see which restaurant I’m most likely to want to eat at, then locates my friends in the area, and uses Twilio to auto-text them to ask them to lunch. If you had the desire and the chops, you could host that on Google App Engine for next to nothing.

With the depth and complexity of what Google churns out from day to day, I bet they have a tough time not looking down their noses at Apple’s work as child’s play. Oh, you have facial recognition in your photos app now? That’s adorable.

And before thinking, “of course Google can do all this stuff, they’re humongous”, think of the kind of rabid passion and laser focus that is required to pull off ideas of this magnitude, no matter the size of the company. Microsoft can’t stop screwing up its own best ideas (Courier, we hardly knew ye) due to infighting among its teeming middle-management ranks.

The biggest mistake Apple could make now would be to try to hunt on Google’s own turf (i.e. heading into the cloud). Google was “born in the briar patch”, so to speak. They and Apple could accomplish so much by cooperating instead of kicking dirt in each others’ eyes, but that’s a topic for another article.

Here’s how I would describe the 3 companies:

Apple is a pyramid, like the Luxor in Vegas, with a large base of people who taper to support one beam of light, one man’s vision. And that’s great (until a successor is needed).

Google is a series of pillars. Their biggest one supports most of the weight, but they are constantly building other pillars. They’re all building in the same direction and with the same purpose, but they’re more loosely federated.

Microsoft is just a mess. That’s all. It’s clear they don’t understand why they were ever successful in the first place, and unlike most who don’t understand their history, they’re doomed to not repeat it.

Incidentally… did you see Google’s “Pac-Man 30th Anniversary” homepage recently? A playable, fully-HTML-graphics, pixel-perfect version of Pac-Man is an astounding technical feat (certainly beyond Namco’s own capability), not to mention a lot of fun. It’s meticulously programmed: Pinky’s trickier, more aggressive personality is intact, and ol’ Pac is slower while chomping on dots than when the lane is clear. Google knew that this icon that shaped so many of us as young geeks deserved no less a tribute. That may be more telling of their corporate personality than anything at I/O.