- 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
- 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.
- I think that this question separates the programmers from the report writers.
- 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.
- 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.
- 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.
- 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.
- 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.
Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
Read Where should I post X? if you're not absolutely sure you're posting in the right place.
Please read these before you post! —
Posts may use any of the Perl Monks Approved HTML tags:
You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
- a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
Link using PerlMonks shortcuts! What shortcuts can I use for linking?
See Writeup Formatting Tips and other pages linked from there for more info.
| & || & |
| < || < |
| > || > |
| [ || [ |
| ] || ] ||