Programming

17532 readers

263 users here now

Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!

Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.

Hope you enjoy the instance!

Rules

Follow the programming.dev instance rules
Keep content related to programming in some way
If you're posting long videos try to add in some form of tldr for those who don't want to watch videos

Wormhole

Follow the wormhole through a path of communities [email protected]

founded 2 years ago

MODERATORS

snowe

Ategon

[email protected]

Tips/Resources/Guidance for becoming an okayish lead? (feddit.de)

submitted 9 months ago by [email protected] to c/programming

14 comments fedilink hide all child comments

I'm currently a senior developer, but relatively new in the role of a "lead". In my current project, I'm having a kind of co-lead and we have two devs working in our team. So a rather small enterprise.

Now my boss told me, that going forward, I will probably be leading larger and more complex projects (possible rather soon).

Since I'm constantly doubting myself, I would really like to learn more about how to be an effective/likeable lead. I've had too many "leads" who were just dogshit, professionally and as a person. I don't want to be that (at least the professional part).

So, I guess my question is: what helped you? Books, articles, just random hints or strategies? I'll take everything.

you are viewing a single comment's thread
view the rest of the comments

[–] [email protected] 28 points 9 months ago (6 children)

Personally, I've had an experienced manager and took great inspiration from him.

A few things I fell into:

it was a lot faster for me (I.e. experienced senior dev with context knowledge) to finish a task than for me to assign it to someone less experienced who has to learn the context and takes 5x as long to do it, with lots of help needed from me still. This yielded me not building up my team either in experience or knowledge.
I assumed deadlines I got told were set in stone and my job was to meet them. This made business-y people happy. It made everyone else (including me) miserable. I had to learn to say no and push back, it very much changes between companies but most of the time I found it to be a negotiation and either the deadline could move or I had to argue to exclude things from the scope to make the deadline reasonable.
on the above, everything takes at least 3-5x as long as I think it takes. If things finish early, great time to give my team some slack, add in additional QA work like extending tests or repay some tech debt. Delivering something early gives a pat on the back for us but no discernible benefit to the team.
every time someone said "you'll have time to write tests/repay tech debt/upskill later once X is shipped" it never came true. Those things have to be built into delivery scopes, and it's a constant battle - if you don't do this, nobody else will.

I'm sure there were other things too, but these are the ones I mainly recall. Talk to your team, ask for feedback. Every team, project and company are different - you'll have to adapt.

[–] RonSijm 3 points 9 months ago

I think I couple of those points come down to the tech-lead to write a "Definition of Done"

1 - This is useful for junior members or new members to know what to expect. For example, "Definition of Done" would include that a new function should be documented, it should be refactored into clean code by the code standards, it should be tested by QA, there should be unittests covering the function, the function should be released to production to be marked as done - etc

2 - When giving managers that don't know anything about coding an estimation - either by you, or by someone in your team - they can take the Definition of Done" as a reference point. If a manager asks how long something will take, you don't just consider "Oh, I guess I can build this in a couple of days". Yea ok sure, you can build it to meet the managers minimal requirements for the function to kinda work but its messy code and untested - so if you keep in mind that there are loads of other meta-things to do besides just building code, you can pretty much double your initial estimation

Otherwise you just accumulate more and more technical dept, and at some point your "just build it" estimation gets inflated because for every change you have to touch lots of 1000 line files, figure out what broke by the changes, fix that, see what failed now, etc etc

And it would have been better in the long run if you would have spend more time on it while you were working on the function

load more comments (5 replies)