Your Political Virginity.

I don't care how lucky you are. I don't care how amazing your work culture is. If you; dear reader; have not taken a few punches of office-politics; at-least once in your life; you haven't learnt enough. 

You think that the bully who made you do all the work in the school project and took all the credit for it; when you were in school; was an asshole?

You have no idea what your first political experience at an organization is going to be like.

You; are still a political virgin.

Days move on and then one seemingly beautiful morning; you find yourself in a hostile political environment of a really-shitty-client-and-his-organization.

That's when it hits you; really hard.

Smack on your face.

It is at this point that you lose it --- your political virginity.

If you survive the blow and find yourself reading this; pat yourself on your back.

You are now a 'manager'; for better or for worse depends on the survival approach you picked.

Survival.

For me; my first exposure to the stupidest form office politics was at a client; where I was stationed for a period of three months. For the purposes of this post; dear reader; this small client of mine comprising of around a fifty odd people; shall be called Multiplitaxion Inc.

Multiplitaxion Inc, had a team of three genuine builders who were not just surviving but thriving and getting things done.

I called them the three musketeers.

Three young programmers who were; what Steve Yegge would refer to as --- done and getting things smart.

Fun loving guys; who were good at what they did.

What I found most amusing when I met this team; however; was that they had not just survived the politically hostile environment at Multiplitaxion Inc; for months; but had actually thrived in it.

When I joined their team; they were under the management-microscope.

The mere act of joining the team meant that I would be under this microscope too.

Management Microscope.

Did you push the release on time or were you late by a day?

Did you follow the organizational process and send an internal daily report to your manager?

Did you remember to spell-check your daily status report?

When you are under a management microscope everything you say or do can and will be used against you.

I can give you a thousand reasons about why you might find yourself under the management microscope; but each one of those thousand reasons eventually boils down to this:

Someone up there in the pecking order of your organization does not like you.

You make them feel insecure.

Our microscope at Multiplitaxion Inc; extended all the way; office timings; documentation; discipline; formal attire; you name it and we were being monitored and criticized for it.

The funniest part however; was that none of these three individuals answered any emails pertaining to random irrelevant criticism.

I on the other hand; had an irresistible itch; of providing equally long-winded responses and explanations.

Before I sent out my responses; however; I asked why they did not; and learnt about 'fouls' and 'goals'.

Fouls And Goals.

One of them pointed at a recent email which complained about how we didn't spell-check our status report; smiled and said - 'This right here; is a foul'.

Like all good things; the idea was stupid simple.

Every random criticism being thrown at the team was referred to as a foul.

If there was one fact everyone in this really small team understood it was this:

You do not win soccer matches by fighting over fouls. You win them by scoring goals.

A week before the project ended; we scored.

As a response to a month old email that complained about an internal status report not being spell-checked; one of the three responded with the latest status repot which showed that we were a week ahead of schedule and were done with the project. The report also mentioned that we had a formal sign-off on User Acceptance Testing from the QA department and the business users.

Then; he signed off the email with the words which were on the the lines of:

"This one is spell-checked. Special thanks to you for your continuous support and encouragement during the course of the project".

During the course of the project there were over scores of emails that none of us responded to.

When the project ended I was glad we did not.

This team; dear reader; did not need a manager to sedate the monkeys - we had survived the stupidity of office politics; and we; dear reader had picked the survival path of scoring instead of haggling over fouls and learning the art of whining.

Would I go back to work for this client again?

Absolutely not.

Something tells me none of us from that team would.

Having said that; what this client of mine, taught me was invaluable.

If you happen to be my manager in future; and if you send me an email; telling me how critical it is to use 'Verdana' font in the internal status report; that only you are going to read; please do not expect a response. You dear; manager; just scored a foul.

I am sorry for not responding but I will try my best to respond when I am done with scoring a goal.

Honest. I will.

Note: This article is a part of a Work In Progress Book. To Read connected articles read the Builders At Work category of this blog.

My Gripes With Technical Writing.

My previous blog was all about technical writing. As a young and budding developer; some of the posts out there were aimed at talking about the latest cutting edge technology; flexing my engineering mussel and getting more traffic out of Google.

As I wrote the posts however; I realized that; unless you are talking about the products you are yourself involved in; technical writing is harder than any other forms of writing.

Unless you genuinely believe in the craft of story-telling; the life-cycle of writing a technical post pretty much goes like this: You take a topic; you dissect it; you understand everything there is too understand about it and then you try to pass that understanding over to your readers. It was almost like taking a traditional approach to teaching.

After a while; I realized that there was one word that describes this entire process: Boring.

Don't get me wrong; dear reader. The mere act of writing code or reading it isn't boring. It gets you in the flow and does amazing things to your life. Having said that; the very process of writing about code; or reading about it; is in fact very boring; and there are multiple reasons; dear reader; why this is the case.

I'm going to make a humble attempt at touching some of these reasons and try to figure out why most technical articles or books out there are unable to keep my attention span end-to-end.

Ready?

Let's get started with my gripes on technical writing.

Technical Writing is Based On Facts.

Let's face it; the way most technical writers of today write; Dependency Injection is basically --- dependency injection. That's where most technical writers of today start and stop. Take the Wikipedia definition of dependency injection; for instance. Here is how it goes:

Dependency injection (DI) in computer programming refers to the process of supplying an external dependency to a software component. It is a specific form of inversion of control where the concern being inverted is the process of obtaining the needed dependency. The term was first coined by Martin Fowler to more clearly describe the mechanism.

The very first sentence is a turn off. By the time you near the end of the article; you can hear yourself snoring out loud.

It isn't Wikipedia's fault though.

What Wikipedia is doing; dear reader; is capturing facts and presenting them to you. This is what most other technical writers writing technical books seem to be doing. Most of them; seem to base their books or their writing around facts; and the inherent problem with this approach; dear reader; is that facts; are boring.

Lack Of Spice And Information Surrounding The Content.

Pick a few basic books on neuroscience and they will tell you a great deal about how our brain stores and interacts with information. Neuroscientists; around the world; up-till the recent times believed that information in the human brain is stored in a central location and that lesser the information the easier it is to commit and recall.

Recent opinions however; seem to suggest that information in the human brain is basically stored all over the place; and the human brain uses the 'context' to get you a faster recall. Long story short; dear reader; spice and some amount of irrelevant information; connected with the fact is just as important as the fact itself.

I first understood the importance of this brain-rule during my French-classes.

To illustrate my point; dear reader - I am going to teach you some French.

Ready?

The French word for 'who' is 'qui' - I want you to commit this to your memory - get on with your life and do a recall a couple of months later.

Now; if you are like most of us; chances are that a couple of months later; as you move on with your life you are going to forget this piece of information all-together.

Now; do this - turn the literal fact - "who in English equals qui in French" - into a tiny little sentence with some useless information and some context.

Put simply; just try and remember the English sentence - 'who has the key'.

Now; given that the pronunciation of key and qui are exactly the same; months later; when I ask you the French translation of 'who' - chances are; that you will not just remember the French translation; but you might actually have a faster recall.

Ok; back to technical books on programming. The problem with most technical books today; is that they lack this additional spice and information that is supposed to make it easier for people to remember the facts that the book is presenting.

When it comes to technical writing and reading about code; less is not more. In fact; neuroscientists around the world will tell you that when it comes to storing information about a fact; the more random connected information you have about the fact; the higher your chances of remembering that fact are.

Now; look around. Take a look at all the technical books you have. Also take a look at all the technical blogs that you can find online. How many of them give you this additional information connected with the facts they present? How many of them provide you with additional; hugely interesting information that helps you commit and recall the stuff; faster?

Thought so.

This Thing Is Supposed Be Fun.

I've known some amazing fun loving authors and have had the pleasure with observing them or even remotely working with them. These are seriously fun loving guys who can take a concept and drill it into your head by the time you are done with your lunch with them.

However; when they indulge in the act of technical writing; you somehow seem to get a sense that you are reading a completely different individual all together. Pick their books and you will realize that the sense of humor is gone; the jokes are gone; the funny analogies are gone.

What remains is a me-too book or a me-too programming blog on C# or Ruby On Rails that other C# or Ruby On Rails programmers go to.

Over years; our technical writers and authors around the world seem to have nurtured the thought that a technical book ought to be something 'serious' and 'professional' and therefore it is completely inappropriate to go out and experiment when you are writing a technical book or a technical blog-post. That dear reader; makes most technical books and blogs out there nothing more than material that you reference when you are stuck with a problem.

When was the last time you picked up a book on Design Patterns and had 'fun' reading it?

When was the last time you giggled while reading a book on C# programming?

When was the last time you had a deep realization that triggered a chain of thoughts while reading the explanation behind a code-snippet?

Technical Writing Lacks Persona.

Every book; be it a novel; or book about software development; reflects the author's personality. Most technical books out there however; don't.

We have seen the use of F-word; in books and blogs that are connected to software development.

We have seen management books use words like Asshole.

We have seen books on organizations and entrepreneurship which move and inspire.

The idea is not just to grab the attention of readers with purple-cow words; but to leave a little bit of your daily-persona into the book when you are writing it.

While it is true that no-one cares about you or your product; it is also true that there is a little bit of you in everything that you do and that little-bit-of-you makes everything you do different. Most technical writers however; seem to miss out on putting in a little bit of their personality into their technical writing.

We are Taking It Way Too Seriously.

There are over two hundred blogs that I subscribe too. The ones I love the most are blogs where authors take chances; post something that is wrong; learn from their comments and then go out there and change with time.

While the whole idea that authorship does not mean authority seems like a well known fact in blogs that do not talk about code; the ones that do; still seem to be a little hesitant at being opinionated; passing on their own thoughts and insights about the code they are explaining and making blatant mistakes while they do that.

As a matter of fact; most authors seem to take the easy-safe-boring way out; which is to eliminate this information all together.

As authors and programmers are we taking what we write or read; way too seriously?

Are we missing out on all the fun connected with making mistakes and learning from these mistakes?

After all; there is something to be said about learning with a mind of a child.

As I slowly start nearing the end of my first book and as I find more time to fly-free; every 'once-in-a-while'; I plan on working on an article or two that touches code; programming techniques and even design approaches; to see if I can add a little bit of myself to my technical writing.

The idea; dear reader; is to introduce you to my very own personal code persona that has it's very own approach to dissecting and trying to understand code; programming techniques; and information pertaining to improving your programming skills that is freely available out there.

Maybe; I'll make a fool of myself; maybe the articles will not be 'technical enough' for a few hardcore programmers out there. Maybe they may not fetch me all the Google traffic that my older blog used to fetch me; but I am going to go ahead and give it an honest shot anyways.

If you are a programmer at heart; you should too.

Go add a little bit of spice; fun and yourself to every seriously technical post that you are about to publish on your blog.

I dare you.

Small aside: If there is a book or technical blog out there that you know of; which goes deep into programming; code and design in a way that is fun; if you know a book or a technical blog that has an interesting persona of its own; I would love to read it. If its a blog I would love to subscribe to it. Go ahead; drop me a comment; or send me an email.

Young Kick-Ass Fire-Fighter.

As a young and budding developer at Multiplitaxion Inc; I took great pride in my fire-fighting skills.

Something does not work?

You need a quick and dirty macro to do payroll processing for the month?

The sky is falling?

I was your man.

Even if the so-called-senior programmers refused, cringed and pull back at the very thought of working under panic or doing something quick-and-dirty; I; dear reader was around to get-stuff-done; especially when the sky was falling.

Remember those visual-basic applications with a lot of hidden text boxes and a lot of public modules?

Heck; I built a lot of them.

But; at the end of the day; I got stuff done --- at the eleventh hour; when people were getting all worked up and wanted the work done.

Crisis As A Way Of Life.

While as developers; we all do crisis-based-reactive-programming or what I have called demo-driven-development; the problem with crisis is that if you allow it to happen; it will. 

All the time.

Humor me; dear reader. Analyze your organization; take a sample size of a few managers in your organization. Chances are that you will at-least find a couple of them whose projects have a track record of people staying late; people working holidays; people making random mistake; people panicking --- people firefighting.

Now; go look at teams within your organization and I'm sure you will find teams that have a track record working in projects which require a lot of firefighting.

No dear reader; I'm not talking about the isolated example of one project where the client was desperate to get things done really quickly or your CTO was desperate to have the next version rolled out before the demo.

I; dear reader; am talking about a life-style; where the team spends every single day working on 'changes' suggested that day and fumbles to get them done by the end of the next day; and they do this; day after day; project after project.

Managers; who know how to create crisis out of every situation.

Teams; which will be the most reactive and productive when asked to firefight; everyday.

Programmers; who crave crisis; because it lets them flex their engineering mussels and flaunt their heroism.

People who get into crisis all the time; and once they are there; they refuse to even think of giving up.

Believe it or not; dear reader; crisis; is a way of life.

Soak Time And The Problem With Crisis.

As I write this I can visualize multiple young and budding managers knitting their brows.

'So Pops; what is wrong with a little bit of crisis everyday; specially if it keeps your team reactive and helps you get stuff done?' --- you ask.

The answer dear reader; is simple:

'No Soak Time'.

Ever passed by a passage of cubicles and observed a few veteran programmers staring intently at their code?

No; they are not working.

They are indulging in the act of; what I call; letting-the-problem-soak-into-their-heads.

Soak time; is usually the time when your brain is making decisions; that will eventually dictate the life-span of your project. It's the time when your brain thinks of taking the bold decision of throwing away code or routing through the shortest and smartest ways of finding the right way when you are lost.

Soak time; is the time when you brain is chirping away at more problems connected to the primary problem are trying to solve. Problems that are not documented as 'exception flows' in your use-case-document. Problems that are only found and fixed during the soak time.

Soak time; dear reader; is the time when your brain decides to take the reporting module of your application out of the core-application-code and package it as a separate component.

It is the time when you take the most critical decisions associated with your codebase; the problem that you are trying to solve or the overall product.

It is the time that ultimately results in the neatest of features which ultimately make your applications tick. The time when you think about dropping features and question if you really need them. The time that decides your burn-down and how long your code-base will survive the test of time.

Observe any genuine builder out there; and you will learn that a decent part of the day for any builder; is his soak-time.

The biggest problem with crisis; dear reader; is that you have --- no soak time.

When you are in crisis mode you are doing only one of the three things:

1. 'Monkey Attacked, Monkey Fights Back'.
2. 'Monkey Attacked, Monkey Runs'.
3. 'Monkey Attacked, Monkey Gives up. Monkey Gets Hurt'.

Ever seen developers in meetings trying to convince their managers why a particular feature cannot be done and then scrambling to do it when their manager refuses to listen or accept the fact that it cannot be done?

If you have, you probably know what I mean by the three monkey-statements I make above.

Irrespective how how amazing a manager you are; crisis situations happen once in a while.

Handle them with Empathy and your team will take you out of them.

Create crisis situation; project after project; and all you are doing is turning your team of genuine builders into monkeys without any soak-time.

Advice For Managers: Think.

The next time; you press the panic button as a manager; think.

Can you prevent it?

Can you focus on the core and have your team build more by building less? 

Are you giving them room to maneuver and giving them the 'soak time' they need to take the right decisions for the project or are you just turning them into monkeys that 'react' to situations and your panic-buttons all the time.

Advice For Developers: Think.

The next time; you decide to indulge in the firefighting exercise as a developer; think.

Is it really as critical as your manager is making it sound?

Is there stuff in there that you can turn around and say 'no' to building?

Are you being asked to solve a problem and add meaning through your work or are you just being made to react to situations and write some random code?

Isolated incidents of firefighting are fine; but if you find yourself firefighting all the time; you might be getting your promotions; hikes and pats on your back; but chances are you are not developing any real roots or doing anything genuinely innovative.

I was a firefighter. I still am; but I don't really go around looking around for crisis situations so that I can flex my mussels and show my heroism or get a few pats on my back.

In fact; as a developer; I try my best to avoid the crisis situations all together if I can. As a manager; creating panic and crisis situations definitely shows up as one of the top items of my not-to-do-list.

Remember those visual basic applications with a lot of hidden text-boxes and lots of public modules?

I try my best not to make them now.

Maybe I have grown older; or maybe that is just a part of growing up; as a developer and as a manager.

The next time you find yourself firefighting take a pause; and reflect. Are you doing it all the time or is this just an isolated incident? If you find yourself firefighting all the time; dear reader; it is time to keep some soak-time aside; figure out what you are going to do about it and then go out and do it.

I wish you good luck.

Note: This article is a part of a Work In Progress Book. To Read connected articles read the Builders At Work category of this blog.

My First Introduction To SideWiki.

A few days ago I was emailed by folks at Google; targeting selected bloggers; who asked me if I would be interested in getting more information about a product they were about to launch. If I was interested; I would be sent a gift package that would give me more information about the product.

When the package arrived; what I was expecting to find was a DVD with a Power-Point presentation; a video or other marketing material about a new Google Product.

What I found instead; was a seriously beautiful example of story telling from Google. Something Seth Godin would call a purple cow.

The one; and only thing the package contained; was a copy of - "Sailing Alone Around The Room" by Billy Collins.

That's it.

Nothing else.

When you're expecting a product demonstration DVD or a manual; finding a best selling book containing a collection of poems is a purple cow that grabs you by your collar and gets all your attention.

As I fiddled with the book scrolling through it; I noticed the corner of one page folded neatly as if someone was reading the book. The page had the poem marginalia:

Sometimes the notes are ferocious,
skirmishes against the author
raging along the borders of every page
in tiny black script.
If I could just get my hands on you,
Kierkegaard, or Conor Cruise O'Brien,
they seem to say,
I would bolt the door and beat some logic into your head.

Other comments are more offhand, dismissive -
"Nonsense." "Please!" "HA!!" -
that kind of thing.
I remember once looking up from my reading,
my thumb as a bookmark,
trying to imagine what the person must look like
why wrote "Don't be a ninny"
alongside a paragraph in The Life of Emily Dickinson.

Students are more modest
needing to leave only their splayed footprints
along the shore of the page.
One scrawls "Metaphor" next to a stanza of Eliot's.
Another notes the presence of "Irony"
fifty times outside the paragraphs of A Modest Proposal.

Or they are fans who cheer from the empty bleachers,
Hands cupped around their mouths.
"Absolutely," they shout
to Duns Scotus and James Baldwin.
"Yes." "Bull's-eye." "My man!"
Check marks, asterisks, and exclamation points
rain down along the sidelines

Lying lose; right next to the poem was a small-yet-beautiful-post-it-note from the SideWiki team at Google.

Every page on the web is missing one crucial voice. Yours.

Were you ever reading a web page and realized you had a particular insight or annotation to add?

We wondered what the web would be like if everyone could contribute this way.

Google SideWiki,
http://www.google.com/sidewiki

Now that; dear reader; is what can be called seriously interesting story-telling.

All you need to know about a product; using a book of poems with the page folded at one legendary poem; and a post it note. 

My introduction to SideWiki had all the elements any organization should use to introduce their products to their users.

There was the element of suspense; shock and surprise. Then there was the whole act of involvement; as I fiddled through the book and tried to figure out why-would Google send me a collection of poems. Having said all of that; what I loved most about the whole episode; was Google's respect for my; or should we say their user's; intelligence and not trying to 'sell' too hard by giving me a stupid power-point presentation on how amazing SideWiki was.

I; dear reader; was sold.

The Product

So; yes; Google pulled off an amazing act of story-telling and grabbed my attention. Enough to get me to the SideWiki website. But then; I would not be writing this if the product itself was not strong enough to complement the amazing thought and effort that then went into getting the product to me.

I; dear reader; am writing this; which clearly goes on to mean that SideWiki is amazing.

If I can be honest here; I loved the idea and the implementation as much as I loved the way the product was marketed to me.

Now that the folks at Google have indulged in the act weaving a seriously amazing story around SideWiki already; let me; dear reader; take the mere mortal route of traditionally plugging the product and recommending that you give it a shot too.

For someone like me; who is always nudging people to participate and contribute; SideWiki is interesting because it allows people to contribute without working hard on their writing skills; signing up for a blog; or whining about the fact that they don't have time or anything interesting to say.

If you don't read anything interesting; or have nothing to scribble along the margins of the pages you are reading; you seriously need to question whether you are an active internet user or just a leach.

Now go get SideWiki; go to your favorite website and participate by providing the web pages your very own personal perspective.

My Gripes

Ok; flawless marketing of the idea; awesome product; but there are areas about the product which make you knit you brow. While I am at it I thought I might just as well list my gripes about the product. Everything else about the product; that isn't listed here as a gripe; dear reader; I like.

Ready for the gripes?

Here we go.

Please Don't Replace Stuff By Default.

SideWiki makes me install a bloat of other applications. At-least it seems like it does. The default installation went ahead and decided that it wanted to modify my taskbar and add a Google search functionality on to it.

Yes; I love Google like we all do; but I really don't want a Google logo on my taskbar. I've always held the opinion that typing 'iexplore http://www.google.com' is faster that reaching out for the mouse. Seriously.

Long story short; gripe number one; is simple; it's 'my' desktop.

Leave it alone.

At-least in the default installation.

I Love SideWiki But The Toolbar Is Complicated And Boring.

As much as I love SidiWiki; I don't like the Google Toolbar all that much. It's childish; has way too much clutter and lacks the classic Google simplicity. It is complex and it is confusing. The least Google can do on this front is; reduce the clutter; improve the icon quality; figure out the services I really use and hide everything else.  Yes; I know you can remove these buttons by using the toolbar-settings; but the default configuration makes the toolbar look way too cluttered.

Put simply; unlike most Google products; the Google toolbar looks complex at the first glance and I am not so sure that's a good thing.

No Spell Check Support

Everyone who knows me or reads this blog probably knows that I'm not that much into spellings. Having said that I hate it when I make spelling mistakes. A decent spelling-checker into SideWiki plug-in would have been an interesting feature to have.

Currently the comment text box seems like yet another boring text-box that does not do anything intelligent.

No Chrome Version.

Other than these; it would have been amazing to have a Chrome version; but then there are enough people whining about that already; so I will leave that one out of my list of official gripes.

And My Very Own Personal Wish-List

Not sure if these are already a part of SideWiki; if they are; enlighten me; dear reader; by leaving in a comment and this post will be updated accordingly.

If; however; these are not a part of SideWiki already here is my personal wish-list of features for the product.

If there was a way to get RSS feeds for SideWiki entries on a per-page basis that would have been amazing. There are multiple organizations, sites and pages that I would like to subscribe to and get constant feeds of what people are saying about the pages. Currently I cannot seem to find an easy way of doing that with SideWiki. [updated information available at the end of the page]

There is something about having hyperlinks to your Twitter posts which makes twitter special. Features where I can at-least get permanent links or URLs of SideWiki comments; would have made SideWiki golden. [updated information available at the end of the page]

Besides; if I own a website; I cant seem to get one consolidated page or feed where I get to see everything people are saying about my domain using SideWiki. That; dear reader; is also one feature that would be amazing to have.

The Overall Verdict

Like I said; If I was not pleased with what I saw; and if I would not have loved it; I would not have spent my time writing this review.

I highly recommend anyone who reads this to go download a copy and start participating and contributing.

Oh; and by the way; please don't tell me you do not have the time to blog; or nothing interesting to say; because now we will all know that is just an excuse.

Update (Based on response received on Oct-6): Heard back from folks at Google that sidewiki already has some of the features which I asked for in my wish-list; particularly RSS feeds and permanent links; more information on that is available here or on the sidewiki page of this post. 

Watch And Learn.

Early on in my programming career as a student; we worked on a system which was supposedly an intelligent system capable of striking a textual conversation with the end user. This was a small research project at the school level which won accolades at a few local news papers and received a little bit of attention.

The premise of this project was fairly simple. As far as human beings are concerned; most; at-least quite a bit of what we learn; is learnt by aping things. You know; the monkey-see-monkey-do way of learning and doing things.

With my limited reading on neuroscience back in school; little did I realize how wrong I was about the human brain and how it worked. Books like the Brain Rules will tell you that there is a whole lot of preprogrammed intelligence in the human brain besides just an ability to ape and learn stuff. But when you are a kid you do funny but really interesting things which keep you excited and in the flow. Things like trying to emulate the human brain with computer programs.

Having said that; the basic premise on which the system was built does hold true even today. The human brain; at-least a huge part of our brain; evolves by observing the things that happen around us; deducing our own reality out of what we observe and then aping the changed versions of that reality back into our lives whenever we need to or want to.

How do you become a great author?

By reading lots of good literature.

How do you become a great poet?

By reading lots of good poems.

How do you become a good builder?

Now; if you are a normal human being with a functional brain you probably answered instantaneously; - 'you do it by observing a lot of builders @ work'. 

That right there was a live example of learning by aping logic based on the first question and using it to answer the third one. As human beings; we do this all the time and after weeks of observing genuine builders at work; one of the things that I've learnt is that the sooner you start observing genuine builders around you and the sooner you at-least start understanding what they are doing; the better off you will be; as a builder.

Steve Yegge uses his music learning experience to illustrate how can Practicing Programming by observing other programmers. He explains:

The saying "practice makes perfect" is inaccurate, as any music teacher will happily tell you. Perfect practice makes perfect. I'd been practicing sloppily, and had become very good at being sloppy. For one thing, I was tensed up, trying to force my fingers to make the right moves. So I only knew how to play tensed up, which exhausts you quickly. I was actually doing all sorts of things wrong, more than I'd ever have guessed, but the details aren't important. What's important is that I was thinking about it all wrong.

I knew that everyone said you should take lessons, but I had convinced myself that I didn't need them. I was actually a bit afraid to take lessons, because instructors were telling me I'd have to "forget everything I knew and start from scratch." That was a stupid way to attract new students! Nobody's going to want to throw away years of work. It was also incorrect: lots of the stuff I knew carried forward. Learning the proper technique turned out to be more like learning a new song than learning a new instrument. But at the time, I thought: "Screw that. I know how to play guitar. I'm happy with my playing, and I'm not going to change the way I play."

I hope you don't think this discussion is too far afield, because my attitude towards guitar lessons was identical to the way most programmers feel about their technical skills. "I'm already great at Perl, so I don't want to go back to the beginning and learn C, or assembly-language. I like the way I program." Or: "I'm great at Java, and I don't see any reason I should have to learn how to write scripts. I can get by just fine without them."

The thing is: I wasn't a great guitarist, and Perl-only folks aren't great at Perl. But you can't see that until you've done the hard work of learning what your instructors are telling you to learn.

Practice Drill #2:   Make a list of programmers who you admire. Try to include some you work with, since you'll be borrowing them for some drills. Make one or two notes about things they seem to do well — things you wish you were better at. 

Simply thinking about good programmers you know, and what makes them good, is good practice in itself. But we'll also use the results of this drill in some later drills.

Finally, there's music practice. There are sooo many types of practice. The common characteristic among them is that practice has to be habitual. Professional musicians develop daily and weekly practice habits that they keep up for their entire careers. Practice requires a recurring time commitment.

One type of practice is simply to go listen to other musicians play, as often as you can. You'll learn a lot just by watching and listening. The analogs in the programming world are watching other people program, and reading their code.

In his classic video on Attention and Sex; Scott Berkun; describes the same phenomenon and describes the importance of giving attention to how the masters of innovation give attention to things. If you have not seen the small five-to-seven-minute-video I highly recommend you do.

This book; in general and this series of posts about observing-and-understanding-genuine-builders in particular has been all about watching builders @ work and learning from them. If you want to learn the art of genuine innovation; including the craft of building stuff that is genuinely remarkable; you don't start by getting in a meeting room and thinking of a grand idea.

You start by paying close attention to every builder that you can lay your eyes on; every piece of information about every remarkable organization that you can find out there.

Then you study that information.

You squeeze out every practice; every fact and every approach to problem solving out of that information. You dissect that information and you spend a conscious bit of time and effort doing it. You do it consistently; every single day of your life.

Do that long enough and you will learn things that are bound to change your whole perspective of innovation and how stuff gets built in the real life. No; some of the best builders that you will be able to find don't succeed all the time. In fact; they fail early and they fail really often. Genuine builders don't spend a huge part of their lives in meeting rooms. Some of them even prefer to work at the middle of the night in just a towel.

Some of it; like being aware of how important consistency and patience is, when it comes to building stuff; will be learning that will prevent you from bailing out or quitting too early. It might even help you cross the dip and become the best in the world at whatever it is that you are trying to do.

Other facts; might just be a confirmation that you are on the right track.

Some; like knowing how builders hibernate; might just tell you where you are going wrong or how you can fix it.

Whatever be the case; once you are done with this post and before you move on with your life; consider this --- if there is one thing that you take back from this book and this section in particular; it is that when you see a genuine builder around you who is getting things done; you need to stop whatever it is that you are doing as a 'manager' and you need to observe the guy.

See him work.

Watch.

And Learn.

I wish you good luck.

Note: This article is a part of a Work In Progress Book. To Read connected articles read the Builders At Work category of this blog..

Where There Are Human Beings --- Shit Happens.

I was once told that the difficult part of story telling is when you stop writing and the story starts writing itself. That isn't really the difficult part of story telling. What I have learnt with this book is that the difficult part of story telling is not just letting the story write itself; but wrapping things up brining them to a graceful end when the story is really busy writing itself.

Yes; there is a lot more to be said about building remarkable work and play environments. We can sit here all day and talk about all the specifics of creating an amazing work and play environment and then you can go out there in the real world and realize that every single problem that you face at your work environment is not even close to the problems that you read in this book.

Or you could spend years of your life as a manager; sixteen hours a day; trying to build an environment that absolutely rocks and then one fine morning be told that even the best of your builders aren't even remotely happy in the environment you've built for them.

This is probably not because you went wrong with or were inattentive to every minute detail that this book talked about.

It is probably because of the simple cardinal fact of life --- where there are people; shit happens.

No; seriously. Before you snicker and smile at that statement harp on its reality a bit.

Human beings by their very nature are complicated creatures moved by different motivations.

The story of a seriously interesting builder who supposedly loved working at Multiplitaxion Inc, comes to mind. The guy was a decently good builder who was pretty good at the craft of getting things done. We had given him all the tools he needed to get things done; got out of his way; gotten him salary hikes; promotions and big fat bonuses.

When the guy left he was in serious need of more funds and a higher salary. Understandable. What was not understandable however; was that as soon as he found a better job offer; he admitted having written two really long and interesting anonymous emails. One consisted of blatant, non-constructive criticism about the organization and how it was a pathetic organization to work for. The other was a blatant criticism for 'the man' who worked for the organization.

We read the emails with a meticulous eye; looking for any piece of constructive criticism that we could pounce on and improve the overall work environment. I even went so far as assuming that he referred to me when he talked about 'the man' and tried to read the email with an objective eye looking for anything where the organization or I; as a manager; could go out there and improve myself.

As far as constructive criticism was concerned - there was none of it.

'Multiplitaxion Inc, was too materialistic to give out employee loans and advance salary to their older loyal employees' --- the email read.

As a matter of policy we did not give employee loans and salary advances back then. Everyone knew it. It was common knowledge.

'The man who works for the organization does not not even like listening to music' --- the email read.

Well as a matter of fact, there were quite a few of us who found the idea of listening to loud music while programming a little distracting. We preferred people used their headphones. We even went all the way; had the organization buy these headphones and gave them out to the music lovers absolutely free of charge.

After reading the emails over and over for a couple of times; feeling down for a few minutes; we decided to leave the emails behind and move on with our lives.

There were multiple reasons why we could do that without having to rage a major war with our guilt or consciousness:

1. As an organization we; at-least most of us; had been just, fair and open about our policies and everyone who stuck around were aware of these policies. Everyone who decided to stick around had made a conscious decision to stick around. None of it was confusion or deception. 
2. As managers; we were all learning and we were working our asses at it; giving our level best to our job which included removing impediments from the way of builders. We were serious about creating environments which were great for serious work and play. Yes; we made our share of mistakes; but we learnt from them; and we survived by moving forward --- consistently. 
3. When we made mistakes; we said sorry; and we fixed things. Obviously; when we got these anonymous emails with no constructive criticism what-so-ever; just whining; it seemed logical to ignore them and move on. There was nothing to say sorry about; nothing to fix. After all; we had an organization and projects to run and we could not afford to let the bozos get us down.

Every work environment is different and so is every human being that you work with. Yes; when the young and budding engineer you pushed hard to promote turns around and criticizes your whole idea of openness or flatness; it sucks; but at some point in your professional life and even as organization's life; you will have to take a stand and realize one simple fact of life --- you cannot please everyone in your organization.

Funny But Interesting Donkey Story.

It is probably floating around in emails trails somewhere. This is a fable of a man who about to embark on a journey decides that he wants to carry his old donkey on his back.

Somewhere along the trip the donkey slips into a big mud-hole.

The man spends hours thinking of a way to get the donkey out but finding no rope or help near-by decides to put an end to the old-hurt-donkey's misery by covering the hole with mud and cremating the donkey alive before he moves on.

He takes a bucket full of mud and throws it on the donkey's body.

The donkey shakes it off; and steps on top of the mud.

Bucket after bucket; the man keeps throws the mud on the donkey's body to cremate the donkey live.

Bucket after bucket; the donkey keeps shaking the mud off his body and stepping up on it.

Soon; the hole is covered and the donkey walks out alive.

As funny as narrating this story in a book connected with software development seems; it should actually be taught at management and software development schools across the globe.

Why?

Because if you are trying to build truly remarkable work and play environments or trying to bring about any change in your organizational environment, you have to develop an overall attitude that has uncanny resemblance to the donkey's attitude in the story. 

Shake It Off. Get Over It. Move On.

When you are trying to bring about change; or build amazing work and play environments chances are; that you are going to be criticized heavily. Someone somewhere in your organization is going to have serious issues with what you are trying to do.

It is going to hurt even more when the people who you were hoping to become your change agents have serious issues with what you are trying to do.

If you want to have any chance of survival in the long run; remember the three very basic; simple rules:

1. Do 'not' forget the magic word - 'Empathy' - if you lose it you lose everything.
2. If you genuinely believe in what you are doing; keep doing it consistently; and hope that people will 'see it' and 'get it' sooner or later. 
3. When the criticism comes in; analyze it objectively; see if there is anything you can do to improve yourself and if the criticism was just directed to let you down  --- shake it off; get over it and move on; just like the donkey you read about in the story.

Remember; you get just a couple of human beings in a room and shit happens. In a typical organization; you're dealing with quite a few human beings. Having said that; If you remember these three simple rules; improvise and adapt as per these rules; you should go a long way at creating amazing work and play environments.

Of course things will feel shitty at times.

Of course things will feel like nothing is even worth-doing at times.

But stick around and you should be able to build an environment that is different, fun and stands out; despite of all the shit around that happens around you; and then if you are lucky; the shit that happens around you will slowly keep on reducing over time.

Having said that; don't expect all of it to go away completely. It wont. But if you keep showing up; keep doing what you think is the right thing to do; sticking to the three simple rules; you might actually start loving what you do and you might witness change happening. Slowly. Over time.

I wish you good luck.

Note: This article is a part of a Work In Progress Book. To Read connected articles read the Builders At Work category of this blog..

Relationship Circles.

Relationships and connections that bring people together at work are fairly interesting.

Take a circle; it is time to observe.

Yes dear reader; by a 'circle' what I mean is that group of individuals you see hanging out in the cafeteria; together --- all the time.

Watch them; because 'circles' have the potential of empowering you with the information you always craved for as a manager.

'Circles' can tell you a lot about individuals who constitute them.

Located smack in the center of the 'circle' is the central connector that forms the circle. It could constitute of multiple things:

1. Human Connectors - What Malcolm Gladwell would 'connectors' in his classic book; The Tipping Point. These; are human beings that bring other human beings together.
2. Memes And Causes - People in a circle are getting together and talking about their project. With their current project or what-ever-it-is-that-they-are-working-on is going to change the world; make a dent in the universe and show the organization that they have been right all along.
3. An Asshole - Yes; if you are talking about the world of software development; assholes bring more people together than you can think of. You hate Fred; I hate Fred; so lets hate Fred together. Its so much more fun that way. Of-course Fred; could be a manager or an entire organization. As long as we can get together and collectively hate something together we should be good building a circle around that hatred.

At Multiplitaxion Inc; I had the opportunity of working with a senior manager who actually took pride at being the asshole who connected everyone within the organization. In a direct; open; candid; one on one conversation this gentleman told me he knew how everyone in the organization hated him. He said it in a tone which translated almost like saying he knew how he was actually brining everyone together through a common reason; which was the act of hating him.

Foundation For Long Term Work Relationships. 

While only one of the managers I have worked will till date; was candid or mature enough to admit this; I have worked with a countless number of managers who at some level or the other; knew they were hated by people around them and actually took pride in the fact; or at-least got a very perverted kick out of it.

Talk to most vice-presidents and CEO's around the world and quite a few of them let whiners and assholes stick around in the organization; because at some level of consciousness or other they are noticing first hand how having these whiners and assholes are bringing teams together. Besides; everyone loves a few whiners in the organization.

If you are trying to create an environment which is fun to work in; and produces genuine innovation for years; here is the bad news however --- the whole idea of hatred for assholes acting as the unifying glue that holds your entire organization does not work in the long run.

Why?

Because problems do not tend to exist forever and when your relationships are based on specific problems; with the problems out of your way; you are pretty much stuck in a rather awkward situation.

Another manager; who for the purposes of this post; we shall refer to as Fred; for example; was a universally hated manager at Multiplitaxion Inc. Fred; single handedly formed the central focus point of many circles and the sheer make-fun-of-Fred-task was a project in itself. It was in fact a way of life which brought groups within the organization together @ the Multiplitaxion Inc, cafeteria.

Then one fine morning; when the sky was blue and the birds were chirping; Fred found a better opportunity and left Multiplitaxion Inc.

Just like that;  he wrote a formal it-was-nice-working-with-you-guys email; and disappeared the next week.

You could literally hear the sound of crickets chirping in the cafeteria.

A few younger ones tried continuing the when-Fred-was-here stories even after he was gone. 

It seemed to work for a couple of days.

Then that didn't work either.

This is when; over a period of time; I personally witnessed the ends of multiple 'circles' within the organization. People who were intelligent people; spending hours together; were nowhere to be seen together now.

Walk into its cafeteria and Multiplitaxion Inc no longer seemed like the fun and happening place roaring with laughter it had once been.

Builders who had joined forces to sedate this monkey; found nothing to talk about and went their own way.

All you could hear on any given day in the corridors of Multiplitaxion Inc; was the sound of crickets chirping.

If there was one thing this incident taught me; it was that 'circles' that are brought together by true and genuine fun-loving connectors tend to survive for a relatively longer span of time. Circles that are brought together based on the mutual hatred of a particular asshole or a particular organization; do not tend to survive in the long run at all.

The only circles; however; that stand the test of time are circles which are formed out of mutual desire to create meaning. Circles where the objective is to get together and 'build stuff'.

Next time you notice a circle forming around an asshole; try to penetrate it; and give them a cause; a meaning or a bigger arch enemy. That dear reader; is your only chance at forming long lasting 'circles' of genuine builders and not collective-whining-groups.

I wish you good luck.

Note: This article is a part of a Work In Progress Book. To Read connected articles read the Builders At Work category of this blog.

Building Stuff Is Hard

Virtually every veteran builder that you talk to; tells you the same things about building remarkable stuff. Building stuff is hard; building stuff takes time; building anything means you face a lot of criticism and building stuff requires something that is much more important than just raw talent --- it requires patience and consistency.

Bottom line; you keep jabbing; keep shipping; and keep firing; till the time you cross the dip and hop over the thin line that separates a young and budding armature from a mature veteran.

If building stuff that is truly remarkable is that hard and usually happens after multiple encounters with failure; the question that really kept bothering me; as I worked on this book; dear reader; was that; apart from the Hollywood-Appeal-Factor is there anything else that attracts, nudges and pushes genuine builders around the world to keep building stuff.

The answer as it turns out is --- passion and flow.

Flow

The more builders around the world; I observe; the more I am leaning to believe that passion for what you do and flow are two most important reasons which makes builders put in the tremendous amount of patience, slogging and consistency it takes to make the dents in the universe; that they are trying to make in the first place. 

Wikipedia defines being in the flow as:

The mental state of operation in which the person is fully immersed in what he or she is doing by a feeling of energized focus, full involvement, and success in the process of the activity.

Csíkszentmihályi identifies the following nine factors as accompanying an experience of flow:

1. Clear goals (expectations and rules are discernible and goals are attainable and align appropriately with one's skill set and abilities). Moreover, the challenge level and skill level should both be high.
2. Concentrating and focusing, a high degree of concentration on a limited field of attention (a person engaged in the activity will have the opportunity to focus and to delve deeply into it).
3. A loss of the feeling of self-consciousness, the merging of action and awareness.
4. Distorted sense of time, one's subjective experience of time is altered.
5. Direct and immediate feedback (successes and failures in the course of the activity are apparent, so that behavior can be adjusted as needed).
6. Balance between ability level and challenge (the activity is neither too easy nor too difficult).
7. A sense of personal control over the situation or activity.
8. The activity is intrinsically rewarding, so there is an effortlessness of action.
9. People become absorbed in their activity, and focus of awareness is narrowed down to the activity itself, action awareness merging.

Not all are needed for flow to be experienced.

The software development world as I know it; dear reader; is composed to only two kinds of human beings --- first kind includes one who have experienced the feeling of being in the flow; other includes those who have not.

If you work with me, know me or read this blog regularly, you may have heard or read me describe my first encounter with my first desktop as - love at first sight with no looking back since then.

During those days; picking up a random problem like creating a shooting game with quick-basic and spending hours at it; day after day; without having the need to concern myself with mundane details regarding like if I was going to paid for what was being built; was a relatively easy way to truly enjoy the journey of building stuff and experiencing flow --- without even knowing what flow was.

Then it disappeared as I tried to 'grow up' as a programmer.

It took more than ten years of programming to get a little bit of that same childishness back into my life and to brush against experiencing flow once again.

Today; as someone who toils and labors with his insanely mulish attempts at writing code; posts or anything that is supposed to make really small dents in my very own little universe; dear reader; even I; dear reader; have brushed against the feeling of being in the flow more than once.

If you have; too; dear reader; you know exactly why it makes builders around the world keep craving for more.

If you have not; chances are; that; if keep doing what you absolutely love doing; you will and when you do; you will know exactly what it is all about.

After you have experienced what it feels like to be in the flow for a few times; there is very little you can do; other than fall in love with what you do and continue doing it; day after day.

What are you experiences with getting in the flow?

Does being in the flow frequently make your overall life much more productive and happier?

Do you actually crave the experience every time sit in front of a monitor; dear reader?

Discuss.

Note: This article is a part of a Work In Progress Book. To Read connected articles read the Builders At Work category of this blog.