Category Archives: Articles

Andrés Taylor: “Top ten things ten years of professional software development has taught me”

I love reading things like this: Top ten things ten years of professional software development has taught me


  • “Object orientation is much harder than you think”
  • “The difficult part of software development is communication”
  • “Learn to say no”
  • “If everything is equally important, then nothing is important”
  • “Don’t over-think a problem”
  • “Dive really deep into something, but don’t get hung up”
  • “Learn about the other parts of the software development machine”
  • “Your colleagues are your best teachers”
  • “It all comes down to working software”
  • “Some people are assholes (…) Don’t take this too hard”

Just a Few Good Men!

Another cool article: The Future of Software Development


  • “Digg,, YouTube and other poster children of the new web era were developed by just a handful of programmers.”
  • “(…) dynamic systems are not engineered, they evolve.”
  • “Like living organisms, these systems are continuously reshaped to fit the dynamic landscape of changing requirements.”
  • “Code is constantly changed to make sure we end up with the simplest, and best possible system that reflects our current needs.”
  • “(…) it only takes a few good men (and/or women!). With a bit of discipline and a ton of passion, high quality engineers are able to put together systems of great complexity on their own.”
  • “Equipped with a modern programming language, great libraries, and agile methods, a couple of smart guys in the garage can get things done much better and faster than an army of mediocre developers.”

Writing Code – Similar to Writing Poetry

I came accross a very interesting view of Richard Gabriel:

His points:

  • “(…) because you can program well or poorly, and because most of it is creative (in that we don’t really know what we’re doing when we start out), my view is that we should train developers the way we train creative people like poets and artists.”
  • “(…) what do people do when they’re being trained, for example, to get a Master of Fine Arts in poetry? They study great works of poetry. Do we do that in our software engineering disciplines? No. You don’t look at the source code for great pieces of software. Or look at the architecture of great pieces of software. You don’t look at their design. You don’t study the lives of great software designers. So, you don’t study the literature of the thing you’re trying to build.”

Richard Gabriels website:
There you can find more interesting articles and downloads:

  • “Richard Hugo, the 20th century poet and writing teacher wrote about the use of triggers in creative work. A trigger is any idea, scene, image, thought, sound, smell, or memory that by its ‘appearance’ in a mind causes that mind to create something. A trigger can end up being a metaphor, a reminder, a stepping stone, an association, or anything that sparks connections to the creative mind. Hugo almost goes so far as saying that all creativity is really just an ability and willingness to take up the thread a trigger provides.”

Teach Yourself Programming in Ten Years

I came across this interesting article by Peter Norvig – Teach Yourself Programming in Ten Years.
Here are the keypoints:

  • “Write several significant programs, and learn from your successes and failures.”
  • “Work with an experienced programmer and understand what it is like to live in that environment.”
  • “In 3 days you might be able to learn the syntax” (…) “but you couldn’t learn much about how to use the syntax”
  • “Researchers have shown it takes about ten years to develop expertise in any of a wide variety of areas, including chess playing, music composition, painting, piano playing, swimming, tennis” (…) “There appear to be no real shortcuts.”
  • “Get interested in programming, and do some because it is fun.”
  • “Talk to other programmers; read other programs. This is more important than any book or training course.”
  • “The best kind of learning is learning by doing.”
  • “The most effective learning requires a well-defined task with an appropriate difficulty level for the particular individual, informative feedback, and opportunities for repetition and corrections of errors.”
  • “In any case, book learning alone won’t be enough.”
  • “Be the best programmer on some projects; be the worst on some others. When you’re the best, you get to test your abilities to lead a project, and to inspire others with your vision. When you’re the worst, you learn what the masters do, and you learn what they don’t like to do (because they make you do it for them).”
  • ” Work on projects after other programmers.” (…) “See what it takes to understand and fix it when the original programmers are not around. Think about how to design your programs to make it easier for those who will maintain it after you.”
  • ” Learn at least a half dozen programming languages.” (…) “You learn about what other people like in a language, how deeply they feel so, and perhaps even a little about why they feel so.”

Blogposts: Kevin Barnes’ Code Craft

Kevin Barnes and his amusing – slightly cynical – view on the software lifecycle.

Write software because you’re in panic.


- “The code garden (an analogy that sucks less)”
‘Basically, code is like a garden. (…) Giving people a better analogy is one of the best ways to quickly change how they think about things.’

- Agile processes, are they killing our children?”
‘I doubt anyone could accurately diagram my development process. (…) Every line of code they don’t write is another line that can’t break.’

Think about your ‘Cyclomatic Complexity’

If you have asked yourself: When can you safely say you’re done writing unit tests. The answer lies in the ‘Cyclomatic Complexity’ of your code.

When you have written tests that exercise each possible path through your code, you are having a code coverage of 100%. For your unit-testing efforts this means: you’re done.

Thinking about your code in terms of ‘Cyclomatic Complexity’ as you write it may help you write more testable code.

A simple explanation: