Pareto principle and elimination

April 2nd, 2012

From Wikipedia:

The Pareto principle (also known as the 80–20 rule, the law of the vital few, and the principle of factor sparsity) states that, for many events, roughly 80% of the effects come from 20% of the causes

I saw couple of articles which mention Pareto principle in the context that you should keep (continue doing) just 20% of activities and still you will get 80% of results.

Two important notes on the pareto priciple :

1. It it works only if events are independent.

2. It works only if resulting effect is measurable.

As example, some hypothetical software engineer have following activities:

– develop software

– research

– discuss what needs to be done

– break down complex tasks to simple tasks

– setting up build envinronment

– defining practices

– mentoring junior developers

In the case, if I will eliminate everything what doesn’t produce a product directly than most likely it will cause:

a) a jump in what we measure (as example lines of code)

b) enormous overall decrease in company productivity

P.S. I am all for elimination of unproductive tasks. However, I am against elimination of 80% tasks just for the sake of elimination.

And couple of interesting links:

Setting up Jenkins on Amazon EC2

Handwriting vs Typing

 

8 perfect ways to screw up a job interview

March 26th, 2012

– Don’t show up

– Try to prove that an interviewer is stupid

– Critique extensively everybody who you worked with

– Interrupt an interviewer

– Come to an interview being drunk

– Leave unexpectedly

– Mention that your dog eat your resume

– Come in a tin foil hat

Did I miss anything?

Git rulez :)

March 24th, 2012

I started to use Git couple of month ago.

OMG!!!! I will never get back to SVN (If I will have a choice)

a) Most of operations local. They are super fast and I don’t need an internet connection.

b) I can do 25 local intermediate  commits without worrying that such commit may break somebody else’s build.

c) I can see all untracked files. So, I will never again forget to add a new file to a commit.

d) I can stash my changes and switch easily between multiple versions to fix some bug and to get back to things which I did before.

If you didn’t try it yet, give it a try.

 

Define work

March 21st, 2012

I wanted to write down some reasonable definition of work. I tried to put it in one sentence, but it’s too vague to be precisely defined.

So, I came up with following graph which shows where work sits on the continuum of “have to do”/”will be paid”.