Project Plans and Gantt Charts have floated around in office corridors since Project Managers have existed in the business of software development.

The thing with folks who run around with these documents and knock on your cubicle three times a day, is not they they are bad human beings.

If they could have helped the developer who is running late at meeting his dead-line they would.

But most of them stopped programming at the first opportunity they found.

Typically here is how a developer manager conversation that I often overhear runs:

Manager: "We are running really late. Do you know what is wrong? Why are we taking so much time?"

Developer: "Not sure. I mean it is pretty straight forward but this nested query keeps timing out for no particular reason. I mean this is a simple cursor that takes the data from a table, throws it in a temporary table and then filters out the data we do not need. We have done similar queries in the past and they all run just fine."

Manager: "How much more time do you think we will need?"

Developer: I'm not sure.

Manager: Can we try to do this by the weekend? Its really important.

Developer: Hmm... okay... I will try my best.

Manager: Thanks. I will go ahead and update the status report.

Can you see what is happening here?

First, none of the parties are at fault here. They are just speaking a different language. The developer is clearly seeking help. He wants someone to sit down and take a look at the nested query. The manager would have loved to help, but he cannot. As much as he would love to help, he knows as much about cursors and queries as the developer knows about the Gantt Charts.

Usually in these cases, the manager also misses an important queue: that the developer is seeking help.

The manager switches to the Gantt Chart mode and talks about how much more time the developer would need.

After a while the developer gets the rules of the game and he stops discussing technical issues with his manager. They try to talk the language of the Gantt Chart, except of course, there is only one problem: Developers suck at speaking that language, specially when it involves saying no.

A disconnect begins.

Very soon, the performance of a developer who was otherwise thriving, takes a steep hard nosedive.

The post is not about criticizing managers or developers. I also don't have a recipe for success here. The only advice I can leave you with, if you are managing a team of developers, is, look for slightest of signs when your developers need help and when you notice that they need help, help them. If you cannot help them because you are not technical enough don't hesitate walking up to anyone in the organization who can genuinely help and ask for it.

Until you do that, chances are, that the nested queries will not automatically speed up by the end of the week.

The story of NewsTilt and why the young startup nosedived its way into failure and eventually shut down sends a chill down your spine as you read it.

As you read the post which describes one of the founder's view of why the organization failed, you start reading between the lines and you start finding dark gaps which give you a glimpse into what the real reason for NewsTilt's failing might have been. Embedded between the lines of the posts you find chilling comments passed with an innocent, matter of fact tone which make them all the more scary. For example, Paul (one of the founders of News Tilt) explains:

Since we needed to build so quickly, as soon as we got some money we wanted to hire another technical person. Nathan had a friend he wanted to hire, who was exactly the kind of great programmer he could work well with. However, it took some convincing to get him to try working on a news website, and he wasn’t sure he’d stick with it. We were sure we’d be able to convince him to stay, and we even waited two weeks for him to move to work with us.

Unfortunately, we were never able to excite him about the project, and we quickly realized he was never going to be intrinsically motivated the way we need for a first employee. There was a point when I was over in Cambridge with Nathan and the other developer, and I noticed that the developer wasn’t working on a Sunday. Now, we aren’t the kind of people who think our employees owe us 90 hours a week, but startups need that kind of work ethic from very early employees–exactly the reason that intrinsic motivation is so important. If your first employee doesn’t love what you do, doesn’t wake up each morning dying to work on HIS product, you have likely chosen poorly, and that’s exactly what we did.

As you skim through the article you begin to understand that the problem with NewsTilt wasn't any of the reasons mentioned in the post. The problem with NewsTilt probably was the fact that the founder believed that by jumping into an unknown domain and hiring idiots who work ninety hours week can make you a shitload of money. Take for instance this quote from the post:

Somewhat surprisingly, the journalists we picked were too good. We made a big deal of only hiring the “best journalists”, something we spent a great deal of time getting right. We had a guy with a Pulitzer, one with an Emmy, and overall a great deal of talent writing for us [3].

In hindsight, this may have been a big mistake. The kind of writer we actually needed was one that was hungry to succeed. Someone who would write five pieces a day, and who wanted nothing more than to be a big-time journalist. We needed a young Perez Hilton or Michael Arrington, people who wrote for 18 hours a day in order to make their names.

Instead, we got journalists who were already successful in their day jobs, and who already had families and other commitments.

Not to mention of course that these journalists were working for free. If this post does one thing, it bring out NewsTilt as a company which expected everyone, their employees and their journalists, to sacrifice their personal life and give in eighteen hours a day behind an idea and a domain that the founders themselves did not know anything about.

Paul explains why his idea was great and that Google could have made it work:

Google could have made this work. I believe that if Google applied the same model they could probably succeed. They have the tech ability, they have the traffic, and they already have a massive news property. They also have have a big problem with whiny news organization, and an elegant solution would be to kill them off by enfranchising their journalists to be their own bosses.

Of course Google could have made it work. But then again, Google is okay with giving twenty percent personal time from their normal five day work weeks to their developers, leave aside expecting them to work Sundays. Besides, Google is also not pointing fingers at their developers for not working weekends when their products fail. Not to mention that most successful developers work less and say no to meaningless slogging.

Let's face it. NewsTilt probably failed because of a lousy founder who wanted people to stop having a life and work ninety hours a week for an idea that he himself did not know deeply.

The entire post runs into pages and by the time you are done with reading it you realize that Paul could have done a way better job with the post by just saying  "I fu@#ked up. I am sorry". It would have been way better than whining about the developer not working weekends and the journalists having families. But then again, saying "I fu@#ked up" is hard.

Besides, realizing how bad you are at something requires the same skills that you need to become good at that thing.

Paul as a founder has a terrible blind spot that most readers of that post can see rather easily.

Go on. Read the chilling story of NewsTilt and it's failure and as you read it be sure to read between the lines and learn exactly the kind of attitude you should avoid while leading an organization, startup, business or even your small team at work. That and when you make mistakes, stop pointing fingers at others and accept the fact that it was you who fu@#ked up. After all, it is always your fault. Seriously.

The topic of a recent discussion that I got into revolved around what made 37Signals, 37Signals to begin with.

Was it their life style?

Was it their methodology?

Was it the fact that they were small?

Was it their book, Getting Real?

The opinion that emerged out of the discussion was that the answer was none of these. What made 37Signal, 37Signals is that they contributed true value in the form of Ruby On Rails, then Basecamp and then truckload of other products.

Ideas are a dime a dozen. Anyone can start a blog and talk at length about how amazing product management should be done.

Of course, anyone does not include the millions of 501 programmers, who cannot even program or muster enough motivation to lurk at a blog or own a book on programming, leave aside writing one, but well, anyone with enough motivation, some basic writing skills and some imagination can talk about software development and do blog posts on wisdom gained from doing years of software development.

If you do not have years of experience in software development, you can talk about social media and pull numbers straight out of your ass and impress people. Or better still, you can just quote numbers others have pulled out of their ass and act smart and knowledgeable.

If even that does not do it for you, talking about Entrepreneurship and how you will run your company when you start it up might do the trick.

Preaching, is easy.

Don't get me wrong. Sharing of ideas and experiences is what this blog has been about since its inception and we need some inspiration and sharing of ideas from time to time. It keeps our creative spirits alive. But too much inspiration can be addictive.

When you find yourself taking shots of inspiration morning, afternoon and evening. When you find yourself seated in meetings about entrepreneurship once every week, you know that you are just talking. Participating in a discussion, even at a world wide scale is good but do too much of it and you get a little sick and tired of it. There are times, when after years of blogging, you look back at your blog and you question if the value that you have added is adequate.

Yes you contributed a few innovative ideas, you sparked a few interesting discussions and you rocked on Reddit a couple of times but are ideas, thoughts and discussions all you can contribute? What about real value? What about a real product? What about discussing real code?

Somewhere months ago I asked myself this question and started Code Persona, my little corner where I document my development experiences. The site of course did not take off primarily because of lack of content.

Within weeks of starting the website it was rather evident that I might be decently acceptable at writing code (who needs talent when you have intensity) my ADHD makes it nearly impossible for me to write technical posts on the web much like I find it difficult to be reading from a physical book all the time.

But recently the desire to add genuine, concrete, value has been driving me nuts. In short, I have done enough of preaching and while I love sharing ideas here, which I will continue to do as frequently as I have been doing, I also really want to get out there and discuss something concrete. Like, say, code for example.

Without going into specifics, lets just say that it was simple divine intervention, that prompted me to grab a microphone and headset that had been sitting on my desk only to get used occasionally for boring conference calls, to start recording a series of videos on Microsoft Entity Framework.

The thousandtyone youtube channel was born.

This is 'not' going to be about thoughts on management, this is not going to be about discussion on process and hopefully this is not going to be about countless arguments on what is right and what is wrong.

This is going to be the IDE and code. We start with a series of videos on Entity Framework and from there every week we will dive into anything and everything that seems interesting. I spend a good part of my day breathing, writing, reading, eating, drinking and thinking about code. It is high time I start contributing something through it.

Like I said, the first series of about five to six videos is going to begin with Entity Framework but from there, we are going to jump into anything that seems interesting. Object Orientation, Inversion of Control, Test Driven Development. If it seems interesting, we might end up doing a quick fifteen minute video on it. If the video does not cover everything that had to be said on the topic, expect the video to turn into a series of videos.

Also expect to see a video series on Getting Started With Programming. I know quite a few business analysts, testers and managers who can benefit from that. Besides, the real motive behind that series is going to be teaching my young eight year old nephew how to write code.

The YouTube format of fifteen minute videos works perfectly for someone with ADHD like me. Besides you can chose to skip the videos, rewind them if you do not understand them or play them at triple speed if you believe we are moving along too slow.

Long story short, here is the thousandtyone youtube channel. We are going to write code on the record mode, we are going to learn how to write better code, we are going to teach you how to write better code and we are going to do that rather often. Hopefully, every week.

Code Persona will get updated every time a video gets published on the channel so if you are subscribed to it, you should get notified every time a new video hits the thousandtyone youtube channel.

Basically, it's like this. I spent all these years talking about good programmers and good programming. Here is your opportunity to see me writing code and tell me how much I suck at it. You are not going to miss that opportunity, are you? #Grins.

Go ahead, hit the channel, take a look at the first video and subscribe to it if you are interested in being a part of it.

What is your role in your organization?

What are you responsible for?

I know you are confused about your existence in your organization.

I know your designation means nothing.

But if you are a kickass programmer these are probably not the things that bother you as much as random stupid unpredictability in your work life.

Lets jump into the depths of time and bring from the ages that have rolled behind, the gist of what pissed off the best of the programmers at Multiplitaxion Inc. It was movement. Unpredictable, completely irrational and sometimes hugely irritating movement.

As a programmer you spent months working on a project. Putting in sweat and blood on the project and getting attached to it, only to be told one fine morning that you are now going to have an idiotic moron leading the project and you are expected to report to him.

Then there were historic moments where some of the most kickass programmers walked into office only to find out that they were expected to move to a different project all together and start their knowledge transfer effective the very same day.

As programmers we spend multiple hours a day talking to the compiler, where we expect the same consistent, coherent results for the same code written over and over again. We look for systems even when we are connecting to other human beings. The best of your geeks are afraid of unpredictability specially the kind that has 'stupidity' written all over it.

As a manager it is your responsibility that you reduce the element of unpredictability that gets thrown in your team's way to a minimum and if there is unpredictability it is positive unpredictability that challenges them and helps them grow stronger neurons. If you cannot do that the least you can do is be open about the changes in your organization and have no secrets. Transmit information openly.

If you must move them to a different project, do you have a genuine cause for doing that? Are you explaining your thoughts and your rational to them before you move them or are you basically passing orders from the ivory towers of management?

It takes years of solid teamwork, multiple streaks of good luck and a lot of stars have to align before you become a part of a project that is awesome, that rocks and that has the potential of making a dent in the universe of a small group of people or an industry.

All it takes to ruin that is a couple of stupid random unpredictable decisions that you impose on your team without discussing things with them, without listening to them and without giving them a chance to react.

There are multiple awesome projects that might be running in your team right now. A couple of programmers are spending their night time to work on aspects of your project that might take your project to the next level. The real question is, are you going to listen or are you just going to take random decisions and move people around like pawns on a chessboard?

Choose wisely, because your choice ultimately decides the future of your team and your projects.

Back in the days at Multiplitaxion Inc, Fred tends to throw random ad-hoc work on our plates every time he sees us passing by the corridors of the office.

More often than once we find ourselves gathered in the cafeteria discussing what it is that Fred himself does.

Michael Lopp explains this rather articulately in his book, Managing Humans. He explains:

“What, exactly, do you do?”

Slack.
Jawed.
Amazement.

This question is coming from someone I trust. A trusted employee who has been working in my group at the startup for years. This guy always tells me the straight dope and now he’s asking me what I do with my day because he honestly does not know.

My first reaction to this question is the wrong one. I want to leap over the table, grab my friend by the shoulders, shake him, and yell, “While you were uselessly staring at that one bug this morning, I was keeping this organization moving, pal.” My second reaction is to take a deep breath, so I do.

This basic what-do-you-do disconnect between employees and managers is at the heart of why folks don’t trust their managers or find them to be evil.

But the real problem here isn't the fact that Fred is incapable of answering the what it is that you do here question.

The most evil of managers are not the ones who cannot answer that question. In fact, the stupidest of managers are also not the ones who do not have much work on any given day. Most developers are used to both these kinds. Add a little bit of empathy to their characters and these two kinds are not really all that dangerous after all.

In fact, they might be adding secret ingredients to your project and your organization, quietly and subtly.

These are not the kinds that typically do the most damage.

The ones who do the most damage to your project, work and your team are the ones who don't have any work and to add to that, don't have a life either.

This is the breed that goes around the office with a printout of a project plan, the breed that buzzes the development team three times a day, the breed that organizes meetings that run hours and the breed that pulls out the stupidest of ideas or features straight out of their ass and then insist that they get implemented even when no one really needs them.

So, if you are a manager, the next time you walk up to someone's desk with a project plan in your hand and ask him the status of his module for the third time in that day because you don't have any other meetings to attend, remember that while you might not have anything to do, others in your team might be busy doing some real work.

Don't have work?

The least you can do is stop inventing random work for others and get a life.

Find a video game, play Farmville, take your son out, spend some quality time with your family, go home and stop bothering your team. Consider working less, even if you think you are supposed to 'drive and manage' the team. Seriously.

We have all seen these emails. Emails from your Vice President where he wants a certain Fred to look at your project and provide “inputs”.

You know the famous architecture team story by Joel Spolsky.

That kind of inputs.

Before you know it, "consultants" with terrible blind spots who are awesome at playing the jargon game and who have zero knowhow about the domain, zero understanding of your team dynamics and zero expertise in the technical space are meddling in every decision your team is taking.

Well not exactly those consultants, but if you have been through an architecture review meeting with external consultants you know exactly what I am talking about here.

Every small change is questioned and discussed in meetings that no productive programmer would want to attend in the first place but then you suddenly find yourself in these meetings spending hours defending the most common sense driven decisions you took.

You know your car is going round and round in circles. You are not getting anywhere. The fact that you are going around in circles is common sense. You have too many drivers fighting to take control of the driving wheel.

Obviously, you are not moving ahead. Obviously, throwing in more drivers is not going to solve the problem. Obviously, you need to pick a single driver to drive your project. Obviously, you need to check his track record closely before you pick him. Obviously, you need to learn how to trust him. But then again, obviously, obvious is not so obvious, especially when it comes to big organizations that are trying to pretend to be even bigger than they really are.

If you run a team or an organization, remember that every time you get more than one driver at the wheel you run the risk of getting nowhere. So the next time you invite those external consultants to review a project that is moving just fine or fu@#k up a department that is moving along smoothly, think twice.

Here is my humble word of advice from the forefronts of software development: Pick a single capable trust worthy driver. It doesn’t matter who you pick, as long as the person is competent and trust worthy.

Then move to the back seat and let the person you picked drive without bothering him.

You may not get to your exact destination. You might get just a little closer to it. But then at least it is better than moving round and round in circles.

I wish you good luck.

Do you want to really see the worst of software that exists on the surface of planet earth? A few funny examples aside, chances are, that you are not going to find it online. If you are looking for some genuine gems of stupidity, lack of vision, bad design or just down right stupid implementations,  go look at the applications that power the intranet of some of the so called big enterprises or the fortune five thousand.

Khoi Vinh takes the famous analogy of duck typing: "If it looks like a duck, swims like a duck, and quacks like a duck, then it probably is a duck" and turns it into a rather interesting satire on enterprise software. He calls it: "If It Looks Like a Cow, Swims Like a Dolphin and Quacks Like a Duck, It Must Be Enterprise Software"

Khoi also provides his logic on why he believes enterprise software stinks even after the countless dollars that are poured into the efforts of building these applications. He explains:

This is partly because enterprise software rarely gets critiqued the way even a US$30 piece of shareware will. It doesn’t benefit from the rigor of a wide and varied base of users, many of whom will freely offer merciless feedback, goading and demanding it to be better with each new release.

Shielded away from the bright scrutiny of the consumer marketplace and beholden only to a relatively small coterie of information technology managers who are concerned primarily with stability, security and the continual justification of their jobs and staffs, enterprise software answers to few actual users.

Given that hothouse environment, it’s only natural that the result is often very strange.

Of course, most people who take the buying decisions in the enterprise world are going to have blind spots but If you are a programmer with basic ethics and self respect who happens to build software for the enterprise, the first question you need to ask yourself is this:

How do you take the same software, shred off the elements of complexity out of it, stop bitching about performance and add a touch of genuine magic, simplicity, genuinely kickass speed and interactivity to your applications.

Google Apps does it with its paid offering. They take the simple, easy to use, light weight applications designed for end users, tested by millions of live real life users and offer it to the enterprise with added features, more space and a premium price.

If you look into the approach it is rather simple and straight forward. You build for the end consumer. Then once you have enough people using it for free, you let enterprises adapt it and pay for it. You stop bitching about performance and you actually build fast applications. You focus on simplicity, ease of use, easy adaption and you build with the purest of intent.

As rework the famous book by the guys at 37Signals describes, the suits at enterprises that make the buying decisions and sign off paychecks don't wake up in morning wishing they had more slower, sloppier or complicated applications.

So if you are a developer or a technical manager, stop using the fact that you build an enterprise application as an excuse for slapping together random text boxes, drop down lists and option buttons, frameworks, building weird things and calling them enterprise applications. Continue to master the art of simplification. Even your enterprise users will love you for it. After all, working on Enterprise software is not an excuse for building software that sucks. Seriously.

You there; if you are reading this you probably have something you can teach us; something you can build or maybe a story to tell. Some insightful content, some meaningful software or a product that can change our lives in the tiniest of ways, maybe just for a couple of days.

Maybe you can make us smile. Maybe you can make us laugh. Maybe you can make us take a pause from our routine, mediocre, mundane lives and nudge us to think. Maybe you can give us a tool or a utility that you were working on last week.

The real question is, are you giving us any of that? 

If not, why?

You are afraid of failing. Aren’t you?

Actually, you are shit scared.

You already know that the 'I don't have time' is the lamest of excuses you have given yourself for years, haven't you? 'I want it to be really good before I release it' - that is a lame excuse too.

Of course you want to spend time and sign stuff you put online. Put finishing touches to it. Polish it. Make it the best you can. All you need is a little bit of time. Newsflash – you are never going to have that ‘little bit of time’.

Remember, you don’t have to be the best to have an audience. You don’t even need an audience. Just being loud, being opinionated and adding a little bit of genuine value with an intent that is pure and clean, is all we, you readers, followers, subscribers, audience (or whatever it is that you want to call us) expect from you.

Show us what you’ve got. We don’t want you to polish it for hours. We don’t want a formal website with professionally done videos surrounding it. We don’t want marketing weasels selling us crap. We don’t want impotent words or formal introductions of your product.

Show us a little bit of yourself through your product, service or whatever it is that you have to offer.

Make it Raw. Unedited. Real.

Even if it is as raw, unedited and real as the videos from Khan Academy.

Salman Kahn from Khan Academy explains this rather articulately in his video on the topic.

Normally, I would have quoted from the video, but this one is fairly inspirational and I would rather than you take the twenty minutes and see the video for yourself. 

The takeaway from all of this?

If your intent is pure and you are adding value, we will listen. And if you continue doing it long enough, consistently we might even spread the word for you.

Now go give us something meaningful, cute, smart, sexy, funny, or simple and informative.

Give us a little bit of you.

The you that moo's and the you that is purple.

I wish you good luck.