Updated 2013-08-17 07:09:00 by uniquename ▲

Programming can be a very frustrating thing to do at any level.

There are a few things that have kept me going:

  • Be excited when little things work
  • Realize that from little things big things are built
  • Everybody is still learning (even Knuth)
  • Focus on being the best programmer you can be, rather than as good as someone else
  • Realize that holy/language wars just bring upset and the best thing to do is to fix the problem, rather than complain
  • Don't be intimidated by 500+ page books (almost everybody finds them frustrating)
  • Remember your past difficulties when helping new programmers

Please extend this list - George Peter Staplin.

MSW: In fact I love 500+ pages technical books :)

  • Enjoy bugs. Remember, they are there to be fixed by you - be excited when you fix that thing.
  • Enjoy interaction with your users: They will show you ways to use your program you've never thought about before.
  • Expect credits for minimal, ridiculous changes you do, but don't for abstract flexible frameworks: You get cheered on for what they see.
  • The smile on the faces of your users when you implement their wishes quickly
  • Humor. You'll often laugh hard when you read code you wrote years ago - especially if you are now more fluent in that programming language

DKF - It's books that are over a thousand pages that are intimidating. Especially when used on cow-orkers... ;^)

D. McC: Keep it down to about 800 pages, like Eric Foster-Johnson's commendably unintimidating Graphical Applications with Tcl & Tk, and you should be OK.

As for the "cow-orkers": I used to think the fad of omitting properly placed hyphens in words such as "co-workers" was harmless, but no more.

"I've had it with this company! He accused me of orking cows! I've never orked a cow in my life!"

"Oh yeah, tell me about it--you probably sneak out to the Cow Palace and ork cows all night long, or until they come home, whichever comes last!"

"Hey, stop that! Break it up! Somebody call the police, quick!" :o)

  • Sometimes failure isn't really failure. When you learn from a project it can in a way be considered a success.
  • Keep reaching for the sky. If you only do coding that is easy you won't make the gains that you may seek.

[Economic absurdities ...]

The most dangerous moment is when you have a vision and say to yourself, "Hey, I could code that!" The next thing you know, no one has seen you for a week and you've perpetrated yet another Tcl object system. -- WHD

LOL! So true... so true --ro

Perhaps related to this are books like The Nudist on the Late Shift [1] [2].

I seem to remember a book by Robert L. Glass called Hot Dogs and Mixed Nuts: Tales of the Computing Profession, but I cannot find any reference to it. It must have been written in the late 70s.

David S. Cargo (dcargo@marix.com)

This seems to be the book: Glass, Robert L. 1978. Tales of Computing Folk: Hot Dogs and Mixed Nuts, Computing Trends

but it is out of print.

Keith Vetter I've always liked best the explanation that Fred Brooks gave in the book The Mythical Man-Month on why programmers spend endless hours sitting in front of a small screen.

Why is programming fun? What delights may its practitioner expect as his reward?

First is the sheer joy of making things. As the child delights in his mud pie, so the adult enjoys building things, especially things of his own design. I think this delight must be an image of God's delight in making things, a delight shown in the distinctness and newness of each leaf and each snowflake.

Second is the pleasure of making things that are useful to other people. Deep within, we want others to use our work and to find it helpful. In this respect the programming system is not essentially different from the child's fist clay pencil holder "for Daddy's office."

Third is the fascination of fashioning complex puzzle-like objects of interlocking moving parts and watching them work in subtle cycles, playing out the consequences of principles built in from the beginning. The programmed computer has all the fascination of the pinball machine or the jukebox mechanism, carried to the ultimate.

Fourth is the joy of always learning, which springs from the nonrepeating nature of the task. In one way or another the problem is ever new, and its solver learns something: sometimes practical, sometimes theoretical, and sometimes both.

Finally, there is the delight of working in such a tractable medium. The programmer, like the poet, works only slightly removed from pure thought-stuff. He builds his castles in the air, from air, creating by exertion of the imagination. Few media of creation are so flexible, so easy to polish and rework, so readily capable of realizing grand conceptual structures.

Yet the program construct, unlike the poet's words, is real in the sense that it moves and works, producing visible outputs separate from the construct itself. It prints results, draws pictures, produces sounds, moves arms. The magic of myth and legend has come true in our time. One types the correct incantation on a keyboard, and a display screen comes to life, showing things that never were nor could be.

Programming then is fun because it gratifies creative longings built deep within us and delights sensibilities we have in common with all men.

DKF - I like that quote very much indeed.

Borrowing a major concept from Peter Naur's "Programming as Theory Building" (Peter is the N in BNF): Programming isn't about creating the text of a program any more than science is about creating the text of a report. Much as science is about building theories about the universe around us, programming is about building theories about what's supposed to happen in the computer.

LV When you reach the point of learning to find out what a user/requestor really wants, rather than what they say they want, and move to fulfill that, you reach a new milestone in developing programs as well.

Oh - and someone - I forget who right now, in a teleconference on developing and programming, gave these as four keys to a successful team regardless of whether it was of programmers or someone else. Why, they even help the Tcl community.

  1. a clear purpose and shared values and goals.
  2. developing individual skills
  3. an attitude that no one of us is as smart as all of us (leading to development of harmony, synergy, and team skills)
  4. repeated rewards and recognition

SYStems I like that quote

We the unwilling, led by the unknowing are doing the impossible for the ungrateful. We've done so much for so long with so little we are now capable of doing anything with nothing.

and for some reason most people would agree that it's pretty relevant to the practice of software systems development

IL [3] is a great summary for the Unix Programming Philosophy. It consoles me greatly at this point in my career. There is a better way!

SYStems I have to disagree with Pike's Rule No 5

Rule 5. Data dominates. If you've chosen the right data structures and organized things well, the algorithms will almost always be self-evident. Data structures, not algorithms, are central to programming. (See Brooks p. 102.)

A program is collection of Inputs, processes, ouputs

Input = Data, process= Algorithm, Output= Data

A program code complexity, depends on all 3, if you have more complex data types, you can have less complex algorithm, and vice versa, if you have very simple data type you will have very complex algorithm

Taking any point to the extreme will be harmful, complexity should be fairly disptributed on the algorithm and the data, I know you can't target for a 50-50 balance, and maybe Pike is arguing fro 65-35 in favor of data

But my point is, program with complex data types, will have simple algorithm, but ... they will have complex data types, so it will still be hard to understand it's code, i.e. the code that describe the data

I am thinking most people who argue against OOP at actually saying, if you make the data structure too complex, you didn't solve anything

So no don't let your data dominates, both algorithms and data are equally important

Lars H: I suspect you're missing the point, SYStems. Yes, one sometimes has to choose data structures so that they are suitable for a particular algorithm, but much more often the algorithm should be chosen so that it is suitable for the data structures at hand. Data exist not only as input or output, but almost always also throughout the process. Data must often be operated upon by a number of different algorithms to get the job done, and then it is often not reasonable that it should be restructured for every new algorithm that gets invoked.

As a particular example of how data dominates, consider sorting. If the data to sort is stored as a linked list, then one should most likely use mergesort for the task, even if one's pet sorting algorithm happens to be quicksort. (Quicksort is unsuitable because it requires random access to the data.)

For a higher level example, one may consider Linear Programming. If all constraints are explicit, then Karmarkar's algorithm is (AFAIK) the state of the art. If on the other hand constraints are generated dynamically by an oracle (often because the full set of constraints is too large to make explicit), then the ellipsoid method can be superior.

So, indeed data dominates. There is a certain feedback in that an unsuitable choice of data structure can make some operation very expensive and therefore call for a different data structure, but an experienced programmer generally discovers this before anything has been coded and can revise the data structure accordingly. Once a data structure has been settled upon, coding may commence. The cost of changing algorithm in the coding phase is generally small compared to the cost of changing data structure; even economically data dominates.

  • Most of the time, you'll be writing a program to do a job. Concentrate on doing the job elegantly; don't let computer science worry you unnecessarily.
  • Encountering a problem isn't a blemish on your competence; it's an opportunity to explore.
  • Be humble enough to realise that you need to break things down to understand them, but confident enough to realise that breaking things downs puts almost anything within your grasp.
  • Sometimes you can solve a problem more easily without needing a program. That doesn't make you a bad programmer, but a creative thinker.

Stu (2005/12/29)
         Jonny looks around, confused, his train of thought disrupted. He
 collects himself, and stares at the teacher with a steady eye. "I want
 to code demos," he says, his words becoming stronger and more confidant
 as he speaks. "I want to write something that will change people's
 perception of reality. I want them to walk away from the computer dazed,
 unsure of their footing and eyesight. I want to write something that
 will reach out of the screen and grab them, making heartbeats and
 breathing slow to almost a halt. I want to write something that, when it
 is finished, they are reluctant to leave, knowing that nothing they
 experience that day will be quite as real, as insightful, as good. I
 want to write demos."

         Silence. The class and the teacher stare at Jonny, stunned. It
 is the teachers turn to be confused. Jonny blushes, feeling that
 something more is required.  "Either that or I want to be a fireman."

                                        - Grant Smith,
                                                14:32,
                                                11/21/93

It seems like the field of programming becomes less and less an area of passion about programming and more and more a method of obtaining a paycheck.

uniquename 2013aug17 - I believe it has been said that it takes about 10,000 hours to get good at anything --- sports, music, etc. In mid-2013, after about 15+ years of Tcl-Tk programming at an average of probably less than 2 hours per day over those years, I am finally near that 10,000 hour level. It feels good. I can now do a lot of good stuff. But I still feel like I know no more than about 3% of what there is to know about Tcl-Tk.

Category Discussion