In one of my earlier post; I talked about the infinite loop of failure and the infinite loop of non constructive criticism. Joel Spolsky in his post on Figuring-out-what-your-company-is-all-about; how he avoids these loops using a simple diagram.

In the post Joel describes how he started Fog Creek as a company that programmers would absolutely love to be at. He also has a series of posts; like this one for instance; which shows the amount of time; thought and effort that Fogcreek spends behind their employees and their happiness.

If you work for most body shops or software development firms out there; or you are a manager who worries a lot about optimum utilization of human resources; chances are that you; dear reader consider happy programmers dangerous.

Erik Forsberg explains the idea as he narrates his very own personal experience as a developer conference:

Lot's of people from different tech companies in Linkoping. Someone said that Scrum kept the programmers happy which would produce better code. That's probably true. Here comes the fun part - another person in the audience were worried that happy programmers would code things they thought were fun instead of the things they were supposed to do.

Hmm.. yeah, right. That's the way it works. Or maybe not! I'd say that the risk is much bigger that bored programmers spend their time working at things they shouldn't do.

I would really like to know where this person works, so I can avoid working there.

The whole model of hiring cheap programmer; squeezing them to their limits; and micro-managing them to get results leaves most companies out there hanging in the realms of safe mediocrity.

The folks at 37Signals take the concept of happiness and bake it right into their Ruby-On-Rails framework to make developers around the world 'happy'. David Heinemeier explains this concept while giving an interview at eweek. He explains:

The author of Ruby, Yukihiro Matsumoto, tells us that he set out to create a language that would "make programmers happy." Rails attempts to run with that noble and profound goal and bring it to the world of Web application development. Were optimizing for humans first, compilers and the frameworks second. Its been a constant search for how we could make the development process more in tune with what makes programmers happy.

Kathy Sierra dissects the whole concept of happiness and talks about spreading it to all levels within the organization; even in areas which are connected to programming or seriously technical. She explains:

Understanding the connection between happy users and happy developers (or happy anything-supporting-users) is a big step forward.

The HR folks have cared about happy employees for a long time, but the notion of "happy programmers" was always more about benefits, perks, or pay... now a lot more people are starting to care--and talk--about things like programming language, API, framework, methodology, etc.

The things that keep you in a flow state.

If you take all of what his post has talked about so far and compare it with what happens in most organizations out there; what you might realize is that; most organizations out there; actually work hard at building technology; processes; business models; marketing techniques; sales strategies; when all you need to do if you are an entrepreneur is:

1. Hire the best programmers; managers; marketing guys; or for that matter; any other kind that you recruit.
2. Get out of their way - stop micro-managing and interfering in their job. 
3. Figure out innovative ways to keep them happy.

If you can do just these three things and do them well; chances are; that you might have a very successful and even a very profitable organization in the long run. After all; happy programmers build remarkable products; and even more remarkable organizations. Happy marketers often sell better without lies.

Now; go and rethink your policies; your compensations; your projects; your technology and your processes. Are they fundamentally built to make the best of your employees feel 'connected' to your organization? Are they designed to spread happiness? If you answered with a 'no' - get rid of them - and build new ones which are designed keeping the fundamental idea of happiness in mind.

I wish you good luck.

This post is about all about doing some serious soul searching and reflecting on your professional self.

If you have spent more than a couple of years in the business of building software you probably know by now that designations mean nothing. Anyone who has read a couple of books on neuroscience or management will tell you that the first rule of self improvement is that you stop trying to improve on your weaknesses and you utilize your core competence to make them stronger and more effective.

Step one to this process of-course is knowing what your core competencies are; and in a world where we excessively turn to business cards to pass our judgments on human beings; finding out your core competencies or what you 'really' do; is hard. Michael Lopp describes this rather articulately in his book - Managing Humans. He explains:

What do you do? Seriously, on your business card there is a title. Say it out loud.

1. "Senior Manager of Engineering"
2. "Industrial Data Analyst"
3. "Human Factors Specialist"

Is that what you actually do? Try this: think about the last four hours of your job and give yourself a title. Mine would be "Senior Meeting Wrangler" or perhaps "Guy Who Listens." Last week it would’ve been "Whiteboard Operator."

When you graduated from college, when you got your first job in your chosen profession, did you think you’d be doing this? No. Whatever you thought you'd be doing when you looked forward to being an "Associate Software Engineer" is not what you ended up doing.

You'd think this title dissonance issue would be a problem. You'd think that the fact that what you thought you'd be doing has nothing to do with what you do would turn into angst, but it turns out, as long as everyone is clear what your secret title is . . . we're cool.

The basic idea; dear reader; like all good ideas; is a rather simple one. Pause every once in a while as you work and question what you are 'actually' doing. Compare what you are 'actually' doing with what you business card reads and you might realize that you have more than one; what Michael calls --- secret titles.

The more you do this the more likely you are to find more of your implicit or secret titles. Club these together and you might be able to figure out a general direction of your core competencies. What is really scary about this process however; is that when you do this; chances are really high that you might actually discover that your core competencies evolve over time and they often have nothing to do with what your 'official' business card reads.

When this happens most folks panic.

After all; when your business card reads 'development lead' and you suddenly have a realization that you are just a 'guy who listens' it is easy to shift to the shit-I-am-going-to-get-fired mode and focus more on your development capabilities rather than your listening capabilities. If that is what you have done in the past; I have two words for what you may have done:

Big mistake.

If you; dear reader; were to wake up one fine morning; and you were to discover that morning that your secret title has developed a strong tangent with your what your business card reads; I have one advice for you:

Don't Panic.

Sure; spend a little bit of time doing what your business card reads; but instead of trying to force yourself to move back to your 'official' designation; try sticking around with your secret title and see if you can get better on that front. Then as you get better at doing what-ever-it-is that your neurons are naturally meant to be doing give out gentle signals of your secret title to folks around you.

Chances are; that people around you might accept you for what you were naturally meant to be and might actually like you for it.

Remember; the sooner you find out your secret titles and their variance from your official designation; and the sooner everyone around you knows and accepts this variance the happier you will be as a professional.

I wish you good luck

If you are in the business of building software; every now and then; you will find yourself surrounded with moments when the sky-is-falling. Every now-and-then; you might also come across seriously kick-ass engineers who emerge as super heroes and save the day.

It is rather easy to identify and reward these super heroes of your organization and shower them with pats on their backs; salary hikes and promotions. What is hard; dear reader; is identifying and recognizing the silent programmers; who avoid the sky-is-falling moments or as Michael Lopp in his book; Managing Humans calls Malcolm events. He explains:

Avoiding Malcolm events is completely unsatisfying and here’s why: you know what failure sounds like, but success is silent. It’s when the release goes well. It’s when you don’t have to release an immediate update to your major release. Avoiding a Malcolm event is when you managed to predict the future and no one is going to believe you when you tell them what you did because nothing happened.

Management is the care and feeding of the invisible. You’re doing your best when it appears the least is happening. I love the thrill of the last month of a release as much as the next guy, but I suspect the reason we’re yelling at each other, working weekends, and feeling the depressing weight of compromise is because we’re surrounded by Malcolm events.

Nassim Nicholas Taleb in his  famous book - The Black Swan - explains the exact same problem of identifying the true silent heroes and rewarding them much more dramatically through his excellent story telling and though experiment:

Assume that a legislator with courage, influence, intellect, vision, and perseverance manages to enact a law that goes into universal effect and employment on September 10, 2001; it imposes the continuously locked bulletproof doors in every cockpit (at high costs to the struggling airlines)— just in case terrorists decide to use planes to attack the World Trade Center in New York City.

I know this is lunacy, but it is just a thought experiment (I am aware that there may be no such thing as a legislator with intellect, courage, vision, and perseverance; this is the point of the thought experiment). The legislation is not a popular measure among the airline personnel, as it complicates their lives. But it would certainly have prevented 9/11.

The person who imposed locks on cockpit doors gets no statues in public squares, not so much as a quick mention of his contribution in his obituary. "Joe Smith, who helped avoid the disaster of 9/11, died of complications of liver disease."

Seeing how superfluous his measure was, and how it squandered resources, the public, with great help from airline pilots, might well boot him out of office. Vox clamantis in deserto. He will retire depressed, with a great sense of failure. He will die with the impression of having done nothing useful. I wish I could go attend his funeral, but, reader, I can't find him.

And yet, recognition can be quite a pump. Believe me, even those who genuinely claim that they do not believe in recognition, and that they separate labor from the fruits of labor, actually get a serotonin kick from it. See how the silent hero is rewarded: even his own hormonal system will conspire to offer no reward.

As software managers; we tend to look for people who emerge out of nowhere; and turn complicated defeats into victory and save the day. We glorify them and shower them with praise, salary hikes and promotions.

What we often fail to take a note of; dear reader; is the silent catalyst who gracefully builds synergy in the team; the brilliant engineer who does excellent estimations; the manager who sedates the monkeys; the technical lead who pushes the idea of keeping the team size small; the kick-ass programmer who quietly fixes the first broken window or the young recruit who changes the culture of the organization without making a lot of noise about it.

It is tragic but true; when it comes to the world of software development; a smooth sailing successful project without any panic moments does not seem to grab management attention. Add elements of panic; late night programming; working weekends or a rescue operation of an almost failed project and suddenly you have everyone giving you all the attention you want.

An excellent oracle database administrator who worked at one of our client; who for the purposes of this post; we shall refer to as Multiplitaxion Inc; received very little recognition for all his efforts.

During a casual conversation I asked him what was the most heroic moment of his life. He smiled at me and gave a reply which was somewhere on the these lines: 'none. maybe I should have taken our website database offline one or twice and then everyone in the organization would know me as a person who saved the day by bringing it back up. Maybe I should do that every five or six months and then I would be really famous individual in this organization'.

As a manager; the next time you come across a sky-is-falling event; a hero emerges out of nowhere and saves the day; sure; reward the hero; but also do a constructive analysis of why the sky-started-falling in the first place. Look hard; and you might find surprisingly new reasons and causes for the sky-falling.

As far as your smooth sailing projects are concerned; where Jack is sitting in the little corner and pushing the culture of writing clean code that takes a little bit more time; before you treat him like the legislator from Taleb's Black Swan thought experiment; do some serious soul searching and try to estimate the number of panic moments Jack is saving your organization from.

Next time you see Jack; try giving him recognition and reward for what he is avoiding with his talent and hard hard work.

Recognize your true silent heroes; give them  the recognition for their work; and you; dear reader; would have taken your first step to genuine management.

I wish you good luck.

Fred is struggling to answer the basic Fizz Buzz questions. He is answering them averagely well and yet something about both; his handshake and his personality seems nervous and weak.

Half an hour into the interview Fred seems desperate. He is fumbling; lying and pushing hard to get to the right answer; his desperation to get selected clearly showing in every question he answers. Half way thought the interview I ask him a question which changes the course of the entire interview:

'Tell me three things that you find completely unacceptable in an organization. Three things or attributes that if we had; they would make you reject a job offer; even if we were to give you one'

Fred looks at me like I just dropped a dead rat on the table. He thinks hard; and yet he cannot seem to think of one thing that would make an organization not worth joining.

What Fred; like most programmers who cannot program; was doing dear reader; was applying for a job where the only criteria that would decide if he joins us; was the criteria of us selecting him. 

Put simply; he would join any organization that offered him a higher salary; and had an interview process; he could somehow manage to clear.

Most veteran builders; unlike Fred; realize that interviews are not a phenomenon where a interviewer sits on the other side of the table and asks difficult questions which have to be answered --- 'somehow'.

Most veteran builders around the world that I have worked with; and in particular interviewed; realize that the act of applying for a job; is almost like making friends or for that matter; even dating; where both parties involved have to mutually decide if a relationship would work out in the long run.

If you happen to take interviews dear reader; may I suggest; that besides asking technical questions; you also spend a few minutes driving the discussion towards finding out the level of interest the candidate genuinely has towards your organization:

1. What does he know about your organization?
2. How much time has he spent on your website and what does he like or not like about your website?
3. How many valid and interesting questions does he have about your organization?
4. How many valid and interesting question does he have about the work he would be doing?
5. Is he even interested in knowing or finding out about the culture of your organization and how he fits into  the whole picture?

And most importantly; does the candidate have preferences; opinions and a spine strong enough to understand; that of the many programming jobs out there not every job is meant to be 'his' dream job; or even the one that he accepts.

When hiring candidates; don't just look for people who meet your criteria. Hire candidates who themselves have strong criteria; other than salary; that they expect the companies they join; to meet.

Hire candidates who clear your interview with confidence and then have the confidence to turn the tables around and interview your organization.

Hire folks who understand that of the many job offers that they can get not every job is worth joining. Hire folks who take time to know your organization; then actively interview and hand pick your organization; much like your organization hand picks them.

I wish you good luck.

I'm a firm believer of building close allied relationships with every single client that you work with. Having said that; the art of building allied relationships in the war front is a tricky affair. Finding a true ally you are willing to trust and bet your professional life on; is even trickier.

At Multiplitaxion Inc; a client of ours who was into selling multi-functional devices; it was not an uncommon sight to see countless engineers scramble for cover every time a new client showed up.

The reason: every single engineer in the premise knew that the client could ask for any product feature and chances were; that the marketing folks would go out there and either say that the device driver we were building already supported the feature or it was a part of next release that would be out in the next fifteen days.

Then; armies of consultants would be hired to get things to move faster. Multiplitaxion Inc; built their projects based on lies; but more than the lies; what really came back to bite us was the fact that Multiplitaxion Inc saw the client as external entity who descended from the heavens above; told the development team what to do; and then we; like robots; pretty much went out there and did what they told us to do.

Even today; I see countless engineers; both young and veteran ones; take the whole 'the-word-of-the-client' way too seriously. Every month I interview countless engineers; who use insanely stupid and complex frameworks to solve insanely simple problems. Ask them why they picked the framework and chances are; that they will tell you that their client wanted them to use the framework.

One example of taking the client's word way too seriously; came in this blog as a comment on my post about getting rid of your systems and not logging every single requirement your client has.

For those of you know did not read the post; the one line simplified version of the post; is that you need to get rid of as many systems as you can and sensibly possible and get your developers talking to each other.

Harvey Kandola offers a rather thought provoking comment on the very idea of getting rid of systems.

He brings up a valid point:

Good post, but not convinced the advice from 37Signals is applicable. What would you say to your clients who want to log and track each Request? Would you tell them that "we do not log / have systems". I think not.

In the end, every organization is different, and needs to look at things from it's own perspective. Team dynamics are a major factor in how people adopt and use systems.

I've myself gone ahead and suggested in the past that every organization is different; so yes; there is validity in the point Harvey makes. Having said that Harvey's comment also brings up a rather interesting concept of asking why and checking on the basic premise of the comment.

Humor me; dear reader; and read on; even if you might disagree. If nothing else; I might end up giving you some food for thought.

So; assuming that you have moved to an truly agile (without a capital 'A') environment where you have a successful product being used by a couple of clients; and you totally believe that logging every single requirement in a 'system' is not the way to approach software development. Smooth, free flowing, verbal communication has done the trick for you and has got you more than one successful implementation.

It is then that a client shows up and tells you that they want to track and log each request. What is it that we as software development shops; entrepreneur; and even developers; find so criminally wrong about telling the client that - we do not log or have a system for that.

Remember; that each client is different; and your relationship with your client; is an allied relationship or a marriage of two organizations to get something constructive done; where most typically your clients are supposed to know what needs to be get done and you are supposed to know how to get it done.

It is a mutual relationship; based on equality and exchange of value with your talent and services.

Go down the path of putting the client on a raised pedestal as a superior species who is always right; and you will soon learn that the path does not have an end. Every now and then; every successful business out there pulls the plug and learns the art of saying 'no'.

Success Factors CEO; Lars Dalgaard pulls the plug and draws the line; at the idea of being nice. He explains:

I was in Boston once and one of our customers was very nasty to our employees. I made it extremely clear to him right then and there that if he continued that; that means we close the deal. We like closing deals.

37Signals does it by starting by saying no:

Every new feature request that comes to us — or from us — meets a no. We listen but don't act. The initial response is "not now." If a request for a feature keeps coming back, that's when we know it's time to take a deeper look. Then, and only then, do we start considering the feature for real.

And what do you say to people who complain when you won't adopt their feature idea? Remind them why they like the app in the first place. "You like it because we say no. You like it because it doesn't do 100 other things. You like it because it doesn't try to please everyone all the time."

We at have work; in my current organization; have said 'no' to a process or a methodology that a client wanted us to follow more than once. 

There are millions of clients on this planet; not every client out there is 'your' client. If your organization; or you genuinely believe in an approach or process; have the courage to stand by it; and say no --- even if it means losing a client.

Now; go find your own answers; figure out what works for you and what does not.

The next time; you have a client; who wants every error logged in a system; and 'if' your organization genuinely believes doing so is a waste of time; try saying 'no' for a change. There is a high possibility that you client might thank you for it in the long run; and if you lose them; they were probably not 'your' client in the first place. Just in case; if that happens; go look for another client.

There are plenty out there and if you look hard enough you might find clients who you can form strong allied relationships with.

I wish you good luck.

As programmers we love the idea jumping up to build a new system at every given opportunity.

At Multiplitaxion Inc; I see a few young and budding managers attend a conference for a project management tool by a software development giant. They come back hugely serious; excited and amazed; much like babies who have found something new to explore and play with.

When I see them bubbling with excitement --- I cringe.

As programmers we have a tendency to get hugely excited about building something or putting a completely new system in place. Walk up to a programmer and tell him that you are having problems with people not applying for leaves in advance and chances are; he will tell you; you need a leave tracking system in place.

Tell a developer that you are trying to start a small library to encourage people to read books and chances are that he will tell you how badly you need a library tracking system.

To be honest; it is not just the excitement of building something new that gets the programmer within us excited. As geeks we love to also connect using familiar systems. The problem with having a whole lot of systems in your organization however; is that if you get make too many systems available to your builders and geeks; chances are that they will never connect and communicate at a human level.

Folks at 37Signals have interesting advice to give to people who are looking for a 'system' to track the feature requests. In their classic book; getting real; they explain why you should just forget your feature requests instead of trying to log them in a formal system:

Of course we don't fault people for making requests. We encourage it and we want to hear what they have to say. Most everything we add to our products starts out as a customer request. But, as we mentioned before, your first response should be a no. So what do you do with all these requests that pour in? Where do you store them? How do you manage them? You don't. Just read them and then throw them away.

Yup, read them, throw them away, and forget them. It sounds blasphemous but the ones that are important will keep bubbling up anyway. Those are the only ones you need to remember. Those are the truly essential ones.

Don't worry about tracking and saving each request that comes in. Let your customers be your memory. If it's really worth remembering, they'll remind you until you can't forget.

James Shore and Shane Warden come heavily on the simple idea of a bug tracking system in their book - the art of agile development. They explain:

Unless you're writing software by and for yourself, you will have to deal with at least one other person somewhere during the process. A grudging détente is not enough; you need to work together effectively. This means forming solid working relationships that are built on honesty, trust, cooperation, openness, and mutual respect.

You can’t force people to do this. The best your agile method can do is support these sorts of relationships. For example, one way to engender healthy interaction is to have people sit together and collaborate in pursuit of common goals.

It’s far easier, unfortunately, to craft your method in a way that discourages healthy relationships. An extreme example (sadly, one that actually happens) is forcing all developer communication with stakeholders to go through business analysts. As another example, a sure way to damage programmer / tester relationships is to require them to communicate solely through the bug-tracking system.

Ideally, your team will fix bugs as soon as they find them, before declaring a story "done done." Nobody’s perfect, though, and you will miss some bugs. Schedule these bugs with story cards, such as "Fix multiple-user editing bug." Schedule them as soon as possible to keep your code clean and reduce your need for bug-tracking software.

The point here; dear reader; is not to throw away all your systems of organization and turn into wild programmers who write random code. The point in fact; is all about is about letting go of access baggage and getting your basics facts right.

If you genuinely want your programmers to connect and communicate; first get rid of any excess 'systems' that you can possibly get rid of. Of course there will be some - like a version control system or the IDE in which you develop - that you cannot and should not get rid of; but reflect on and question the existence of every other system that you can see running in your organization.

Once you have done that; give your programmers opportunities to genuinely connected to each other verbally; their programming skills and their communication skills being the only two options left open to them and chances are; that they will use them both to the best of their abilities.

With no CYA systems in place and with free flow of information you will feel every ripple in your organizational pond and believe me dear reader; you will not need a fancy project management tool or an expensive bug tracker to find out what is going on. Honest.

At work; as a labs project; Kaushik Das; who is one of our seriously talented developers has been working on studying the SQL Server Schema --- just for the fun of it. To turn this learning into practical implementation instead of just theory; we decided; to build a web based administration console which users can use manage SQL server instances that they have access to using a web based administration console. This; is how eFORCE SQL DB Administrator was born.

Put simply; the first version of SQLDBAdmin by Kaushik; in it's scope and basic philosophy is pretty much like any other web based administration console for SQL server; one common example being - Microsoft Web Data Administrator.

We do realize that this problem has been solved multiple times before; and we also realize that as of today SQL DB Admin happens to be a 'me too' product; but what we believe makes SQL DB Admin worth giving a try are the following facts:

1. Looks and feels just like the SQL Server 2005 Database Management Studio - so there is very little learning-through-fiddling that needs to be done. 
2. It is free and open source; which means you can not just download it but actually modify the source code for your implementations if needed.
3. We will be working really hard to add new features to SQL DB Admin which might make it easy to do day-to-day administration tasks. Some examples include: scheduling a database backup, compressing a database, re-indexing a table. etc.

As of today you can grab a copy of the SQL DB Admin code base by visiting its codeplex site.

As a matter of fact; this is one of those projects that we just started for 'fun' and now that we have something that works; we are seriously looking at adding new features that give you; dear reader; reasons to download it and use it while comparing it with multiple other web based SQL server administrators that are out there.

If you; dear reader; have a task or a feature in mind that you or your database-administrators do regularly on SQL server administration front and you would like to perform the same tasks through a web based console; let us know about the feature and we will try out best to squeeze those features into the road map for SQL DB Administrator.

In the meantime; if you want to grab a copy of the latest code base and start using it in it's current beta stage; you can get a copy from the SQL DB Admin codeplex website.

We genuinely and sincerely hope that this product; makes your life; as a database administrator; developer or anyone who has to manage multiple remote databases behind the firewall; just a little more easier. We will continue to add new features to SQL DB administrator and then blog about those features when we add them into the product.

Wish us luck.

More open source goodness coming soon.

Stay tuned.

Throughout my career; if there is one thing I have seen a lot in the software development world; it is; programmers who cannot program pretending and advertising that they are the alpha geeks of the millennium.

When I was a young and budding programmer; brimming with dreams and confidence; I walked the world of software development assuming only three kinds of people existed in the world of software development:

1. Alpha-geeks who were kick-ass programmers making huge dents in the universe with their code.
2. Passionate programmers who knew how much they sucked and were on the life-long path of learning how to become kick-ass programmers.
3. Programmers who could not program but were busy pretending they were alpha-geeks.

Then; years later; while consulting for a client; who for the purposes of this post; we shall refer to as Multiplitaxion Inc; I met Jack; and I realized; that I was; dear reader; so very wrong; in my assumptions about people who exist in the software development world.

Jack was not a programmer.

In fact; he had done his major in philosophy.

When I first met Jack; the question that bothered me was simple: how the f@#k did Jack manage to join a software development firm?

In my first few weeks of working with him; I found my answer in the way Jack approached work; people and life. The guy was an interesting storyteller. He was almost a catalyst. To add to that; he was what I then started referring to as a --- 'contributor'.

During the first month of the project; Jack and spent a huge amount of time with me and the five person development team. He would read the requirements end to end and then talk about those requirements; so that we would not have to read them; he had valid questions on the flows we built; he engaged himself in usability testing; he tested the screens that we rolled out and pointed out valid bugs the official testing team was often not able to point out.

Our true surprise however; came when someone from the development team showed Jack how to write Ant scripts and we discovered that he was surprisingly good at it. Within a few days; we also had a build manager; taking up tasks which no developer wanted to take up.

Jack; dear reader;  was not writing a single line of code; but in a matter of three months; he had made himself very difficult to replace.

Steve Yegge brushes against the concept of a contributor in his post on a completely different topic; he explains:

Let's face it: there are a lot of professional programmers out there who realize they're not very good at it, and they still find ways to contribute.

If you're suddenly feeling out of your depth, and everyone appears to be running circles around you, what are your options? Well, you might discover you're good at project management, or people management, or UI design, or technical writing, or system administration, any number of other important things that "programmers" aren't necessarily any good at.

You'll start filling those niches (because there's always more work to do), and as soon as you find something you're good at, you'll probably migrate towards doing it full-time.

If you read between the lines; Steve's post might actually suggest that finding other ways to contribute when you discover that you are not a programmer; is not the best of things. You can actually hear a slight tone of sarcasm between the lines if you were to read them carefully. A few years ago; I would probably have agreed; but my experience with Jack; and a couple of other contributors I worked with after Jack; changed my opinion of this topic all together.

Yes; we don't need millions of non-programming contributors; but till date; I hold the opinion; that if you are a young and budding programmer; struggling with programming; not loving it; but you still feel passionately about being connected to the world of software development; you are much better off trying to morph into a contributor who contributes a host of things towards making the project a success and is a 'fun' guy to have on the project.

We do need a select few genuinely passionate 'contributors' around; much like we need good passionate programmers and at times; if you are genuinely passionate; we might not even care if you can write any code in the first place.

So stop trying to pretend you are the best programmer around; stop trying to climb in pecking order of your organization and desperately get promoted to the position of a manager; stop being a whiner; or a 501 programmer.

Find your niche and start making genuine contributions.

I wish you good luck.