Oh god, you're right, they did! That's horrible!

If I want to do something, say, work on a project, I set a timer for 30 minutes and start working on the project. My rule for myself is that for 30 minutes, I have to work on the project, even if I'm banging my head against the wall and not making any progress. After 30 minutes, I either keep working (if I'm in the zone), or stop, re-evaluate and repeat - but never stop before 30 minutes is up. At first, this was painful, but now it's pretty easy to get into the flow. I do this also with things I really don't enjoy, like dishes and housework.

While I think that the rule itself is arbitrary, I think what it did was help me to build discipline, which was immensely important.

Then, video games and other entertainment go at the end of the day, where I can enjoy it guilt free - and importantly, where it can't overlap with work. One nice thing is that I don't feel guilty having fun anymore. Of course, I'm not so strict, sometimes I wake up on a Sunday morning and play games for three hours, but generally I try to stick to this plan.

As other people have said, you need to separate what you need to do over what you want to do.

Another technique that I use is to separate work space from play space. I'm not going to go and play Starcraft II (my chosen drug) in a Starbucks, so if I'm feeling particularly distracted, I'll go there to do work. I live in NYC so I don't have the luxury of having a spare room to use as an office, but if I did I'd seriously consider setting up an office separate from my main desk (ie. have a video game computer and a serious computer).

Finally, start slow. Lots of people look for big overnight change, don't get it, and revert to old habits. Instead, start slowly. Do one of these 30 minute sprints each week day, and two each weekend day.

The code is pretty simple - very similar to what you did:

	  function (func, wait, immediate) {
	    var timeout, args, context, timestamp, result;
	    return function() {
	      context = this;
	      args = arguments;
	      timestamp = new Date();
	      var later = function() {
		var last = (new Date()) - timestamp;
		if (last < wait) {
		  timeout = setTimeout(later, wait - last);
		} else {
		  timeout = null;
		  if (!immediate) result = func.apply(context, args);
		}
	      };
	      var callNow = immediate && !timeout;
	      if (!timeout) {
		timeout = setTimeout(later, wait);
	      }
	      if (callNow) result = func.apply(context, args);
	      return result;
	    };
	  }

Empirically, I can't type fast enough (sustained) for throttle to be better than debounce here — there are frequent 200ms gaps in my key presses. This is part of why I was confused. I thought I was typing very quickly, definitely faster than 43wpm == five keystrokes per second, but apparently I slow down to think now and then. My code seemed to behave like _.throttle already, but changing the timeout from 200ms to 2sec made it clear that it wasn't.

But I'm switching to _.throttle, partly in case someone is a faster typist than me, and partly because it makes a leading-edge call, which may give a feeling of greater responsiveness.

1. http://drupalmotion.com/article/debounce-and-throttle-visual...

  _.debounce: [...] Useful for implementing behavior that
  should only happen after the input has stopped arriving.

Right after your quote, the docs add: "For example: rendering a preview of a Markdown comment, recalculating a layout after the window has stopped being resized..." These operations can both be very expensive on the client side — layout is slow — and can also distract the user if they make stuff jump around on the page. The downsides of doing these updates too often are more clear than for a simple autocomplete.

But obviously, in this case, the interviewer specifically outlined requirements that would make debounce the better choice than throttle.

In that case, showing live updates in the window during resizing might not be worth it.

In the class, he defines a closure as follows:

"We have said that functions are values, but we have not been precise about what that value exactly is. We now explain that a function value has two parts, the code for the function (obviously) and the environment that was current when we created the function. These two parts really do form a “pair” but we put “pair” in quotation marks because it is not an ML pair, just something with two parts. You cannot access the parts of the “pair” separately; all you can do is call the function. This call uses both parts because it evaluates the code part using the environment part.

This “pair” is called a function closure or just closure. The reason is that while the code itself can have free variables (variables that are not bound inside the code so they need to be bound by some outer environment), the closure carries with it an environment that provides all these bindings. So the closure overall is “closed” — it has everything it needs to produce a function result given a function argument."

(section course notes: https://d396qusza40orc.cloudfront.net/proglang/lecture_slide...)

[0] -- http://shop.oreilly.com/product/9780596802806.do

I found that to be a really valuable shift in the way I processed the phrase "free variable".

This is a distinguishing trait of every great manager that I've worked with.

If it's genuine, or at least convincing, I would agree.

I've witnessed a few attempts at this which clearly didn't meet that criteria and it was nearly the most off-putting managerial song and dance I've ever witnessed.

I get the impression there's a certain group of people who read lists like these online or in a book somewhere and go about mimicking them without understanding the underlying prerequisites.

Eating the failure and giving the success necessarily requires a total understanding of the actual successes and failures.

Without that, the selfless routine is doing everyone a disservice by hiding the actual problems and quashing further discussion that might reveal them.

As a somewhat of an aside, I notice this disturbing tendency a lot in rookie salespeople. One of the bits of sales advice everyone appears to have read in some list somewhere is something about mirroring and first names.

It would creep me out (and trip the "douchebag alert!" signal) every time I spoke to a salesperson who would poorly imitate my mannerisms and keep jamming in my first name between their words.

Outside of the team, ultimately the manager is responsible for delivering. That is their job, and with a good manager, the buck stops at them - without exception. If they don't deliver, it is their failure - even if that failure is a result of their reports failing to deliver, or unrealistic requirements from their superiors. Perhaps the appropriate internal action for that failure is to discipline their reports, but ultimately they are the captain of their ship, and should be the first one on and the last one off.

Obviously, all this assumes that it actually was a valid mistake. In the rare case where the failure was caused by gross negligence or intentional misconduct, then you should take responsibility for hiring and trusting them, and then you should fire them.

1. Pick a task, and explicitly state my goal. You could write it down, but the point is just to have a better than high level idea of what you're doing it, so I just usually say it out loud to myself. For example, "Make the submission form for the user signup page".

2. Spend 30 minutes uninterrupted working on this goal - even if I'm stuck, poke at things, read documentation, do anything to move forward in the task even if just a little bit.

3. After the 30 minute mark, keep working on the task until I loose steam - and not necessarily at the task at hand. Sometimes I'll keep working for another four hours at this point, other times I'll stop at the 30 minute mark to regather my thoughts (but never before). Take a break, and then GOTO 1.

I do this with more than just programming - practicing piano, reading, running, cleaning, etc.

I find that the first 20 minutes of working on things are the hardest, since I'm still in the mode of formulating a problem, and filtering out information, distractions, etc. Building focus. So I would take breaks, surf hacker news, etc. Eventually I would get through that 20 minutes, but it would take a lot longer than 20 minutes. This forces me to get through that 20 minutes.

As a programmer, it can be hard to separate work from rest time (ie. does a 2 minute hacker news break while unit tests are running count as work, a break, or is it just wasted time?), and so I am trying to be more clear to myself about separating the two.

While I've never tried the pomodoro technique, at the surface it strikes me as too rigid. Some days I can work for hours on end without blinking - so all that I need is that single catalyst to kick off a day of productive work. Others, it takes all of my will power to write five lines of code. So I want something that pushes me to start, but gets out of the way after that.

Does anyone have experience with similar things?

1) getting "in the zone" takes less and less time. It used to take me most of my 20 minutes to actually get focused. Now, 3 or 4 minutes suffice.

2) the level of focus I reach is unusually high, especially for technical subjects.

A final remark is that I realized that you can do a lot of things by spending only 20 minutes every single day. A lot of things indeed.

You keep cars on the periphery of the city, and have good public transit to and from them. So your 30 minute trip turns into a 20 minute public transit ride to your car (or a 10 minute taxi ride), and then say a 25 minute drive - longer than before, but not 4 hours. So no, you are not "fucked over".

And presumably, this comes with an increase in public transit quality. Most cities now are built around cars, but they don't have to be. Also, something like this would have to happen gradually - make dedicated non-private vehicle lanes (buses, taxis, etc), build up public transit, disincentivize cars via taxes and zoning, etc.

A place that's perhaps in range of this is Manhattan - most people I know, quite successful, don't own cars - and the ones that do use them to get out of the city on weekends, not for daily transit. It's a place where owning a car is pretty much worse than not - expensive and rare parking, high insurance, congested roads, etc. No joke, I know at least one senior executive here who doesn't have a driver's license because he let it expire.

And why do this? Because we should be building safe, healthy, happy, sustainable and affordable cities - something which cars are not contributing too. So ban them outright? Of course not - but maybe phasing out private vehicles in cities over the next 20 years is something worth seriously considering.