Hard software problems

Lately I’ve been thinking a lot about how I could build software to solve really hard problems.

Recently Y Combinator put out a call to kill Hollywood.  I agree with the principle…  but this is not a particularly hard problem.

Let’s talk about something hard.

Let’s use software to stop rape.

I don’t know how to do this, but we can do better.

I think I can write a mobile app which can detect when someone is being assaulted and automatically phone for help. 

I think I can write buddy-system-like app which can connect solo girls with trustworthy strangers at bars who can walk them home. 

Let’s use software to stop suicide.

I don’t know how to do this, but we can do better.

Reddit has created a beautiful thing.  Go there now.  If you don’t come back, that’s fine… it happens.

I searched for Suicide Hotline in the Android App Market.  The offerings are weak. How about a decent Suicide Hotline app?  It’s really simple:  Your app’s icon says “help”, and when you push it you get to a screen that says “You’re ok. We’re here for you.” and there’s a single button which calls your local suicide hotline.

Let’s use software to stop child abduction.

I don’t know how to do this, but we can do better.

More and more kids today have cell phones.  Let’s make an app which works like this:  Every 30 seconds, your phone will chirp to other phones in the area.  If someone goes missing,  track the last known locations of the person and contact all of the witnesses.

 

 

My ideas so far are all just attacking the low-hanging fruit.  They’re mobile-centric because that’s what I happened to come up with. There are better solutions and bigger things to investigate.  These are hard problems, and let’s be honest- my ideas suck.  But even though they suck, they could make a difference.  I find that both sad and inspiring.  It’s feasible that a weekend project could save a life.  There’s no need to get Orwellian, let’s just work on these.  What are you doing next weekend?

Be creative every day

One of the most beautiful things I’ve seen in recent memory was this delightful… thing.

http://www.drawastickman.com/

It ended with a fantastic message.  It’s something that resonated with me and something that I already totally embrace but fail to fulfill.

Why are you still reading? Go draw a stickman. I’ll wait. Go!

Great, so now we’re on the same page!

So, aside from the message, something I really loved about that website is that everything it did was within my grasp.  I could have made that.  My artistic ability, primitive as it is, could have created that.

So why didn’t I?

Hmm.

There was a hacker news link to a interesting Stack Overflow question earlier today.  I read the question and….  was appalled.   The educators initial thought for how to illustrate programming to students…. involved math!  “NO, that’s Wrong!™” thought I. 

…And then I didn’t answer the question.   It entered my mental queue.  I can construct a “good™” answer to this, but I didn’t.  Or at least, haven’t yet.

Hmm.

Well then.

The Godenites would shout about how it’s due to my lizard brain.  Maybe.  Maybe the reason I don’t act on every impulse or every thing I think I can contribute is because of a fundamental human fear of failure.  But I somewhat aspire to mania…

There’s merit to being a little bit insane.  Not legitimately insane, mind you – just a social aberration.  Willing to speak when unexpected or not speak when expected.  Or perhaps just embedding a song in my stride as I walk down a hall… wondering if anyone notices my slightly off-kilter footsteps.

Or just asking the obvious question.

I lied… I don’t aspire to mania or insanity.  I aspire to reason and thoughtfulness… but I enjoy the unexpected. The intrigue of abnormality. Thoroughly.

 

Sometimes I write under the guise of a cynic.  I don’t wish to be negative … actually I’m always quite upset when I catch myself caught in a context of negativity: I wish to drown out my world with positive perspectives whenever possible.  It’s better that way.   But cynicism is interesting.  The devil’s advocate is both a fun and important role to play.

I wrote a haiku today, and I won a refrigerator.
I don’t think there was much competition, but it’s perhaps the most monetarily valuable poem I’ve ever composed.  There’s a novelty in that, and I suspect that in time the novelty will prove itself to have been more valuable to me than the refrigerator.  Though I’m sure it was entirely unintentional and unrealized, the invitation to write a haiku in exchange for a refrigerator was a delightful gift that I received today.  I think there’s a great value in giving gifts like that to the world.

 

Next time you leave a tip with a credit card,  write a haiku on the receipt.   Have humble trust in your gift of novelty being appreciated. It will be.

 

For Christmas this year, I purchased one present.  A simple item that would cause a smile.  It’s important to have something under the 10” tree.  The rest are a stream.  I have envelopes, glitter pens, a vest, a girl who loves dancing, and I know how to combine them.  Protip: do not combine the glitter pens with the vest. The true gifts will trickle in, and their objective is simple and clear:  maximize the experience.  Theatricality is paramount;  cost, practicality, and sanity.. less so.

 

And so I meander.  Most of my writing evolves in this way, and then I edit viciously.  Early in my writing development I discovered that the antithesis of creativity is the blank page.  There was a time when I had to provide a 5-point essay on the topic of my choice… every day.  I learned to write them in 10 minutes. Watch:

This is literally the first paragraph of the essay.  It’s not of consequence that it’s a paragraph talking about how it’s the first paragraph of the essay, all that matters is that the page is no longer blank… instead, it’s a page with a paragraph.  I’ve started many a good essay with a paragraph on ewoks, lines from a Cream song, or assorted daydreamy thoughts.

Now we’re on to the second paragraph.  Grasp something, anything, from the first paragraph and make a point from it.  It doesn’t even matter if the grammar is repetitive.  The topics of my daydreams have drifted in time.  As a child, I focused primarily on sensational topics – running, climbing, jumping, feeling, tasting….  As a teenager, I drifted more toward … err..  well..  girls.  That one who smiled at me, especially.  What was her name?   Just kidding, I remember perfectly well.   But in adulthood… now it’s about change.  Be the change you want to see in the world™.  Disrupt a flow; optimize an edge; kill all humans; find a new way; channel Feynman.

…

The third and fourth paragraphs are easier now.   Grasp the topic of the first paragraph – day dreams – and take it in two different directions.  The fifth paragraph is a little more of a challenge, but the objective is pretty clear:  You need at least three sentences.  That’s easy enough…  in one sentence each, recap each of your 2nd, 3rd, and 4th paragraphs.  Add a leading sentence if it helps the flow.  Now in your final sentence, draw a conclusion based on the three sentences you just wrote.  Something novel and logically following (however absurdly) from those three simplified sentences.

Now Edit Viciously.   The introduction? The paragraph that starts by saying it’s an introduction, and then talks about ewoks?  Kill it.  It’s crap.  …But you’ve got 90% of the rest of the essay done, so it’s easy to actually introduce the thing that you’ve already spent 4 other paragraphs talking about.    Repeat this for paragraphs 2 through 5.   We want to pull the insanity out… but not quite all of it.  That reference to channeling Feynman?  That was creative and relevant! Keep that bit.  Keep the crazy bits that actually fit™.

And now we have an essay.

Hypothetically, I mean.

This thing you’re reading now? It’s not an essay.

It’s closer to stream of consciousness writing.

Most of my writing starts this way, and then I edit.  Viciously.

 

Editing brings in its own problems… because that’s where I introduce most of my typos and grammatical mismatches.  It’s harder to rewrite a flow than to live with what was there in the first place.  It’s harder to read code and fix its bugs than to write it fresh.  It’s easy to have had things, such as them, and a thing, such as it, and keep their pluralities and tenses proper when you morph their amalgam to what they were and this is.  Editing that type of absurdity will only get you in trouble,  but it came out fine the first time through.

 

Which is why I’m not going to edit this.   I backtrack slightly as I write,  but most of what’s here is raw.  I’ll probably read through this at some point in the future and fix up a typo or a grammatical idiocy,  but until then I’m going to throw this to the wind.  Because I’m done writing now.  I created something and it was joyous… and picking through it for flaws will not be joyous.  I have my MVP and I’m going to ship it. Right now.

I hate cell phone service companies.

Ever since my first Verizon phone back in high school, I’ve always felt somewhat abused by cell phone service providers.  I’ve never paid for any other service which

• Charges me monthly fees completely disproportionate to their operating costs
• Presents their billing agenda in an intentionally convoluted manner
• Bills me based on services that are trivially available for free via the internet

The only stupider thing I’ve ever paid for was a gym membership. 

This adventure started as I began investigating MetroPCS.  They promote themselves as a Metropolitan-area-centric, cheap, no-BS company.  Disregarding phone quality, I would say that they appear better than the big boys, but my week trial with them was sufficient enough to show me that they were still pretty lame.

This made me ask myself a tough and obvious question: why have I been paying over $100 a month to companies I hate for services I’m unsatisfied with?  Because I’m an idiot.

Moving forward…

-  Stirling and I have cancelled our cellular plans, and our old numbers are now dead.  We’re now both using our Google Voice accounts as our primary phone numbers.  They can send and receive calls and text messages for free and have much better email integration than anything else.

- I purchased a ViewSonic G-Tablet, which is a joy.  There’s wireless all over NYC and Brooklyn, so I can use that tablet to stay connected to the internet and send/receive calls.  It has the added perk of being a mobile internet device which isn’t infuriating to use for things like composing email, and there’s no Apple silliness to deal with.

- We purchased a super-cheap prepaid phone from Virgin Mobile.  Of the cell companies, they seem to be the least sleazy, but it still makes me feel a little dirty.  We’ve realized that while cell phones are unnecessary for the vast majority of our phone and text message usage, there are a few exceptions: Travel; Logistical coordination on the fly; Urgent calls from work.   A cheapo prepaid phone with tiny amounts of minutes solves all of those issues.  This lives with Stirling, since if we’re not proximate then I’m probably at work and have internet.

It’s working well so far, and I hope to never subscribe to the cellular overlords again. 

There are a couple kinks in the new system that we’re still working out…  once done, we’ll propagate our new phone numbers to our contact lists.

But… you know what feels really good?  No more cell phone bills.

 

P.S.:  Just because paying for cellular service made me an idiot, that doesn’t reflect on anyone else. My stance here is fairly heavily based on my monetary philosophies and the amount of time I spend using my phone (very, very little).  There are lots of valid use cases for phone plans, I just don’t think I have any of them.

Autonomy, Mastery, Purpose

I just watched an amazing presentation about the economics of incentives in the context of highly creative work.  It’s highly relevant to software development, and yields some interesting insights into the prevalence of free and open-source software.  You should watch it immediately [source] :

http://www.thersa.org/events/vision/animate/rsa-animate-drive

While I enjoy hearing these things explicitly stated in a research-backed manner, I also feel like this video is highlighting what is otherwise common lore in the software development community.  Specifically:  Autonomous developers are more creative; People tend to be happier when they are improving their skills or learning new ones;  understanding the purpose of your job (and being fulfilled by that purpose) is essential if you want to feel like more than a cog.

After watching this video, my thoughts immediately turned to if I feel my environment is sensitive to these traits.

Autonomy

At the company and product levels, I’m pretty vocal about my opinions. Although it’s not uncommon for me to be wrong, disagreed with, or emphasizing something of too-low priority to matter, I have never been stifled and I feel that many of the things I’ve said have been acted upon.  That’s satisfying.

At the development level, I always feel like I’m in control over how I should go about things.  Well.. maybe “control”, is the wrong word: external feedback is very valuable to me, and I will generally not proceed if there’s someone who feels that my path isn’t the best one.  Lack of consensus seems to always indicate a communication failure or a valid opinion which hasn’t yet been considered, so I think consensus is important to achieve.

Do I feel like I can literally work on whatever I want when I come to work?  Well… “what I want” is tricky.  I feel that I often have a sufficiently complete picture of the product that “what I want” often corresponds with the current development focuses.   There are some killer features that I very much want to do, but if they’re not already on the top of the queue then there’s something more important in front, and if I agree with the importance, then I want to do the more important thing first.  It’s very uncommon that I disagree with the current priority queue, and I have yet to find myself working on something that I didn’t feel I should be.

Pitfall:  It seems like if devs aren’t in touch with the current product vision or the current prioritization methods, it would be easy to create situations in which devs are working on the things that they don’t feel like they should be working on.  This would be bad.

Hobby projects are important to me, and I feel they greatly aid my feeling of autonomy.  This article is one such example;  I’m in my office right now (Sunday afternoon) because I felt like doing something abnormal, and this is my most favorite environment to be creative in.  Tidy Case Events is one of my hobby projects created in this manner, and it’s wonderful to work on and exceedingly wonderful whenever I get an email from someone who is happy with my work.  I feel like I have energy for hobby projects because I’m not burned out after work… I like that a lot.

Pitfall: It seems like dev burnout (via overtime or otherwise stressful conditions) will damage autonomy, as the devs won’t be as likely to have pet projects outside of work.

It seems to me like autonomy breeds mastery and purpose.  If mastery/purpose aren’t otherwise provided, but autonomy is, then we can autonomously give ourselves mastery and purpose.  For instance, I was interested in learning about CoffeeScript and the Google App Engine, so I used my Creek Week (like “FedEx Day” except spread out over a week) to create a new product written for GAE using Python and CoffeeScript.

Conclusion:   I feel autonomous.  Win.

Mastery

In college, mastery was always related to how much passion I chose to have for a topic.  I mastered data structures because I investigated it on my own, because I asked questions and tried new things, because I pursued advanced topics, and because I started teaching others about how they worked… not because I took a data structures class.   The class was certainly an enabler, however.   I feel the same pattern applies toward subject mastery in industry.  I’m gaining mastery in C# and JavaScript because I push myself to try new things when I develop new code.  I know I’m advancing whenever I’m embarrassed by code that I wrote 6 months ago.

So… I think mastery is mostly a personal thing.  You’ll either strive for mastery, or you’ll be lazy about it.   I’m certainly lazy about some types – cmd is still my dominant command prompt in Windows, and I well know that PowerShell is vastly superior…  but I’m not fascinated by PowerShell and am happy enough with cmd that my command line skills are stagnating.

Pitfall: I think crunch time is damaging to mastery.  If I need something fixed *now*, I’m not necessarily going to learn the best way to fix it, I’m just going to fix it the fastest way I know how.  Creative time, on the other hand, aids mastery-  finding the better way to solve a problem rather than going with the known way.  Good stuff.

Outside of self-drive, it seems like companies can still provide a great service by providing enablers.  As with my data structures class,  while it may not have pushed me to mastery, it opened the door for me.

Some enablers I’ve experienced in professional development:

• Weekly peer tech talks.  These commonly expose me to new topics or at least new ways to do things. 
• Guest Speakers.  I had a lot of fun siphoning knowledge from Patrick and Brent.  They helped expand the amount of things I know I don’t know, which is always great.
• Conferences.  I’ve been selecting Business of Software… and I dig it.  It’s like an enabler for other enablers.  B.o.S. has introduced me to people like Dharmesh Shah, who is a brilliant person that I’ve since learned many things from via his writings and talks, and Seth Godin, whose daily insights occasionally strike a powerful chord and whose books strike many.
• Code reviews…   My peers push me to write better code, and I learn to write better code by observing them.  I love code reviews.

…Yeah, I feel satisfied in terms of moving toward mastery.  I’m commonly learning new things, and that feels good.  I have a long way to go.

Purpose

I suspect a lot of people invent their own purposes when the overarching purpose of their work is unclear (or disagreeable) to them.  I certainly did that throughout high school and college.

I’m lucky now, as I don’t need to invent my own.  I work to help other developers around the world make better software, and there are countless more things to do.  I work in a competitive field, but I feel no animosity toward our competitors: they’re all developing tools to help other developers make better software.  I think our competition will help us push each other toward better products, and that’s excellent for developers everywhere.

“Somewhere today, a project is failing” 
– Peopleware

I’m helping to fix that. 

Redditerations 1

Well that was fun…  I picked an opinion that seemed generally useful, wrote about it, submitted it to /r/programming, and got some feedback.

Via Reddit, I received 420 page views (quite a bit higher than my normal 5-10), 3 upvotes, 2 downvotes, one blog comment, and 4 reddit comments.

The feedback was mixed.  It’s interesting to me that all of the feedback which I would consider “negative” is based on points that I didn’t intend to make, and some of it seemed a bit absurd.  That’s ok though, because it’s great feedback none-the-less, and I like feedback.

Some trends I noticed that I’ll experiment with next article:

1. I ended my article with a prompt which nobody responded to.  This may just be an issue of sample size, but it seemed pretty pointless.   I’ll not do that next time.

2. I attempted to make two core points in my last article. One point was made (relatively) concisely, while the other was extremely verbose and example-driven.  All of the criticism I received was related to the verbose component, while the concise component was either unmentioned or praised.   I suspect this is caused by two negative traits of the verbose section:  Since it was long, more people skimmed it and thus had a higher chance of misinterpreting my intent or falling back on their existing assumptions; Since it was long, there were more opportunities for me to communicate unclearly or accidently broaden the focus of my article.   I’ll get more concise.

3. Examples seemed to strictly hurt me.  That may just mean my examples were poor or they implied a lot more than I intended. I’ll try omitting examples next time.

4. Referencing my affiliation with Fog Creek seems (at least based on the tiny set of commenters) to be strictly negative in the scope of blogging.  I’ll just omit that in the future… it’s not necessary.  I think Fog Creek is awesome, so I tend to reference that, but it’s not necessary, and certainly its quality is higher than that of my articles.

I don’t know what my next topic will be, but I’ll write it with these points in mind.

Stylistic defaults and awareness- a neglected college lesson.

I am a young SDE.  I’ve worked in “industry” for Fog Creek Software for a little under two years now (including my internship), which means that the bulk of my software development career occurred in college. 

Although most of my development time may have occurred in college, the vast majority of my productivity has occurred while working at Fog Creek.  This is interesting to me, and I’ve picked up many practices in industry which were generally outside of my programming repertoire as a student.

Some of these items are simple and obvious: fluency in debuggers, code editor/IDEs, version control systems….

Other items are less obvious, at least they were to me.  One such item is programming style.  To be specific, I’m talking about what would commonly be documented in a “Coding Style Guide” for a given language.  In programming teams of any scale, language-specific style guides are extremely beneficial, so much so that companies like Google will have style tests that must be passed before a programmer is allowed to develop in that language.  While I think mandates of that nature can be beneficial, I feel that the more important skill is for a programmer to have a conscious awareness of their surrounding code, and a good set of defaults.

Defaults are more generally applicable, so let’s talk about those first.

Good Defaults

Part of my job at Fog Creek involves interviewing potential hires and interns.  I don’t generally count coding style as points for or against the candidate unless it’s remarkably good or bad.  A common pattern I see in (failing) candidates is an inability to name their variables well, followed by moments of them struggling with their own code and introducing bugs because of confusion caused by their own poorly-named variables.  Even in strong candidates who have no trouble following their own code, it’s uncommon for them to not ponder a variable name for at least a few seconds.

These things are happening because they don’t have a strong set of defaults.  At Fog Creek, we conform to an in-house programming style which has evolved from the principles outlined in one of Joel’s articles. The basic idea is as follows:

Variables should be prefixed with their intended data type.

There are many caveats to this, and it means many things.  Most superficially, it has driven us to have the prefixes such as:

• f: Flag; Boolean values
• n: n-Way Flag;  Enums, etc.
• s: Strings
• ix: numeric indices and GUIDs
• c: numeric counts.
• rg: Ranges; c-style arrays.

There are many more which can be extrapolated based on context.  E.g., if I have a class “Dog”, then instance of Dog will likely have the “dog” prefix.

More importantly, these prefixes are composable:

• rgs: An array of strings
• sRg: A string representation of an array
• ixrgs: An index into an array of strings
• cRgsIxDog: The size of an array of string representations of indices of dogs.

These names and this specific style.. are not important.  There are tradeoffs in all chosen styles, this just happens to be the one that I use.  What’s interesting about a style like this is that you can extract a lot of useful defaults.

If I have a function which accepts an instance of a Dog and returns that dog’s name as a string, then I can thoughtlessly construct the following function prototype:

string GetSName(Dog dog)

While it could be debated as to whether this is the perfect name for such a function, I could argue that it’s a pretty good name, and further that every decision about the name was made automatically.

If I felt I needed to augment the prototype with additional information, I could do so:

string GetSNameThatWasGivenByItsOwner(Dog dogWhoseNameWeWillGet)

In a sufficiently complicated system, elaboration of this type can be useful, however most of the time just using the bare-minimum prefixes gives me a sufficient amount of information.

Let’s hash out the body of this function…

string GetSName(Dog dog)
{
  var tag = dog.collar.tags[TagTypes.Rabies];
  foreach(var vet in GetVetarinariansByZipcode(11225))
  {
     var s = vet.GetDogNameByTag(tag);
     if(!String.IsNullOrEmpty(s))
     {
        return s;
     }
  }
  return “Fido”;
}

I wrote this in an intentionally verbose and silly manner, but even so all of the variable names were automatic.  The rabies tag gets the variable name “tag”, because it’s a Tag.  If there I were handling multiple tags within this function, I would have disambiguated by calling it “tagRabies”, but that wasn’t necessary.  Ditto for the veterinarian, however I shortened that variable to “vet” since it also wasn’t ambiguous.  “s” could be validly called “sName”, but again that’s not necessary within the tiny scope of this function.

This doesn’t sound very special, but here’s the thing:  All of my variable names, even in a context where there were not yet any established prefixes, were completely automatic.  I could spend my time thinking about other things and I completely avoided all of the small nagging variable naming decisions.  Is this function optimally beautiful? No, but for anyone familiar with the coding style, it’s perfectly reasonable and readable.  The same cannot be said for:

string Get(Dog gie)
{
  var foo = gie.collar.tags[TagTypes.Rabies];
  foreach(var my in GetVetarinariansByZipcode(11225))
  {
     var giesname = my.GetDogNameByTag(foo);
     if(!String.IsNullOrEmpty(giesname))
     {
        return giesname;
     }
  }
  return “Fido”;
}

In my examples I’m focusing on naming conventions.  I don’t mean to imply that “coding style” == “naming conventions”, however I do feel that good names are a big step toward good style.  There are countless metrics that can be used to produce “high quality code”, and they all need some level of conscious involvement.  The core of my point is that for any stylistic choice, having a reasonable default will improve your speed and quality.  This doesn’t mean that you’re exempt from all stylistic decisions, but there’s no reason to deeply ponder every single variable name.

Improve base programming quality and reduce menial thought overhead by choosing a set of good stylistic defaults.

 

Stylistic Awareness

This comes into play when modifying or augmenting existing code.  A simple test for awareness is to examine the fresh code alongside the legacy code and get a feeling for if the code feels like it was written by a different person. Can you even tell which code is legacy?  If the change is stylistically identical to the surrounding code, that’s a good indicator that the programmer was stylistically sensitive.  If the change is obviously in a different style, then either they are intentionally fixing a broken or damaged style, or they were unaware.

This skill can be very important when working with legacy code.  Legacy code tends to be painful to read in the first place, and stylistic consistency is a great way to reduce the burden on fresh programmers trying to handle the legacy codebase.  The further the codebase devolves into a series of differently-styled hacks, the smellier it gets.

The most important coding style is generally the one that’s already in place.  As appropriate,  adapt your style to conform.

Note also that I’m not claiming that it’s in any way ideal to live with a legacy codebase, it’s just a common situation.  Even outside of legacy code, stylistic awareness can be a wonderful trait.  If you were vetting an incoming patch into your open-source project, would you feel better about it if it already looked and felt like your own code?

The neglected lesson

I feel like these are things which were mentioned to me in passing during my college career, but I never incorporated them until after I reached industry.  I can remember reading a syllabus which outlined the programming style which was to be used in one of my courses, and I also remember that I followed it only so much as to get full “style points” during grading.

How was programming style emphasized during your college career?  If you’ve settled on a style, what made you do so?

Removing my hardhat

Tactfulness is hard.  I’ve always biased myself toward direct communication and tried hard to sniff for and handle fallout.  I like to think of that as an engineering-inspired approach to communication.  This is one of many strategies, and it doesn’t always mesh well with others.

Let’s start with what I might intend as a pleasant, helpful interaction:

Hey person responsible for a different area of my company, I see a small area of what you’re working on that could be better. Let me help you make that better.

Let’s translate that into the core of the received communication:

Hey person,
You’re doing it wrong.
Let me show you how to do it right.

Not very tactful, is it?  I’d say that team-member to team-member, that can work, but’s pretty prickly.

The thing is, there are tons of things which can be evaluated in that manner. Take a moment to critically evaluate every effort put forth by your company.  How many of them would you like to tweak? How many of the could be just a little bit better if you could get your hands on it?  A lot. There will always be a lot, and you can learn a lot more if you spend time going to wonderful conferences filled with brilliant people.

Significant change at the product-scale can be done by an individual. Overhead is low. It’s possible to systematically sand down every rough edge.  Nobody will be upset if I fix a typo in their comment.

Change at the company scale is more difficult. Repertoires, cultures, goals, and contexts vary in different teams and at different levels of “management.”  These shifts are so extreme that they even vary within a given person when they’re playing their different roles.

The robot inside of me would like to interject for a moment:

This is bullshit.  We should all be honest, open, logical, collaborative, highly-efficient machines.

Sorry robot, that’s not possible, nor is it correct.  We are emotional, social beings, and we’re more creative that way.  Imagine a company of Roombas.

So, here’s the painful piece:

No matter how right you are(n’t), nobody wants to be told how to do their job. Nobody wants to be told that they could be doing their job better. Nobody wants to be told they are wrong, especially with the corollary that someone else is right.

So hang on to that nugget for a moment and return to your list of things to fix about your company.  How the hell are you going to communicate those ideas without and endless dance around politics and culture?

List of Idea Injection Strategies for the Aspiring Lynchpin

Strategy 1, order your ideas by importance and clustered by ownership area.  Take your cluster of ideas to the person (singular!) who owns that area and can give you an OK to hack in your fix.  They may do so, or they may give you an excellent reason why you’re wrong and you now need to go away and let them do their job.  Both of these results are relatively ok, as you’ll either improve things or learn something, but neither are good enough.  At scale, you cannot be the ‘low-hanging fruit champion’ of your company, nor can you be the guy who understands everything about everyone.

Strategy 2, pester your peers/manager(s) about how you feel it’s important to the company to execute Your Vision.  Tell them you’re passionate about it. Tell them you think it current operations are inefficient.  (Sounds a bit pompous, ya?)
…Honestly, I think this strategy might be appropriate.  If you can’t convince anyone about the validity of your ideas… your ideas need some work.  This type of communication sounds great for the Rands-style for 1:1 meetings, but there’s no need to repeat yourself.  The downside to this is that you’re essentially placing your idea in a little paper boat and sending it into the stream of communication with the hope of it getting picked up in a land far away.  Again, this won’t scale and still can hit the dynamics of “The dude from the other team had this message from you: ‘ur a n00b, do eet lik3 dis:…’”   Not OK.  You don’t want to play telephone with your ideas, nor do you want to be perceived as the whiney one.

Strategy 3, beer.  Lots of conversations can be had in casual contexts which don’t apply to the structure of work.  I haven’t figured this out yet, but I see it all the time.  In my case, a beer-like environment is lunchtime.  If there’s someone whose brain I want to pick, I just need them to like me and an empty seat beside them.  “Have we tried…”, “What if we…”, “Could you tell me about…”, conversations seem to work well here. 

This is why it’s important to go to the business lunches.  This is why, if the CEO is a golfer, you should take up golf.  As companies scale, face-to-face time outside of your team scales against you, and you need a lot more time than you think.

 

Unless your focus is narrow, all of this still scales unfavorably.

This is too complicated. Can I just enter my idea into a machine and have it ranked against all other ideas, prioritized, and implemented by responsible parties?

No.  (…unless you really like agile development)

People don’t like their work to be based on someone else’s idea.  Even if they do it, the fact that it already hasn’t happened is an indicator of two things:

1. They have a different mentality.

2. It’s not their plan.

Even with optional efficiency in implementation, having a smattering of idea generators scattered throughout the business will be fragmented and weird.  Misaligned vectors.  If everyone does this, nothing will progress.  It’s sub-optimal, and single-ownership beats this out. 

…But,  someone doing something important is doing it wrong!

Stop right there.  Just stop.

Nobody is ever wrong.

Right and wrong are relativistic to a context.  Everyone is always right within their own context unless they’re lying to you.  Sometimes they lie to themselves and that propagates to you-  that just means that their context is shaped by emotion, denial, or some other psychological demon.

This whole debate comes down to something fundamental. What do we do when one of us thinks the other is wrong?

Oh, I know!

Tell the person they’re wrong.

Or even..

Tell the person that you’re right.

Yeah… no. These are blunt force weapons. Not usually appropriate.  Right and wrong are usually pretty inconsequential relative to being thought of as an ass.

How about if we try…

Expanding your context until they are right.

Expanding their context until you are right.

Expanding both of your contexts until you’re both right.

This is sounding better.

I can always find something which I can say is “wrong” or “bad”, and sometimes I can even say that there is a “right” or “better” thing to do, but providing answers is not a sustainable strategy, it doesn’t scale, and it’s a good way to become hated.

Teach. Share context. It’s necessary.

Let’s start with what’s intended to be a pleasant intention:

Hey person responsible for a different area of my company, I see a small area of what you’re working on that could be better. Let me help you make that better.

Let’s make this better:

Hey person,
You’re doing it.
Have a beer.