Accounting for time spent on different tasks (when there are many and hectic) and doing the actual accounting (instead of your accountant) are both tedious tasks. Did them both today and I can say only this: If you cannot do one, you are for sure bad at another.

This leads me to the tools like Toshl and Toggl. As always, it is paramount to actually have the tools mobile, with you. This way, you can create a habit (quite the same as with myFitnessPal). You will know your finances with this approach – always. And, much more importantly, you will know how you spent your time. After all, time is finite.

Made breakfast. First snow this winter. Little one mega excited, so we had to go to the hill nearby. Was walking on the lake after… 25 years. Two major accidents avoided. Watched female ski jumping. Watched a movie.

Interesting problem cropped up today. While working, it became evident that part of the people I should get concrete results from by the end of the day, got confused. We exchanged several emails, with no real progress. I tried to be very specific, wrote emails with appropriate summaries, process and action oriented – no result.
We then decided to switch to voice and organised a conference call. At the beginning, there was again some confusion. Of course, we come from different organisations, from different backgrounds – we needed to establish the basic understanding, or at least, establish basic translations between words and known concepts.
After this initial phase, things went like a charm. We finally understood each other, finally decided on the initial phase, set goals and actions.

What I took from this experience:

• Be positive. It is never easy to switch contexts, gears and vocabularies.
• Repeat after people in your own words. This enables everyone to get to grip with different vocabularies.
• Never assume people aren’t smart, just because they don’t understand your jargon. It is you, that is living in your bubble and it is you, being incompetent and not able to express concepts in layman terms.

It seems every year there is the above mentioned run around the local (artificial lake). It is rather odd that I didn’t know about it, but then again, I have been always rejecting this kind of “mass events”. In any case, I am happy to say, I participated in the 42nd iteration ;).

I must admit I was amazed that my wife and daughter decided to join – actually, when my father in law decided to join, that was even more over the top. After two spine operations, this was something that I wouldn’t expect of him.

After 2.5hrs, going up and down around the lake, we made it. Tired. But satisfied.

Next year again!

The past year was kind to me. It was full of challenges, but the good version of them, the ones that make you grow and not “build your character”. I sincerely hope and wish 2017 is to be the same ;).

But let’s see.

In any case, I decided to write on daily basis. It may be just a pure observation, something short, whatever – a fixed point in time where you stop, think about your day and write something down.

Let the 2017 begin. A new year, a new adventure. Or, the continuation of the old one ;).

After several years in management, one forgets how to work with git (on the contrary, one never forgets how to work with vi – I guess it has to do with the pain of the experience).

The tools: If you are working on Windows/Mac, you can get SourceTree. If you want to go vanilla, opt for official client, which is cross-platform.

I went for the latter, but still installed SourceTree – it is very good for branch visualisations, which means it is good to have at hand. Also, the official client, at least on Windows, adds git-bash, meaning you have your old linux commands at hand, along with the vi.

Let’s start with the configuration. First, config your name and email. This helps with all sorts of questions later on.

git config –global user.name “Your Name”
git config –global user.email you@example.com

Once this is done, go into folder, where you want to have the git files. Start with:

git init
git add README.md
git commit -m “first commit”
git remote add origin <whatever it says on github>
git push -u origin master

This will get the master version from GitHub on to your local repository. OK, now you have the code locally. Pay attention to the two-step process when working with git. Fetch only gets it for you, but you cannot see it. Merge will actually merge it locally with your local data. The same for add/commit and push.

Let’s discuss some customs, when working with git.

It is customary, to branch master into your own branch – that’s where you work, experiment and finally add, commit and push changes to the branch on GitHub, where you create pull requests. These are then reviewed and merged.

Let’s proceed in customary fashion and create a branch:

git checkout -b newBranch

Now you pay attention – you will see the name newBranch or master along your commands – this is important as it shows on which branch you are on.

Let’s make a change, add a new file – name is “newFile”.

To push this file to GitHub, you have to go through add, commit and push phases. First one simply adds the new file to the local repository, commit makes the commit locally and push will push it to your branch on GitHub.

git add newFile
git commit -s
git push origin newBranch

Remember: When working locally, git log and git status are your friends – you check what is going on with your repository, what changes have been applied and similar.

Now you go to GitHub and create a pull request for your branch. You now either wait for the merge (in cases where you need to work on related code) or simply create a new branch and work on another part of code.

Usually, you simply switch to the master branch, fetch new stuff and merge it to your local master. After that, you can make a new branch.

git checkout master
git fetch origin master
git merge origin/master

git checkout -b newNewBranch

In some cases, your pull request will require some changes in the code in your newBranch (the previous branch). In that case, you switch to the newBranch, do the changes and then go for the amend and forced push (see below).

git commit –amend

In some other cases, before merge happens, they will ask you to rebase your branch to the new master. This simply means that they want to see all your code changes to be checked against the most recent version of the master and to resolve any issues yourself. First, get the master.

git checkout master
git fetch origin master
git merge origin/master

You switch to the newBranch, issue rebase command, check if everything is OK and then force the push – remember, pull request is already open, this forced push simply updates it.

git checkout newBranch
git rebase master
git push –force origin newBranch

And that’s it. There is a number of tutorials out there to get you through the basics, but this one is simple and fast – under supervision of @gberginc (thanks!).

One good tutorial: http://learngitbranching.js.org/

Yesterday I watched Mel Robins (see below). Besides the usual mantras (move yourself, act, etc.), the thing that caught my ear was her “I’m fine” bit.

Today, I got to test it and directly said what I’ve felt (instead of the “imfine”). The reaction was a mixture of shock and surprise – I’d say, that’s a good start.

We all just need to cut the proverbial crap and call it as we see it. Life will be much fuller then -> Isn’t that what we all want?

You’re working with someone that responds rigorously to your emails, but the content (and the pattern) is always the same – you ask for A and the response is that A is being worked on and it will be available tomorrow, due to X, Y, Z.

Then tomorrow never comes.

What do you do?

My technique has been to log these promises and bump on the promised dates. After a while, person in question gets it.

Do you have any better solutions?

Read a good article on the upcoming data paralysis on Datanami.

It is useful to see people understanding their problems (we cannot decide, as we have too much and too little data), but it seems we’re still not very much aware of the problem we’re creating with the Big Data hype.

Quite simply – there has always been the need to:

• have data,
• have people with domain knowledge and experience in the domain data comes from,
• to learn from data and
• to interpret the data, using the said domain knowledge AND knowledge about the algorithms used for predictions or modelling.

Currently, we usually have data. Domain knowledge expertise is hard to get by (and no, no newfangled job descriptions will change that :)). We also have very good machine learning people. But, the intersection of all the requirements from above is usually quite lonely place.

So, you see, the big data paralysis is not coming. It’s always been here, but now, it’s uber-hyped, so we acknowledge it :).

I need to say this: when your team fucks up (and they surely will)

• Please accept that as a fact, learn from it, make everyone understand that it is safe to make mistakes, as long as we care and learn about them. In short: mistakes make us grow, develop business instincts – in short – every fuck-up, if dealt with properly, will multiply in good and sound decisions, better work, better processes.
• You DO NOT FLAME on the public email list!
• You don’t go and indiscriminately flame everyone (=multiple teams) on the public list (not even saying which team borked up) !
• Please act, but act responsibly – it’s your team, you depend on them.

NEVER FORGET: If your team fails, you fail. If your team learns, succeeds, you learn, succeed. 

There. I feel better now.