Yesterday, Chartboost hosted a presentation by Gregg Pollack, founder of Code School and Envy Labs. I found this event by joining The San Francisco Ruby Meetup Group.

The slides + audio recording can be found here: http://penxy.com/qeh

The talk Pollack provided was not very technical in nature. He mostly focused on general productivity, communication, and other soft skills rather than discussing hard skills. Therefore, the talk had a self-help or self-improvement vibe –as opposed to an academic one.

What I Learned

I didn’t plan on going into as much detail as I did in my previous event review because you can check out the presentation for yourself in the penxy link I already provided. However, the penxy recording failed to capture the last 2 out of 12 steps. It also missed the conclusion. I also like to ramble.

The 12 steps to be a better developer

1. Set expectation
2. Be mindful of your engineering background
3. Software development is a craft
4. Learn how to delegate and improve the system
5. Continue to learn inside and outside your company
6. Stay out of your comfort zone
7. Make friends and build relationships
8. Don't be afraid to ask for help
9. Learn to eliminate distractions and get in the zone
10. The most complex solution is rarely the best solution
11. Communicate visually
12. Understand what brings happiness

My (re)interpretation of the 12 steps

I think a lot of Gregg Pollack’s steps are good, a few are great, but a lot are poorly worded. Ok, they’re not “poorly worded” per se, but some seem a tad cryptic. It’s almost as if Pollack picked partially enigmatic titles on purpose, allowing him to turn a 12-step list into a 1-hour presentation. Almost.

To be fair, I don’t think he has nefarious intentions, but I disagree with the wording of the 12 steps enough to motivate me to re-present them with different diction.

1. Pay more attention to communicating expectations

Everyone knows communication is important. Pollack takes the time to suggest you spend more attention on communication with clients with a focus on expectations. Pollack posits that you think about some failed projects and consider that a possible (perhaps probable?) cause of failure was mismatched expectations.

You can preempt this problem by obtaining client feedback more often, being geographically closer to the client, and by having someone on the client’s team become part of your team (as a liason, I imagine). By the way, Pollack often frames his ideas in the context of client-consultant relationships due to his experience running a consultancy.

2. Avoid criticizing people

Here’s another bit regarding communication: don’t forget other people don’t think like you do. Pollack specifically points out that engineers need to be cognizant of the simple fact that non-engineers think differently, and if you don’t account for the difference, then you may “kill collaboration.”

At this point, Pollack mostly discussed the problem of “diagnosing problems” and criticizing others. I actually started reading the oft-cited How to Win Friends and Influence People, and the concept of criticism is covered in one of the early chapters. Lesson learned: most people simply cannot handle criticism.

Pollack recommends rephrasing your criticism into additions to another’s ideas rather than subtractions. I think that’s a bit crazy, but what do I know? I admit my less-than-4 years of work experience don’t make me an expert in workplace communication. On one hand, I agree that cold-and-calculating communication may seem efficient to engineers, but it just sounds asshole-y to most people. In other words, learn some empathy skills and put them to use in the workplace! On the other hand, I think the technique of rephrasing criticism into “Yes, and …” statements involves too much hand holding, and you will fail to convey your points because they are too busy treating the diabeetus caused by all the sugarcoating (TIL: “sugarcoating” is only one word).

Before moving on to the next step, Pollack briefly discussed the awesome warm-fuzzies derived from good listening skills. I concur with his thoughts on good listening.

3. A good developer builds what others want

Why did Pollack include this step? This step was presented more as a way to help describe the role of developers, but it doesn’t really help you become a better developer in my opinion.

So what did Pollack say exactly? Well, he essentially said the customer’s needs come first, but he just worded it differently. He said it’s a developer’s job to take whatever canvas they’re given and make something awesome. He cited a Walt Disney quote about building things for the sake of others –not for yourself. He said a lot of things without providing examples of actions you can take to improve your quality as a developer. Boo. I guess his point is just that you should stop whining and get over yourself?

4. Delegate work (pretty straightforward stuff)

Everyone is familiar with cautionary tales about over-burdening oneself. Everyone knows you need to hire people to prevent you from tasking too many multis (so to speak). Everyone knows about the significance of delegation.

But section 4 of this talk was not wholly uninsightful. He provided an example of “doing the math” by talking about framing delegation in terms of hours saved. His example involved a snazzy company that hired a full-time barista to take care of coffee for everyone else. After guesstimating some numbers, Pollack posited that the 8-hour barista added 20 hours of development productivity at the relatively low cost of a barista’s wages.

WITHOUT barista: 80 employees x 1 cup of coffee per employee x 15 minutes of time used to get each cup of coffee = 20 hours per day spent on coffee (not an exact quote, but you get the point)

As a sometimes smartass-y skeptic, I take issue with his guesstimates. More importantly, I’d like to point out that the 15 minutes spent on getting coffee is probably considered as a break that employees enjoy. They will likely find a new way to take a break if you shorten the amount of time it takes to get their caffeine buzz. To be fair, this is something that Pollack acknowledges (somewhat) in a later section of his talk, so I shall holster my quick-draw revolver named Wise Guy.

5. Remember extracurriculars? Do them.

This is a two-parter. First, Pollack highly recommends attending meetups, seminars, talks, conferences, etc. that are relevant to software development. He also recommended further academic learning through resources like Code School of course. Second, your company should foster internal knowledge transfer via internal brown bags, “What I’m Working On Now” presentations, retrospectives, book clubs, planned pair programming, and even just eating meals together.

One tidbit that I found interesting was that Pollack said it’s worth mentioning to hiring managers and bosses that you like attending meetups and whatnot. Bonus points!

6. Embrace challenging tasks; avoid embracing trite crap

Pollack claimed that human nature causes us to embrace easy-to-accomplish goals and tasks such as responding to work emails. This can lead to traps where you feel productive by doing a lot of small, low-value tasks. To avoid these traps, plan your day around addressing the big challenges first –don’t procrastinate by scheduling the tough stuff after the easy stuff.

On a higher level, it’s important to embrace tough challenges for the sake of keeping your brain fit, keeping your skills up-to-date, accomplishing meaningful work, etc.

7. Nurture friendships with co-workers

Many forget that one way to make the developer community better is to make friends in the community. One way to make workplace collaboration better is to become better friends with co-workers.

At this point, Pollack quickly discussed introversion/shyness (as an audience member later pointed out, introversion != shyness). He provided some social skill tips like establishing personal goals to meet 5 new people per meetup, for example. When meeting new people, Pollack’s main tactic is to ask them about themselves. I think we’ve all heard that advice before. My take on it is that it works, but it still feels awkward until the conversation gets through the first few minutes of chilliness.

8. Ask for help sooner than later

We’ve all heard it before: if you don’t ask for help now, you’ll struggle with your issue for much longer by going solo. Pollack’s rule of thumb is to ask for help after trying to tackle a bug, obstacle, etc. on your own for 30 minutes. If a small problem is taking you more than 30 minutes to solve, it probably means you’re using the wrong approach anyway (i.e., you’re digging yourself into a deeper hole).

9. Take breaks and avoid synchronous communication

I like Pollacks claim that optimal work hours are 80% productive and 20% (unproductive) fun. Companies should embrace breaks and create a work environment that acknowledges employees’ “need” to check Facebook at work. But employees shouldn’t just take breaks while at the office, they should take breaks from the office by working at alternative locations such as coffee shops.

In step 9, Pollack also talked about abandoning synchronous communication like IM for asynchornous communications like email. He said IM can be a problem because it interrupts your train of thought whenever someone contacts you. Upon interruption, you’ll be tempted to check email or do other less intellectual work. It’s a bit weird to me that Pollack basically grouped “avoid distractions” with “take breaks” in step 9. They seem unrelated enough to warrant separation, but oh well.

10. Make sure you don’t over-engineer your software

It’s easy to get stuck spending lots of time on optimization, worrying about handling heavy load, predicting future requirements, and expanding “just in case” feature sets. Pollack went so far as to suggest not worrying about optimization or heavy loads until your software starts buckling under the pressure of intense usage. Do I agree? I’m afraid I’m too ignorant at this point to really have an opinion.

11. Use visual communication, not just text-based comms

You might love email. Your client might love email. But sometimes, it’s hard to really describe a feature or a bug through text alone. Pollack is in love with the idea of not only attaching annotated screenshots, but also sending screencasts.

I had never really thought about screencasting as a form of regular, commonplace communication, but it makes a ton of sense. The key is to limit yourself to 5-minute videos recorded in a single take. Such screencasts may be rough around the edges, but they can still drive a point home faster and harder than a simple email.

Additionally, screencasts provide other benefits such as added wow-factor for client interactions and passing along an easily shareable mini-demo to customers or the client’s stakeholders.

12. Better work is motivated by meaning

The final step of Pollack’s talk doesn’t really seem like a proper step to me. Maybe I zoned out, but Pollack didn’t connect the dots.

Perhaps he is suggesting that if you don’t think your work is meaningful, then you should find a new job, thereby increasing your productivity and output quality. In the end, Step 12 is still a good point. It will be familiar to any one who has seen this animated lecture about motivation.

What I Thought

This was a very solid event. I give it 8 hamster dances out of 10. Audience members were even given stickers and Code School coupons.

Presentation Content

I like Pollack’s style of discussing productivity problems in the context of “human nature.” The term “human nature” came up a lot, and whether or not it’s backed up by science, it certainly makes the presentation content feel more intuitive.

I’m also partial to Pollack’s claim that writing skills are a good way to differentiate yourself from other developers. He said that if two developers are applying for the same job, and they have similar hard skills, then one of the best ways to pick a new hire is to examine their writing because better writers are better communicators.

As you can tell from my re-interpretation of the 12 steps, I didn’t like some of Pollack’s wording, but I admit that I’m oddly particular about such things. I also didn’t like that some of the advice was just common sense. Maybe it’s unfair, but I tend to expect a lot of insight from advice-giving presentations so I feel let down when I’m presented with advice that is not only familiar, but derived from the same common sense I already possess.

Speaker

Pollack’s filler word is “right?” (with upward inflection). I find this to be a little annoying. It’s not the first time an otherwise awesome speaker has used “right?” this often. I think it bothers me because I perceive it to be slightly patronizing …or maybe a subtle form of pandering.

That said, I really like Pollack’s relatability. He seems to be a down-to-earth guy, making his speaking style easy to follow. Well done, Mr. Pollack.

Venue

Chartboost had tons of free beer, great pizza (not just some Pizza Hut banality*), tons of free soft drinks, good mic setup for the speaker, and friendly staff on hand. After the presentation, they encouraged audience members to stick around and mingle, consume more pizza and beer, and use their company ping pong table. Sweet.

*Note: I’m not actually anti-Pizza Hut, and I’m certainly not a foodie, but even I found it refreshing to eat higher-quality pizza at a free meetup.

Followup

I need to check out Jing, a screencasting tool. It has limited recording time and no editing features. These limitations prevent you from spending too much time over-engineering your communique. It forces you to get to the point and be concise.