I'm pretty sure that if you write down a list of inconveniencing things, this cannot be anywhere but at the bottom. The fact that some person will cry and shout that it is very very inconvenient seems to just confirm this person is acting like a toddler.
But in fact you are right, "mildly inconvenient" may not be the best way to put it, it could have been "because otherwise you are as inconvenienced as they are if they follow your wish". After all, that is my point: I don't say it's not inconvenient for you, I'm just asking why should a group prefer the solution where A is inconvenienced and B not inconvenienced over a solution where B is inconvenienced and A not inconvenienced.
I think one is more inconvenienced than the other. If someone doesn't answer your question immediately, search harder. The answer is out there somewhere.
I think it doesn't really have much to do with what anyone wants. It's funny that I am inclined to think OP would be annoying, but this comment almost is doing the opposite of what you intended and swaying me the opposite way. Knowledge should be shared, and not under a list of very capricious conditions.
But, I get it, that's how you work and we've all got our things. I've never worked at an office, and I'm just realizing that all the discussions here could be solved by simply having a guy like OP paired with a guy who enjoys sharing their knowledge and unblocking these problems ASAP. A people person, which I get coders tend not to be. A guy whose flow is that, not just being an island out of a krazam sketch.
Hm, one could as legitimately argue: if the person who has the knowledge FAILED to document it properly and give it to the person who needs it. Then the person who has the knowledge is the one who deserve to have their flow disrupted instead of the person who notice they haven't done their work. Why should the person who demands the knowledge pays for the other person failure?
But more importantly, a grown-up would say: the two persons are collaborating, they are not fighting each other. The person who has knowledge is a grown-up, they will want the work to progress correctly and they will want to see their colleague succeed professionally and socially. The person who needs the knowledge is a grown-up, they will not ask over and over again when they see it disturbs the person who has the knowledge (and no one here is against that, obviously).
That's a sad way of seeing professional relationship, but also not a very smart way too: in real life, your own position is biased: when Mr X asks Mr Y a question, it is because Mr X truly believe it's a legitimate question. But maybe Mr Y has written the doc somewhere and Mr X missed it (which can and will happen). In which case, Mr Y will think Mr X is "wrong". But how Mr X can be sure he is not "wrong": Mr X does not know what he does not know. Or maybe Mr Y has written the doc, but badly. In which case, Mr Y will incorrectly think Mr X is "wrong". Or maybe ...
In short: grown-ups understand that communication is messy and that "counting points" is just ridiculous, inefficient and just something that a person who has poor understanding of the reality will think is fine.
> if the person who has the knowledge FAILED to document it properly and give it to the person who needs it. Then the person who has the knowledge is the one who deserve to have their flow disrupted instead of the person who notice they haven't done their work
Hard agree!
> But more importantly, a grown-up would say: the two persons are collaborating, they are not fighting each other. The person who has knowledge is a grown-up, they will want the work to progress correctly and they will want to see their colleague succeed professionally and socially. The person who needs the knowledge is a grown-up, they will not ask over and over again when they see it disturbs the person who has the knowledge (and no one here is against that, obviously).
Hard agree!
> In short: grown-ups understand that communication is messy and that "counting points" is just ridiculous, inefficient
Agreed. However, as engineers, if we see communication within the team being messy, you also need to judge is that okay, or could we improve it, by setting some ground rules or improving some process or maybe having more dedicated sessions for creating a good shared understanding. OP's thread, it felt to me, thought that messiness in communication was solvable only by being on-prem and able to ask quick questions, while I am convinced it can be solved far more elegantly and with less overall effort with a good, focused onboarding experience and even (or especially) in remote settings.
It is not like you asked a waiter for another beer as they walked back to the kitchen. They may have 1kb of level 1 cache they need to purge from their brain to help fix your eslint file.
> "we should just force people to go back to the office, just to teach those toddlers to behave like adults". (not always, it's just a knee-jerk reaction "oh come on, stop behaving like babies")
Sorry for the adversarial tone, but "we should just force people" to me shows you deserve to be chastised a bit. First of all, you are not an employer (luckily), so there is no "we", each company decides for itself how to handle remote, and luckily, many have weighed on the benefits and have decided to go with that.
Second, the premise of you saying "oh come on, stop behaving like babies" shows to me that you think that "behaving like a baby" means:
- not wanting to waste an average of 2 (unpaid) hours of your day stuck in traffic commuting (which, by the way, is also bad for the environment)
- wanting peaceful and quiet atmosphere where you can focus on your work without noise and people tapping you on the shoulders
And I don't want even to argue with that, it's that bad of a take. Based on your views you are either young and full of energy (not having children), or old enough (boomer) and with people taking care of chores for you (wife) that to you it is the norm and we are all snowflakes unreasonably complaining. I don't see our views and incentives aligning on this.
> The number one problem I see at my work place is devs that are good at coding but that are very bad at even understanding what is the goal of the code they are doing.
That's just bad developers. They can't be good at coding if they don't understand the goal of the code, that's an oxymoron.
> Between a great coder and an average coder, the one who is good at being interrupted is a better dev. Coding in itself is just part of skill, but it is not the most important.
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. Also, most of the times it's better if a discussion is in a written form (e.g slack/PR/ticket) so others can use it as a reference in the future, rather than a chat you and Josh had at the whiteboard. Being a good coder also means being able to document well what your reasoning are, what your design is, and how to implement it, both things which require you to write it the HECK down.
> For me, you are the one who sounds like a toddler who asks everyone around them to be less efficient just because otherwise you are mildly inconvenienced.
The premise that everyone is more efficient with constant interruption and questions pouring from every direction, all the time, is laughable at best. There is ton of research that office interruptions drag down the productivity of the group, while all you have is some boomer's feeling that people are working better where they can observe them.
I started this response by saying I am sorry for the adversarial tone of my response, but the more I think of this now, the more I am not sorry. I see opinions like yours as a part of the problem why the rest of us can't have good things and a quiet and productive work life. If you want to go the office to get immersed in the beautiful, inspiring atmosphere of rows of desks with guys with headphones click-clacking away on their keyboards and discussing the last season of Game of Thrones, be my guest and go for it, but I am happy that the rest of us can choose not to.
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.
> 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.
> I do, however, believe there is lots of merit in ...
Nobody disagrees with that. What are you talking about?
A quick and simple question can also be "naturally" followed by documentation. For example, when someone asks about an ambiguity in the doc, they will naturally immediately amend the doc after the clarification. Another example, they will write the code and the own existence of the code will clarify the situation for other users.
Some small questions are also not worth documenting. For example: "yesterday you said you will work on X and Y this week, and we are the middle of the week. Today I realize I'm interested in X because it is related to Z, did you started working on it already?". At the end of the week, the information answering this question will not be relevant for anyone ever.
> sit together again
This is very very inefficient to book meetings all the time at the first simple question. I really cannot see how you are able to work in such conditions where communication is over-burden with so much process.
There is pros and cons in a lot of way of communicating. Your position that quick and simple questions are not fit for any purpose is not really realistic, and you now need to grasp at straws to find argument to defend this position. Even if "a hyper-planified communication plan where everything is written down" would be ideal (which is still arguable), I doubt the benefice of it are big enough to be perceptible.
> However, if you see the quick and easy questions coming at too high of a volume that it overwhelms the team
Which is a dysfunction. You had someone talking about a process that you seems to now agree makes some practical sense, but you call this person "toddler" because of the remote possibility of pushing this process in absurd direction.
> 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.
You are calling other people "toddler" based on something that only happened in your head. It's a bit ridiculous to then talk about "being mindful of other peoples' [stuff]". Nothing in OP indicates that they are not mindful of other peoples' times.
> 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
No, OP just said he like one way of working, nowhere I see they advocate for forcing other people to do as they like. On the other side, YOU are calling names to people who don't do as you please.
> I am simply sharing the viewpoint ...
You are calling other people "toddler". You are now backing up on that now that you have to admit that your initial position was self-centered childishness.
Honestly, I think forcing people to work at the office is a very bad idea, but, karmically, for people like you, while I don't wish that upon yourself, you just don't have the ground to complain: you are a self-centered individual that calls other people "toddler" at the first occasion, if you end up with a boss that has a similar behavior and ends up coming up with the bad idea of forcing you back to the office, how can you criticize your boss?
