1) fat takes much longer to digest

2) refined sugar/wheat is like a drug. Basically you get withdrawal symptoms that force you to eat more sugar soon. I bet that the food companies love it

3) ... and technically your body can't process over certain amount of protein per day (i think it was 300g). If you eat more than that for some reason, then you just pee it out.

I'm on "paleo diet" + cheese and have lost a lot of weight so far. I don't count carbs and I need to remind myself to eat (lack of hunger).

Besides, specialization increases productivity.

FizzBuzz style questions are really important (eg. create an array with 4 numbers: 1, 2, 3 and 4 and output the values. Oh a "Java and Python 'expert'?". Please in both languages then!). Although I agree that home tasks and trick-algorithm questions are useless.

I don't think home tasks are useless, but they have to used properly. A home task geared to 1-2 hours seems reasonable for an exercise between the first and second interview. Some may say they'll just look up the answer (it's encouraged!), and that's why during the second interview the employer should discuss their answer. If the candidate can explain why they made particular decisions on the take home piece and have an intelligent discussion about the trade offs they took then who cares if they looked up the answer. In fact, the home test is probably closer to real programming since I don't know anyone who codes without Google nearby.

So, my preferred method is to use FizzBuzz as a first cut on the first interview and then give a take home quiz that should take the candidate 1-2 hours or less if they are good.

* Figure out what do you want achieve in the long run (eg individual freedom, another interesting idea that requires much more capital, fly to space, save pandas etc). Does switching/quiting really help you towards that goal? No matter what idea you choose there will be always some less interesting aspects about it. So you need more than "interesting".

* Are your goals/ideas too unrealistic (=loss of interest)?

* start long distance running (helped a lot!)

* be open about what you do (friends, family)! Social pressure is not that bad in your case :)

I hired 2 programmers more than a year ago. One of them was a guy with a lot of experience and another was a girl with only basic programming knowledge (university, first year). It was a valuable experiment, because my gut feeling yelled HIRE HER, but at the time it seemed like a completely irrational decision :)

Anyway I had to let the guy go 4 months later, because he didn't progress fast enough (imho, too lazy/ego). In fact, just after 4 months the girl was already much better!

So how?

* Personality: high intelligence, abstract thinking, perfectionistic tendencies, fast learner

* A good mentor: someone has to constantly look over and point out design flaws/errors/bugs (btw, I had to do it only once with her! With other coders I had to do it at least 2-5 times per bug/antipattern type)

And the most important thing:

* Write consistent code!!! So when you make a bad design error or a bug. Rewrite it again (a function, a class)! And again. And again. Until your code is consistent. Whitespace, curly brackets, comments, variable names, function names, class names. Absolutely everything. It starts with tiny things like:

if(x) {

vs

if(x)

{

When you copy-paste a code snippet from a website - rewrite it so it matches your own style!!! And repeat! And repeat!

When I write Smalltalk, I ignore formatting and indentation. I just write code. When I'm done, I hit Command+r and the editor formats everything for me. This is just one of a billion tiny bureaucratic issues that the Pharo environment handles for me.

(Offtopic: makes me wonder why we don't build programming environments from the IDE down instead of building them from the language up. Our current approach doesn't seem to be working very well, IMO.)

We had a split between founders (business vs technical) about outsourcing vs hiring more people, but I finally gave up. So we outsourced 2 non-trivial components, I interviewed both teams (that was my condition and they were really good!) and of course they shipped.

The problem was that we had to throw both outsourced components out and eventually expand our team. Why?

1) Minor tweaks: code was hard/impossible to extend - no long term thinking and why should your outsourced team really care? They follow the specs! 2) Pivot 3) Expensive 4) No know-how 5) Hidden costs -> communication 6) After some time the code quality dropped dramatically

If you need something YESTERDAY and have the resources to do that... then why not? Just be mentally ready to throw that code away next month.

In retrospect we should have used outsourced teams only for mockups/experimental front-end prototypes and not for the actual product.

Use plain XOR, ROT13 or RC2/RC4. Strong crypto might get you into trouble/extra paperwork later (iOS, US export regulations). And lie if you have to, because that's how it actually works! Security through obscurity! But it should be good enough to stop "casual" pirates/hackers/wannabes.