I have no words to describe the last meeting.

One of the project managers was putting his feet on the desk, chewing his gum with an open mouth, and playing around with his phone.

The people in the room were so tense and looks defensive, which is normal if you have dirty shoes in your direction.
Luckily I'm remote but at least I know that won't like to move to his team at any cost.

We had a planning meeting and it was mentioned that a specific story is too big and needs subtasks.

A team leader took responsibility to do that and guess what? The person just created two or three subtasks without any f*** content.
Yes, just a generic title and have fun figuring out the responsibility of each subtask.

A customer asks for a change request or a bug fix and it results in creating a ticket for that.
It's the process and how it works in most places but after you finish with the task and fix the same customer who provided you with the requirements will request that you share the steps on how to test the fix or the feature.
I'm not speaking about the data preparation or required configuration. I mean a step-by-step instruction on how the tester/QA will test it.
It's driving me mad!! So a way to counterplay this stupid requests, I provide the happy path and what to expect. And in case, they stumbled on a bug later in production, I can easily say "It was approved by your testing team and that's a new requirement ;)"

PR reviews, people leave great comment, some suggestions and there could be a discussion.

But please don't be the person who goes there and add those weird and useless comments such: "CI failed, your PR is behind dev branch..."
That's the role of the provider(Github, Bitbucket.....) and adding that comment is just a waste of time.

This start to happen more often and I had to rant about it :D

This is one of the weird moments that I have seen.

The company management decided to have a presentation session where they wanted to answer some questions and present some new ways of working (they emphasize about communication aspect).

I joined a couple of minutes before the meeting schedule and I was surprised to see a presentation going on and the meeting ended in 5 mn.
I get into self-doubt mode and I was checking if I have an issue with my calendar and discovered that the meeting schedule was updated but I didn't receive an update.

And the fun part, most of the new joiners didn't receive that update as well, so it's was a nice sign to show how inclusive the environment is, and how do they care about communication :D

Usually, the best approach to get a quick answer is by sending a DM.
To my surprise, the person mentioned that he will check it (then typical radio silence).

Next step, post in a channel that is dedicated to that topic, nothing.

Let's try an experience, I posted the same thing in a channel that the project manager has access to it. He just added an emoji and within 5 mn everyone was adding his input to the thread.

It seems that's the way how things work here 🤷‍♂️

Changing jobs sound exciting until you discover the onboarding experience.

No architecture overview, no presentation about core services. It's not a problem except that I have to navigate through the different services or hmmm the distributed ball of mud hmmm.

And then they ask you to estimate how long that X or Y ticket will take, so I give always the max possible number :D

When you spend hours in a messy codebase to fix a bug properly and add an integration spec to cover that specific case.
And even you do a round of testing on staging + providing screenshots, there is always someone on the team that will write in your PR, "It works, I tested the change on my machine".
I understand that some people are skeptical but to the point of not trusting integration tests + screeshots/recordings then please test it on staging or production next time because if it works on your machine doesn't mean it will work there ;)

"I want visibility in the sprint", "Information for everyone! When you do even a small refactoring, you should add a card to the sprint, clear?"
Those were the words of the product manager.

That sounds reasonable but when there is a bug to investigate, he just pops to the chat channel throw a request with a bit of information and asks to check/fix that.

So to keep my sanity, I asked him to create a ticket with relevant information and additional observations so we can have visibility as he was advocating for it ;)

It felt just good to see him going silent :D

With a nice cup of coffee, you start earlier than your colleagues, you do the hard part that everyone is afraid to touch.
But there is always someone who starts late his day and leave usually the first with a stupid smile.

I'm not the manager, so it's not my responsibility to control this person, I admit seeing this affects my motivation but I don't need to have his load on my plate.

I know that this case is quite common but I needed to rant about it.

#do_your_work_bob

Switching jobs is part of our career growth and as a developer, we do this every two years on average.
I know that after announcing my resignation my colleagues won't treat me the same.

It's like I'm an entity in the system that you don't have to query it anymore but you have to exhaust its knowledge transfer limit within the notice period.

All the facades and presenter layers will fade out and you will know which models care about you and want to keep the existent associations. Those models only deserve to publish your contact payload with them.

My requests will be faced by slow response HR endpoints and I'll have to rely on a retriable solution to access the required document data.

I was mentally ready for it but it's still painful as I have to endure this for 2 months, yes, the EU has longer notice periods.

Do you guys have tips to share from your experience?

I was checking my work Inbox and the first thing that I saw was a recruiter email.

So, let's check, is this my personal email, no.

Hmmm, maybe this is a prank or a test? check email domains and everything looks legit.

It seems that recruiters want to get developer attention at all cost nowadays. :D

Startup rant ---

John and Bob joined a startup at the same day but they were in two different offices.

John joined the US office while Bob joined the European office (let's not share the country here ;) )
Both of them worked really hard, they worked longer hours, showed result and helped the startup to reach and get Serie A funds.

That seems good no? But let's step back, John was promoted twice and get more perks while Bob got only a salary raise that aligned him with the current market.

There are different reasons for this but the most important one is that the company is having two different cultures for the two offices.

What's funny here is that Bob effort is well known across the two offices and his contribution has made a huge difference to the company but unfortunately he wasn't rewarded for it.

So Bob opened a new window not in his office but in his browser to find better opportunities.

I have colleagues that enjoy only drinking, nothing wrong so far but those guys are ordering a lot of crates monthly on the company budget.

You can see it as part of the fun or making the workplace enjoyable, what's wrong with having some relaxed atmosphere?

The funny fact that each developer has an education budget and guess what? you can't even claim it, the manager said no to conferences, if you want to get a book or training he will come up with 1000 excuses.

So when the company priority is spending thousands on drinks and ignore education and growth don't expect the motivated developers to stick longer.

---Startup Rant---

Being a senior developer doesn't grant the privilege to join a team and starting a drama out loud that everything is bad and you don't like it.

First, if everything is perfect there is no need to hire you.
Second, think about the value that you can bring to the team instead of making them feel bad, how can you prepare an improvement plan and start to learn the factors and reasons behind those decisions.

What's funny, it that the same guy after a couple of months starts introducing bad fixes and he says it's ok for the moment, it's not good but it's okayish, I wish I had a time machine for those developers!

---- Startup RantLife ----

In this episode, we introduce Brian, this guy is skilled and tries to provide an answer or explanation for everything (even if it's not work related).
By now you may guess this is the one that I know everything and you should listen to me type.

The problem with Brian that he wants only his solution to things and to be written exactly as he sees it and arguing with him is a waste of time.

How do you guys deal with developers like Brian?

---- Startup RantLife ----

A senior developer joined the team, let's name him Bob, and this guy is really good no doubts about that.
He made suggestions, some improvements, but Bob is always waving his hands and says out loud that some part of the code base is really really bad.
I kept quiet until one day I had to pair with Bob to check a feature. Guess what happened, as usual, Bob clenched his fist and start pointing that this code is super ugly.
So let's check the history of changes and boom, Bob was the main writer.
That moment, I was completely silent, trying not to smile as Bob came up with an excuse, he never admits that he is wrong, now he needs a scapegoat and he starts blaming the process, the planning...
I believe that being humble and saying sorry is a quality that it requires time to develop.
So don't be like Bob, please :)

is this normal?

I work in a small startup, we have only 6 developers.
Recently some changes were announced that a developer was promoted as the engineering manager and the second one as a team leader.
This sounds good and promising but isn't this somehow early at this stage and scale?
Did you guys had similar experiences where you end up having 3 managers (like me in this case) in a small startup?

We have a developer that is known for rejecting PR during code reviews.

He sent me a message and asked me to come to his desk to discuss my PR.
He mentioned that he didn't like my solution and suggested to rewrite the code together.
So far so good, he is a senior developer and I'm sure I'll pick something from the pair programming session. He went with his approach and faced some issues that led us to my solution after nearly 2 hours.
I'm not angry because this scenario happened at least 3 times but how do you guys deal with senior developers that are stubborn?

Really?

Far far away in a small startup, one developer was brave enough to try to fix the beautiful iOS application (hmm, nothing fancy just a broken, patched and served behind a wrapper).
To do so our hero needs, of course, a testing iOS device.
So the guy went searching for the testing device and asked around, then he returned to his desk shocked when I asked him what happened the guy told me literally:
- "Can you believe it? The boss gave the testing device to his fiancée"

and now guys you know why bugs in startup application take a while to fix :/