Programmer Tip: Differentiating Between Toys And Wisdom.

Have you seen a young and budding programmer flex his engineering mussels?

No; seriously.

If you get a chance to overhear two young and budding engineers bump into each other at a cafeteria or a grocery; chances are that all you will hear is a conversation which revolves around the famous which-technologies-are-you-working-on-now-a-days-question.

Observe.

There is a huge possibility that the discussion will continue forever as both these engineers try to impress each other with the cutting-edge technology they are working on in their latest project. 

You Don't work on Windows Communication Foundation yet?

Seriously?

Don't tell either one of these engineers.

If you do they might look at you like you belong to another planet.

Every now and then I personally witness the minds of more than one young and budding programmer explode when they hear that I am not working on any project that uses Microsoft Windows Workflow Foundation.

As developers we like to drool over the latest technology that Microsoft, Google or 37Signal throws our way. We crave to put it on our resumes and we get a huge technical-ego-boost out of using it in our real-life projects.

Rarely do we realize that all we are doing is tinkering around; consuming API's; tweaking configuration or should we just say --- playing around with new programming toys that are made available to us; year after year.

Now go grab the same two programmers you were overhearing at the grocery and ask them what Inversion of control is; what dependency injection is; or what liskov substitution principal is and watch them stare at you like you just dropped a stinking rat on the table.

Chances are that most of them will fail at even the fundamentals of object orientation.

Look hard; and chances are that you might even find programmers who cannot program working on some seriously cutting edge technologies out there.

If you are one lucky son-of-a-gun who landed in an organization that works on the latest technologies out there; and you have been busy slamming your fingers on the keyboard; writing code on some of the latest technologies out there and living in a technical-paradise; it is time to take a pause and reflect. 

When was the last time you studied closures as a language feature instead of just focusing on lambda expressions as a cool new C# feature?

When was the last time you picked a book on object orientation or the craft of writing better code and decided to browse through it?

When was the last time you kept some time aside for investigating how big your functions should be; what you should call them; or how you can get better at the craft of working with best invention in history computer science?

While it is OK to go grab the latest-beta-version of windows on your box; play around with ubuntu; and have fun exploring Windows Presentation Foundation; are you; dear reader; also giving in serious and conscious effort at understanding programming languages or reflecting on object orientation?

Are you  browsing through the code-base of open source projects out there and seeing how they lay out code; how they design their applications or approaches they take to solve generic problems.

As far as the world of software development is concerned; if playing with toys is important; developing wisdom and deeper insights about the craft of writing good code is equally important.

Do you actively track; realize and differentiate your playing-with-toy time from your wisdom-development time?

How much time do you spend on a weekly basis to get better at the craft of writing better code or developing deeper insights?

What are the tools you use to develop the craft; pick up deeper insights and grow wiser every day; dear reader?

Discuss.

The Requirements Were Not Well Defined.

As a part of my job role; I conduct interviews.

Tons of them.

If you read this blog; you probably know that one of my favorite interview questions is - talk about one colossal failure that you were associated with in your professional life.

The idea is simple: If you have not failed even once; you have not taken chances with your professional life. You have played it safe and you have avoided building remarkable stuff by resting the realms of mediocrity.

Put simply; you are what we call a 501 programmer.

Every once in a while however; I will find a developer sitting on the other side of the table; who; when asked this question; knits his brows; look up at the ceiling; pretends that he is trying to think of a failure really hard and then comes up with a random project name.

Ask him what was wrong with the project and watch him give random excuses with full blown jargon meant to point a finger at someone other than him.

The most common one of them all: 'Requirements were not well defined by the customer'.

Requirements were not well defined by the customer along with lack-of-process continues to remain the biggest and the most convenient excuses for most failures or fu@#kups that we as programmers are involved in.

After all these years of software development; we continue to work with customers who just cannot seem to be able to 'define requirements' for a simple payroll processing system.

Doesn't something about the whole requirements-were-not-well-defined arrangement thing sound terribly strange or fishy every time you hear it?

They Didn't Tell Me What To Build.

If you are a non-programmer; who is not associated with the world of software development; you are probably knitting your brows right now as you read thing and wondering - 'But Pops; if your clients want you to help them with their problem; how can they not tell you what their problem is?'.

To be honest here; the problem usually isn't about the client not telling you what the problem is. The problem is that over years of BDUF development; we as developers seemed to have changed our definition of requirements from a 'definition of the problem that the client has' to 'instructions on the bare minimum that I need to do to make this project successful'.

More often than not; when a young and budding programmer; who has seen his whining seniors do this; tells you that his project failed because the requirements were not well defined; what he is basically telling you; is that his client did not give him a step by step list of the bare minimum task-items that he needs to do to get the project successfully completed.

Seth Godin in one of his recent posts; describes the problem much more articulately than I will ever be able to describe it. He explains:

"What do you need me to do?"

This is a question that defines the person asking it. It is very different from, "here's what you might need..."

If you ask people for the next task on the list, if you allow them to define the thing they are buying from you, you have abdicated responsibility.

Your work product becomes dependent on the insight and guts of the person giving you an assignment. This is especially dangerous for consultants and freelancers, because the answer might be, "nothing." Or it might be a paying gig that's profitable in the short run but a career deadener over time.

Far better to reach a level of confidence and skill that you can describe solutions rather than ask for tasks.

The guys at 37Signals take this concept to the next level. They believe in showing some tough love to their clients by not letting the clients dictate exactly what they want from a product. In their classic book; getting real; they explain:

As a software development company, you have to act as a filter. Not everything everyone suggests is the right answer. We consider all requests but the customer is not always right. There will be times when you just have to piss some people off. C'est la vie.

Related to this, it's critical that you as a development company love your product. And you won't love your product if it's filled with a bunch of stuff you don't agree with.

That's yet another justification for vetoing customer requests that you don't believe are necessary.

Steve Yegge even ventures out so far as suggesting that business requirements are Bullshit:

I learned a lot about the Fine Art of Building Shit that Nobody Wants back at Geoworks, when in 1993-1994 I was the Geoworks-side Engineering Project Lead for the HP OmniGo 100 and 110 palmtop organizer products. Both of them launched successfully, and nobody wanted either of them.

People spend a lot of time looking at why startups fail, and why projects fail. Requirements gathering is a different beast, though: it's a product failure. It happens during the project lifecycle, usually pretty early on, but it's the first step towards product failure, even if the project is a complete success.

Self-professed experts will tell you that requirements gathering is the most critical part of the project, because if you get it wrong, then all the rest of your work goes towards building the wrong thing. This is sooooort of true, in a skewed way, but it's not the complete picture.

The problem with this view is that requirements gathering basically never works. How many times have you seen a focus group gather requirements from customers, then the product team builds the product, and you show it to your customers and they sing: "Joy! This is exactly what we wanted! You understood me perfectly! I'll buy 500 of them immediately!" And the sun shines and the grass greens and birds chirp and end-credit music plays.

That never happens. What really happens is this: the focus group asks a bunch of questions; the customers have no frigging clue what they want, and they say contradictory things and change the subject all the time, and the focus group argues a lot about what the customers really meant. Then the product team says "we can't build this, not on our budget", and a negotiation process happens during which the product mutates in various unpleasant ways. Then, assuming the project doesn't fail, they show a demo to the original customers, who say: "This is utterly lame. Yuck!" Heck, even if you build exactly what the customer asked for, they'll say: "uh, yeah, I asked for that, but now that I see it, I clearly wanted something else."

If there is one thing that is common between advice coming from Seth Godin; 37Signals and Steve Yegge; it is; that you cannot be letting the customer define your requirements. The first step to building a successful product; is living the life of your costumers; feeling their pain and understanding their problems really well; before you even think of building a product for them.

It Is Just A Lame Excuse. Seriously.

Requirements that are not 'well defined' are a convenient excuse for all your failures. As programmers we are so used to blaming the process and the requirement and then believing our own lie; that we rarely look back to reflect on the real cause of our failures; reflect on them; and learn from them. We don't even feel the need to practice the craft of building good software.

Next time you think back on one of your failed projects; if you find yourself blaming the customer or your business-analyst for requirements that are not well defined; stop; and reflect on how you could have understood your customer's pain and given them a genuine solution for the problem.

Saying that the requirements-were-not-defined basically puts you in the same bucket as thousands of other outsourced bodies-with-their-brains-switched-off working out of Indian body shops; and that; dear reader; is something no genuine programmer worth his salt should strive to become.

Next time you are working on a product; either build something which solves a problem you yourself have; or live the life of your client; connect to them; take time to understand their problem; feel their pain and add a little bit of yourself to the solution you give them.

I wish you good luck.

@BuildersAtWorkBookNotice

Team Contributions.

In an insanely huge meeting room; at a client who for the purposes of this post I shall refer to as Multiplitaxion Inc; a 'Yearly Status' meeting begins. As an external consultant who has been around for more than six months and has given more than one successful implementations; I am also invited to the meeting.

I look from one end of the table to another; my brain doing some serious soul searching and asking some rather philosophical questions to myself:

1. Why am I here?
2. Why are we all here?
3. What are we trying to achieve?

A vice-president opens the meeting with pep-talk on how team-work is essential for overall synergy and growth of the organization. He then talks about how personal contributions are nothing compared to team contributions and how we are all a big happy family.

I cringe.

Three of us have been working for sixteen hours a day for the last one month.

We are; probably the selected few who have shipped anything; in the last six months.

Something tells me I should talk.

Challenge the concept of team contributions being something larger and divine than our very own personal contributions.

Then I realize; I am not even a permanent employee of this organization.

I keep my gob shut. It is a short temporary hibernation or more of an End-Of-Yes-But-Discussion-Hash-Tag applied mentally.

My eyes reflect clear and open disagreement.

I look from one end of the table to another; looking into the eyes of the team members I've been working with; they are rolling their eyes in disagreement too.

The rolling pair of eyes tell me one thing: right here; in this meeting room of professionals there is a small tribe of selfish individuals who build stuff.

I feel happy.

It tells me that this room has a selected few who; thank god; are not working for the best interest of the organization. Just their very own personal selfish interest of being involved in genuinely successful implementation.

I feel safe.

Individual Contributions

I'm going to spare you the pain of having to go through a thousand words and over a dozen examples pulled out of history; that prove one thing: Almost any innovation worth its salt has been an idea and implementation that emerged out of one single mind.

Remember the Google's proprietary ranking algorithm that set them apart from a dozen other search engines out there? We call it 'Page' rank. Not because it ranks the pages but because it was the brain child of Larry Page.

Linux? Linus Torvalds.

You name a successful website; service or application out there and chances are; that if you look deep down into it's history you will find the single mind that conceived and executed the idea till the point where other builders started joining in.

What Drives Builders To Start Stuff.

Anyone who tells you that he is working for the best interest of the organization; is probably a whiner of the first order.

Anyone who tells you that he is sacrificing his own interests and is building stuff for the team or is doing so to make the world a better place is also a whiner of the first order who knows nothing about building stuff.

Any manager who tells you that teams comes before individuals and gives you a pep-talk on how the-we-comes-before-me is not a manager. Just a whiner who lugged on to the we-wagon and kept taking credit for stuff other builders around him were busy building. Someone who could neither master the art of build nor contribute through genuine story-telling about the product.

Veteran blogger; Jeff Atwood; usually ships one magnificent gem of a post every weekday. Now; if you have never owned a blog; try owning one; and try writing anything meaningful just once a week. I can tell you first hand how hard it is. If you wonder why Jeff spends countless hours writing; it is not to change the world or to help the human race move forward. He explains:

We may kid ourselves into thinking we're writing out of some sense of public good, or to create connections, or contribute some small bit of knowledge to the world. But let's face it. Most of us blog because we're raving egomaniacs. We not only love to hear ourselves talk, we're incredibly eager to hear other people talk about us, and the more the better. I think Dale Carnegie put it best.

Nothing is sweeter to someone's ears than their own name.

So it should come as no surprise that I have an automatic Google ego search set up for my name. Nothing special about that. It is considered neighborly to have your ear to the ground (within reason), and to politely comment on relevant articles mentioning you and your "stuff". All very standard, banal, ego-fluffing stuff.

Ask any genuine builder out there why he does what he does and you will get his reasons: 'because I love doing it'; 'because it is fun'; 'because it makes me happy'; the reasons will continue. Long story short; most genuine builders are aware that they build stuff for their very own selfish reasons.

Most ideas that survive as a platform start as a personal problem.

The story invariably begins like this: someone with an eye for spotting problems has a problem in his real life; spots it; figures out an answer to the problem and starts working on it; for a very long time.

Half way through other builders join in; create what marketing guys and traditional managers like to call synergy and you have a remarkable product that ultimately ends up making small or big dents in the universe.

But Then Why Would Other Builders Join In?

I can almost see a young and budding manager knitting his brows already. 'Great! Now you are suggesting that team work means nothing. That we all focus on individual contributions and forget the whole idea of contributing towards a team' - he says.

Yes; Mr. Manager. That is precisely what I am suggesting.

As someone who has himself makes contributions as patches to open source projects out there; I can tell you that I do not do it for the good of mankind or some other noble agenda of that sort.

I do it purely because I want the patch in the project SVN so that I do not have to worry about making the change every time I upgrade the version of the framework.

The folks who receive the patches are happy to apply them because it makes their product stable gets more people to use their product and gets them more popularity and in some cases an ego-boost.

None of us are working for the divine-goal-of-the-team.

None of us are giving or taking a truckload of crap about keeping 'the-we-before-the-me'.

We have common selfish interest which are aligned; which bring us together.

The teamwork; helping each other or even the so-called-management-buzz-word called synergy results out of these commonly aligned and totally selfish interests.

In fact; these are precisely the cases where the teamwork is the highest; where people from completely different countries, cultures, time-zones and people who do not even know each other; come together and make things work.

Now here is the funny part - you don't hear words like synergy and we-is-more-important-than-me in these environments.

When builders see amazing stuff being made; they will join in. They will join in because they want to be in the flow; they want to be a part of something huge that eventually leaves a mark on lives of people; they want to learn something new; they want to find and create meaning out of their very own lives; they enjoy being a part of it or for countless other reasons all of which are totally selfish.

Make no mistakes about it.

Lets Stop It. Now. Seriously.

Lets work on a project shall we?

Hypothetically; that is.

For reasons that are purely selfish; I will give in complete individual contribution to get my module up and running in time. I will bend over my back to help you integrate with it. As a matter of fact; I will even go out of my way to help you with your module; purely because; one: it makes me feel good about doing that; two: because it establishes me as a really smart person in the team and three: because I don't want a failure against my name.

I expect you do the same; for similarly selfish reasons.

If our interests are aligned; we win.

If they are not; we fail.

It is really that simple.

Can we please stop talking about team-work, synergy and exchanging truck load of crap regarding how the we-is-more-important-than-the-me or how the team-comes-before-individuals. It's boring; hugely artificial and not even funny.

If you run a team; may I suggest; dear reader; that instead of giving your team long winded lectures and speeches on how the-we-is-more-important-than-me; give them a platform where every person in your team can genuinely and truly contribute individually.

Build an environment where they get credit and recognition for their individual contributions.

Find folks who have interests that do not align with yours and get them on projects where their interests have a higher chance of aligning with yours.

Do that and all the pep-talk on teamwork and synergy that you always gave in your meetings; will not even be necessary.

Recognize the important of individual contribution and all of those organization-changing ideas that you had about team work and 'synergy' will start turning into reality; faster than you can think.

I wish you good luck.

@BuildersAtWorkBookNotice

Climbers.

You are a young, budding and really smart graduate fresh out of college.

You have landed with your first job.

Ambitious; full of dreams and a relentless desire to grow and climb the corporate ladder rather quickly .

More sooner than later you will be faced with a hugely important decision of picking the growth path you want to take.

A choice.

The sky will fall; and you will find yourself exercising frequent skips; playing the blame game; or hinting to your manager how every single f@#kup that happened was not your fault.

You might also find yourself casually hinting to your manager whose fault it was.

When the yearly reviews happen; you would have jumped ahead of all your colleagues; your manager has developed a reputation of your being an alpha-geek who never fu@#ksup and you would have earned your promotion.

You; are a climber.

Choosing to be a climber is a perfectly legitimate career choice; except of-course that there is just one minor hiccup associated with it.

Empathy.

You give none of it; you get none of it.

Yearning desire to indulge in the act of 'climbing' probably creates more asshole than any of the other reasons.

Brief Digression and a quick history lesson.

The battle of Gaugamela is taught in practically every history class that talks about Alexander. An example of amazing planning and war techniques; what only a few history books will tell you; is that this war was also a classic lesson in managing intelligent human beings; growing as a leader and winning wars.

After a fierce battle; execution of an amazing war plan; Alexander is practically minutes away from slaying his arch enemy; the Persian King Darius III; when Parmenion; a general in the army; sends out a distress signal.

The choices Alexander is faced with are fairly simple:

Continue his advance; slay Darius; win the battle or Turn around; move to help Parmenion and let Darius escape.

Alexander chooses his men over victory.

He helps Parmenion; lets Darius escape and eventually wins the battle.

Historians around the world will tell you that what Alexander really won in Gaugamela; more than the battle; was respect and trust of his army; which eventually won him multiple other battles that followed.

The Builders Path.

If you are in any remote way associated with software development; like it or not; the sky will fall; and when it does; I don't care how amazing your work culture or your work environment is; someone high up in the pecking order is doing to ask the question that ultimately destroys projects around the globe:

"Who was responsible for the fu@#ckup?"

When the sky falls; you are left with pretty much two simple choices: you can take the climb path or you take the build path.

The build path happens to be slightly less glamorous.

You find yourself sitting in front of your colleagues monitor; helping them out with threading issues.

You find yourself trying to talk about the problem rather than answering irrelevant questions like who was responsible for it.

You find yourself giving cover fire to your team and every once in a while you find yourself in a heated argument with your manager; which to be honest; is not the best way to get a promotion.

But then; you and your team scores and when the promotion comes and you have a fancy sounding designation on your business card; you know you at-least you didn't 'climb' ruthlessly all the way up to it.

If software development is a war; build stuff that is remarkable; and when given a choice; pick your men over victories.

Successful projects will follow pretty much magically.

I wish you good luck.

@BuildersAtWorkBookNotice

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.

@BuildersAtWorkBookNotice

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.

@BuildersAtWorkBookNotice

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.