Beefy Boxes and Bandwidth Generously Provided by pair Networks
Keep It Simple, Stupid

Questions from "Coders at Work"

by bsb (Priest)
on Oct 17, 2009 at 08:15 UTC ( [id://801727]=perlmeditation: print w/replies, xml ) Need Help??

I'm currently enjoying "Coders at Work - Reflections on the Craft of Programming", by Peter Seibel. It's a series of reflective interviews with various guru progammers. There's a few recurring questions which I thought might be fun for the monks to answer.

  1. Are there books every programmer should read? Have you read The Art of of Computer Programming by Knuth? Cover to cover? (books)
  2. Have you tried literate programming? Have you ever proved your code correct? (literate/proofs)
  3. To what degree is mathematics and mathematical thought important to programming?(maths)
  4. How to you get familiar with a substantial piece of someone else's code? Do you step through it? Have you read code for fun? What? (code reading)
  5. How do you prepare to code something new? How do you actually begin coding, top-down, bottom-up, tests, interfaces..? (new code)
  6. What makes a good programmer? If you are hiring programmers, what do you look for? (hiring)
  7. Have the skills changed required to be a good programmer changed? Are there key skills programmers must have? (skills)
  8. Do you think of yourself as a scientist, engineer, craftsman, artist or something else? (scientist..)

There's lot's more to ask, but I'll stop there

Update: added labels, just the numbers was confusing.

Replies are listed 'Best First'.
Re: Questions from "Coders at Work"
by roboticus (Chancellor) on Oct 17, 2009 at 16:26 UTC
    1. I've read volume 1 cover to cover, and skimmed through a few sections of volumes 2 and 3. I thought it was interesting, and a worthwhile purchase (at the time), but wouldn't recommend it. I've got bookshelves of stuff, but the titles that I'd recommend include:
      • The dragon book I find that knowing how a compiler works has really improved my understanding of the computer. (Of course, starting out with simple computers also helps!.)
      • Data Structures and Algorithms Aho, Hopcroft, Ullman
      • Algorithms in C Sedgewick
      • No Bugs! Thielen
      • Algorithms + Data Structures = Programs Wirth
      • Debugging the Development Process Maguire
      • Code Complete McConnell
    2. I've tried literate programming, but haven't used it much as the corporate culture of the places I've worked didn't support it. I've never proved my code correct, though.
    3. I think that this question separates the programmers from the report writers.
    4. Generally, I get familiar with other peoples code by rewriting it as I read it. It's not a good way to do it, and I'd like to learn a better way. Usually, I throw away the version I rewrote when I'm done, though I'll add some of my hard-won knowledge into the original as comments.
    5. Once I open my editor, I start outlining my code. The outline ultimately turns into comments and/or function names. I keep outlining until the code is trivial. I also like test-driven coding, so I'm working on an approach to integrate it into my standard method.
    6. Good problem-solving skills, and passion. The first you can evaluate fairly easily by tossing them a few questions and seeing how they respond. The latter is easy to discover by asking them what their favorite problems to solve have been.
    7. The "big picture" skills don't change: You need the passion and talent for problem solving. You need good communication skills to work with your clients. The "little picture" skills (programming languages and such) change frequently enough, but it's unimportant, because you can adjust your skill set as needed.
    8. Yes, yes, yes and "hack". Though which role I'm in depends on what I'm doing. When I'm trying to come up with a better algorithm for performing a task, I find myself in scientist and engineer mode. When I'm doing jobs similar to ones I've already done, I'm in engineer and craftsman mode. I'm in "hack" mode when someone in the business unit asks a question that the system can't answer. Generally, I'd take a chunk of code that uses Spreadsheet::WriteExcel and DBI, perform a few queries from one or more databases, and then create a spreadsheet. When I'm creating tools for me to use in my hobbies, I'm often in artist or "hack" mode.

      I like the idea of learning code by rewriting it. It would be hard work, but probably quite effective.

      Your outlining approach to the development sounds similar to mine, although I tend to scribble on paper for a while first.


        It's really not so bad, since you don't start from a blank slate. I just compile it to make sure it all works and that my development environment is ready. I play with the program a little to see how it reacts. While playing, I make a few test cases so I can compare my "improvements" against the production system.

        Then I start reviewing the code. I don't bother to rewrite the obvious stuff, only the stuff that I need to figure out. Then I rewrite that chunk of code and fine tune it, making sure to test the code.

        Finally, I should mention that when I rewrite, I don't just blow away the chunk of code and write blindly. Some chunks of code are fine, so I can use them as is (though I might move them to a more "sensible" location). So you can do the rewriting fairly quickly, unless you start finding odd mismatches in your test cases. Then it can be a be a bit slow going.

        A case in point is from Uploading pictures - displays only 2 of 12: The code was repetitious, so rather than making myself go blind looking for a subtle difference or missed edit between each repeated block, I added a little code to set up some values and then ran the code to generate my reference output. Then I assumed that all the blocks were the same and turned it into a loop. I then ran the code and compared the output to the original, and there was no difference. The original complaint was that the code acted differently depending on how many items were selected. I didn't see any evidence of problems in my updated code, and he didn't provide a complete example, so I expect the problem was elsewhere, and I left it at that.

      If only 5% of the programmers I deal with on a daily basis had read what you have, I would be a happy man (reading implies understanding here). I am curious - have you read The Pragmatic Programmer? If so, is there a reason it is not on your list?

      Cheers - L~R


        I've not read it yet. But a friend loaned it to me a month ago, and I plan to read it around the end of the month. You're the third person who has mentioned it to me, so I'm looking forward to it.

Re: Questions from "Coders at Work"
by wjw (Priest) on Oct 18, 2009 at 01:37 UTC
    1. Probably, but I would not venture to suggest, and No, I have never read Knuth.
    2. No. My code is correct when it does exactly what I wrote it to do, or pukes gracefully.
    3. I am lousy at mathematics, but use mathematical thought in programming constantly. Programming in my opinion is mathematics.
    4. I read code someone else wrote for two reasons:
      • because it needs to be changed or
      • because I need to learn to do what they already have done.
      I do step through it if at all possible, as the sequence tells me not only what they think but how as well.
    5. I have not read code for fun, but have occasionally had fun reading code.
      • I take what I know and see how far I can get with it
      • then head for CPAN (or similar depending on the environment I am in)
      • Take what I end up with and start boiling it down to subs just to clean up
      • then comment where appropriate
      • then run 'tidy' to smooth things for readability.
      All this while keeping in mind KISS
    6. A good programmer has something to do and gets it done, then makes it maintainable. I look for breadth of knowledge, both in programming and in other areas. I look for someone who likes to learn, but most of all wants to learn by applying.
    7. The one skill all the good programmers I know (and I am not one of them) have is the ability to listen, contemplate what they are listening to, and in doing so, translate that into core questions and the relevant supporting questions. Once the questions are defined, the answers are apparent. I don't think the skills change so much, they are just re-defined every so often, and then re-arranged into new "sets", which happen to correlate with the most recent fad, whether RAD or RUP or ILP or etc...
      • Scientist - No
      • Engineer - Yes
      • Craftsman - Yes
      • Artist - Yes

    Gosh! I can't even count! Eight questions and nine answers! Nope, not very good at mathematics! :-)

    • ...the majority is always wrong, and always the last to know about it...
    • The Spice must flow...
    • my will, and by will alone.. I set my mind in motion
Re: Questions from "Coders at Work"
by CountZero (Bishop) on Oct 17, 2009 at 21:25 UTC
    1. Having learned programming by myself, I have no idea of any book which is an absolute "must have" for programmers. I do have Knuth though and read volume 1 and parts from volumes 2 and 3. Some parts of it are now very much outdated, but the underlying assumptions and ideas are still valid.
    2. I tried literate programming, but it did not sit well with me. Never proved my code correct in a formal way. I do write tests of course.
    3. I'm a lawyer, but with an interest in mathematics and science. Actually lawyers will make good programmers as we are trained to analyse cases, then synthesize a solution and "language" is our main tool. Whether it is "natural" language or computer language doesn't make a bit of a difference. Also lawyers are trained to apply rules (the rules of syntax and grammar of a computer language are much easier to apply than the rules of a code of law).
    4. I rarely had to do that, but I first try to get a broad view of what the code is doing --grokking it as it were-- and then going into details where needed. I only (read) code because I find it fun to do.
    5. No set way of doing it. Most of the time I get a mental picture of the program I need to write and then just start writing it.
    6. I have no idea.
    7. Powers of analysis and synthesis, are in my opinion the major skills needed.
    8. A combination of a craftsman and an artist, but isn't that true for anything?


    A program should be light and agile, its subroutines connected like a string of pearls. The spirit and intent of the program should be retained throughout. There should be neither too little or too much, neither needless loops nor useless variables, neither lack of structure nor overwhelming rigidity." - The Tao of Programming, 4.1 - Geoffrey James

Re: Questions from "Coders at Work"
by apl (Monsignor) on Oct 19, 2009 at 06:45 UTC
    I should've also included The Mythical Man-Month and The Management Style of Genghis Khan. These aren't needed to become a better programmer, but to understand your management...

      I like the idea of learning code by rewriting it. It would be hard work, but probably quite effective.

Re: Questions from "Coders at Work"
by apl (Monsignor) on Oct 18, 2009 at 05:15 UTC
    1. In addition to what roboticus suggested to read, I'd add Design Patterns by the Gang of Seven and Software Tools by Kernighan and Plauger.

    6. I wish I knew...

      There was a interesting difference of opinions on Design Patterns in the interviews; some have it high on their list, others dislike it and the cargo cult around it. I did something out of Design Patterns when I read it, but I was doing more C/C++ stuff at the time.

        some have it high on their list, others dislike it and the cargo cult around it.
        I won't say I dislike it; rather, I don't believe every problem or solution can decompose as neatly as they describe. Professionally, I've always had to support the work of other people. So even if I don't worship at the altar of Design Patterns, I need to know what they are and how they work. And, after all, your question concerned what every programmer should read, not what they should agree with. 8-)
        I did something out of Design Patterns when I read it, but I was doing more C/C++ stuff at the time.

        Isn't the main point about patterns a kind of contract with both parties hopefully understanding the meme in question identically? To allow selecting one approach as the default approach? To allow common/default assumptions?

        To allow reuse and communication with neither

        • drowning in verbose documentation, nor
        • the "normal" situation of having to reverse-engineer code for all but the most trivial usage (dusty-corners, there be dragons, you're not expected to understand this-comments)?

        So a team selecting a set of patterns to allow for default assumptions is a good thing (e.g. about large scale architecture, constraints, preferred approaches). Actually improving team (or CPAN author / module user) communication.

        A herd of small patterns all slightly different?

        Way too much of a good thing (cf. the missing default OO style for Perl5). So skimming a book introducing yet another set of patterns is good to obtain new tricks and approaches. But being a dictionary, such a book only offers a little help with the real problem: communication. And with Perl's expressivity (plus), many of the low-level acclaimed C++ patterns boil down to more or less single-line techniques (e.g. Schwartzian transform). Or lack direct applicability as we still didn't select a default OO style (minus - it's not helpful if a trivial one-line pattern requires 20 lines of interface glue to cope with both blessed hashes and blessed scalars).

        Now what is the set of patterns and assumptions that are safe to be assumed default/standard for random CPAN module ABC?

        Is selecting/migrating such defaults for OO or just CPAN modules only possible with a Revolution once in a while, with breakage of a scope similar to the Perl5-to-Perl6 situation?

        not really convinced about the most of the wave of pattern books (read: small-scale pattern dictionaries),

        PS: TIMTOWTDI is great. But we can improve upon it, if we select one W as the (non-exclusive) default, to allow shortening the description of most of the variants to a small listing of differences: Situational awareness is a severely limited resource for me, and diffs waste less wetware capacity...
Re: Questions from "Coders at Work"
by jakobi (Pilgrim) on Oct 18, 2009 at 15:47 UTC
    1. Hm. Books about the underlying principles, protocols and architecture. D.E.K is certainly a classic for algorithms (though I only skimmed some sections). McKusick, Mauro, the Magic Garden Explained, and R.W.Stevens for Unix and network. Small gems like Gancarz' Unix philosophy or Kernighan/Pike's Practice of Programming (that's small as in size).
      Get the paradigms and principles down pat, the rest is mostly just intelligently combining/layering/playing with them. Add small gems like Gancarz' Unix philosophy or Kernighan/Pike's Practice of Programming.
    2. Cweb (but currently templates being run through embperl and POD is about as near as I go there). Not for real stuff.
    3. Math: Logic, signatures and reasoning about signatures are probably the most important sections.
    4. Code reading: a) kind of the impossible approach of 'incremental-proof-by-repetion', with sometimes asking questions of more or less isolated code sections. b) Sometimes. c) Well-structured functional code is enjoyable and doesn't require much documentation and commenting (if the architectural big view _is_ documented).
    5. Prototyping: Puncture the problem field with a "tunnel-prototype" (also takes care of feasibility), top down with abstracts and stubs, then bottom-up. Afterwards it's just Groom, Grow, Repeat. But the programming projects usually aren't that huge, and more of a side show.
    6. Being able to abstract and communicate. Perl virtues + Paranoia. Being able to structure and overthrow structure & play with abstraction levels. Background knowledge and interest in the underlying principles and protocols. The ability to not forget about the correct amount of documentation, esp. for the big view. Aversion of both Huffman-encoded source as well as MVS documentation-style.
    7. Frameworks and skeletons certainly changed some things, with a tendency for a lack of overview/big-picture, and a tendency for excess fat, while requiring more memorization of not-that-relevant details like object names, etc. So memorizing got more important and may even hide a dangerous lack of skill, abstract thinking and background knowledge. See also (6).
    8. The "hard" boundary between craftsman and artist is a fairly recent misconception. All of the terms describe more or less the same area, when you consider the common historical root of all of (science,) math and arts. A bit of everything, I guess.

    Update 1

    Ad 6/7: Roboticus point in the first comment about

    The "big picture" skills don't change: You need the passion and talent for problem solving. You need good communication skills to work with your clients. The "little picture" skills (programming languages and such) change frequently enough, but it's unimportant, because you can adjust your skill set as needed

    is also an important observation. With the little picture skills sometimes hiding (or causing) fatal holes in the big picture.

    Of course for a small number of the little picture skills, an intent to improve to expert level is IMHO also required for a good programmer, even if only to anchor/compare other skills or knowledge against.

Log In?

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlmeditation [id://801727]
Approved by Old_Gray_Bear
Front-paged by planetscape
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others making s'mores by the fire in the courtyard of the Monastery: (2)
As of 2024-07-24 03:22 GMT
Find Nodes?
    Voting Booth?

    No recent polls found

    erzuuli‥ 🛈The London Perl and Raku Workshop takes place on 26th Oct 2024. If your company depends on Perl, please consider sponsoring and/or attending.