If you have been working in a development environment that is bringing you down, how long have you been there? Better yet - if you have been working with a tool that is holding you back from getting things done faster how long have you been using it? Do you complain about the environment or the tool?
So just how many people does it take to screw in that light bulb? How many people collectively complaining about the same tool or process does it take before people take notice and attempt to change or remove the problems and obstacles?
Here is what I figure:
When the collective drag produced by utilizing a process or tool is SOOO great that you end up having to work around the work arounds just to get something done, it is time to give some serious consideration to changing the way you do things or the tools you use. Do not let it fester, if you do let it fester you too are to blame for the processes/tools continued existence.
Do yourself and others a favor speak up when you see these things [bad processes/tooling], louder, ... LOUDER - make your voice heard. Help you and your fellow developers out of the RUT and put a stop to bad process/tooling. Take a stand against the idea that if it was NIH its no good. Allow your processes and tools to support light weight ideas, and have a small impacts on your day. Allow those things to assist your efforts to get things done fast and in an efficient manner without repeating your self (DRY). After all this is why coders use IDEs right? They make things easier, right? if they didn't why use them? Take the democratic path - PROTEST bad process/tooling in earnest. BE THE CATALYST FOR CHANGE.
Wednesday, May 2, 2007
Get your "Code Goggles" On
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.
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:
Posts (Atom)
