If it’s a library or framework question, research on your own until quite stuck
If it’s a codebase question, ask immediately (in a relevant company public channel) and continue digging. If you get the answer first, answer your own question, improve docs.
That, or the act of forcing myself to organize my thoughts so I can explain it makes the solution clear.
Just explaining what the problem is out loud is very often all that is needed.
I've tried cutting out the middle man and just forcing myself to organize my thoughts but it's not nearly as effective without the social pressure.
turns out there was a HUGE amount of churn for a day after an order was created with changes, and this saved a huge amount of headaches.
The same sort of behavior is on display with the one-essential-person who has gotten themselves at the center of everything in an opposite kind of way.
As a curious counterpoint, try taking the opposite approach for a bit and only get involved when it is absolutely apparent that no one else can do the job/guide people through decisions. Have junior folks write down what they are about to do in a design, or what they've tried before to help build documentation, design, and debug muscle. You may find that people are more able to run the show than you give them credit for.
98% of the questions I get are not about the basics, they are very high-level problem solving questions coming from people that just need clarification or 2nd pair of eyes on something. I mean even I need that quite often and I am very grateful for the help.
That's not at all standard, at least not if you're talking about documentation that's actually available in a useful fashion.
> 98% of the questions I get are not about the basic
How do you know your advice is being followed/ is valuable? I don't think that statistic is relevant. I don't think people are misinterpreting what you said. Its either
1. a tautology: because when they need help, they'll ask.
2. It can be misinterpreted: Ask for help whenever something challenging happens.
I've definitely seen junior devs get used to hand holding from senior devs, and learn nothing
The end result is I had learned how to solve it on my own and a senior dev had checked it to make sure it was the right path.
Some people seeing this advice may be worried about people coming to them with too simple problems or without trying to work it out themselves first, or other similar issues. That happens, but not that much, from my experience. And when it does, it’s usually with new people. In such cases you will want to explain to them what they could be doing better with this process, and avoid discouraging them from seeking help altogether.
There is a lot of value in being humble and asking. You will probably grow faster if you ask too much than too little. People who keep asking the same things are the real annoyance.
Also seniors who resent helping juniors shouldn't be seniors. They shouldn't be there at all actually.
Baby sitting should not be part of any serious work. If you do that, better go into nursery and let the real engineers do the job. Failure (in your words a "pointless work") is a part of the process. I guess instant gratification generation cant fathom that.
So black and white here - there are worlds between 1 hour and infinity FFS.
Sorry but so much machismo, so little engineering culture here.
> Failure (in your words a "pointless work") is a part of the process.
No, failing when everyone knew for good reasons and experience you were going to fail is not part of the process. This is hubris. Anything you do which could have been avoided is a cost that shouldn't be there. It is the opposite of proper engineering.
> Baby sitting
Providing guidance is not baby sitting. If you can't properly deal with less experienced people including making them confident enough that they don't pester you, you have no business being a senior member of the team because that's what distinguish the job from just being a productive junior member.
You are making this up again. Who is "everybody" and how they know? To know, you must get involved, the people minds are not projected into mine while I walk around or eat soup. If I get constantly involved in junior level shit (like every claimed hour x N juniors == constantly) , why am I here and how will junior become something else, and how will I progress into better engineer (hint: not by repeating hello world patterns, but buy doing real world "macho" stuff as you say it) ? This even exists in animal world mate, first time rat mothers are too accommodating and their pups are easy pray for predators.
> Providing guidance is not baby sitting.
I am not against providing guidance, but what you talk about is not that.
Sorry, but if you behave that way, you are baby sitter and you are making community around you the kindergarten, which is detrimental to profession.
I also do not discourage a developer from trying something on their own if they feel inclined to do so. That, for me anyway, is most of the fun of programming: the problem solving.
I think that asking a developer to "try it for an hour before asking" is just wasting another hour.
There are many ways to solve a problem, I want to make sure my developers have the access to me that is necessary to develop the best solutions.
There is no wasted hour - you learn from the failures.
What did this world turned into ?
Imposing vocabulary (in my case) === honesty.
About expectations, you totally missed it - I expect dummies to react unfavorably and I couldn't care less as long as I can express honest thought.
I mean, N minutes ? It insults the entire planet its just isn't immediately obvious :) I make it obvious.
Nothing in the grandparent post precludes writing good docs and allowing/encouraging experimentation.
1. Please do, but
2. If I signal that I need time, respect that.
I am more than willing to help people with their problems, and I love answering questions, teaching, providing advice, discussing thorny problems...
...but I won't countenance an "interrupt": Come to my office, knock on my door, say my name, whatever, but if my hand shoots up with the "Just a moment" index in the air, respect that.
If I do that, it's because what I have in my head will take me far too long to regain once lost - and the interruption will blow it up.
I need to checkpoint. Maybe even solve. I need anywhere from a few seconds to an hour (and, yeah, I may forget you were there, foibly human and all that).
Pretty much everyone I've ever worked with has learned that I have all the time in the world for them, except when I don't, I will let them know when I don't, without being rude (well, perhaps debatable, it is the barest acknowledgement), and when I can I will give them all I can.
Unless you persisted. On a good day, when I am feeling open and relaxed, hopefully we can talk about how to manage things differently, figure out a way that works for us.
On a cross day, an impatient day, I will kill you with fire. Metaphorically. Being a foibly human. Who sometimes overvalues his time. We are both likely to regret this. Hopefully we will find occasion to laugh about it later.
(Over the decades, the "just a moment" finger comes up less often, at least in part because I've learned those thoughts I was holding were neither so valuable nor so fragile as I once thought. Often, it barely starts to rise and I've already shifted gears, caching things away for later. I had to teach myself that because I really do prefer taking the interrupt and helping to breathing flame.)
I also found that functional programming, types or type annotations, and writing very small functions glued together by longer functions helps to reduce cognitive load when solving problems. Then I can add comments to literally bracket the area I am searching for the problem or solution and slowly move them closer together as I rule out functions and stuff.
So... are you working on that? Calling yourself "foible" doesn't forgive you of your shortcomings.
1. It weeded out the people who wouldn't invest anything.
2. It let a good 25% of the engineers "rubber duck" their way out of a problem.
3. When the problem got past the first two filters, the problem was much better defined when we worked on it together.
Remote working has made this super easy as often the way of reaching out to people is with a Slack message or equivalent. So many times over the past year I’ve answered my own question as I type out a lengthy Slack message explaining a problem to someone.
Interrupt me after you've tried as many ways as you can to solve the issue, and present them to me so either I can determine the remaining set you haven't tried or we can brainstorm. It shows initiative and thoughtfulness and creates a starting point for our solutioning.
Depends on what you value more. If you are optimizing for personal productivity, sure this makes sense. But if you are optimizing for team wide productivity, it doesn't make sense for someone to spend 3 hours trying everything they can think of before asking if you could have given them the answer in 5 minutes.
Something like spending 30 minutes trying and then asking even though you could go on makes more sense team wide.
Ultimately, team productivity isn't about enabling people in the codependent sense. It's better to build them up than to merely support them.
There is a balance here. Hard and fast rules don't cut it in my experience.
I prefer new hires have a culture of problem solving, but not at the expense of being afraid to ask for help. That is more important than my uninterrupted time.
This usually means some people need to be incouraged to reach out sooner, and others need to be encouraged to try a few things on their own first.
The worst thing I could to is create a culture of fear around asking for help, and I'll err towards having more interruptions to make sure that isnt the case.
Some people have a tendency to not so much converse as to pontificate. If you are seeking input from someone, you have to give them the chance to give that input.
If you have an issue with a point someone made within their first two sentences, the rest of the speech doesn't matter, so it's almost rude to wait until they finish to tell them their original assumption was wrong. Or they go off on such a tangent that you both forget the original purpose of the conversation.
Hypothetically, if someone is complaining that their back is sore from all the glass bottles they carry around to hammer nails with, waiting for them to get into the fine minutiae about the embroidery on their glass bottle bag is just wasted time. You need to ask the immediate question, "Why are you using glass bottles to hammer nails?"
...sorry, should have let you finish. You were saying the same thing.
Those who expect an interruption once understanding has been reached, and those who expect complete statements before interruption.
The failure modes from when these two different approaches mix is either "awkward" or "rude".
Generally, if someone is rambling, interrupt them. (With exceptions like if someone is emotionally venting, let them release it).
This is the amount of time the person needing help should try to solve it themselves. After that they should write down what they've done (they should be doing this anyway in an engineering notebook or worklog file), and then ask for help.
The delay is to make sure an attempt is made to solve it themselves. It's long enough to get them to try to understand the problem, and short enough to not put them far behind.
I've also found that if they need to get help often then it's not their problem, but the problem of who is tasking them. Their tasking, or the context of that tasking, is probably not being communicated well, or might not be defined well-enough.
It might seem silly but if you're able to make slow incremental progress you'll eventually figure it out and it helps grow your intuition of what to do to fix/unstuck yourself. I don't know of any other way to develop that intuition other than going through it yourself (if you have any tips I'd love to hear your thoughts!). Yes, it might be slow at first but the compounding effect on your growth cannot be overstated. It's also not a hard rule, if you're on some sort of time crunch and need help you should obviously feel free to ask for it.
1. I’m thinking harder about this thing but not blocked.
2. I’m still not blocked, but could really use a pair right now.
3. Actually stuck.
They basically act like andon cords for my quality of understanding of a task.
If anytime someone needs to invest a day to learn how to research a solution, try something out, gain experience, I simply give them the exact and specific answer in two minutes, then I deprive them of experience. I substitute my experience for their opportunity to grow.
I can appreciate that it's nice to want to help people out by giving them the answer, and my advice does not mean that you leave people to hang or feed them to the wolves and suffer... it's that as an organization, in the long run time is better spent giving people a system they can use to learn and grow and that system will necessarily require developers to invest a lot of time learning seemingly trivial things and learning from mistakes for themselves.
And, I am 100% sure that providing education is better than letting them struggle. If you don't want to tell them the answer (and I haven't fully understood why not), then pointing them in the right direction to discover the answer is certainly going to be more helpful.
If you had spent those same hours after two minutes of support, you might have learned even more.
Example: I am a Unix user and I want to delete a directory. But I don't know how to do that. So I say "ls /bin" and think that maybe the "d" in "dd" has something to do with delete directory (and "df" is delete file?), and so I do "man dd". So I get some idea what "dd" can do. (Deleting directories is not one of them, though, it seems) I also find "unlink" which seems promising, but that one can't delete directories, only files.
If I had asked you, and you would have told me "rmdir", then I would never have learned about "dd" and "unlink".
It's just an example; I wasn't sure I could come up with something more realistic from actual development.
What I try to teach developers is how to learn things without getting frustrated. Usually people get frustrated because they don't have to right process in place for learning things, they try bolting solutions onto existing code and try fitting a square peg into a round hole. They get massive compiler errors or stack traces that are hard to isolate from the specific problem they're having and it feels like in order to solve one problem they need to solve a dozen other tangentially related problems.
That's overwhelming and frustrating, but it need not be that way.
I teach people how when they come across a challenge, how to learn to come to a solution from first principles; how to create a minimal project isolated from the rest of what they're working on and experiment. I try to emphasize the importance of having various different mental models of how a computer works and how to apply those models to have a better understanding of what's happening beneath the hood.
> I haven't fully understood why not
Because working in my industry isn't a matter of knowing answers to questions. It's about the process of knowledge discovery and that process comes with experience and practice. I really don't need anyone to be a glorified typist... if you need to take an entire day to really understand how to solve a problem, even if it's a trivial problem I could solve in a minute, then take the day. That's an investment I'm willing to make now while you're a junior and I am in a position to fully understand the problem you're facing, compared to 10 years from now when I won't be able to fully understand the problem and then we're really screwed.
And it's not like you're going to someone more senior and saying "I'm stuck; do my work for me". Ideally you're just getting a strong hint as to the right approach to take, and can make progress with that.
Like... asking for help and having a chat with a mentor who has relevant experience.
(Most) people don't do that easily and are likely to have already spent time and effort formulating the question.
Asking them to go away and spend more time on their own is interrupting an effective way of learning.
It is very high form some types of activities and brains, and even higher if the interruption is raised (!) after a long work session, as the interrupted has to 'swap out his context' (what he was thinking), tackle the question, then 'swap in his previous context' before resuming.
"The average lost time is 23 minutes per major interruption ((...)) For developers, it is far worse" https://www.brightdevelopers.com/the-cost-of-interruption-fo...
What should I do when someone asks for help?
Coach, don't fix.
If you help someone find the answer to a problem, and give them the support they need to learn, you'll find that you both resolved the underlying issue, and that you gave them tools they need to become better at what they do. You'll also set an example for them when someone comes to them for help.
So make an effort first so that when you go to your colleague you can tell them a few things that you have already tried. You may find an answer before you need to go to them. And if you don't find the answer the list of things that you have already tried can help set the context and help your colleague to help you better.
This is particularly important if the problem is easily google-able. If you keep going to your colleagues for help and they search a few keywords on google, go to the first result and show you the answer right there that's the sign that you are not making and effort to solve it yourself first.
Each org I have seen is a bit different. Some projects just seem to be more geared towards gurus (aka, the software is wonky, no way anyone could know about that without asking).