Do all the things like ++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatarSign Up
SukMikeHok1019875dis bob a team leader of that project?
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 :)
elfico184674dMoral of the story, don't be like Bob
gradlefailed7674dThere 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...
Wolle21474d@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.
Nanos542674dManagers are supposed to take responsibility for their team members mistakes. :-)
But not the blame..
Nanos542674d> I believe that being humble and saying sorry
> is a quality that it requires time to develop.
In my experience, most people either have it, or they don't, few learn to change for the better.
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.
Your Job Suck?
Take a quick quiz from Triplebyte to skip the job search hassles and jump to final interviews at hot tech firms
Get a Better Job