There Are No Small Delays

Software development is (arguably) one of the most complicated, mentally demanding disciplines, built on increasingly complex layers of abstraction, comprised only by the substrate of thought. One is always juggling multiple complex data and procedural flows in one’s mind.

To quote Dijkstra (a prominent pioneer in Computer Science) on the subject:

From a bit to a few hundred megabytes, from a microsecond to a half an hour of computing confronts us with completely baffling ratio of 109! The programmer is in the unique position that his is the only discipline and profession in which such a gigantic ratio, which totally baffles our imagination, has to be bridged by a single technology. He has to be able to think in terms of conceptual hierarchies that are much deeper than a single mind ever needed to face before. […] For [many], an automatic computer is something like the familiar cash register, only somewhat bigger, faster, and more flexible. But the analogy is ridiculously shallow: it is orders of magnitude worse than comparing, as a means of transportation, the supersonic jet plane with a crawling baby, for that speed ratio is only a thousand.

(The source, while lengthy, is a worthwhile read.)

One consequence is that thought interruptions are costly. Now, a single interruption is always costly, as aptly described in the sort-of-famous comic, “This is why you shouldn’t interrupt a programmer”:

This is why you shouldn’t interrupt a programmer


So a single interruption is quite costly. A delay lasting for one second may cost orders of magnitude more in productive time lost.

Multiple interruptions (even seemingly minor ones) not only add up incrementally, but their total result is even worse than their mere sum, as momentum and concentration needs to be picked up time and again. This includes indiscernible amounts: the same way that a bad shoe or an un-warmed-up muscle might hinder a runner (physical hinderances), if a programmer has to stop to think about anything but the task at hand, it breaks his/her flow. The issue at hand is not (only) the inevitable gradual accumulations of seconds and minutes wasted, but the loss in overall momentum.

Bottom line: There Are No Small Delays. Every delay, sidetrack, interruption – by its very nature – costs many times its size in missed mental productivity.

This why keyboard shortcuts matter. Why short URLs matter. Why dealing with timesheets, bills, and emails is destructive; why you shouldn’t have to ‘just remember this small thing’ like having to turn the light on in the staircase at your office, or one of many passwords; why I never answer the phone.

A moment’s distraction could mean a productive hour lost.

There Are No Small Delays.

Pimp Your RubyMine

(The following is a very technical post, aimed at Ruby software developers.)

0. Introduction

I spend most of my day coding in Ruby. I alternate between two main code editors:

1. Sublime Text, “The Editor You’ll Fall in Love With“, which is truly beautiful and fun to work with. Sublime is sweet.
2. RubyMine, a [big-ass] IDE, Ruby’s equivalent of ‘Eclipse’, which has a lot of shortcomings. While I personally abhor the bloatware and, IMHO, mostly redundant functionalities IDEs offer, three main issues keep me using RubyMine as my dominant code editor (though I alternate):

a. Click-Through to definition
b. Superior breakpoints (set without typing code as ‘debugger/binding.pry’)
c. Superior code inspection and evaluation during debugging runtime

Though I would honestly love to use Sublime exclusively (and in fact, am using it to write this very post), points a-c are deal-breakers for me. Appropriate packages for Sublime Text seem to exist for these, but I have found them to be sadly inadequate/subpar. The end result is I find myself doing most of my day-to-day work in RubyMine. I am (obviously) not the only one, and come to think of it, I believe my team has a slight majority in RubyMine users over Sublime users. Huh.

So, if you too find yourself using RubyMine (and by all means, try Sublime ‘cuz it is awesome), you should spend the due diligence into pimping it up into the best (read: fastest, most lightweight) editor it can be. (This post will focus on usability, not technical performance.) Using RubyMine 6 – whose performance is not bad at all – the following creates an end result which gives Sublime a run for its money.

1. Setup:
– go to preferences: cmd+,
– find the keymap: preferences + search for ‘keymap’
– search for ‘find action’ and change[/add] its keyboard shortcut to shift+cmd+P, as in Sublime.
– Now access keymap via find-action+’keymap’ (Change current keymap)

Boom, now we are on fire. We can search for any action, and assign it a custom keyboard shortcut via find-action+keymap+search (cmd+shift+P, ‘keymap’, ‘Change current keymap’)

The following are some pimped keyboard shortcuts RubyMine offers (along with a few suggestions for changing some keys)

2. Your minimal set of ninja swiss-knife Code Editing/Debugging keyboard shortcuts:

(These are all awesome. You should seriously be using at least the following set all the time.)
find action: shift+cmd+P (see above)
go to file: cmd+shift+O (change this to cmd+P, as in Sublime, via keymap. Consistency [with yourself and with others] is good.).
toggle breakpoint: cmd+F8  (sweet! change this to cmd+B[reakpoint..], and remove the conflicts. )
click-through, go to declaration: cmd+B (sweet!) change this to cmd+D[eclaration..], and remove the conflicts).
go back/fwd: cmd+alt+left/right {recommend switching to cmd+'[‘/’]’}
step over: F8
step into: F7
open code evaluation window: alt+F8
edit keyboard shortcut for anything (as above) – cmd+shift+P, ‘keymap’, ‘change current keymap’, find action name (you can use the default keymap as a reference for action names).

3. Prettiness (it counts):
– set theme (cmd+, search for ‘fonts’) as ‘monokai’ (same as sublime); increase font size to 14. (and save as your own theme name.)
– edit menus appearance to your liking by going to Preferences (cmd+,), the ‘appearance’.
– hide all menus by menu->view->uncheck all toolbars ()
– disable code analysis on right-hand side (next to vertical scrollbar) by right-clicking it, ‘customize highlighting level’, ‘none’. (It actually has some pretty good tips, but syntax tips are notoriously problematic, especially unless the entire team is using the same one.)

Awesomeness. If you have further tips, hit me up. No go forth and remember – real men don’t use the mouse.

Happy New Year, 2014!

Happy New Year!

2013 is coming to an end. As the Hebrew saying says – ‘it was good, and good that it was.’

I look back at my 2013 resolutions and, well – they left some to be desired. 2013 was a year of ups and downs.

But that’s OK. 2014 will be an awesome year; we’ll do all of our previous resolutions and then some.

Here are my resolutions for 2014:

  • Happy. Life is short, let’s have fun.
  • Healthy. No junk food. Work out 3-4 times a week.
  • Save time. Life is short, don’t spend time doing stuff you don’t like.
  • Travel. At least 3 foreign countries, of which at least one is new.
  • Family. Spend more quality time.
  • Write. Blogging once a week, South America first 10 chapters.
  • Experience. Try to do at least one thing every day that makes that day worth it.

OK, time to put our party hats on. Catch you all next year.

Happy New Years! 🙂

RackSh – Console for Rack based Ruby web apps (like Sinatra)

At Fiverr, we are making increasingly heavy use of Sinatra-based services, and need all the productivity knacks we can get. Any Ruby/Rails developer knows the console: the console is your friend, your ally, it will tell you when you are seriously injured, it will keep you awake and angry, and remind you to finish the job and get the hell home. But you know the worst thing about the console? It is not available for non-Rails Ruby apps, such as Sinatra-based apps.

Well, actually it is. Check out RackSh, a no-nonsense gem for console debugging for Sinatra apps. Read the link for the full details, but the gist of it is

$ gem install racksh
$ cd my_sinatra_app
$ echo 'gem racksh' >> Gemfile
$ bundle install
$ racksh

Wham! Console heaven.

A Programmer with a Mac: Contentious Opinions; Nothing is Free

I’ve noticed that many of my professional opinions are [inevitably, to those who know me] out of line with the programming bon-ton, both within Fiverr and outside of it. While these are purely professional disagreements, some of them are quite the touchy subject, and have already earned me (too much?) attention. It seems that ‘plus ça change, plus c’est la même chose’ – this has been the case in every place I’ve ever worked. The recurring theme is that I grow increasingly competent, confident, and (most importantly) emotionally involved (would not recommend this as a best practice). Following a particularly public (professional) discussion that escalated to loud tones, somebody called me ‘Che Guevara’, which might not be historically exact, but that’s not the point: I champion my causes, unpopular as they may be.

As programming goes, since I still consider myself new to the art I try to keep a(n arguably) low profile and accept best practices from more experienced members – being young and learning from others is a privilege quickly and irrevocably lost, so it is worth making the most of it. However, with each passing day I am miffed by certain practices that seem to me to be less than ideal (though usually with their own understandable merit or background). I contend my opinions are and can be articulated and backed by concrete arguments, but still appear to widely differ from the standard wisdom. These topics include preferred languages, coding styles, testing philosophies, and ramp-up procedures, to name a few.

One noticeable meta-opinion I feel keeps coming up in almost every context (beyond just programming) is the people’s amazing tendency to stick to politically ideal notions, without embracing the understanding that resources are limited and that EVERYTHING YOU DO IS AT THE EXPENSE OF SOMETHING ELSE.

Nothing comes for free, and resources are always limited. In an organizational context, this means any measures taken must not only have a net positive impact, but must be considered in terms of how cost-effective it is, and how important it is in comparison to any alternatives. Two examples that we have recently been debating at the office are various types of testing (which everyone agrees might help, but I claim their cost exceeds their value), and Computer Science as a necessary knowledge and skill for software engineering (which I claim can always help, but in 99% of cases is simply either irrelevant, or by far a less necessary commodity than other fields of expertise and experience. I thought this was obvious, but a recent discussion regarding a new interviewee’s skills made me realize this might not be as much in consensus as I had assumed.

These are hard cases to make – in the organization, as anywhere else, touting what good things that ‘need’ to be done is easier than claiming ‘no, this is not important enough to spend our meager resources on it.’ Testing? Yes, it’s good! We must do it! Computer Science skills? Of course it’s crucial!

Everything is crucial. Everything is important. Sadly, your resources are limited, so the wisdom is in being able to define what *doesn’t* matter.

A Programmer with a Mac: Job Definition (Software Engineer vs Programmer)

I never know what to say when people when people ask me what I do. I can’t just say I ‘work in high-tech’, since that is extremely vague (so does my company’s secretary, our marketing people, our QA guy, etc). Am I a ‘software engineer’? That sounds quite pretentious (in Hebrew the subtleties are different, but similar). Is ‘programmer’ a more apt definition? People who build airplanes aren’t ‘airplaners’, but as people have pointed out, I don’t have an engineering degree (just CompSci, pfft), so I’m not really an ‘engineer’ by the formal definition of *that* word. Pertinently, however, it seems relatively little of my time is spent churning out code, and most of it is debating and considering how to best coordinate complicated interactions between separate, intertwining logical [software] components (and interweaving *that* coordination with the inter-human level creating all that). This is a simple reflection of the technological efforts that my company (Fiverr) in its entirety (well, at least the technological stack) is dealing with these days. Perhaps the good news is most people don’t really care that much – the most important thing for them is oh, so can you help me fix my printer? (Just kidding. Nobody has a printer anymore these days.)

A Programmer with a Mac: Fiverr is Hella Cool

Fiverr, as a company and as a product, is – to sum it up in a word – really cool. In brief, it’s a marketplace for services – sort of like ebay, but instead of selling (or buying) materials, you sell/buy services (“Gigs”), as in someone can ‘sell’ creating a logo for you, or video-art, or build a website for you, etc. It’s Thomas Friedman’s “The World is Flat” taken to the limit – anyone can sell (anything), anyone can buy. Other than the business resonance, I was (and am) especially taken by the social implications. Anyone today can set up a website and offer their services online. Fiverr just makes it super-easy: publicity, payments, etc.

When I was interviewing back in January with Sharon, our head of HR, she pitched me the ‘social’ aspect of Fiverr. Basically, she said, it’s good karma: we give people a stage to make money. There are people (quite a few, it turns out) who make a living by selling on Fiverr. And in today’s turbulent economic times, that’s quite a feat. So, it’s a refreshing change from the porn-gambling-toolbars-security shady and murky Internet-waters in which Israel so revels. Wouldn’t it be nice (this is still part of the pitch, remember) to know your work is doing some good to people?

At the time, I remember thinking to myself – what does this lady want from me? Just tell me what tech stack you’re on, how much money you’re offering, and let’s get on with it. It took me another half-year at a corporate intelligence company (and a few weeks in Northern India, pondering the Dalai Lama’s teachings [which sounds wayyy kookier then it actually was]) to decide (or “realize”, as a less introspective person might put it) that there is much merit to Sharon’s point. Karma is important, and helping other people is ultimately helping yourself. (If you don’t swing the Buddhism’s way — and I totally don’t — know this basic truism is well supported by workplace-happiness contemporary psychological studies.)

To be clear, I don’t deal with sellers (nor buyers) on a daily basis at Fiverr. I write code. And to put it in perspective, I’m not saving orphans or curing cancer. But it’s nice to be able to practice your chosen vocation, but at least in a way that positively impacts others.

As an end-note, a couple of start-ups that I think are doing massive amounts of good (especially relative to their size) are Coursera, who are just possibly revolutionizing the future of education, and CouchSurfing, who are making traveling a better experience for everyone, for free. The Wikimedia foundation are also amazing and always worth a shout-out.

Being cool counts.

A (Good) Programmer with a Mac (series)

Today marks my four-month mark as a back-end software engineer at Fiverr(.com), a small (but growing) software company (“start-up”, some might say) in Tel-Aviv. I have learned (and still am) a lot in these four months, and would/should detail my thoughts on these.

We use Macbook Airs at Fiverr. More on that some other time, and I thought this title would be a good title for the series: A Good Programmer with a Mac.

As with any worthy thing, there is a hidden message beneath the bare words, based on a *wordplay of* a famous Hebrew joke. This is my favorite type of jokes: where there are several layers of understanding and perhaps a cultural reference (oh, I did love me The Da Vinci Code); I especially enjoy the glint of people who immediately understand the joke (hint: in this case, the original joke is a Hebrew [racist] pun about ‘with a pen’). I’ve also found this to be one of the best assessors of intelligence – people who can grasp the deeper context of a saying, and immediately at that.

But I digress. I’m definitely a programmer (by trade), and I have a Mac, at the moment. ‘Good’ is as subjective as anything, but you can read the other posts and make up your mind on that.

Social Interactions – Becoming More Notable

One of my favorite topics is interpersonal interaction. I am especially interested in 1-on-1 interactions, but 1-on-many has its moments, too. I recently stumbled across yet another gem on Quora pertaining to this subject and decided I want to log it somewhere for future reference. So, here it is.

בוחן פתע!

בסוף השבוע אומר מורה לכיתה שבשבוע הבא יהיה בוחן פתע באחד הימים. קם תלמיד ואומר שלא ייתכן שהבוחן יהיה ‘פתע’, לפי הלוגיקה הבאה: ראשית, ברור שהבוחן לא יכול להיות ביום שישי, שכן אם יגיע יום חמישי והבוחן עוד לא ניתן, אז התלמידים יודעים שהבוחן יינתן בשישי ולפיכך הוא לא יהיה מפתיע. אם כן, די ברור שהבוחן לא יכול להתקיים (בהנחה שאכן יהיה מפתיע) בשישי.

 מכאן נובע שהבוחן יכול להיות לכל המאוחר בחמישי, ואם יגיע יום רביעי ועוד לא ניתן, אז התלמידים יידעו שכיוון שהבוחן איננו יכול להיות בשישי, הוא בטוח יהיה בחמישי, ולכן יידעו לצפות לו, ולא יופתעו. אם כן, די ברור שהבוחן לא יכול להתקיים (בהנחה שאכן יהיה מפתיע) בחמישי.

 ‘קל לראות’ שלפי אותה הלוגיקה, הבוחן אף לא יכול להתקיים ברביעי, שלישי, שני וראשון ולכן לא יכול להיות מפתיע בכלל. ועם זאת, במבחן המציאות המורה נותן את הבוחן ביום שני וכולם בכל זאת מופתעים. איפה הטעות הלוגית שלנו, אם כן?


למרות שהיא ‘ללא הפסקה’, רק תנסו למצוא בית קפה פתוח ביום חמישי בשלוש לפנות בוקר באיזור צפון אבן-גבירול. אין כזה (בחיפה, אגב, גרג פתוח 24/7. ג’אסט סיינג), וכך נועם ואני מצאנו את עצמנו יושבים לפנות בוקר על פרוסת פיצה שמנונית (12 שקל, 15 עם ביצה, הילדים הערסים מסביב זה בחינם), מתעפצים ומתווכחים, איך לא, על פרדוקס לוגי, הנ”ל.

 הקהל האינטיליגנטי, בוודאי האקדמי וקל וחומר בוגרי לימודי מדעי הטבע, רגיל לראות להטוטנות לוגית ולהניח שאם רק יתרכז לכמה דקות יצליח לזהות את הבעיה ולפתור אותה בנקל. הופתעתי לראות שגם אחרי מאמץ די ממושך, אנחנו לא הצלחנו להגיע לפיתרון מניח את הדעת.

 אם היינו עושים חיפוש איטרנטי זריז על הסוגייה (נגיד, קוראים את הערכים בויקיפדיה או בויקיפדיה בעברית) היינו רואים (רק בגרסה האנגלית, כן? הוכחה נוספת למה אסור לסמוך על הציוֹנים) שלמעשה מדובר בבעיה לא טריוויאלית בעליל, ולמעשה כזו שאין הסכמה לגבי האם/איך היא פתורה. לקהל הסקרן באמת, מאמר מרכזי שמבצע סקירת ספרות אודות הפרדוקס מציג את כל הנושא בצורה מעולה ומהווה קריאה מוצלחת מאוד. אצטט:

 The natural reaction to a paradox like this is to try to resolve it. Indeed, if you have not seen this paradox before, I encourage you to try to resolve it now before reading on. However, I do not want to discuss the resolution of the paradox right away. Instead, for reasons that should become apparent, I discuss what I call the meta­paradox first.

The meta­paradox consists of two seemingly incompatible facts. The first is that the surprise exam paradox seems easy to resolve. Those seeing it for the first time typically have the instinctive reaction that the flaw in the students’ reasoning is obvious. Furthermore, most readers who have tried to think it through have had little difficulty resolving it to their own satisfaction.

The second (astonishing) fact is that to date nearly a hundred papers on the paradox have been published, and still no consensus on its correct resolution has been reached. The paradox has even been called a significant problem for philosophy [30, chapter 7, section VII]. How can this be? Can such a ridiculous argument really be a major unsolved mystery? If not, why does paper after paper begin by brusquely dismissing all previous work and claiming that it alone presents the long­-awaited simple solution that lays the paradox to rest once and for all?

 כהערת שוליים, שועשעתי לראות שגם נועם ואני וגם במאמר הנ’ל, מהר מאוד מבצעים רדוקציה ל’שבוע בן יומיים’, קרי לבעיה פשוטה ביותר: אם אני אומר לך שאתקשר אליך או מחר או מחרתיים, האם תופתע מבחירת היום בו אתקשר אליך? שהרי אם מחר לא אתקשר תדע שזה יהיה מחרתיים ולכן לא תופתע ולכן זה לא יכול להיות מחרתיים, ולכן זה יכול להיות רק מחר, ולכן לא תופתע אם אתקשר מחר, ומכאן אינני יכול להפתיע אותך כלל. ועם זאת, ‘במבחן המציאות’ אם אתקשר מחר – כן תופתע.

 מרתק. בחזרה לביצתנו הקטנה – הבעיה לא נתנה (ולראיה, לא נותנת) לי מנוח. לו הייתי רק ניגש לאינטרנטים, הייתי רואה שלא רק שרבים ניסו ונכשלו לפתור אותה, אלא שגם הפיתרונות המוצעים (וראו המאמר המלונקק לעיל) נסחפו למחוזות אפיסטמולוגים מפחידים, משפטי חוסר-קונסיסטנטיות של גדל ונוסחאות מתמטיות מפחידות. (כאלו שנועם ואני ניסינו לשרבט על מפית ב-3 בבוקר, ונכשלנו כישלון די חרוץ).

 כפי שאומר המחבר Chow, לקורא הסקרן אני מציע לא להמשיך הלאה בקריאה אלא לנסות ולפתור את הבעיה לבד. כפי שאף אומר הנ’ל, נסו להגיע לפיתרון משלכם – אך אם הגעתם, ודאו שהוא אכן פותר את הבעיה, ולא רק מתחמק ממנה. בפרט, לפי טענת האינדוקציה, אני מעוניין לראות פיתרון שפותר את ‘ההשלכה על העולם האמיתי’, שכן האינטואיציה שלי לא מצאה עד כה פגם בהסבר לפיו המבחן אכן לא יכול להיות בשישי (כי אז הוא לא יפתיע), ואם הוא לא יכול להיות בשישי גם לא יוכל להיות בחמישי (כי גם אז לא יפתיע), וכן הלאה. ושוב אזהיר מפני “אשליית המדמ’חניק”, אשר היא “אה, מה הבעיה, אם רק נפרמל את זה אז נראה שיש סתירה פנימית ולכן זה די פשוט”. תראו לי הוכחה.


 אוקיי, אוקיי, אז חפרנו. וכפי שכותב Chow:

why does paper after paper begin by brusquely dismissing all previous work and claiming that it alone presents the long­awaited simple solution that lays the paradox to rest once and for all?

 אני לא קראתי לעומק את כל שאר הפתרונות שכן הם נראו ארוכים ומפחידים. רק ארצה לשתף את הפיתרון שהגעתי אליו בעצמי, בהברקה של התגלות שאני אשמח לקבל עליה תגובות (האם כבר ציינו אותה? אשמח לקבל הפניה, או כל תגובה אחרת). ושוב, אמליץ לקורא הסקרן לנסות את כוחו לבדו במקום להמשיך הלאה, אך ניסיון החיים אומר שאין זה טבע האדם לדחות סיפוקים בצורה הזו. אם כן, להלן דעתי הצנועה לגבי פיתרון אפשרי לסוגיה זו, ולטעות הלוגית (מבחינתי, היחידה?) שבאינדוקציה.

 ראשית אגיד, בדיוק כפי שתואר לעיל, שאם הבוחן לא יכול להתקיים בשישי מפני שלא יהיה מפתיע, אכן לא יוכל להתקיים גם בחמישי, בדיוק מאותן הסיבות. אכן, נניח וטיעוני התלמיד צודקים ולא ניתן לקיים את הבוחן בשישי, אז כבר ביום ראשון עובדה זו ידועה, ואפשר להתחשב בה בכל שלב. לא יהיה בוחן בשישי. ואכן, לפי אותה הלוגיקה, גם לא יהיה בחמישי, וכן הלאה. אני אינני רואה פגם בטענה זו. אם כן, למעשה החולשה היחידה שנותרה לנו לבדוק היא הטענה שהבוחן לא יוכל להקיים בשישי.


 אומר התלמיד – הבוחן לא יכול להתקיים בשישי, שהרי אם יגיע יום חמישי בערב ועוד לא היה הבוחן, אז נדע שהוא יהיה בשישי, ומכאן לא נופתע, בסתירה לכך שהבוחן אמור להיות בוחן פתע. כאן, ורק כאן, האשלייה. שכן, בהגיע סוף יום הלימודים ביום חמישי (או בחצות) – *רק* באותו הרגע התלמידים מבינים שהבוחן עומד להיות בשישי וזוהי הפתעה עבורם. באותו הרגע הם מגלים שהבוחן יהיה בשישי. הם לא ידעו זאת ‘מראש’, וזהו רגע ה’הפתעה’ של הבוחן. וכך הבוחן אכן יכול להיות בשישי והוא אכן מפתיע.

 ההבדל היחיד נעוץ בכך שאילו הבוחן נערך בחמישי (או רביעי, או שלישי) התלמידים ‘מופתעים’ ורגע  ההפתעה הוא רק ברגע הבשורה על הבוחן (אם נניח לשם פשטות שאת הבוחן נותנים בהתראה של רגע). אם המבחן ניתן בשישי, אזי רגע ה’הפתעה’ הוא אכן בלילה הקודם, אבל הוא אכן מפתיע. וכך, הבוחן יכול להינתן בשישי והוא אכן יהיה מפתיע. מיד נפתרת גם הבעיה של יום חמישי, וכך הפרדוקס כולו.

 הרחבה להסבר יכולה להינתן אם נדמיין שהבוחן יכול להינתן בכל רגע ביממה, בהתראה של רגע, ונמשך רגע בלבד. קרי, נוריד את הדיסקרטיזציה של הימים. כאן, כך נראה לי, ברור עוד יותר שאין שום בעיה של הפתעה: עד לרגע הלפני-אחרון אין התלמידים יודעים מתי ייערך הבוחן, ורק ברגע הלפני-האחרון הם יודעים שהבוחן ייערך ברגע האחרון – ואז הם מופתעים, בדיוק כמו לפני כל רגע אחר.

נראה אם ל-Math Overflow יהיה משהו חכם להגיד בנושא:

 Today was a good day for science. 🙂

 הערות, טענות, בעיות, מענות, ופרס נובל ניתן לשלוח לי ל