in reply to New stuff to learn

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:

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

Replies are listed 'Best First'.
Re: Re: New stuff to learn
by toadi (Chaplain) on Jun 03, 2001 at 01:43 UTC
    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

Re: New stuff to learn
by pmas (Hermit) on Jun 04, 2001 at 06:25 UTC
    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