4 ms·

I don't see why you need to be writing code to understand all of this. It can help, but almost everything you said is ascertained from daily syncs

dv_dt 2y ago
Fewer or shorter daily syncs is a plus
Aeolun 2y ago
You don’t need to be writing code. But it’s a convenient shortcut to a great many things that otherwise take dedicated effort to understand. Some managers will do that. Most won’t. Given that, it’s easier to just tell them all to code.
- andoando 2y ago
  Or just tell them all to regularly communicate/listen to their team? Sounds way more efficient.
  - Aeolun 2y ago
    Doesn't work, because the team won't always tell you of the issues that block them (normalization of deviance). Sometimes you need to find out yourself.
    - windward 2y ago
      You can see this when you join a (disfunctional) new team, notice the friction, then suggest improving it.
  - strken 2y ago
    If a manager communicated with and listened to their team, but their team had written a web service with gaping security holes or disastrous data integrity practices because all their senior engineers were incompetent and/or were hired at a level that was above their ability, would that manager find out just from chatting with them? I promise you that it's not guaranteed. You need to actually go looking through the code to find everything that's wrong.
    - andoando 2y ago
      I think you can certainly learn a lot by being curious and fishing out anything that smells, yeah. But agreed that youll find more mistakes, if your manager also happens to be the best IC on the team.
icedchai 2y ago
Daily syncs allow the loud, not necessarily the most productive, to dominate. You cannot judge someones actual contributions by what they say.
- andoando 2y ago
  I didn't say you should be judging performance solely on daily syncs, but you have a myriad of ways of doing that as a manager including simply looking at the big-picture content of PRs, what issues a dev identified and solved, what devs contribute to discussions/technical solutions in slack/meetings, what projects are completed, and how well they turn out etc. But eh? Doesn't matter how loud you are in a sync, you can very easily go off the actual content of what someone is saying. If someone goes off 5 minutes about how they managed to turn an object into a json string, that doesn't exactly make them look good.
ozim 2y ago
I don’t see how you can understand something without being part of it. It is like learning stuff from the book vs learning hands on. There is no book that will teach you skiing. The same for working with the team - it is so much different than listening and trying to understand. Everyone nags about how MBA graduates ruin everything by thinking that you can manage and it doesn’t matter who and what.
- andoando 2y ago
  But you are a part of it. You are the manager of the codebase, you should actively be part of the discussions of what's being merged in, what your architecture looks like, what changes are required to complete a new project, what issues are arising, what the blockers are on projects, whats slowing down your team etc. None of that requires you to sit down and code. If you're really listening and asking the right questions you should be aware of even changes like "Were deciding to use this HTTP client rather than what we currently have". OK why are we doing that? What was the issue? Ask ask ask. As a manager Id argue you have (or should have) more technical insight into your whole codebase than any IC
  - jaggederest 2y ago
    How do you do any of that without extensively reading code? Do you consider reading large volumes of code not "sit[ting] down and cod[ing]"? Just because you're not actually producing large volumes of commits does not mean that it's not coding.
    - andoando 2y ago
      I think "coding" is commonly understood as writing code, not reading code, you know like if I say "I coded google jamboard", someone thinks I developed it, not read the source code. But besides, why do you need to extensively read code to understand whats going on? Assume you read your code base once and understood it. You get a feature, discuss how its going to be done (well add this table, add these endpoints, etc). You should have a damn good idea already what thats going to look like in your codebase. I don't think knowing all the low level details is necessary (most people would call that micromanagement) and besides writing code yourself isnt going to help know all the low level details of all the other projects

dv_dt 2y ago

Fewer or shorter daily syncs is a plus

Aeolun 2y ago

You don’t need to be writing code. But it’s a convenient shortcut to a great many things that otherwise take dedicated effort to understand. Some managers will do that. Most won’t. Given that, it’s easier to just tell them all to code.

andoando 2y ago
Or just tell them all to regularly communicate/listen to their team? Sounds way more efficient.
- Aeolun 2y ago
  Doesn't work, because the team won't always tell you of the issues that block them (normalization of deviance). Sometimes you need to find out yourself.
  - windward 2y ago
    You can see this when you join a (disfunctional) new team, notice the friction, then suggest improving it.
- strken 2y ago
  If a manager communicated with and listened to their team, but their team had written a web service with gaping security holes or disastrous data integrity practices because all their senior engineers were incompetent and/or were hired at a level that was above their ability, would that manager find out just from chatting with them? I promise you that it's not guaranteed. You need to actually go looking through the code to find everything that's wrong.
  - andoando 2y ago
    I think you can certainly learn a lot by being curious and fishing out anything that smells, yeah. But agreed that youll find more mistakes, if your manager also happens to be the best IC on the team.

icedchai 2y ago

Daily syncs allow the loud, not necessarily the most productive, to dominate. You cannot judge someones actual contributions by what they say.

andoando 2y ago
I didn't say you should be judging performance solely on daily syncs, but you have a myriad of ways of doing that as a manager including simply looking at the big-picture content of PRs, what issues a dev identified and solved, what devs contribute to discussions/technical solutions in slack/meetings, what projects are completed, and how well they turn out etc. But eh? Doesn't matter how loud you are in a sync, you can very easily go off the actual content of what someone is saying. If someone goes off 5 minutes about how they managed to turn an object into a json string, that doesn't exactly make them look good.

ozim 2y ago

I don’t see how you can understand something without being part of it. It is like learning stuff from the book vs learning hands on. There is no book that will teach you skiing. The same for working with the team - it is so much different than listening and trying to understand. Everyone nags about how MBA graduates ruin everything by thinking that you can manage and it doesn’t matter who and what.

andoando 2y ago
But you are a part of it. You are the manager of the codebase, you should actively be part of the discussions of what's being merged in, what your architecture looks like, what changes are required to complete a new project, what issues are arising, what the blockers are on projects, whats slowing down your team etc. None of that requires you to sit down and code. If you're really listening and asking the right questions you should be aware of even changes like "Were deciding to use this HTTP client rather than what we currently have". OK why are we doing that? What was the issue? Ask ask ask. As a manager Id argue you have (or should have) more technical insight into your whole codebase than any IC
- jaggederest 2y ago
  How do you do any of that without extensively reading code? Do you consider reading large volumes of code not "sit[ting] down and cod[ing]"? Just because you're not actually producing large volumes of commits does not mean that it's not coding.
  - andoando 2y ago
    I think "coding" is commonly understood as writing code, not reading code, you know like if I say "I coded google jamboard", someone thinks I developed it, not read the source code. But besides, why do you need to extensively read code to understand whats going on? Assume you read your code base once and understood it. You get a feature, discuss how its going to be done (well add this table, add these endpoints, etc). You should have a damn good idea already what thats going to look like in your codebase. I don't think knowing all the low level details is necessary (most people would call that micromanagement) and besides writing code yourself isnt going to help know all the low level details of all the other projects