Cure for puzzle piece programming habits?

Question

Even though I went to a decent CS school, I was still taught with the mentality of programming with puzzle pieces. By puzzle pieces I mean, looking up code segments at each step of the development process and adding them together as needed. Eventually gathering all of the pieces and having a properly working program.

So as an example, if in my program the next step is to tokenize a string, I go to google and search "how do I tokenize a string in language". All instead of critically thinking about its implementation.

I personally don't think its a very good way to program and I always seem to forget everything that I have searched for. So how can I get out of this puzzle piece mode of programmer that I was taught.

Answer 1

Frankly, this mentality isn't necessarily bad. Software engineering relies heavily on this type of code reuse, and now Google as well.

There is one caveat I would add though: when you take code in this manner, make sure you understand it, or else you'll never be able to maintain it, unless you miraculously find the original Google result where you first got it.

Answer 2

Knowing how to find the answer is sometimes more valuable than knowing the answer. However, Tesserex's caveat is very important.

Answer 3

Unplug the network cable for 30 minutes, plug it in for 5 minutes. Repeat until coding is complete.

Answer 4

You could try doing some of the problems from Project Euler.

Answer 5

There is nothing wrong with reading and learning from existing implementations. You might want to stop short of the habit of wholesale cutting-and-pasting of entire sections of code. But reading other peoples code before implementing your own is always a good idea. It is the modern equivalent of picking up a book.

Answer 6

One of the things I tend to do when looking up a solution online is to read through the code example, figure out what the programmer is doing and then go about writing the same thing myself.

Sometimes I'll need to make quick reference checks to the sample code to re-member what I saw earlier but for the most part I try to code the solution myself, even if I'm simply copying out from memory. This way you'll be more likely to remember how you did what you've done.

Answer 7

If you are satisfied to be an "adequate" programmer, just borrowing or hacking until you get something that works is good enough. If you want to be a great programmer, you need to understand the concepts. Learn the big picture. Learn how all the pieces fit together to make the big picture.

Here's a little anecdote that sums up my advice: When Windows came out, I had to make the switch from command-line programming to GUI programming. So I took a class and got some books and was able to copy-and-edit from examples and get something that worked, but I didn't really understand it. So finally one day I said, I'm going to learn how this really works. So I brought up a blank screen and tried to write a simple GUI program from scratch, without consulting any references or examples. Of course my first try didn't work at all. So I tinkered with it and hacked away until I fixed the first problem. Of course it then failed with a different error. So I worked on that. Etc. At a few points I looked back at an example to see how mine was different. Ah, I said, I see, I failed to do such-and-such. But I just fixed one thing from an example each time. By the time I finally had a working program, I had something that closely resembled the examples I had been using. But now I knew what every line of code did and why it was there.

So that's my advice. Every now and then, take the time to step back and write something from scratch. No book, no Google, nothing. Make it a rule for yourself that if it doesn't work, you will only consult a reference or example to fix one problem at a time, and you will study it until you understand why that fixes the problem. Then when you're done you'll understand it.

Anybody can write a great work of literature if copying Shakespeare word-for-word counts as "writing". The trick is when you can do it yourself with just a blank sheet of paper and a pen.

Answer 8

I've been coding without internet for the last three months or so... I've gotten pretty good at using the man pages and help menu in the Terminal

Answer 9

Keep the big picture in mind.

Before you write any code, break down the problem into smaller pieces. Only allow yourself to look something up in Google if it is a small item on the list, meaning you've taken 30 seconds to break down the problem into parts before attempting to find the solution. It doesn't have to be anything fancy, just a sentence or two for each piece. This should get you thinking about the overall outcome instead of limiting yourself to a possibly overly-narrow search result.

Answer 10

Time to think went away?

Einstein got relativity without google...

well now everything has change, you can be offline, but if you are online.. is preferable to enjoy being part of this global brain we are

We are the robots