People like you are the reason I personally don't want to be in an office.
> asking quick questions and getting an instant answer. vs chat where I may not get an answer for hours.
Basically like having a toddler around. Sorry for the negative take here but how it's written it feels like you don't necessarily realize that some people do need deep work, and prioritize your quick satisfaction to other's focus. Or I might be projecting, but I simply can't stand incessantly being asked questions, I view it as a type of interruption.
> running ideas by others. This doesn't happen on chat for me, and VC is too scheduled.
Yes, because who needs order in their time when somebody just wants to ask the group from their opinion, without even bothering to write it down. Also, whoever is sick that day and missing from the office, that's on them, whatever discussion happened, no evidence of it, so sucks to be them I guess.
> I don't feel connected to me team at all working from home
Please don't cross into personal attack. We have to ban accounts that do it repeatedly, so if you'd please review https://news.ycombinator.com/newsguidelines.html and stick to the rules, we'd be grateful.
Also, please don't post in the flamewar style generally. It's not what this site is for, and destroys what it is for. We want thoughtful, curious conversation in which people are open to learning from one another.
> it feels like you don't necessarily realize that some people do need deep work, and prioritize your quick satisfaction to other's focus.
This is very one-sided. If you can unblock someone now so they don't spend 3 hours searching through the local intranet for some information, then that makes your team faster. There's a balance to be had, of course, but your team's overall delivery is what's important.
> I view it as a type of interruption.
It's not your view. Of course it's an interruption. That doesn't make it bad.
But it's not a dichotomy between 3 hours or instantaneous. It's a dichotomy between instantaneous and when someone has a break in flow to peek at messages, which IME is more like 15-30 minutes (and i think it's probably fair to ask people to peek around that frequently if they normally wouldn't)
There's a very clear benefit of asking someone for help, when you're blocked.
WFH comes with a lot of issues, when it comes to a timely response from people.
I had many of colleagues in the WfH world, that just ignored me for a month...
The idea that all engineering is highly focused and non-social just feeds the rockstar developer culture. And most of us aren't even close to rockstar status.
There is always a balance between collaborative discussions and focus time. I thought that we learned it 20 years ago, that devs should not hide away in cubicles?
> If you can unblock someone now so they don't spend 3 hours searching through the local intranet for some information, then that makes your team faster.
I'll be blunt here. I have very little interest in how the team I'm part of performs in general. Trying to make one person feel guilty that someone else can't do independent study is very toxic in my opinion, and I usually remove myself from under management that approaches leadership like that.
Asking questions should always be done, in my opinion, _after_ you tried to unblock yourself by RTFM-ing. If people feed you information every time you're stuck, it seldom sticks to your mind as well as going through the motions yourself.
>I have very little interest in how the team I'm part of performs in general.
Your job security is extremely dependent on the health of your company and team. If the structures which provide your employment contract start failing, and you do nothing about it, don’t be surprised if you get bitten.
I don’t expect appeals to empathy will work based on your posts, and I hate “we are a big family” smoke and mirrors too, but let’s be pragmatic here. The fact that your job even exists is predicated on a social and legal contract to provide your expertise for the benefit of a multi-person entity.
Team health does also depend on nudging those who can’t RTFM to do so… you can be an asshole, but you need to be a prosocial one as far as the company is concerned.
> I'll be blunt here. I have very little interest in how the team I'm part of performs in general.
Don't be surprised when others show the same level of empathy towards you, then. It's not about making you feel guilty, it's about making you do you effing job. Unless you're in a very junior position, your job is not to pump out code day in and day out.
I'm not sure what exactly you're reading in my words, but I don't really understand why you think it's my "effing job" to provide training for inexperienced developers. My contract stipulates no such thing, and despite what you seem to assume, I have been in fact hired to find solutions, and write code.
It's a little disconcerting to see someone make such self assured inferences about me, based on a single comment.
when i hire someone, their job is to do whatever it takes that is in their capacity to move the project forward. if it takes a larger team, then getting new team members up to speed is part of that. and if that new team member is unfamiliar with the frameworks the team is using then training them on that is part of the job too.
Aka "hands off management", "or absentee boss" or "sink or swim". Love it! Let me float an idea though, I might be dreaming here, but what if there was a better way than just dumping people and resources and hoping for it to work?
How about you encourage the team to actively monitor where onboarding takes time, year by year, learn from that, make onboarding materials which encompass institutional knowledge, and make the process as much self serve as possible?
Or assigning a "buddy/mentor" like persona that is responsible for this specific onboarding, so the rest of the team don't get distracted + the expectations on delivery are lowered for the "buddy"?
> it takes that is in their capacity to move the project forward
It takes quiet and uninterrupted work and focus time, and spending effort on making onboarding as smooth as possible. Just hoping your devs will do all the work of onboarding + their own work, and you doing nothing, that's just...what I expected I guess.
you are reading way to much into what i said. nothing what you are suggesting has anything to do with it. we all have work todo and we all need to contribute to training the new hires in some form. this has nothing to do with hands off management. i am not saying: here is the newbie, get them up to speed, but: we hired someone new, and we need to figure out the best approach to get them integrated. for me that includes that they work with everyone on the team for some time. including me if i am still involved in the development myself. i'll do my part of the onboarding and everyone else will do theirs.
being that buddy/mentor is part of your job, and i expect everyone on the team including me to be able to take on that role as the situation demands.
moving the project forward takes quiet and uninterrupted work and focus time
and it takes making sure that all team knowledge is shared with everyone. where do you get the idea that i do nothing? it is my job to allocate resources properly, but it is also my choice how to to do that.
you seem to look at onboarding as a kind of burden that i throw onto you on top of your other work that you'd rather not have to deal with. i see onboarding as part of the process to grow our team, exchange knowledge and experience and enable us to do ever better work.
when i am starting a new team then i onboard/mentor everyone myself, until the team is grown enough and some of the team members have enough experience to share that role. eventually, the team will be large enough to divide up into multiple teams, but i am still the one doing the hiring, and i'll be involved with onboarding until the company grows so large that it no longer makes sense to do that personally. but at that point i'll still make hiring decisions because i feel that hiring the right kind of people is to important to completely delegate.
the attitude that i expect from my team is that everyone is made welcome and we all do our best to get them integrated. onboarding materials can't replace that attitude which i see as necessary for the team to work well together.
Are you just telling me that you don't want to do your job properly as a hiring manager, which in my opinion would be to get the best people for the job, and that you prefer to pass the buck to your team to train them?
I mean, sure, that's fine if this is stipulated from the start, but if you expect someone to solve leet code, do programming homework, and then when they get hired they have to also navigate your extra requirements and teach people the basics of their job (because probably you couldn't be bothered to pay enough) then in my opinion you're taking advantage of these people pure and simple.
And to top it off, I know managers sometimes fools themselves that the team is invested in the "project moving forward", but that's rarely the case. As an individual I probably don't give a damn about the project, unless we're solving one the big issues of the world. The bullshit CRUD application you work on, or the latest cryptocurrency is just a means to get a paycheck for most of the people, and if you expect anyone to fake enthusiasm for it you're just deluded.
the best people for the job are not necessarily those that need no training. there are a lot of things to consider. part of that is that while new hires may need training, they also bring experience and knowledge to the team that others can benefit from. training doesn't only go one way.
you seem to prefer working on your own, neither willing to teach nor learn from others. that's fine if you can find a job as a lone developer, but i don't consider this a suitable attitude for working on a team.
I care, but I care as a result of some projects moving forward being part of my annual goals and affecting my bonus. I agree with the spirit of the post though.
> Are you just telling me that you don't want to do your job properly as a hiring manager, which in my opinion would be to get the best people for the job, and that you prefer to pass the buck to your team to train them?
Not all jobs are simple enough to hire people into with generic skills. People need training. Even if it's just "I think that other team should prioritise this feature for us; who do I ask?" People need to ask questions and bed in over time. If you've just done simple CRUD apps in small orgs you may not have seen this, but that doesn't make it not the case.
> And to top it off, I know managers sometimes fools themselves that the team is invested in the "project moving forward", but that's rarely the case. As an individual I probably don't give a damn about the project, unless we're solving one the big issues of the world. The bullshit CRUD application you work on, or the latest cryptocurrency is just a means to get a paycheck for most of the people, and if you expect anyone to fake enthusiasm for it you're just deluded.
You seem to keep on inventing things no one is saying to respond to. If you have a load of unrelated things to get off your chest that's fine I suppose, but it seems you actually think people are saying this and you're making points in response to them.
How so? The camaraderie that companies try to enforce on their low lever employees with this kind of manipulation is nothing but a ruse.
Why do you think that a whole team of people should be responsible for the inability of some? I have empathy for individual people that start their careers and struggle, but I also believe that if you apply for a job, you should be qualified to do it independently.
camaraderie in a team is a job requirement for me. without it i'll be out of there in no time. i simply do not want to work with people who can't be bothered to be nice and helpful to each other.
i do not want to be just a cog in a machine that grinds out work without any consideration for the project as a whole.
it is also needed to allow new team members to get onboarded faster.
as a hiring manager i find your attitude unwelcome.
That's perfectly fine. I think the world is large enough so we can coexist in peace.
Also I don't dismiss camaraderie that appears spontaneously between coworkers, I was complaining about the company enforced fake camaraderie that gets pushed down everyone's throats with trite team building exercises, company parties, team goals and other methods of hammering people into conformity.
> it is also needed to allow new team members to get onboarded faster.
Of course, it's fine to have team members absorb domain knowledge through interactions with their peers, but if that's the only way to on-board them, I most definitely don't want to work for you, but again, that's fine, I'll just look elsewhere.
> I was complaining about the company enforced fake camaraderie that gets pushed down everyone's throats with trite team building exercises, company parties, team goals and other methods of hammering people into conformity.
This is nothing to do with what you said before, about not wanting team performance to be important. Unless you're there to do a very specific job, a lot of performance is actually about team performance. If nothing else, the bus factor on people who want to do things solo makes them an automatic liability.
i agree with the forced stuff. but i expect a level of interaction to be naturally there so that enforced camaraderie is not even needed.
it's fine to have team members absorb domain knowledge through interactions with their peers, but if that's the only way to on-board them, I most definitely don't want to work for you
ok, you lost me here. what other way is there? it's not possible to assess all the knowledge a new hire has. if i have to hire a trainer to get them up to speed it will just cost more money and they will not learn the company specific domain knowledge.
in my experience specifically onboarding can only be done by others on the same team. it's a teams responsibility.
Of course there is a balance needed. But spending once 3 hours to search something might increase familiarity with the resources the intranet provides. So the next question could be answered way faster. Or it could be the occasion to improve the local intranet with some missing cross reference or some comment.
I think if we constantly interrupt each other, we should very critically ask ourselves if that's the proper way forward. Often people physically being there is used as a "crutch" or a "band aid" to bad onboarding practices and big knowledge gaps. I am tired of people seeing their team drowning, distracted, noise, responding to the same question 31040041 times and then simply saying: "well, I need to be there in person to help Josh, he just started". While that's a good team spirit, you gotta look beyond that. There are things you can do to make it easy for yourselves and the new starters.
Of course, people are responsible for their own productivity, but there is also such a thing as a team. And the team itself will benefit if people are less disruptive of each other.
My point is that teams should retrospect aggressively on where they spend their time, and if they find that lots of their time is spent on answering questions to onboarders or big knowledge gaps between one another, they should do something about it.
I won't waste space here outlining what can be done, but there ARE things that can be done. Do those things, and then the argument that you:
A) "must" be in the office to do good collaborative work
B) and you "have" to ask 5 min questions all the time
loses any validity and becomes just corporate laziness and bad management.
Sure, and if you can't keep up then you should reflect on that. Meetings and discussions are great. Constantly nagging your coworkers because you can't figure out how to do your job on your own is not.
> Constantly nagging your coworkers because you can't figure out how to do your job on your own is not.
This is the problem: you've invented this scenario. There is a gaping middle ground between what people are describing and your stereotype of what they "must really mean"?
I think the problem is that too many of us have experienced this scenario, and had it described much in the way that the OP of the thread did.
Too many people are too un-self-aware to recognize that their "just a 5-minute question" is being asked because they have not internalized the knowledge, rather than because it's genuinely something that they haven't had an opportunity to learn—too un-self-aware to recognize that this situation is unnecessarily stressful and it's their fault.
Yeah people do this simply don't recognize that they are annoying other people. From long time ago I have figured that there are two kinds of people in this world. One is more aware to him/herself and one if more aware to the outward world. Group 1 are usually tagging other people for their benefits (or, for the team's benefit as they so see it) while Group 2 do not do that very often.
Of course this has nothing to say with selfishness or else. It's simply that each Group project their own ideas to the outward world -- so people who like to outreach think other people like that too, while people who doesn't think the inverse. But taking a step back as a third party, we would realize that Group 2 is usually more harmed than benefited.
> Too many people are too un-self-aware to recognize that their "just a 5-minute question" is being asked because they have not internalized the knowledge, rather than because it's genuinely something that they haven't had an opportunity to learn—too un-self-aware to recognize that this situation is unnecessarily stressful and it's their fault.
This is just assumptions though. Too many? Compared to what? Narrators are just as unreliable as anyone; some will be unreasonably opposed to any questions. Complaints aren't all 100% trustworthy. And complainants can also be un-self aware in that when they were more junior, or new, then they also asked questions. They just maybe had people answer them who were more happy to invest in them.
I think I would be fine not having you in the office, given your condescending response..
> Basically like having a toddler around.
I changed jobs during lockdown. When I've joined other companies earlier, everyone knew to step in to help the new guy. So people would constantly ask me how I was doing, see if I were struggling and ask to help me, or I could just poke someone in the room.
But getting onboarded remotely during lockdown (in a non-remote-first company), I didn't know who to ask. No one could see me being stuck. I couldn't just ask out in the open room. Writing a message in a chat channel meant it could take ages before I got any help to get going.
Yay to me for at least not "disturbing" people. But the tradeoff here is that the whole team suffers as a team, just so people can have personal productivity. Which I think lessens speed in the long run. We're not code-monkeys picking Jira-tasks and dishing out features. We're working on a project together.
When I read your account of your onboarding at two different companies, I can only see a company with a good culture and another company with a poor culture. If you had onboarded the first company remotely, I bet you would have got check-in messages. Similarly, if you had onboarded the second company on-site, nobody would have cared about how you were doing.
Yes, but that's the company culture the one I'm replying to is advocating for. A culture where you never should dare asking anyone for help, as you're inconveniencing them. Just sit silent with your problems and schedule a meeting the next day, and they might find it in their heart to help you. Or also get annoyed by "all the meetings destroying their focus time"..
I advocate for another culture, as I've seen everybody beihg happy with it.
I advocate for a culture where onboardings are mostly self service and most documentation is up to date, frequently available, and easy to access. A culture where people are not afraid to ask questions, but they rarely have to, because most of the stuff is at the docs, and they never wonder who to ask, because they've been told who their onboarding "buddy" is. The person being onboarded is also aware that it's probably a good idea to batch their questions into a list, so they can discuss them with their buddy during their scheduled meetings, but is also not afraid to ad-hoc ask questions, because no documentation is perfect. If these ad-hoc questions are too much and too often, it might be that something in the self service is missing, and that is remedied accordingly.
In the culture I advocate, everybody's satisfied, learned well, and mindful of each other's time and flow, and it has nothing to do with being in the office or not. In fact, I have anecdotally noticed that in-person companies are more likely to use existing people's time and attention as crutches for compensating for a the lackings of a comprehensive on-boarding plan, which is what I believe the OP experienced and wrongfully thought to be the solution.
Sounds like the remote company wasn't that good at it, or at least the team you were in.
At the very least they should have assigned someone to be your mentor for coming up to speed.
That way you have someone you can ask (and you're aware you should) and you're not just forgotten about and left to you own devices, which is rarely successful.
> you don't necessarily realize that some people do need deep work, and prioritize your quick satisfaction to other's focus
Surely there must be ways to balance these things?
When you want to ask someone a question it shouldn’t be too hard to infer whether it’s a good time to do that now or you should wait (if it is, well it’s exactly a very hard skill to learn if you put in some effort)
That's no different from being in an office though.
If someone taps me on the shoulder and says they need a few minutes of my time looking over problematic code or whatever, I can say "sure just give me about 15 minutes to finish off this X/Y/Z"
When someone is relegated to doing this over Slack/Teams/whatever, the other person might have their notifications muted and rarely check for new ones. So it could end up being several hours of waiting.
Just because someone checks in with you IRL and asks if you have time to help with a question doesn't mean you need to be interrupted from "flow".
A notification is a quick glance in the corner of the screen, a tap on the shoulder is turning around to look at and focus on the person talking to you.
The latter is a full context switch to me. It will often leave me having to try to remind myself what I was just thinking and having to rebuild that thought.
I used to work in an open office and one guy had a light mounted to his cube. When it was red it meant do not disturb. Green meant he was available for whatever.
No, you don't. You need to communicate it effectively to 6 people and be open enough so they aren't waiting for the 15 minutes you claim to have free. IN general, if folks have a question and can easily see that you don't want to be interrupted right then, they'll wait a bit.
Instead of "just a quick question", the OP could prepare a list of their questions, and ask them all at the allocated time. A scheduled deep dive into the questions the OP has might even be more productive than multiple unscheduled disruptions of others' time.
And in an open office, even if you ask only a single person something, others might hear it too, despite the question not being intended to them.
We are talking about multiple people's brain cycles being dragged out their focus space, we are talking multiple conversations happening next to you, we are talking about click clack of people's keyboards next to you, and people moving going to take a coffee in your peripheral vision. It's a nightmare.
So what you are asking is that OP destroy their own "deep work" a lot just that you don't get a mild distraction in yours.
> And in an open office, even if you ask only a single person something, others might hear it too, despite the question not being intended to them.
I guess I'm special, because when I'm in a "deep work", I just don't hear people around me. I know it's not the case of everyone, some of my colleagues just put noise-suppression headphones, which is yet another easy way to solve your problem without forcing others to cater to your needs.
Of course, open space can be bad, and there are numerous examples of crazy open space situations. But what OP was describing is clearly not to the extend of what you are talking then.
Propensity for distraction varies a lot between people.
For me it varies on a day to day basis. Some days I could focus through a hurricane while others people buzzing around me is enough to make it difficult to think at all, let alone deeply. It averages out to normal productivity but I’d rather have fewer low productivity days, if I had the choice.
> some of my colleagues just put noise-suppression headphones
Great. Now the rest of us have to put up with even more noise.
People wearing headphones make a lot more noise themselves. Presumably because they don't hear the noise they make. Suddenly there's heavy breathing, sighs, grunts, moans, inaudible and sometimes disturbingly audible mumbling, humming &c.
I'm not when it's normal noises, made by non headphone wearing people.
Normally people are conscious about the sounds they make and restrict them a bit. If you're coughing in a group, you try to do it softly, or you leave the room. Things like that. When people wear head phones this kind of subconscious self control seems to be a lot less effective.
I'm certainly not the only one to have made this observation.
I sometimes start audibly breathing with headphones on. Something I never do without them. So I won’t wear them around others when I can avoid it.
That’s aside from tapping I might not realize is making noise with headphones on, or a particular motion in my chair that’s making it squeak and I don’t know it because headphones, et c.
Loud breathing is one of my biggest concerns when wearing noise-cancelling headphones around others. Partly because I dislike hearing it from others and don't want to subject them to that, and partly because I don't want to sound like a smooth-brain mouth breather.
> So what you are asking is that OP destroy their own "deep work" a lot just that you don't get a mild distraction in yours.
Yes! I believe the OP should write down all their questions in a structured format, and then schedule a meetings with 1 person helping them onboard, where they can discuss the questions at length and go on any tangent, rather than interrupt colleagues ad hoc. That's a normal, grown up thing to do, and it will also help them crystallize and distill what knowledge is missing.
> I know it's not the case of everyone, some of my colleagues just put noise-suppression headphones, which is yet another easy way to solve your problem without forcing others to cater to your needs
I do put noise suppression headphones, but they can't stop the people moving in front of me nor the taps on my shoulder.
> without forcing others to cater to your needs
Not wanting to be interrupted is not forcing others to take care of your needs.If you are unsure what I mean, let me call you in the middle of the night because I want to have a conversation with somebody and discuss economics. You not wanting to pick up is completely normal, right, or are you forcing ME to cater to your needs of being left the heck at peace? How dare you forcing me to have normal boundaries and call you at reasonable times!
No, it's the people who interrupt others and forcing to drop everything else so they answer "just one tiny question" and expecting it to be done on the spot. That's forcing people to take cater to their needs! Hence me liking the OP's behavior to that of a toddler.
> I believe the OP should write down all their questions in a structured format, and then schedule a meetings with 1 person helping them onboard, ...
Let me guess: that 1 person will of course not be you, right? Because if it is you, I bet you will complain even more.
Also, it's ridiculous to pretend that all questions require deep dive at length. Some do, and, yes, I agree we should do that for those. But what about the majority of the questions? If these questions still exist, then you will still be interrupted, so it will not solve the situation.
Also, it is quite telling that you did not also consider another solution: if they need to ask you a question, you could have avoided that by properly sharing the information before hand. But of course, it's always someone else's fault. (just to be clear: it is sometimes someone else's fault, but your way of reacting of just thinking that everyone else should adapt is just giving me the impression that you don't care about solving the problem in a fair way)
But it does not answer my question: what you ask them to do is very inconvenient and inefficient, as the large majority of questions do not correspond to big dangerous lack of knowledge that needs 3 hours lecture course to be solved. So we still have the problem: why should the company pay for one person being less efficient because of needing to do all this useless process, instead of paying for you being less efficient?
> I do put noise suppression headphones, but they can't stop the people moving in front of me ...
As I've said, I don't understand how people can be in "deep flow" and be so easily distracted by people moving around. People are different, so I can understand it can be a problem for you. But my problem with this reaction is that everything is centered around what is best for you, without any considerations of how it affects others. I reacted because you first mentioned that GP was behaving like a toddler, but in your reaction and the description of the problem, you seems to focus on you, you, you, which does not look very grown-up either, don't you think?
> ... nor the taps on my shoulder
If they tap on your shoulder, you should simply answer, like a grown-up does.
> Not wanting to be interrupted is not forcing others to take care of your needs.If you are unsure what I mean, let me call you in the middle of the night ...
But you are not complaining about being interrupted in the middle of the night to talk about things that is not related to you, you are complaining about doing your job: working with colleagues and sharing information so that they can progress.
What I'm saying is simple:
1) you can be a toddler and interrupt someone constantly for no good reason. This is not good and unprofessional
2) you can be a toddler and cry when someone interrupt you for a good reason. This is not good and unprofessional
3) the good situation is in the middle: you WILL have some level of interruption, it is just unreasonable to expect otherwise and it is childish to ask people to jump through hoops to care to your need to never be interrupted.
> How dare you forcing me to have normal boundaries and call you at reasonable times!
You don't have normal boundaries. Grown-ups at work know that they will interact with other people. You inventing that people should not interact with you, or interact only in your own terms even when it is inconvenient for them.
> Hence me liking the OP's behavior to that of a toddler.
OP's behavior did not even mention if they interrupt people that have inform them they don't want to be interrupted.
As far as we know, OP's behavior is 100% compatible with what you want.
> Let me guess: that 1 person will of course not be you, right? Because if it is you, I bet you will complain even more.
I don't mind it being me, as a matter of fact, it's often me, as I am in a more senior position and have a lot of historic context. However, a lot of time has been spent on documenting most things, so often I am just going over the docs with the new onboarder, which is okay, as long as it's done in a structural manner.
> You don't have normal boundaries. Grown-ups at work know that they will interact with other people. You inventing that people should not interact with you, or interact only in your own terms even when it is inconvenient for them.
I don't mind interacting at all, nor do I mind onboarding. I do mind, however, being interrupted all the time, on information, that could easily have been condensed in an onboarding package if the company gave people the space, time and initiative to create such a package.
What I am pointing out is that the OP experienced bad onboarding and thought the solution to that is being in-person in the office. I would argue what they simply had was a badly planned onboarding, with randomly shared responsibility across the team, and an ad-hoc learning plan. If the OP's company uses that lesson and makes a better onboarding process, that'd be great and they might even reconsider the need to be there in person.
> you are complaining about doing your job: working with colleagues and sharing information so that they can progress.
I would love share the information, but I want to do it in a structured manner, and not in chunks and without disruptions.
That's why schools and unis have classes, and classes have predictable and scheduled time frames. It's not just a building with teachers, and random children entering ad hoc and asking whatever question came to their head, then leaving, and coming back 5 min later.
And what's wrong with wanting lots of this information to be self-service? That's the whole idea of knowledge bases, of onboarding docs, of developer handbooks. What does it have to with people being in person or not? I'd argue if the OP's company spent the effort in actually putting all that knowledge in writing, they will have an easier and less disruptive onboarding to the team, with reduced bus factor, and clearly documented steps.
Everybody thinks their question is simple and quick, then it takes 30 minutes of time at minimum. I dunno why you are getting so much push back, must be a bunch of managers. Developers need to be left alone.
The push back is because it's extreme and one-sided. If you have some information that unblocks a team member, or another part of the business, say to make a sale, yes you should be interrupted. Your salary comes from somewhere, and your delivery is as a team, not an individual.
Because, you bring up sales, I am assuming that is your area of expertise. If a big sale can be unblocked by asking some specific employee an important question now, do it. If that happens five times a day, those sales are neither big nor are these very specific questions. Developers are most productive when in deep working mode. A simple question like "What time is it?" can be answered in 5 s, but it may cost a developer 30 min when in deep working mode. Because of the lost focus. On the other hand, many questions (not onboarding questions) could be answered by the colleagues themselves, if they would spend a bit more time on them. Thereby, they would learn more than just by getting the answer.
> Because, you bring up sales, I am assuming that is your area of expertise
I'm not in sales at all. Having an overview of the different bits of the business isn't a sales attribute. It's just an example of "what your job is" - which might range from weeks of uninterrupted detailed technical work at Microsoft Research, to presenting to clients, to running teams, to making technical decisions and getting agreement, to writing code.
Thinking every engineer's job is "writing code" and anyone who thinks wider is wrong is what the pushback in this thread is all about.
> We all have access to the exact same information.
We might have the same access, but rather than dig through 20 medical textbooks, I'll go ask a doctor. Access is a really poor way of thinking about things.
> But 90% of the time someone taps on my shoulder, they want me to think for them. You can do that by yourself. Just send an email.
Why send an email when they're thinking for themselves?
Because an email allows me to field it when I am not working on high-focus tasks.
It also
1) forces (or at least encourages) laying the whole thing out in a coherent order
2) leaves a record of both the question and the answer, so that the asker can refer back to it if they forget
3) leaves a record so that if the asker is asking obvious questions, or repeatedly asking the same questions, or failing to formulate their questions in a sane and coherent manner, there is documentation to take to their supervisor, not only to prove it, but to show exactly the shape of the problem, and have a possibility of getting them the kind of help they need
You get an appointment. Here noone is against appointments, here people discuss the notion of going to ask a doctor in the middle of a surgery a "quick question".
> Why send an email when they're thinking for themselves?
Because, the act of writing down a question --- with the necessary details to state the question precisely --- is often enough to find the answer yourself. Unless it is simple matter of a missing fact. But that is rarely the case in my line of work.
I think assuming everyone's situation is the same as yours, or your imagined stereotype of what people must be like if they don't agree with you, constitutes a lot of the content that's being pushed back on.
Some businesses have huge depths of technical content to understand that can't all the memorised in a training session. Nothing difficult can. Even knowing who to talk to about an issue is going to be found out via a question.
If I am a doctor in this situation, then you can create a JIRA ticket and I will see it .. eventually. Do you have instant access to all of your doctors?
But why would you see it if we have access to the same information? That's the point you made that I'm disagreeing with. Are you now saying that yes, even though I and my doctor might have access to the same information, that doesn't mean I should never ask my doctor things?
If we have the same access, we are both developers? You can ask things, just.. asynchronously. If it takes a long time for me to respond, you probably could have found the information yourself in that time.
Need help? Send an email or make an appointment and he will respond with help.
How is it your assumption that the team member asking the question can’t possibly be delayed 30-45min for them to be available. Seriously? Are they in an active shooter situation and need to phone a friend or something. Lives on the line?
> I don't mind it being me, as a matter of fact, it's often me, as I am in a more senior position and have a lot of historic context. However, a lot of time has been spent on documenting most things, so often I am just going over the docs with the new onboarder, which is okay, as long as it's done in a structural manner.
So, according to you, no one would ever need to ask you a question. So, obviously, GP will never ask you a question (they will ask other people if they want to).
So why are you calling them "toddler"?
> I do mind, however, being interrupted all the time, on information, that could easily have been condensed in an onboarding package if the company gave people the space, time and initiative to create such a package.
This is not at all what OP was presenting. You realize that?
> What I am pointing out is that the OP experienced bad onboarding and thought the solution to that is being in-person in the office.
That is not true. Plenty of people are having a very good onboarding and still like to fine-tune their understanding of the situation, which is arguably a very good way to reach good software.
> would love share the information, but I want to do it in a structured manner, and not in chunks and without disruptions.
But that is exactly the point of my initial comment about workflow. When your colleague Johnny needs the quick and simple information X to allow him to finish his code (for example "I've read what ath3nd has written in the doc, but it is ambiguous because sometimes it is, obviously ath3nd is not a god who can read mind and think of all the interpretation of their comment, especially when ath3nd is also not expected to not introduce a bug in the code from time to time"), you are asking him to break his flow, write some kind of ticket, wait for it to be triaged and come to you and wait for you to answer.
Your initial point is that you need to not be interrupted when you are in your flow, and you are now arguing that we should use a very flow interrupting process for the other participants.
> That's why schools and unis have classes ...
Are you seriously pretending that GP that just said "asking quick questions and getting an instant answer" is in fact in favor of not having any structure at all?
In fact, guess what, in a lot of classes, students are allowed to ask questions during some part of the lecture, even during exercises. Yes, incredible, right: some students are concentrating on solving the exercises while others _talk_! They _talk_! In the same room! Instead of writing a written letter to the teacher and wait for the post return so they can proceed with the exercise they have a question about.
> And what's wrong with wanting lots of this information to be self-service?
No one here is arguing against that. Simply, you can have as much self-service you want, it will never make a quick and simple question not the most efficient way to go.
It is just incredible that some people are so self-centered that they cannot understand that asking simple and quick questions is just, SOMETIMES, a super pragmatical and efficient way of progressing.
You sound extremely self-centered yourself. Its fine if you thrive in a collaborative open office environment, and noise-cancelling headphones are all you need. But that's not true for everybody else.
Your argument that you need to maintain your flow by actively interrupting other people is incredibly selfish and frankly just ridiculous. Also, flow is overrated. If you are in flow-mode, you are probably not doing the hard parts of your job. Not having to context-switch is different from flow, but more important, I would say, but you are forcing that on your fellow developers. If they don't mind, that's fine! If they do, you should respect that.
I think you did not got my point. My point is not that it is self-centered to "break the flow" (or whatever you call the reason that makes asking a question disruptive).
My point is that we had a situation where at least one person is going to adapt. The person self-centered is the one saying "the good solution is to have the other person adapt".
I'm NOT saying that the good solution is to have the other person adapt, I'm saying "why are you saying that having the other person adapt is the best solution? That's self-centered".
You answer me by saying "you are asking me to adapt to you, so, you are self-centered".
But I don't ask that. I don't force anyone. I'm just saying "why are you upset that this guy is forcing you to adapt to him but think that you forcing him to adapt to you is not self-centered".
I see the situation as very very symmetrical:
Some people needs A to be efficient, some people needs non-A to be efficient.
One aspect of the problem is that some people say "I like A, so let me just do A, and I let you non-A". But in reality, they don't let them do non-A. If you are a team of 2, and that you like not receiving questions but that your coworker like to ask question, there is no situation where we satisfy both.
The only solution is to act like adult and accept that I will do less A than I would have liked, but my coworker will do less non-A that they would have liked.
But here, some are saying "no! I want to do all A and it's to my coworker to adapt fully".
I'd say two people like that shouldn't be on the same team, at least not on their own. If it is possible to find some sort of compromise, that's great, but it might not be. You are going to make each other extremely unhappy, and why would anyone want to put up with that?
A scheduled list of questions at a preset time is often pretty bad too. Scheduling a 30 min VC for 1 simple little question sucks and conversely sometimes you have no idea how big of a can of worms you're about to open or who even has an opinion on it.
Chat messages are best IMO but the team needs to make an effort to respond when they aren't in the zone.
> Sorry for the negative take here but how it's written it feels like you don't necessarily realize that some people do need deep work, and prioritize your quick satisfaction to other's focus.
I'm always confused by people who struggle so much with being able to quickly answer a question and get back to what they were doing.
Also, here you're prioritising your work over someone else's.
> I simply can't stand incessantly being asked questions, I view it as a type of interruption
Well, you are being interrupted. But you're being paid to be interrupted.
> I'm always confused by people who struggle so much with being able to quickly answer a question and get back to what they were doing.
> Also, here you're prioritising your work over someone else's.
That's what the whole article is about. The struggle is that holding a context in your mind is easily broken by small interruptions. It's not by choice. So the question is how do you reconcile people on both sides working together.
If you make me think about some technical problem other than the one I have halfway solved in my head, anything I didn’t write in code is gone and I need to reinvent it almost from scratch.
When management evaluates my performance, delivering my projects carries much more weight than helping yours (which they might not even be able to measure).
>When management evaluates my performance, delivering my projects carries much more weight than helping yours (which they might not even be able to measure).
1. Your project is generally the same as those you work with.
2. Management often care about how you work with others. If you have someone who is helping everyone else, they're a lot more important than the person who just focuses on their task. Not just on team work but overall their knowledge is generally better than others.
This is a pretty common anti-pattern with how technical ICs view their work. No matter how technical or silo’d you are, your work is always going to be inherently collaborative, and your ability to collaborate with others is a hard bottleneck on everybody else’s ability to extract any value at all from the work you do.
Managing or working with ICs with this perspective is also a lot like having a toddler around.
This shit about being connected is killing me, people goes to work as part of their social life and are ruining everyone else existence, if people doesn’t have connections therapist is where they should go not coworkers
To be fair, I was a bit overly harsh with the OP, and it's purely due to reactionary reasons, as I've been far too often on the receiving end of a barrage of questions from multiple sides, while trying to meet deadlines. And I don't blame the newcomers, they are simply finding their way in a bad situation, I blame the company.
The funny part here is that the companies expect you to help onboard new employees AND do your other work at the same time, while at the same refusing to give you the time to build on a proper onboarding, with documentation to read, what software to install, etc.
In my current company we assign a "buddy" to the new onboarders, we have a handbook + a (supported and tested) onboarding installation toolkit, and pretty good documentation. The buddy does the handholding via scheduled and ad-hoc sessions, the onboarding material does the rest. During the pandemic we got to test this approach out on people who haven't even visited the office, and we improved it iteratively on every new onboardee. It's surprising how just improving such a small thing makes onboarding so much more pleasant for everybody, and how this, when done well, works both for office AND remote new employees.
I agree that this is the case, though the causes are pathological to the system, not the individual. You have to spend all your time at work, so you depend on it for social stimulus.
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?
> asking quick questions and getting an instant answer. vs chat where I may not get an answer for hours.
Basically like having a toddler around. Sorry for the negative take here but how it's written it feels like you don't necessarily realize that some people do need deep work, and prioritize your quick satisfaction to other's focus. Or I might be projecting, but I simply can't stand incessantly being asked questions, I view it as a type of interruption.
> running ideas by others. This doesn't happen on chat for me, and VC is too scheduled.
Yes, because who needs order in their time when somebody just wants to ask the group from their opinion, without even bothering to write it down. Also, whoever is sick that day and missing from the office, that's on them, whatever discussion happened, no evidence of it, so sucks to be them I guess.
> I don't feel connected to me team at all working from home
I...am sorry.