Sponsored By Aspose - File Format APIs for .NET

Aspose are the market leader of .NET APIs for file business formats – natively work with DOCX, XLSX, PPT, PDF, MSG, MPP, images formats and many more!

A different shade of rose, or “How to…actually, I’m not up for subtitling this one”

To me, nothing is more disheartening than having my optimistic view of the world negated. Yes, sometimes people do irrational things on a regular basis but in the back of my mind, I always think there is a middle ground that can be achieved somehow. That hope is never lost. Or at the very least, that it won’t affect me personally. (Side note: I jest. Look it up.)

So here’s a question: What would you do if people more experienced than you were brought in to your team to work with on a project? Would you react with fear that you wouldn’t be able to keep up, or that your job was in jeopardy, or that they’d go crazy trying to implement “new-fangled” ideas like MVP? Or would you welcome the opportunity to learn and advance your craft.

What happens when they start introducing concepts that they know in their heart of hearts will make the application better but that you don’t agree with at first glance? Do you dig in your heels and violently oppose them? Or engage in a debate to come to some common understanding?

These are leading questions, obviously, and you know what my answers are to these questions. This post is more about the people, the ones that answer yes to the former questions rather than the latter above, even if they do it subconsciously.

Simply put, it’s frustrating. I’ve tried to rationalize the responses I get but the only conclusion I can come to the fits is that there are people in this world who are not only unteachable but are also steadfastly against even trying to learn. I was so sure that these people didn’t exist.

For someone who always thinks people want to do their best and always want to improve themselves and their craft, it’s depressing. Maybe I’ve just been lucky in my career that I’ve never encountered them, or maybe I’m just insulated from them because the people that I hang with, that go to or speak at user groups and conferences, are pre-inclined to the continuous learning disposition. But it’s not just in my industry. I can’t think of a single person I know well that doesn’t want to be better at what they do, whether it’s accounting, or land surveying, or nursing.

It’s not the lack of knowledge that bothers me so much as it is the close-mindedness. Listening to barely concealed sarcastic comments like “how many cool patterns can we put into this app?” Counter-arguments like “We’ve always done it this way” or “we need to be consistent with our other applications” or simply “I don’t like it.”

I can deal with disagreement. There are others on my same team that I don’t always agree with but that I respect. When we debate the merits and pitfalls of one method vs. another, it’s based on experience and rationality.

But here’s the distinction: if, at the end of these rational debates, we end up not using my method, I’m still happy with the code I’ve written. And that I’ve gained a new perspective. Being forced to go back and remove all INNER JOINs from our stored procedures because they’re “too confusing” makes me feel like I’m losing some unseen war.

And it’s one that I didn’t think even existed, let alone had to fight.

Kyle the Disenchanted

This entry was posted in Conscientious Coding. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • http://graysmatter.codivation.com Justice~!
  • http://codebetter.com/members/kylebaley/default.aspx Kyle Baley

    Some of the comments have given me cause for reflection on this and if I were to be honest with myself, I’m not totally blameless in my conclusions. Corey, you bring up a good point about speaking from ego vs. as a mentor. Thinking back to the situations that led to this post, I went on the defensive far too much when one of the methods I used was questioned.

    Being remote has added to my frustration because despite being able to pair via SharedView, it’s always far too easy to just find an excuse to hang up the phone and continue on with what I’m doing than to try to explain the value of what I did. I’m discovering that I have less patience than I did five years ago for some reason.

    I guess I’m more used to meeting someone halfway. But in some cases, we may have to go a little further than halfway.

  • http://blog.coreycoogan.com corey coogan

    Kyle, I have on my list to write on this very topic. Typical reactions I hear are “that’s stupid, why would they do that”. This is usually overheard from several cubes away, so I may stop by to explain and am usually met with more resistance, like “that’s not how I do it, doesn’t make sense”.

    It’s a fine line between ego and educating the confused. but I think it’s important to recognize when it’s ego and change the approach because speaking from the ego will always come across in a negative way.

  • Jim Cooper

    You’re pretty lucky not to have run into this situation until now :-)

    Everybody should read this chapter (and the rest of the book for that matter) from the pragmatic guys:

    http://media.pragprog.com/titles/ahptl/chap2.pdf

    It explains a lot about the people you probably have to deal with.

  • Not this time ;\

    Sigh I know the feeling – I’m just a normal developer (although enthused, love programming) with many ‘Senior’ developers who don’t care about programming – its just a job. As I’m not ‘senior’ my opinion seems to be automatically disregarded.

    That’s quite disheartening too.

  • Heh

    Outperform them. You want to drive business change, make sure that your code has a lower bug rate, is delivered on or ahead of schedule.

    Then take your metrics to your boss, get him to take them to his boss. Change will come.

  • http://blog.schauderhaft Jens Schauder

    These people do exist, and they exist in huge numbers. Their numbers concentrate in big companies. If you are working for such companies, you are pretty much out of luck. But if you are working for a smallish company, maybe up to a few hundred employees, you might be able to change some of them.

    Show them how life actually gets better when they learn and that their job and the value of their opinion is not in danger. They will resist at first, but they might change.

    At least I haven’t lost all hope in this.

  • http://shadowcoding.blogspot.com Erik

    Meh. My sympathies, Kyle. That’s a horrible situation to be in – I’m not too sure I would have the personal fortitude it takes to tough that sort of thing out. Good luck…

  • http://codebetter.com/members/kylebaley/default.aspx Kyle Baley

    Careful mendicant. I don’t want to give away my methods…

    Good suggestions by all, including the one to formally train in this arena, which is the only one I haven’t tried. Nice to get notes of encouragement as well though I’ve tried to make sure the discussion doesn’t turn into a “my workplace sucks” diatribe. But even after doing due diligence, after offering (and doing) mentoring and holding learning sessions and making certain compromises and showing evidence and trying to lead down a path that makes them see the rationale, and even after they’re specifically told by higher-ups that they have to get with the program, there are still people who firmly believe that data access through data readers and static methods is the best option out there.

  • mendicant

    I’m incredibly lucky to be working with a couple of consultants who have a lot more experience than me right now.

    Though our shop is really high up in terms of what we use, I find the biggest thing is trying to change too much too soon. Now, the obvious difference here is that we have had our consultant(s) come in with the idea that they would be helping us to improve our way of doing things.

    Current improvements include:
    – Use of func and action delegates as method params
    – nHibernate
    – Asp.Net MVC
    – Jquery
    – Conversion from handrolled IOC to Windsor (painful transition but soooooo worth it)
    -AutoMapper
    -I’m sure there’s more

    Of course, we’ve done this over the course of a couple of projects. The only problem we’ve had is they want to do it all at once. Improvement is improvement, but if you try to do it all at once, it does more harm than good (I’m sure you’re aware). We try to pick one or two things per project to improve upon.

    It’s too bad that people aren’t willing to listen though, because if you can introduce those improvements, even one at a time I’m sure they’d benefit a lot.

    Maybe you need to introduce guerilla improvements?

  • http://twitter.com/saadware Scott Saad

    We need to understand that it’s not just “close-mindedness” that is the problem. It may be our lack of understanding people and their defense mechanisms.

    It seems natural (especially for engineering minds) to put up our force fields when somebody is telling us a potential “better” way of doing something. It would seem that this is because many inherently feel that by being told another way of doing something means their way must be incorrect or inferior. It may actually be the case (inferior or incorrect), but if our jobs are to teach we cannot expect ego to disappear when so many engineers hold their code so close to their heart.

    We can then ask ourselves, who is really failing here? Are they failing to see the light, or are we failing to communicate in a way that makes them feel less threatened?

  • http://richarddingwall.name Richard

    I’ve had to deal with a few change-adverse people over the years too. The key is to get _them_ to see the light for themselves (omg this is a great idea) and champion it – not beat them into submission.

    To do this you need three things:

    1. Evidence. First you need to demonstrate clear advantages of why something is a good idea. Hard facts they can’t deny, not abstract theory.

    2. Alleviate their concerns. Put yourself in their shoes – anticipate their worries and counter-arguments and raise them they can (make it sound like they’re really important, even if they’re just little things). Explain what the risk is, and how you plan to mitigate it.

    3. Empowerment. Sit next to them and show them how easy it is to do an inner join. Turn your crazy foreign idea into something achievable they can do themselves.

    By now, your idea should be a no-brainer. Unless 1) it really is a stupid idea or 2) there is more at play. If the latter is true, my advice at this point is just to do it anyway and deal with the consequences after it’s already implemented. It’ll be the same as above, but your argument can be even stronger now you can show the benefits it provided.

    – Rich

  • http://devlicio.us/blogs/sergio_pereira/archive/2008/06/17/maintainable-by-whom.aspx sergiopereira

    I think a big part of deciding what to use and what to avoid in a project is considering your role and the rest of the team. If you are a full time member of the team, it can be worth insisting and introducing a new tool/technique. On the other hand, if you’re there temporarily, as a consultant or on your way out, choosing tools that the team is comfortable with can be the responsible thing to do.

  • The Chief

    I’d used a lambda expression tree as a method parameter and this guy said that he’d never seen anything like it and questioned whether it was a sensible thing to do because of this. My response: “Yeah, fair enough. I agree. I’ll change it back. It’s like when I lived in Germany. It took me a while to persuade Germans that they needed to use less complex grammatical structures. Some of them even had the cheek to suggest that I should learn the freakin’ language.”

  • Steve Sheldon

    We need to be able to learn to work with people like this. It involves learning how to be patient and advocate for your idea without getting frustrated.

    This is a huge challenge. As Jared mentioned, the “how to win friends and influence people” is probably good advice.

    I know it’s easy to just change jobs, but let’s be honest… everywhere we go you encounter people like this.

  • http://unhandled-exceptions.com/blog Steve Bohlen

    This experience falls firmly into the old addage of “if you can’t change the place you work, change the place you work” :)

    My sympathies but in this case it sounds like “run as fast as you can in the opposite direction from these people” is about the best advice I can suggest~!

  • http://twitter.com/jrowett JonR

    oh dear. you have my deepest, deepest sympathies. the best platitude i can offer is “don’t stop being you” – keep your ideals and get on with the business of being a pro.

  • Jared

    I concur, sucks for you.
    These situation are always frustrating. In similar situations I’ve found, especially when your seen as a threat, that you have to be very careful how you bring up your recommendations. Try reading some books on sales tactics and influence.
    It’s an older book, but reading “How to win friends and influence people” really helped me realize that people were reacting to the way I suggested something more than what I was suggesting.
    Of course, it may just be you found a place were everyone is a stick in the mud and hates change.

  • http://www.cyberkiko.com Kristof

    >I was so sure that these people didn’t exist.

    Well, I know folks were “great” web apps are C++ CGI. Functions are huge (largest I’ve seen was 3500+ lines). TDD is a waste of time. Subversion is a sort of science fiction. Integration is something that happens at the end of the project, usually several months after dead-line and with severe pain. That’s how they’ve done it for years, so why change. No amount of facts and arguing would change anything…

    >Simply put, it’s frustrating.

    Yep.

    I admit, I’m no expert on most of the stuff posted here at codebetter.com, however this time man, I do understand what you are talking about 100%. :-)

    I’m getting better on other stuff, too. So keep up a great work!

  • http://www.danielroot.info Daniel

    Brilliant. I don’t understand these people either, but they do in fact exist – and the more you work with government, the more you will find.

    I’m only halfway joking. The real de-motivator is workplaces where ‘getting by’ is good enough. IMO HR policies in many businesses and most government agencies foster this attitude.

  • http://codebetter.com/members/rob.reynolds/default.aspx Robz

    I think this comes down to that people rate their abilities and knowledge much higher than it might actually be. They may not see you as more experienced. They may also see you as causing more work.

    I know I fall on both sides of the spectrum, influencing the less experienced and also having a more experienced person mention things to me that I may not immediately see. Almost all of the time I am open to it, but not always (even with the same person).

    Sort of reminds me of the Blub Paradox (Paul Graham’s Beating the Averages article): http://www.paulgraham.com/avg.html

  • http://www.elegantcode.com Chris Brandsma

    So when did you start working for city/state government?

    [Condolences to any of the hardworking city/state employees out there for this sarcasm — you are the few and should be proud]

  • http://www.dimecasts.net Derik Whittaker

    I guess the only upside for you is that you are getting paid not only to create the original code, but also to remove it because someone deemed it ‘too confusing’

    Sucks for you