Creation, Attribution, and Misogyny

One of the hidden, insidious, morally bankrupt things that repeatedly peeks its head above the slime in open source development is plagiarism - specifically, the lack of attribution.

We can have all the arguments you want about 'pirating' code and the like - this is not about patent trolls - and pirating code is stealing, but it's also not really the subject of this post. This post, instead, is about intentionally writing creators out of history - whether it's through intentionally omitting an author or reference link or by actively deleting it. Of course, it happens all the time and it's dishonest...and not in a cute "I'm a smuggler for the Rebel Alliance" kind of way, but in a .

Oooh, what's that? Open source is different - it shouldn't recognize any individual authors/creators/innovators? No, that is absolutely not the case, and writing them out of history is not only dishonest, it's misogynistic as well. That's right, I went there. If you are writing authors, creators, or innovators out of history, you're a sexist pig - and frankly, there's no other way to see it.

We must take sides. Neutrality helps the oppressor, never the victim. Silence encourages the tormentor, never the tormented.

Elie Wiesel

I hear people all over the world crying out in terror "I'm not a sexist pig, I delete (or omit) all creators, not just women". Here's the thing, though, in removing creators you are, at the least, maintaining the illusion and bias that many people have that women are not creators, and at the worst, actively promoting a hostile environment that dismisses and negates the contribution of women. Neither option is something which should invoke pride in our work.

Women are profoundly underrepresented in STEM. That's a simple fact. We can debate whether it's a pipeline problem (it both is and isn't) or whether STEM fields are hostile environments for women (they are), but ultimately none of those causes affects the outcome that women are underrepresented in STEM, and it isn't getting much better, folks.

Read this Twitter thread

Let's take a case in point, Nicole Sullivan started something nine years ago that is used almost universally today in user-interface engineering today, and not only is she not "Twitter Verified", many people don't even know her name, and Wikipedia even deletes entries about OOCSS.

I appreciate Nicole's contributions to the industry I have made my career. When I use her work - whether it's CSSLint or OOCSS - I point out that it doesn't come from me, and given my experience working directly with her while she was consulting for PayPal, I know she would act in a similarly ethical manner.

Attribution is important, and as my career has progressed, I've seen it growing in importance. As anyone who suffers from Imposter Syndrome can tell you, love/hate relationships with ownership and attribution of accomplishments is a very real thing, but it's something the entire tech industry needs to get a grip on...and it's something that very definitely eludes us.

One final thought - as someone who has led teams of engineers, including those working on projects that resemble Frodo and Sam's journey through the Dead Marshes, morale is something rather fragile. One of the easiest ways to boost morale is to give everyone on the team the sense that their contribution matters - to, as we used to say at PayPal (and eBay), keep it human. One of the easiest ways to keep it human is to afford each other the dignity of recognizing the creator in them. Of course, the opposite is also true - take that dignity away and morale will soon follow.

Related posts: Visibility and Obscurity, My Pen Is My Tongue

My Pen Is My Tongue

A few days back I sent out a series of tweets about "self-documenting code". Self-documenting code is an idea that's been around for many years, like stories about the wee folk...and like the wee folk, no one has seen self-documenting code.

The short version of the tweet series is that if you're writing code, you should be writing documentation as well - it's really too important to skip. This post, however, is not really about self-documenting code, but rather about how to write documentation, and more specifically a certain piece of documentation that you should never neglect.

---

I entered the whole techno-geek world at a time when computer labs were a real thing. Punchcards and shelves full of binders stuffed with documentation were commonplace. Documentation isn't like that anymore. When Java came along, I was almost enthused to use JavaDoc because of the level of clarity it added when writing the documentation. Now that nearly all code written by large, technologically advanced firms is either in Java or JavaScript (or ECMAScript), JavaDoc and JsDoc are - or should be - the de facto standard.

There is seldom serious argument against using one of these two tools anymore. There is disagreement about how the tools should be used, however. In the JsDoc community, one of the points of contention is the @author tag. To be clear, the JsDoc tool authors have stopped using the author tag and no 'contributor' tag has been added. It might seem, from their use (or non-use) that these tags are unimportant, and in fact, that is a common perception, especially in light of the advances in source code management, or what we used to call "version control".

However, not only should you use the authorship tag(s), you should be encouraging everyone else to use them as well.

It would come as a surprise to no one if I reminded you that we write code to solve problems. Not only are we writing code to solve problems, we're writing code to solve complex problems. For example, no one would write code to add two numbers...doing simple calculations on large data sets, perhaps, but there is a "complexity bar", below which we wouldn't dream of using code to address a problem. The first step of writing code is understanding the problem you're trying to solve.

As a hypothetical example, let's assume you've inherited a project. You've read the documentation that describes the solution to the problem the code offers, but after getting a small understanding of the problem combined with the solution being used, you have a list of questions. Why was this particular solution chosen over other solutions, for example. You can make some assumptions, but wouldn't it be nice to be able to contact the author to ask for their insight? Code, even well-documented code, is only a partial story. Just like every fan of a book turned into a motion picture knows, even faithful adaptations leave out bits that someone thought important. The first reason to include authorship information in your documentation, then, is the abundance of information it can point you to.

The common response to this concept is that the authorship information is not needed in the documentation because source control software, like git (my personal favorite), can track that information and expose it through tools like blame.

This response, however, misses the purpose of such tools. Version control is tied to a specific change...in git parlance, a commit. Yes, you can look at a particular line and see the last change of that line - the author of that change - but that is qualitatively different information than the author of a solution...and that information is generally only the last change. In order to get authorship information you must follow changes to a specific line back through history, and if at any point history was squashed or rewritten, that information is gone. Version control tools are excellent at solving the problem the author intended them to solve, as the author understood the problem; do not expect another author's code to solve a problem as you understand it.

Another reason authorship is important is we, as an industry...and really we as the human race...have difficult acknowledging the contributions of women and persons of color. The list of women who have significantly contributed in STEM fields without attribution is long...far too long. Not including attribution participates in that system of oppression by reinforcing the status quo. If we want to have any hope of disrupting patterns of discrimination, patterns that have existed for millennia, we must combat it at every turn.

A while ago I wrote a post called Visibility and Obscurity that described a situation in which attribution was changed on work I had done. In academia this is typically called plagiarism, and in most instances it's a punishable offense. Even outside academia, claiming to have done something you have not done can have serious consequences - Scott Thompson's resume scandal is evidence of that.

We should be writing code we can release with pride. Build things you're proud of and put your name on it...and give that same consideration to others. Amplify voices that are too often silenced or ignored - it does not diminish your contribution and it makes a difference. If it only makes a difference to the woman or person of color who finally has their contribution recognized - that's enough. If the only people who see an authorship reference are your employees, your colleagues, that's enough - they are important too.

Happy coding.

Visibility and Obscurity

Several years ago, when I first started at PayPal, the front-end development environment was still fairly young. As a result, tools that might have existed in other environments were missing.

As a veteran coder, I quickly grew tired of repetitive tasks - I wanted to be writing code - and set about writing scripts that developed into a significant tool suite. I shared that tool suite with both front-end and back-end developers (there were no full-stack developers in those days) and the use of those tools spread throughout the company, across the globe.

Out of that activity, there were two different experiences that bear examination. I'll address the later of the two experiences first.

In later years, as the development environment matured, another engineer - one responsible for establishing a standard development environment - took control of the tool suite (totally understandable) and put his name on my work (not understandable). The tools I had birthed and nurtured through numerous changes in the development environment, and continually promoted so they would be visible to all engineers - were adopted and their new foster father promoted himself as their creator when they became visible to upper management.

This is not an unusual situation. It happens all too often - much more frequently to women, of course - that someone other than the individual who has done the work takes credit, especially as the work becomes more visible.

That experience taught me two lessons. First, how you handle it says volumes to those who see the situation. Second, obscurity can be moments away, behind someone else's shadow, even when you think the visibility you've worked to cultivate over years is secure.

The second experience was much more pleasant. On a regular visit to a development office, I was introduced to an engineer who had recently joined the company. The engineer and I exchanged pleasantries - the normal "nice to meet you" bit - and then the engineer who introduced us told her my username (which was explicitly tied to the aforementioned tool suite)...and her expression and demeanor shifted dramatically. As someone who's never been in the "popular" club (yes, I've been a nerd and geek since before secondary school), that reception was quite an ego boost.

I had no real expectation of receiving such a reception - none of my long-time friends who'd seen me develop the tools reacted in the same manner - and it caught me by surprise. That reception also taught me a lesson - there will be some ways in which you're always more visible than you believe you are.

History is eager to write out of the picture those who have struggled to build great things - whether it's a woman who's made a significant contribution to our community (like Nicole Sullivan, the creator of OOCSS) or a man who is more interested in the work than the credit (like Nikola Tesla).

When you find yourself in these situations - situations of visibility and/or obscurity - how you navigate those shoals says volumes about your ambition, your drive, your values - such as integrity and trust, and what you know to be true about yourself. In those situations, may you have fair winds and running seas.

Happy coding.

The Party's Over

On the way in to the office today I was listening to the radio. No, not "internet radio", real radio - with a real DJ and everything. There was an interview with Paul McCartney, who was asked, in light of his upcoming appearance at Candlestick Park, why the Beatles stopped performing...his response was "it wasn't fun anymore". Something about the culture of money, fame, and ostensibly doing what they loved changed and it wasn't fun anymore, and that was enough to make them walk away.

I know that the Beatles, individually, were famous and talented enough that they were able to enjoy 'solo' careers, and that even if they never toured or recorded again, they could probably have survived quite comfortably, and that's no small comfort (for them)...but still - walking away from millions of dollars and instant recognition with no guarantees that you will be able to do what you love again...it's nearly mind-blowing.

You might find yourself asking "why is this important, why is he bringing this up" - and with good reason. After all, my most recent posts on this blog have been at least somewhat technical...and there haven't even been any of those for a significant span of time (at least in blog years). So, your curiosity is understandable...and I'll get to the why of the timing eventually.

Back to the original train - "it wasn't fun anymore". When I heard this come over the airwaves, it reminded me of something I'd read in April of this year - Brian Chesky Note 1 relating the advice of Peter Thiel Note 2 when he funded Airbnb.

Don't fuck up the culture.

Peter Thiel, 2012

There have been a lot of people considering Thiel's advice - there are around 31,000 document matches when searching for Thiel's exact words - and now here is my journey down that particular rabbit hole.

When I was at university in the Metaphysics course, a question intended to highlight the division between essentialists and existentialists arose, framed not as a question about people but objects. Consider that we're rebuilding a sailing ship and we tear it down to the keel and replace all of the boards. When our work is complete, is it the same ship? If we think of it in terms of automobiles, it would not fit the definition of being the same car, because the identifier for the car - the VIN Note 3 - no longer accurately represents information about the vehicle. So, is it a question of how much we change something or what we change that makes the determination? Are organization analogous to objects? How does this apply to organisms?

Corporations are not people, but they are organisms, with values and personality that govern their actions, for good or evil. If we go back to the question of 'how much change' or 'what kind of change' makes something no longer identifiable as itself, we can think of situations in which we've thought, even though we may not have formally defined it, that some person we know has changed in some way and now they are not the same person - we may even readily claim this using this exact phrase. We should consider corporations subject to these same rules of behavior and personality. In fact, we can most likely each think of an organization - such as a business or philanthropic organization - that after an unsettling experience left us with the thought "they would have never done that it the past" or "they sure have changed."

Thiel most likely has seen organizations that have damaged their culture time and time again in organizations that have come to him for venture funding. He certainly sees it not only as a possible problem, but one that is likely as well. This, too, stands to reason as the common thinking is that as an organization grows, the culture changes as efficiency of scale is achieved in various areas.

The problem that I imagine Thiel sees - and yes, I am putting words in his mouth to an extent - is that when the culture changes, people leave - a situation that is also accepted as not only survivable, but normal. However, in reality, the turnover caused by culture changes are dangerous for an organization - it's like having an illness that has not yet been diagnosed - one with symptoms that you decide you can live with but that just might kill you. Part of the reasoning here is that culture changes are generally a self-reinforcing loop - the sort of loop that once it's started is not only difficult to stop, but also difficult to control or in some cases to even recognize.

Given the semi-private nature of an organization's culture, the earliest greatest impact of damage to an organization's culture will be to those within the organization. Why is this important? People are generally not motivated by money - culture is what motivates people - and it motivates people to do amazing things - like work 80 hours a week for several weeks at a time even though they're only compensated for 40, meet ridiculous deadlines, or nearly violate the laws of physics to deliver a high-quality, low-cost product quickly - whereas incentive programs generally don't work. Note 4 Because of the tight coupling between culture and other areas - like motivation and productivity, changes to culture can have a dramatic effect on the organization as a whole.

At this point, we might be tempted, after seeing people violate Thiel's advice, to think the culture of the organization is permanently damaged any time that it is changed dramatically. There certainly are people who have departed any number of organizations thinking just this thought. A brief review of companies on a site like glassdoor gives insight into the number of people working for a company who believe "changed" is equivalent to "damaged". However, here we have to stop and notice that Thiel's advice wasn't "don't have a damaged culture", his advice was "don't damage the culture". The linguistic difference between those two messages is less significant than it should be, because they are drastically different concepts.

In one version, culture is in a damaged state and in the other it's different than what it was. We need look no further than our own history of romantic relationships to see the truth of the premise that these are different, regardless of our willingness to admit it in the pain and grief that comes immediately after the recognition of how we, or the other, have changed. Just because someone or something you love - be it a person or an organization - changes and you find they are now intolerable (to you) that does not mean that they are therefore befouled or damaged - they can be a perfectly nice, good person (or organization) and still not be your cup of tea. Changes are significant, however, because once you've changed the culture, people no longer have the company they love, and people not only lose motivation, people start leaving - whether they're customers or employees - and that's seldom a good thing. Note 5

When the people most invested in the success of an organization - like employees - leave because the culture has been damaged, there are likely to be repercussions that ripple out in ever-widening circles, like those created when a pebble is dropped into a pond. If the damage to the organization's culture is significant enough, it's just a matter of time before that trend carries outward as far as customers. Whether the organization can repair the damage and weather depends on a variety of factors that are outside the scope of this brief essay, but in every case, the nature of the business will be profoundly changed. Whether that change is for good or ill is something only time can tell. If your organization survives by knowing their customers (or users), such turbulence can be exceedingly dangerous, and it is unwise to assume that it is not.

Now, to address the question of why this post, now.

Recently there has been a lot of interest in why I left a position I held for nearly a decade. Here is the best brief explanation I can offer - I left for the same reason the Beatles stopped touring - it wasn't fun anymore. Unfortunately, that explanation has frequently proven inadequate and I have developed a longer, but still brief, explanation.

Several years ago, I started what I believed could potentially be my last job in the industry. The work was challenging and interesting, the people were, as they say, "wicked smart" and immensely talented, the product was an economic product geared toward serving under-served populations, and the general corporate culture was based on four basic values that resonated with me. It was, in a lot of ways - very nearly every way in fact - the perfect fit. Over the course of the next several years, things changed - as things do. The work became mundane as my skills were under-utilized, the vast majority of people moved on, and the product and culture changed significantly. The organization was not the same organization with which I had fallen in love, and I finally came to recognize that all the perks and incentive programs were metaphorical chains that bound me in place.

As a result of changes that transformed the organization from something I loved into something that I didn't, I left - and yes, it was before finding another gig - because I'm a firm believer that when you see it's time to go, you put your affairs in order, raise your sails, and go. Now, three months past my departure, I still have a sense of what I've lost, and yet there are times that, like the song says, I'm "too relieved to grieve" Note 6  because, in the end golden chains are still chains (Robert's Rule #33).

Notes and references

Links in the notes and references list open in a new window

1. Brian Chesky is the founder and CEO of Airbnb. You can learn more about him on wikipedia.
2. You can learn more about Peter Thiel, an outspoken entrepreneur and venture capitalist, on wikipedia. 
3. The Vehicle Identification Number is an alphanumeric sequence used to uniquely identify a vehicle.
4. A summary of a journal article in the Harvard Business Review says it clearer than I've seen it said before - "according to numerous studies in laboratories, workplaces, classrooms, and other settings, rewards typically undermine the very processes they are intended to enhance."
5. There are a number of reasons it's not good when people leave an organization - brain drain and the ills associated with turnover - hiring costs, overtime costs, low morale, and low productivity to name just a few - are just two of the big reasons.
6. "Let It Go" (Kristen Anderson-Lopez and Robert Lopez) as performed by Demi Lovato.

What's in a name?

Women face a number of barriers in science-based endeavors, perhaps more so than in other fields1. This matter is not really even open for debate. What is up for debate is whether or not it's justified and whether or not we will actually do anything about it.

Much debate surrounds the causes of the gender disparity evident in many fields. Some argue that girls and women do not pursue STEM2 educational programs and therefore either show a lack of interest in the topics or aren't generally qualified to pursue the programs. This is, almost certainly in part, due to traditional gender roles, but it cannot be limited to that as the limitations based on traditional gender roles have decreased as time has passed and societal norms have adjusted.

Another portion of the lack of pursuit of STEM programs by women is almost certainly self-inflicted doubts. This can be seen in a (1946) conversation between Einstein (yes, that Einstein), and a South African girl named Tyfanny. In corresponding with her, after she revealed her gender, Einstein said,

I do not mind that you are a girl, but the main thing is that you yourself do not mind. There is no reason for it.3

Einstein recognized, in Tyfanny's words, the self-doubt resulting from generations repeating the societal refrain "you're a girl".

These problems are significant, and we must fight tenaciously to overcome them; however, these facts alone are not enough. These are facts of history - facts that society has dealt with for years and yet, one might argue that while female representation is much lower in STEM-related fields, it is significantly imbalanced in many fields4. Why is this? Why are we not convinced that especially science, technology, engineering, and mathematics are about ideas and not something as trivial as gender? Are we really so blinded to not be convinced that women can think as well as men?

I refuse to believe that it is something in our conscious behavior, and I posit that our bias goes much deeper than we originally thought. Even though we have convinced ourselves that even if the larger populace does not subscribe to a meritocracy those of us in STEM-related fields are well into a meritocracy, we have deceived ourselves.

In what should have been a mind-blowing study written more than a decade ago, Rhea E. Steinpreis, Katie A. Anders, and Dawn Ritzke revealed that both men and women demonstrated gender bias in hiring recommendations.5 The subjects for this particular study were all PhD-level psychologists - people who should recognize that science is about ideas and not gender, people who should recognize trivial and non-trivial information for what it is. In a similar study, written just last year, it was demonstrated that even among science faculty at research-intensive universities, gender biases favor male students.6

What these two studies illuminate is that our gender bias is so thoroughly ingrained that even individuals who are trained to deal directly with data, identifying what is trivial and non-trivial on a daily basis, are incapable of suppressing something as trivial and unreliable as name-based gender bias. Before anyone starts with the 'academia vs. real-world' arguments, a cursory search regarding this topic yields some very interesting anecdotal evidence that supports the same hypothesis.7

We are, like the characters in Shakespeare's Romeo and Juliet, using names as a priori judgments. These two studies also speak volumes about our decision quality, our hiring and staffing policies, our integrity and values, our knowledge about our ability to evaluate people and ourselves, and even our ability to manage diversity.

When otherwise qualified candidates are eliminated from the process based upon their name it's easy to see where a significant portion of the disparity originates. We can work to correct gender stereotypes and eliminate gender roles from early education, we can do a number of things to encourage girls to enjoy and pursue STEM education and programs, we can even build gender-based groups that encourage and promote not just gender balance, but women in the work-force on university and work campuses across the country. None of our efforts to increase education, ban words, or anything of the sort will mean anything until we address eliminating the gender bias that is demonstrated to occur at the first step in any selection process.

Of course, one of the worst parts of this situation is that even though this has been a known issue for more than a decade, we've done nothing to change the situation even though it is incredibly easy. How easy? Here are four simple policies that every organization could adopt with little to no impact to their schedules or bureaucracy, which would alter the landscape significantly:

1. Publicize the existence of gender biases in relation to CV's and resumes and what is being done to compensate for it or correct it.
2. Replace names with unique codes on all CV's and/or resumes that are submitted prior to their being screened.
3. Restrict access to names and codes during the selection process
4. Identify discussion of a candidate's name as especially problematic and a punishable offense

As a bonus, when these policies are introduced, other name-based biases will be reduced or eliminated as well - the most notable are race, nationality, and religion, because when Juliet, in Romeo and Juliet, asks...

What's in a name? That which we call a rose by any other name would smell as sweet.

Romeo and Juliet, Act II, Scene II

...as it turns out, there's more than enough information, and if you don't believe me, just ask Romeo.

Notes and references. Links in the notes and references list open in a new window

1. You can find the research regarding the types of barriers women in science face, published by AAUW in "Why So Few? Women in Science, Technology, Engineering, and Mathematics", at http://www.aauw.org/research/why-so-few/
2. Science, Technology, Engineering, and Mathematics
3. This tidbit is revealed in "Dear Professor Einstein: Albert Einstein’s Letters to and from Children" by Alice Calaprice, along with views on gender's relationship to the study of science that were far ahead of his time - i.e. it doesn't matter.
4. One recent edition of philosophers' sound-bites (Philosophy Bites, by David Edmonds & Nigel Warburton) references 44 males and 8 females - a paltry 15%.
5. The study is called "The Impact of Gender on the Review of the Curricula Vitae of Job Applicants and Tenure Candidates: A National Empirical Study" and you can easily find it online and read it in its entirety - which I recommend.
6. The study is called "Science faculty’s subtle gender biases favor male students", by Corinne A. Moss-Racusin, John F. Dovidio, Victoria L. Brescoll, Mark J. Graham, and Jo Handelsmana. You can read it at http://www.pnas.org/content/109/41/16474.full.pdf+html.
7. In the blog post "I understood gender discrimination once I added 'Mr.' to my resume and landed a job", an individual seeking employment in a non-STEM-related field relates how self-identifying as a male on his CV made a positive change in the response rate to his inquiries.

One last note: If you follow this blog, you might have noticed that I've been missing of late. To offer explanation (not justification or apology) I will say that sometimes personal lives get very busy, we have a temporary shortage of creativity (e.g. writer's block), and we need time to work up the courage to say what we need to say how we need to say it rather than just exclaim "WTF!" and be done with it. For me, it's been a mixture of all of these as I've seen my oldest niece married, contemplated my daughter's education, and ruminated regarding how to address gender disparity in hiring for quite some time, even discussing the policies that will correct this with women in technology companies before writing this post.

Ambition

It's the middle of the year, so that means it's time for semi-annual reviews. Reviews are always a little difficult for me - in part because I was raised to believe that it was morally wrong to, as the saying goes, blow your own trumpet. This belief is so ingrained that in the past I've had difficulty with writing a CV or even effectively answering questions regarding my previous accomplishments during an interview for a position.

There's more here than just my ingrained beliefs, however; more that relates to ambition and how others perceive it. More that we in the corporate world refuse to discuss because we all know what the words and concepts mean. We are so convinced we know the meaning that we really need not think about the words or the concepts they convey. However, I wonder if perhaps it is that we don't really understand ambition, even though we think we know the definition.^[1]

As a case-in-point, I recently received a message from a former coworker - I'll call him Mr. Foo - that I'm going to paraphrase here, removing references that will identify who it was or which employer we shared in common. All edits will be enclosed in *[ and ]* to identify them.

When I was at *[our common employer]*, I was full of ambition and could not for the life of me figure out why you didn't put a ton of effort into sharing your *[tools]* with the *[rest of the employees there]* in a more formal fashion than just have them 755^[2] in your home dir.
... 

*[It]* might sound kind of weird, but in this weird way that chosen inaction on your part really stuck with me and I've always respected and always will respect you as an awesome developer and wise person in general...and time to time I think "well, Robert had this awesome stuff and didn't really share it or align himself with movement x y or z". There's wisdom in your actions, I think, and its taken me a while to come around to understanding that.

Now, I might have shared this message because this person referred to me as "an awesome developer" (and yes, I appreciate "awesome developer" more than "wise person" - it's better geek cred) and it's not really blowing my own trumpet because Mr. Foo has done it for me - that sort of ego stroking always feels good, but that's really not why I share it.

My thought today is this - most of us - and by most I mean nearly all, have become convinced that ambition and self-promotion are inseparable. They are not. Few of us have difficulty with people who are ambitious - at least to a small degree; however, more than a few have difficulty with those eager for self-promotion - people who, as they say in the western US are "all hat and no cattle"^[3]. While ambition is a necessary condition for self-promotion, it is not a sufficient condition.

My experience of the cycle of self-promotion rampant in corporate culture has been one that has shown it to be one of the most emotionally damaging issues confronting humanity. It is a vampiric greed that drains the soul of a person, because just as for the gun-fighter of the old west, there is always someone faster or willing to cheat just a little, and in the end you're just as dead.

In honesty, I created the tools Mr Foo references to make work easier - for me, sure, but for anyone who used them. I promoted the tools (not myself as author) on several occasions as something that could help resolve a problem but if others didn't use them I wasn't offended - I decided to not be bothered by the action of others.

That is not to say there aren't consequences for avoiding self-promotion. There are. It would be nice if the world - or our little part of it - were the meritocracy we teach our children it is - one where management paid less attention to self-promotion than work. Unfortunately, life is not nice - nor is the corporate world. If you're going to avoid self-promotion - the grasping greed of blind ambition - be prepared to get punched in the face, hard. People around you will not understand, and will likely criticize, your lack of ambition. Of course what they really mean is that you don't share their goals, but that will not be how it is put forward - this isn't a cooperative game with a win-win outcome, this is a bare-knuckle fist fight because people don't like what they don't understand, and people don't understand others who refuse to engage in self-promotion.

The good news, however, is that while self-promotion may not keep you from getting punched in the face, without it you're more likely to keep your soul in the exchange.

To Mr. Foo, if you're reading this and recognize your words, thanks for everything.

Notes:

1. Ambition: (a) an ardent desire for rank, fame, or power; (b) desire to achieve a particular end
2. 755 is the numeric representation of permissions for a file that indicates it is readable and executable by users on the network but only modifiable by the owner
3. Full of big talk, but no action; pretentious

Rockstars and Innovation: Stairway to Heaven

A friend recently posted a link to an article^[1] by Francois Marchand of The Vancouver Sun that covered a portion of the Kennedy Center Honors - specifically the tribute concert for Led Zepplin^[2]. Being a big fan of the Kennedy Center Honors, I watched this particular celebration when it aired on my local CBS affiliate, but the article brought something back to mind that I had temporarily forgotten - a question I had nearly every year when I watched the program - do stars realize they are creating something epic when they are creating it?

We know a lot about stars (divo or diva, if you will), especially in the US where we're constantly fed minutiae, from what they wear and eat to the foibles of their children and the sins that will be visited upon them - we even know about their demanding, uncompromising fits of rage and a little about how their attitude might be handled^[3]. It would be dishonest to imply that all the stars are thespians and musicians, after all, we in the technology industry have our share of stars (some of which, Steve Jobs for instance, have notable rants). However, we might say that all the stars consider themselves artists. It's with this area bordering aesthetics^[4] that I'm particularly interested.

First, I would posit that people, stars in particular, never realize the true nature of their creation - they may have visions of a possible future, but never fully grasp the import. Even some of the (arguably) most brilliant of minds do not realize the most minor consequences of their actions until they see the first glimpse of their creation come to life^[5]. One reason for this is that we simply cannot foresee the future. We cannot anticipate the many ways in which our creation will be re-arranged, re-interpreted, or re-worked.

A more important reason for this disconnect between the recognition of the impact a creation has and the birth of the creation, however, is in the very act of creation itself. The two events - the birth and the post-birth impact are bound to different understandings of time. Where the birth is held by kairos^[6], the impact - whether or not something is epic - is held in chronos^[7].

Some artists are entirely comfortable with this difference, willingly surrendering the telling of the story or the composing of the song to the moment and leaving the remainder to time and even going so far to say that they are driven only to create - storytellers have stories that they feel must be told, or in some cases, tell themselves, and musicians have songs they feel must be sung. It is the purity of this brief moment - a brief moment in which things are possible - that births what is epic, and even though we strive for perfection, we cannot intentionally create anything truly epic, for all of our planning and working - logos - is bound to chronos.

What does this say about pleas for organizational leadership for 'innovation' then? As we've begun to see, innovative has suddenly come to mean not only 'changed' but also carries the connotation of the change being epic as well. Innovative is revolutionary, evolutionary is passe.

There are only two directions in which we can move from this false understanding of innovation - recognize that striving for 'innovation' is irrational and therefore counterproductive, or move to the original understanding of 'innovation'.

Given that epic creations are rare and cannot be crafted through striving, strive instead to innovate in the true sense - change things, especially through small, non-fundamental (evolutionary) changes - changes like adding a choir to your arrangement of an iconic song. Not only does this approach involve less risk than major or fundamental changes, it can just as easily give birth to something epic - something that even the creator didn't imagine^[8].

Notes:

1. Heart plays Led Zeppelin’s Stairway To Heaven, makes Robert Plant cry, The Vancouver Sun, 27 December 2012.
2. Heart - Stairway to Heaven Led Zeppelin - Kennedy Center Honors
3. Robert's Rule #6: when working with rock stars, get your M&Ms ready
4. The branch of philosophy dealing with the creation, appreciation, and nature of art, beauty, and taste.
5. Oppenheimer, in recalling reaction to the first test of the creation produced by the Manhattan Project, said that he, and his fellow scientists realized the world would never be the same, and called to memory a line from the Bhagavad Gita, "now I am become death". [Video]
6. In mythology, Kairos (opportunity), was the youngest son of Zeus. He is described as running swiftly, balancing on the razor's edge, unclothed and with only a forelock - so that if you grasp him from the front, you might be able to hold him, but once he has moved on not even Zeus himself can pull him back. Because of this tie to mythology, kairos is the brief moment in which things are possible, and is a qualitative measure of time.
7. In mythology, Chronos is the personification of time and the serpentine consort of Ananke (inevitability) who co-creates the cosmos. He is not unending time (represented by Aion), but is the one turning the wheel of time and is, therefore, not a brief moment, but a quantitative measure of time.
8. Make note of the reaction of both Plant and Page throughout the video of Heart's rendition (see note 2).

What kind of engineer, indeed.

Several of my friends and colleagues have tweeted and otherwise commented about a post on the extremely knowledgeable Nick Zakas' blog.

I have a lot of respect for Mr. Zakas, and often enjoy his blog posts, learning something each time I visit, and this post was no exception. Unfortunately, there is also a point with which I don't agree...but it's not really Mr. Zakas' point. He says,

If you stop and think about it, writing code is something that a lot of people do. You can hire someone cheaply out of college to write code and it may not be as good as an experienced software engineer, but if it’s close enough, that’s usually all you need. So if your programming acumen is the only thing that you focus on, you aren't improving your position in the company. What matters far more are the soft skills that you have along the way. Do people enjoy working with you? Do you add something over and above your coding skill?

First, to Mr. Zakas' point, there are a lot of people who can code...but there is a potentially significant difference between "close enough" and "correct". With "close enough" your revenue most likely will not be zero, but it will also likely not be as much as it would with "correct"...and in some situations, "close enough" may be nowhere near close enough. If we're talking about a web page that responds in 8 seconds instead of 4 or 6, that may be one thing (though you might want to see my earlier post about speed in websites, Faster, faster, faster) but if we're talking about real-time or life-critical software, is "good enough" really good enough.

Still, Mr. Zakas is correct in that our reputation is important...but therein lies my problem, and it's demonstrated to a degree by those Peter Hinssen refers to in Will the real CIO please stand up - individuals who associate responses to the phrase 'IT departments' which are "wonderfully colorful comments such as 'arrogant', 'out of touch with reality', 'language of their own' and - increasingly often - 'hopelessly out of date'."

Are there engineers who are reasonably considered "arrogant" or "out of touch"? Certainly, and, I suppose if Mr. Zakas' post were geared toward those engineers alone, we might not have anything to discuss. Note, however, that Mr. Hinssen's post discusses the prevailing attitude. If we see "arrogance" and "hopelessly out of date" as the status quo, then I would posit that Mr. Zakas' advice to adjust our attitude addresses a symptom of the underlying problem without addressing any of the underlying issues.

In part, the prevailing attitude - that we are arrogant and out of touch - is our fault as software engineers. Whether we write software for the World Wide Web, smartphones, or desktops - we have, to some degree, failed to convey our value to the organization. Often we do speak a language of our own, and life would be much easier (from the perspective of those who see us as arrogant and out of touch) if we would just communicate more/better/the right way - if we would stop being so out of touch - if we would stop seeing ourselves as so valuable to the organization - after all, the contribution of an engineer is not that significant because "writing code is something that a lot of people do" (emphasis mine).

As a User Interface Engineer (or web developer, if you'd like), I often hear comments similar to this - comments about how someone's teenage relative can build a good web page. While there are, of course, prodigies, the amount of engineering that is required to create the best web page is significantly greater than the skill level held by general practitioners, as is the amount of engineering required to create the best software for other media. I would posit, therefore, that our challenge is not as much improving our soft skills (though every engineer I've met would benefit from such development), but rather conveying our value to the organization in a meaningful way. To that end, as a counterpoint to Mr. Zakas, I would commend a quote that Baskin-Robbins used to hang in their stores: "there is hardly anything in the world that someone can't make a little worse and sell a little cheaper - and people who consider price alone are this man's lawful prey."¹ 

There are a number of issues that might be discussed when an organization perpetuates a culture similar to Mr. Zakas' comment above (that people who code are a commodity) or similar to those Mr. Hinssen references; however, one of the most significant is that organizations which learn to accept "close enough" when it's less expensive incur technical debt that becomes deadly. Further, the effect such an attitude has on morale within the IT department can be equally as deadly as mounting technical debt.

There is, in my estimation, another side to this story. In the face of significant potential issues, such as creating code that's "good enough" under one estimation and not another, mounting technical debt without having resources to address it, and demotivating personnel, there is also the thought that perhaps the perception of engineers as weak in soft skills, arrogant, and out of touch, is mistaken. Perhaps, just perhaps, those engineers are instead are significantly different than other employees.

Perhaps these engineers are not arrogant and out of touch. Perhaps there are weaknesses related to their soft skills, but if we, instead of operating from the assumption that what these engineers do is something that a lot of people can do, operate from the assumption that what these engineers do is something that few people can do, and that they are therefore in a different realm than others, might we see their "arrogance" as an indication they have a different understanding of their capabilities and the situation? Might the perception that they are "out of touch" be due to the manner in which they, in their different world, relate to those outside  of their area of expertise.

Let us consider then, the possibility that their "arrogance" and being "out of touch" are, at worst, simple weaknesses in their soft skills. What is the best advice? Certainly Mr. Zakas' advice is good, and traditional - work on your weaknesses. However, is that really the best way in which these engineers can contribute? In this consideration, I would offer the following advice that Dr. Donald Clifton gave his son: "your weaknesses will never develop while your strengths will develop infinitely."²

Let me be clear - the best advice the creator of the Clifton StrengthsFinder, Gallup's own online psychological assessment, could offer his son, was to build his life and work around his strengths rather than try to fix his weaknesses. For Dr. Clifton's son, and many engineers, Mr. Zakas' words, and in fact the words of those who brand us as "arrogant" and "out of touch" would have them "fix their weaknesses".

In this, I would posit that rather than engineers spending time fixing their weaknesses, that they spend time using and developing their strengths, and that management (at all levels) spend time seeing and celebrating diversity and the value it brings. I understand this is unconventional wisdom, but perhaps, just perhaps, this is a new age - an age in which each of us can contribute to our fullest.

What kind of engineer do I want to be? One that develops my strengths infinitely.

1. This quote is attributed to John Ruskin, though there is some debate about whether or not that attribution is valid.
2. Reported in a post by his son.

Following the eight-fold path

Following your passion is probably not the worst advice ever, but it's easily not the best. For most of us, it's simply impossible. Oh, we all dream of being a rock star/athlete/astronaut when we're kids, but seldom do we even find the energy or opportunity to fulfill one passion. So, what do we do? How do we find fulfillment and happiness while at the same time settling for something that pays the bills?

1. Find your one thing. What is it that you want? Deciding to follow your dreams can be a terrifying, thrilling, and dangerous activity - but then again, deciding to abandon your dreams to the dustbin is too. It's helpful to keep in mind that your 'one thing' is not a specific plan, like to be a rock star/athlete/astronaut, but is a more general idea, like living simply, having power and influence, or making a difference.

2. Be flexible. There is seldom 'one perfect job' - but there are often a few not-quite perfect jobs, several workable jobs, and countless run-away-as-fast-as-you-can jobs. Flexibility frees you from the need to find 'the job', helps prevent you from chronic (and frequent) job-hopping, and it also lets you select jobs that encourage you to focus on you (more on this next). Since job-hopping can be an effective career killer, this is pretty important, but this last bit is really the more important of the advantages, because it gives most any job the potential to be one in which you can find and grow your passion.

3. Focus on you. Simple, right? A few really interesting studies have shown that competence and autonomy yield higher rates of job satisfaction than other factors. (Check out Drive: The surprising truth about what motivates us for more information.) To keep it simple, ask yourself "how do I get better?" By answering this question, you'll increase competency (keep in mind Robert's Rule #1) and as a result, you'll most likely increase your autonomy. Just keep focusing on you.

4. Look to the stars. This is the companion to focus on you. This will answer much of the question about how you get better. The stars who do the same work you do will show you the skills you need to hone to become better. Often, they will enact those skills without even noticing what they're doing, so asking them "how do I get better" will most likely not yield the results you expect (see Robert's Rule #3). Instead, observe them - note what situation they address and how they address it, ask them to mentor you, ask them questions about their skill that make them think, but don't ask them "what do I need to know" or "how do I get better" - those are your questions to answer.

5. Become visible. There is a theory that if you're invisible, you're less likely to become redundant, "riffed", or otherwise "terminated". Perhaps there was a time that line of reasoning was true; however, job security of that sort is truly an anachronism. While it may be that the squeaky part gets the grease (or gets replaced), very few employers are a pure meritocracy, and even in a meritocracy there is the concept of 'winking in the dark' - so increase your visibility.

6. Understand what you value. As you focus on you and become more visible, those you work for will begin to see your value. As the organization sees your value, they will (most likely) push you toward those roles and activities which they value. It stands to reason - after all, who wouldn't want their best employees on their most important projects, right? Keep in mind, however, that what an organization values may not be the same thing that you value, and following what someone else values may take you off your path.

7. Be relentless. Passion is called passion for a reason. If the potential you see does not drive you, if it is not a goal you can taste without which life would be a miserable, empty shell, settle. The work is too hard and your ambition is not enough. On the other hand, if there is a single thing you want more than anything else, then in the words of Yoda, "do or do not, there is no try".

8. Leverage your value. As you follow the path, it can lead you to a point where you can leverage your value. Here's the payoff for all your hard work. Here's where you get to follow your passion. You may not the rock star/athlete/astronaut who gets to sing the national anthem before the championship game where you score the winning point before the manned mission to Mars, but maybe, just maybe, you'll be able to follow your passion, and like friends of mine who have become the surfer-web developer, the hiker-photographer, and the UI engineer-disc golfer.

Trust everyone at the table, but cut the cards anyway (Robert's Rule #18)

[Tweeted 2011-06-06]

Living in an area where there are multiple casinos within a short drive or a long walk, I've learned to see some things using gaming metaphors. One of these metaphors is trust everyone at the table, but cut the cards anyway (Robert's Rule #18), and if you are an empiricist like Hume, then this rule will automatically make sense.

How does it apply to work? First, if you are not able to trust your colleagues, work (and probably life) will be miserable. Of course the reverse is also true; trusting your colleagues will go a long way in making work not be the worst part of your life. In fact, I've had some jobs I should have hated because they were such a poor fit and yet I didn't because of my colleagues.

Second, not only will the inability to trust your colleagues make life miserable, it will be very difficult to accomplish what you need to accomplish as well. The amount of time you spend countering the machinations of office politics in a hostile environment will outweigh whatever other successes you have. In addition, those times in which you don't succeed your discomfort will be worse because of the negative self-talk that comes out of the lack of trust and your assumptions about yourself.

Of course, this doesn't mean that you should just blindly trust. After all, your trust can be pretty easily misplaced, and this is your livelihood we're talking about here. You can't just go about willy-nilly assuming that everything your colleagues do and say is true, and even a series of lucky guesses ends sometime, which is a very good reason to confirm what you believe to be true.

Of course all of this is to say trust everyone at the table, but cut the cards anyway.

No matter how many Novices you add, they'll never equal one Expert (Robert's Rule #16)

[Tweeted 2011-06-01]

One of the typical responses to a project that is behind schedule is to add people to the project with the intent that they will be able to further subdivide the work and develop in parallel, getting the project back on track.

This, of course, is part of the problem in defining software development project timelines using straight developer days or 'man months'. Part of the difficulty lies in the idea that all tasks can be subdivided (hence the concept of the 'mythical man month'). If we apply the idea that all tasks can be subdivided to areas outside of software development, such as pregnancy, then the erroneous conclusions become obvious; after all, we all know that 9 women cannot complete a pregnancy in 1 month.

One of the other, lesser known aspects of Brooks' law is the concept of a 'surgical team' which identifies 'good' developers and 'the rest of the team'. While I won't go into all of Brooks' concepts in detail, this concept deserves special consideration, in part because Brooks estimates that 'good' developers are 5 to 10 times as productive as mediocre developers. In addition, if we factor in the effects of a higher degree of skill on quality we can easily see the error of our ways.

So, next time you're trying to get a product out the door and it's repeatedly behind, remember that not only does it matter how many people you add, no matter how many Novices you add, they'll never equal one Expert (Robert's Rule #16).

One who waits for the ax to fall will surely lose his head (Robert's Rule #10)

[Tweeted 2011-05-06]

One of the most uncomfortable things we face in IT is the layoff, and anyone who's worked in IT for any length of time has felt it.Usually it starts as a rumor that the company is not doing as well as projected and then there are cutbacks in different areas of the budget and eventually, the company starts reducing the number of staff.

In the past, I've been on both sides. I've gone into a company to install a computer system and been met with "you're the one who's going to take our job away" and I've heard "we're cutting back and we have to let you go". It's never comfortable.

Some react to the situation by railing at their (now former) employer and some quietly accept their fate, attempting to say nothing derogatory. In my experience, neither reaction matters much, because everyone expects that those cut will have some negative feelings.

In contrast, actions before reductions appear to matter. In fact, sometimes you can even avoid being the subject of a reduction in force by proactively changing departments or roles. Adjusting your career to new situations isn't earth-shaking advice, but even so, some people tend to settle into a specific role and not want to move forward or even sideways. Such stasis, however, is deadly, because the one who waits for the ax to fall will surely lose his head (Robert's Rule #10).

You are not your job, you are a person (Robert's Rule #8)

[Tweeted 2011-05-04]

Like many people, I get asked "what do you do" quite often. At times it's been rather difficult to explain to people who "don't get" computers. In fact, one person went so far as to say I didn't really work because I didn't "make" anything. It took me a while to determine that, in his mind, unless you contribute to the production of a physical item in a meaningful way, you aren't really working and you shouldn't get paid. Thankfully, there have never been very many in my circles who have held the same belief.

Another problem I've had in responding to the question is until recently "what do you do" has been a little vague, or imprecise, rather because I've always done several things simultaneously. When I started out in the industry, I was an "Installer". As an Installer, I traveled a region and installed payment systems, trained the users, performed any troubleshooting required, made sure the customers had the supplies they needed, wrote customer service utility software, et cetera, et cetera. After I moved on from that job to client/server development and became a "Systems Programmer". However, 'programmer' jobs were usually more analysis and design than actual development, and then added to that were DBA duties, managerial duties, et cetera, et cetera. When I moved from the client/server environment to the web and became a "ColdFusion Developer" or a "Web Developer", it generally didn't reduce the scope of work much as there were design duties, development duties, network/server administration duties, DBA duties, et cetera, et cetera. Basically, there generally has been more 'et cetera' than distinct role duties.

All of this poses a problem more for existentialists than essentialists, I suppose, so perhaps it's only a problem because of my perspective, but perhaps not

I guess you might say at certain points in my past I've been an Installer-Trainer-CS Representative-Field Engineer-Programmer or Systems Programmer-Data Analyst-DBA-User Interface Designer-Technical Writer-Manager or System Administrator-Web Server Administrator-Programmer-DBA-Web Developer-Web Designer. All of that sounds really complicated and imprecise simultaneously. Besides, I noticed that any time I've been 'between jobs' I've never stopped 'being', so a change in perspective was required and I came to the startling revelation that you are not your job, you are a person (Robert's Rule #8).

As a result, when people ask "what do you do" I no longer respond "I'm a [insert title here]", I generally clarify whether they inquiring in what capacity I'm employed or if they mean something else. If they're inquiring about my work, I say "the majority of my work is as a [insert title here]"; if they mean something else, then I answer their real question to the best of my ability.

There are a few side-effects that I've noticed when verbally recognizing this small truth. First, people generally take a moment to consider what they're asking, which tends to move the conversation quickly out of the in-one-ear-out-the-other chat (that drives me mad) into a realm of real conversation. The second side-effect that I've noticed is that I feel more free to balance work and non-work life. For example, the majority of my "outside-the-home work" may be as a system administrator and that may entail thwarting network attacks, but the majority of my "inside-the-home work" is as a husband and father and in both inside and outside the home I am a person. That means, for example, that there are some meetings I don't take (such as those scheduled during my daughter's bedtime when I'm supposed to be reading her a story or singing a lullaby) and some job opportunities I will never pursue (because they would require me to sacrifice some portion of my humanity).

As far as I can tell, we all have only one life to live. At the end of mine I hope that my wife and daughter say "he was a good man"...anything else just won't do.

When working with rock stars, get your M&Ms ready (Robert's Rule #6)

[Tweeted 2011-05-02]

Most managers I know claim that they would love to have a team of rock stars. Most of the time it's pretty clear that's because a team tends to make a manager look awesome (or not). It makes sense that managers would conclude that a team of rock stars would make the manager look like a rock star as well. Not all teams are comprised of rock stars though, and those that are tend not to maintain cohesion.

For a while I tried to determine why this is the case...why is it that a group of people, especially one where the majority is highly skilled, would spin apart after a period of cohesiveness. Here's what I've discovered: highly skilled people tend to not only be highly skilled but also have their own style, and everyone else's style is not as [insert your descriptor here]...and, simple as that, you find your rock star has become a diva, a word that has connotations beyond the "star" quality that it denotes.

There are two ways I've seen managers react to divas on their team:

• they tighten control as much as they can, making sure the "diva" knows the manager is in charge
• they stay out of the way of the "diva" as much as possible, working behind the scenes to make sure the obstacles are cleared

Having been on both sides of this particular equation, allow me to share the following. Reacting by making sure the diva knows the manager is in charge will backfire. The manager may be in charge, but yanking a dragon's chain seldom ends well. At the very least, the rock star will become miserable and rebel, reducing team morale and in some cases the rebellion has resulted in political intrigue that results in the termination of one or more of the parties. Keep in mind that even as a manager, you're only in charge as long as you're actually employed and have employees reporting to you.

In contrast, one of my best managers, one who dealt with several highly skilled technical people, all with strong personalities, said her formula for success was to hire rock stars and stay out of their way. That she enjoyed the success of a team that delivered solid, feature-rich, complex products ahead of schedule and under budget with extremely low defect rates is a testament to the validity of her approach.

She didn't sweat the small stuff and made sure that her team was rewarded adequately, and most importantly, she made sure that even if she didn't initially understand the reason for a request, she tried to move towards honoring it at the same time that she sought to understand it because, as it turns out, rock stars tend to have very good reasons for seemingly odd-ball requests (one of the most famous examples).

All this led me to Robert's Rule #6: if you want your team to be rock stars, expect a few divas and get those M&Ms ready.