15
August
2009

An Allman Brothers Band special on 106fm

A couple of months ago I had the pleasure of being a guest editor of an Allman Brothers Band special on 106fm radio. You can listen to it online by opening this link and looking for the “23.04.09” show. The playlist is here .

13
July
2009

Praise the unintelligent user interfaces

Some 18 months ago I started writing a post which was (sadly ?) forgotten called “Programming as if the user experience doesn’t matter”. Today I came across this wonderful post which wisely says

Stupid is predictable; predictable is learnable; learnable is usable.

Perhaps the time has come to dust off my post…

30
August
2008

Emacs: kill-matching-buffers-by

Nothing fancy here, just some emacs functions that assist in killing multiple buffers based on buffer name or file name. I wrote this to help me cope with the large number of log files I so frequently open in emacs (where else?).

(defun act-on-buffers (pred action)
  (let ((count 0))
	(dolist(buffer (buffer-list))
	  (when (funcall pred buffer)
		(setq count (1+ count))
		(funcall action buffer)))
	count))
 
(defun kill-matching-buffers-by (acc)
  "Kill buffers whose name matches the input"
  (let* 
	  ((re (read-string (format "kill buffers matching: ")))
	   (match (function 
			   (lambda (buf) 
				 (string-match re (funcall acc buf)))))
	   (kill #'(lambda (buf) (kill-buffer buf)))
	   (count (act-on-buffers match kill)))
 
    (message "%d buffer(s) killed" count)))
 
(defun kill-matching-buffers-by-name ()
  (interactive)
  (kill-matching-buffers-by 'buffer-name))
 
 
(defun kill-matching-buffers-by-filename ()
  (interactive)
  (kill-matching-buffers-by #'(lambda (b) (or (buffer-file-name b) ""))))
26
March
2008

Easier path construction using overloaded /

At long last I found a justifiable use for operator overloading. Recently I’ve been writing quite a bit of rake files which involved a lot of path construction, like

 path = "#{all}/#{along}/#{the}/#{watch}/#{tower}"

Noticing all those extra characters required to create the path string I realized that the / operator can used for concatenation in this specific use case

class String
  def /(other)
    File.join(self,other)
  end
end

and then we can write a much cleaner version

 path = all/along/the/watch/tower

I wouldn’t advocate the usage outside of a rake file or other path construction intensive code, but for these specific scenarios it is pretty sweet.

Also posted on dzone snippets

22
December
2007

Hunger for success?

Hunger is a primitive urge that requires immediate satisfaction. It commands your thoughts and demands a short term remedy often ignoring the most obvious consequences. I find it extremely odd that it is so commonly used by the industry as a positive quality sought for in candidates particularly for management/sales positions. If hunger for success resembles hunger for food, a hungry employee (or worse manager) is likely to cut corners, to ignore longer term goals, to disregard his co-workers (or worse, his subordinates) and generally to dutifully serve the company only when it is aligned with his immediate goals. Loyalty and strategical thinking should not be expected.

Indeed hunger may foster some creativity but it can not seriously be considered as a state you want to stay in. And frankly who on earth would consider starving himself just to keep himself motivated? Hunger is basically a primal urge that can overtake your mind just like that other primal urge that assumes control over your mind. And you don’t see job descriptions looking for “horny managers”, do you (although I guess many would apply) ? This isn’t just an unfortunate choice of words – it is very much consistent with the current “set of beliefs” of the industry. I can go on and on ranting about the lack of values, short-sightedness etc. but I guess the point is clear.

13
July
2007

Happiness Is

Happiness is finding out in the middle of a run while Since I’ve been loving you is playing on your iPod, that you can turn the volume up. Way up.

30
June
2007

A lesson from Dune

I’ve literally read Frank Herbert’s Dune dozens of times1. Other than being a fantastic SF book it contains some pearls of wisdom that apply to many situations in our day-to-day lives.

One of the quotations I like the most is

Give as few orders as possible. Once you’ve given orders on a subject, you must always give orders on that subject. – Duke Leto Atreides, “Dune” (Frank Herbert)

When leading (ahm, and yes, managing) development efforts I’m often in a situation when a developer asks me to make a decision regarding her work. If I think however it is an issue that falls well within the territory and responsibility of the developer, I try very hard to let her decide. No, I’m not trying to avoid decision making (always a pain), I’m just trying not to “give orders” (as the Duke puts it). You see, if I make the decision I have in essence minimized the (good) responsibility areas of the developer and her ability to freely progress in the future. Now she has less space to operate in, less room to express her ideas, and she is becoming more a “doer” than a “thinker”. So overall the freedom of the team to develop as they think is right is hurt. And if that wasn’t enough, your decision on outcomes of this decision (like the evolution of that particular feature or design) will always be required, and the scalability of the team as a whole is affected.

This practice, of minimizing the decisions you make for your developers, is even harder to follow when you have a strong opinion about something one of your developer is (or is about to be) doing. For example he is about to write some fancy lock-free data-structure while you think plain old synchronized hash table will do. As long as his plans are not colliding with the overall design and the extra effort isn’t dramatic it is better to let him do what he feels is right. Above all, it is a local decision within his territory, an area which he surely knows better from anyone else. If you force him to use your solution, don’t be surprised when every little obstacle he encounter will result in him calling you to fix it for him and again you turned a thinking programmer into a robot that just follows your orders and avoids exercising his brain. A living REPL .

Indeed a mistake can be made when the decision is the wrong one. So what? Didn’t the developer and hence the team just enhanced their experience? Hey, aren’t you still making fullish mistakes? As long as the mistake is well contained within acceptable boundaries no real harm is done. It is your responsibility however as the lead to make sure such boundaries exist, so mistakes are quickly identified.

True, this practice can’t be applied with less experienced or less capable employees, but I try very hard to make sure everybody who works with me is at least capable of making smart decisions regarding her own work. Otherwise, why hire them?

1 Incidentally, I once read that the Hebrew translation of Dune exceeds the original. That’s a bold statement to make, but even if it isn’t true, the Hebrew translation is very very good.