Calendar Pictures Open-source contributions Really old pages DWright.org

Thu, 25 Sep 2003

But I already said that!!!

I'm finding that a lot of the ideas that I'm expressing at work are being dismissed only to come up later in the mouths of other people. I think part of the problem I have is that I'm so concerned about learning as much as I can from the people around me, that I've implicitly come to put greater value on the opinions of my peers than on my own opinions. Consequently, I'm finding myself backing down way too quickly when I should be sticking to my guns.

I've had plenty of hard knocks in life that have taught me the dangers of being over-confident in myself. I believe it might be the case that I am over-compensating. Or perhaps self-confidence is something which should be variable depending on who you are dealing with.

I'm also coming to a revelation about programming methodologies. They don't work. The struggle for the ultimate, most efficient programming methodology is ultimately fruitless. There are far too many variables and not nearly enough constants. Once you lock yourself into one way of programming, you have doomed yourself into a downward spiral of bad programming. Things that effect this:

• Morale - There are some projects that we are really hyped about, and some that we could care less about. These can not both be handled the same way.
• Size - You can use the same methodology for a one week project as you would for a one year project, but most likely the methodology you have chosen isn't the best fit for either.
• Mood - When I'm happy or not so happy, I program differently.
• Project Target - The destination of the deliverable has a dramatic influence on how it is written! I can't stress this enough. Often I will bring this up and people will say "Oh, of course, I know that". No, you don't! The monsters which you created in school do not prepare you to create the monsters that you will create in real life. In fact, the monsters you created at company y, have only slightly prepared you for company x (Note: These examples are not directed towards anybody in particular, if this sounds like you, its only because this applies to about 90% of the programming work force out there). How the project is delivered also affects the way it is developed as well. I'll avoid giving examples because I don't want to inadvertently restrain the scope of the bigger picture here.
• Social Hierarchy - Perhaps also known as the pecking order. Programmers are typically a-social creatures, except with other programmers. But within programming circles, there is a massive amount of fulfillment of the otherwise starved human need for validation. The extent to which this is happening on any given day follows some sort of wave pattern and affects how or what we want to program. This is becoming an important beast for me to understand, I will likely expand on this at some point in the future.

What is my conclusion? There is no black and white, even something that might otherwise be thought to be as cut and dry as programming. People leak into everything, and they bring those people things with them. The only truth is that if you thump your chest too hard and claim to be correct, you will ultimately prove to be wrong.

Oh.. and if you don't get this, it doesn't necessarily mean I'm wrong, it just might mean that you don't get it.
posted at: 12:43 | permanent link to this entry | Comments: