Thoughts On Intellectual Honesty And Personal Ambitions

1 Comment »Written on October 4th, 2009 by
Categories: Opinions, Rants, work/career

One of my favorite topics discussed in the classic Code Complete book (simply a must-read for every developer) is that of Intellectual Honesty. It basically means being honest about what you know, what you don't know, what you can do and what you can't do. It also means that you need to be able to give credit where credit is due, and that you as a developer need to be able to accept solutions to problems no matter where they came from, even if it wasn't your idea or if the idea/solution comes from someone you might not always agree with.

I've always thought that Intellectual Honesty is a very important trait that every developer needs to have. I also believe that it is too frequently missing in this business. Some people just want (or need) to be right all the time, even if they are wrong. In software development, it's generally in everyone's best interest to go with the best possible solution to a given problem, while still keeping all relevant constraints in account. Some developers have a genuine interest in the architecture that is used and how things should be done. That is obviously a good thing and i wish there were more developers like that.

I'm in a position where i have a lot of influence on architectural decisions and how we should develop our code. But i've never wanted to be the only one who had to make these decisions, nor do i want people to just go ahead with every idea that i have. I want people to get involved with these things. I want feedback. I want to hear ideas from other people that are better than my own. It's better for everyone if multiple people are involved in such discussions and decisions. Get a couple of people together, discuss things, go over the options and eventually pick the best proposed solution no matter who came up with it. That's always been my approach and it always will be. And i truly believe that it's a healthy approach for everyone involved.

But there are always people who either want to be the only one who gets to decide these things, without input from others, or are generally unhappy in their job if they believe their ideas aren't being considered.

My question to these people is: why? Why does it matter if another person's solution is chosen? Why would you need to be frustrated or disgruntled if your solution wasn't chosen? If you're working for a company where your ideas aren't even considered then sure, you have every right to be frustrated or disgruntled (and i should know, because i've worked in such a place in the past). But if you're working for a company where you know full well that everyone's ideas are considered, then you really have no reason at all to complain if your solution wasn't accepted.

Unless of course, you are more concerned about your personal ambitions instead of the actual results. If all you care about is your status, position or whatever you want to call it, then you really are in the wrong business. Sure, there are companies where you can make quite a career out of such an approach, but it's just not healthy. Not for you personally, nor for your employer, nor for your customers. It doesn't help anyone but yourself, and that sure as hell won't last forever.

Be honest, at least to yourself and preferably to the people you work with as well. If your ideas don't make it, then you might need to question your approach (and for some people specifically: your tactics), your real motivations, or perhaps even your skill level. Again: be honest about what you can do, what you can't do, what you know and what you don't know. And learn how to work with other people, instead of simply trying to get ahead of them.

I'd like to end this post with a quote from Dale Carnegie:

Any fool can defend his or her mistakes, and most fools do.
  • http://www.basissap.com martin english

    I work in a relatively large organisation, so I can get feedback about design decisions I make or that I’ve inherited, from people much more experienced than me from outside my project team(s). Depending on our place in the project, there is sometimes very limited scope to vary from the ‘party line’ on these.

    However, when I do get the opportunity to influence design decisions, my usual problem is getting any sort of feedback from the rest of the Project team about these sorts of things. I see their input as necessary, because they have a much closer view of the users requirements, and as you imply above, the more ideas the better.