Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site hoptoad.uucp Path: utzoo!watmath!clyde!burl!ulysses!bellcore!decvax!decwrl!sun!hoptoad!laura From: laura@hoptoad.uucp (Laura Creighton) Newsgroups: net.singles Subject: Re: Title Inflation Message-ID: <464@hoptoad.uucp> Date: Sat, 1-Feb-86 21:07:07 EST Article-I.D.: hoptoad.464 Posted: Sat Feb 1 21:07:07 1986 Date-Received: Mon, 3-Feb-86 04:48:17 EST References: <705@leadsv.UUCP> <130400004@hpfcls.UUCP> Reply-To: laura@hoptoad.UUCP (Laura Creighton) Organization: Nebula Consultants in San Francisco Lines: 97 In article <1197@homxb.UUCP> afa@homxb.UUCP R. McIlree says: >Therefore, to me, a software engineer utilizes the available >methodologies, software packages & tools, structured languages, >and development environment enhancements to turn out an >ENGINEERED PRODUCT: namely electrons flying through a CPU with >some method to it; or those same electrons residing on a disk >pack or floppy. >A programmer, on the other hand, takes direction (namely from a >software engineer or systems analyst) and cranks out code that >is supposed to meet a specification drawn from the software >engineer or analyst. I had a job like this once. You're an engineer, all right, but I fear that you will not meet your deadlines. The problem is in the methodology. If you want good code produced, you have to employ people who can turn out an ENGINEERED PRODUCT. If you are supposed to take the random sludge from 3 idiots who can type, and turn this into a product, then you have had it. Your best bet would be to dictate what you want onto tapes and then give it to your employees, but even that is risky. I worked like that, with staff like that once, and I never came within a mile of making a deadline. It won't work -- you are trying to do the hard part of the job for 3 people -- 4 counting yourself -- and that will never swing it. On the other hand, you may have 3 engineers working for you. In that case, you should make it part of their job to turn out an engineered product. Provided you don't keep the information ``what makes an engineered product'' locked tight in your brain, your engineers will deliver. Obviously, one of your employees still needs to learn this (Gosh! I thought that *my* last crop of employees were wretched. But nobody would show off a demo to *me* that failed abominably, unless it was due to a TERMCAP problem. This seems terribly unprofessional to me.) but this may be someone who is just learning his job. You, however, I think could stand 2 pieces of advice -- and I am posting this because I am *sure* that you are not the only one!. FIRST -- the law of the jungle is ``if you have a problem I will meet you in your office''. This is a law for programmers, engineers, and other people who are trying to get some work done. This is frowned upon in most management books I have read, where they stress that you should have people come grovelling to your office, where you have the psychological advantage. As far as I know, most management books were not written about the computer industry. You really want to be able to do some work in your office, and you don't want to be attacked in it. At work, your office is *your* safe space where *you* get *your* work done. So you shoudl meet your boss, your employees, and whoever else you can manage in *their* office. Anybody who is hiding in someone else's office to read the paper (I did this once -- no, shit, more than once) is letting other people be too free with their time. When people have problems, tell them that you will come see them. And do see them, but when it is iconvenient for you. You cannot get your own work donw if you are driven by other people. You will start concentrating, and then be interrupted. In case you haven't noticed, it is your concentration and thinking which they are buying from you, and if you keep being interrupted you won't be able to deliver. And you will nopt ship in time. SECOND -- if you are overworked, work *early* rather than *late*. Go in to work at 6 am. Work ofr three hours before your boss or your employees show up. You will have the work that *you* want to do done by then. So, since half the people who phone you are only interested in hearing that there has been progress you will have real stuff to tell them, so they will *go away* and *let you work*. And, if any crisis shows up, you can deal with them without worrying about when you are going to fit your work in among the firefighting. Work EARLY. not LATE. Late workers in management spend their evenings getting caught up because they spend their days frantically puytting out fires and waiting to do their own work. People who already have their own work done make better firefighters. THIRD -- if your staff is any good, then the purpose of management is to keep the rest of the department off their backs (by running interference for them) so that they can get their good work done without intereferences, meetings, phone calls, and other things which get in the way. So any time anyone would be tempted to phone one of your staff, they should phone you instead. And any time that a member of your staff needs to find out something from someone in another section or department, they should tell you what they need to know, and you should ask the right person. This will leave your engineers free to program all the time, without having to deal with any extarenneous communication which they are not interested in. Lots of great engineers love this -- they love their work, it is the company buracracy which they can't stand. So isolate your people from this bureacracy, do all of their communicating for them, and (if you take this job) be warned that this is a full time job in itself. And it shoudl pay *very* *very* well -- after all, the engineers that work for a manager who understands this are happier and more productive than ones stuck in the bureacracy. ----------- I've been there. Keep the people you don't want in, out of your office and you will get more work done. take care Laura Creighton -- Laura Creighton ihnp4!hoptoad!laura hoptoad!laura@lll-crg.arpa