Knowing The Geek Within And Learning How His (or Her) Mind Learns.

As a geek who has ADHD I am intrigued by the idea of observing the learning process rather closely and hacking the heck out of it.

As someone who had major trouble focusing on a book end to end I realized that my attention span shoots up when I am listening to audio books. This might seem like a tiny little realization to some of you guys out there but for the geek within me this was huge. It was a discovery of a hack that allowed me to break inherent limitations of my mind and push beyond them that intrigued me the most.

This meant that I could grab an audio book out there and be done with it in just a few days.

Heck! I could even turn a text document or a PDF into an audio book.

The same approach even made proof reading for this blog much more easier.

As someone who had strong feelings his entire school life, particularly classrooms or lousy teachers sounding like experts and as someone who recently quit his French classes half way through, classrooms are also one of those approaches to learning that often do not tend to work well for most geeks and yet they exist. A concept Khan Academy has managed to hack the heck out of.

Are you really learning when you attend a training session?

Are you really asking a question based out of genuine curiosity or are you just trying to impress the trainer or other participants?

Do endless arguments on Forums and Blog Post teach you something or are you just better off marking a thread #EOYBD and resisting the temptation to respond once it reaches a point where you realize you have not much to learn out of it?

Are you learning the most when you are talking or are you learning the most in your quite time when you are in a disconnected mode?

Are you learning better with the technical books out there or does more information and spice mixed with technical content helps you understand and recall information faster?

I don't have all the answers here.

What matters however is, are you giving enough time, attention and effort to learning how you learn best?

If not, why not start now?

Chances are that the geek within you that spends hours tuning that database might love tuning the heck out of your mind and figuring out new approaches to learning that might help you move beyond your inherent limitations.

Each mind is different and you will need to figure out what stimulates, excites, motivates, captivates and keeps your mind hooked. Start by understanding the basic rules, learning some basic hacks and then overtime figure out your own hacks, tweaks or workarounds to enhance your learning process and add fun to it.

I wish you good luck.

An acquaintance who recently moved from a small but innovative software development firm over to Infosys tells the story of how the organization runs. He starts the discussion by talking about the plush green and well maintained campus of Infosys.

Something even I have talked about before.

Then he moves to the overall process and some of the facts that emerge during the discussions are chilling to their core. Here are some highlights of the discussion to give you a quick idea of the process that powers Infosys.

Nine hour workdays

Infosys demands that every employee spend at-least nine hours a day in the company campus. The electronic cards record your in time and out time every time you swipe them. This person forgets swiping out his card on a day and gets an email from his project manager letting him know that this behavior is unacceptable and that he needs to pay special attention to these details moving forward.

Talk about working less.

Ties Two Day A Week

Infosys demands that all their employees wear ties in the office complex two days a week. They take this rule rather seriously. So much so that the security guards at the main gate have been instructed not to let anyone in without a tie on the specified days.

Talk about wearing what makes you comfortable.

Compulsory Internal Exams

Infosys demands that employees clear at-least two internal functional exams with a minimum of sixty percent marks. Your failing to do that prevents you from getting a promotion after three years. Promotions cannot be obtained just by giving kickass performance at your project.

Passing the exams is critical. If you do not study for these exams like young college going students and do not clear them your chances of climbing to the next level after three years of service are slim.

These exams are not Microsoft or Oracle vendor certifications and are internal Infosys exams which have no meaning outside of Infosys.

Monitoring Your CPU utilization

Infosys is working on a new system which will monitor CPU utilization of every developer to see how actively they are using their machines. Something that they believe will be a better indicator of if the developers are really working. Just spending time in the office premises apparently, is not enough. They need you to be slamming those keys at the keyboard and utilizing that CPU firing builds.

Internet Access Depends on Your Level

Internet access depends on your job designation and level. Level 300 and below for example are not given internet access around the clock. They just get internet for a couple of hours a day. Senior levels still have personal email sites like gmail blocked. If you are an engineer who is working at or under level 300 and are heavily dependent on Google for your work, you are basically screwed.

Selection Criteria And Client Interviews

Infosys still spends heavy amount of importance on school and college marks even while recruiting candidates with over five years of work experience. They also conduct regular client interviews where their engineers are expected to answer questions that their overseas clients ask them over telephonic interviews.

A huge number of Infosys engineers (in the case of this acquaintance this number was eight out of every ten) fail these interviews miserably because there is a huge disconnect between how much they scored in college versus what their clients expect them to know.

Not to mention of course that over the course of time these candidates figure out means to clear these interviews by collecting questions from folks who were interviewed before them and maintaining their own question banks.

Angry Employees

Even though this was not directly mentioned by the acquaintance after this discussion I set out to find the truth about the level of employee satisfaction and apparently stumbled upon countless examples of the employees venting out their frustrations and anger openly in the comments section of wall street journal blog and the Times of India blog.

All of these articles and the passion with which the comments were posted seemed to suggest that Infosys was not keeping the best of their employees happy either.

Automatons And The Programmers Bill Of Rights

Of course the point of this post is not to thrash Infosys per say. It is by far one of the best consulting body shops India has to offer. Having said that, the state of affair of most software consulting shops in India and around the world is tragic.

Maybe it becomes so hard to find programmers who cannot program because most huge organizations around the world aren't looking for programmers. They are looking for and breeding automatons who punch their time cards, wear ties to office thrice every week, clear three exams every year, learn up answers for client interviews and score high in their high school and college.

If you are a young and budding entrepreneur, Infosys and the similar breed of companies provide a perfect template of practices which you should put down in your "not to do" list.

As you grow your organization, do you also give in to the temptation of hiring and herding flock of sheep who obey your rules or do you have the courage for remaining small in spirit even when your organizational size grows slowly and steadily? If you are reading this and run an organization, remember this, you cannot "Out-Infosys" at being Infosys, setting rules and hiring automatons. If that is all you do chances are that an Infosys somewhere will outbid your business.

What you can do is be small, cater to a niche and hire smart human beings who have talent, individuality, their own opinions and the spine to say no when asked to wear a tie five days a week. Hire the best that you can get. Hire like the life of your organization depends on it. Once you have done that, try sticking to and honoring the programmers bill of rights instead.

I wish you good luck.

There is nothing that pisses your technically savvy and intelligent customers off more than pictures of random men and women in suits grinning away to glory on corporate websites of enterprises around the world.

Stock Photos by their very nature indicate that there is something seriously f@#kuped up within the corridors of your organization.

The sexiest of voices hired to do voice overlays on product videos tell your customers that either the product is built by a bunch of engineers who did not care enough to make a product video themselves or the product is so weak that it needs a sex appeal of a cute voice to cover up its flaws.

Are you hiring smart builders who are also doubling up as wordsmiths?

Are you hiring smart story tellers who can weave such a compelling story that people get gripped and watch the video even if the background does not contain a cute female voice?

Are you building a culture that is so strong that random photographs taken on any given day can be things you can put up on your website?

You do not need stock pictures, sexy voices, men in suits with cheesy smiles or even a corporate look on your corporate website.

Make a remarkable product.

Be Yourself.

Its a lesson all of us learn multiple times in multiple walks of life.

This time, remember it and start living it. You might be pleasantly surprised.

Now go rebrand your website to reflect your true personal or organizational character.

I dare you.

The Microsoft SQL Server 2005 pricing model is transparent, online and in your face for you to decide if the product fits your pockets.

MySQL on the other hand seems like a "call us to find the price" operation when you first Google for its pricing.

The kind I prefer referring to as the Mafia Ransom Pricing Model.

Even though MySQL is in reality not a "call us for pricing" operation I cringe every time I see marketing guys show their famous "call us for pricing" move.

Pricing is hard. Pricing takes a lot of experimenting. You can never price your product to please everyone.

But that does not mean that you run away from the problem all together, hoping that your potential customers will call you every time they want to know the price of your product and then they will spend countless hours haggling with you.

The "call us for pricing" approach tells your customers that you have no clue about what your product should be priced at.  It also tells the customers that you are going to charge each customer differently not on the value your product provides but on how much the customer is willing to pay or a host of bizarre factors.

Consider this line on MySQL pricing page for instance:

With MySQL Enterprise Unlimited, companies with up to 1000 employees can deploy an unlimited number of MySQL Enterprise Servers, with full 24x7 production support for a fixed price of $40,000. You also get unlimited 24x7 access to MySQL Enterprise Monitor.

It does not take a rocket scientist to catch a bad vibe about the pricing model if you are somewhere in the nine hundred employee ball park and are looking to hire more people. What happens when you cross a thousand employees? You call up folks at MySQL and haggle with them?

Ever wondered what the correlation is between which database your project uses and how many employees your organization has? None.

To understand this concept of "no correlation" between what you charge for your product and what the pricing depends on, lets start by assuming that we had an awesome word processor that you were interested in buying. We started off with the "call us for pricing" tagline on our website. Now lets assume that out of the hundred customers that saw the website and the ninety seven who never came back, you fall in the range of three customers who did.

Let's also assume that you actually picked up the phone and decided to give us a call. On the call, we told you, that what we charge you for the product is going to depend on what kind of documents you choose to write with our word processor.

If you write a blog post that no-one reads, we would give you the word processor for fifteen dollars a license but if you were to do the sales deed of your home on it, the price of the word processor would shoot up to five percent of the deed price.

Picking important factors which have strong concrete correlation to how you price your product is also important. Pricing a database license based on the number of users or processers is perfectly fine but pricing it on the number of employees in my organization is as messed up as pricing a word processor based on what I plan to do with it.

MySQL does seem to have a well defined pricing page too and this post by no means is an attempt to thrash MySQL. The point of this post however is to convey the central idea which is this:

Every time I see a product website with well defined versions and price tags attached to these versions, I make a decision based on if it fits my pockets and needs. Every time I see a "call us for pricing" tag on the pricing page of a product, I cringe. I almost never call. But then again, maybe that is just because I am a geek. Pricing is a hard problem but that does not mean you avoid it. Putting a "call us for pricing" callout on your website is not an answer.

Now go figure out your product plans, prices and publish them on your product website.

I wish you good luck.

Of the first few times I recall being addressed to as a geek or a nerd, one was during my high-school days. It was meant to be a slightly derogatory remark passed in a setting which shook me up for a couple of days.

Fast forward a few years. I am called a geek again.

This time I smile inwardly and take it as a genuine complement.

Somewhere between the two remarks a lot of things changed but fortunately the Geek within survived these years. Most of him remaining unchanged.

Somewhere between these two remarks, I was also fortunate enough to bump into dozens of other geeks who had not just survived, but thrived. Flourished. Made small and big dents in their universe and had told the world around them in a loud and clear tone that they were there to exist. On their own terms. Without changing. Their weirdness, their stupidity and insanity turning into their primary survival and growth technique.

As I observed these Geeks not just survive but actually thrive and create a ruckus in their world, one of the things that absolutely fascinated me was the mind of these geeks and how it usually works. There was a pattern emerging somewhere. There was something about their mind.

It was weird. Insane. Wired strangely. And yet, it was rather fascinating.

The more I observed these minds, the more convinced I became that there is a lot to learn from these minds.

We are not talking about the Pseudo-Geek mindset here. The kind whose resume you see floating in Job portals around the world. We are not talking about the kind who can calculate their monthly take-away to the precision of decimal points after tax deductions when they look at the offer letter for their new gig. That is the race of dangerous programmers who often cannot program or professionals who will cheat and rob you at the first opportunity that they get.

What we are talking about is the mind that figures out the intricacies of an encryption algorithm and implements it but cannot get itself to care about calculating his monthly takeaway or submitting his reimbursement forms on time.

We are talking about the mind that spends hours focusing on understanding the universe and everything in it from the viewpoint of a system and the personality that tries countless ways to tweak the rules, hack them, break them or work around them. We are talking about the kind that loves doing this.

Now, if you are a genuine Geek, chances are that you have not tried understanding your brain or your thought patterns, with even one tenth the effort that you put in your last project. Of course you might have gone in and grabbed a copy of Being Geek but then do you take a pause every now and then to dissect and analyze situations where you react differently than a perfectly normal-sane-practical-human-being? No? Hardly Ever? Thought so.

This series of posts is my attempt at doing that. It is my attempt at answering how a Geek thinks. How he works. How he reacts. How he sees things. It is an attempt at understanding the minds that have fascinated me ever since I first realized that I might not be as awesome as them, but I can connect to them and understand what makes them tick.

If you are one of them stay tuned for more on the topic as this series of posts unfolds itself. If you happen to work with Geeks or Nerds and were never quite able to figure them out these articles might help you get a deeper insight into the minds of Geeks and Nerds. Stay tuned for a series of posts where we attempt to understand the minds of the genuine geek that might be sitting right across your cubical or maybe even inside you.

This classic hugely inspirational scene from Glengarry Glen Ross has been one of my most favorite when it comes to getting things done.

Having said that, I am not so sure that this is a scene young and budding software marketers or sales guys should be watching though.

Coming from a consulting background I have been a part of countless sales calls and meetings. After watching countless sales deals that fizz out, if there is one thing that I have learnt about selling stuff it is that, If you want to sell badly enough, you will sell badly. If you try hard selling, selling will become hard.

Recent discussions with someone at work reveled a fascinating story on selling his used car. This person had been thinking of selling his car for a long time.

Somewhere during this time, his friend lands up with a broken car and since this car is sitting unused in his garage, he decides to help his friend and let him use it for a dew days.

"A few days later, this friend of mine comes to me and makes me an offer for the car", this person explains. "I told him that German cars need a lot of maintenance after a few years and if he wants a cheaper used car, he should be going in for a Japanese car, but he kept insisting on wanting to buy my car".

"I guess the one thing I learnt about selling and the whole try before you buy model is that you have to have genuine interest in helping someone when you let him 'try' your product. You cannot be thinking about selling when you are helping.", the person concludes his learning from the story.

The point? If your 'try' part is focused on moving your customer to the 'buy' part you will almost never sell. If your 'try' part is focused on helping the customer and letting him discover for himself if he genuinely loves your product to come back to you and buy it, chances are that you won't sell to everyone, but chances are also high that you will hit a niche of people who will really "want" your product.

Don't try to sell to everyone. Don't try to sell anyhow. Don't try to sell all the time.

If the "Always be closing" model is not working for you, the best you can do is move to an "Always be helping" mindset and then when you see someone who genuinely wants your product, give them the line that is dotted and chances are, they will sign on it happily.

I wish you good luck.

When you are the kickass rock star alpha geek of your team churning out code by the minute and getting things done, you love being in the flow. Then slowly, as more and more people in your team realize you can help and as you accept one promotion after another, somewhere it becomes fairly obvious that if someone in your team is stuck he is supposed to walk up to your desk and cause an interruption often without asking if it is okay to interrupt.

The first few years of this 'helping mode' are fun. You are busy helping everyone. You don't really care if you are not churning out a lot of a real work yourself. Time moves on. Fast forward a couple of years. You have managed to stay deeply connected with code, but on an average you just find a couple of hours of non interrupted work in a day. There are days when the builder within you asks you the question: 'What did you do today?'.

You know the answer to the question instantly.

The answer freaks you out.

There are two knee jerk reactions possible in this scenario.

If you were the geek who always loved code, you are going to go back and assign the most complicated module to yourself, lock yourself in that cubical for days f@#king up your responsibilities as a manager and those emails from your clients are going to sit in your inbox unanswered.

If you are the guy who was never quite good at coding you are going to take it upon yourself to walk up to every developer you can find and ask them the status three times a day. You are going to answer every single email in your inbox and watch your experience as a developer go down the drain as you morph from a capable alpha geek to someone who just answers emails and talks.

Both of these knee jerk reactions are small steps towards big problems.

What you need to do is take a pause. Breathe. Let the question soak in. Reflect.

What did you really do today?

You helped Jack by taking his rather long winded function and using an API that would do the same work in half the lines of code. You researched the API. You tried a quick POC on it with Jack. Of course, it was his work but it was your job to keep him moving forward.

Then you spent time responding to emails and building a story around your product so that the clients don't just look at the data.

You picked a bug or two. Fixed those. Did a scrum. Thought about a couple of new features.

And in the process of these you answered about a dozen questions on a feature, on a decision that had to be made or a problem someone was facing. You have done enough by doing nothing concrete which you can sign off as your work.

If there is a geek within you, he is never going to see any of the above as real work so yes you do need a couple of hours a day when you are logged out where you work on keeping your sword sharp and churning out some real code.

Having said that, the sooner you get used to the idea that at some point of time in your life, you will have to stop adding items to the list of things you personally did, stop showing this list to your bosses and start spending a decently big part of your day mentoring, teaching and guiding others, even though this does not really qualify as 'real work' according to the geek that you still are, the better off you will be.

Go on. Strike a balance between teaching, inspiring and doing.

I wish you good luck.

Earlier last week we talked about the Thousandtyone youtube video channel. Last week another video on the series of Entity Framework videos has been uploaded to the channel. Going forward additional videos are expected to get uploaded and if you would like keep a track of all the topics of videos that are getting released here is a quick table of content that will get updated every time a new video is uploaded.

Going forward an additional RSS feed will also be added for the videos. The whole point of starting the video channel was collective learning. If there are any specifics topics you would want me to cover, feel free to view the list of upcoming videos, vote and add items to the list.

Looking forward to your opinions, ideas and suggestions.