Blog
Michael Bykovski
I have worked at small and medium sized companies within the 15 years, however I have had customers ranging from small and medium sized companies to corporations. I have developed internal applications, stores, evaluation and automation applications, microservices, services, web applications, sensor and mechanics based software and other applications.
I have productively used the following technologies: REST, SOAP, GraphQL, Vue, React, Angular, jQuery, store systems, web design, data science tools, Ansible, Gitlab (CI), SSH, Kubernetes, Go, Java, PHP, C, Groovy, Python, JavaScript, NodeJS, Firefox, Chrome, Internet Explorer, Symfony, Puppeteer, Selenium, Github, Next. JS, Django, NestJS, numpy, pandas, Python Celery, Clickhouse, Postgres, MariaDB, MongoDB, Kafka, SAFe, Agile, Scrum, Kanban, Tensorflow, Keras and much much more.
I have a Master degree in Computer Science and work part-time at the Rhein-Main University of Applied Sciences as a lecturer, where I offer the subject Webengineering.
During the implementation of these applications I had to deal with more than 100 teams and more than 500 people during the 15 years. Mostly I had positive but also some negative experiences.
After 15 years of software development, there are always new challenges in my job that I am not yet up to. Certainly, there are many things that I can implement in no time, for which many other developers would need weeks. But, the more I see and the more experience I gain, the more I understand that there are different angles, levels, and degrees of difficulty that you just haven’t explored yet.
The fact is that as an experienced developer or developer, you should keep respect for the cause and your colleagues. Professionalism is characterized by the fact that even trivial problems should not be underestimated and room must be given for other developers to enjoy the same experience.
This is a nagging issue, where I have to be fair and say that in the past I wasn’t that consistent either.
In the meantime I always write tests, at least in the backend. Unit tests are a must and for every endpoint there is at least one integration test that tests at least the „happy path“.
The excuse: „We don’t have time for that“ doesn’t apply here. Rather, you have to ask yourself, „If we don’t do this now, will we have time for it in the future, and most importantly, will we have time for all the bugs it will create?“
The answer is quite clearly, no. Therefore, invest the time to implement a good test setup, it’s much easier and more common these days than it was 10 years ago. Do it!
In the world of software development, software development teams occur very frequently. It is quite rare for one software developer to run the whole show.
Over the last 15 years, I’ve learned that distributing responsibility within a team leads to the team trying to pull together. This creates a three musketeers attitude: „One for all, all for one“.
It is fatal if there is one person in the team who is responsible for 90% of the code and the rest always depend on it. From an economic point of view alone, this is too risky and you should make sure that the responsibility is distributed among all members.
From my point of view, I can only say that it is much more pleasant for a software developer to work in a team where everyone can rely on each other. Where even in case of fluctuation there is no fear that nothing will work anymore, but the responsibility simply has to be redistributed.
This was once in an e-mail signature of one of my highly esteemed professors – and how right he was.
During my student days there were a lot of buzzwords and a lot of software developers, including me, fell for them. React, Vue, Angular was big at the time (2013-2018) and many dabbled in it. However, at that time it would have been much smarter to learn JavaScript itself, understand the issues and benefits, and then go to libraries and frameworks.
Likewise, phenomena like „blockchains“ are nothing more than chained lists, which are a hard-to-change chained list due to hashing. Kafka can do that too, even almost better and more efficiently.
So don’t try to think in terms of frameworks, libraries and applications, think in terms of concepts, problems and formal solutions. Then you will be able to recognize the facets of bloated systems and eventually replace them with lean and smart systems.
Dependency Injection is my friend. For a long time I knew DI (Dependency Injection) and dismissed it as an annoying add-on in various frameworks. Meanwhile I don’t build any backend application without DI anymore.
The possibility to loosely couple the code by DI, to expect an interface as dependency in a class, but to put any implementation of this interface into it, makes the software a „soft „ware: Easily changeable.
In the meantime I develop a concrete implementation and a fake implementation for every interface I put in as a dependency somewhere, simply to be able to fake every single module in my application and thus test it easier – manually or automated.
A wristwatch is complicated. You can plan it, draw it, measure it, feel it and imagine it concretely. If I have planned a watch, I can build it again and again and each subsequent watch will be the same.
Complexity is unplannable, difficult to explain, difficult to imagine, and varies from case to case. Complexity is what happens when people come into play.
As soon as I work with people and plan something, we are in a complex world, with feelings, hierarchies, cultures and more.
As soon as I work with software, we are in the complicated world. Software is clearly defined, there is code and the software does exactly what the code says and nothing else. There may be unexpected effects that act on the outside of the software, but the software itself is complicated.
Now we are not building software for software, but software for people. So we have to juggle the transition from the complex world to the complicated one, as well as back. And that is the art of a software developer to get it right.
The question of how to get it right is difficult for me to answer. I would say it’s a mixture of experience, openness, honesty, patience, discipline and the pursuit of good.
In fact, a good friend caught me doing this just the other day. Sometimes you avoid a complicated to complex problem by researching and seeing if the problem has already been solved before you.
Nevertheless, we must remember that there is very rarely one solution to a problem. Sometimes research makes sense, especially to see if there is already a best practice solution to a problem, but the best way to deal with it is an actual hands-on, because in the end it’s all about having code in a file.
Within a project there are many meetings, discussions, ideas and decisions. Make your project members and stakeholders aware that every decision and idea is weighed in the balance and taken seriously. If the stakeholder says: „Feature XY should be improved“, then create a ticket in the ticket system directly with him or her, estimate it and try to schedule it into the next sprint.
This way the added value of your work becomes clear, because now for every change the visibility and traceability of your work is seen. Do not at all make any ad-hoc changes without making that visible in some way.
This follows on somewhat from point 8. Discipline is the name of the game in software development. Whether you are disciplined and write tests steadily, or create a ticket for every idea/decision, or always leave the code better than you found it, discipline keeps you on the ball.
The benefit of discipline is to become more predictable in the software team. When each team member follows their own discipline (assuming positive discipline) it makes it easier to deal with each other because now communication and behavior become more predictable (keyword complexity).
At the beginning of my career as a youngster, I thought that my code was nobody’s business. What a mistake that must have been…
How are you supposed to get better as a software developer if your code isn’t shared, discussed, and improved? That is ultimately what open source software is all about. Almost all systems today (Linux, Nginx etc.) are based on this, namely that code does not belong to anyone and everyone is allowed to screw around in it until the best result comes out.
At the end of the day it’s about offering a product to the customer. And when you get into a car, you also want everything to be tested and the steering wheel not to fall off. We should look at software in the same way.
Discipline is good, it brings a certain predictability to behavior and communication. Nevertheless, I believe that without courage and risk there is no driver for innovation. Sometimes it is also important to dare new ideas and take risks.
In the stock market they say: „The higher the risk, the higher the profit“ and so it is in the real world. Of course, it’s also a matter of experience which risks you should take and which you shouldn’t, but if you want to get ahead, you have to take some – that’s for sure.
There are many things in life that bother you or that you hate. In order for this negative emotion not to affect your mind, you have three options.
Start loving the thing, find something you like about it.
Start avoiding the thing, do something else instead.
Start changing the thing so that you can love it or leave it.
The good old scouting rule applies not only to your environment, but also to your code. Try to leave the code cleaner than you found it. Again, approach this with some discipline.
This is good for you because you will keep improving and for your team because you will improve and the code will become easier to read.
Back when I was discovering more and more software development, I thought I would always sit in a quiet cubbyhole and tinker with code. But software development is much more than that, it is: designing, thinking, taking responsibility, maintaining discipline, dealing with people, processing emotions, understanding complicated problems, keeping up with the latest technology, discussing and arguing, explaining and presenting your problems in an understandable way, telling the truth and much much more.
This is something I tell my students and anyone else who ventures into software development. Complexity or not, at the end of the day it’s about saving code in a file and executing it. And if that doesn’t sit, how are you supposed to handle all the other problems in the complex world?
In my career, I sat at the computer and programmed almost every day. Of course, I read various books and blog posts, attended conferences, watched Youtube videos, but none of that got me anywhere near as far as actually programming software.
If you’ve made it this far, I’d like to start by thanking everyone who has stood by my side along the way and worked with me on great projects.
