Linked by Thom Holwerda on Fri 28th Sep 2012 21:51 UTC, submitted by MOS6510

Thread beginning with comment 537048
To view parent comment, click here.
To read all comments associated with this story, please click here.
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[2]: Old Programmers had to write precise code
by lucas_maximus on Sun 30th Sep 2012 13:27
in reply to "RE: Old Programmers had to write precise code"
I think visualising the problem first is what separates the good from the bad developers.
I am trying to get our junior developer to break down problems into a set of steps. I sat him down with me and went through what I was doing and why.
He just wrote everything down, completely missing the overall point.
While I rarely write a lot of pseudo-code anymore, I normally have a diagram, set of rough steps or something similar I wrote first to get the problem well understood in my head.
Edited 2012-09-30 13:28 UTC
Member since:
2006-10-08
Programming began in the head, not on the terminal's keyboard (if you had one). I think there was more emphasize of the "pre-coding work". Today you don't need that approach anymore as "trial & error" is inexpensive, all on company time. :-)
You could be happy to even see the machine you're woring on (or for) once in your life. :-)
So you know where "accounting" in relation to computer resources (CPU time, storage, hardcopy) originates from. The UNIX and Linux operating systems still have this functionality built in.
I remember my CS professor stating: "'Trial and error' is not a programming concept!" :-)
For those not familiar with this important era of computing, I suggest reading "Programming with Punched Cards" by Dale Fisk:
http://www.columbia.edu/cu/computinghistory/fisk.pdf
It's more funny than you may think, and as a historic sidenote, it depicts the role of women in IT when IT wasn't actually called IT (but data processing).
I admit it's hard to compare in terms of worse or better. At least it's much different, even though some basic elements have been shared throughout IT history. Those who are willing to read, to learn, to think and to experiment will always be superior to "code monkeys" and "typing & clicking drones" involved in so many parts of corporate IT.