3 ms·

Screw these other commenters saying you're a stubborn introvert. If I had a company, I would hire you. I have the same view. Micro management erodes trust, whi

Screw these other commenters saying you're a stubborn introvert. If I had a company, I would hire you. I have the same view. Micro management erodes trust, which deskills programmers. If you know the exact bounds of what a programmer that you hired can do, then they can never do anything exceptional. I understand large companies need reliable workers because they are working on cornering their market, but for startups, or just for anyone going after something that's never been done, you need to take a risk, and that risk includes your programmers as well. What's more, there's a small but important difference between being told to go to a meeting and converse with other employees, or CEOs, or clients to get some external validation on your work, and choosing to seek out those people of your own free will. I agree that no programmer can silo themselves off and "do work", but that doesn't mean we have to infantilize them and spoonfeed them their feedback. A fisherman knows how to catch fish, so why are you telling him what lure to use and how to cast his line rather than just letting natural competition takes it's course and allowing him to become jealous of the better fisherman and having him improve. "Didn't catch a fish today" "well you should've used the red lures like Bob does". Do you want a better fisherman? or do you want the same fisherman?

KZeillmann 8y ago
It's not micromanagement. It's working as a team. I don't really understand what you're saying. Sometimes programmers are proud and don't want to seek out help. They'd rather spin their wheels trying to debug something than stoop to asking someone else for help. It's dumb but it happens.
- pwm 8y ago
  I'm not GP, but let me try to explain. The key is to treat people as responsible adult professionals with the best intentions. This way communication will happen organically and proactively. For organic proactive communication async channels are ideal. When you bump into a problem you need help with you message someone you think can help. They will eventually see your message and find the time to reply (seeing and replying won't always happen at the same time). This type of communication is extremely efficient and sustainable. Sync communication also has its benefits and they're trivial to set up using async comms if/when the need arises. This does not mean that recurring synchronous communications aka. standups are bad per se but their value is highly context dependent and oftentimes they are not the best solution. On the other hand if you treat people as irresponsible children that needs constant supervision then, in my humble opinion, nothing will save you on the long run and implementing mandatory protocols like a daily standup are just surface treatments.
  - zamber 8y ago
    Developers come in all shapes and sizes. Some barely use Slack and are laconic on standups. The whole Agile (tm) is a surface treatment for having a grasp on complexity. It's more of a ritual thing than an exact science. The introvert developers are sometimes so introvert and protective that they deliver at the last possible moment stuff that doesn't follow any conventions set by the team and in some cases makes stuff explode after merging. I would rather have them forced to give me an update and subsequently a pretext to get a peek at their work under the guise of helping than have them fail the whole team. Eventually they shed their impostor syndrome, or at least I hope they do. Personally, I've been on both sides of this pattern and I would rather still have standups. As for supervision, I've seen teams selling bullshit with glitter on standups if there were transitional people or stakeholders. Then it's nothing more than the usual status update dance.
- ravenstine 8y ago
  If the team is truly a team, that kind of goal-oriented facilitation really isn't necessary. While it's good to have some sort of institutions within a team, good quality teams tend to be self-organizing. If employers focused more on creating quality teams, they wouldn't need tools like Scrum to mitigate problems that might not even exist (the fact of which can easily be swept under the rug by rigid adherence to such systems). Sometimes I run into a really tough problem, and good team members don't need to have a system to force this behavior. In fact, I'd say it's within the prerogative of a developer to withhold problems they believe they can work through so that other cooks don't jump in to crowd the kitchen, and so that managers don't make a counterproductive decision to dislodge a perceived roadblock. As you say, some programmers are proud and don't want to seek out help. Does this reflect in their work? If it doesn't, then who cares? And if it does, then management should resolve the issue by whatever means necessary. Trying to force "I'm facing a tough bug" out of people is not the way. Creating a culture that fosters collaboration, on the other hand, seems more effective in getting people to seek genuine help. Just make standups about the people. Hire good engineers or engineers with potential and invest in them, and allow their team to function naturally. Remove the goal-orientation from standups and just give teams 10 to 15 minutes out of the day to just shoot the shit. Having to make it about going person-by-person and saying "Yesterday, I did X...", "Today, I'm doing Y...", or "I ran into some issues with X-thing", is really just like being back in elementary school where the teacher picks on students. I know some people don't seem to feel this way, but I'm really not that interested in going back to the 3rd grade.

KZeillmann 8y ago

It's not micromanagement. It's working as a team. I don't really understand what you're saying. Sometimes programmers are proud and don't want to seek out help. They'd rather spin their wheels trying to debug something than stoop to asking someone else for help. It's dumb but it happens.

pwm 8y ago
I'm not GP, but let me try to explain. The key is to treat people as responsible adult professionals with the best intentions. This way communication will happen organically and proactively. For organic proactive communication async channels are ideal. When you bump into a problem you need help with you message someone you think can help. They will eventually see your message and find the time to reply (seeing and replying won't always happen at the same time). This type of communication is extremely efficient and sustainable. Sync communication also has its benefits and they're trivial to set up using async comms if/when the need arises. This does not mean that recurring synchronous communications aka. standups are bad per se but their value is highly context dependent and oftentimes they are not the best solution. On the other hand if you treat people as irresponsible children that needs constant supervision then, in my humble opinion, nothing will save you on the long run and implementing mandatory protocols like a daily standup are just surface treatments.
- zamber 8y ago
  Developers come in all shapes and sizes. Some barely use Slack and are laconic on standups. The whole Agile (tm) is a surface treatment for having a grasp on complexity. It's more of a ritual thing than an exact science. The introvert developers are sometimes so introvert and protective that they deliver at the last possible moment stuff that doesn't follow any conventions set by the team and in some cases makes stuff explode after merging. I would rather have them forced to give me an update and subsequently a pretext to get a peek at their work under the guise of helping than have them fail the whole team. Eventually they shed their impostor syndrome, or at least I hope they do. Personally, I've been on both sides of this pattern and I would rather still have standups. As for supervision, I've seen teams selling bullshit with glitter on standups if there were transitional people or stakeholders. Then it's nothing more than the usual status update dance.
ravenstine 8y ago
If the team is truly a team, that kind of goal-oriented facilitation really isn't necessary. While it's good to have some sort of institutions within a team, good quality teams tend to be self-organizing. If employers focused more on creating quality teams, they wouldn't need tools like Scrum to mitigate problems that might not even exist (the fact of which can easily be swept under the rug by rigid adherence to such systems). Sometimes I run into a really tough problem, and good team members don't need to have a system to force this behavior. In fact, I'd say it's within the prerogative of a developer to withhold problems they believe they can work through so that other cooks don't jump in to crowd the kitchen, and so that managers don't make a counterproductive decision to dislodge a perceived roadblock. As you say, some programmers are proud and don't want to seek out help. Does this reflect in their work? If it doesn't, then who cares? And if it does, then management should resolve the issue by whatever means necessary. Trying to force "I'm facing a tough bug" out of people is not the way. Creating a culture that fosters collaboration, on the other hand, seems more effective in getting people to seek genuine help. Just make standups about the people. Hire good engineers or engineers with potential and invest in them, and allow their team to function naturally. Remove the goal-orientation from standups and just give teams 10 to 15 minutes out of the day to just shoot the shit. Having to make it about going person-by-person and saying "Yesterday, I did X...", "Today, I'm doing Y...", or "I ran into some issues with X-thing", is really just like being back in elementary school where the teacher picks on students. I know some people don't seem to feel this way, but I'm really not that interested in going back to the 3rd grade.