For over a decade I have worked for one of the world's largest software development companies. While doing a lot of tasks, I've seen many aspects of the business, from fast cowboy coding to serious purchases of competitors and startups.
Planning meetings
Most of the developers I know love their job. They really love developing, writing code, building programs, and maintaining the infrastructure necessary for their code to see the world.
To do this, they often need to focus on what they are doing. Perhaps this is the reason for the popularity of noise canceling headphones and AirPods that surround us in everyday life.
However, rallies and focus are real enemies. I’ve already lost track of how many times my planner distracted me by telling me that in 15 minutes I had to show up for a planning meeting while I was trying to figure out a complex concept I recently came up with. Of course, I knew in advance that there would be a planning meeting. When I looked at my schedule on Monday to estimate the time I would have to write code this week, I had no doubts: my workdays are filled with meetings.
The longer you work and the better you cope with colleagues, the more knowledge you gain. Valuable knowledge. Or experience, as some call them.
And you know what? This knowledge is mainly transferred through meetings. Don't get me wrong, this is good in itself.
But when I'm in a stream and in the process of writing the best code of my life (at least that thought helps me fall asleep at night), then the last thing I need is a tiny reminder in the corner of the screen that says "It's time."
It's time for another meeting.
Huge car
I am very fortunate to work for an extremely large company. And every day I thank fate for this.
This is probably why the topic of this section will be especially relevant to me. But each of us, in one sense or another, is part of something larger in our professional life. The main goal of our companies is to write great code.
“But don’t we all need to be able to sleep peacefully at night?” - I whisper sometimes at our cozy planning meetings.
However, the tasks are not limited to this, they are larger. We have to deliver products and services. Satisfy the needs of our end users and customers. In the end, make a couple of cents.
And this again conflicts with the concept of the Developer. I've had countless situations where I knew (or at least thought I knew) that Solution B would be better than A in terms of performance, user friendliness, or code quality. But a person higher in the hierarchy or an important client had a different opinion. And this is what prevents me from falling asleep at night.
But we have to put up with it. In addition, to challenge the wrong decisions (you guessed it, this happens in endless meetings), you have no way to influence the outcome. You will simply be informed of the decision. Intercom or short conference call. To give it credit, sometimes people listen to your arguments. This is great because it not only raises self-esteem, but also makes you feel like a part of a Huge Machine.
There is a strange duality - on the one hand, you want to be part of the mechanism, on the other hand, some bitterness remains.
A huge car is a rather strange thing.
Code quality and delivery time
If you got to this part of the article, you may already have noticed how much I love the quality of the code. Good code is my bread, almost literally. We can speculate at length about writing perfect code (which doesn't exist, I must admit), but I think most of us would agree that this is at least what we're aiming for.
But guess who will knock on your door more inevitably than on-screen scheduler notifications while you squeeze the most out of the IDE?
Project deadline. Deadlines.
It's not hard to see that code quality and deadlines don't go well together.
I must say that deadlines, of course, can be pushed back if the quality of the code is not yet satisfactory to us. Yes, it happens. But the same is true in the opposite direction. The code is delivered despite not having the quality your team strives for in their day-to-day work.
Because a big hand hangs over all of us.
Code check
I'll admit right away that code review is a critical part of every development department. I know this and agree with it.
But, to be honest, learning code and solutions that are conceptually very different from the utopian constructions in my head is not my favorite thing. Yes, you learn a lot. Others, I hope, are also learning from my digital writing.
If you work as a senior developer, you are constantly asked for your feedback. Of course, during the code check itself, but at other times too. At the coffee machine, during meetings, even when you scratch your back.
In many ways, it is an honor for you because it means that your thoughts and feedback are appreciated and respected. And I give it its due, without any sarcasm.
But when it comes to my daily professional life and personal level, I prefer to look at other people's work infrequently. I study other people's code only if I want to learn something, or out of curiosity.
But I have to, I have no choice. The more experienced you become, the more you study other people's work and the more you are connected to it. Whether you like it or not.
Colleagues
This point applies to all of us, regardless of position. Unless you've built an ingenious app in the garage alone, you have to deal with colleagues.
Some of them are great and may even become your friends. But we must admit: there are others. This is human nature: we like some, we don't.
Those who we don't like, or those "with whom we don't have a very good understanding", can write beautiful and high-quality code. And some of my friends are not the best developers.
But such is the inevitability when communicating with people, with colleagues.
I repeat: as we already understood from the example of code review, the more experience you have, the more you have to communicate with people at work.
Extroverts may be happy about that, but I'm not an extrovert.
Conclusion
I have one colleague, let's call him Larry.
He sits alone in the corner all day. He's much smarter than me. It does not seem that people decided to stay away from him: he is just that who decided to stay away from people.
The point is the confrontation between him and the world. Larry against the Huge Machine.
He always attends meetings (without uttering a word all the time), but most of the time he looks at the screen or presses on the keyboard with a force that its manufacturers did not expect. When his management asks what he is working on, he replies in a quiet and serene voice: "You know what." And does not take his eyes off the monitor.
Management doesn't often ask what he is doing.
He creates the most incredible solutions and algorithms. One perfect solution after another.
Sometimes I want to be like Larry. Be on a deserted island in the middle of the ocean. Just me and my laptop.
