The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Information sharing in the workplace

Some of my major goals are to improve and learn about anything that helps me do my job. The only problem is that not everyone I work with shares this mentality. I have learned tons of useful bits of information that could make drastic differences in the workplace, but how do I share it with my coworkers and the lead developer?

I believe that the general consensus for many development issues is often wrong, and fighting groupthink is difficult. Without my coworkers having prior experience and knowledge of an issue, getting them to agree is especially difficult when most others feel the same. The input from the lead developer usually isn't helpful, either. I am ready and willing to discuss issues to make my point known, but it's difficult to have them give me the time of day. Let me give you an example to show you what sort of mentality they have: I developed a class that will help us debug our applications more easily over the web. I shared it with a coworker and he said, "That's neat, but I probably won't use it"! The whole point of the class was to add uniform and controllable debugging mechanisms to our code -- I don't think explaining that would have persuaded him to use the debugging class.

I don't want to be bossy; I only want to help, and I want to do so in a way that doesn't make them resent me. I do not want to be the guy, who, when he speaks, everyone else thinks, "Oh God, not him again. When will he shut up?" Of course, this could be one of those cases where I should shut up because I do not know what I'm talking about, but I've learned from credible sources, experienced good practice first hand, and have consulted with other professionals who have all agreed with me. Even if I am wrong, though, I believe having them listen and proving me wrong is very important, it would remove doubt and resentment on my behalf.

Please help! How do I influence the others I work with without resentment? Should I even care? I mean, the job will still get done, right? What should I do?
sili Send private email
Sunday, May 15, 2005
If the company wants to change it will.

If you try and change it, you'll end up getting stress or fired or both.

There are huge numbers of environments like this across the world. The people in them are often "lifers" -- they don't have transferrable skills, so they can't leave. They don't like change very much, so if you look like change, they won't like you very much either.

They're often not broadly educated in CompSci areas -- so a lot of the work that gets done gets done by religious beliefs; Example -- making you put "==true" in all your C++ tests on the basis that the compiler "needs it". Hence "if ((counter==1)==true)"

The religious beliefs are more important that truth. Things are described as "hard". Threading, exceptions, inheritence... even things like "sscanf()"... they're often "banned", because someone once did something they didn't understand with them and it all went wrong and now that area of the world is fenced off and full of dragons.

Rather than read a book on concurrency, they'll go to enourmous efforts to never use it... People in those environments do not want to learn. They do not want to read technical books... They do not want to *change*.

Your example of small, tidy tools that no-one even wants to consider using is the perfect indicator. In some workplaces, people would test it, smile and then ask you to roll it out and make it available.

In others they won't use it because it's new and they don't like new.

All I can offer is that in my experience, those unlearning environments can fight against change with ferocity that would put the Catholic church to shame.

You can either leave and go looking for people who do want to learn stuff, or just accept a quiet boring life of drudgery in which productivity will be low, but you'll get paid for work you could sleepwalk through.
Katie Lucas
Monday, May 16, 2005
Katie covered your situation perfectly. I just want to add one piece of advice: get out if you can. I wasted 6 years of my career in a place like that and I regret it to this day.

Don't be like me :)
Jeff Mastry Send private email
Monday, May 16, 2005
I think you need to know which battles to fight.  And then as you build up credibility, you'll be able to fight other battles.

The most fun thing to do is to introduce a concept using a non-standard name... that might flush out whether it's the concept or the name that has been banned.

I've found that - as Katie notes - things get banned because of a mistake, but then the people involved move on and no one remembers why anymore... they just remember the Commandmant:  THOU SHALT NOT USE THREADS
KC Send private email
Monday, May 16, 2005
As all of us who do any posting know it's much easier to make pronoucements and shout people down than it is to be patient enough and skilled enough to make a difference.

1) Go for power. Being the leader puts you in the best position to impose your own insanity on others.

2) Lead by example. Since few us ever get the power you have to play the slow game of leading by example. Setup a wiki showing new stuff and try to make a community of like minded people. If your code ownership policies let you, change other code as an example. Over time this will make a difference. Setup weekly classes where developers discuss stuff. Try to create a culture where people talk to each other rather than out do each other.

3) Learn to accept what you can't change. Do your thing and be happy with your own efforts. Maybe the time will come when you can step in.

4) Consider you are wrong.

5) Leave to greener pastures. Those pastures will still be filled with cow shit though.
son of parnas
Monday, May 16, 2005
In regard to this posting, I too am extremely enthusiastic about "sharing the wealth" with other teammates. Whenever, admist of the project, I had to run off learning a new framework, the next meeting I was up on the board trying to spread the gospels. But alas, I was usually shut down by a few weary head nodes implying "Ya ya, whatever, we just want to get the project done." Even the smallest "Utility" classes were pushed aside despite the fact they could facilitate their work as well.

I don't know, maybe it's only me; I'm really hungry to acquire a new set of skills, not in depth as I should, but at least scratching the surface, tasting the water. These sort of attitudes, as I've found out, are not generally embrassed by masses so I've set my strategy to pick up people who are equally eager to learn on "a" subject and avoid slipping on social banana pills.
Aria Kockochka Send private email
Monday, May 16, 2005
You're looking for people who want to learn, who are willing to question rationally and who are prepared to personally commit to the effort that it requires. I hate to be overly cynical, but I've found that these people are incredibly rare.

 My advice to you is to think of a set of methods you consider worth trying (and realistic for you) in order to attract a group of these people. Mailing list, forum, wiki, discussion group lunch meetings, workshops, suggestion boxes, speaking invitations, training courses, whatever. Set a time limit for trying them. If it doesn't work out, get out or accept your lot.

 I'm speaking as someone who has been trying to institute change for nearly 5 years now, with just enough occasional movement to keep the hope alive. I now realise I should have recognised the underlying and immovable culture I was dealing with years ago.

 Then again, perhaps that is something you have to learn for yourself?
Tuesday, May 17, 2005
"if ((counter==1)==true)" is good :) we should put it on

I would one point to all the brilliant posts in here.

You grow as an engineer, when closely working with (learning from) someone more experienced, and as a leader/manager - when mentoring and organizing work of your team mates. It is my experience, that it is extremely hard to find a position when you can do a lot of both, unless all your life is work.

Someone here had a link to a very honest essay - "How to be a programmer". It looks relevant to the discussion.
Tuesday, May 17, 2005
Shouldn't it be if ((counter == 1) == true) == true)? Otherwise, how does the compiler know that the test against true evaluates to true?
comp.lang.c refugee
Wednesday, May 18, 2005

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
Powered by FogBugz