What is origin/master, or how to update to latest changes in git

When using git, there are few concepts that are hard to grasp at first, but are (in my opinion) required to get fluent with it. It does not matter if you are using GitHub, BitBucket, Gitlab – figuring out how it works (at more than basic commit/push/pull level) will be very useful when you will try to set up your workflow or when you find yourself in a corner.

One of those concepts I think is – what is origin/master? How does it differ from master?

Collegue of mine had a problem where he could not reproduce issue with code. We thought it may have been related to latest changes on master branch, that were not included into his branch. But he insisted that he in fact did merged master branch changes. Spoiler: he did not.

What my collegue was doing was: git merge origin/master. Now that’s perfectly fine, I said, but you are not getting latest changes that were made by others in our team. “But I am calling origin/master, so I am getting latest, freshest code, right?”. Nope, you are not. origin/master is not latest code. It is latest code since the last time you contacted origin server.

Here’s how it goes. You contact server sometime, usually when you are doing operations like pull, push, fetch. Then your local copy of repository gets latest code changes, updates your branch pointers etc. But – not all pointers. Just those that are reflection of server state, like origin/master, origin/nasty_bug_solution, origin/new_fancy_feature etc. But your nasty_bug_solution branch will stay unchanged – unless you will merge changes (or you are doing pull which merges changes automatically).

So now you have your latest version of code, you are at the same place where origin server is. But that’s not forever. In a few minutes your collegue may add something to master branch and whoops! you’re out of date. But that’s OK, that’s cool. That’s what makes git – git. You can work offline with your branches, not requiring asking server over and over again what’s going on there. Just keep in mind that when you are doing git merge origin/master – you are checking and merging your local version of branch, last state you have seen on server, not what is there now.

In graphics above you can see how it flows – unless you do git fetch (or git pull which fetches underneath) – you won’t get server status update. You can merge all you want – code will still be in the state it was.

So if you want to update your branch with latest-freshest master copy – do git pull and git merge origin/master afterward. That’s the way to success!

Or, if you are feeling frisky, you can try git pull origin matser – pull changes from server origin, branch master on that server, and then merge those changes into my current branch. But that’s only for the bravest! Will you dare?


Custom TypeScript typings not recognized

For a while we got problem in our project where TypeScript typings (*.d.ts files) were not recognized. This resulted in many failed builds. Solution was rather straightforward – reference those files directly, for example by code like this:

/// <reference path="shared/my_custom_typings.d.ts" />

While this works – it is far from perfect – those typings should be automatically recognized.

Turns out when bumping typescript version at some stage they did introduce a change. While in older version directory structure like this was OK, in newer requirements changed – and so our directory structure had to follow.

We had to move our d.ts files into dedicated directories, one for each typing, following structure something like:

+ shared
    + my_custom_typings
        - index.d.ts
    + my_other_library_typings
        - index.d.ts

And with that we could get rid of all reference directives as they got loaded automatically (of course there still has to be some kind of indication where to look for those common, shared typings – set it up in tsconfig.json!)

Inclusive job interview or fighting for your job

For past year I have been working (partially) as technical recruiter. This lead to some nice and some weird experiences, but mostly has been very interesting – sitting on the other side of the table. While the process of recruitment is not perfect, we are trying to make it more open, inclusive and make sure people are going out with something: either an offer, or at least info about what was missing in them, where they are not lacking – but have some holes in skillset that is required for the position. Some skills, that people do not have at the moment, can be quickly learned. Others are more complex and people just didn’t make it – that’s how life goes sometimes.

Recently we’ve had discussion with fellow technical recruiters. We’ve touched few topics, all opinions were very interesting (mostly because quite different from mine). But one opinion struck me. Colleague said that he is very dissatisfied with job interviews that are nice and easy. What he said is that getting offer after nice interview, where everyone was not only respective but simply goes out of the way to make you feel included, and where there are no trick questions – just does not feel satisfying. That this is too easy. He expects that job has to be obtained through hard talk, complex questions, maybe trap question here and there. He has to sweat to get through it.

This feels totally weird to me. I understand feeling stressed out on job interview, it is hard to avoid. Someone is judging you, your skills, you are sitting in foreign space, unknown people. Hard to not sweat a little bit (use antiperspirant!). I however love it when people are open, happy to talk to me, are going out of their way to make questions clear and well defined. Do not try to trick me and prove me how unworthy I am of taking software engineering position at the company they are recruiting me to. Bleeding through interview is simply wrong to me. Why would I want to work with people that are trying to squeeze me out of my bucks (that’s the whole point of job interviews with tricks etc. – they still want you if you fail to answer some of those, but this will go against you when going to money part of interview).

If you are interviewer – I urge you to be nicer, more inclusive of people. Lack of skills, holes in knowledge – we’ve all been there, none of us have been born with our current skill set. It is OK not to hire someone, but it is not OK to make them feel wrong about it.

We are not hiring coding monkeys. We are not hiring spec-ops soldiers that have to work under top stress conditions. We are not hiring robots.

We are hiring humans.