On almost every job interview there are questions about frameworks, programming principles, maybe some coding or whiteboard architecting. On the other side, there is the way you work. Tools and skills you use on a daily basis which define how you work. No one really asks about those things but I find them quite important.
At work, we are slowly breaking down the monolithic application into smaller manageable services. Some time ago we had a very interesting issue which proved that microservices are hard to implement. It’s especially true if you are not there yet but somewhere in the middle. When you need to introduce intermediate solutions which will enable you to work further on the migration to service oriented architecture.
I’m learning python for some time now. I’ve made myself familiar with the syntax and then started looking into other ways to increase my knowledge about language and learn its quirks. I’ve found a very nice site that allows me to practice basics and strengthen different kind of muscles that I’m using in my day job - adventofcode.
At work I’m are engaged in the maintenance and development of a pretty big legacy monolithic application. Some time ago team size basically doubled. To keep things simple and activate more people we decided that we need to split the huge team into smaller more focused parties. Here is how we are working on many features of the same code base in single monolith with multiple teams.
Imagine the situation when you’ve just released something on production and deployment went fine. You’ve just sent release notes and went out to grab a coffee. Once you are back you see an email with information that feature team have been working on for past 3 sprints doesn’t work at all. Turns out you forgot to change something in production server configuration. In this post, I’m going to present the simplest idea which will help you to avoid this kind of issues.
Recently while starting work on a project we’ve (team of two ;)) decided to try something new and use Kotlin. The project is far from ready and still under active development, but after writing some code in Kotlin I’ve got few observations I’d like to share.
Code review is a great process which gradually improves code quality. It is a system you can implement in many ways. In this post I’m going to grumble about one particular way of performing code reviews - when there is only one person responsible for doing code reviews and suggesting/accepting/rejecting changes.
We all love to write new stuff and learn about things. But when we’ve got to do something in one of the older applications we’d rather avoid it and lag as long as possible hoping that someone else will handle it. You shouldn’t be afraid of legacy code (as long it is not ball of mud). You should take the opportunity to look into the past, and learn from it as much as possible.
