Beefy Boxes and Bandwidth Generously Provided by pair Networks
No such thing as a small change
 
PerlMonks  

comment on

( [id://3333]=superdoc: print w/replies, xml ) Need Help??
Says dze27:
Try reading books like "Programming Pearls" & "The Practice of Programming" which teach you about the craft. Also a lot of people recommend "The Pragmatic Programmer" although that's not a favorite of mine.
Warning: This is going to be a weird article. I would probably not post it at all, except the original poster cited me as an example. This is what has worked for me; it may not work for people with very different mentalities.

If you want to become a strong programmer, amaze your friends, and confound your enemies, one thing you should probably do is try to read a lot of books that are not what other people are reading. We have a community in which all the members read the same books. Then everyone knows the same things, and discussions of technique turn into a lot of navel-gazing.

I recommend: Find two new languages that nobody else you know knows how to use. Then do a couple of projects in each language. Take notes. As you read the language manual, judge every sentence. Ask yourself "Why was it designed this way? Is this like other languages? How are other languages different? Is it better or worse? Why? What would this be good for? When would I want to use this?" and so on. Take notes. Yes. Take notes. Then when you do the projects, revisit the notes. Notice what you were right about and what you were wrong about. Write down the stuff that you didn't appreciate at first and the problems that didn't appear until later.

This is not like in college where you write down a whole bunch of boring crap that will be on the test. Here, the goal is to write down only the interesting stuff that occurs to you while you are reading. If no interesting stuff is occurring to you, there is a problem. One problem is that you don't find the material interesting. In that case you should trade it in for something you do find interesting. A more likely problem is that you may not know how to read. This is not a joke---most people don't know how to read. They think that the meaning will magically jump from the page into their minds. But it doesn't. You have to read actively. Read once sentence, then think about it for a long time, and ask yourself the questions I listed above. Then read another sentence. You are going for depth here, not quantity, because the goal is not to learn language X, but to become smarter.

Writing stuff down makes you smarter. It gives you an infinite memory. Smart people can sustain a train of thought for maybe fifteen or twenty minutes if they are not disturbed. If you take notes, you can carry on a sustained train of thought for months. It's amazing how few people do this.

Do the same thing when you read the Perl manual. Read a sentence. I will pick a sentence from the Perl manual at random: Line 2000 of perlfunc, whatever that is:

getpgrp
Returns the current process group for the specified PID.
Great example. What is a process group? What is it for? When would I want to use getpgrp? What is an actual application in which I would need getpgrp? What is another? What will getpgrp actually return? An integer, or what? What would be the best design here? (Then if the next sentence reveals that they didn't use the best design, try to figure out which one of you screwed up.) Can this call ever fail? When? How? How will it report the error? What might the return value be in that case? (Then read on to see if you are correct.) Are there permission or security problems here? Would it be dangerous to be able to get the process group ID for someone else's process? And so on.

Then you go on to the next sentence. If you read the whole manual like this, you will progress. That's what you wanted to know, right? How to progress.

Another thing I suggest: Find out what books everyone else is reading, and then read different books. Then you'll be well-placed to solve the kinds of problems that the people areound you haven't been able to solve. What if everyone owned a hammer and nobody owned a screwdriver? If you know things other people don't, the community will be stronger. Here are some books I liked that other people do not reommend: Paradigms of Artificial Intelligence Programming, by Norvig; Computer Networks, by Tanenbaum; Principles of Program Design by Michael A. Jackson (which is a brilliant, brilliant book that nobody reads); Software Tools by Kernighan and Plaugher. It's tempting for me to suggest a bunch of other random crap that I found enlightening, but that would be missing the point---you need to follow your heart, find the stuff that you find interesting, and read that. If you discover yourself saying one day "Gee, I keep hearing people talk about CORBA, but I don't know what it is," then get a book about CORBA and find out. And take notes.

The books I like are the ones that make value judgements. You should not be afraid to make judgements. Engineering depends on judgements. There are usually four or five ways to do something, and most programmers pick the first way they think of, which is why software is so crappy. To do good engineering, you need to pick the best way. It doesn't do any good to get all mealy-mouthed and say "Oh, but which way is 'best' will depend on circumstances, so you can never really know, wah wah wah." It's the engineer's job to know. You are in the circumstances, you know the circumstances, and you have to make the best decision for the circumstances. That's what engineers do. Reinforced concrete, or prestressed? (This week I'm reading Why Buildings Stand Up by Mario Salvadori.)

Also I would agree with Randal's point that most people waste a lot of time doing stuff like watching the TV. It's really easy to waste a lot of time watching a lot of crap on TV. TV-watching is often a waste of time because it is so easy to do it passively; you just sit there and let the pictures go by. I like to watch TV with my wife, and while the show is going on we talk about what has happened, what might be coming up, and why the characters are behaving the way they are. Of course, this requires that you have the right wife; I can't offer any useful advice about that. :)

People waste a lot of time with novels in the same way that they do with TV: They just turn over the pages and let the words flow into their minds without thinking about what they are reading---so don't. Read actively: "What is James feeling? Why did he do what he just did? What will Lydia's reaction be? What will the outcome be?" I like to read aloud sometimes, because actually hearing the words is different from reading them. Your brain isn't built to read language; it's built to hear it. When you actually hear the dialogue and description in a book, all sorts of meaning becomes much clearer. Of course, if you do this, you're likely to discover you've been reading a lot of crap. ("Gosh, nobody talks like that! Why didn't I realize before how silly this sounds?") Oh well!

To summarize: (1) read and do things that other people around you are not reading and doing. (2) Read actively, asking questions and taking notes.

This is what has worked for me. I hope it is not too peculiar.

--
Mark Dominus
Perl Paraphernalia


In reply to Re: At what rate are YOU progressing? by Dominus
in thread At what rate are YOU progressing? by mothra

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post; it's "PerlMonks-approved HTML":



  • 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.
Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others perusing the Monastery: (5)
As of 2024-03-19 03:30 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found