| ??? 09/10/09 23:30 Read: times |
#168846 - The customer is always right Responding to: ???'s previous message |
Per Westermark said:
Richard said:
[...] but a fully developed individual knows how to tackle the unfamiliar problem [...] Notice the problem with that little text. There are no fully developed individuals. There are always unfamiliar problems. Finding ways to solve these unfamiliar problems is something a developer has to do all through his career. It is only by getting new unfamiliar problems to solve that he can grow and add to a possibly already magnificent experience. As long as we don't get hit by dementia, we have the ability to learn new things until the day we die. In the real world, everyone is a student now and then. Hopefully also a teacher now and then. In a team where A knows how to solve a problem, an information transfer from A to B means the team suddenly have two skilled developers who knows how to solve the problem. Having sampled a goodly number of the youngsters, I'll stick with my 45+ set. There's trouble with the youngsters coming to work, let alone with coming to work on time, and with getting them to do their work, not to mention doing it on time. They tend to argue pointlessly about how the customer is wrong, when the job is to give the customer what he has agreed to pay for. No, Per, it will take a VERY unusual under-40-type to interest me. It could happen, but I don't look at new graduates. That 45+ set has discipline, experience, and well-honed skills not yet present in a youngster. True enough, they were all youngsters once, and the smart ones remember when. However, only one in a thousand new grad's gets to be a "fully developed" (my definition, not yours, since yours don't exist) seasoned engineer. Now, there was a time when I did employ youngsters. Of course, I was pretty young then, myself. I had engaged a couple of university faculty/staff to do a job because the Unix-based boxes we were using back then were just like the ones at the school. After nearly three months on a job I gave them, which I estimated should take at most a week, I hired a 15-year-old from the local high-school electronics club who took on the job and completed it, including (somewhat rough) documentation, in a single weekend. There's a lesson in there, somewhere ... Hasn't it hit you, that someone out there and just out of school could actually ask you why you want to use a 64kB part, when there is an alternative solution that would fit in just 32kB? Life isn't just about finding the coolest way to blink a LED. The customer wants feature X, but feature X can normally be realised in more than one way. Right now, feature X, Y, Z, ... are always implemented your way, because you are using a one-way approach. Trying "what do you think about implementing this like ..." can lead to a response "Yes, that would work. But what if we insted did it like this...". A project manager has to make the decisions, but the quality of the project can be greatly improved if the experienced developers - the "hired hands" - are allowed to make suggestions too, before the manager takes the decision. My concern is to realize that feature, and, until someone convinces me that the best way to blink a LED is something other than the cheapest way, I'm not going to worry the matter. The job is to provide that feature, and not to spend a lot of time and resources on how. When I tell 'em the customer wants a 64k Byte memory, it's because that's what the customer specified. The job is to give him what he wants, and not to second-guess him. That's the way to get paid, doncha know! RE |
