|Pathologically Eclectic Rubbish Lister|
Hey there peaceful friendly monks,
I need a quiet haven after all the unpleasantness here at work. Here's my story:
At work we are having this ongoing rift between different groups of coders - I'd group us into two categories:
1) If it ain't broke don't fix it
. We code three different databases, all of which share minimal (if any) code. It was then suggested by a manager-type that we explore ways we could share more of our code since the functions of the databases are very similar. We thought we should start by all using the same routine to connect to the databases. easy enough, right? uh, no.
Some of the coders say that they are fine with doing this. But their actions say otherwise. They just want to use the current code.
Other coders have grown very resistant to even the idea of change. They don't see why the code should change to something else. They have this mindset that nothing will ever change, and that making the code more abstract (ie. separating out the config from the Perl) is useless to them.
Anyway - here's my question(s) -
I know we all face this challenge of not reinventing the wheel. Have you managed to get your coworkers to share their code more - from using libraries to setting standards. How do you get the word out about new code you've written? How do you get it so that everyone doesn't just rewrite the code in the style that they prefer? I know that I have done that myself . I was thinking that if our group had more shared coding standards, (and more documentation), then maybe I would have used the already existing database connection code.
But everything is done in this hacked, do-it-my-way style. Also, do you have any advice for me on how to convince coworkers that sometimes change is ok?thanks rachel