Falcon start with Polish satellite

I’ve just watched SpaceX’s Falcon 9 rocket liftoff. It took 64 small satellites (called cube sats) to Earth’s orbit. Among them was one that I witnessed being born over past few years. My two friends (@maciejt_nowak and @mandrek44) were part of a team that wrote the code for one of the first polish satellites (I think it’s the 4th one?). There was also hardware team from Warsaw University of Technology, overseeing this whole PW-Sat2 project.

Falcon went into space, released second stage with payload and then landed safely on the “Just read the instructions” droneship (nice name, right?). All as expected. What a time to be alive!

See you space cowboy!

Leadership and authority building training – overview

At the beginning of the year I was promoted to architect position. Well, it is more lead developer position, but architect sells better to non-developer clients so that’s what company went with. So no ivory towers, thanks God! With it came package of trainings that I have/should do. There will be some technical ones, but there are also dreaded soft skills trainings.

I say dreaded because I don’t think anyone actually likes participating in them. I mean – day or two out of work are cool and all, but usually somewhere in the middle of the first day I was finding myself thinking – I would rather be coding now. Don’t get me wrong – this is useful knowledge. Knowing how to communicate, how people work, how psychological aspects are affecting us – whether we want it or not (even: whether we are aware of it or not!) is a must. I also do part time recruiting at the company, so meeting other people, external to our organisation, is normal and I better communicate appropriately. But those trainings are usually boring, assignments done in groups are too long, to vague. Seems like all the knowledge could be condensed into 1-2 hour block and we would be done with it.

Last training I was at, touching topics like building authority and leadership skills, working with teams and (to some extent) managing teams – it was completely different. It was so good. Two days packed with knowledge, fun, short exercises, that had direct impact on what we do and discuss later on. Touching real problems that participants brought with them and sharing work-life stories by trainer – everything anchored in the topic and logical rules and groups introduced. Not only was this good from soft skills point of view – it was also good from engineering point of view! Trainer presented concrete knowledge, show us for example how teams are developed, how they change, what changes with them and how to approach teams at different level. And I think everyone participating had those moments where they thought: yea, I know that type of team, I’ve been there. I know I did, more than once.

At first I was afraid it’s going to go into manipulating teams, how to make them do stuff they don’t want to. I was wrong. It was all about communicating with teams and individuals. How to pass our knowledge to them, how to be clear and precise in telling them what we need of them. How to setup clear working framework and manage expectations. Most of all – it was about how help teams and people in those teams grow professionally.

It’s been more than 24 hours since the training ended. I gave myself one day to clear my head and let they hype ventilate. But even after that – I’m still in awe of how good this training was. How it clicked with my engineering brain, showed clear instructions – if you see this kind of person, this is what you need to do. Different type of person – approach them this way. Sure, we’re still talking to humans, so there’s some wiggle space and we need to approach everyone individually. But having a framework that prepares you for the direction things can go to and how to steer it for mutual benefit – that’s perfect.

I wish all future soft skills trainings will be done like that. Concrete. Precise. Based on experiences. And giving straightforward advices and rules to follow.

[Book] 4-hour workweek, Tim Ferriss

Recently I’ve read a book by Tim Ferriss “4-hour workweek”. Title is click-baity (and Tim kind-of admits it). But it is pretty honest, says what the book is about. And if it sells – I will not hold it against it.

In general – the book is nicely written, it reads fast, chapters are not too long and the content is of very good quality. Good job there! And I definitely agree with many points presented in the book. Automate stuff – no brainer. If something can be automated (or, even better, completely avoided) to save time – do it. Outsource stuff – to some extent it clicks. Avoid clutter, junk information diet etc. Hell yeah! I try to do that (to some extent) and fail way to often, but I will keep pushing.

What I have problem with is the general idea Tim is trying to sell. That you can work 4 hours a week and have a good, fulfilling life. While that may be option for some, it definitely does not sound like something everyone can do. Someone has to do the heavy lifting, baking bread, cleaning up, cooking or coding software. Is all the work we do necessary and valuable? Heck no! Buch of stuff is being done just for the sake of doing it. Consumptionism is full-blown disease of our times. Some people like to present themselves as working 60 or even 80 hours a week. Some people really do work that much! Hell, that’s no way to live your life! But if everyone worked 4 hours a week we would be nowhere. We would achieve nothing. It may be the way to get money for some, if you can create something that can sell well to many people and at the same time not require much work to keep it going. But that’s something only few can do.

I liked the book. It is worth reading, I think. But at the same time I feel like I’ve been conned. I payed for the book and helped Tim make his 4-hour workweek work – even when I don’t agree with him completely. Good play, Tim! ;)

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.

Idempotent changes

I finished chasing a bug in code few days ago that took me a while to understand. What happened is – system failed because it expected to have one value matching search criteria, but it found multiple. Two, three, up to four in some cases. That should not be possible, violates business logic. It should violate SQL Server constraints as well, but for one reason or another those were not in place.

The source of a problem was the fact that, when importing data from external source, system tried to add default value to some list. In case of failure, it did retry few times. Each time it added default value. In our case, there were three retries due to system setup, so we ended up with four default values in a list.

Why did that happened? Multiple reasons. Retries called code to setup defaults etc. at every retry. The code that inserted those defaults were not made aware that such thing could happen so it assumed default has to be added.

It is, first of all, lack of communication and clear design from the team as a whole. Should defaults be clearly marked as being called every time – team would have avoided this mistake. But this is hard.

One big thing that everyone on a team could do is – whenever possible, write code to be idempotent. Do not introduce side effects when not necessary. If changing value triggers event in system – check if value was not already what you are trying to change it into. If you are adding something to the list – check if it’s not already there. If you need to make call to external service – check if value is not already downloaded.

Not only it may save operation time in some cases, it may help avoiding bugs if someone unaware tries to use method incorrect way.