Gaslight & Steam Dev Blog

When you’re in the trenches slinging code, it’s very easy to become disillusioned about your skills. Without a frame of reference, tasks you think should be easy become mind-bendingly difficult and there’s no light at the end of the tunnel. That’s certainly been my experience developing for the web and also in designing games. In the latter case, it’s even harder because you can easily convince yourself that no one in their right mind will ever enjoy the gameplay you’ve devoted yourself to for months. I read a post today John Nunemaker that he succinctly titled, “I Have No Talent“. He says:

I am sick of hearing people say, “Oh, I love your code, I wish I could do that.” You can. The only reason you can’t is because you don’t practice enough. I used to think that I wasn’t smart enough. I was jealous of those that did crazy code stuff that I couldn’t even comprehend. Then, one day, I ran into something I did not understand and instead of giving up, I pushed through.

His blog post reminds me of a discussion I had with one of the programmers on Forza Motorsport. At one point, I made an off-hand coment about the complexity and difficulty of what he did in working with the Cambridge Research Center. His response was much the same as Mr. Nunemaker’s, albeit a bit more curmudgeonly. In short, where I perceived this baffling artifice of dazzlingly complex code, he saw it as something that anyone could learn to do with enough time and effort. His insight helped me to keep slugging away at writing my first C# application and not becoming discourage at the intricacies of serializing and deserializing XML.

Working with senior developers has given me insight into how to do some pretty amazing things with computers. Seeing the frustrations of junior developers has taught me how aptitude is different from knowledge. In some cases, things never click, but in the vast majority of instances, it’s just a matter of experience and learning. When I taught basic computer classes through the King County Library System (for those in the Puget Sound region, the KCLS computer classes are a great introduction for novices and they’re free), I got see many people who had never used a computer before gradually come to the realization that surfing the web or using Microsft Word wasn’t nearly as difficult as they feared it would be.

So if you want a more objective appraisal of your development skills, try teaching someone else what you know. And if you want to know whether your game is actually any fun, let someone else play it. But that’s a post for another time.

Looking out the window where I work, my co-workers and I can see the steady progress on the construction of Amazon.com’s new buildings in the South Lake Union neighborhood. Today, safety-vested and hard-hatted troop of people came parading through in the rain, presumably on a tour to see the progress being made. Since we use Lean processes, it seemed analogous to a “gemba walk” that our managers are supposed to conduct regularly.

But why use a term like gemba walk when the Japanese word gemba has a literal meaning of “factory floor” and applies to an industrial process rather than the development of software? Further, for non-Japanese speakers, why use the specific Japanese word when there are plenty of English words that are more immediately understandable to outsiders (those not engaged in applying Lean methodology in the workplace)? It’s not even so much that using this word jars the ear of an English speaker, but that other words to refer to other parts of the process are not used or are, in fact, translated. In a workplace that also embraces kaizen (lit. “improvement”), why are terms like muda (waste) and seiketsu (standardization) not used? When Lean practitioners do recognize waste, they often fail to recognize the differentiation that would be captured by proper use of the Japanese terms (specifically, muda, muri, and mura, the latter two being distinct from more general waste that comes from an inexact translation of muda). To me, as an occasional speaker of Japanese, the reason to use the foreign word is so that the specific nuance of that word isn’t lost or because the translation is too inexact.

To my mind, using the term gemba smacks of putting a new coat of paint on the idea of management by walking around, albeit with a formally defined set of goals and methods. However, I think the formality of the process, typified by the use of ill-defined buzz words, becomes a waste all its own. The danger is that the process becomes a meaningless exercise: “It’s a ‘drive-by’ gemba. No matter how sincere, it is shallow.”

On a related note, the term kaizen rolls off the tongue easier than Kontinuierlicher Verbesserungspozess (such as that employed by Volkswagen), the latter being more in the nature of focussed improvement on a specific process and being more punctuated than the Japanese process.

Addendum: Regarding the use of Japanese terms, Mike Wroblewski has some excellent points and links to arguments both pro and con. In case it’s not clear, I agree with him and don’t think that the Japanese terms should be abolished, but rather that practitioners shouldn’t let the term obscure the intent. By all means use the appropriate terminology to effect the changes the organization wishes to see. If the changes aren’t occurring, then perhaps the managers performing their gemba walk has gotten bogged down in the terminology or process and need to spend more time listening to what is actually being said.

The term anti-resume is used in several different senses, most commonly refer to a narrative resume in the fashion of Anne Sexton’s Resume 1965. My own profile is a reasonable example of this form of resume.

The other sense of the term is that mentioned in Nassim Nicholas Taleb’s book The Black Swan where the author comments, “People don’t walk around with anti-resumes telling you what they have not studied or experienced.” For computer geeks, this seems to be doubly true since it’s often a point of pride about the depth of knowledge in a particular area one has, whether it’s a computer language, a code framework, or some particular anime director’s corpus of work.

To list all the things one doesn’t know, even in the broadest sense, would still be a ridiculously large list, not to mention a rather pointless intellectual exercise. But there would actually seem to be quite a bit of value in analyzing one’s abilities in terms of what one aspired to learn (but might never learn due to lack of aptitude or limitations of time) or what one planned to learn for a job role (a variation on the, “where do you see yourself in five years” question). In the latter, the anti-resume becomes a tool for planning one’s personal or career growth.

My first take on a personal anti-resume looks something like this:

• Foreign language (Japanese and Mandarin Chinese). Despite having had two years in college on the former and taking some lessons in the latter, my ability to speak these languages is below the level that might be considered functional. I comprehend enough Japanese to get the gist of conversations when my daughter’s friends speak Japanese with their parents and I can occasionally puzzle out words in katakana. My Mandarin is stuck pretty firmly at the preschool level, though I know all the words to the children’s song “Liang zhi lao hu” (“two tigers”, sung to the tune of “Frere Jacques”).
• The .NET web technology stack (IIS, C#.NET, SQLServer). I know just enough of these technologies to be dangerous, having worked off and on with IIS and deployed ASP pages, built at least one app with C# and used SQLServer on the desktop for Vignette. But I’d like to know more and I’d like to be able to build full-featured data-driven web applications with this technology with the same proficiency that I do with other technologies (LAMP and Java).
• Functional programming languages. Ever since first being exposed to them in a meaningful way at No Fluff Just Stuff in 2008, I’ve been excited about functional programming languages like Erlang or Clojure. In addition to learning more about those languages (pick one), I’m still fuzzy on concepts like lambda calculus and curried functions and would like to learn more, particularly when it comes to applying some of those concepts to the Javascript work I do.
• Probability. Having completed a course in statistics, I feel like I have some better tools to further improve my understanding of probability and things like Bayesian analysis. There are so many applications for probability in the computer field and I feel like I’ve barely scratched the surface with my reading.
• Geography and GIS. I have a real fondness for maps and geography along with the ways we use maps in ways beyond getting directions somewhere. The use of maps on the web and other technology like GPSes are of particular interest where they overlap with ideas of space over time and human relations to space (such as human migrations and land use, urban development, and community building). I may not be quite the GIS maven that Scott Davis is, but I have his book GIS for Web Developers and I plan to read it all the way through sometimerealsoonnow.
• Javascript and jQuery. I’ve been writing Javascript for years, though it’s only recently I’ve begun to explore its real capabilities, as enhanced by the various frameworks out there including YUI, prototype, jQuery and DOJO. I’ve had the ability to dive pretty deeply into jQuery in recent months and want to master its capabilities.
• Computer Security. With the recent concern about PCI compliance and working in an industry where we deal with confidential health records, security of our data, our applications and our servers (the latter two, respectively, accessing and storing the data) is a major concern. Among our many concerns are making sure we’re in compliance with regulations, checking that the site isn’t vulnerable to things like XSS attacks and ensuring that the applications are secure. We also work closely with the IT group that manages the servers to avoid inadvertently introducing security holes and exposing data.
• Algorithms and Design Patterns. My first serious exposure to design patterns was with my Java certification, though I discovered I’d been using some variation of various patterns without knowing what they were specifically. Having the knowledge and using it in a systematic fashion has made me want to learn more about patterns I haven’t used. The same holds true with algorithms such as sorting data and lists, traversing trees, and compressing data.
• Aikido. I’m currently a member of the Tsubomi Seishin Kan Dojo, but time constraints and finances have limited my ability to take aikido lessons right now. I hope to continue classes in the near future, probably as soon as I’m not spending as much time with school and learning some of the previous things in this list. Of the martial arts I’ve studied, aikido resonates with me, combining the breathing and moving meditation of tai chi with the discipline and weapons practices of karate. Not only that, but the people in my dojo are a really great bunch of folks I like spending time with.
• Writing. I’ve written extensively throughout my life and in number of different modes including fiction, poetry, technical documentation and this blog. There’s always room for improvement and learning. I’d love to write a book, perhaps a novel, and some short fiction, either fantasy or science fiction.

That’s just a quick take, but probably more than enough to keep me occupied for the next five years.