GitHub profile cleanup

A few weeks ago, my friend sent me a few screenshots showing quite funny descriptions of my public GitHub repositories. Those descriptions were generated by https://github-roast.pages.dev. I had 19 public repos at that time. Those screenshots and descriptions reminded me how much out of date and untouched for a long time my GitHub profile was. So I decided to fix that.

After a cleanup, I have only 2 public repos now:

  1. https://github.com/DamianMarkowski/ios-security,
  2. https://github.com/DamianMarkowski/BuckSample.

I believe both of them may be useful for at least some people. Moving forward, I will be adding and hopefully maintaining more public repos with the code focused on algorithms and data structures.

Code reviews – how to approach them

We do it (almost) every day, we review someone else’s code and our code is being reviewed by our colleagues. It might be a bit tricky for junior developers to get used to it at the beginning though. Let’s write down some useful tips about code reviews.

  1. We do it to improve a codebase.

    A main purpose of a code review is to get a feedback on your code from a colleague from the team. The is no developer who writes perfect code, we all sometimes miss something, forget to test some edge case or commit some unneeded code. This is why code review is helpful – you get someone else looking at the same code, someone who approaches code in a bit different way, who tests different cases, someone who didn’t spend on your branch 4 last days and looks at it with a fresh mind.

  2. Try to teach, not blame.

    Blaming someone because of not perfect (in your opinion) code doesn’t help anyone. It destroys that code author’s day, it destroys your day too. Try to phrase your comments in a way you would like to get feedback too, the way it can be useful, full of knowledge. I think it often sounds nicer when you use plural form rather than a singular one while requesting some changes: for example “Can we move it to a class level?” rather than “Can you move it to a class level?”. It shows that the author of the code is not left alone, that you are trying to improve this code with them.

  3. Link documentation pages, blog posts.

    Different developers have different opinions how particular code could be improved, changed. There are many cases when it’s just subjective, there are a few different opinions and none of them is the only “right” one. On the other hand, there are certain well known patterns, that experienced developers just use automatically. Less experienced developers might not know about them. While trying to suggest such options try to give a link to documentation page, blog post or similar. It may have one nice side effect – author of the code may save this link in their notes, keep it for the future and learn quicker.

I think I will conclude the post at this point. Feel free to add your own tips in comments. Happy code-reviewing ๐Ÿ™‚

3….2….1…. Advent of Code 2018!

This year I’m taking part in Advent of Code online challenge for the first time. The rules are really simple – there are 2 coding puzzles every day starting on the 1st of December till the 25th of December. I will be pushing my solutions to the following repositoryย https://github.com/DamianMarkowski/Advent-of-Code-2018-puzzle-solutions.