Just as side note. “Agile methodology” is an oxymoron. If it’s methodology and you have to follow it whatever happens then you aren’t agile and if it’s agile than you shouldn’t try to define rules written in stone (methodology).

And only now, after 4 years of doing different Agile But, I finally started to work in real agile environment.

I believe there are two core reasons, why company practices Agile But:

- A company does agile just because it’s a new cool thing and the company wants to get another boy stout badge for being kind-of Agile.

- Some engineers are frustrated that releases are always late and their buts got kicked as result of that.

These are WRONG reasons to do agile. In both cases it’s seen as just another initiative. A lot of people thinks – oh… well. if it help that’s fine, if it won’t help – no big deal. As result, most likely no resources will be allocated to it, no serious changes will be done.

I think,real agile can come only from the top of the company. As soon as owners of the company understand that

- The world is complex thing and any assumptions needs to be checked (the faster the better)

- Resources are very limited and it’s absolutely critical to do most essential stuff

they formulate very simple idea – being Agile (especially for a startup company) isn’t just another initiative, but rather live or die decision.

Immediately as soon as you decide that’s it that critical you will know the answers to questions like  why do we need short releases, automating testing, automation builds, get functionality to real Done state, constant prioritization, fighting technical debt and so on. It just sets number of additional positive constrains which pushes you  into correct direction.

We are looking for a senior programmer to conduct research and develop prototypes related to Android security at all levels of the Android stack.

You must have the following skills to qualify for this job:

- Passionate about solving complex low-level problems (any OS platform)
- 1+ year of Android development
- 3+ years of Java experience
- 3+ years of C/C++ experience
- 5+ years of overall software development experience

The following skills are not required but are considered a plus:

- Knowledge of Android operaint system source code (AOSP) – big plus
- Experience with open source
- Experience with Linux internals
- Experience in mobile development (e.g. iOS, Symbian, Windows Mobile)

- Businessman

He/she should be all about money – make sure that there is enough money, track cashflow,  kick everybody asses to bring in the revenue.

- Visionary

This person should think strategically – where do we want to be, what problem do we want to solve, how could the company be the best in what it’s doing.

- Builder

This person is all about tactic – choose a next step and just do it.

You don’t have to have three actual persons. One person can wear several hats, but without a doubt founders should cover all three roles between them.

If you are working at a job which you know exactly how to do – it’s time to change the job.

If you are constantly doing tasks which you know how to do perfectly – you have to do something new.

If you have answers to all questions then your questions are wrong.

Here is snippet of its description:

“SpydrSafe Mobile DLP™ provides app-level protection for all of the data on your Android smartphone or tablet.

Your mobile devices contain all of your personal data. Keep it safe with SpydrSafe Mobile DLP™. Protect any app on your mobile device—email, Facebook, texts, photos, mobile banking apps, mobile wallet—any app on your mobile device can be secured with SpydrSafe Mobile DLP™.”

You are welcome to:

- download an use it

- send us your feedback

- leave positive reviews

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

- 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?

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.

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