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.

This Money Under 30 article recently appeared in my Facebook feed. One friend posted it; another friend left a beautifully/brutally succinct comment like so:

This article is bad.

I concur, but I suck at being succint, so this here’s a giant explanation in the form of a blog post…

Is My Sacasm Detector Working?

The article is so random that it feels like satire at various points. The text is written with few facts –mostly just vague thoughts. The author, Phil Villarreal, avoids specifics, and just encourages the misconception that you always get what you pay for. Value isn’t always directly tied to price. There are usually quite a few exceptions in the world of consumer goods.

What is considered too expensive/cheap? Other than that $80 exaggerated plate, we have no idea what price ranges he’s talking about. Also, his article assumes value always comes at a price. Is my sacrasm detector faulty, or is Mr. Villarreal being completely serious?

Systematic Breakdown

Based on the article’s format, I’m going to split the rest of my blog post into two sections: 6 products/services with a tight value-cost relationship and 6 products/services where you may as well tap into their respective bargain bins.

I admit this blog post lacks citations, but at least I make some verifiable claims. Besides, I only need to provide anecdotal counter-examples to rebut Villarreal’s arguments thanks to his own reliance on anecdotes, hearsay, overgeneralizations, etc.

Allegedly Worth Spending More

Socks - Even expensive socks get holes in them. I’ve gotten expensive socks as gifts. They were thin and broke quickly. I’ve gotten generic-brand dress socks from Costco. In my 3+ years of wearing business pro and business casual attire on a daily basis, the cheap generics never broke, but the others did.

Pillows - Yes, they’re important. No, you don’t need to pay extra to be happy with your choice of bedtime headrest. How many people do you know that have unnoteworthy pillows? How many of them are truly discontented?

Toilet Paper - I would’ve agreed, but recently, I saw this gem from Consumer Reports:

So maybe I should reconsider my stance on toilet paper –now that’s a statement I never thought I’d share with the Internet.

Computers - Most people don’t need expensive/fast computers, but if you’re going to spend the extra dough, you need to know what features you need. You don’t just throw more money at the store and assume you’ll get a product that performs better for your purposes. Most people will never notice the difference between an Intel Core i7 CPU (expensive) and a Core i3 (cheap). They will notice the difference between an SSD harddrive (expensive) and a conventional one (cheap). Too bad the Villarreal doesn’t provide these types of relevant details.

Home Repairs - I agree, but how do I filter the expensive good from the over-priced bad. Advice please?

Shoes - This is a perfect example of how the author needs to provide more context (i.e., PRICE RANGES). Yes, $20 Payless sneakers will die if you look at them too hard. But is he suggesting boycotting $40 Sketchers too? There is room for middle ground, but the article ignores that. Sure, Villarreal emphasizes comfort when it comes to shoes, but cheap shoes can be comfortable too.

By the way, if you’re buying shoes for a specific sport, I’d suggest that paying a lot generally isn’t worth it unless you’re really serious. For example, with the way I run on the court, I will wear out the tread of expensive tennis shoes just as quickly as I wear out the tread of mid-tier tennis shoes. I don’t think the $40-60 price difference is worth the added stiffness/support of a hardcore tennis shoe.

Allegedly NOT Worth Spending More

Shoelaces - Fair enough. Good analogy, Mr. Villarreal.

Phones - I can understand saying the average Joe doesn’t need a top-of-the-line phone. However, expensive phones will generally be able to handle future OS updates better than cheaper ones, so it’s not always bad to get a flagship phone. Basically, if you’re a techie, you shouldn’t feel bad about your expensive phone purchase despite what Villarreal claims.

What’s dumb is buying a new phone too often –something the article mentions. What’s especially shameful is paying for a $100+/month phone bill just so you can do a lot of texting, occasional on-the-go Facebook, and take derivative photos…usually of food. If the phone user is on a family plan, then more power to them. If not, they better not complain about their bank account balance. [/off-topic]

Haircuts - I mostly agree, but does he intend to speak for women as well?

And I don’t usually judge authors by their looks, but I’m not taking haircut advice from this guy. [I actually feel iffy about this burn. Too personal?] Regardless, “accept your mediocrity” is never good advice. This is the line that REALLY makes me think this article is satire. Am I being trolled?

Clothes - Let me get this straight. We should invest in quality socks, but not quality coats, dress clothes, gloves, pants, etc? WTF is this guy smoking? You don’t have to be an expert blogger like Villarreal to know that it’s worth investing in a solid jacket/coat, and that good jeans can last for a longggg time. (Yes, 4 ‘g’s because I’m talking about serious duration here)

Car Repairs - Is the author color blind? Because the world sounds pretty black and white from his perspective. (Yes, I know color blind humans can generally see more than just B&W)

Earlier, I made a case for saving money on things that wear out in my paragraph re:shoes, but now we’re talking about complicated beasts called cars. A higher-priced tire can have lots of benefits (less rolling resistance, less tire noise, much better grip, etc). The low-tier tires can have shitty grip. Mid-tier tires can have awesome grip, so I think they’re worth it. If Villarreal thinks shoes are crucial, he should also consider that tires are basically the shoes of cars. They’re considered the most crucial part all carowners can change.

More expensive motor oil can make a difference –especially conventional vs synthetic. Synthetic is a more expensive option even when you factor in its superior longevity (usually 5,000 miles between oil changes instead of 3,000), but it’s better for your engine and the environment (and the oil-based economy?) because you’re using up less oil and fewer resources during you car’s lifespan.

Lastly, more expensive brake pads generally have better stopping power. If you survive a near-accident and feel like doing something to allay your new-found fear, then you should consider spending some extra moolah to upgrade your tires and brakes.

Food - $80 plates are not necessary? How insightful.

Maybe Villarreal could give some tips on how to buy healthy stuff at the grocery store without spending a lot? Otherwise, I will end up eating nothing other than ramen based on his two-extremes critical thinking skills.

Seriously though, everyone complains that eating healthy is expensive. Does he disagree? If so, he should explain because that would actually be useful.

“Expound” is the Apt Word

The article provides no specific suggestions for what brands/specs/details to buy/avoid (other than suggesting you make all judgements based on price tag), very few good examples, no context for what’s a good price range, etc. There is no true insight.

The article runs on weak reasoning, and the type of writing that tends to earn accusations of “lazy journalism.” It’s “lazy” because it uses an attractive, list-oriented headline/format to bait the reader into thinking a really efficient learning experience is presented within. Instead, the article reads like something an editor forced a blogger/journalist to write at the last minute to meet a quota. It’s filler.

I admit I could be wrong about what is and isn’t worth splurging on, as I don’t have a ton of life experience. However, the style of Villarreal’s arguments leave so much room for questioning. That’s what bothers me so much.

You can’t present a case in such a manner without expecting someone to poke holes in it. For example, if I say, “The sky is blue due to the properties of light,” then I am technically correct, but I wouldn’t expect everyone to just accept that statement at its face value. I’d feel obligated to expound.

In my paragraph re:cars, I did a lot of explaining because I expect most people aren’t too familiar with cars’ intricacies. Ignorance is not stupidity. I assume most people are ignorant about a lot of car-related things, but I don’t assume them to be too stupid to understand some important, relevant details.

Villarreal fails to expound on the many statements that he should know aren’t worthy of acceptance based on face value alone. He should feel obligated to explain further, but he doesn’t because the article was never meant to truly help any one. It was just meant to get some easy page views.

I wasn’t happy with the style of my standard <h1> header. I wanted to spice things up. After some aimless browsing, I learned that there is an :after selector in CSS. Inspired by this new selector, I wanted to find a way to add an <hr/> element “after” my <h1> headers.

Check Out This Sweet HR, Man

Apparently, it doesn’t quite work the way I expected, but that’s ok because I eventually found this sweet compilation of horizontal rules!

I entered the following CSS code into my sass/custom/_styles.scss file:

.entry-content h1 {
  text-align: center;
  margin-top: 12px;
}
.entry-content h1:after {
  content: " ";
  display: block;
  height: 1px;
  margin: 6px 0px 6px 0px;
  background-image: -webkit-linear-gradient(left, rgba(0,0,0,0), rgba(0,0,0,0.75), rgba(0,0,0,0)); 
  background-image:    -moz-linear-gradient(left, rgba(0,0,0,0), rgba(0,0,0,0.75), rgba(0,0,0,0)); 
  background-image:     -ms-linear-gradient(left, rgba(0,0,0,0), rgba(0,0,0,0.75), rgba(0,0,0,0)); 
  background-image:      -o-linear-gradient(left, rgba(0,0,0,0), rgba(0,0,0,0.75), rgba(0,0,0,0)); 
}

So instead of adding <hr/>s after my <h1>s, I added gradients inside of very thin background images. It’s more complicated than what I had originally envisioned, but it looks way nicer.

Codeblock, the Party Pooper

Unfortunately, in the process of writing this blog post, I discovered that my codeblocks (powered by CodeRay) aren’t as responsive as I had hoped. I mentioned my CodeRay configuration in my first post. The configuration involves picking a codeblock format Octopress _config.yml file.

I chose coderay_line_numbers: table at first, because I want line numbers, and I want them to be separated from the code. The problem is that CodeRay codeblock tables are apparently unresponsive to browser size. Consequently, the codeblocks were wider than the <div>s that contained them whenever they were viewed on a smartphone or even on a PC looking at this blog’s front page. The front page automatically narrows my posts quite a bit, and that made the codeblock tables very unhappy. It was very annoying.

I haven’t found a true solution despite diving into the CSS. All the relevant CSS selectors already have width: 100% so I don’t know what else to do. I experimented with some overflow properties, but to no avail. For now, I have resorted to turning off line numbers entirely. Dammit.

Last Thursday, General Assembly hosted a presentation by Jenny Tsai (nice URL, by the way). Tsai is a pro UX designer, but her talk was meant for UX noobs. So instead of focusing on how to be a great UX designer, she focused on what is a UX designer. I’m not looking to become a UX designer, but the event was free, and I like hearing about the various roles involved in modern tech startups. Besides, I think all wannabe web developers such as myself wonder what differences separate UX design and web development.

Unfortunately, I was a fool, so I didn’t bring a laptop or padfolio for taking notes, so I’m just going to relay the short bits I jotted down in my smartphone.

What I Learned

Note: Tsai didn’t present this info in a DOs vs DON’Ts fashion. She didn’t do a “What’s the deal with wireframes” slide. I’m presenting the info my way, not her way.

General

What is UX design? Designer is to developer as architect is to engineer.

What do UX designers do on any given day? Draw wireframes and mockups, draft user personas, create task flows, and get user input.

What’s the deal with “wireframes” and “pixel perfect mockups”? Wireframe is to mockup as sketch is to painting. It’s all about fidelity. Both are generally non-functional, but sometimes functional mockups are created just to demonstrate animations, screen changes, and general navigation. You want to use wireframes for quickly iterating on an idea. You should save mockups for later because they use a lot of time, which is equivalent to money. And I hear money is expensive these days.

What are user personas? Looks more like a marketing thing to me, but it’s basically creating profiles of target demographics. For I’mPregnantNowWhat.com, a user persona is going to be a profile of a young woman whose tech savviness is at level X. She cares about A, B, and C. And so on. I zoned out for a bit here, so I could be wrong.

What are task flows? Flow charts on how users interact with the website/app.

Who do UX designers interact with on a daily basis? Product managers, marketing peeps, customer service folks, developers, and other designers. PMs have the vision, marketing cares about the branding, customer service gives you customer feedback, and developers are the engineering for your architecting.

What is information architecture? Figuring out how relevant info is organized. For example, a shopping website could display products based on price, color, size, etc. For example, with Amazon.com, IA also involves deciding what product categories/options are displayed to the user so they can browse based on those categories/options. I imagine this is where the battle between overwhelming a user with too many choices and underwhelming the user with not enough info unfolds.

What software is used by UX designers? Wireframing software (there are a ton to choose from), collections of pre-made buttons and other GUI elements (especially common for smartphone apps where you can drag and drop stuff like on-screen keyboards into the mockup), and Adobe Creative Suite for pixel perfect mockups and assets (such as logos or new buttons).

What does it take to be a UX designer? Yes, you need some artistic skills. Tsai was an art student. However, you need a lot of logic, not just artistry. Logic helps you solve the problem of meeting user needs through UI design, interaction design, IA, etc.

Users

UX design juggles a lot of objectives, but in the end, it’s all about merging the product’s objectives with the user’s needs. The example Tsai kept using was Amazon. Amazon’s objective is to sell stuff. The user wants to buy stuff. To do that, a user needs to be able to easily browse, search, etc.

So how do you know what users need? You interview them. Regarding user feedback, Tsai mentioned the following:

What I Thought

Tsai did a pretty great job. 9/10. Some of her presentation slides included small, hard-to-read text. It would’ve been fine for a smaller conference room, but I sat in the last row of chairs, and I couldn’t read a lot of the text. Other than that, she spoke well, the slides looked visually appealing, and she answered all questions easily.

I could do without the intro slide where she sighs over the fantastic view of the Bay Bridge she gets to enjoy on her daily walk to work. Then again, maybe I’m just cold-hearted; maybe other people loved that part of her talk.

I arrived 5 minutes late, but judging by the post-presentation Q&A session, she neglected to describe her own career path at the beginning of her presentation. That’s a big oversight because this is an introductory talk! Of course audience members want to hear how you got your start! You can check out her LinkedIn by going to her website in case you’re wondering about her career history.

As for the content, after the one hour session, I definitely have a clearer picture of not just the roles of UX designers, but also the roles of those who interact with UX designers. The talk also gave noobs like me a better understanding of what it takes to make a web/mobile app.

The only real bummer was the acoustics. I’m going to whine a lot here, so skip to the followup if you get bored. The General Assembly (GA) building is pretty nice. It has a few classrooms and conference rooms, but like all cool beans, GA uses a relatively open floor plan. Tsai’s presentation was held not in a classroom, but in an open area on the second floor. When I arrived, there were a handful of people working at nearby computers. They were chatting, as you’d expect, but that’s a distraction for audience members.

On top of that, the air conditioning system popped on during the last segment of the event, and it spooked Tsai. Everyone thought it was some annoying truck or something, but the sound didn’t go away. It really bothered Tsai. After she inquired, the GA staffer explained it was just the AC. Damn that was an annoying AC.

By the way, just like everyone else, I think exposed walls/ceilings, glass conference rooms, and open floor plans are slick as hell (especially compared to the drab corporate offices in DC). However, it’s pretty obvious that the recipe for office hawtness is also a recipe for poor acoustics. I’m surprised GA hosts presentations in the middle of an open floor of such a building. I give GA a score of 6/10. Yes, I’m sure my scores change the world.

Side note: When using folding chairs, is it possible to stagger the rows so then the columns don’t line up? This would help short folks like me see through the heads of taller people rather than staring at the back of the head of the tall guy sitting directly in front of me. I’m sure staggering rows would be less space-efficient, but if you’ve got a lot of rows, then the people in the back could sure use some help seeing the presenter and the projector screen.

Followup

GA did a good job of following up with attendees. We were emailed a survey (in which I notified them of their crappy acoustics), a blurb about GA’s other UX classes, and two lists of resources, which you can see for yourself below.

UX website reading list:

• http://www.uxbooth.com/
• http://boxesandarrows.com/
• http://www.uie.com/
• http://uxmag.com/
• http://www.uxnewsfeed.com/
• http://www.inspireux.com/
• http://uxdesign.smashingmagazine.com/
• http://www.nngroup.com/reports/
• http://techcrunch.com/
• http://bx.businessweek.com/user-experience-ux/news/
• http://hbr.org/

UX book reading list:

• Design of Everyday Things
• The Elements of User Experience Design (by Jesse James Garrett, who Tsai referenced)
• Don’t Make Me Think
• A Project Guide to UX
• The Inmates are Running the Asylum

Wandering Around: Bits of SF from Jeff Lee on Vimeo

Soon after I moved from the east coast, I set aside an afternoon to simply roam around downtown San Francisco. I was really excited to grab my crummy-yet-trusty, point-and-shoot Panasonic Lumix TS-1, and just be a tourist.

To my delight, I discovered that the hilly nature of the city lends itself to providing fantastic views. Also, being short helps me conquer hills.

I compiled some of those views into a brief clip because I think I can do a better job of sharing vistas through my camera’s video recording than through its photo capturing …and because I like adding music to visuals.

Last updated: Aug 10th, 2013

Here We Go

Dammit. I’ve made so many tweaks and adjustments, but I still haven’t gotten this blog looking quite right. I’m about to get nerdy, so jump down if you have no sympathy for programmer growing pains.

FYI, I’m using Octopress to create this blog, github to host, and I write posts/pages in a little language called Markdown. Maybe I should’ve just created a WordPress blog, but I admit I fell victim to Octopress’s tagline: “A blogging framework for hackers.”

Some of you non-tech geeks may raise an eyebrow at the term “hacker,” but it’s really not as evil as you think. The word embodies a more jargon-y connotation as well as the archetype portrayed in the media. In this case, Octopress is appealing to the techy DIY folks who like to have a lot of control over their creations (even at the expense of convenience…as is definitely the case for me).

The Tweaks Never End

I began customizing this blog by adding a lovely Octopress theme. I then tweaked the hell out of it. You can compare and contrast by checking out the theme’s original implementation. My changes customized the color scheme, the background image, the size of the hero (i.e., cover photo area on the home page), the Twitter widget, the footer, navigation links, etc.

The customization process was tough because I had never seen a Liquid setup before. Also, I’m fairly new to git, Ruby, and the other bits involved in an Octopress-powered blog. I had to delete, re-install, and re-clone more times than I care to disclose.

But I’m still not done. I still need to tweak the colors and the background image. I want a green theme because I think green is under-used. Unfortunately, it clashes with certain Markdown parts. I switched my blog’s Markdown engine to Redcarpet, but I still get gross code blocks and lists. I tried using a Redcarpet plugin, but that threw errors during the rake generate process. I tried kramdown with a sweet CodeRay theme, but that setup completely ignored code blocks, block quotes, etc. I need help!

Update! (Aug 10, 2013)

I used HTML5 Dev Gal’s helpful instructions and links to finally implement the alliterative combo of Kramdown and CodeRay. I also realized how to add custom CSS to specifically address lists created via the Markdown engine.

So hooray! Lists and Code blocks are no longer given a ridiculous dark blue background! And why were lists given a background anyway?

Sadly, automatic TOCs don’t seem to work. I also still need to figure out how to add autolinking, which works in stock Octopress, but once modified to use kramdown, shit’s broken?

TL;DR

I’m whining about how difficult it can be to use a DIY path, but it’s really helped me learn a lot. So it’s all good.

What’s Next?

So what can you expect on this blog other than sentences that probably shouldn’t start with the word “so”?

Past

• Difficulties of my cross-country move

Present

• Chronicles of my career change
• Short reviews
• Compilations of cool links I’ve found

Future

• My goals, targets, milestones
• My thoughts on the future of tech, cars, gaming, music, tennis, and more