Daily challenges for a senior developer – InformTFB

Daily challenges for a senior developer

Daily challenges for a senior developer

For more than a decade, I worked for one of the world’s largest SOFTWARE development companies. While performing many tasks, I saw many aspects of the business: from fast “cowboy” coding to serious purchases of competitors and startups.

1. Meetings

Most of the developers I know love their work. They really love developing, writing code, creating programs, and maintaining the infrastructure needed to make their code visible to 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.

But rallies and concentration are the real enemies. I’ve already lost count of how many times my planner has distracted me by telling me I have to show up for a meeting in 15 minutes 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 working days are filled with meetings.

The longer you work and the better you do with your colleagues, the more knowledge you gain. Valuable knowledge. Or experience, as some people call it.

And you know what? This knowledge is mostly transferred to the meetings. Don’t get me wrong, that’s a good thing in itself.

But when I’m in the middle of writing the best code of my life (or at least that thought helps me fall asleep at night), the last thing I need is a tiny reminder in the corner of my screen saying“It’s time.”

It’s time for another meeting.

2. Huge machine(mechanism)

I am very lucky to work for an extremely large company. And I thank my fate for this every day.

This is probably why the topic of this section will be particularly relevant to me. But each of us, in one sense or another, is a part of something bigger in our professional life. The main task of our companies is to write great code.

“But don’t we all need to be able to sleep soundly at night?”, I sometimes whisper at our cozy planning meetings.

However, the tasks are not limited to this, they are more ambitious. We must produce products and services. Meet the needs of our end users and customers. Eventually, earn a couple of cents.

And this, again, is in conflict 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 up in the hierarchy or an important client had a different opinion. And that’s what keeps me from falling asleep at night.

But we have to put up with it. In addition, to challenge wrong decisions (as you guessed, this happens in endless meetings), you can not influence the result in any way. You will simply be notified of the decision. With an internal message or a short conference call. To be fair, sometimes people listen to your arguments. This is great because it not only raises your self-esteem, but also makes you feel like you’re part of a Huge Machine.

There is a strange ambivalence — on the one hand, you want to be part of the mechanism, on the other hand, there is some bitterness.

A huge car is quite a strange thing.

3. Code quality and delivery time

If you got to this part of the article, you may have already noticed how much I love the quality of my code. Good code is my bread, almost literally. We can talk for a long time about writing perfect code (which doesn’t exist, I should note), but I think most of us will agree that this is at least what we’re aiming for.

But guess who will come knocking on your door with more urgency than on-screen scheduler notifications while you’re making the most out of the IDE?

Deadline for submitting projects. Deadlines.

It’s easy to understand that code quality and deadlines aren’t very good friends.

I must say that deadlines, of course, can be pushed back if the quality of the code does not suit us yet. Yes, this is happening. But the same is true in the opposite direction. The code is delivered even though it doesn’t have the quality that your team strives for in their daily work.

Because there’s a big hand hanging over all of us.

4. Checking the code

I immediately recognize that code review is a critical part of every development Department. I know this and I agree with it.

But, to be honest, studying code and solutions that are conceptually very different from the utopian constructions in my head is not my favorite business. Yes, you learn a lot at the same time. And others, I hope, also learn something from my digital writing.

If you work as a senior developer, you are constantly asked for feedback. Of course, during the code review itself, but also at other times, too. At the coffee machine, during planning sessions, even when you’re scratching your back.

In many ways, this is an honor for you, because it means that your thoughts and feedback are appreciated and respected. And I give it my due, without any sarcasm.

But when it comes to my daily professional life and personal level, I prefer not to look at other people’s work very often. I only learn someone else’s code if I want to learn something, or out of curiosity.

But I have to, I don’t have a choice. The more experienced you become, the more you learn about other people’s work and the more connected you become to it. Whether you like it or not.

5. Colleagues

This point applies to all of us, regardless of the position. If you didn’t create a brilliant app in the garage alone, you have to deal with colleagues.

Some of them are wonderful and may even become your friends. But I must admit: there are others. This is human nature: some people like us, some 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 this is unavoidable when communicating with people, with colleagues.

I’ll repeat myself: as we’ve already seen from the code review example, the more experience you have, the more you have to communicate with people at work.

Extroverts might enjoy it, 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 I am. It’s not like people have decided to avoid him: it was he who decided to avoid people.

It’s about the confrontation between him and the world. Larry versus the Big Machine.

He always attends planning meetings (without saying a word during all this time), but most of the time he looks at the screen or presses the keyboard with a force that its manufacturers did not expect. When his management asks him what he is working on, he answers in a quiet and serene voice: “You know what you’re working on.” And he doesn’t take his eyes off the monitor.

Management doesn’t often ask him what he’s doing.

It 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.

Anderson
Anderson
Web site editor and tester.

Leave a Reply

Your email address will not be published. Required fields are marked *