---- 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 bob a team leader of that project?

@SukMikeHok

hopefully not, did you have similar experiences with team leaders?

@justDeployIt i am supposed to be a team leader for the first time soon

but i always admit my mistakes, i even put the blame on me even if someone else fucked up

just looking out for advice of a good skills a team leader should have

@SukMikeHok that's a very good leadership skill

@SukMikeHok

Congrats for the promotion!

You asked a good question, what are good skills that a team leader should have?

It's easy to point out bad habits of team leaders and that's why I suggest to go through your experience and note every bad habit that you didn't like from all your previous team leaders.
Once done, you can work on avoiding those habits. It's like solving the problem from a different perspective.
I hope this may help anyone in the future :)

bobsn't

@SukMikeHok try not to take others' blame. They'll never get better if they aren't responsible for their mistakes.

Moral of the story, don't be like Bob

There are a couple of times when my senior saw a block of code and say who did this... I'll be like i dont know, lets check commit history and boom his name appears in commits...he is like hmm okay I'll fix it then don't worry...

@svgPhoenix @SukMikeHok I slightly disagree. My last Boss was very good a protecting his Team from upper Managment and other Teams (so kinda took the blame for our fuck ups). And then he dealt with it internally, aka he told me I fucked up and had to fix it etc.It was very easy to trust him, because he didn't throw us under the bus and still kept us responsible.

@Wolle sounds like a great manager. I didn't think about the difference between being held responsible by your direct boss vs. upper management and other teams

I criticize code quality a lot, but I always try to frame it like "I could've written that".

Because the reality is, I could have.

The reality that everyone starts writing code iteratively. My first language was c64 basic, with a lot of if then else goto line 126749 steps.

A "senior" points out that long iterative routines are bad™, because they don't separate concerns and are difficult to maintain, debug and test. You easily insert a statement on line 126739 which breaks code on line 126748.

Then you might go full OOP, wrapping every Type in a DTO, setting up interfaces for all your classes, using dependency injection, bridges, composites, factories and whatnot.

Then someone points out that your code is bad™, because all you were trying to do was to map values in a tree and reduce them to a single value, and all your OOP structures should be archived under "pretentiously overengineered crap"

Then you see the light, you write an FP library which implements strong types and catamorphisms over monadic functors and then use arrows and lenses to map the json string... And then the juniors complain that your code is bad™, because they get confused when you talk about morphisms and codomains and categories.

Good and bad are determined by so many factors, many of which determined by fuzzy subjective shit like "readability" and "maintainability".

There are some guidelines, some vague rules of thumb and tricks to improve truly evil code, but very few absolute truths.

There is only one absolute truth: If you can not point and laugh at how stupid your code used to be, you aren't growing as a developer.