Practicing Creative Confidence

I hadn’t picked up a book for much too long. The leisurely read. The lay-on-the-beach kind of reading. The curl-up-before-bed kind of reading. The zone-in-on-the-commute kind of reading.

creative_confidence_art

I picked up Creative Confidence because, well, I was in a rut. The routine of waking up at 8 am, planting myself at my desk from 8:30 am-12 pm, grabbing a quick lunch to bring back to my desk, planting myself back in front of the computer until my lingering departure at 6 pm (sometimes 7 pm, sometimes 8 pm, sometimes 9 pm) had stripped me of any fresh-faced enthusiasm for what’s to come.

I enjoyed my job. And, I was good at it but it no longer gave me joy: the joy of being challenged, the joy of learning something new, the joy of contributing something tangibly “good”. I knew I needed a jolt of inspiration to push me out from behind my desk. An external push. I had become a bit too comfortable. I was strapped down by a fear of the unknown and a complacency for the known: a looks-good but feels-not-so-good (but good enough) job.

I needed more. I wanted more. But I was otherwise lost.

creative_confidence

Creative Confidence was exactly the dose of inspiration I needed to awaken me on how to “unleash the creative potential within us all”. With powerful anecdotes of those who were once (knowingly) lost but took charge of their creative potential through the lessons put forth by David Kelley (IDEO founder and Stanford d.school creator) and Tom Kelley (IDEO partner), I gained a better know-how to take the first step towards harnessing my own creative confidence.

So much of Creative Confidence resonated with me that I collected the words, literally carrying them in my pocket to remind me that latent creativity can be developed into creative confidence through everyday practice. One step at a time.

These quotes speak for themselves.

  • “What’s the greater risk? Letting go of what people think or letting go of how I feel, what I believe, and who I am?”
  • “In our experience, one of the scariest snakes in the room is the fear of failure, which manifests itself in such ways as fear of being judged, fear of getting started, fear of the unknown. And while much has been said about fear of failure, it still is the single biggest obstacle people face to creative success.”
  • “Fear of failure holds us back from learning all sorts of new skills, from taking on risks, and from tackling new challenges. Creative confidence asks that we overcome that fear. You know you are going to drop the ball, make mistakes, and go in a wrong direction or two. But you come to accept that it’s part of learning. And in doing so, you are able to remain confident that you are moving forward despite the setbacks.”
  • “György Konrád once said, ‘Courage is only the accumulation of small steps.'”
  • “When ideas are in short supply, it’s tempting to become possessive or territorial and limit your options. If you have only a few ideas in your idea bank, you’re more likely to settle on one of the few you have and defend it fiercely, even if it’s not optimal.”
  • “The best kinds of failures are quick, cheap, and early, leaving you plenty of time and resources to learn from the experiment and iterate your ideas.”
  • “Little changes can eventually add up to a big impact. Starting small gets you from a state of rest to a state of motion, and you’ve started to build momentum for the bigger challenges ahead.”
  • “Whether your resources are abundant or scarce, embracing experimentation can help fuel the fires of innovation. Experiments, by their very definition, are expected to have a higher rate of failure. But if you recast the traditional failure-is-not-an-option attitude as a series of small experiments, you can actually increase your chances of long-term success.”
  • “So don’t sit back and let circumstances determine your fate. Take action yourself, and influence the actions of others. As one of our favorite radio journalists, Scoop Nisker, used to say at the end of every one of his broadcasts, ‘If you don’t like the news … go out and make some of your own.'”
  • “When work is strictly a job, it may effectively pay the bills, but you’re living mostly for the weekend and your hobbies. Those who see work as a career focus on promotions and getting ahead, putting in long hours to achieve a more impressive title, a larger office, or a higher salary. In other words, you are focused on checking off achievements rather than pursuing deeper meaning. In contrast, for those who pursue a calling, their work is intrinsically rewarding in its own right— not just a means to an end.”
  • “What matters most about your career or position is not the value that others put on it. It’s how you view your job. It’s about your dream, your passion. Your calling.”
  • “Once you start to think about your life and career as just another creative challenge, many different possibilities may come to light.”
  • “While everyone has enormous potential for creativity, our experience suggests that successfully applying creativity in your work and life requires something more: the courage to leap. All that potential energy will just fade away if you don’t work up the nerve to unleash it, again and again. To make that leap from inspiration to action, small successes are key. Just as fear of the first step holds us back at the beginning of a project, the weight of the status quo hinders us from making significant career changes. You may have entertained the thought ‘I could have been a writer,’ or ‘I wish I worked in health care,’ and stopped there. However, if you make the first step small enough, it can nudge you toward your goal. But you need to take that first step.”
  • “If you want to transform your life from mere duty to real passion, you have to start by realizing that your current situation is not the only option open to you. You can change how you live and how you work. Look at setbacks as the cost of trying new things. Don’t be afraid to try and fail. The worst thing you can do is to play it safe, stick with the familiarity of the status quo, and not try at all.”
  • “If you are stuck in a ‘looks good, feels bad’ position or job, think about the overlap between your personal passions and the workplace options that might be available to you. Learn new skills. Start writing the new story of your working life. Keep searching for and moving toward a role that will feel as good as it looks. When you reach it, you may realize that you have found your calling.”
  • “Thoughts become words, and words become deeds. If you get the language right, it affects behavior.”

Review: The Art of Readable Code

Title: The Art of Readable Code: Simple and Practical Techniques for Writing Better Code

Authors: Dustin Boswell & Trevor Foucher

art_of_readable_code

Contents

  1. Code Should Be Easy to Understand
  2. Packing Information into Names
  3. Names that Can’t be Misconstrued
  4. Aesthetics
  5. Knowing What to Comment
  6. Making Comments Precise and Compact
  7. Making Control Flow Easy to Read
  8. Breaking Down Giant Expressions
  9. Variables and Readability
  10. Extracting Unrelated Subproblems
  11. One Task at a Time
  12. Turning Thoughts into Code
  13. Writing Less Code
  14. Testing and Readability
  15. Designing and Implementing a “Minute/Hour Counter”

art_of_readable_code_cartoon

Source: The Art of Readable Code

My Story

When I first arrived at Stanford a few years back, I was shocked by the disarray in which project files were being “organized”: no discernible structure, no standardization, no version control, etc. It was sheer confusion as I waddled through the files trying to figure out what was what. For example:

  • Is “analysis teacher turnover v3.do” or “analysis teacher turnover final.do” (same date-stamp) the latest version of the program file?
  • Does “analysis teacher turnover.do” have to be run before or after “analysis student turnover.do” … or does order not matter?

It was not only how files were named but the content of the files i.e., the code. It was as if I was reading someone’s diary and getting a gist of the underlying story swathed in inside jokes, unique lingo, and subtle inflections. The problem is code shared and collaborated across a team cannot be a personal journal of more or less rambling thoughts. If a graduate student or staff researcher on our team had left, his/her replacement would have little idea of how to replicate or update the code — or at least would have to spend an inordinate amount of time playing Sherlock Holmes. I wouldn’t even be surprised if the author wasn’t able to figure out the code without jolts of memory defibrillation.

Hence, as soon as I settled in, I wrote a manual of best practices for planning, organizing, and documenting code. Adopted by 30+ professors, graduate students, and staff, I called my manual the “POD”, drawing inspiration from J. Scott Long’s “The Workflow of Data Analysis Using Stata“. I wasn’t an expert on the topic but I had enough experience to share my know-how to lead an otherwise blind team towards adopting basic efficiencies (e.g., readability, consistency, etc) for reproducible research.

Some of the best practices in my “POD” manual echoed those in “The Art of Readable Code” including:

  • Packing information into your variable, function, and class names (8)
    • Choose specific words
    • Avoid generic names (or know when to use them)
    • Use concrete names instead of abstract names
    • Attach extra information to a name, by using a suffix or prefix
    • Decide how long a name should be
    • Use name formatting to pack extra information
  • Aesthetics (34)
    • Use consistent layout, with patterns the reader can get used to
    • Make similar code look similar
    • Group related lines of code into blocks

The Art of Readable Code

Boswell & Foucher lay out a lot of useful tips and step-by-step examples demonstrating the “art of readable code”. While the purpose of the book is not to teach the art of architecture or design patterns, the essential basics are covered: naming variables, including comments, formatting code (e.g., column alignment, blocks, logic order, etc), simplifying loops, etc. Sure, many of these things may seem intuitive or could have been figured out on-the-job but if not, this is a great place to start. And, for those who have already mastered these practices, reiteration of the “why?” and “how?” is always a helpful reminder of what can be dismissed as common-sense or second nature.

The key idea behind the teachings is:

“The Fundamental Theorem of Readability: Code should be written to minimize the time it would take for someone else to understand it.” (3)

What I love about this book is its plethora of examples illustrating the multiple ways in which you can implement the Fundamental Theorem of Readability. Examples are provided in C++, Java, JavaScript, and Python. But fear not if you are a newbie to programming or an expert in some other language, say, Stata! You do not need to be proficient in any of these languages to understand the concepts being illustrated: the beautiful code “art” vs. the uglier stuff. And, if you do get lost or intimidated, each chapter is wrapped up with a summary that bullets the key principles and techniques so you will always have the takeaways in plain English.

Review: Team Geek

Title: Team Geek – A Software Developer’s Guide to Working Well with Others

Author: Brian W. Fitzpatrick & Ben Collins-Sussman

teamgeek

Contents

  1. The Myth of the Genius Programmer
  2. Building an Awesome Team Culture
  3. Every Boat Needs a Captain
  4. The Art of Organizational Manipulation
  5. Users are People, Too

Mission Statement

“The goal of this book is to help programmers become more effective and efficient at creating software by improving their ability to understand, communicate with, and collaborate with other people.” (xiii)

Team Geek is a light and fun read with insightful commentary on how marrying the human “soft skills” with the technical “hard skills” can create the foundation for a great team. While Team Geek is written for software engineers (and their managers) in mind, its takeaways are relevant to anyone — engineer or non-engineer, lone wolf or team player. Though common sense at times with lessons already picked up from experience, what makes this book worth the read is the packaging of these lessons as entertaining stories and analogies like:

  • “Strengthen what we call the bus factor … the number of people that need to get hit by a bus before your project is completely doomed” (7)
  • “Your team’s culture is much like a good loaf of sourdough” (27)
  • “A boat without a captain is nothing more than a floating waiting room” (54)
  • “Engineers are … like plants: some need more light, and some need more water (and some need more bullshit, er, fertilizer).” (81)

Three Core Principles

The building blocks for a great team are based on “three pillars” of social dynamics: Humility, Respect, Trust — or HRT (12).

  • Humility: “You are not the center of the universe. You’re neither omniscient nor infallible. You’re open to self-improvement.”
  • Respect: “You genuinely care about others you work with. You treat them as human beings, and appreciate their abilities and accomplishments.”
  • Trust: “You believe others are competent and will do the right thing, and you’re OK with letting them drive when appropriate.”

What does this mean in practice? Actions of HRT include:

  • lose the ego
  • learn to both deal out and handle criticism
  • fail fast; learn; iterate
  • leave time for learning
  • learn patience
  • be open to influence

Using anecdotes and accompanying illustrations, the authors emphasize the importance of HRT not only for one’s own growth but for the success of the larger team. While the rare specimen of a “unicorn” or “lone craftsman” may exist, none of us work in a vacuum. Successful leaders are especially important in managing the team – particularly when attacked from within by poisonous threats (e.g., ego, over-entitlement, paranoia, perfectionism). Patterns (and anti-patterns) adopted by leaders to build a resilient (or dysfunctional) team are collected from first-hand accounts:

Antipattern (for Unsuccessful Leadership)

  • Hire pushovers
  • Ignore low performers
  • Ignore human issues
  • Be everyone’s friend
  • Compromising the hiring bar
  • Treat your team like children

Pattern (for Successful Leadership)

  • Lose the ego
  • Be a Zen master
  • Be a catalyst
  • Be a teacher and a mentor
  • Set clear goals
  • Be honest
  • Track happiness

All in all, HRT must be taken to heart by each and every team member in all interactions, big and small.

What I took to heart

As I find myself in a transitional phase seeking to learn what I am lacking (currently be on a team of a lonely one without strong leaders and mentors to learn from) and what I am searching for to find that happy spot in a Team Geek, the following resonated with me:

  • “If you spend all your time working alone, you’re increasing the risk of failure and cheating your potential for growth.” (5)
  • “Working alone is inherently riskier than working with others. While you may be afraid of someone stealing your idea or thinking you’re dumb, you should be much more scared of wasting huge swaths of time toiling away on the wrong thing.” (10)
  • “Your self-worth shouldn’t be connected to the code you write. To repeat ourselves: you are not your code.” (17)
  • “Let’s face it: it’s fun to be the most knowledgeable person in the room, and mentoring others can be incredibly rewarding. The problem is that once you reach a local maximum on your team, you stop learning. And when you stop learning, you get bored. Or accidentally become obsolete. It’s really easy to get addicted to being a leading player; but only by giving up some ego will you ever change directions and get exposed to new things. Again, it’s about increasing humility and being willing to learn as much as teach. Put yourself outside your comfort zone now and then; find a fishbowl with bigger fish than you and rise to whatever challenges they hand out to you. You’ll be much happier in the long run.” (20)

Even if we think we can stand on our own and detach from the human dramas, software engineering (and essentially all personal relationships and professional endeavors) is a team sport and in order for us all to win, especially in the trenches of conflict and bureaucracies, everyone must play the game by the social rules: Humility, Respect, and Trust.

* * * * *

Check out Fitzpatrick & Collins-Sussman’s Google I/O 2009 talk “The Myth of the Genius Programmer”: http://youtu.be/0SARbwvhupQ