Photo by NESA by Makers on Unsplash

I started to work as a contractor one year ago. Since then, I have worked for 4 different companies on-site and learned from many people. That helped me to understand how similar and different modern organizations are at the same time. I want to share with you some unsorted thoughts I have had since last year.

Agile development

Finally, stop telling everyone in the morning that you had a meeting with someone yesterday or, even better — that you had a retro where all attendees were present. Stop making notes on a post-it before a meeting, not to mention that you were doing Task X yesterday. Stop waiting until all have finished with their reports to plan your day. Start making your Dailies useful — introduce a meeting Moderator.

The moderator should guide you through the wall (or Jira board) and synchronize all with the current status. The wall must show progress and the plan for a day. Every work-related effort should be transparent and visualized on the wall. Moderators shouldn’t be the same person all the time.

That was my eye-opener last year, and I recommend you put some effort into it.

I’ve heard a lot of mystery about whether a team follows a true Scrum, what is a part of the framework and what isn’t. Someone is proud to implement a Scrum-by-the-book; someone says that it’s not meter. That motivated me to read the source of Truth — Scrum Guide. It’s just 20 pages and is easy to read. Highly recommended. Some inspirational quote:

Scrum is: Lightweight, Simple to understand, Difficult to master

I’ve observed opposite opinions to Pair Programming in different organizations. Some see it as a waste of time (speak money); others think it’s a valuable investment in Product quality and Knowledge sharing. I know the truth somewhere in the middle. More on Pair programming here.

What was unusual for me — to rotate pairs working on the same story frequently (every day or two). It was strange in the beginning because of wasting “a lot of” time for a switch, but that paid off. The team benefited from knowledge sharing and was safe in case someone goes on vacation or got sick.
The team was probably a bit slower but more confident in what we’re doing.

Want to ask a business-related question to someone but don’t want to bother the whole slack channel? “I’ll clarify it in a private channel and then share the result.” Oops, forgot to share? You’d love to ask him/her on a channel, but she/he isn’t there? Welcome to the club. The good news — you can always (i mean always) use an open public team channel and invite anyone to it. It works.


Gitflow is not Githubflow. They’re different. More likely, you use Githubflow, but that’s just a guess ;)

Trunk-based development, where developers collaborate on code in a single branch, doesn’t forbid you to have a feature branch(es) (with additional rules and discipline). More info about claims and caveats could be found here.

I started to learn about Cloud service from AWS a couple of years ago. I got some experience with it and always heard AWS around me. It was like a synonym of Cloud to me. I thought all people know about those SQS/EC2/SNS/ECS/…

In 2019 I first heard: ”We use GCP, and it feels better than AWS.” Whaaat?. Why? “It has some nice APIs for image recognition, and we need that”. Ok, sounds reasonable.

Later, I’ve heard about Azure, and I could not believe that it’ll become my Cloud provider of choice to develop a new Application. Worth checking.

I’ve worked in an organization that heavily uses Kotlin for building its Microservices. It’s such a great feeling when you see that Java code could be shortened 3–4 times with Kotlin without losing readability.

Historically, Kotlin became very popular among Android developers, but nowadays, I don’t see many reasons you would take Java instead of Kotlin for a new project.

For those of you who still read this, I’ve prepared a new Glossary:

  • Don’t say “I copy/paste it from that Class X”, because it sounds unprofessional. You just made it redundant, say it with honor;
  • Before a review or during a production accident, you don’t do a cheap workaround, but you take a pragmatic approach;
  • Never say that you don’t care (even if you do) because that sounds negative. But when you’re flexible on that, you’ll look more negotiable;
  • You know, that self-organizing team means nothing else, but that you’re not going to do it.

Ok, some were inspired mainly by the internet ;)

Thank you very much for reading this, and I’d be glad to read about your learning in the past year.

Software engineer from Hamburg (Germany)