Sorry for the long hiatus, dear reader, the last many days have been crazy at the job.

These are notes for a presentation by Perl guru Mark Jason Dominus, the author of Higher-Order Perl, among other things. From these many wisdom nuggets, here’s a few ideas I retain.

1. As said Vonnegut, “God damn it, you’ve got to be kind.” Really, it’s not so hard, even I am up to it. Writing to someone you know but in reputation, to ask or comment about code or ideas? Introduce yourself briefly, give some context to your question or remark. Do not confound curtness and concision: the latter is appreciated, the former is unsettling. Hellos, pleases and thankyous are not fluff, they’re air: the air that fills the tires your car/bike rolls on. Want a smooth ride?
2. The other side of the coin of kindness is the fish discussion. I’ve taught many classes at the undergrad level, and I’ve seen the results of a having a positive stance towards questions. I’ve always given prompt, helpful answers to students who cared to state their question clearly enough for me to understand (not always the case). Those students who pried direct answers for homework problems were seldom interested with the course material in the first place, and often performed in the lower and middle tiers of the group. However, for people interested in the course matter, a few helpful answers would get them on track to complete their projects and solve the most difficults problems on their own, making them happy and proud of themselves, and getting them to perform in the higher tier of the group. There was no sucking-up, nor any sort of favoritism or nepotism going on. What have I got out of this all? Many of these then-interested students have become good professional contacts, with whom I share a common appreciation of our respective competences. In other words, if I’m seeking work, I can call some numbers. Giving a bit of your knowledge freely nets you karma, grasshopper.
3. OH: apparently, Lisp communities are not friendly with newcomers. HA! opportunity, here we go. I love Lisp dialects, though I’ve only dabbled lightly. Let’s talk some Lisp; let’s start a Lisp community that takes heed to my idea #1 above. To be honest, Montreal’s Clojure user group, named Bonjure, is a very nice bunch. Let’s copy their kindness without mercy, while we talk some Lisp problems.

4. Dominus raises a very good point about pragmatism of code solutions. This is the one snag I always trip in while doing test-driven development: after writing a few tests, I get smartypants. I start writing a clever complex solution. It takes time. In the end, it’s useful as-is only as often as it’s not, which I figure as I get to later parts of the task. So much time lost! 

   So, brain, hear this: from now on, when going for the first implementation that gets a test to run, you go for simple. Keep the smart stuff for when simple is not enough anymore. Don’t look over this moment’s shoulder, don’t try to take into account what’s coming after these tests, just do simple. Does it look dumb? Whatever. Does it look inefficient? It’s only looks. Do you think we’ll have to scrap it before lunch? We’ll see. Ok? That’s a good brain.

5. Software is like any human project: sometimes, it’s, you know, finished. That it receives no further update or new feature does not mean it’s abandoned. It’s just right as it is.

   A good example of this is TeX, Donald Knuth’s famous document preparation software. It has not had a single new features since the ’80s. Is it abandoned? No, it’s finished! Besides having received a few bugfixes throughout the 30 years since being feature-complete, it’s used both by itself and within many other document preparation systems, notably LaTeX. Many mathematicians, physicists, engineers, scientists and writers can use //nothing else// to typeset their stuff. So, before pronouncing the death of software that’s not receiving updates, wonder whether it just solves your problem already.

6. Reading is hard. Sure, one can follow the text, maybe even retain some of the material. In all honesty, while writing this post, I am referring again and again to Dominus’ notes: “What was he saying again?” It’s just about four pages long and I have trouble remembering what’s in there. So what’s in that big 500-page book you’ve read last week?

   Reading actively is difficult, I’m often drawn too much towards what comes next to really pay attention. I prefer Andy Hunt’s advice in Pragmatic Thinking and Learning: read once through the whole document, to get an overview of the material. Then, take the time to re-read slowly, taking notes in margins or in a notebook. I must say, while I love e-books for learning, since they’re lightweight and inexpensive, there is just not a single good way to annotate them. I mean, the whole bezel area of my Kindle is covered with annotation graffiti after reading through Hunt’s book. I’ve tried sticky notes, but they fall off the device after a while.

Feel free to share similar wisdom articles from devs or gurus you respect in the comments.