Beefy Boxes and Bandwidth Generously Provided by pair Networks
Your skill will accomplish
what the force of many cannot
 
PerlMonks  

New stuff to learn

by toadi (Chaplain)
on Jun 01, 2001 at 16:00 UTC ( [id://84901]=perlmeditation: print w/replies, xml ) Need Help??

Hello,

I'm a frequent visitor(therefore not poster) on PM. I learned a lot. But now I notice being between fellow coders at work. That they still are stuck in their way of doing things.
They don't read docs, man's or PM. And they never do. I know you can have a deadline and you think it works. Pff finished. But they never look for a better way to do it. NEVER!!!

They're still stuck in they're arrays while perl has the nice feature of hashes :). I've seen code that even with my minimized knowledge of perl could have been written simpler and smaller.(actually I'm doing it right know).

But they always fence with the fact well I don't have time to read the manual...

And for the worse I show them stuff they say cool, but they stick with they're things. If I give enough arguments, like it's clearer to read, lesser to type, better logic, hashes are faster, etc. They say wow. But they still go on doing it their way.

On the otherside I have my ways of doing things and as long as nobody gives me good aurguments why I should change I won't change. But I'll change when the right argument is given. Why can't they?

Do any of you guys have experiences like this with co-workers?

DISCLAIMER: Not all my co-workers are like this

--
My opinions may have changed,
but not the fact that I am right

Replies are listed 'Best First'.
Re: New stuff to learn
by davorg (Chancellor) on Jun 01, 2001 at 16:30 UTC

    You get people like that everywhere. The only difference is in the numbers. They are not programmers. They are simply people going through the motions. We have a couple here. One of them will be coming on my Idiomatic Perl course in a couple of weeks. I think it will blow his mind.

    Tactics for dealing with it vary with the situation. I'll assume that you're not senior to them (if you are it all gets a bit easier). Here are some suggestions:

    • Suggest to management that peer reviews of code would be a good idea. Go into the reviews with well-rehearsed arguments on why your methods are better.
    • Be a good example. If the code that you're writing is better in some way, then demonstrate that fact by showing how it's faster to write, faster to run, more maintainable or whatever. Eventually you'll be a good reputation and will be given all the more interesting tasks to do.
    • Put some of your code into reusable modules. This will make you even faster, but will also make it easier for you to suggest that the others use your code instead of reinventing the wheel.
    • Maybe suggest running small classes in more 'idiomatic' Perl. Just a couple of sessions introducing some of the cooler features. Pick a couple of sections from Effective Perl Programming and base it on that.

    Hope that helps, if it doesn't, then look for another job.

    --
    <http://www.dave.org.uk>

    "Perl makes the fun jobs fun
    and the boring jobs bearable" - me

      It's not about looking for another job. I like it here and the work is interesting...
      But what you suggested sounded good and I will keep it in mind :)

      --
      My opinions may have changed,
      but not the fact that I am right

Re: New stuff to learn
by footpad (Abbot) on Jun 01, 2001 at 19:28 UTC

    You can lead a man to logic, but you can't make him think.

    I think part of this depends on the personality involved. Some people are naturally curious about finding better ways to do their job, others aren't. They're perfectly satisfied with their habits and really wish the curious ones would just go away. It's unfortunate, but exists.

    Here are a couple of other ideas that may help:

    • Make sure you go to your co-workers when you're stuck. Use them as a resource and collaborate on solutions. They'll feel like they're helping you and, in turn, may be more open to your suggestions. Who knows? Maybe they do have a useful trick or two?

    • Obtain a copy of The Pragmatic Programmer and read it while you're at the office (during lunch and breaks, of course). Start practising its ideas in your work. As your quality improves, others may notice and ask about it. Don't get overly zealous, just point them to the book and show them how it's helped you. You might also suggest it to your manager.

    • Consider fostering an informal get-together during non-development time. At one job, for example, I helped start a series of non-mandatory "brown bags" at lunch time where people would offer short (15-20 mins) presentations and everyone would discuss the information round-robin. It turned out to be a great way of a) sharing knowledge, b) getting feedback from your team, and c) knitting the team together. In the end, we weren't just a bunch of coders, we were a team. In turn, people were more open and accepting of alternate approaches.

    Keep in mind, though, that there's only so much you can do. True change only comes from within. You have to lead quietly through example and demonstrate true benefits if you want people to consider adopting your ideas.

    --f

      On your first point. Yes I do that. But sometimes I have to admit I say: "Oh my god what is this!". Maybe there is a more diplomatic way to do this.

      On your second point. Read the book several times :) And already adopted several things at work.

      Comming to your third point. At work I show it mostly at my team or the ones that are interested.


      Just to give a example: a developer at work needs to retrieve some info get it in the right format and load in the database. Well she did it for the most part manually??? Can you believe that? It took me a hour to write the script a 1/2 hour to test it and 5 mins to put in the cron!!! And never think about it again. It took her a 1/2 hour every 2 days. Now the script runs every hour so the db is more up to date!!

      She said nice. But it really meant now I have to do less work instead of learning how she next time could do this too!!



      --
      My opinions may have changed,
      but not the fact that I am right

      I feel your pain, brother...:)

      I read somewhere that only 10% of computer users will ever read documantation, 90% will stick what they learn 'by accident" and never try to learn more, only if persuaded (screaming and kicking) to do so. So no surprises your colleagues matches 90% of population.

      My situation is also rather complicated. Although I have 10+ years of experience in programming, it was client/server and databases. I started with web, CGI and perl 3 months ago on my new job. I am in a team with 3 more programmers with various levels of experience (but max is about 3 years in IT), with little experience in design big multiuser systems, and even worse: they never worked in bigger teams (max 2).

      So I needed to learn about perl, genetics, fix design flaws, develop common routines, while they can vote my proposals down on meetings. Or I need really to convert at least one or two of them before meeting to get my proposal through.

      I understand their position: If I propose to fix something they cannot see, because it is too far away for theit experience yet, they may feel my concerns unnecessary.

      But proposal about code reviews looks good for me, I'll try to do it. Any suggestions about link/books how to do it?

      Thanks to perl saints, there is such a great place as perl monastery where you can express your concerns and share your pain with other perl developers, who "been there, done that" and may help with insight.

      I definitelly get "The Pragmatic Programmer" book, I do not know where to get time to read it... :(

      pmas

Re: New stuff to learn
by bikeNomad (Priest) on Jun 01, 2001 at 19:00 UTC
    Something that took me years to realize is:

    Half of all programmers are below average.
    And the average ones aren't that great, either.

    If you're fortunate enough to work for a small company in a hot area, this can mean that you get only above-average programmers. But as the company size grows, or if you're in a not-so-hot area, you have to deal with the best of what you can find.

    All isn't lost, though. You have to realize that people stick to what they know because they feel reasonably competent with it (whether or not they are). No one wants to feel incompetent. The fear of looking stupid keeps many people from trying new things.

    If you can share ideas with your coworkers in a non-threatening environment, it's best. Code reviews can be threatening, because you're "judging" someone else's work product -- exactly what they're being paid to produce.

    If you can find another venue to share information, it's better. The suggestions above for conferences and tutorials are good, though many people don't seem to get much out of them after a few weeks.

    Perhaps you can make some other event at work: a "show and tell" where everyone has to present something they've learned to everyone else will allow everyone to feel like an expert for a few minutes, and will give you a place that you can guide the others.

    Just try not to threaten them, and it'll go smoother.

    It's hard to underestimate the amount of human behavior that is caused by fear...

Re: New stuff to learn
by delegatrix (Scribe) on Jun 01, 2001 at 17:55 UTC
    Code review sessions really help. My office has started these and we've all benefited. Just be sure that different people offer up code each time.

    You might also suggest informal office seminars on basic topics like commonly used modules or specific perl language features.

    Lastly, if your employer has the budget, suggest sending programmers to conferences and workshops as part of a professional development program. Sitting through, for example, MJD's Red Flags workshop can really open your eyes to your poor coding habits.

Re: New stuff to learn
by Johnny Golden (Scribe) on Jun 02, 2001 at 00:09 UTC
    I have often run into similar problems. The scariest thing I ran into was a programmer who was taught (and I have verified that this is the way a lot of programmers were taught 10 to 15 years ago) that when having to fix a problem, the goal was to fix the problem, not to have the program run correctly. I find if the end user can't use the program, they feel it is worthless. As they tend to more directly influence those who write our paychecks, I find it is best to make sure everything works before you release it. A lot of people are stuck in their ways and with technology you just can't do that. The thing I love about Perl and this site in particular is that it is a living system that grows and changes. Sure you will never know everything about the language, but I find that it tends to attract people who like to learn. I heard somewhere that biologists have a word for something that doesn’t change: dead. In fact, I believe I learned that on this site.
Re: New stuff to learn
by arashi (Priest) on Jun 06, 2001 at 00:39 UTC
    I can relate, not by dealing with people programming perl, but simple web pages. I work for the Web Development Office at my University, and it seems that there are a very limited number of people who want to implement new things in their web pages. We get calls all of the time from everyone, from students to professors, who don't know much html, or they're still doing things the way they did 4 years ago. They all want their pages to look good, or have some useful items on it, but if they can't get those with old, outdated code, then they won't take the time to learn it. I actually had one guy tell me that he doesn't have the time to learn basic things like tables, etc... when he probably could have learned all about tables during the time it took for him to tell me he had no time :)

    I've come up with a solution to our problem, take control away from people who can't adapt to new ideas--along the lines of "oh, you don't know CSS and you don't have the time to learn, that's fine, no web for you!". (actually I don't think I could be that mean :) If people don't want to implement new things, don't let them have the chance. I want to change the name of our office to the OTC (Office of Total Control). My plan is to use HTML::Template and a database to control all of the web pages on campus. Users log in, enter their data in a form, and the perl script does the rest. When some new technique is discovered, we (those who want to learn) change the template. The beauty of the plan is that similar systems are already in place all over the web. I'm sure there will be some initial resistance to it, but hey, if they can't cut it, don't let em. If someone really wants to learn, they can figure out how to change/affect the template, by doing that, they'll be forced to learn new techniques...or, Heaven-forbid, they ask us to teach them something new (and they really want to learn).

    Arashi

    I'm sure Edison turned himself a lot of colors before he invented the lightbulb. - H.S.

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlmeditation [id://84901]
Approved by root
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others making s'mores by the fire in the courtyard of the Monastery: (5)
As of 2024-03-28 23:46 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found