I love writing on this blog. For me this blog is more of an opportunity to stand back, evaluate the experiences of my life and write about these, by adding a little bit of myself to this blog. The very fact that I post multiple times a week, turns this blog into something which allows me to exercise my writing skills and develop my writing mussels.

Having said that, this post has developed a very different audience than what I initially expected. Besides programmers, this blog is read by managers, business folks and even my mom. One of the thing that I try to pay special attention to, while writing, is the timelessness of each post.

I try to add content here which usually does not tend to become obsolete when the next version of visual studio comes out. Of course, there are one or two  exceptions, but then, most of it happens to be timeless. At-least I try to make it timeless to the best of my ability, even though when I read my older posts, I do realize how much I sucked.

Because this blog is read my more than one reader, it often means that I end up spending a lot of time adding graphics, hyper linking, formatting and proof reading all content that goes out here.

To be honest, I love doing all of that.

A huge part of my life includes working with other human beings and that is what this blog is all about.

But then, there is another part of my life. A different persona, so to say. One that deals with bytes. One that likes to fiddle with technology, explain design patterns using wild examples and whacky home made philosophies and the one that likes to tinker with the code-base of crux in my free time.

Unlike most software developers, I have been fairly open about my experiences with other developers or what I learn from these experiences but then unlike most developers who write blogs, my close encounters with code and technology often remain undocumented.

The idea is not new however. I have been thinking about this for a long time. The whole concept of learning like a teacher and teaching like a student is something that I have talked about before on this blog.

I think it is time when I can introduce a different part of my personality on a different blog all-together.

People, here is presenting, my code-persona.

Think of code persona as my personal little wall to scribble things on as I work. Just bought a new cam-coder, you might read a review that I slapped together rather quickly there. If I just learnt a neat way to solve a programming problem, you might read it on code persona. The posts on code persona might not be as well formatted or as minutely proof read as this blog, but that's the whole point. Like I said, its my personal little wall.

So What Happens To This Blog?

Nothing. It continues. Just as before.

I am not stopping to write on this blog.

This blog will continue to have posts added to it, just like before.

So if you like the kind of content that you read here, you will continue to find more of it. But if you are a hardcore programmer and you are more interested in curly brackets and semi-colons, code-persona is the blog you also want to subscribe to.

It's been quite some time since I did some serious hardcore technical blogging.

I feel like a little child again and that, I believe is a really good thing.

Feel free to hang out with us on code-persona.

More content will start getting added there soon.

Wish me good luck.

My team at Multiplitaxion Inc, happens to be a group of really seriously kick-ass programmers where even some of the weakest in the team can kick some serious butt. Fred clears multiple rounds of interviews for Multiplitaxion Inc, and wants to join this team.

I cringe.

As far as I am concerned, if you are joining my team, I prefer that you have, either gone through my interview and met my criteria or have proved yourself within the organization in one way or the other before you are made a part of my core team.

Fred as it turns out, has done neither.

He is a young and budding programmer fresh out of college who has taken an engineering degree, answered a few math questions and a few puzzles correctly and cleared the Multiplitaxion Inc, interview with flying colors.

A few mails back and forth, the really awesome folks at the Human Resources department Multiplitaxion Inc, allow me to screen the guy and they give me the liberty of taking him in my team or letting him move over to a different team.

I spend some time talking to Fred, asking him a simple question - We have a month to build anything that you want to build. Can you spend a day thinking about what you want to work on and let me know tomorrow. We will start working on whatever you pick and I'll help you as we move on. After a month we will evaluate what we have built and if it's good enough you join the team.

Fred looks at me like I just dropped a rodent on the table.

The next day he comes back with three things that he would like to work on:

1. A brand new operating system - which is what you often fantasize about building when you are in an engineering college and if you are lucky they even let you build a small theoretical kernel as your college project.
2. A brand new security algorithm - again a hugely academic project I am sure a million mediocre students in a million colleges around the world are working on.
3. A Patient tracking system for a hospital - this one, I'd rather not comment on, for the fear of sounding very nasty and mean.

Then Fred basically tells me that even though he has thought of these, he is not going to actually work on any of these. Put simply he is not up for this whole lets-innovate-idea. He wants an assignment and he wants to start working on it right away.

On any given day I get bombarded with dozens of ideas which I tend to put on the back-burner till they find me, grab me by my collar and make me work on turning them into realities. In our days, we became programmers, because it was fun and because it was empowering. It allowed you to think of stuff you could build and turn this stuff into reality.

I see, talk and work with countless programmers around the world and while the niche still gets it, I think, overall we are just breeding 501 programmers who join the software business because its good money or because their friends are joining it. Of all the things that young and budding programmers coming fresh out of college these days tend to lack, is the ability to find their own sources of motivation.

We are screwing the software development world and letting it loop in the infinite loop of failure by turning it into factories where clones are produced. If you are reading this and are responsible for hiring folks in your organization, might I suggest that you turn this into an interview question.

Ask a candidate what he would build if he was given one month of free time to work on anything that he wanted to work on. His reply may or may not impress you, but it will tell you a lot about why he wants the job. Now make an objective decision on if you really want him on your team.

Go hire programmers who can drive themselves rather than folks who want to be driven like a folk of sheep.

I wish you good luck.

Most managers typically go through the periodic phase of being an asshole. Its the time when you play the blame game. Its typically the time when you forget that you are not getting paid to screw people left and right.

The difference between a-fun-to-work-with-person and a prick is that while the prick never snaps out of that adolescent stage of being an asshole, the fun to work with manager often gets sick of it, disconnects and learns from those times. He looks back at those times of his life as painful moments and treasures everything that he learnt during the conversion phase.

He probably has a Not-To-Do list for himself which is bigger than a to do list for his team.

He is serious about the idea of being nice at workplace.

I call these folks, converted assholes.

Now, a truckload of things might have caused the conversion to happen, starting from a tragedy to just finding a pet, but a guy who was once an asshole and is now raging a war against the idea of prickdom at workplaces, is invaluable for your organization.

This is the guy who understands how prickdom works inside out.

This is the guy who can smell prickdom from miles and can spot an asshole in an interview.

This is the guy who can identify assholes in your organization.

This is the guy who can give the assholes in your organization a hard time. Sedate the monkeys. Confuse the jargon idiots with more random jargons. Attend meetings and sit through them without dozing, guarding the ground from folks pooping on your organization or team through funny decisions that are usually taken in these meetings under the name of 'working for the best interest of the organization'.

Put simply, he knows how the game is played, he plays it well and can be a bigger prick when dealing with pricks in your organization.

If you are a young and budding entrepreneur looking to have a kick-ass environment at your workplace, go hire a few converted assholes and get them to rage a war against prickdom within your organization.

I wish you good luck.

I have always nudged young and budding developers to try and turn themselves into one man armies. I have also often gone ahead and said that a good programmer is formed when, as they say in martial arts, the warrior and the weapon become one.

In a recent conversation with a young and budding programmer regarding how most office environments are nothing more than cubical farms for breeding incompetence, I stuck to my point, that most awesome programmers who know what they are doing will figure out ways to communicate and collaborate without needing a common physical location.

They will find quite islands, homes, cafeterias and corners of the world to work from. They will continue to thrive even as more and more loud or lousy workplaces continue to get built around the world.

The seriously kickass programmers will turn into one man armies and software cells that can function from anywhere and anytime. They will carry their weapons and most importantly they will carry their ability to become one with their weapons anywhere and anytime.

The Dell Mini 9, was given to me by eFORCE to try out when Netbooks first came out. I have had this thing for more than a year now and my assessment of it is that this is one rather peculiar weapon in the hands of a developer.

When I say that the Dell mini 9 is a very different kind a weapon, what I really mean by that, is that Net-books by their very nature, screen size and keyboard layout are a very different kind of a weapon in the hands of a developer.

To begin with they tend to make any developer worth his salt get a serious headache when you try to work on them. After a while, you start questioning the whole idea of working on a tiny oddly laid out keyboard and a tiny screen.

It is purely because of this peculiar nature of these devices that the Dell Mini 9 practically sat unused for months lying at my home.

I would occasionally use it to load and work on Ubuntu, but as far as practically using the device was concerned, I would cringe at the very thought of typing at the small keyboard and staring at the small screen.

I used it so little I even managed to lose its power cable.

It was not until recently that the idea of being able to work from anywhere and harnessing the power of mobility started getting discussed, that I thought I'd give the Netbooks another shot. The idea was to get a new internet access data card and use the Netbook to work from anywhere.

Today is about my first day of seriously trying to work on the Netbook and things aren't really as bad as I had expected them to be. For starters, I am getting used to working long hours on the smaller screen and the headaches are starting to disappear rather rapidly. In fact, I am no longer experiencing those headaches and bouts of irritation anymore.

The keyboard layout on this thing is slightly weird, but then I am getting used to it rather fast as well.

I have a Window 7 Ultimate loaded on this thing, along with a couple of image editing software, windows live writer, Microsoft office and a text to speech converter so that I can proof read my blog posts.

This would be my second post from the Mini 9 and as strange as it might seem, I am becoming one with this tiny weapon that lay unused at my home for months.

On the work side, I tried remoting into a office machine and tried writing some code on the remote box. It was not as bad as I had expected either. It's definitely not the only machine you would like to have, but then, it is a very different kind of a weapon for a very different kind of an attack that every software programmer must learn.

One major gripe I have with this machine, specially while programming is the position of the double-quote and a couple of other keys on the keyboard. Having said that, a little bit of practice and I think I might be able to get over these annoyances.

The funny thing about these devices, specially if you can tune yourself to become one with them and use them productively is that you can exploit the heck out of them. For once, you could be writing code on a remote box located at a data center in California as you drive through the plush green pastures of India on a  weekend vacation.

No fear of denting an expensive laptop. No worries of wearing off the battery because of excessive use. Toss it in your bag, carry it everywhere with you, exploit the heck out of it and get work done like never before, from anywhere, anytime.

Go learn the art of mastering tiny weapons, tune yourself to them and become much more productive.

I wish you good luck.

On a side note, for a detailed technical review of Dell Mini 9, see Scott Hanselman's post on the review of the device. I consider Scott to be a rather worthy maven of the software development world and his post on Dell Mini 9, to an extent, nudged me to try out my Dell Mini 9 again rather than letting it gather dust. I am happy it did.

I will continue to post updates if my opinion on Netbooks changes again but for now, I am loving the idea of being able to carry these devices anywhere and doing some serious damage using them. What is your experience with Netbooks?

Discuss.

We are seated at a local startup club where startups demonstrate their products to a bunch of fellow developers, designers, entrepreneurs or technologists. An young man is talking about his idea of building a community site with a difference. He wants to build a community site for runners and walkers around the world.

He doesn’t have a thing to show us.

No wireframes. No screens. No working systems. Absolutely nothing.

He seems to be blabbering non-stop about how his idea is different and how no website in the world has thought about it before him. It almost seems like he has just hit upon a totally different and new way to fly the skies.

During a quick bathroom break we start talking to this gentleman and I mildly and politely hint to him that maybe, just maybe, everything that he is trying to build on his community website can be easily done with a Facebook community site.

He seems grossly offended.

Somewhere, unknowingly I seemed to have shattered his dream and told him what he really does not want to hear.

Its not his fault though. Most ideas are a dime a dozen. To make things worst, when its your idea you tend to think that its the best thing since slice bread. You tend to protect your ideas like babies when your all your ideas need is dedication and concrete work, not protection.

Go on. Take the litmus test. Think of an idea. Then try to find websites that do exactly what you just though about. Chances are that you will stumble upon at-least a dozen sites that do exactly what you were just thinking about.

There is also a high possibility that when you stumble upon these websites, you will disregard them as useless and you will start sentences which begin with – "yes but this website is slightly different than what I was thinking about. It does not do 'Z' which is what is going to differentiate us from them.

Newsflash.

Your idea is already taken. Someone beat you to it and you have no unique selling points. You are just making this differentiation crap up because your brain has just switched to a denial mode where it is clearly refusing to accept that someone beat you to that idea, executed the entire idea flawlessly and is making money from the idea.

You, were late.

Deal with it.

Your product idea just does not have a unique selling point.

All that yes-but-we-are-different talk that you are mumbling is just bullshit to feed your own ego and pamper it.

You have about a dozen competitors out there and the only thing that is going to set you apart is how you add a little bit of yourself to the product and how you handle execution.

Now, take a pause. Reflect. Ask yourself if you can genuinely pull off an execution that is superior than any of the other products out there. Be careful, because even here, your brain is going to trick you into saying, 'Sure! Of course I can!' without giving it any real thought in the first place.

Take your own sweet time. Reflect. If the answer is no and if the idea is not keeping you awake at night, it's okay let go shamelessly. After all, you do not find truly remarkable ideas. Truly remarkable ideas find you. It just makes the defeat that much more easier to accept and it frees your mind to find something else that really matters to you.

Go ahead, start something that makes a small dent in the universe or just give up and wait for a new idea but don't build a mediocre crappy product because we have enough of them already.

I wish you good luck.

One of my first teams kicked some serious butt. We shouted at each other, we used the F-word rather generously and when that did not work, we raised our volumes to a level that would blow the office roof sky high.

Then when the fight was over and the best solution had won, we would go out and have lunch together with no hard feelings.

That was my understanding of strong opinions and disagreement.

These were two very useful tools to reach the best of solutions. During my times at Multiplitaxion Inc, I often tended to respect guys who had strong opinions weekly held and had  the conviction or the spine to disagree with me.

Disagreement was loud.

Disagreement was a good idea-validation-check.

Disagreement was good.

It was only during the later part of my career that I bumped into a different form of disagreement that confused me and left me totally dumbfounded.

Ladies and gentleman, if you haven't met 'Silent Disagreement' you are one lucky son of a gun.

If you have, you know exactly what I am talking about.

This is a form of disagreement where someone sits smack across the table to you in a meeting, nods his head in agreement to everything you have to say and then goes out and does just the opposite.

Consider an arbitrary example for instance. Assume that everyone in  your organization, starting from the lowest programmer fresh out of college, all the way up to the chief-executive-officer agree on having a free open internet access policy.

You call the group who is responsible for maintaining the restrictions on firewall in a meeting where you tell them to drop all restrictions from non-work related sites like Facebook or You-Tube. You are going to trust your employees work ethics more than a firewall, you tell them.

Everyone nods in agreement.

You wait for the firewall policies to change and Facebook to get unblocked. Nothing happens. Days later someone higher up in the management sends a flame mail, asking that all sites be unblocked immediately, and everything gets unblocked, only to get re-blocked a couple of days later.

You call another meeting to discuss what went wrong here. Did we disagree on something? Did we not collectively decide that we were going to have an open internet policy? Did we not agree on that? Didn't we waste an entire day discussing the pros and cons on having free internet and trusting your employees versus blocking non-work-related sites?

Strangely enough, even in this meeting, everyone agrees to the idea of an open internet policy.

Strangely enough, non-work related site still remain locked down.

It is then that you realize, that you are not dealing with rational, thinking, objective individuals who believe in strong opinions weakly held. You are up against folks who take every argument personally, folks who indulge in strong flavors of mitigated speech and folks who do not express their disagreement in words but instead choose to disagree, silently.

During my career as a software developer I have seen countless examples of silent disagreements. I have seen examples of folks who think that they should say 'no' to their managers but who lack the spine to say 'no' to their managers on their face, so they resort to silent disagreement. I have also seen folks who think that they are working for the 'best interest of the organization' and use silent disagreement to avoid all arguments or discussions.

Assuming that you can bring about change in your organization, if there is just one thing that you can change, I suggest you put an instant stop to silent disagreement within your organization. This is another one of those issues that you are way better of confronting rather than avoiding.

Go on, confront the folks who tend to disagree silently, and demand an open objective argument or total agreement through not just words, but action.

I wish you good luck.

I'm heading to office. The phone rings. Someone, somewhere wants a stupid signature on his release letter. I tell him I'll be there in about thirty minutes. My DVD company just shipped the next DVD on my queue to my office and I'll get it the next day. My manager is calling to catch up on how things are going. My phone is losing charge already and so am I.

I am juggling with an iPod, a phone, a book and the bus playing a stupid radio channel - when all I should be focusing on is enjoying the long roads that pass me by. Or I should be reading the amazing book I grabbed last evening. I am doing, twenty other things.

Then I walk into office, hoping to get to the bug I spent my entire last night thinking about. I woke up with my mind still chirping at the problem and I found the answer when I was in the shower. It feels like first day at work. Knowing that I have the answer and experiencing the pleasure of putting the fix in place.

That's when I open my mailbox.

A dozen other funny problems await me. Someone is not being able to make it office because of a headache. Someone has a broken laptop and is whining about it in a mail trail. The support guy responsible for fixing his laptop is yelling back and using the caps lock key rather generously both in his written emails and verbal communications. Yet another client is raising stupid, irrelevant red flags.

My miserable little dreams of focusing on one thing that is important and blurring everything else out seem to be getting shattered like a house of cards. That's when the headphones come out.

If you read this blog, you probably know my preference of silence over any form of music when I am consumed in work, but headphones serve another important purpose. Ted Dziuba explains this behavior of using headphones rather articulately in his post titled - Break my concentration and I break your kneecaps. He explains:

I own a good set of headphones that fully enclose my ears. I am not an audiophile, I just don't like to hear other people talk at me.  When I am staring at my Emacs windows with headphones on, it generally isn't a physical cue that I am looking for conversation.

In fact, when I am that deep into thinking out a problem and I get interrupted, I think about the anti-workplace-violence clause in the employee handbook, and how a poorly lit parking lot probably doesn't qualify as "company property".

Interrupting a thinking programmer is a sucker punch to productivity's kidney. Of course it's still important to keep open communication channels, especially in a small team. I don't mind answering questions and helping out, so long as it's not an immediate context switch for me, i.e. I'll help you if I don't have to speak.

On any given day, there are a dozen tasks that I ignore. There are probably dozens of emails that I ignore as well. The underlying assumption is simple. If it's truly  important, someone, somewhere will remind me or someone somewhere will talk about it. If no-one reminds me that it is important, it probably isn't important. I can go back to putting my headphones on and working on things that I believe will eventually matter in the long term.

Then there are things which are pseudo-important, the false urgency alarms, the trivia of broken laptops, egoistic arguments, meetings and the discussions on the status of how things are going. Being a programmer isn't just about programming and chances are that on any given day, you are going to be bombarded by things which seem important but at the end of the day, your ability to ignore them is going to be much more important than your ability to get them done.

Slow down. Take a pause every now and then. Think about, what matters the most to you and spend most of your time on things that matter the most, because most other things that seem really important, hardly matter. Most things that you do on any given day are just random distractions.

Go, reflect on what is really important to you and then spend most of your day, doing those things.

I wish you good luck.

During my days as a young and budding programmer, I was bubbling with confidence. Never in the wildest of dreams did I imagine that a software project or a task given to me could just not get done.

I mean, sure I might have to throw in a few extra public variables, not have enough time to give a shit about the quality of the code I was writing or throw in a couple of hundred band-aids on the codebase, but I would still get the job done.

Put simply, I knew if I worked fourteen hours a day I could stick it up together to deliver to a client. I also knew, if I acted smartly, I would not get my ass kicked or busted. To add to that, if I used enough jargon I could blame it all on requirements, use-cases or some abstract shitty artifact that was always responsible for the failure of the project.

Young engineers learn the shit that they see their seniors do and they learn it fast.

Then it happened. My first successful failure where we were building a piece of software that was sofa king (to be read really fast repeatedly) complex that the thought occurred to me a month before the delivery date - what if, we don't make it - the voice said deep down within as I tried desperately to write a function that would increase the power of the device my code was supposed to control.

This was a project where we were integrating with random devices around the world and some of them had serious issues with their hardware, which is what we were working around. This was not a typical - 'what if we don't make it in time' or 'what if we are a week late' question. Those, you can answer by pointing your finger at a random artifact. This was a case of 'what if we just cannot build this project'.

We did not have shit to show to the client.

What we had, did not work.

What if another one month passed and we were not able to crack the show-stopping problems we were facing?

What if we just did not get anything done?

The question was scary. The realization that I as a software programmer with just a couple of years of experience behind me, had limitations which were as real as gravity was scary. The realization that I could not overcome these limitations with trickery, big talk, smart ass ideas or stupid band-aids was even scarier. All the tricks that my so-called seniors had taught me were failing me. Blatantly.

The project ended without anyone getting killed. We threw tons of band-aids in there. Got a few things done. Then, I struggled for hours and days to set it right before we handed over the project to the client and moved on. Multiplitaxion Inc announced it a grand success. I called it the first (and hopefully the only) successful failure of my life.  

I don't want to live that part of my life again. It was terrible. It was scary. It felt like shit. What felt worst after the project however, was not the fact that I was overworked, stressed out, about to quit had it lasted sometime longer or any of that. What felt worst after the project was the feeling of being used - almost like a mindless human bomb who goes and blows himself up for a cause which is totally insane and downright stupid.

This was the part of the project, that helped me grow in ways I would have never otherwise grown in my entire life.

One of the most important things that the project taught me was the art of caring and putting in my one hundred percent into the work that I do, without giving a f@#ck about what my team, my managers or my clients classify as 'success'. After all, I had just been a part of a project that my team, my managers and even my clients classified as a huge success when the reality of it is that it felt like a one big colossal f@#k-ups of my professional-work-life.

Since then I have come across countless examples and incidents where a client somewhere wants me to believe that my tiniest of non-confirmations to their processes, their dates or their deadlines, equates to a humongous failure. The idea is simple - convince the programmer psychologically that shipping the software on a specific date with a specific list of features is so hugely critical that his entire career depends on it and then he will ship.

I have been through so many of these situations in my life, that I almost find them hilariously funny every time I encounter them now.

Every time I come across situations where I am being told how critical it is to ship on a given date or just how critical fixing a spelling mistake of a label is, I smile inwardly, argue outwardly and somewhere deep down inside, there is a calm, quite, silent voice telling me:

'You have been through this before Pops. You know what to do. Give it your best shot, be honest to yourself and then don't give a rat's ass about the so-called-success.'.

Years ago, after my first successful failure, I learnt that you are way more efficient if you leave your fears of failure behind and replace them with passion. If fear and pressure move you, that is all you will get your entire life.

On the other hand, if you are moved by your own passion to do amazing work, questions like - what if we do not ship on time or what if we fail - will just start sounding seriously stupid to you. You will eventually stop worrying about them and start giving your best shot irrespective of whether these questions are asked or not.

When the sky starts falling, don't panic. Prioritize. Think pragmatically. Give practical options to your clients. Do all you can to turn your project into a win-win situation for everyone connected with it. If you keep getting bull-shit in return, continue helping them, continue shipping, continue putting in your best but just stop giving a rat's ass about what anyone on the project says about the success of failure of your project.

It's time to wear a thicker skin.

I wish you good luck.