??? 09/10/09 21:32 Read: times |
#168844 - I'm not at all sure I agree Responding to: ???'s previous message |
Per Westermark said:
The nice thing between R&D work is that there is always something new to learn. It doesn't matter if you have been in the business for 40 years.
I can pick up a lot of new ideas on my own, but communicating with other developers is a great way to speed up that process. Why? Because these other developers have already sifted through a lot of material, so the things they want to tip about it the best things they have seen. I just can't sift through everything published myself. There's a place and a time for that exchange. It's not at the desk or workstation. There are professional groups, symposia, etc, that invite such interaction. It's not everyone is totally silent with "shoulder to the wheel" at all times, but it's not a Kaffee Klatsch either. There are discussions, particularly during breaks and mealtimes, and there are ad-hoc meetings that occur just for the purpose of "chewing the fat." Next thing - it doesn't matter if someone have 40 years in the business. If you make a design, someone else (even if they are hardly out of school) can still suggest improvements. Maybe even huge improvements. That is a reason why there is a need for a two-way (and sometimes n-way) communication when managing a project. A manager that always "knows best" can be a disaster for a project. I'd say it does matter. It's not that the boss knows best, but we endeavor to deliver what the client has contracted us to deliver, no less, and no more. Experience has taught me that inserting things not specified by the client is dangerous because it can, and often does, have undesired side-effects when you put in something that's not absolutely necessary to meet the customer's requirements. We give them what they say they want. That's the way to get paid. If they decide later on that they want more ... well, we tell them to bring money and we'll give it to them. People will only grow if you trust them. And if you look for a 50-year old developer, that developer will not have grown into an experienced and capable developer if someone else didn't trusted him before. The technology moves too fast for it to be realistic to sit at home with no connection to the outside world but a couple of magazines and expect to keep up. Having access to Internet will not make a significant change either - unless you are prepared for two-way communication. Sometimes talk. Sometimes listen. Evaluating. Giving feedback and receiving feedback. Without feedback, a developer (or any human being) will never reach their full potential. They may still be great, but not as great as they could have been. I've said it before, and I'll say it again. I'm not here to grow a labor pool. There's no benefit to me in teaching people anything except how to get the job done in the presence, some of the time, anyway, of the specific others involved. Some people just don't like one another, and I can't help that. If they want to work in my organization, such as it is, then they have to do that. As for coming up with "ideas" ... the client specifies what we have to do. If he says he wants to support 64kB of memory, that's what we do. If someone thinks it clever to provide for more memory because it might be helpful in the future, I put a stop to that right away. That's not what I agreed to do! If the client wants a green LED, blinking at 3 Hz, that's what he should get, no matter how useful a status signal in "Morse code" of some sort might be. Youngsters are always looking for ways to demonstrate their cleverness by including something they've already learned to do. Seasoned engineers have outgrown all that. I want people who are fully developed. Not everybody knows how to do every thing that comes along, but a fully developed individual knows how to tackle the unfamiliar problem and arrive at a reasonable solution. I can tell them how I perceive the task, but they have to do it in a way that they comfortably understand. RE |