Trying Too Hard

In a post titled The Problem with the FizzBuzz Problem, Gayle Laakmann McDowell discussed the cognitive trap that a high performer can fall into when faced with a deceptively inelegant real world problem. She called it the “Smart Person’s Mirage.”

I was caught in this trap in an interview once myself. I was asked to write a function that took an integer parameter and wrote out an ascii art diamond pattern in the given size, like this:

  *  
 *** 
*****
 *** 
  *  

The symmetry cried out to me. There must be some way, I was sure, to leverage it in both directions at once. It seemed like an affront to the concept of elegance if I didn’t! Also, there were so many options. Use a buffer, or several, or none? Make nested loops? How should an even parameter be handled?

In a matter of minutes, I had pieces of at least three conflicting solutions scattered all over the whiteboard. That was when the interviewer let me know that that was exactly what the question was designed to test for.

The way out of this failure mode is to not try too hard. As tempting as it is to write code poetry and dazzle my interviewer, the bottom line is that it’s not required. Moving forward with something, anything, that actually completes the task is. Optimizaton, neatness and elegance (and sometimes insight) can come later.

Inspired by Gayle’s post, I revisited the ascii art diamond problem. By letting go of finding a “perfect” solution, I came up with a workable one in a couple of minutes. Here it is in all its kludgy, messy glory.

    /* diamond.c
     * utility to take an integer on the command line and
     * output an ascii art diamond in that size made of splats
     */
    
    #include <stdio.h>
    #include <string.h>
    #include <stdarg.h>
    
    #define MAX_DIMENSION 41
    #define DEFAULT_DIMENSION 5
    
    int main (int argc, char **argv) {
    	char line[MAX_DIMENSION];
	static char on_char = '*';
	static char off_char = ' ';
	int dimension = DEFAULT_DIMENSION;
	int midpoint;
	int lineno = 1;
	int columnno = 1;
	int i, j;

	if (argc > 1) {
		dimension = atoi (argv[1]);
		/* even dimensions end up being treated as the
		 * next highest odd dimension (ex. 4 makes a 5x5)
		 */
    /*		if (dimension % 2 == 0)
			dimension += 1; */
		if (dimension > MAX_DIMENSION)
			dimension = DEFAULT_DIMENSION;
	}

	memset (line, off_char, MAX_DIMENSION * sizeof (char));
	midpoint = dimension / 2 + 1;

	/* print top half of lines to midline */
	for (i = 0; i < midpoint; i++) {
		printf ("%s\n", line);
		line[midpoint - i] = on_char;
		line[midpoint + i] = on_char;
	}
		
	/* print bottom lines */
	for (; i > -1; i--) {
		line[midpoint - i] = off_char;
		line[midpoint + i] = off_char;
		printf ("%s\n", line);
	}
    		
	return 0;
    }
Advertisements

Public Speaking and Making Things Happen

Over the last year or so, I’ve spoken at SCaLE, OSCON, LinuxCon, and the Grace Hopper Celebration, as well as a slew of small local events and Toastmasters clubs. It often doesn’t seem like it, though. It seems like it happened in a fantasy. I have vivid memories of the train and plane rides, the hotel rooms, and sometimes, the expo halls. These haunt me. Less vivid are the memories of the post talk conversations, of looking out over rooms full of interested people, and especially, of connections with people who found my knowledge and perspective valuable. These are the memories that want to dissolve into my ever present mental fog unless I do the challenging emotional work to keep them fresh.

When looking back over what I learned, I wish I had some scintillating insight about speaking, about technology, or even about community to share. I wish I was advanced enough for that. What I actually did learn is something much more basic: that these things actually did happen. They were real, no matter what my avoidant selective memory wants to tell me; and I made them happen by learning and gaining skills, by being able to package and deliver knowledge to help others acquire those skills, and not to be minimized, by responding to calls for participation and catching my breath as I clicked the “Submit” button. I know intellectually that they happened. My current job is to learn it emotionally.

That’s why, as part of my visualization exercises, I’ve been letting those memories flood my internal monitor screen and saying to myself, “This happened. It was real. You made it happen. You had help from wonderful, supportive people who care about you. Still, it was you.” I’m learning to be with the cognitive dissonance surrounding those memories, and to sort out the clash of emotions that create it. Most of all, I’m learning to prevent my old self image from taking over and shutting down that active, ambitious, successful part of me. It’s uncomfortable. But ongoing failure and mediocrity is even more uncomfortable.

I did it. I made it happen, and I can make it and other things happen again, whenever I want. That is the lesson.

Linux Kernel Hacking 101 at NVidia Toastmasters

This is the official online resource area for the Linux Kernel Hacking 101 talk on Thursday, March 19, 2015 at NVidia Toastmasters.

This post is to let you, the attendee know what to expect from the talk, make the additional resources easily accessible in one place, and provide space for additional discussion.

This talk will familiarize you with the activities and habits of a Linux kernel contributor. It is intended to be entry level to people who already know a little about programming. While it’s helpful to be familiar with open source tools and methods (such as the C programming language, Git, and IRC), it isn’t necessary. Most NVidia technical employees probably already know enough to follow the talk easily.

If you are unfamiliar with the idea of an operating system kernel and what it does, please visit this link for a quick intro:

Kernel Definition

The agenda for the talk will be:

1. The creative cycle of coding: finding your contribution, creating and delivering your work, gathering and incorporating feedback
2. Communicating with team members and community: channels of communication and learning, purpose and benefits of working with others
3. Coding your changes: ways of working that are peculiar to the kernel, or helpful in its context
4. Delivering your patch: making your work available and accessible to the human stewards of the codebase

The talk should take about 15-20m.

It is not possible to give sufficient detail about any of the individual technologies and skills that go into the craft of kernel and open source participation, much less all of them. There is a wealth of excellent tutorials and information already online. A list of these has been compiled in the slide deck, and is reproduced below for easy access.

Kernel.org git repositories
Linux Kernel Newbies
Outreachy First Patch Tutorial
The Eudyptula Challenge
KVM Installation
Linux Kernel Mailing List
Various Linux related mailing lists at Gmane
Linux Foundation events
Linux Weekly News
#irchelp
Irssi – The Client of the Future
Wikipedia entry for the grep command
Linux Cross Reference at Free Electrons
Linux Kernel Coding Style (pdf)
Vim the editor
Pro Git (Also available here)
The Mutt E-Mail Client
Video of this talk from SCaLE 13x

Last but not least, here is the Github repository for this talk, including the slide deck. Run

$ git clone https://github.com/shegeek/kernel-hacking-101.git

if you have Git installed on your system.

Thank all of you for participating! Please leave a comment with your evaluation.