Something has come to my attention recently and I think it was partially triggered by re-reading my previous post, why is it when people notice that the masses are unhappy with a direction or decision that they fight and kick and scream all the way through a change to make it better? Better yet - how is it that some people can not see the Code Smells that exist in a given code base.
I have now been working here at Big Co. for just over a year and have been quite astounded by the resistance to change within the IT organization. I have been equally astounded by the inability to bow down in the face of overwhelming opposition to an idea. In general I have my opinions about things. Lord knows I have my opinions - but when I am questioned on them and allowed to say my peace and the opposing side is allowed to say their peace I am comfortable then that all cards are on the table and the decision can be hashed out. I am also more likely at that point to allow my self to be trumped with a better or equally good idea. I think that this is a major part of a good give and take in life - let alone in the software development world. I also think that it is a good idea to be able to 'Let your Baby Go' and allow different ideas to take a seat and get some legs. To resist other peoples ideas or to resist the change that other people bring is bad practice and fails to value the things that a different perspective may bring.
Think of the ways that this particular resistance to change can manifest and you'll see what I mean:
1) The "CODE" Monger
This is the person who clings so tightly to the code that they developed that they will not allow anyone else to go in and make modifications/refactoring because the way they did it is SOOOO awesome that no one else could ever top it. GOOD GOD People, when you work for someone else your code is NOT your code - it is the companies code and other people by the very nature of a development organization will have to change and modify things you write. Just let it go.
2) I "Must" Be Right
Existing processes developed by other people in Big Co. start to take on water and look stale but the original 'designer' of the process refuses to modify or allow to be modified the original basis for the decision.
Both of these things fail to see the value in the people that work with you. Working with people like the above fails to acknowledge that other people have ideas too and that those ideas may have merit and they may not. In the end all being like the above does is diminish the Big Co. team as a whole because you have a small number of voices with little consensus driving the way things are being done. Actions like the above sew discontent and make people feel under valued, they are also very poisonous to the organization as a whole. Lets wake up, take the goggles off and take a good CLEAR look at what were doing to avoid being "That Co-worker" and have good clear conversation about where we want to go and why. Then lets go there together.
Subscribe to:
Post Comments (Atom)
3 comments:
You are right on the money; I am faced with that exact problem everyday, and frankly, it gets very old very quick.
Just because the idea is not yours does not mean it is bad. Don't dismiss something you don't understand, or think is too complex without trying to recognize the benefit.
Yeah - I just got completely fed up talking about it yesterday. I personally look at this as being some what of a maturity issue, i.e. are you mature enough to recognize that you really are not all that and the chips? Everyone has SOMETHING to add some smaller and some larger then others.
People that don't let you touch or modify their code are that way for one of 2 reasons:
1. They think you are too dumb to mess with their code so they don't trust you.
2. They think their code and ideas are perfect and should not be tampered with.
Either way, this poisonous type of developer needs to be taken out back and shot or just work on one person projects where they are the only developer.
Just my two cents...
Post a Comment