Subscribe to PHP Freaks RSS

Learning to think like a programmer.

Print
by Tony Quilkey on Jun 17, 2008 1:37:01 AM - 20,647 views

Being a moderator here on the phpfreaks.com forums I have been witness to many newcomers to programming jumping to the conclusion that learning to program may just be as simple as learning a programming language. I'm here to say its not.

Sure, a big part of programming is knowing how your language of choice works, what it's functionality is capable of and how to piece it all together, but In my opinion, of bigger importance is the idea of logical thinking.

All too often I see people who have just finished reading that new php book they got for their birthday stroll into a message board and ask 'How do I build a forum?'. I've read these books too, and to be honest, I don't think any of them have emphasised the importance of logical thinking and breaking your feature set down into smaller pieces. Nor do they mention the amount of time you might save in doing so.

Why search for a good tutorial on building a registration system using php5 when if you've learnt to break down the problem you wont need it?

As an example, Joe has recently picked up php's syntax, is quite comfortable with how to use the manual to look up functionality and now wants to build a login system for his website. Having not learnt the importance of logical thinking and having no clue where to start he posses the question 'How do I build a login system?'. He gets a few responses pointing him to some useful tutorials and his on his way. With that feature complete he now wants to add the ability to validate his users are providing him with a valid email address, but with no clue where to start he posses another question 'How do I validate a users email address?'. Again he is pointed to some useful tutorials but because he lacks ability to piece together the information he ends up back at square one with the new question 'How do I build a login system validating a users email address?'.

This story could go around and around with Joe eating up valuable programming time reading more and more tutorials which may eventually get the job done, but really leave him not much the wiser. The next project he embarks on may require an entirely new feature set and while some of what Joe has learnt may be of use, it is likely he is going to need to refer to those same tutorials he has now bookmarked for prosperity.

On the other hand, Mark who has read the same book as Joe but has also had it drummed into him that all problems can and should be broken down into bite size pieces. Again wanting to add a login system to his website he posses the questions to himself....

q) What functionality makes up a login system?

    a) Registration?

        q) What functionality makes up registration page?

            a) Take user submitted details and store them for later reference?

                q) How do I enter user submitted data into a database?

                    a) I remember reading about that in my book, I'll use that as a reference.

    a) Verification?
        ...
    a) Identification?
        ...

Even with this simple scenario we can see that Mark is well ahead of Joe. He is thinking through the issue piece by piece and is able to simply refer back to his still in good tact book for explanations of the syntax some things might require. The entire problem doesn't seem as overwhelming as that of Joe's 'How do I build a login system?' And in the end, because Mark has been through the thought process and understands how all the pieces fit together adding new functionality will be a simple task of posing the right question, in the right position.

Comments

Corbin Hughes Jun 17, 2008 1:56:48 AM

I thought about writing a tutorial about thinking like a programmer.... Then I remembered how lazy I am.

Nice blog. Very interesting, and true. I was thinking about this the other day.... Users will come onto the forum all of the time and post questions that are just common sense... in a programmy way... If that makes sense, and they just didn't stop to think of what they're really trying to do.

Oh, I just happened to notice "tutorials and his on his way," by the way...

mthomps71 Jun 19, 2008 3:42:05 PM

How about checking your grammar : )~ LEARNT

oh my bad that must be uk's version of learned

macrunning Jun 20, 2008 1:21:51 PM

You know as a designer learning to code I find myself constantly trying to learn. I guess I could understand your perspective if you know everything there is to know about .php and coding. Truth of the matter is people are looking to learn and what better way than to have someone help point them in the right direction. That is what makes the internet so great. I don't think one person on here could walk down the street and just start asking people programming questions and get help in what direction they need to go in order to learn. As a moderating I am quite surprised you would look down upon the newbies in this way and not give them a more consoling and helpful hand in becoming better programmers.

Tony Quilkey Jun 22, 2008 3:51:35 AM

I think you may have missed the point. Point is, learning everything there is to know about a language will get you nowhere if you haven't learnt how to think a problem through. Its easy to think of a feature you wish to build (the end result), but leaning to step back and think of how that feature might get to that end result is where its at. Untill you can step through a problem in logical steps you will forever be asking others to do the thinking for you.

wrathican Jun 22, 2008 4:40:17 PM

When I first started out I decided to create a portfolio for the projects I had completed over time. I sat down and thought about what features I needed to make the portfolio work. At first I didn't even touch a computer. I sat down with a pen and paper and wrote down and described everything I thought I needed. This included my database design and deciding what data types my database needed.

So, to all the new starters out there I recommend doing exactly what I did. Sit down and think before you code.

macrunning: I have been in the position of 'Joe' and it truly is a lot of wasted programming time. Instead of asking a question, sorting it, coming back and asking another question, rinsing then repeating. It is so much more productive to know what direction you are trying to head in.

numan82 Jun 23, 2008 12:36:25 PM

nice discussion, well in my view, to be a good programmer you need to have logical thinking plus your passion and innovation and love for your work, until you don't love your programming job you can't be a productive programmer.

jdcpar5 Jun 26, 2008 9:48:18 AM

Even though it's not focused on php, I found this book very helpful in learning to think more like a programmer, and less like I was just hacking code together into scripts:

"How to Think Like a Computer Scientist: Learning with Python" at
http://www.greenteapress.com/thinkpython/thinkCSpy/

Another great resource for this is the "Head First Software Development" book from O'Reilly.

Barry Andrew Jun 30, 2008 9:15:26 PM

Note to mthomps71

He learned
He has learnt

Greg Davis Jul 4, 2008 8:10:56 PM

I think the word to be emphasized here, which has been surprisingly absent, is APPLICATION. Before you can create with your new found knowledge you first understand the appropriate method(s) with which to apply that knowledge. In contrast to this brief article, the tutorials you find are actually a very good starting point for understanding application. By seeing how others have utilized the language a relative "noob" with at least some common sense can work out on his/her own the best way to apply new found knowledge.

I agree that merely copying the work in these examples is no way to accomplish true application ability but by studying and modifying you learn much quicker than by merely breaking things down and going it alone with only what you've studied.

dogbiter Jul 5, 2008 12:15:29 AM

very good topic i think. and good point too you do need to understand php to be able to think this way though but for someone that reads the book then just puts it aside and trys to figure things out will not be very successful. the point is learn the basics then when you try something more complicated you have a base. and if you know what your application needs to do then you can seek out the functions and the syntax that you need for that action. if it's in your book that you read then you have a good start if not then turn to the internet. and this is coming from someone that learned the bulk of my php programming from tutorials online.

Led Zled Jul 17, 2008 8:15:17 AM

As always there are two sides of the coin. Yes, it's difficult, if not impossible, to design and code a complex login system without proper planning. On the other hand, planning a design without knowing anything about coding isn't that easy either. It's sort of like planning a journey - you have to know where you're going before you decide how to get there but if you don't know what means of transportation are available you might not get anywhere.
My point being that the better approach for Joe would be to learn programming by walking through some of all the great tutorials available here and elsewhere. Then, when he's beginning to understand a little of what programming is about, he could start planning and designing his complex system. thta's pretty much how I started out some 5 years ago. I built a site for a CS clan by converting an asp/access driven site to php/mysql. After that I've started out on a personal site a few times but I always end up biting off more than I can chew...

knowj Aug 15, 2008 2:27:38 PM

[quote=Corbin H]I thought about writing a tutorial about thinking like a programmer.... Then I remembered how lazy I am.[/quote]

Beging lazy is a requirement of being a programmer. It especially helps with OOP you build stuff so you can be lazy later and never have to write the same thing again.

Good blog. I agree with you about books so many tell you how to learn a language but few teach you how to program. I am yet to find ANY documentation on BEST PRACTICE and i have been in the game for a good 6-8 years.

activeserver Oct 25, 2008 8:23:52 AM

What you're saying is so very correct and important - Joel Spolsky too says the same thing - http://www.joelonsoftware.com/articles/fog0000000245.html
( NOTE: in my opinion, the small reference to evidence-based scheduling is probably more reasonably fitting to teams and corporations making huge products.)
I personally yearn for the day that I start making plans that actually get implemented on time ;-)
Breaking down tasks and asking lots of questions - very much needed.

"Point is, learning everything there is to know about a language will get you nowhere if you haven't learnt how to think a problem through. Its easy to think of a feature you wish to build (the end result), but leaning to step back and think of how that feature might get to that end result is where its at. Until you can step through a problem in logical steps you will forever be asking others to do the thinking for you."
Needs to go into the main article :-P

haku Jan 23, 2009 2:45:39 PM

Good post. I'm sure it can seem frustrating to read it for a newer user (as is obvious by the comment made in this thread), but its not a matter of looking down on newbies, rather its looking at newbies from a perspective of knowledge. To use an example I read somewhere else on the site tonight (Crayon Violent maybe?) Being a parent is much the same thing - we don't look down on our kids, but we know a lot more than them.

When I was studying C++ in university, my professor made us write down all our code in plain English before doing anything. We were also required to submit it along with our code, and he would grade us on this.

Basically, we wrote out something just like in the post. A plain English list of steps that we would take. It annoyed me when I first started, as I just wanted to sit down and start programming, but it was a good lesson, and made my programming a lot easier, and my code a lot cleaner (though it was still garbage!).

I still do this for big projects (I don't need to for small ones), particularly when I am putting together a quote for a client. Seeing the specifics broken down like that gives me a better idea of how long I will spend on the project. I am also able to show this to the client so they can see what I am doing (in words they mostly understand), and how many steps there are to do the project, which helps justify the time and cost of the project.

peleg May 8, 2009 2:10:05 AM

The approach I use I find is applicable to almost any sizeable problem, even if it is not a programming problem. I've heard it called "Divide and Conquer". It works for large programs as well as, for example, planning a wedding. It is how I would define what it means to "Think Like a Programmer".

A project starts with a simple statement of what the program is supposed to do. If I can nearly write the program in my head, then I start coding. If I can't see a way to do it, then I partition the problem into two or more smaller problems. Then I look at each of the smaller, sub-problems. If I can see how to do each sub-problem, then I start coding. If any of the sub-problems still seems too hard, I recursively partition each of them until I can finally see how to solve the smaller problems. When I can see how to do them all, the partitioning is done.

I then proceed to code the smallest problems first, walking back up the chain, coding the progressively larger problems, using what came before. I just keep walking up the chain until there are no more uncoded problems.

Each of the sub-problems roughly corresponds to a procedure that calls the sub-problems just bekow it in the chain, along with some code to integrate all the sub-problems it calls. So, most of the work is done at the lowest level and the higher levels are largely integration and aggregation of the lower-level subproblems.

A diagram of the process would be a tree, where the problem statement is the root and each leaf is a procedure that is composed of the leaves coming from that leaf. The terminal leaves call no other procedures, except those built into the language.

The choice of a language can be done when the project is partitioned and is then a relatively easy task. Given that I now know what I have to do in some detail, it is not that difficult to choose a language that best supports those tasks. At the same time, other considerations can be taken into account, and weighed accordingly -- the choice of language is not always solely based on how good it supports the technical requirements.

When I started doing web sites, I used Perl for my backends, and it worked, and did a good job. Technically, I think Perl is good language and can do most anything. However, when I started to explore PHP, I found that it was a better match to what I needed to do to build a web site, and it takes so much less code to do the same things, so I've switched to PHP. I still like Perl, and I'm glad I know it because it definitely has it advantages over PHP in some circumstances, but I think most backend code is better done in PHP. This opinion is certainly debatable since both languages can do the job well. Thus, my personal preference is a major deciding factor and a preference is not easy to argue.

When people ask, "How do I ..." the answer I would give would not necessarily have anything to do with any particular language, rather I would encourage the person to think more about the problem itself and try to do a least the first level of partitioning. No matter how well they know a language, if you don't know what you need to code, you can't write the program.

On the other hand, once you can partition the problem all the way down, then you can write the program, and in most any language.So, until you've got the project sufficiently partitioned, I wouldn't worry much about the language.

But once you've got the problem partitioned, then looking through a text for the way to code it up becomes much more productive because there is then a much better match between the small problems you need to solve and the language itself. For example, no language (that I know of) has a statement that creates a login page. But, given you know that one problem you have to solve is to look up a username and password scraped off a page, you can rather easily find those statements and functions that have to do with database queries. I can use PHP to create a login page, but the solution is not to be directly found in the language manual.

And I think that is how programs get written.

I'm not sure I would use the term "logic" to describe the process, though. "Methodical" seems a more descriptive term to me. "Logic" refers to thinking processes like "If A, then B". I know, the general usage of the term allows it to be used in this context, but I guess I'm just anal about being precise in my choice of words. Comes from, I think, being a mathematically-oriented programmer for over 30 years. (I've come to think of my procedures as abstract entities that solve the most general problem that is practical, and this makes them a lot less likely to fail when presented with some data I hadn't expected.) Terms have a necessarily precise definition in math and computing -- at the very least, it saves a lot of confusion and lengthy explanation -- and so I am careful about them.

Add Comment

Login or register to post a comment.