Post #1628672
2025-04-27 04:12 UTC
Replies (32)
-
@vwbusguy@mastodon.online 2025-04-27 04:28
@geekygirldawn Absolutely, yes.
-
@jackscottau@aus.social 2025-04-27 04:31
@geekygirldawn I read somewhere (and I wish I could remember where!) about the 15 minute rule, which I tell all my new hires: you must try and solve this issue on your own for 15 minutes. After 15 minutes, you must ask for help.
-
@mherbert@social.chinwag.org 2025-04-27 04:36
@geekygirldawn yes, but the answer should also cite references that they can use to search for examples before asking next time - this could be standards documentation on the web or internal-only documentation that describes the system at hand
-
@abstractcode@eigenmagic.net 2025-04-27 04:46
@geekygirldawn I tell more junior colleagues when they're on support rotation that it's a triage role and they can ask for help. Make a reasonable effort, but you don't need to run yourself ragged. If support cases spike call for help. If everything is on fire call for help. Go for lunch, look after yourself*. I've also been telling team members they can ask me stuff and that helping them is part of my job (you call me a Staff Developer, I'm going to assume I help develop staff). This is something I have identified I need to do more proactively in my new(ish) team. My view is more senior developers have a proactive responsibility to help more junior developers, without discounting their skills and opinions or removing all their autonomy. *this is very "Do as I say not as I do" to be honest
-
@TonyYarusso@infosec.exchange 2025-04-27 05:31
@geekygirldawn OMG, yes. I’m still shocked at how often I find out that some coworker is completely frustrated and upset because they’ve been fighting with some problem in total silence for several days if not weeks. Like, dude, I might not have the answer either, but at least ASK the team and/or the vendors we pay several times your salary to check if anyone’s seen the problem before.
-
@TonyYarusso@infosec.exchange 2025-04-28 03:41
@simon_lucy @geekygirldawn In this case it’s actually a problem of PAST exposures to toxic cultures. Our current team and even most of the whole division tend to be pretty good, but we were formed by gradually consolidating in staff from many different agencies (this is state government sector) along with external hires, and some people are traumatized by the places they came from and it’s taking years to break them out of old mindsets. We do have a quite active MS Teams chat of all of us all the time, with the range of “hey I have this problem”, “if anyone gets an alert for this, I’m the one breaking things”, and “enjoy these silly memes”, a weekly team meeting that alternates between more managerial and more technical (either troubleshooting or knowledge-sharing - started for the purpose of “don’t let one person be the only one who knows anything”), and more scattered specific stuff. Some people are just more comfortable mentioning something in the chat early than others, because of history. Same goes for the entire category of “dude, just tell the customer no - if you aren’t comfortable doing that, have me tell them no and be the bad guy instead”…
-
@zaunkoenig@mastodon.online 2025-04-27 06:55
@geekygirldawn I had a team leader thinking it would be best if the IT guys are sitting in different rooms together with team members doing something else so that they learn other things, too. Even after everyone telling her it was a stupid idea and you cannot learn like this she sticked too it.
-
@rebeccafinn@topspicy.social 2025-04-27 08:18
@geekygirldawn this only works if your seniors aren't of the thought that "you should already know this"
-
@ujay68@mastodon.world 2025-04-27 08:27
@geekygirldawn I think the balance is important. It’s certainly not a good productive experience for the person, the team, the employer if a new team member spends lots of time and frustration searching for readily available answers. However, especially in tech jobs, I also think it’s vital to develop some kind of scientific curiosity, some urge to explore, some tolerance for and endurance of tech issues not readily solved, and also to question (in limits) existing architecture and technology.
-
@raymo@toot.wales 2025-04-27 08:57
@geekygirldawn some really good responses here and definitely agree with the 15 minute rule. On top of that, when I get asked for help I tend to create a gap and then come back to the person, so they don't lean on my availability as a crutch. Sometimes quite happily they've already solved the problem by the time I come back to them!
-
@Legion495@mk.absturztau.be 2025-04-27 09:06
@geekygirldawn@hachyderm.io Luckily is one of the few things I am quite okay with. Also we got good documentation.
-
@confusedMiddleAgedDad@mastodon.social 2025-04-27 09:29
@geekygirldawn chemical engineer/process safety person here. I thoroughly agree. Yes, for new hires in first job but also to a certain extent yes if you have some experience but are new to the organisation as managers and technical leaders we also understand company systems and controls. Please ask questions when you are stuck or unsure. If your managers or mentors do not help then we are not managing or mentoring well. You don't know everything from education and we don't expect you to do so.
-
@Thebratdragon@mastodon.scot 2025-04-27 11:03
@geekygirldawn first day of a new hire, drill into them, 'there are no stupid questions'. Same thing drill into old hires, not least as we all blank sometimes.
-
@MadSc13ntist@mastodon.ie 2025-04-27 11:19
@geekygirldawn this. This. This. It is 1,000,000 times more frustrating to hear "I spent 4 full work days wrestling with this problem" when they could have just asked someone for guidance. I'd add one piece here that strikes me alot these days: Google is hot garbage, ask a human. Search engines were a crutch even in the early 00's before "SEO optimization". "Google can bring you back 100,000 answers. A librarian can bring you back the right one." --Neil Gaiman
-
@dawngreeter@dice.camp 2025-04-27 11:19
@geekygirldawn As a manager I have worked (and in fact currently work) with a bunch of college hire engineers, and this is the very first thing I tell them. Getting unstuck and effectively taking feedback are two of the most important skills when you start in the tech industry.
-
@kay@meow.social 2025-04-27 11:25
@geekygirldawn I always teach new people: if it's not like, a P1, have a look online, spend 20 mins reading and trying yourself, if you are still stuck then come ask someone. If it's really urgent then just ask.
-
@dimsumthinking@mastodon.social 2025-04-27 12:04
@geekygirldawn @nicklockwood I show what I’ve tried and ask for a comment or a push
-
@JustinDerrick@mstdn.ca 2025-04-27 12:04
@geekygirldawn Thankfully, my experience was different. When I switched to the IT department, I was assigned a mentor -- the guy who did the tech interview with me. He did two things for me... 1) Ordered ALL the manuals for me. When I say 'all', I mean that one morning my cube was filled with over 200lb of boxes. OS / DB / Storage Management / App. 2) When I started, he introduced me to a half-dozen people that were to be my primary contacts for specific issues (OS/DB/SM/Change Mgmt/etc)
-
@adredish@neuromatch.social 2025-04-27 12:18
@geekygirldawn @dahukanna This is also a huge problem with students and trainees in labs. I've been a professor for 25 years. I have *never* had a trainee in my lab bother me too much, but man oh man, I have had lots of trainees not bother me enough. As I've pushed on this, I've found that it's not that they think they are "cheating", it's the (incorrect) belief that these other people are "busy" and they don''t want to bother them with questions. PS. In my experience, students don't have a problem separating classwork (where you are being tested on what you know) from jobwork (where a task needs to get done), but I do agree that they carry lessons over. One of those lessons is "not bothering the teacher". I try very hard to get students to come to "student hours" (what I call "office hours"). I had one student in my class finally show up to ask for help who said they came to "student hours" because I was the first one who seemed to "actually want someone to bother them to ask for help".
-
@mahryekuh@hachyderm.io 2025-04-27 12:21
@geekygirldawn Agreed, with a note: It is up to a company to nurture an environment that fosters new people to ask questions. Someone must feel psychologically safe asking questions and expecting support without others judging them. This also applies to admitting when one makes a mistake. One way to achieve this as a senior developer is to emulate this desired behavior in a group chat as much as possible. So, as a senior, I will ask questions and admit when I don't know something. If a junior sees a senior do that, they feel less threatened when it's their turn to ask for support.
-
@aliceinwaterdeep@sunny.garden 2025-04-27 12:21
@geekygirldawn I absolutely agree, however that highly depends on your work environment and colleagues. My first coding role whenever I got stuck and asked a question I was met with annoyance if not straight up rudeness that made me feel like I was dumb. I learnt not to ask anymore :') Thankfully my following jobs were very different and I started feeling safe to ask again.
-
@redhoodoutlaw@universeodon.com 2025-04-27 12:34
@geekygirldawn Agreed
-
@ZetaZetan@infosec.exchange 2025-04-27 12:41
@geekygirldawn Also that "look at how it's done elsewhere in the codebase" is the most basic way to learn. (And even flat-out "copy-paste something to use as a template" is often good - there are reasons to be cautious about copy-paste code, ofc, and depending on the required tweaks if you're doing it too much it might be a sign things need refactoring, but it's still an important tool in your toolkit. Asking what the best thing to use as a template for XYZ is also good because codebases are often in different states of disrepair.)
-
@meta@mastodon.au 2025-04-27 13:10
@geekygirldawn All of this just makes me very grateful that the first junior I’ve had to mentor in my career is someone that isn’t afraid to ask for help and will listen to me infodump on the hows and whys after I’ve fixed his problem (and looked like a wizard in the process). Something I’ll definitely keep in mind once I move on from my role because I know I’ve got a unicorn.
-
@hendric@astronomy.city 2025-04-27 13:20
@geekygirldawn My son is at Texas A & M on a comp eng degree, and my god do they teach them this anti-pattern *hard*.
-
@Dave42W@amastodon.uk 2025-04-27 14:04
@geekygirldawn I wish that had always been part of the culture everywhere I've worked. Too often knowledge it felt like knowledge wais held onto for power games. Or failing is seen as some kind of right of passage. I wonder why so little attention is given to these kinds of cultural issues, it's not as if it's difficult to see what a huge difference the culture makes.
-
@csepp@merveilles.town 2025-04-27 14:12
@geekygirldawn Still trying to learn this.
-
@hfinyow@mstdn.ca 2025-04-27 17:38
@geekygirldawn whenever I'm asked to interview a potential developer, I always look to figure out if they will let me know when they are in over their heads. Too often, junior resources keep going even though they are clearly out of their depth
-
@krisfreedain@fosstodon.org 2025-04-27 20:17
@geekygirldawn agree. And a lot of the time, that veteran will help explain how to get to the answer.
-
@jose@mastodon.gamedev.place 2025-04-27 20:40
@geekygirldawn never really connected the dots with academic cheating and the resistance to asking for help. Makes much sense, thanks
-
@dpnash@c.im 2025-04-28 00:23
@geekygirldawn This is something I had to unlearn… when leaving academia and going into private-sector jobs. The first job I had after getting my Ph. D in chemistry made it quite clear that, after a fairly short ramp-up period, you had to know *everything* about your projects. *Everything*. Asking questions to other people was, after a few months, a sign that you did not know what you needed to know. Losing collaborators? You need to pick up everything they knew, quickly. Of course, not all academic research positions are like this, but….sheesh. Transitioning to a software development career later was almost ridiculously easy by comparison.
-
@h3mmy@tech.lgbt 2025-04-28 11:42
@geekygirldawn I like to make it very clear to newer devs I interact with that they are expected to ask for help. And it's a balance of giving them the answer and guiding them through the process of figuring out the answer. Sometimes a problem breaks down to them not knowing something and being too embarrassed to ask directly. Like "Oh, so that's how you check the logs in that environment" or "I don't know how to use a java debugger" and I try to be reassuring that it doesn't matter that they don't know those things. It matters much more that you communicate and ask for some help figuring it out instead of languishing.