Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!


Forgot your password?
Programming IT Technology

How to be a Programmer 442

Martin L. Smith writes "Rob Read has posted his magnum opus, "How to be a Programmer: A Short, Comprehensive and Personal Summary" to Samizdat Press where it can be scarfed by the masses. Rob's book is a forty-page tour through the million-and-one things he thinks a programmer ought to know as he sets out into deep water. One of the reasons he posted this was to get some feedback, so tell him what you think. Samizdat Press is maintained by the Colorado School of Mines to provide a distribution point for free (mostly earth-sciences related) texts."
This discussion has been archived. No new comments can be posted.

How to be a Programmer

Comments Filter:
  • We got it (Score:5, Funny)

    by mao che minh ( 611166 ) on Wednesday January 29, 2003 @02:44PM (#5183635) Journal
    I think that 90% of the people here already have the whole "how to thrive in a seclusive career path that is extremely difficult to find employment in and you end up having very little contact with the softer gender" thing down pat, thank you very much.
    • by joe_bruin ( 266648 ) on Wednesday January 29, 2003 @02:59PM (#5183748) Homepage Journal
      just read this handy guide to writing unmaintainable code [mindprod.com] and do exactly what it suggests
    • by zootread ( 569199 ) <zootread AT yahoo DOT com> on Wednesday January 29, 2003 @04:24PM (#5184377)
      you end up having very little contact with the softer gender

      I don't know where everyone gets this from. Maybe this was somewhat true 10-20 years ago, but not now. Not all programmers are socially inept dorks with no lives outside of computers. Or am I the exception to the rule? I tell women I'm a software developer and it *increases* my chances with them (I suppose they think $$$). Hey, and I've been a geek most of my life--and I still spend much of my free time on computers. Women like a guy who can fix a computer. Trust me. Being somewhat successful in your profession helps also, so reading "How to get a Programmer" will indirectly help you get chicks.

      If you're a geek, you *can* have luck with the ladies; especially if you've got a job and some cash to spend. Shave that beard, get a decent haircut. Buy some nice clothes. Go out, drink a coupla beers, and just talk to women. There are ladies out there for everyone. Trust me, they are just waiting for you.
    • Re:We got it (Score:4, Insightful)

      by DickBreath ( 207180 ) on Wednesday January 29, 2003 @05:18PM (#5184887) Homepage
      how to thrive in a seclusive career path that is extremely difficult to find employment in and you end up having very little contact with the softer gender

      Maybe you should change career?

      Some of us either aren't seclusive, or don't see being seclusive as a problem. Or maybe seclusive means "not hanging out with stupid people". If you are in an environment with mostly stupid people, and noone smart to hang with, then you might seem seclusive.

      Some of us are employed. On another point: the economy is bad right now. But even if the slump is permanent, some of us are, and it is possible to be employeed doing things that are somewhat insulated from economic cycles, but maybe aren't as glamorous as the dotcoms were.

      Finally, while I'm sure this only applied to a minory of us, I am happy to avoid contact with that particular gender. :-) Others may differ. But being a geek does not somehow magically exclude one from dating. Learn to interact with people and develop some social skills. Lots of people must learn to do this.

      My point: Some people think being a geek is bad. I think it is good. You can find joy and happiness in being a geek too. Stop thinking of "How to be a programmer" as "How to have a miserable life." It's baloney.
  • by Anonymous Coward on Wednesday January 29, 2003 @02:46PM (#5183653)
    1) Write a spec
    2) Send spec to Indian/Russian/Chinese Programming Outsourcer
    3) ...
    4) Profit!
  • just a thought (Score:4, Insightful)

    by Anonymous Coward on Wednesday January 29, 2003 @02:46PM (#5183654)
    ok, i just skimmed a couple lines of this thing but it seems to that he glosses over some major areas: "Idealists may think that design...is more fundamental [than debugging] but they are not working programmers." IMHO it's nearly impossible to implement a major system without doing some serious design work first - debugging can fix logic errors, but not design flaws.
    • Re:just a thought (Score:5, Insightful)

      by SirSlud ( 67381 ) on Wednesday January 29, 2003 @02:51PM (#5183694) Homepage
      In the real world, if you're designing large systems, you're not a programmer, youre a systems architect.

      Think .. architects design the huge thing .. programmers build it, and make localized design decisions.

      But I dont think its fair to say programmers must be good at large scale design since thats a career path unto itself. And those who can design large scale systems are usually not so good at the nitty gritty ... so I think your point is more one of semantics.
      • Re:just a thought (Score:3, Insightful)

        by HalfStarted ( 639977 )
        While I agree that a programmer does not NEED to know how to design the full system I do not really agree that a system architect does not have to know all the nitty gritty. Yes in a pure since it isn't necessary to know the details but in practice I do not think it is possible to design a robust, scaleable system with out a solid understanding on the nitty gritty, as that knowledge is usually one of the driving elements in architectural decisions. ... this comment cut short by the need to do real work... sigh
        • Re:just a thought (Score:5, Insightful)

          by Coz ( 178857 ) on Wednesday January 29, 2003 @04:13PM (#5184278) Homepage Journal
          Since I'm doing that "system architect" job at the moment, I feel like I can reply to this :->

          If I didn't have years of prior experience hammering systems together, debugging custom code and off-the-shelf things made to play together in new and unforseen circumstances, and a few tens of thousands of lines of multiple languages of coding, I wouldn't be able to avoid the land mines that the folks who designed THOSE systems subjected me and my "tribe" to.

          One of the glaring gaps in the last 15 years or so has been the one between the classic "system engineers" and "software engineers". The "System Engineers" have usually been hardware types, and have no problem saying "it's a software problem - deal with it" and making the poor code monkeys cope with their bad decisions. It's taken me years to get the credibility among those folks to make them listen to my opinions and actually change their minds; I was just a software guy, not a Systems Engineer. Now, I have a program manager who's former software, and a software manager who's former software, and I'm senior to our chief system engineer :-D. I can't dictate, but if it doesn't fit in with my architecture, I have a veto - and I'm consulted on every technical decision that's not already delegated to someone for implementation (I review those).

          This may actually be my dream job - fortunately, we're doing well on it, so we're thought of well inside the company; unfortunately, we're meeting our schedules, so it'll end within the year *sniffle*. Then, I'll just have to find a way to keep myself out of management....
      • Re:just a thought (Score:5, Insightful)

        by oconnorcjo ( 242077 ) on Wednesday January 29, 2003 @03:41PM (#5184035) Journal
        But I dont think its fair to say programmers must be good at large scale design since thats a career path unto itself. And those who can design large scale systems are usually not so good at the nitty gritty ... so I think your point is more one of semantics.

        I totally DISAGREE. Good programmers have a total picture of how thier programs work and interact and that is why they work and interact very well (the nitty gritty is done with a debugger and testing). If a system architect was not at one time a very good programmer then he is probably a bad system architect. Of course thier are tons of bad programmers who then become bad system architects FWIW.

      • Most applications are medium-sized, and don't require more than the initial developer or two for anything until they get past the first release or two.

        I've found that you can build systems much faster and cleaner when the initial development is done by a single person - it gives a clear, consistent set of design patterns that future programmers can use to extend the base system.
    • Re:just a thought (Score:2, Interesting)

      by RobertLRead ( 627533 )
      I don't necessarily think debugging is the most important skill for a programmer, so much as that it is the first really hard skill you have to learn. I think one can do a lot with poor design skills and good debugging skills, especially when just starting out...after all, not everyone can create the design. Surely those who find and report bugs in open-source software are doing a very hard and valuable taks.
    • by ackthpt ( 218170 ) on Wednesday January 29, 2003 @04:10PM (#5184263) Homepage Journal
      debugging can fix logic errors, but not design flaws.

      Such sagely wisdom

      With anonymity you write

      Knowing and unknown.

    • Re:just a thought (Score:5, Insightful)

      by Citizen of Earth ( 569446 ) on Wednesday January 29, 2003 @04:13PM (#5184279)
      IMHO it's nearly impossible to implement a major system without doing some serious design work first - debugging can fix logic errors, but not design flaws.

      I find that a very effective way to discover and fix design flaws is to try to implement them. A two-year PowerPoint exercise doesn't always do this.
  • by anactofgod ( 68756 ) on Wednesday January 29, 2003 @02:49PM (#5183675)
    That one can't learn from reading Dilbert and watching Office Space.

    "Why didn't you put a cover sheet on the TPS report!" - "Terrible" Terry Tate.
  • ...Simple, just keep doing the stuff they give you. When one tool doesn't work, pickup and learn a better tool. I remember taking on a student job as a programmer, back in 1981. The path has twisted and turned a bit, but I'm still doing it until I find something else I really like ... or win the lottery ;-)
    • by EvilTwinSkippy ( 112490 ) <yoda@@@etoyoc...com> on Wednesday January 29, 2003 @03:42PM (#5184046) Homepage Journal
      The journey of a thousand miles begins with a step.

      I agree with the poster above, but I would like to add a twist. I have found that few successful programs are successful at simply programming. To be truely successful, you must be good at learning to program.

      It doesn't matter how much you can do or have done. The market for programmers will always be in untested areas doing the impossible, or at least the highly improbable.

      In the end, your actual training and experience is bunk, unless it used as the basis for learning more. The truely gifted programmer does not build static project. He or she builds a tome of routines and knowledge that are the foundations for code used decades later.

      Meditate on this, Grasshopper

      • I agree with the poster above, but I would like to add a twist. I have found that few successful programs are successful at simply programming. To be truely successful, you must be good at learning to program.

        Agreed, yet...

        n the end, your actual training and experience is bunk, unless it used as the basis for learning more. The truely gifted programmer does not build static project. He or she builds a tome of routines and knowledge that are the foundations for code used decades later.

        I'll differ here. I once felt it was a good idea to build a library of routines. However, the flow and product of the routines is more important than actual code. Better still is the experience of writing the same program a thousand times. The experienced programmer/analyst hears someone describe a need and is already assembling it in their mind. Visualizing the manifestation of the concept is key, writing code is just manual labor. What's the saying? Success is 10% inspiration, 90% perspiration? Well, the 10% is what they're really paying you for.

  • by arf_barf ( 639612 ) on Wednesday January 29, 2003 @02:53PM (#5183704)
    How to deploy the software and updates to it.

    It gets quite complex in custom business applications where you have to distribute client, middle tier and database updates to production systems.

    Anyhow, my 2 cents.

    • Not that I've read the piece, yet, but I'd say that has nothing to do with being a developer. That has everything to do with being a release control engineer - which is another hat.

      Yes, many developers wear more than one hat (developer, QA, RC, etc), but the RC hat is not the same as the developer hat.
  • The short list (Score:5, Insightful)

    by mighty_mallards ( 259544 ) on Wednesday January 29, 2003 @02:54PM (#5183717) Homepage
    Here's what is important to me as a programmer:

    1. Always keep learning - it's not as important how much you know - it is important how fast you can learn new things

    2. Don't just implement something for the sake of doing it, or because it will look cool on your resume. Make sure you have valid reasons for what you do, preferrably backed up by some research. Change isn't bad unless it is change for the sake of change.

    • Re:The short list (Score:5, Insightful)

      by jgerman ( 106518 ) on Wednesday January 29, 2003 @02:59PM (#5183749)
      Err 1 and 2 are kinda mutually exclusive. Additionally, as far as I'm concerned and backed by experience, people who do 2 tend to be the better programmers. People who dabble in CompSci because they love it, and write code for the sake of writing it, are not only more experienced, they're also more willing to try new things, and have a better understanding of the field.
    • 2. Don't just implement something for the sake of doing it, or because it will look cool on your resume. Make sure you have valid reasons for what you do, preferably backed up by some research.

      Making sure your resume is fully buzzword compliant is a perfect justification for picking up a technology. To this day, I consider Java to be C++ for dummies, yet that is what puts food on the table. There are patterns that emerge regardless of the specific technology, so it is usually a good idea to optimize the pocket book while picking up a new skill.

      I'd made the number two spot - do it for love. Love of coding, creating, problem solving, and other aspects of software development.
  • Programmer? (Score:5, Insightful)

    by rela ( 531062 ) on Wednesday January 29, 2003 @02:54PM (#5183719) Journal
    This looks like it should be titled "How to be a Developer", as much of it is oriented towards programming for a project or coporation...
    • Re:Programmer? (Score:3, Interesting)

      by RobertLRead ( 627533 )
      Yes, it is probably mistitled. I'd rather expand the essay to include other aspects of programming than change the title...but in the short term I'll do that, thank you.
  • by TerryAtWork ( 598364 ) <research@aceretail.com> on Wednesday January 29, 2003 @02:56PM (#5183733)
    The 'Thrown Out Like an Old Sock' chapter.

  • by C60 ( 546704 ) <[ten.06nobrac] [ta] [dalas]> on Wednesday January 29, 2003 @02:57PM (#5183741) Homepage
    1) Write code
    2) Avoid commenting your code at *all* costs
    3) Obfuscate code, heavily and often.
    4) Make sure everyone sees your code. This will culture a sense of fear and awe in your coworkers. Particularly if you can make your Perl code look like assembler.

    With these 4 easy steps, you too can be one of the last people to be laid by your employer!
    • by rela ( 531062 ) on Wednesday January 29, 2003 @03:04PM (#5183784) Journal
      With these 4 easy steps, you too can be one of the last people to be laid by your employer!

      Mere typo, or Freudian slip?

    • To be fair, commenting code is a slippery slope.

      A little commenting can go a long way to helping someone else understand the system.

      A lot of comments can be a burden. Why?

      Nobody updates them, and lots of people don't read them. Additionally, it takes a long time to write lots of well-written comments - time that is usually better spent re-architecting the system to make it easier to understand.

      Every day I come to realize more and more that comments are, on the whole, a waste. Sure, a little comment here and there when something non-standard is going on, or unintuitive. But it is neither feasible nor necessary to comment all the code in a large system - just write better code!

      Note that this is NOT meant to say that documentation is worthless. On the contrary, in my experience, the most useful documentation is that which describes the system as a whole, the assumptionst that are made, how the subsystems interlock, etc... Those are things that are not easily gleaned from code, no matter how well written.

      Additionally, lots and lots of comments get in the way for the coder navigating the source. It can be a serious slowdown if comments are used too much.

      Don't comment, but DO document.
  • My advice... (Score:5, Interesting)

    by JaredOfEuropa ( 526365 ) on Wednesday January 29, 2003 @03:00PM (#5183756) Journal
    There is no substitute for experience, but there is something resembling a fast track.

    Get paired to a senior programmer/systems engineer

    If you have the opportunity to work with a senior on a one-to-one basis, grab it with both hands. There will not be many times when an experienced guy is willing to work with you or coach you, so rejoice when the opportunity presents itself, take it. A colleague of mine asked me which project he should take: a glamorous one where he would be working in a large team with no coaching, or a boring-looking but difficult job, working under one senior programmer. I adviced him to take the latter... which he did, and while he often complained about the job itself, his programming skills improved by leaps and bounds, which made him a senior programmer on the next assignment. I was glad to see he has taken it upon himself to teach in the same manner and spend lots of time with the junior guys.
    • So what advice would you give to the senior programmer/systems engineer who is also asking (and needs to ask) the question: How to be a Programmer? I've found that typically only 15% or so of programmers really know what they are doing. That figure rises as you move up the ranks and is finally double that at the senior level ... 30%.

      • Re:My advice... (Score:5, Insightful)

        by homebru ( 57152 ) on Wednesday January 29, 2003 @07:05PM (#5185726)
        ...what advice would you give ...

        You only need to stay 15 minutes ahead of the others for them to think that you are a genius.

        Several things you can do:

        • Create a small version of your development environment at home and spend time doing little proof-of-concept projects there before announcing your design ideas at the office. Even if people find out that you are proofing at home, you can get points for having a Give-A-Shit attitude.
        • Write up your thoughts/notes on the current project and give them to the new kid in the group. S/he will become conditioned to come to you for answers. Which will force you to learn.
        • Call meetings of the programmers to talk about shop standards, techniques, "how to use GDB", etc. Nobody else is trying to form the herd into a team and you will look like a leader. Which will force you to become one.
        • Teach classes to the other programmers. Managers love to get department training for effectively nothing. An AS400 jockey could try to explain OS400 (is that the right name?) to UNIX jocks. A UNIX type could intro Linux to the 400 jockeys. You really find out what you do and don't know when you try to teach someone else.
        • Get a copy of some presentation tool (power-point equiv.) and learn to do simple presentations. Ten pages or less; outline form; major bullet points. Then use those techniques in your peer meetings. Scare the bejeezus out of your manager by using a formal presentation to explain why you HAVE to have some new tool in the department. You'll know you have "arrived" when your boss uses your presentation to go to his boss for more budget money.

        Get the idea? Learn by doing privately and learn more by teaching. To be really great, you need more than coding skills. You also need writing, teaching, leading, and public-speaking. But most of all, don't try to do it in a vacuum. You can learn from others while you are teaching them. You can't get there overnight, but by constantly picking at it, one little piece at a time, you will get there.

        Downside is that marginally-abled management will see you as a threat to their jobs.

        p.s. For goodness sake, learn to punctuate and use a spell checker. (No touchbacks.) You don't get points for looking professional; you lose for not.

  • by Anonymous Coward
    It's really funny that the second sentence of the 'Learn to Debug' section has a heinous grammatical error.
  • Take each page number in the index, and add two.
    Other than that, it looks very nice :)
  • by Anonymous Coward on Wednesday January 29, 2003 @03:06PM (#5183791)
    Choose no life.
    Choose no natural light.
    Choose cafeine.
    Choose to have RSI.
    Choose no girlfriend.
    Choose to work long hours and the weekends.
    Choose to use C.
    Choose to use JAVA after talking to the boss.
    Choose to have a bloody big 21 inch monitor.
    Choose to comment code.
    Choose to have to comment other people's code.
    Choose to run a sourceforge project on the side.
    Choose to be abused by mindless helpdesk jockeys.
    Choose Comp Sci.
    Choose D&D geeky friends.
    Choose Slashdot.
    Choose an early grave.
    Choose something else.
  • by axxackall ( 579006 ) on Wednesday January 29, 2003 @03:06PM (#5183792) Homepage Journal
    This classic translation [canonical.org] takes care about the spirit of programming.

    Just few quotes:

    Does a good farmer neglect a crop he has planted?
    Does a good teacher overlook even the most humble student?
    Does a good father allow a single child to starve?
    Does a good programmer refuse to maintain his code?

    There once was a master programmer who wrote unstructured programs. A novice programmer, seeking to imitate him, also began to write unstructured programs. When the novice asked the master to evaluate his progress, the master criticized him for writing unstructured programs, saying, ``What is appropriate for the master is not appropriate for the novice. You must understand the Tao before transcending structure.''

    The Tao gave birth to machine language. Machine language gave birth to the assembler.

    The assembler gave birth to the compiler. Now there are ten thousand languages.

    Each language has its purpose, however humble.
    Each language expresses the Yin and Yang of software.
    Each language has its place within the Tao.

    But do not program in COBOL if you can avoid it.

  • by rela ( 531062 ) on Wednesday January 29, 2003 @03:11PM (#5183821) Journal
    This has been up, what, 15 minutes, and already all I can see is posts bashing his use of feminine pronouns. No comments on the text itself? It's got some good points that would apply to working on any kind of project, not just programming.

    I especially like:

    There is a lot of room for miscommunication about estimates, as people have a startling tendency to think wishfully that the sentence:

    "I estimate it might be possible if I really understand that problem that it is about 50% likely to be completed in 5 weeks if no one bothers us in that time."

    really means:

    "I promise to have it all done 5 weeks from now."

    Heh heh heh...

  • Twaddle! (Score:3, Informative)

    by OldCrasher ( 254629 ) on Wednesday January 29, 2003 @03:13PM (#5183836) Homepage
    The script reads like a collections of untruths, half-truths, whinings, myths and philosophical twaddle. The person writing it does not have the experience to write it, nor the insightfulness to realise they should just put up and get back to work. Clearly written after too long a session in front of the glowing tube.

    The Glossary is outright wrong; maybe it's the footnote from some SNL show on educational tom-foolery?

    This rambling, ill-thought out work would be a terrible handicap to some junior scholar thinking they could read this and jump into the big pot we call IT.

    I guess if it gets published the author can collect their royalties. My advice to those that ask me, and many do, will be to avoid this like the plague.

    Well, I guess I just sank my Karma!
    • I agree completely (Score:4, Interesting)

      by Celandro ( 595953 ) <celandro&gmail,com> on Wednesday January 29, 2003 @04:57PM (#5184671)
      The biggest clue that the writer has no clue about computer programming is his statement that 50 hour weeks are typical and 60 hour weeks are his limit. If you are writing code for more than about 2 hours a day, you are writing bad code that is horrible and buggy. I always try to explain what I do to people as very complicated math homework. Noone can actually do math homework for 60 hours a week. It is far too draining.

      The majority of most programmers days at work is spent processing ideas in the back of their heads while they do other things (like post on Slashdot). The 2 typical tasks in programming, adding a new small feature to an existing program and debugging a bug are about 100 lines of code and 2 lines of code respectively. These would take in theory half an hour and 2 minutes respectively. But as the old story goes, its knowing which $1 component to replace in the $1,000,000 machine that costs the $10,000. So it is in programming.

      Knowing how to integrate the new features and bug fixes without horribly ruining the existing design is the mark of a good programmer. Actually coding the fix or feature once it has been designed (on paper or in your head) is trivial. Overworking yourself leads to bad design and more bugs, which take even more of your overworked self to fix. This escalating behavior leads to burnout as well as the human brain can not spend that much time working on difficult problems every single day.

      Anyhow, now that my brain has figured out how it wants to implement the new feature Im working on, while writing this comment, its back to work to toss out my 100 lines of well designed code. If my writing seems confusing or poorly structured, its because my brain was working on code design, not paragragh design.
  • by Hirofyre ( 612929 ) on Wednesday January 29, 2003 @03:18PM (#5183869)
    Another good reference for this type of info is The Pragmatic Programmer [barnesandnoble.com]. It lays out how to write flexible, dynamic, and adaptable code, as well avoiding traps that a lot of new programmers fall into. It takes the time to explain the "why's" behind a lot of the engineering approaches advanced programmers take. It is definitely aimed at "junior" programmers, though. Usually when we get someone just out of collage, I point them to this book.
    • I was just out of collage once. And a good think too, the Elmer's glue was starting to get on my nerves. Though I did have to walk aroung with bits of magazine stuck to my sides for a week or so. ;)
  • by AbbeyRoad ( 198852 ) <p@2038bug.com> on Wednesday January 29, 2003 @03:19PM (#5183873)
    Most programmers are not female. Using "She" makes
    the work sound peculiar and unprofessional. It
    implies a anti-sexist bent which has nothing to
    do with the subject matter. Either write things
    in passive verse to avoid pronouns, use "they" or
    in the few cases where you really need to, use
    "he". Anyone who thinks this is sexist has a
    problem which your essay is not here to
    • Anyone who thinks this is sexist has a
      problem which your essay is not here to

      Anyone who thinks that using female pronouns is unproffessional has a sexist bent that really shouldn't be pandered to. One reason why women avoid programing might just be that everything they read about it reminds them that women are not supposed to program.

      Personally I think it is quite healthy for authors to remind themselves, and their readers (especially if those readers are typically male), that women exist as well and that they also might be interested interested in reading what the author has to say.
  • I know this is going to be way offbeam for most people, but one of the first things I was struck with is the fact that guy lives on Norris Drive here on Austin, Texas, which is on the same street the guy who runs Adventures in Crime & Space science fiction bookstore [crimeandspace.com] lives. (In fact, I've occasionally gone over there to pick up some books.)

    This is where I would cue up "It's a Small World After All," were it not for the fact that Disney would sue me if I did so...

  • Cheez-Wiz, this paper doesn't sound anywhere as glamorous as those 'Lincoln Tech" ads on late night television promising me millions of dollars and pretty women. Foo!

    Actually, it is interesting to see he starts out with debugging -- how many of us have seen wanna-be programmers come and go when the project hits the dreaded maintenance cycle. Provided of course they can make it through the Yourdon-esque death-march [yourdon.com].

  • Just downloaded it, only skimmed the contents so far, but he seems to be trying to cover a load of stuff that isn't directly related to programming, and, in addition, is highly context-specific. For example, do all programmers have a team for which they have any responsibility? Do they all get involved in the quoting process? I wonder whether a couple of pages on how to negotiate a contract is worse than nothing at all...

    • I'm sorry, but even I (a female programmer) had to snicker at your Subject line given the abundance of the female pronoun in this article.

      Did you pun intentionally?


  • Some quotes from the first few paragraphs:
    "I confine myself to problems that a programmer is very likely to have to face in her work."
    "Even if she is perfect, she is surrounded by..."

    Considering that the female to male ratio in this business is something close to 1 to 100 and that some of us can still work many years in the field without ever meeting a female programmer, I found that somewhat amusing. But I guess it gets boring pretty quick, reading he talk about a generic "she" no one will ever meet...
    • I have to agree. Why can't people just accept that in English the pronoun "he" is used for both male and undetermined gender. Instead, the author uses "she" as a pronoun, which, in normal, non-PC usage, refers only to females. It annoys me to the point of distraction. At the very least, he could have used "he or she" or, if that would add too much to book length, "s/he" might have been a more acceptable alternative. Personally, I avoid buying books where the author is obviously trying to be PC just for book sales, especially in a male-dominated industry.
  • Uhm (Score:2, Funny)

    by Garen ( 246649 )
    "... programmer does not live in an ideal world. Even if she is perfect, she is sur-
    rounded by and must interact with code written by major software companies,
    organizations like GNU, and her colleagues."

    Yeah, right. Next.
  • by KIngo ( 168933 ) on Wednesday January 29, 2003 @03:32PM (#5183984)
    I thinks his comments on dealing with performance problems are especially helpful, even for experienced programmers. Most decent programmers know how to debug, but few programmers excel in tackling performance problems. I've found that profiling is a very fruitful activity even if there are no obvious performance problems, because it provides tremendous insight into the runtime behavior of your applications. Things are often very different from what you would guess intuitively.

    If you happen to work with Java, there are quite a few good commercial profilers around that are really easy to setup and use (such as JProfiler [ej-technologies.com] or Optimizeit [borland.com]). Try working with one of these for some time and observe how your way of programming changes for the better. Most importantly, you learn not to pre-emptively "improve" performance - one of the deadliest sins of programming which is responsible for a lot of bad and unreadable code.

  • by T-Kir ( 597145 ) on Wednesday January 29, 2003 @03:40PM (#5184032) Homepage

    ...Is to use this site [mindprod.com] as your programming bible :-P

    It is a *must* read for any budding or experienced programmer! (You might split your sides from laughing too much).

  • by ggruschow ( 78300 ) on Wednesday January 29, 2003 @03:48PM (#5184096)
    I like this quote from the document:

    "Life is too short to write crap nobody will read. If you write crap, nobody will read it."

    As I read through the comments here, it's apparent that virtually none of the posters clicked on the link much less read the document, and a good 90% of them didn't even read past the posting title.

    Anyway, the article touches on good points, but it's very clear where the author has personal experience with something and where he doesn't. Some of those times he starts to sound like the books he recommends (all excellent recommendations). Other times (e.g. 4.1. How To Stay Motivated), he simply states something that would be good, but doesn't describe how it should be done.

    He recommends "Succinctness is Power" by Paul Graham. Given the document's spottiness, he probably should've gone alnog those lines instead. Written down a little ditty about why you should read the material, and then his list of books and articles to read on how to be a programmer.

    If half of the programmers I've known had read his recommended list, I'd have a hell of a lot more trouble staying far enough ahead to have time to review articles and post on slashdot.
  • Chop the tree down! (Score:2, Interesting)

    by czth ( 454384 )

    It looks fairly sensible, but the main problem is that (1) good programmers know these things and (2) bad programmers usually can't or won't learn. This makes the audience pretty narrow, i.e., inexperienced programmers with decent raw skills.

    And this bit made me laugh (2.5):

    What do you do when you start to run out of low-hanging fruit? Well, you can reach higher, or chop the tree down.

    It just seems like a funny metaphor (picture it in your head, chopping down the tree is sort of overkill just to get more fruit :), although I understand what he's getting at.


  • by DG ( 989 ) on Wednesday January 29, 2003 @03:55PM (#5184148) Homepage Journal
    I've been coding in an enterprise environment for quite some time now, and I have one rule that is cast in gold:

    Always optimise source code for legibility above all else. Never trade legibility for performance unless you have no other choice, and then document your cleverness in the code so that those who follow behind you can keep up.

    Here's why:

    When you first write a system, it will spend its first few months of life in a very intensive quality control feedback loop. Bugs are found and very quickly exterminated. The code is still fresh in your mind and you're "in the zone".

    But as the system stabilises, there is less and less reason to go back to the code, so that freshness wears off. After a little while, other priorities will take over and the internal model of the code will fade away.

    But there's still bugs in there - there always is. But any bug that makes it past the first few months is non-obvious, intermittant, rare, and so on (thus, harder to find)

    When one finally surfaces, _somebody_ is going to have to fix it. Sometimes it will be you, and you will appreciate code legibilty when you have to dust off source that has laid untouched for years. Not only does it increase the probability that you'll be able to actually find the bug, it cuts down on the time needed to fix it.

    There's nothing like being the guy who finds and fixes bugs within seconds of them being pointed out to enhance your reputation.

    But more often than not, it will be some other poor sap who gets saddled with your code and a deadline to get it fixed - and the guy who draws the short straw is normally not the biggest brain in the shop. There is no gratitude like the gratitude from someone forced to dive into somebody else's code, and who subsequently discovers that you have gone out of your way to make it easier for them to understand.

    This is _also_ a reputation enhancer. "That code was so well written that not only did it take no time at all to track down the bug, but I also learned a couple of new techniques in the process!"

    The true guru is a TEACHER.

    Oh, and ALWAYS check the return code from every system call and provide appropriate error trapping. That's good too.

  • One big thing... (Score:5, Insightful)

    by dasmegabyte ( 267018 ) <das@OHNOWHATSTHISdasmegabyte.org> on Wednesday January 29, 2003 @03:56PM (#5184158) Homepage Journal
    Be prepared to be wrong.

    Be prepared to be proven stupid, to go in the wrong direction and have to forget it, to bust your ass for weeks only to discover you're doing it the dumb way.

    Be prepared to take criticism at this point, to learn the right way and actually practice it, to laugh at yourself and to not gloat over your fellows when they make the same mistakes. After all, the next time you do something dumb, they're the onces who will be pointing it out.

    These are skills that will get you by in any field, but in programming they'll save your ass.
    • by betis70 ( 525817 ) on Wednesday January 29, 2003 @04:35PM (#5184475) Homepage
      One thing I have learned is to not invest a lot of prideful ownership in a particular design decision I make. When reviewed by the team, it invariably gets modified somewhat, sometimes outright rejected. Taking ownership of a subproject (in my case) is one thing, but you have to be malleable enough to "give them what they want". Otherwise you end up beating your head against a wall.

      Oh and lose any aversion to eat crow is also a good idea. At some point you will pronounce "There is no way I made that mistake" only to see your log-in in the RCS/CVS log.
    • by droleary ( 47999 ) on Wednesday January 29, 2003 @05:00PM (#5184698) Homepage

      Be prepared to be wrong.

      Ah, now you've gone and reminded me of my favorite interview moment. The manager sat smugly behind the desk and asked me the age old "What do you consider your greatest strength?" to which I promptly replied "I like to be wrong."

      The look of horror on his face spoke volumes, both of what he no doubt thought of me, and of exactly why that wasn't the kind of company I'd want to work for. I couldn't get out the door fast enough, and he couldn't wait to see me go. So I highly suggest doing the "brimming over with wrongability" thing right off the bat. :-)

  • by Knacklappen ( 526643 ) <knacklappen@gmx.net> on Wednesday January 29, 2003 @03:57PM (#5184168) Journal
    4 years ago, I (Mechanical Engineer, major in Design Engineering) was involved in a bigger software project: Building a modular simulation system for vehicles, based on a database and a Multi-body code with output to Excel and lots of fancy stuff in between to make it all work. Since the customers and users were the people from our Design Dept, i.e. Engineers, I asumed that they would have thought through all the specs and that we basically just had to start.
    Big mistake! Being good and great Design Engineers in the mechanical and electrical domain, regarding software they were as clueless as any Marketing Drone. Whenever we tried to extract specifications, all we got was "make it work like that old APL code we have, but better and more modern and let is calculate/simulate more correct results". Aaaarrrrggggghhh...
    Unnecessarily to mention, that only very few actually knew how the old system worked and under what assumptions it was built.
    Well, we boxed our way through and today I am the only person in the company that has the total insight (the other 2 left). Unfortunately, we were never given time to properly document the system (of course the code itself is quite well documented but there is more to do than just that). In my naïvité I thought that the Design Dept with their fixation on drawings and Supplier Specs and Purchase Reservations and Engineering Change Notices should understand the value of proper documentation...
    A reflection I can now make: Hiring us Design Engineers to make the work instead of professional Software Engineers was probably the only way for the company to get the job done within reasonable time & budget. Non-existent specs, poorly understood assumptions for certain calculations - what a nightmare for any professional software developer!
  • as well as everyone here... treat your peers with respect. A real programmer has nothing to prove.
  • Using the masculine sense for the indefinite article is correct. I don't know about you but all that 'she must do this with her whatever' stuff is quite distracting.
  • by Catamaran ( 106796 ) on Wednesday January 29, 2003 @04:23PM (#5184369)
    Three virtues of a programmer

    The Camel book contains the following entries in its glossary:
    1. Laziness
    The quality that makes you go to great effort to reduce overall energy expenditure. It makes you write labor-saving programs that other people will find useful, and document what you wrote so you don't have to answer so many questions about it. Hence, the first great virtue of a programmer.

    2. Impatience
    The anger you feel when the computer is being lazy. This makes you write programs that don't just react to your needs, but actually anticipate them. Or at least pretend to. Hence, the second great virtue of a programmer.

    3. Hubris
    Excessive pride, the sort of thing Zeus zaps you for. Also the quality that makes you write (and maintain) programs that other people won't want to say bad things about. Hence, the third great virtue of a programmer.
  • by mekkab ( 133181 ) on Wednesday January 29, 2003 @04:40PM (#5184523) Homepage Journal
    In my frosh year Calc II class in undergrad,
    the first day they handed out a little thing written in LaTex about how to be a math student.

    It was great, because it had a lot of obvious stuff in it.

    I think this text would do the same thing for an "Intro to Comp Sci" class in undergrad, or every Comp Sci class that first semester freshman can take.

    And it can be much more than that. It is almost like a self-help book for programmers; a "Chicken Soup for the Coder's Soul" if you will!

    I'm only half way through, but I like what its saying.
  • ah.. (Score:5, Funny)

    by labratuk ( 204918 ) on Wednesday January 29, 2003 @04:56PM (#5184669)
    "How to be a Programmer"

    A new book by Microsoft Press.

    Step 1: Bend over.
  • Really, (Score:5, Funny)

    by sstory ( 538486 ) on Wednesday January 29, 2003 @05:19PM (#5184900) Homepage
    I'd like to see a pdf article called How Not to Be a Huge Dork. I'd carry it around, and give it to 50% of the Comp Sci guys I know.
    Then we could work on distributing other files, like How to Shower, How to Not Wear Stained Star Wars T-shirts every day, How to Not Have Religious Wars about Trivial Things...
  • Feedback (Score:5, Interesting)

    by Ninja Programmer ( 145252 ) on Wednesday January 29, 2003 @05:46PM (#5185106) Homepage
    Here's some feedback.

    Re: Divide and Conquer debugging approach ...

    Knowing *where* to split requires less skill than he suggests. While binary-splitting is useful from an algorithmic point of view, in the arena of debugging, there is no reason to be binary. I will typically split the problem many times (8 or more) at each step. This observes the fact that usually the cost of splitting the code is much less than re-running the scenario to test to see which split it makes it past, or fails to run properly.

    Neglecting examples in the debugging section is bad. In particular miss-synchronization of multi-threaded applications is an example that should be shown.

    Re: 2.6 How to Optimize Loops

    Ok, this is a really short list, and it misses the important principle of "caching", and some of the suggestions are wrong, or typically inconsequential.

    1. Sometimes floating point can actually be faster than integer code. This is especially true if the code can be completely pipelined. In particular trying to change from floating point to fixed point algorithms in modern CPUs may actually *decrease* performance. The details of this requires a lot more discussion.

    2. Inlining will be ineffective if the function routine is too large, or if the procedure prologue/epilogue cost is either low or unremovable.

    3. Fold constants together -- you should be more explicit about what you mean here. Certainly sub-expression elimination is a common technique that usually works well (but compilers are pretty good at finding that for you) but in some CPUs like the x86, immediate absolute value operands are practically cost-free. Perhaps he means "hoist" whenever possible? That certain does help.

    4. As to moving I/O into a buffer ... there is even more you can do. Move I/O handling to a seperate thread (more on this in my next comment.)

    5. Try not to divide and avoiding expensive casts requires much more detail. The best thing to say here is the understanding these costs requires understanding the underlying machine code that results from these operations. (Floating point division can actually be relatively cheap in the right context, and differentiating between cheap and expensive casts can sometimes be difficult, and require context as well.)

    6. Using pointers rather than indicies -- x86's have sophisticated addressing modes wherein there is commonly no difference between these two alternatives.

    Re: 2.7 How to Deal with I/O Expense

    An important principle to apply is to realize the parallelism via multithreading can substantially assist these problems. For example if some IO is non-negotiable, or non-predictable, then at least it can be blocked, or streamed in a seperate thread. The reasoning behind this is that modern operating systems can yield (i.e., block) program control (i.e., your execution resources) from a slow to respond thread to the faster ones. So you can overlap all your algorithmic work with the delays while waiting for the data.

    Re: 2.8 How to Manage Memory

    Something should be said about caching versus non-caching. First of all, point out the cached memory can be tens to hundreds of times faster than main memory (in modern CPUs.) Variables on your local stack, and globals that are commonly used in your inner loops, will tend to be cached. However array streaming will tend to de-cache your data.

    Running through your streamed data in multiple passes is especially bad, as it will require reading your data into the cache multiple times.

    Again much more can be said here.

    Re: 2.9 How to Deal with Intermitten Bugs

    This is an important topic. Its because it represents the hardest debugging problem. We all run into it sooner or later. Even if it is a hard subject to tackle, it has to be expanded on. Giving examples here are invaluable. You have to show that as hard as it is, it is possible to ferret out such bugs.

    Re: 2.10 How to Learn Design Skills.

    The biggest thing to explain here, I think, is to just explain that all code can and should have seperate documentation corresponding to it, that is written *before* the actual code is written.

    Re: 3.6 How to Work with Poor Code.

    Remember that people may be more open, or willing to learn than you think. If you decide you have to recode something for someone, it may be beneficial to be explicit about this and show them the results. But for such a thing to be effective, and to get over any potential ego problems, you have to make sure the rewrite is absolutely, clearly, obviously better (it should be shorter and more easily readable.) Your goal should be to make sure the programmer that is the target of the rewrite, considers the results to be a better approach that is worth emulating themselves. (Give a man a fish ...)

    Section 3.7 needs to be tied to the last paragraph of section 2.1. Scribbling over some "pristene" (sp?) code is irrelevant if you can easily recover it (which you can with good source control.)

    Re: 3.8 Unit testing -- my experience with this is a bit depressing. Unit tests always start out being a good thing, but over time, they are an extreme PITA to maintain. Unit testing is a good thing for what I consider *totally generic modules*. The reason being that truly generic modules do not evolve over time, while other code invariably does.

    Unit testing can only be effective if there in an enforced automated testing mechanism. I.e., a failure causes an automatic and non-negotiable rejection of code checked into the tree. I have found it remarkably difficult to convince people that such a policy is worthwhile. (SGI used to use such a mechanism, and, of course, it worked wonderfully for them.)

    Section 3.9 and 2.4 Belong together. How is 3.9 a team skill?

    Re: 5.2 How to Manage Third Party Software Risks

    In my experience, this is trivial -- rely on track record. Its more indicative than anything else. If the software has already shipped and has a history, then there is no problem. If it has not yet shipped (and you are hoping that it will in time for you to use it), then you are going to get version 1.0 software at best and more likely you are providing a beta test environment for the third party developer. Just put yourself in the shoes of the third party developer. In what way will they maximize the take away from their involvement in a relationship to sell you software? Remember business relationships can tend to dominate technical ones.

    Re: 5.4 How to Communicate the Right Amount

    In here you write: It costs its duration multiplied by the number of participants. Please underline and boldface this. It amazes me how managers don't understand this.

    Re: 6.1 How to Tradeoff Quality Against Development Time

    Remember that a good *design* will be resilient against poor code implementations. If good interfaces and abstractions exist throughout the code, then the eventual rewrites will be far more painless. If its hard to write clear code that is hard to fix, consider what it is wrong with the core design that is causing this.

    Re: 6.2 How to Manage Software System Dependence

    The harps back to a concept I referred to above as *totally generic modules*. These are just libraries that provide useful functionality and can take input without making any non-trivial assumptions, and contains no dependencies whatsoever.

    An example of this is the C run time library. A good example that will help make this clear is that the C run time library is able to provide a quicksort implementation without knowing anything about the underlying array it is sorting.

    State-less, assumption-free, zero-dependency code is very valuable. Its maintenance and development will be finite in cost, while its utility is on-going. Imagine the cost of rewriting the C library every time you use it.

    Impressing this upon programmers will help them recognize the value of reducing dependencies.

    Re: 7.2 How to Utilize Embedded Languages

    Ony option you seem to have avoided is the possibility of embedding pre-canned languages. The real problem with embedding a language is that useful language design is harder than you might think at first. People's aversion to using/learning it is bad enough, what happens when they uncover a flaw in your language that is fatal to its design? People who design real languages put a lot of work in them, that cannot be trivialized. Whipping up an embedded language is unlikely to yield the most stellar results.

    That said, there are currently numerous options for embedded other pre-canned languages. Python, Lua and Ruby come to mind. Before going off on some adventure of trying to design your own language, consider whether or not you are going to be able to do a better job than what you could do by embedding one of these languages. From my personal experience, I can tell you that Lua can be embedded in a few hours, and has probably the smallest learning curve of any language in existence.

  • by rufusdufus ( 450462 ) on Wednesday January 29, 2003 @05:49PM (#5185126)
    How to be a Professional Programmer:
    Demand to get paid for your work.
  • by kenthorvath ( 225950 ) on Wednesday January 29, 2003 @05:59PM (#5185198)

    One day a Novice came to the Master.
    Master, he said, How is it that I may become a Writer of Programs?.
    The Master looked solemnly at the Novice.
    Have you in your possession a Compiler of Source Code? the Master asked.
    No, replied the Novice. The Master sent the Novice on a quest to the Store of Software.

    Many hours later the Novice returned.
    Master, he said, How is it that I may become a Writer of Programs?.
    The Master looked solemnly at the Novice.
    Have you in your possession a Compiler of Source Code? the Master asked.
    Yes, replied the Novice.
    The Master frowned at the Novice.
    You have a Compiler of Source. What now can prevent you from becoming a Writer of Programs?.
    The Novice fidgeted nervously and presented his Compiler of Source to the Master.
    How is this used? asked the Novice.
    Have you in your possession a Manual of Operation? the Master asked.
    No, replied the Novice.
    The Master instructed the Novice as to where he could find the Manual of Operation.

    Many days later the Novice returned.
    Master, he said, How is it that I may become a Writer of Programs?.
    The Master looked solemnly at the Novice.
    Have you in your possession a Compiler of Source Code? the Master asked.
    Yes, replied the Novice.
    Have you in your possession a Manual of Operation? the Master asked.
    Yes, replied the Novice.
    The Master frowned at the Novice.
    You have a Compiler of Source, and a Manual of Operation. What now can prevent you from becoming a Writer of Programs?.

    At this the Novice fidgeted nervously and presented his Manual of Operations to the Master.
    How is this used? asked the Novice.
    The Master closed his eyes, and heaved a great sigh.
    The Master sent the Novice on a quest to the School of Elementary.

    Many years later the Novice returned.
    Master, he said, How is it that I may become a Writer of Programs?.
    The Master looked solemnly at the Novice.
    Have you in your possession a Compiler of Source Code, a Manual of Operation and an Education of Elementary? the Master asked.
    Yes, replied the Novice.
    The Master frowned at the Novice.
    What then can prevent you from becoming a Writer of Programs?.

    The Novice fidgeted nervously. He looked around but could find nothing to present to the Master.
    The Master smiled at the Novice.
    I see what problem plagues you. said the Master.
    Oh great master, please tell me. asked the Novice.

    The Master turned the Novice toward the door, and with a supportive hand on his shoulder said, Go young Novice, and Read The Fucking Manual. And so the Novice became enlightened.

  • by FuzzyDaddy ( 584528 ) on Wednesday January 29, 2003 @06:04PM (#5185234) Journal
    You should at a minimum give the candidate the equivalent of an oral ex- amination on the technical skills for two hours. With practice, you will be able to quickly cover what they know and quickly retract from what they don't know to mark out the boundary. Interviewees will respect this.

    This is right on - the jobs I've been most attracted to are the ones where they asked me the most technical questions. I'm surprised how little of this sort of questioning many people do when hiring. When I'm interviewing people, I try to put them through their paces as much as possible.

    I had one engineer help me take apart a vacuum feedthrough, clean it, and put it back together. She jumped right in and did it. I offered her a job on the spot.

  • by waimate ( 147056 ) on Wednesday January 29, 2003 @10:11PM (#5186768) Homepage
    Something many programmers fail to understand is exactly why they are given their monthly pay cheque. It's not to write great code, or to do clever things, or to be the only one who can solve problems when they occur. It's to bring about a business benefit.

    Your employer may make widgets, or run delivery trucks, or process financial transactions, or manufacture cars. Your goal is to help in that process.

    Programmers can have a tendancy to be easily "disconnected" from the mission of employer, and can think the goal is to write some cool Java, or to make the source code library work better. Yes, that's the job at hand, but it's not why they pay you each month. They pay you to help them build cars and sell them at a profit. It's an important thing for programmers to have at least somewhere in their conciousness.

  • by master_p ( 608214 ) on Thursday January 30, 2003 @04:50AM (#5187923)
    Guys, there is no holy grail guide for being a good programmer. It's all down to a person's abilities to understand the system overview as well as the local details of each subsystems and how those subsystems corellate to each other and how they affect the overall progress of the total system.

    I've seen quite a few programmers. The best ones are those types that are really interested in the programming concept, and what makes a program beautiful. Once these concepts are understood, then the programmer ceases to be interested in using the latest and greatest features of the underlying development environment and only cares to leave behind a system that works, is easy to expand and debug and easy for others to understand.

    A key point to being a good programmer is understanding why an API is bad or good and why the programming language X is better than the programming language Y for project Z. I may not be a good programmer, but I really understand why MFC sucks and why WxWindows is better and Qt the best; or why Visual Basic sucks as a programming language, C and C++ are difficult languages but the most rewarding and why Java is better for most projects(of course this is my opinion and you don't have to agree or disagree, I just mention it here as an example of the issues a programmer has to understand).

    But all these are down to personal interest and abilities rather than some guide that people can follow to become successful. I guess this is true for every profession, but it is more important in programming.

    All these have a direct impact on the social aspect of the programmer job. A programmer that cares more about programming than others may initially be more drawn to his/her computer rather than to the social interaction with his/her colleagues, but in the end that person will have a much better understanding of what is going on and be a much better candidate for a job that is higher in the company's pyramid (manager, engineer, architect).
  • ...have a huge ego (Score:3, Insightful)

    by zitsky ( 303560 ) on Thursday January 30, 2003 @11:49AM (#5189675) Homepage
    Flame suit on...

    I found his paper interesting for the most part. It's very helpful in giving new programmers an idea what to expect.

    Is it just me, or does this guy seem to have a huge ego? I've worked with enough programmers to know there are good and bad ones, easy going and egotistical ones. He seems to have a pretty low opinion of "non-engineers", by which he means non-programmers as opposed to mechanical engineers, electrical engineers, etc.

    My favorite section is "How to talk to non Engineers".

    Non-engineers are smart, but not as grounded in creating technical things as
    we are. We make things. They sell things and handle things and count things
    and manage things, but they are not experts on making things.

    They are not as good at working together on teams as engineers are (there
    are not doubt exceptions.) Their social skills are generally as good as or bet-
    ter than engineers in non-team environments, but their work does not always
    demand that they practice the kind of intimate, precise communication and
    careful subdivisions of tasks that we do. Their teams are more like groups.

    Non-engineers may be too eager to please and they may be intimidated by
    you. Just like us, they may say yes without really meaning it to please you or
    because they are a little scared of you, and then not stand behind their words.
    Non-programmers can understand technical things but they do not have
    technical judgment. They do understand how technology works, but they cannot
    understand why a certain approach would take three months and another one
    three days.

    It's obvious to me when an engineer has this attitude. They usually come across as cocky and condescending. I find that if you treat your coworkers with respect, and assume they have a clue, that your working relationship will be much better for doing it.

    I have a B.S. degree in Comp. Sci. but work as a sysadmin now. Everyone knows that without sysadmins like me, everything would fall apart, and engineers would never get anything done. Ask me how many times I've had to fix an engineer's CVS repository because they didn't have a clue how it worked. ;-)

    I think engineers/programmers need to have more appreciation for their fellow technical workers. Maybe I'm just being sensitive, but last time I checked, my job required building things & fixing problems (complex server systems, and repairing many system level and code level problems). I also have to do job estimation with a good understanding of the technical merits of different approaches.

    And, I hate to disappoint everyone.... but non-engineers are not eager to please or intimidated by you... They might just be too polite to laugh at you to your face when they see how big your ego is getting. ;-P

    The best engineers I worked with were extremely bright, did an excellent job, and were very good at getting along and working with everyone, whether engineer or sales rep. They were recognized by everyone, technical and not, as our best engineers. Everyone knew they were the core of our company. I would break my back to get those guys what they needed, because they treated me as an peer, and respected my own expertise.

    The worst engineers I've dealt with had egos bigger than the buildings they worked in, and chips on their shoulders almost as big. Those were the type I stayed away from. They were also the type that insisted their ideas were right regardless of the facts.

    The last jackass engineer/programmer I worked with insisted our company of 50+ people didn't need a corporate firewall "because we use Windows development systems, and Windows software is secure". And this guy was our most Senior Engineer, I am NOT making this up.

    Well, thanks for letting me get that off my chest!!

The amount of time between slipping on the peel and landing on the pavement is precisely 1 bananosecond.