mdkess's comments

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;
	    };
	  }

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...)

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.

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

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?

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.

Imagine we enter an agreement - you'll lend me $100 for a year, and I'll pay you $10 after a year. The banks will pay you $5 to borrow your $100, so you think this is a good deal.

After a year, I pay you back the $100, but I don't have my $10 for interest. I'll pay you back as soon as I can, I swear, seeing myself to the exit. Five years later, true to my word, I give you the $10. So you get your money eventually - is this a good deal?

Well, no, of course not. It may be better than the bank still, but it's not as good as the deal initially made it appear. You could have taken my $10, given it to a bank for the next five years and - assuming you didn't reinvest interest payments out of a noble desire to make math easier for yours truly - made $0.50 each year, for a total of $2.50. What's more, I could have done that, effectively reducing my debt to you by 25%.

Of course, this isn't on that scale, but that is the risk of delayed payment.

I guess the thing that you should realize though is that this isn't a degree in computer programming, or IT - it's a more or less a mathematics degree. As the saying goes, "Computer Science is no more about computers than astronomy is about telescopes."

If you want to get ready for serious computer science, I'd recommend a few things which are what I think I got out of my undergraduate degree:

1. A solid understanding of algorithms and data-structures. To this end, topcoder.com/tc is invaluable and some serious study will quickly bring you up to speed. CLRS (Introduction to Algorithms) is a great resource, as is train.usaco.org.

2. A basic understanding of theoretical computer science. To that end, I found this a really useful book: http://www.amazon.com/dp/0321455363

3. Basic understanding of networking and operating systems. Not sure the best route here, there must be online courses. Not too many great self-study books in this area, unfortunately. So find some online courses.

4. A decent math background: linear algebra, calculus, combinatorics, and probability. For self study:

    Calculus: Stewart's Calculus is great.

    Linear Algebra: I've yet to meet a linear algebra text I liked, so not sure here.

    Probability: A First Course in Probability is an outstanding textbook.

    Other: Concrete Mathematics by Knuth is an incredible book, very VERY hard and took me a long time to get through, but packed with useful and interesting information. I'd recommend it after the rest of these.

Also, keep writing lots of code. Daily practice is the secret to everything.

Basic income is just a redistribute tax mechanism, but it's one that tries to remove bureaucracy and politics from social security programs surrounding qualifications, etc.

  <div ng-controller="QuoteCtrl">
    <shirt-chooser></shirt-chooser>
    <color-picker></color-picker>
    <size-picker>
       <size-picker-choice label="SM"></size-picker-choice>
       <size-picker-choice label="MD"></size-picker-choice>
       <size-picker-choice label="LG"></size-picker-choice>
       <size-picker-choice label="XL"></size-picker-choice>
    </size-picker>
    <number-picker></number-picker>
    <order-summary></order-summary>
  </div>

Now you get the added benefit that you can test directives individually, as well as the whole controller. Right now, if you do some restructuring of the page, you could end up in a situation where you break all of your test cases. I mean, in this case it might be overkill, but as a general principle I think it's the right approach.

Anyway, looking forward to see what you do next!