Beefy Boxes and Bandwidth Generously Provided by pair Networks
good chemistry is complicated,
and a little bit messy -LW

Re: Questions from "Coders at Work"

by roboticus (Chancellor)
on Oct 17, 2009 at 16:26 UTC ( #801769=note: print w/replies, xml ) Need Help??

in reply to Questions from "Coders at Work"

  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.

Replies are listed 'Best First'.
Re^2: Questions from "Coders at Work"
by bsb (Priest) on Oct 18, 2009 at 09:46 UTC

    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.

        One of the later interviewees (Bernie Cosell) described a similar rewrite-to-understand approach.
Re^2: Questions from "Coders at Work"
by Limbic~Region (Chancellor) on Oct 19, 2009 at 13:36 UTC
    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.


Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://801769]
LanX prefers blood moons

How do I use this? | Other CB clients
Other Users?
Others examining the Monastery: (5)
As of 2017-08-21 18:26 GMT
Find Nodes?
    Voting Booth?
    Who is your favorite scientist and why?

    Results (324 votes). Check out past polls.