3 ms·

What? This just seemed like a bunch of nonsense to me. Like let me make this clear, I am a born introvert. I prefer being by myself and doing my own thing. Tha

What? This just seemed like a bunch of nonsense to me. Like let me make this clear, I am a born introvert. I prefer being by myself and doing my own thing. That makes me happy. But that doesn't mean I hate being a team player, nor do I think programming is a solo activity. It is very much so a group one. And in my experience, the people that tend to go into a cave for a few hours and produce a solution will tend to produce the wrong solution. Because no spec or ask is perfect; you should be asking clarification and follow-up questions (even obvious ones!) to understand what is actually wanted. In more complex systems you might be working on a very small part, and exiting into the sun with a system that doesn't fit the rest of the system means you've spent the past 7-8 hours engineering a solution to the wrong problem.

satisfice 4y ago
You don't want me to have even a FEW HOURS to work out a difficult problem? That is utterly unreasonable. I think you are imagining only a certain kind of problem while ignoring many other kinds. It took me hours to work out how to make a lovely visualization using the Plotly library in Python. No one else knew how to use Plotly. I figured it out and gave them a demo. They are glad I went into the cave. Most of my work is doing blockbusting like that, not doing easy things. But certainly, if someone on the team knows something about the tech I'm researching, I check in with him.
- HWR_14 4y ago
  Spending hours learning something and sharing that knowledge is being a team player.
- fzeroracer 4y ago
  What you are talking about is something that only exists as the result of teamwork. We all rely on documentation, people asking questions, people giving answers and people working as a team. If you're working on rare things where you are the only expert on the team then yes, you can have the opportunity to go into full focus mode and hammer something out. And as the other poster said, sharing that knowledge after you've finished is part of being a team player. If you simply say 'I am an individual contributor, I turn in my work and then I'm done' that to me sounds like someone that's not interested in sharing knowledge.
  - watwut 4y ago
    > If you're working on rare things where you are the only expert on the team then yes, You dont need to be ONLY expert on the team for the above. Other people knowing the same thing dont prevent your knowledge of the system. For the above, you need to have passing knowledge of the thing you work on. And you should have build that knowledge while doing previous taks. The situation in which majority if tasks is assigned to developer who has no clue about that area of the system, again and again, is unreasonable.
deleted 4y ago
[deleted]
deleted 4y ago
[deleted]
ResearchCode 4y ago
You should ask (and preferably asynchronously, not by having random long meetings). Spending 7-8 hours working out a solution is however normal (on working with actual complex systems, like during a PhD, you might go a week between meetings but varies according to actual needs). You seem to be describing micromanagement.
watwut 4y ago
> And in my experience, the people that tend to go into a cave for a few hours and produce a solution will tend to produce the wrong solution. Because no spec or ask is perfect; you should be asking clarification and follow-up questions (even obvious ones!) to understand what is actually wanted. Genuinely, if there are so many questions that few hours of solitude are red flag, then something is massively wrong with the process at hand. It really means that tasks are less then underspecified and likely means testing/demoing processes are completely lacking. > In more complex systems you might be working on a very small part, and exiting into the sun with a system that doesn't fit the rest of the system means you've spent the past 7-8 hours engineering a solution to the wrong problem. Sure, you work in small part. But if all this is routine issue due to 7-8 hours if engineering, then the system is likely mess too difficult to decipher. It also means the development is overly chaotic. The developers working on the project should build up knowledge of the rest of the system overtime, this is somehow failing.

satisfice 4y ago

You don't want me to have even a FEW HOURS to work out a difficult problem? That is utterly unreasonable. I think you are imagining only a certain kind of problem while ignoring many other kinds. It took me hours to work out how to make a lovely visualization using the Plotly library in Python. No one else knew how to use Plotly. I figured it out and gave them a demo. They are glad I went into the cave. Most of my work is doing blockbusting like that, not doing easy things. But certainly, if someone on the team knows something about the tech I'm researching, I check in with him.

HWR_14 4y ago
Spending hours learning something and sharing that knowledge is being a team player.
fzeroracer 4y ago
What you are talking about is something that only exists as the result of teamwork. We all rely on documentation, people asking questions, people giving answers and people working as a team. If you're working on rare things where you are the only expert on the team then yes, you can have the opportunity to go into full focus mode and hammer something out. And as the other poster said, sharing that knowledge after you've finished is part of being a team player. If you simply say 'I am an individual contributor, I turn in my work and then I'm done' that to me sounds like someone that's not interested in sharing knowledge.
- watwut 4y ago
  > If you're working on rare things where you are the only expert on the team then yes, You dont need to be ONLY expert on the team for the above. Other people knowing the same thing dont prevent your knowledge of the system. For the above, you need to have passing knowledge of the thing you work on. And you should have build that knowledge while doing previous taks. The situation in which majority if tasks is assigned to developer who has no clue about that area of the system, again and again, is unreasonable.

deleted 4y ago

[deleted]

deleted 4y ago

[deleted]

ResearchCode 4y ago

You should ask (and preferably asynchronously, not by having random long meetings). Spending 7-8 hours working out a solution is however normal (on working with actual complex systems, like during a PhD, you might go a week between meetings but varies according to actual needs). You seem to be describing micromanagement.

watwut 4y ago

> And in my experience, the people that tend to go into a cave for a few hours and produce a solution will tend to produce the wrong solution. Because no spec or ask is perfect; you should be asking clarification and follow-up questions (even obvious ones!) to understand what is actually wanted. Genuinely, if there are so many questions that few hours of solitude are red flag, then something is massively wrong with the process at hand. It really means that tasks are less then underspecified and likely means testing/demoing processes are completely lacking. > In more complex systems you might be working on a very small part, and exiting into the sun with a system that doesn't fit the rest of the system means you've spent the past 7-8 hours engineering a solution to the wrong problem. Sure, you work in small part. But if all this is routine issue due to 7-8 hours if engineering, then the system is likely mess too difficult to decipher. It also means the development is overly chaotic. The developers working on the project should build up knowledge of the rest of the system overtime, this is somehow failing.