bsb:
- 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.
... roboticus
-
Are you posting in the right place? Check out Where do I post X? to know for sure.
-
Posts may use any of the Perl Monks Approved HTML tags. Currently these include the following:
<code> <a> <b> <big>
<blockquote> <br /> <dd>
<dl> <dt> <em> <font>
<h1> <h2> <h3> <h4>
<h5> <h6> <hr /> <i>
<li> <nbsp> <ol> <p>
<small> <strike> <strong>
<sub> <sup> <table>
<td> <th> <tr> <tt>
<u> <ul>
-
Snippets of code should be wrapped in
<code> tags not
<pre> tags. In fact, <pre>
tags should generally be avoided. If they must
be used, extreme care should be
taken to ensure that their contents do not
have long lines (<70 chars), in order to prevent
horizontal scrolling (and possible janitor
intervention).
-
Want more info? How to link
or How to display code and escape characters
are good places to start.
|
|