3 ms·

> Sorry for the adversarial tone From someone who called other people "toddler" ... > - not wanting to waste an average of 2 ... If you read my comment, you

by cauch 3y ago

> Sorry for the adversarial tone From someone who called other people "toddler" ... > - not wanting to waste an average of 2 ... If you read my comment, you see that I called it a "knee-jerk reaction", it is not sometimes I will really defend. It is just when I see people like you, self-centered and unable to accept that someone can like interacting at the office without calling them "toddler" and inventing that these person will interrupt you for no good reason after you make clear you don't like it. > Based on your views you are either ... None of these descriptions correspond to me. This just confirm my feeling that you "think you know all" but don't really. > and we are all snowflakes unreasonably complaining. Let's be clear on that: I have nothing against you complaining. My problem is that you are complaining about what others are doing to you but you are also complaining that others don't accept you doing the same thing to them. > They can't be good at coding if they don't understand the goal of the code That's my point: people need to communicate A LOT, ask questions, interact. Bad developers are the ones who quickly create a picture in their head and then run with it. I see that a lot in my work (I'm a scientist in the R&D of my company, working with developers to create implementation of the models and algorithms my team design). > Doing good work, for which you require peace and quiet and a focused state of mind, is what being good at coding is all about And yet, I see developers focusing only on that and yet producing shit software. > ... written form ... document well ... But this is not what we are talking about. No one here is saying that this should not exist. But is not sufficient. Let me demonstrate to you why. In software development, the whole process is based on the fact that bugs will happen. There are linter, code reviews, version controls that allow reverting, logs built in the code, advanced ticket system to deal with bug raising, ... Coding perfectly in one go is hard, impossible. Documentation and communicating things are obviously worse. Code are logical instruction with mathematical significance. Communication between person A and B can easily be misunderstood with both "being right", simply because human being cannot read minds and consider the thousand of possible mental pictures that the interlocutor has in mind. Because of that, documentation is bound to be more often incorrect than the code. It does not mean it should not be done, but it means that we should continue to continuously fine-tune our understanding, and it includes asking quick and easy questions. Again, you are misconstruing the situation: no one here is arguing that writing things down is bad or should not be done. Simply, different mode of communication have different purpose and different pros and cons. Asking questions is sometimes the correct and smart thing to do. > The premise that everyone is more efficient with constant interruption and questions pouring from every direction, all the time, is laughable at best. WHO IS SAYING THAT. Can you show ONE, ONE person here who is defending that? GP was simply saying that they like solving quick problem with a quick question, it avoids a lot of problem down the line or a lot of useless inefficient process. Your reaction was to invent that GP would bother you all the time for information that exists somewhere else. You just have to realize that the world is more diverse than your own little person: some team works with little questions and it works very very well. The fact that you have to call GP toddler because their way of working is not the same as yours is why I think you are the toddler here. In fact, it is not even that their way of working is not the same as yours: you even seem to be asking people to do things that you will refuse to do yourself.

ath3nd 3y ago
> That's my point: people need to communicate A LOT, ask questions, interact. Bad developers are the ones who quickly create a picture in their head and then run with it Hard agree! I do, however, believe there is lots of merit in establishing proper communication channels and protocols. Things written down do tend to stick more as institutional knowledge, and can be referred to later by other newcomers or when you simply don't remember why something was done. Contrast that with: "Oh yeah, Barry told me to do it like that last week while you were sick". > But this is not what we are talking about. No one here is saying that this should not exist. But is not sufficient. Also hard agree! Written docu and knowledge bases can never (and probably shouldn't) fully encompass all the institutional knowledge. Talks and clarifications are constantly needed. But let those work in an async manner, or in a focused effort, not random questions flying around. When you are done refining something, and the questions keep pouring in, sit together again to create a shared understanding, update the shared understanding, and 9 times out of 10 you will see the questions subside to a reasonable volume. > Let me demonstrate to you why. In software development, the whole process is based on the fact that bugs will happen. There are linter, code reviews, version controls that allow reverting, logs built in the code, advanced ticket system to deal with bug raising, ... Coding perfectly in one go is hard, impossible. Hard agree. I'd go as far as to argue that pre-planning everything in advance is insane as reality hits back pretty hard. > Because of that, documentation is bound to be more often incorrect than the code. Also hard agree. Tbh, I don't believe in documentation too much (gets too stale, quickly) unless it's autogenerated (API docs, for example) or set of often tested instructions what to run, or even loosely describing what this repo is all about. Another type of useful documentation out there is "aggregator" documentation, which simply gives you a list of all relevant things to do/check/read to get a good understanding of a problem at hand. > It does not mean it should not be done, but it means that we should continue to continuously fine-tune our understanding, and it includes asking quick and easy questions. Agreed 100%. However, if you see the quick and easy questions coming at too high of a volume that it overwhelms the team, then the team's institutional knowldge is being used as a crutch, or somebody is unsure of their understanding, and we should address that, rather than simply accepting it as an unavoidable fact. Maybe the person is too junior and needs dedicated handholding and going through the docs/repos/code together for a longer (scheduled) time? Maybe the docs are wrong? Maybe the consensus of last meeting was not really a consensus? All of these are things to be addressed, and not simply accepted that your colleagues always need to be there to enable your flow. > In fact, it is not even that their way of working is not the same as yours: you even seem to be asking people to do things that you will refuse to do yourself. I am asking for being mindful of other peoples' times and not advocate for people being at their disposal because of a bad onboarding experience they had. The OP is, in a way, advocating for returning back to an old way of working that was deeply inefficient to me and my team, just because they like it, without providing a notion whether his team mates liked it (I guess some did, some didn't). I am simply sharing the viewpoint that while some people really LOVE to ask questions and to immerse themselves in the office space, some don't, because it cab be really disruptive to their own flow and wellbeing.

by cauch 3y ago

ath3nd 3y ago

> That's my point: people need to communicate A LOT, ask questions, interact. Bad developers are the ones who quickly create a picture in their head and then run with it Hard agree! I do, however, believe there is lots of merit in establishing proper communication channels and protocols. Things written down do tend to stick more as institutional knowledge, and can be referred to later by other newcomers or when you simply don't remember why something was done. Contrast that with: "Oh yeah, Barry told me to do it like that last week while you were sick". > But this is not what we are talking about. No one here is saying that this should not exist. But is not sufficient. Also hard agree! Written docu and knowledge bases can never (and probably shouldn't) fully encompass all the institutional knowledge. Talks and clarifications are constantly needed. But let those work in an async manner, or in a focused effort, not random questions flying around. When you are done refining something, and the questions keep pouring in, sit together again to create a shared understanding, update the shared understanding, and 9 times out of 10 you will see the questions subside to a reasonable volume. > Let me demonstrate to you why. In software development, the whole process is based on the fact that bugs will happen. There are linter, code reviews, version controls that allow reverting, logs built in the code, advanced ticket system to deal with bug raising, ... Coding perfectly in one go is hard, impossible. Hard agree. I'd go as far as to argue that pre-planning everything in advance is insane as reality hits back pretty hard. > Because of that, documentation is bound to be more often incorrect than the code. Also hard agree. Tbh, I don't believe in documentation too much (gets too stale, quickly) unless it's autogenerated (API docs, for example) or set of often tested instructions what to run, or even loosely describing what this repo is all about. Another type of useful documentation out there is "aggregator" documentation, which simply gives you a list of all relevant things to do/check/read to get a good understanding of a problem at hand. > It does not mean it should not be done, but it means that we should continue to continuously fine-tune our understanding, and it includes asking quick and easy questions. Agreed 100%. However, if you see the quick and easy questions coming at too high of a volume that it overwhelms the team, then the team's institutional knowldge is being used as a crutch, or somebody is unsure of their understanding, and we should address that, rather than simply accepting it as an unavoidable fact. Maybe the person is too junior and needs dedicated handholding and going through the docs/repos/code together for a longer (scheduled) time? Maybe the docs are wrong? Maybe the consensus of last meeting was not really a consensus? All of these are things to be addressed, and not simply accepted that your colleagues always need to be there to enable your flow. > In fact, it is not even that their way of working is not the same as yours: you even seem to be asking people to do things that you will refuse to do yourself. I am asking for being mindful of other peoples' times and not advocate for people being at their disposal because of a bad onboarding experience they had. The OP is, in a way, advocating for returning back to an old way of working that was deeply inefficient to me and my team, just because they like it, without providing a notion whether his team mates liked it (I guess some did, some didn't). I am simply sharing the viewpoint that while some people really LOVE to ask questions and to immerse themselves in the office space, some don't, because it cab be really disruptive to their own flow and wellbeing.