From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=0.6 required=5.0 tests=BAYES_40,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,bdc41aa5ff8e1d93 X-Google-Attributes: gid103376,public From: bjw@mirage.iassf.easams.com.au (Brendan WALKER) Subject: Re: Programmers -> Engineers; Engineers -> Programmers Date: 1996/08/15 Message-ID: <4uu3mj$o1c@mirage.iassf.easams.com.au>#1/1 X-Deja-AN: 174277057 references: <1996Aug8.115630.4568@relay.nswc.navy.mil> <4uic1j$fg0@news-e2d.gnn.com> organization: EASAMS (Australia) Pty Ltd newsgroups: comp.lang.ada Date: 1996-08-15T00:00:00+00:00 List-Id: In article <4uic1j$fg0@news-e2d.gnn.com>, Andy Askey wrote: > >I have worked on tasks similar to your examples for the pasted 4 >years. Here are my observations: > >1) Don't hire more than a small number that are clearly a distinct >member of one group or another. For example, if you have 20 people in >the group, don't hire more than 2 that say they are radar gurus and >are not excited about software. And don't hire more than 2 software >people who could care less about radar. [snip] I agree in part with this. Certainly you only need a very small number of "problem domain" experts, however if the project is primarily a software development effort then the rest of the staff should be the most compentant "solution domain" experts that you can find. In this case, solution domain means skills on the design methodolgies, languages, operating systems, documentation and testing standards, etc, that your project is using! That is, well rounded, highly skilled and experienced Software Engineers (doesn't matter whether their degree is in science or engineering really, what matters is how they've learnt to apply their skills in the real-world). >2) Hire recent college graduates when possible. [snip] .......... This is in my experience down here in Australia the worst mistake that can be made. I have seen projects fail abysmally due to the company trying to "save money" by hiring far too many in-experienced new graduates. The problem occurs because the Universities/Colleges don't really teach the practical Software Engineering skills that can currently only really be learned on the job. Things such as how a good S/W CM system works, how to test S/W practically and effectively, the importance of documented processes and procedures, how to communicate effectively with other organsisations and team members, how to lead professional teams, etc, etc, etc........ >For you aging vets with a bunch of experience who disagree and think >that you should be given concideration over a new college kid I have a >question. Do you fit into the category of "expert" in your field? I am not quite an aging vet, but 5 years out of Uni and another 5 years working in the industry while studying in the first place I think puts me way beyond the graduate status! > If so, you will always have a job. You will always be hired for one of >those "expert slots". And if you have been working for say ten years >and are a pretty good engineer but not someone who is one of the >"best", and not someone who is particularly interested in software, I >have another question. >WHAT THE HELL HAVE YOU BEEN DOING FOR THE PAST 10 YEARS? Don't know what they've been doing, but I can tell you that most of these people are probably managers! >3) Hire based on the interview and not on previous job history. I [snip] >5) HIRE GOOD PEOPLE. Don't pigeon hole candidates. Just find a >smart and ambitious person and hire them. A smart, ambitious employee >can do most anything. This stuff makes general sense, especially this last bit. To add, a smart ambitious, highly skilled and experienced employee can do ABSOLUTELY anything! Best Regards, -- Brendan Walker | The opinions expressed above are obviously IASSF Project, | the ramblings of a troubled mind, and GMS S3I (Australia) | therefore not those of my employer.