in reply to Re^2: Where are future senior programmers coming from?
in thread Where are future senior programmers coming from?

That's certainly true, about bad habits, tilly. Ego is another issue that can be poisonous. My personal experience is that the need to solve problems on multiple levels does more good -- by a large measure -- than the bad habits do harm, and I'll comment more about ego down below.

My definition of greatness (or 'senior programmer' status) is based far more on one's ability to gauge what parts of a problem are worthy of more applied brilliance than others. That does not appear to be yours, though. You seem more concerned with ability to work to an API defined by a team and write elegantly maintainable code. These are admirable traits in my book also, but (honestly) I've never worked much in group development environments. I am, I suppose, much more a rough-and-ready programmer with lots of odious habits. ;-]

As for your 'group shop', if we turn it around, how many kids are you (collectively) mentoring? We all know that you can generally write code faster than you can explain menial coding tasks suitable for learning experiences. If you're not supporting some, you're making my point: that small-to-medium groups cannot support mentorship opportunities, and big ones are not worthy learning environments. I heartily agree with another responder who said that many bigger shops have dead-end programmers who can't shine a dog's @ss. One of the reasons I rarely get in to larger shops is that those are the ones who get chosen to give interviews. ;-]

Be that as it may, I don't disagree with anything you've said, but I stand on my case that anyone sharp enough to survive the hot seat is capable of learning to code defensibly and in a shared environment. The ego is the sticking point. They can, but will they? It took me a lot of years to learn humility. I never wore my ego on my shirt, but it was definitely riding on my shorts. I "knew" I could solve anything in programming, given tools and time. Now, at least I know that not all problems are made of bits and neither are all solutions. :D

I never really had a mentor, because I was a better coder and analyst than anyone I worked with, but I did have some good (non-programming) teachers who were proud to point me towards the prize rather than the competition. I guess that's the real key in integrating a team member: is the achievement worth more to him than the race?

Now, I'm getting to the point in my career where the young guys are definitely better coders than I am. Here in Austin, they grow up speaking C at the breakfast table and C++ at tea. (Perl, of course, takes up Saturday afternoons out in the garage). However, I'm still valuable because of that early seminal training in recognizing the prize. It isn't really about how much syntax you can crunch before noon, but rather how much closer you get to release by 5.

Don Wilde
"There's more than one level to any answer."
  • Comment on Re^3: Where are future senior programmers coming from?

Replies are listed 'Best First'.
Re^4: Where are future senior programmers coming from?
by tilly (Archbishop) on Sep 07, 2006 at 23:04 UTC
    I am somewhat puzzled where you're getting your impression of my priorities from. For one thing, they're off by quite a bit. For instance while I'd hope that a junior program could code to an API and standard that someone else has developed, I'd never judge a senior programmer on that skill. Instead I'd want them to be good at things like inventing APIs that I'd want to use. The ability to work with someone else's API is like the ability to walk and chew gum - I'd take it for granted.

    About what you value in "great programmers", I'm unsure what you mean by "applied brilliance". Largely that's because there are plenty of things that I consider routine that others consider to be brilliance. Why I like functional programming is a good example. I have no idea what your standards are.

    However, no matter what your standards are, I sincerely believe that you are mistaken to focus on what are probably just flashy hacks. In every field that I know of, when you talk to the best people, they stress the importance of getting the fundamentals right. That holds true whether you're talking about playing a musical instrument, playing a sport, or even an intellectual discipline such as mathematics. (See The path to mastery for a story from mathematics.) And, believe it or not, I've encountered the same attitude from the best programmers that I've seen.

    For instance take the best-known example of a truly flashy "mad genius" programmer in the Perl world. That would be TheDamian. Can we agree that he really is a great programmer? Now go look at the most widely recommended book that he has written. That would be Perl Best Practices. What is it? It is a detailed analysis of apparent minutiae, like whether you should format code with the + signs before or after a line break if you had to break the line. (The answer to that one in Perl is on the next line, BTW.)

    The fact that he was willing to put a tremendous amount of energy into considering issues like this, and that the resulting book is valued highly by so many top-notch programmers, speaks volumes to me about what is important in programming. Namely that fundamentals count. You might not always start by learning fundamentals, but somewhere along the way you need to pick them up. And then you layer knowledge on top of that. Some day as you take the natural approach to a problem you'll see blank stares from people who do not have the background to understand what you're doing. While that can be fun, you get there by getting the fundamentals right.

      I wouldn't disagree with anything you've said about the fundamental disciplines of programming. The only thing I'd re-stress is that "getting" the big picture is the most important skill of all.

      Don Wilde
      "There's more than one level to any answer."