Tuesday, November 16, 2010

Pledge to Participate in and be a Supporter of Computer Science Education Week!

Computer Science Education week is December 5-11, 2010 this year. ACM and the chair of CSed Week steering committer are asking people to sign up and pledge to support CSed Week. I understand that a new CSed Week web site “will be rolling out on November 29, and will encourage students, teachers, industry, and university folks to pledge to engage in some activity to promote computer science education.”

Join with teachers, students, parents and others who are participating in CSEdWeek activities and events. Sign the pledge now to support CSEdWeek activates and events.

Pledge here: <www.computinginthecore.org> and list what you are doing to participate in Computer Science Education Week.

Monday, November 15, 2010

Wisdom in Lists–Really?

Like a lot of people I have an affection for lists that condense a lot of wisdom into a brief set of statements or items. Some time ago I wrote a series of posts on Programming Proverbs for example. That list (reproduced at the bottom of this post) came from a book that was every influential to me, especially early in my career. Each proverb by it self said a lot but mostly to someone who all ready know something about the topic. The original book had a sort of chapter on each proverb and did a wonderful job of elaboration and explanation. My series of blog posts was a couple of paragraphs on each from my own experience. Why do I bring tis up now? Well I found a couple of other posts of somewhat similar “proverbs” if you will. I thought I would share them with you and perhaps suggest a look at my own series in case you missed it the first time around.

The first is “The Two Things about Computer Programming” a couple of years old but still quite relevant. Plus it is new to me so maybe it is new to you as well. Read the whole post for the explanation of “Two Things” but the Two Things about Computer Science and the Two Things about Software Engineering given are:

Computer Programming:

  1. Every problem can be solved by breaking it up into a series of smaller problems.
  2. The computer will always do exactly what you tell it to.

Software Engineering:

  1. Writing the code is the easy part. Writing it so someone else can understand it later is the important part.
  2. Make it work, then make it elegant, then make it fast.

I’m not sure these are the end all and be all and I have a mind to explore them at some length one of these days. But I thought they were worth sharing in “raw form” to see if I can get some conversation going. Are these right? Are there two more important things? Is it even helpful to have the computer programming and software engineering divide?

The other post is 20/20: Top 20 Programming Lessons I've Learned in 20 Years subtitled “This post could be viewed as hard lessons learned for newly graduated college students, entry-level programmers, or advanced developers who just want a chuckle.” Also not a new post but I just discovered it. There are some 60+ comments which may add value as well. I like this list although, as with many such lists, I’m not sure all of them would be on my top 20. But then each individual has a different experience and a different idea of what key learning's are.

The Programming Proverbs I wrote about with a link to each post is here:

  1. Define the problem completely
  2. Think first, Program later
  3. Use the top-down approach
  4. Beware other approaches
  5. Construct the program in logical units
  6. Use procedures {methods}
  7. Avoid unnecessary GOTO's
  8. Avoid side effects
  9. Get the syntax correct now, not later
  10. Use good mnemonic names
  11. Use intermediate variables properly
  12. Leave loop variables alone
  13. Do not recompute constants within a loop
  14. Avoid implementation-dependent features
  15. Avoid tricks
  16. Build in debugging techniques
  17. Never assume the computer assumes anything
  18. Use comments
  19. Prettyprint - format your code so that it looks nice
  20. Provide good documentation
  21. Hand-check the program before running it
  22. Get the program correct before trying to provide good output
  23. When the program is correct, produce good output
  24. Re-read the manual
  25. Consider another language
  26. Don't be afraid to start over