Jose's Read Only Forum 2023

General Category => General Discussion => Topic started by: Charles Pegge on January 11, 2008, 04:17:02 PM

Title: The Psychology of Programming
Post by: Charles Pegge on January 11, 2008, 04:17:02 PM
This subject has not quite made it out of academia, and is a little dry. One may suspect that many of its contributors are not that fond of programming themselves.

But this article is not academic and is based on real experience - see if you agree with the author ( who sports a very discerning Hercule Poirot moustache).

Understanding the Psychology of Programming
by Bryan Dollery
http://www.devx.com/DevX/Article/11659
Title: Re: The Psychology of Programming
Post by: Darrell Price on January 11, 2008, 07:58:43 PM
Thanks Charles. Good article. It was written about programming but the principle applies to many different fields.
Title: Re: The Psychology of Programming
Post by: Kent Sarikaya on January 12, 2008, 01:44:18 AM
Ok, I think this guy has a spycam into my work room :)

Great article, I could relate to all he wrote. Love being in the flow, just don't seem to get into it as often lately :)
Title: Re: The Psychology of Programming
Post by: Charles Pegge on January 18, 2008, 07:06:33 AM

Programming definitely requires all parts of the brain, from visionary artistic to analytical logical skills. I am not sure about this 'flow' idea though. We used to call it 'going on a burn-out'. Human rocket power cannot be sustained over any length of time so you can't rely on it to get through a long project.

The task has to be divided down into manageable pieces, that can be safely interrupted. Then comes the problem of putting it all together.

I find the approach which works best for me is to take previously developed code known to be fully functional and gradually 'morph' it to the desired functionality. Pieces of code are added or taken away,  and tested so the code is always operational and (almost) bug free. Errors left to the end of a project take the most effort to resolve, often out of all proportion to the time spent creating the code.

With unfamiliar libraries and functions, taking a working example is often the only practical way in. I can't imagine building a program that uses Opengl or Directx from scratch - there are far too many specifics, and the way in which the functions work together is often far from obvious. Understanding these systems involves carrying out a series of little experiments on working examples, and and gradually acquiring knowledge about the system, so you can gain more control over it.