bookmark_borderAnonymous code reviews

In the dynamic world of software development, code reviews are a staple practice aimed at improving code quality, sharing knowledge, and ensuring consistency across the codebase. However, while the intentions behind code reviews are positive, the process can sometimes lead to unintended negative consequences.

Receiving critical feedback on one’s work can be tough. Even when feedback is constructive, it can sometimes be perceived as a personal attack, leading to hurt feelings and reduced morale among developers.

Code reviews can be used as a tool to leverage power over colleagues. Meticulous reviews with excessive back-and-forth comments can significantly slow down a developer’s productivity. This not only impacts individual performance but can also affect team dynamics and project timelines.

Biases, whether conscious or unconscious, can influence code reviews. Some reviewers might be harsher on certain individuals or more lenient on others, leading to discriminatory practices disguised as professional feedback. Conversely, pull requests from favored individuals might be accepted with minimal scrutiny, compromising code quality. All in all it can be discrimination under the cloak of professionalism.

Given these potential pitfalls, it’s clear that the traditional code review process has its flaws. To mitigate these issues, we should consider anonymizing code reviews.

Why We Should Consider Anonymizing Code Reviews

  1. Protecting Feelings and Morale: By anonymizing the process, feedback is perceived as purely objective, focusing solely on the code rather than the individual. This helps in reducing personal biases and ensures that criticism is seen as constructive, not personal.
  2. Preventing Discriminatory Practices: Anonymity removes personal identifiers, thereby minimizing biases based on race, gender, seniority, or any other personal attribute. This promotes a fairer and more inclusive review process.
  3. Ensuring Objectivity and Fairness: When reviewers and authors remain anonymous, the emphasis is on the quality of the code. This fosters a more objective and balanced assessment, leading to better code quality and a healthier team environment.
  4. Mitigating Productivity Hits: An anonymous system discourages the misuse of code reviews to deliberately slow down a colleague’s progress. The focus remains on providing genuine, constructive feedback, thereby maintaining productivity and ensuring timely project completions.
  5. Leveraging LLMs for Neutral Language: Utilizing Language Models (LLMs) to standardize the language in comments can further ensure anonymity. This prevents reviewers from guessing identities based on writing style, fostering an environment where feedback is purely based on the code.
  6. Equality in Approval: Anonymity ensures that code is approved based on merit, not personal relationships. This builds a culture of fairness and meritocracy, where every developer has an equal opportunity to contribute and grow.

Adopting anonymous code reviews can transform our workflows, making them more equitable and focused purely on improving code quality. It’s time to embrace this change for a healthier, more productive development environment.

bookmark_borderWorking code isn’t enough

In a great book “A philosophy of software design” John Ousterhout points out that software engineering is not only about quick delivery of digital products. He stresses the importance of long-term perspective – strategic programming. This idea is well known at least since Clean Code, but still somehow ignored. For some reason, many view refactoring or improving code structure as merely a fanciful dream of coders chasing perfection.

It’s the opposite. It’s a necessity if we don’t want the project to collapse.

“The most important thing is the long-term structure of the system. (…) Your primary goal must be to produce a great design, which also happens to work” – says Ousterhout.

It doesn’t mean we should chase beauty and not deliver. It means we must remember that delivering poorly structured code will soon – much sooner than most of us think – cause issues.

POCs become MVPs, MVPs become products, products start earning money, they need scaling, and new features… and boom – suddenly company needs 5 developers to slowly implement new functionalities and perform basic maintenance of an application which was written by one intern in two months.

The inception of a project should always be the most appreciated and well-planned stage. Like pregnancy. We don’t drink, smoke and party in the 1st trimester just to eat whole foods in 8th month – but it’s exactly what we do with code of our IT projects often. We do whatever in the first stage, and then when it’s too late we bring the best engineers to save it.

Remember, engineers: strive to create the best designs possible. Our lives depend on it!

bookmark_borderHow to delete unused local branches in Git?

To remove unused local Git branches we can utilize git-removed-branches npm package.

First install it:

npm install -g git-removed-branches

Then if you want to detect stale branches run:

git removed-branches

To remove them run:

git removed-branches –prune

The command will remove local branches which have been deleted on remote repository.

bookmark_borderEnglish names of programming special characters

Many developers are not native English speakers. Some special characters used in programming may be difficult to remember. Here is a list of special characters used in programming with their names in English:

{, }Braces, curly brackets
{Left brace
}Right brace
(, )Parentheses, round brackets
(Open / left bracket / parenthesis
)Close / right bracket / parenthesis
[, ]Square brackets, brackets
[Open / left bracket
]Close /right bracket
!Exclamation mark
@ampersand
*asterisk
Hyphen, dash
_underscore
=Equal sign
:colon
;semicolon
,comma
.Period, dot
Less than, angle brackets
Greater than, angle brackets
/Forward slash
\Backslash
~Tilde
`Grave accent, backtick, back quote

bookmark_borderThe most useful docker commands

List of containers: docker ps

List of images: docker image ls

Build container from dockerfile in current directory: docker build -t [container name] .

Run container in the background: docker run -d -p [container port] : [host port] [container name]

Get logs from container: docker logs [container hash]

Login to container: docker exec -it [container hash] bash

bookmark_borderHow to reject all changes in Git?

If you want to reject all changes in your local git repository you must:

  1. Discard local changes
  2. Remove untracked files

To discard all local changes run:

git reset --hard

To remove untracked files run:

git clean -df

After executing these two commands you will have no changes whatsoever. If you run git status you should receive:

“nothing to commit, working tree clean”

bookmark_borderWhat is technical debt?

A picture is worth a thousand words. Technical debt is what you see above. A temporary solution that over a period became a problem. Sometimes smaller, sometimes bigger. But the longer we wait the bigger is the risk it will explode and cover our business with odorous excrement. Moreover, like any debt, the longer we keep the liability, the bigger our payback will be.

You could say – who would be so careless to keep such a temporary solution for a long time! You are right. But as they say, temporary workarounds are the most persistent ones. Sometimes there is no time. Sometimes there are no resources. Later there is no time or resources to transform a temporary solution into something proper. Therefore, it stays with us. Until it becomes dangerous.

Technical debt exists in every IT project. In other forms, this phenomenon exists everywhere. In our home, at some messy place which starts to grow until suddenly we realize our whole apartment is a mess. In our body, where few cells grow out of control, and after many years we are diagnosed with cancer. In any business, where crucial operations are done by some single old person who suddenly dies or uses some ancient hardware that breaks and destroys the whole company.

Technical debt is a seed of chaos. The responsibility of software developers and IT managers is to keep it under control. Otherwise, we will be consumed by it one day. No matter the cost – let’s do not let it grow!

bookmark_borderHow to get div height to auto-adjust to background size?

Problem: when we set a background image on div the div size doesn’t adjust to background image size.

Solution:

height: calc(imageRatio * 100vw);

Explanation:

First, we need to get the ratio from the background image. We simply divide one dimension by another. Then we get something like for example 66.4%

When we have image ratio we can simply calculate the height of the div by multiplying the ratio by viewport width: calc(0.664 * 100vw)

A height of a div is automatically updated when the window is resized.

See also: my answer on StackOverflow – https://stackoverflow.com/a/61990449/3775079

bookmark_borderHey Google, could you please add a .gitignore-like option to Google Drive?

Google products are awesome. Gmail, Android, and Google search engine itself. Whoever used Duckduckgo or Baidu knows how awesome Google search engine is… There’s however one thing which drives me crazy: it’s Google Drive.

In particular, the sync engine of Google Drive app. It’s far from perfect, but the worst thing is when you, as a developer, accidentally leave some node_modules inside the synced directory. Then the whole thing literally explodes. As all of the devs know node_modules directory is the heaviest object in the universe…

When Google Drive tries to sync it we can go and grab a coffee. We can grab it from the plant in South America by swimming in a canoe through the ocean, wait until it grows, pick it, bring it to the USA or Europe or wherever we live, wash the beans, burn them, design our custom coffee machine, make a coffee, and then if we’re lucky we can go back to our computer and see the sync finished.

I tried to find a solution. I found this crazy discussion for example https://superuser.com/questions/820145/google-drive-with-a-gitignore-like-option. Poor admins build some custom scripts to make symlinks to the directories which they want to exclude from syncing. Or they remove the directories before running the syncing engine.

Therefore I’d like to pray to Google itself. Please, I beg you, oh mighty – add the exclusion mechanism to the Google Drive sync app so we can exclude the directories, files, anything, just like we can simply do it with .gitignore file. I know you’re busy, I know it might take a long time, but please. It will make the world a bit better place to live. Thanks in advance, Google 🙂

bookmark_borderDevelopers, developers, developers, developers!

You are a dev. You find a job. You get a PC. It’s slow. It lacks the software which allows you to be productive. Half of the internet is blocked. You can’t choose your favorite keyboard or mouse or chair. Sounds familiar?

5S

Japan has a fascinating culture. Esthetics, order, industriousness are its strengths. One of the biggest achievements of modern Japan is its automotive industry. American car manufacturing companies, with the great Detroit and Ford’s assembly line, have been one of the landmarks of USA industrial power. These enterprises had decades of experience, America won the war but despite this in the 80s Japanese took over the automotive industry. Toyota production system became famous and the whole world looked at Japanese organizational techniques to find inspiration.

One of the elements of Japanese culture in this field is 5S. Long story short, it’s the organization of a workplace where:

  • useless tools and items are removed
  • unnecessary move and effort of workers is minimized
  • workplaces are kept tidy and organized

Implementing these principles helps to create a safe and effective workplace. It improves the efficiency of a whole company without putting a strain on workers.

Alcoa

Alcoa is one of the biggest aluminum producers in the world. Charles Duhigg in his famous book, the Power of Habit, described an interesting story about the company. Once upon a time, the new CEO has been nominated. His name was Paul O’Neill. He shocked stakeholders on his inauguration speech because instead of describing his plan to increase effectiveness, profit, and reduce cost, he gave a talk about increasing workplace safety.

 O’Neill managed Alcoa from 1987 to 1999. During that time period, the market capitalization skyrocketed from 3 to 27 billion USD, while net income went up from 200 million to almost 1.5 billion USD.

Was it money saved on industrial accidents?

Obviously not. The money was wasted because of bad organization. Workplaces have been badly organized, they posed risk for workers, reporting the problems was far from perfect and the whole organization suffered. O’Neill has introduced the pressure for improvement of the production process. Workplace safety was metrics of perfection. As we can see from the results – it was a proper one.

The workplace of software engineer

Software development and IT industries obsessed with optimization. New frameworks which allows us to work faster. New processors, more RAM, more storage. Faster algorithms. CPUs generating more FPS. We continuously believe that we can make anything better, quicker, cheaper and more efficient.

A software engineer, when confronted with the job, tries to optimize it. If the tasks are repeatable, a developer will try to automate it. If something takes too long, the engineer will figure out how to do it quicker, using a different approach.

What then can be more annoying and demotivating for a developer than the situation where something slows him down and he can’t get rid of it!

The amount of these obstacles is surprisingly substantial in most corporate workplaces. Let me give you a few examples:

  • our development workstation has too less memory / too slow processor / too small hard drive
  • the internet connection is slow (for example due to proxy)
  • antivirus software dramatically slows down our computer
  • company policy blocks some pages (for example youtube, where we can find a tutorial to solve the technical issue)
  • granting access rights takes ages (for example, to perform some task we need access to system X, but it must be accepted by three managers, which takes three weeks and blocks our)
  • the company does not buy some tools or does it very slowly (for example we need a new testing tool in a week when we start the project, but we can order only during next fiscal year starting next few months)
  • repairing broken hardware takes very long (personally I waited two weeks until my workstation has been fixed)

I remember one manager in a big company wondering how it’s possible that startups are more efficient while they have smaller budgets so theoretically they should have worse engineers. My experience tells me the reason is the corporate inertia, when all the procedures mentioned above slow down everything sometimes to gargantuan extent.

Flow

Except for technical aspects, we need to remember also about the ergonomics of the developer’s workplace. Many companies buy the same chairs, keyboards, desks, monitors, and other gear for all employees. It’s understandable and usually, these things are of good quality. However, there always be some amount of people – some unusually short, others obese, tall or sensitive – who will suffer from these default solutions. They will have headaches, sore eyes, the pain of their wrists. You can be sure they will have a problem doing the most important thing in the work of the developer – to focus.

The software engineer, who doesn’t focus, burns company money. Getting the flow is not as easy as going to the office every day. Talkative colleagues, lots of meetings interrupting our focus during the day, uncomfortable chair – all of this can ruin our flow.

Developer eXperience

User experience became big thing. Every company knows now how important UX is and almost all enterprises producing software have UX experts in their teams.

Analogically we should adopt the idea of developer experience, DX. The lower developer experience in the company and project, the more money will be burned, the staff turnover will be greater and the team’s output will be minuscule. On the other hand – awesome developer experience will bring us great experts at a lower price, will give us a productivity boost and we will not need to constantly recruit new team members because old ones decided to quit.

Last but not least, let’s remember – Microsoft always cared about developers 🙂