30% feed back when 30% done.

Good article on dealing with feedback and how to give and receive it better.

Copied and pasted most interesting section. Source: http://blog.42floors.com/thirty-percent-feedback/

How to Build 30 Percent Feedback into the Culture of Your Startup

Lead by example

Duh.
Don’t worry about anything else below if you can’t there.

Ask for it explicitly

You have to be deliberate because you’re fighting against an innate fear most people have: fear of rejection.   Some of your best people are accustomed to being good at everything they do, so they may be the toughest to get on board.
You have to explicitly ask people to be on board with this concept.

Reward People with great feedback

Whenever someone comes to you for early feedback you have to reward it.  If, even just once, you reject someone’s draft because it’s not polished enough for you, you’ll teach everyone else in the organization to always be 100% done before approaching you.
Execs at big companies may want everything perfect before it gets to them, but that’s no way to run a startup.

Praise Speed

When someone takes way too long to get a first draft out because they’re being perfectionists and you praise them for their quality craftsmanship, it teaches everyone to do the same.  You should, instead, praise people that move incredibly fast.  We always strive for one week.  Even for the most complex projects, we try to see what can come out as a first draft within one week.  From that point on, they can get feedback and start iterating.

Demo Regularly

Set up the company for everyone to demo at your weekly meetings, regardless of what stage their project is in.  It’s more of a show us whatever you have.  PG would do this to us at YC, making us demo every week.  It was both daunting and humbling.  But once we got used to it, we actually got addicted to the immediate feedback.  That’s the culture you want.


One final note.  Every once in awhile you’ll still have to give someone  tough feedback when they thought they were 90% or 100% done.  It always feel shitty to have throw away work.  But hopefully with this system, it will happen much less.  And the result will not only be better products, but happier people.

Software methodologies..

"Once a programming team has adopted a methodology it’s almost inevitable that a few members of the team, or maybe just one bully, will demand strict adherence and turn it into a religion. The resulting passive-aggression kills productivity faster than any methodology or technology decision."

http://typicalprogrammer.com/why-dont-software-development-methodologies-work/

Code Reviews and Bad Habbits

Quoting particular sections:

There are two fundamental problems with single-patch review systems:

1. They encourage lumping at-best-weakly-related changes together. Frequently, when I start implementing a new feature, there are at least three steps: first, refactor the existing code to make it clean to add the new feature; next, add the new feature; and finally, add unit tests. The bigger the feature, the more likely each of these steps is likely to itself consist of several logical steps. If you can store several distinct commits in a single review, then you can simply keep these commits grouped together. But if I’m in a single-patch system, I’m going to be strongly encouraged to do everything in one massive commit. That’s especially frustrating because refactoring existing code, and adding new code, get lumped together, demanding much more mental energy on my part to figure out what’s actually going on in a given review.
   You might argue that you can keep the patches split, creating one review per commit, but that’s actually worse. At best, you’re now separating the tests from the feature, and the refactoring from the motivation for the refactoring. But the real issue is that many single-patch systems make it very easy to approve any one of the commits in isolation, which is exactly the opposite of what you want. Thus, one-review-per-commit switches the balance from “annoying” to “dangerous.” Not really an improvement.
2. They encourage you to hide your history. The whole point of a source control system is to tell you the history of how code got to be the way it was. I want to be able to see what it looked like yesterday, and last February at 2 PM, and anything in between. Sometimes that’s because I know that the code worked then and doesn’t now, and I want to know why, but lots of the time, it’s because I want to know why a given change was done. What was the context? What was the motivation? When you just keep updating one single patch the whole time it’s under review, I’m losing tons of history: all I’ll get is a single finished product as a single patch, without any of the understanding of how it got that way.

http://bitquabit.com/post/code-reviews-and-bad-habits/

Building emacs 24 on Ubuntu 13.10, 14.04, and 15.10

1. sudo apt-get install autoconf texinfo libtiff4-dev libgif-dev libxpm-dev libncurses-dev
2. git clone git://git.savannah.gnu.org/emacs.git
3. cd emacs/
4. ./autogen.sh
5. Not interested in makeinfo at this time, so
• ./configure --without-makeinfo
6. make
7. sudo make install

Updates for 14.04

For step 5, use ./configure --without-makeinfo --with-tiff=no

Updates for 15.10

For step 1, use sudo apt-get install autoconf texinfo libtiff-dev libxpm-dev libncurses-dev libgif-dev libjpeg-dev libgtk2.0-dev

Notes on solving a Rubik's Cube 3x3

Top Layer

Second Layer

Third Layer Sergs B. Third Layer Video

• Make cross (frur'u'f')
• dot
• frur'u'f' with any face
• will lead to l shape
• l shape 
• frur'u'f' with one leg of l pointing towards you, and the other pointing to the right
• will lead to line
• line
• frur'u'f' with line horizontal
• will lead to cross
• Align cross (ruur'u'ru'r')
• two sides should be lined up
• colors are on opposite ends
• ruur'u'ru'r' hold with one color on front and one on back
• will lead to colors at right angle
• colors at right angle
• ruur'u'ru'r' hold with one incorrect side on front and one on right
• all four sides will be lined up
• Place corners (l'uru'lur'u')
• place corner piece in between the three correct centers, not necessarily correctly oriented
• all corners incorrect
• l'uru'lur'u' on any face
• will lead to one corner correct
• one corner correct
• l'uru'lur'u' with correct corner on front right face
• repeat once again.
• will lead to Rotate corners
• Rotate corners (ruur'u'ru'r'l'uulul'ul)
• three corners incorrect
• ruur'u'ru'r'l'uulul'ul with correct corner on front left
• two incorrect corners on opposite corners
• ruur'u'ru'r'l'uulul'ul with one incorrect corner on front right with top color facing right
• will lead to two incorrect corners on same face
• four incorrect corners
• ruur'u'ru'r'l'uulul'ul with two corners incorrect with top color on front and back on the right face
• repeat once again, will lead to two incorrect corners
• two incorrect corners on same face with top color on front and back
• ruur'u'ru'r'l'uulul'ul with two incorrect corners with top color on front and back on the right face
• will lead to two incorrect corners on same face with top color on same face
• two incorrect corners on same face with top color on same face
• ruur'u'ru'r'l'uulul'ul with two incorrect corners on right
• will correctly rotate the two corners

The Curse of the Toxic Peer Review

A peer review system is meant to do two things:

1. disseminate knowledge and understanding of how a new module works
2. help train the developer group as a whole on what the best practices are for the development team considering that best practices are expected to evolve over time.

It IS NOT meant to be a tool used by the authority-needy to impose their judgements for the day's set of finished code.  If one single person on a team of 3 or more does all of the pr's, then you are doing it wrong.  If the rest of the team feels that they need to run pr past a single person, you're doing it wrong.  For the code being pr'ed, if individual teammates are not able to independently come up with the same set of criticisms, you are doing it wrong.  If there are no clearly stated requirements and standards of good code, you are doing it wrong.  If your junior members do not seem to be understanding what is required of them in order to get their pr merged into the development branch without completely rewriting the code, you're doing it wrong.

There are also requirements for who can do pr's.  It is expected that those doing pr's know the code base they are working in and know what is expected from them when writing code in the particular language.  A developer who is uninformed and unable to demonstrate understanding as to what the current developer group standards are should not be doing pr's.

• Why are setting up a peer review system?
• Do you know what you're looking for when code is submitted for review?
• it's been linted
• it has tests
• you can run the tests and see that they pass
• the documentation is sufficient to understand how to use the code without asking the author for more details/information
• you understand how the code works and can demonstrate it

If you find yourself in the situation where you are the main person all PR's go to or if you feel that your teammates are not doing what you expect from them when they do pr's, it is YOUR job to discuss the situation with them and get on the same page across the team.

Considering that newer developers may not feel they carry enough weight to address a toxic peer review situation where a senior developer is in charge of all PR's, it is the manager's job to ensure that proper peer review policy is carried out.  If not handled properly, a peer review situation is not just useless, it's actually harmful in that it glorifies and deifies one or two developers to the point where a company feels it is completely dependent upon those individuals and behaves as if they are the saviors for the company.  This is not a good situation for any company to be in considering how fickle many developers are and the likelihood of any good developer sticking around for more than a year after an ipo is rather low.

You are trying to create a good product, you are trying to create a successful company. You owe it to your teammates and the rest of company to do more than simply wish that you could clone a particular developer.  You owe it to them to set up a proper peer review system such that information and understanding is spread across all developers in a team as easily as possible.

Lemoncello

95.5% alcohol
10 zested lemons
750ml of alcohol
1000ml water
600ml sugar

75% alcohol
10 zested lemons
750ml of alcohol
750ml of alcohol
550ml of sugar



Zest lemons, put lemon zest into mason jar with alcohol for 1 month.

Stir the water and sugar in a large saucepan over medium heat until the sugar dissolves, about 5 minutes. Let Cool completely.

Strain lemon zest from alcohol.

Add alcohol to syrup.

Partition into 500ml bottles and place in freezer for 1 week.