DEV Community: Sophie Kaelin

Queen Bee Syndrome & Me: Navigating internalised misogyny

Sophie Kaelin — Sat, 22 Mar 2025 05:49:14 +0000

A Bit of History

In 2017 I began studying Computer Science at my local university. I was only a few weeks into my studies when I realised that there was a severe gender imbalance in the industry, and that my path throughout a career in STEM would differ greatly to my male counterparts. Little things chipped away at my confidence, like being told I was in the wrong lecture hall, or that I should only work on the documentation element in a group coding project. All these (likely un-conscious) microaggressions made me question whether or not I belonged in the field. When the actions and biases of enough people communicate that you don’t belong somewhere, you begin to believe it too. Despite the casual relationship I developed with imposter syndrome, I remained proud to be a representative of young women in tech, and relished in any opportunity I had to “prove myself”.

As much as it initially unsettled me, I became accustomed to being one of two or three female students in a classroom. I felt special, and, at times, enjoyed standing out. My naturally competitive spirit motivated me to outperform my peers at university, and I relished in the times I achieved stronger grades than the few misogynistic classmates that made me feel unsafe and unwelcome.

“Queen Bee” Guilt

One morning, in my penultimate year of study, my friends and I were searching for a free computer lab when we walked into a class where ~50% of the students were women. My friends and I stood astonished, with one male colleague remarking “wow, it’s so awesome to see so many females taking up IT degrees this semester”.

It really was great to see, especially after several years of feeling disheartened by classrooms void of any feminine energy. Seeing a room packed with enthusiastic future female engineers should have delighted me. But instead, I felt tense, unnerved and intimidated - closely followed by deep shame for the instinctual reaction.

For months I kept this close to my chest, to avoid exposing myself as the toxic woman I surely was. Wasn’t this exactly what I had been advocating for? All these years of campaigning to have more women involved in STEM and the moment I see these goals physically manifested, I have a selfish desire to prove myself as the smartest in the room. I’d grown accustomed to being the only woman applying for a scholarship, or attending a class. So deep down I felt threatened and scared that I was no longer special.

When I confided in my friend, Grace, about this, she explained to me that what I might be feeling is a bit of “Queen Bee Syndrome”. I felt embarrassment but also relief that this reaction didn’t make me a bad person or bad feminist, but was rather a common compulsion felt by women in male dominated industries. After debriefing with Grace, I decided to look more into what Queen Bee Syndrome was.

What is Queen B Syndrome?

Queen Bee syndrome gets its name after, not surprisingly, bees. There can only be one Queen in a hive, and if there are ever more than one they will fight to the death. A Queen bee will go as far as stinging unborn Queens to eliminate any potential rivals. Thankfully the term “Queen Bee Syndrome” involves far less violence (phew). It rather refers to someone who acts hostile towards other women in their workplace because of a subconscious fear that they may surpass or outperform them in their role. This type of behaviour occasionally appears in the STEM industry, where there are hardly any women (~28% in 2020 according to Australian STEM Equity Monitor), so the likelihood of the few in a company feeling pitted against each other is higher.

This is something that also happens between female celebrities - think Olivia Rodrigo & Sabrina Carpenter, Kim Cattrall & Sarah Jessica Parker. Rumours of a rift seem to appear before there is any genuine animosity between these stars. Our society loves to pit women against each other, whether for clickbait or for the sake of gossip and drama.

According to a Forbes article by Kim Elsesser, it can be a way that some women cope with the gender discrimination they’ve faced in their own career. After working so hard and facing so many barriers to get where they are, women in senior positions could interpret a first year student's enthusiasm and eagerness to learn as someone who has had it easier than them - who hasn’t had to fight for what they had to. Perhaps even jealous that they won’t have to go through the same level of bias and discrimination they did.

That just sounds like being competitive. What’s wrong with that?

Healthy competition between two friends isn’t a bad thing. However, an unsolicited competition where two students are pitted against each other solely based on their common gender, is toxic. Feeling motivated to outperform your peers is fine, as long as you aren’t engaging in behaviours that put other people down or inhibit their performance.

It is important not to feel guilty if these subconscious feelings resonate with you. We work in freezing offices with beer taps in kitchens and lunchtime conversations on hardware engineering and League of Legends. This industry was designed to suit men, and this Queen Bee phenomenon is a consequence of the discrimination and gender imbalance, not something created by women. The only way to change that is to continue striving for greater gender equity.

I think I might be a Queen Bee or I know someone who is. What can I do about it?

Again, I want to make it clear that I am not interested in blaming specific people for this phenomena, especially not women.

Women experience enough barriers as it is - things that we have limited control over. And as much as the onus of this issue is not on women, there are some things we can do to reclaim control. By acknowledging and reflecting on any Queen Bee feelings we’ve had, and safely sharing them with other people, we can raise awareness and encourage others to hold a mirror to their own thoughts, feelings and past behaviours. That way, we can reflect and stop these feelings in their tracks before we act on them in the future.

Questions I like to ask myself in those moments are:

What is the goal of this interaction? What do I want to achieve?
Are my words and actions helpful or a hindrance?
If the roles were reversed, how would I want this interaction to go?
Am I acting in kindness?

One thing I discovered early in my studies is that the community of women in STEM is welcoming and strong. I have felt incredibly supported by various mentors and leaders from the beginning. We need to continue looking out for each other and offering assistance and knowledge where we can.

When we feel threatened it is important to acknowledge that feeling, recognise its source and move past it to ensure we aren’t hurting people or modeling Queen Bee behaviour for others. These feelings don’t make us bad people, or bad feminists. It is the consequences of the environment we are in - an environment that will only change if we are vulnerable, honest and refuse to be divided.

Sources

https://www.forbes.com/sites/kimelsesser/2020/08/31/queen-bees-still-exist-but-its-not-the-women-we-need-to-fix/?sh=232d32216ffd

12 Healthy Mindsets to Embrace When Starting your First Job

Sophie Kaelin — Wed, 12 Jan 2022 06:45:46 +0000

Starting your first full time role can be super daunting, and it's not uncommon for graduates to be riddled with imposter syndrome. I started my first full time graduate role in February 2021 as a penetration tester - something I knew very little about (aside from one subject I did at university). Throughout 2021 I received a lot of advice on coping with a full time workload, and how to get the most out of the experience. I also discovered which of my habits, behaviours and mindsets inhibited my progress, and which nurtured it. With all that in mind, I have collated a list of 12 healthy and helpful mindsets that I adopted throughout my first year of work, which made my experience a whole lot more fulfilling and less intimidating.

1. No one expects you to know everything

And if they do, they are being unrealistic. This is a GRADUATE role, not a senior role. Don't compare yourself to mid-levels, juniors or seniors - this is unhealthy and unrealistic.

2. Asking for help doesn't make you look unintelligent

In fact, asking the right type of questions shows that you're engaged with the task and are making progress. It's better to spend 1 minute asking the "silly" question, rather than spending 30 minutes trying to work it out on your own and getting no where. Most people won't hesitate to take the time to explain concepts to you. You aren't being a burden.

There are a few caveats to this:

Don't ask questions just to fill the space or so you can "tick a box" that you've spoken in a meeting. That is a waste of everyones time and doesn't achieve what you think. And
Don't ask questions without doing at least some research first. Make sure you have some understanding of the problem you're facing and search if there are any resources online to help. Only then should you approach a co-worker with your understanding of what's going on, what you've tried so far, and what you've found confusing.

3. Be honest about your abilities

This was one of the best pieces of advice I've received. As much as you want to impress your new team and perform really well, if you aren't able to meet the fanciful expectations that you set for yourself, you will fall short and rarely succeed. It's so important to be transparent so that people can hold you to a realistic standard and understand how they can best help and support you.

4. Say Yes (in moderation)!

When people ask me how I got to where I am today, I tell them "I just participated in everything". Open yourself up to new experiences and engage with your team. I had the opportunity to interview people, be interviewed by magazines and speak at events because I said "yes". The more you say yes to, the broader your network becomes and people will come to you with even more opportunities in the future.

Another caveat here (and I'm about to seriously contradict myself). Don't say yes to e-verything. As much as I'm glad I've been a "yes girl" throughout my life and am grateful for all the opportunities it has afforded me, it has ended up in burn out. It's important to prioritise, and say yes to the things that will fill your cup, and only if you have the capacity to do your best work. Everyone has their limit of what they can do or can handle. Yours wont be the same as everyone else - particularly not as a graduate.

5. Be transparent about your work load

One phrase I like to use a lot when being delegated a "high priority task" is "Okay, so I have TASK A and TASK B which I also need to complete today, alongside TASK C you've just given me. Which should I do first? Which is more important". That way, people are aware of your workload and can have realistic expectations of when a task will be complete, or if giving you TASK C will actually overwork you. It also puts the onus on them if you are pulled in a million directions to complete various tasks.

6. Work can just be work

When you see a lot of super passionate people in the industry, it can make you feel like you've failed or that you're in the wrong job if your level of interest doesn't match others. But your job can just be a job. It doesn't have to be your one and only passion or a defining quality of who you are. Of course, it's important to have some level of interest in your field, particularly tech where a lot of research is required to stay caught up with the current landscape. But you aren't any worse of an employee if you spend your weekends off your computer in comparison to the employee that works all weekend on personal tech projects.

7. You also don't have to be the best at what you love

As mentioned before, you do need to be somewhat competent, but you don't have to be a genius, or programming prodigy who created their own compiler at age ten. It takes all types of minds to create an excellent and accessible product. This goes for any hobby or activity you enjoy - you can love to bake and everything you make be borderline inedible. Passion is indispensable and more critical than competency - because passion is what drives you to be better and enables you to grow.

8. You don't have to put up with bad behaviour just because you're new

Whether that's seniors being condescending, blatant disrespect, or a comment that made you feel uncomfortable - call it out! This can be pretty daunting, especially as one of the newer people in your team. I've had to do this a small number of times, and each time I was met with gratitude and respect. Most people want to do the right thing, and be an inclusive team member, and will take on any feedback positively - particularly when they didn't realise their behaviour was making you feel uncomfortable. Either send them a carefully worded email, or speak in confidence with a manager or buddy about what they think you should do.

9. Every person in your team has once been in your position

Everyone knew nothing at one point. They all had to learn, just as you will.

10. Slow down - there is no rush

You can stay in the same level role for six months or ten years - it doesn't matter. Go at the pace that best serves you. Enjoy where you're at now, because there are a lot of perks of being a junior (cough upward delegation cough).

11. Everyone is on a different journey / timeline

I started my graduate role with two other graduates, who both already knew a LOT more than I did. I reinforced in myself very early that there is no use comparing my knowledge and progress with theirs because we were coming from different foundations. You may start at the same place and level as someone else, and maybe they will progress faster than you did. That's okay! Everyone learns at different speeds and in different ways. However long it takes, is however long it takes, and it doesn't make you the wrong person for the job.

12. Everyone feels like an imposter

You aren't the only person sitting at their desk thinking, "oh my gosh, I know nothing. I don't know how I got this job". Nobody can know absolutely everything about their job - that's what makes tech jobs so exciting!

Best of luck to you in your new graduate roles. Let me know of any helpful and healthy mindsets you've adopted.

Hack the Box - Explore Walkthrough

Sophie Kaelin — Thu, 16 Sep 2021 03:13:35 +0000

Hack The Box - Explore

This is the second box I've system-owned on HTB. Explore was a fun machine to play with which taught me a lot about the importance of perseverance. I completed this box alongside a few other work colleagues.

Details

OS: Android
Difficulty: 3.6/10
Release: 17/08/2021
IP: 10.10.10.247
Box Author: bertolis

Knowledge/Skill Requirements

SSH Port Forwarding
Android OS + associated tools (ADB, ES File Explorer)
I used my Kali Linux VM to complete this.

Enumeration

As always, I started off by looking at which services were running by executing an nmap scan.

Seeing that the four ports running were (2222, 5555, 41567, 59777) I decided to do some research on common uses of those ports on android operating systems. Information I found included:

2222: SimpleSSH
5555: Android Debug Bridge (ADB)
59777: ES File Explorer

I never worked out what 41567 was doing.

Analysis

The two services I wanted to look at in more detail were ADB and ES File Explorer. I'd never played with Android devices before, so I looked a little more into what each of the services did. I also searched if there were any known vulnerabilities/CVE's associated with them. And ... ✨VOILA✨

ES File explorer had a CVE associated with it (CVE-2019-6447). The exploit allows remote users to read arbitrary files from anywhere on the network over port 59777.

Digging around more, I found an exploit script on exploit-db. I played around with the script and saw it can list and retrieve files from the system. Eventually I found a file called creds.jpg which looked promising.

I could retrieve the file by running:

python3 exploit-script.py getFile 10.10.10.247 /storage/emulated/0/DCIM/creds.jpg

The file contained what looked like a username and password (GASP!).

kristi:Kr1sT!5h@Rp3xPl0r3!

As a HTB noob, I thought I'd found the user flag here.

But when entering the password didn't work I looked at how else I could use these credentials.

Privilege Escalation

Remembering that an SSH port was open on 2222, I tried using these creds to SSH onto the machine. And after many failed attempts at guessing whether the password contains O's or 0's, and l's, 1's or I's, I could access the device!

Once I'd fought with find and grep (both of which I can never seem to get to work properly) I could see the flag inside sdcard/user.txt

Full Control

At this point I had access to the device through SSH, and I knew I had an ADB service running on port 5555. In order to run ADB on the device, I had to set up SSH port forwarding so that I could run ADB commands on the device.

ssh kristi@10.10.10.247 -p 2222 -L 5555:localhost:5555

Once port forwarding was set up, I was able to run ADB commands on the device, gain a shell, escalate that shell to root and search for the root.txt file.

adb connect 127.0.0.1:5555

And that's all ! Thanks for reading.

What is the difference between CORS and CSP?

Sophie Kaelin — Mon, 06 Sep 2021 11:14:07 +0000

I often get both of these concepts confused, and apparently so do a lot of other people. It's a pretty important concept to be understood by web developers and security engineers, so hopefully this clears things up.

First, an introduction

Cross Origin Resource Sharing (CORS) and Content Security Policy (CSP) are used by web applications to control what data can be loaded on a page, and what data other pages can load from it (see, it's already gotten confusing). It is vital to have CORS and CSP configured correctly from a security perspective, because it would otherwise be difficult to trust the integrity of a web page (if any scripts can be loaded) but also the confidentiality of your own data on a web page if it can be loaded by anyone.

When learning about CORS and CSP, it's important to understand what's going on from both perspectives (requestor and requestee), because as a host you will be playing both positions. To drive this message home, I'll be referring to YOUR website which is ✨Super Secure Sally✨, and MY website which is 🤡Really Risky Ricky🤡.

Firstly, what is CORS?

To quote MDN Web Docs

"Cross-Origin Resource Sharing (CORS) is a HTTP-header based mechanism that allows a server to indicate any origins other than its own from which a browser should permit loading of resources."

You can view what CORS policies are set on a particular host/page by viewing the response headers. The main header we are concerned with is:

Access-Control-Allow-Origin

This response header dictates which domains are allowed to receive the requested data.

Before making a request from another origin, it's common to make a preflight OPTIONS request to determine whether the request will be successful. In that case, the requestor will provide the request headers:

Origin

Access-Control-Request-Method

Access-Control-Request-Headers

This requestee will then send a response as to which origins, methods and headers are allowed when requesting the resource:

Access-Control-Allow-Methods

Access-Control-Allow-Headers

Let's explore this using examples.

Sally wants to load a resource from Ricky

Sally (you) wish to load a resource on Ricky's domain. Luckily, Ricky has very relaxed CORS settings and will allow anyone to request resources.

Ricky's Access-Control-Allow-Origin header contains a wildcard value * which means anyone can load this resource from his website. This is a super dangerous setting to have, especially if the data is sensitive and confidential.

Ricky wants to load a resource from Sally

Ricky wants to now load a resource from Sally. Sally's data is extremely confidential and the most secure CORS settings have been configured to ensure only she can make requests for that data.

Something in between

Say if Sally changed her mind and she wanted Ricky to be able to successfully request data from Sally. In that case Sally's response header should say:

Access-Control-Allow-Origin: http://ricky.com

In Summary

When it comes to CORS, you want to be conscious of what resources you can load, and what resources other people can load from you.

Next, lets chat about CSP

The goal of CSP is to protect against Cross-Site Scripting (XSS) attacks by dictating which scripts should be trusted and which shouldn't. When a browser tries to run a script from an unknown source, CSP will block it unless it is on the list of trusted sources. If no CSP is provided, then a site will default to using the "Same-Origin Policy" (SOP).

The Content-Security-Policy response header contains rules for that request. The CSP can restrict things like:

default-src: the fallback for all resources being loaded if no other rule is set.
script-src: restricts which inline scripts can be run.
style-src: restricts inline styles from being applied.
media-src: restricts audio and media files from being loaded.
img-src: restricts which images can be loaded.

There are plenty of other options to use. You can see them on this Mozilla Developer Page.

At this point, I'm going to introduce a new site 😈 Evil Eddie 😈.

For each of our scenarios, Eddie is going to intercept a request/response to Sally and Ricky's website and try and inject an evil script off his website onto Sally/Ricky's webpages so that it executes the malicious script.

Evil Eddie attacks Super Secure Sally

Sally's CSP header looks like this:

Content-Security-Policy: default-src 'self' charlies-cookies.com.

When Eddie tries to attack Sally's website, his script is not loaded because it is blocked by Sally's CSP which says only scripts from her website and her friend Charlie's website will be loaded.

Evil Eddie attacks Really Risky Ricky

Ricky's CSP header looks like this:

Content-Security-Policy: default-src 'self'; script-src *; img-src *.ricky.com

Eddies attack is successful on Ricky's page, because Ricky has used the wildcard * character which allows scripts to be loaded from all origins.

In Summary

Be careful with listing which sites your website can load resources from and only update your allow-list if it's really REALLY necessary. It's also super important to chose resources from secure sites that wouldn't be susceptible to XSS attacks themselves.

Okay... but after all of this, CSP and CORS still sounds almost the same?

Yeah look.. they can be confusing concepts to distinguish because there seems to be a lot of overlap. The way I look at it (in order to help separate the two in my brain) is to consider "what do you have control over". As a host, there are three (general) scenarios:

You want to request a resource from another site ~ What CORS policies do they have in place?
Another site wants to request a resource from your site ~ what CORS policies do you have in place?
You want to load a resource (script, image, whatever) from another site ~ does your Content Security Policy allow you to load resources from that domain?

Have you got any handy ways of remembering the difference between CSP and CORS? I'd love to hear them.

Why is learning to code so hard?

Sophie Kaelin — Sat, 10 Jul 2021 06:30:46 +0000

A comment I’ve heard from many people is :

“I’ve tried to learn coding so many times, but it never seems to click.”

Is this something you’ve said in the past? Don’t worry, you are definitely not alone. Having taught multiple introductory programming classes before, I’ve noticed this is a sentiment shared by a lot of newly starting developers.

Learning to code is hard. And while it is true that some people find it easier to learn programming in comparison to others (whether due to higher levels of interest or an aptitude for logical/mathematical reasoning), the way someone goes about teaching themselves to code will impact the likelihood of them developing and retaining those skills.

It is very tempting, as it is when learning all new skills, to jump straight into creating the cool things. Like crocheting a jumper, or baking a twelve story croquembouche. It is important to differentiate between your end goal (what you want to build), and what you need to know/learn in order to meet that goal.

Along with that, there are various skills you should develop that will aid you in tackling any blockers or errors you may face when completing a project.

In this article I will be discussing my top tips I’ve shared with hundreds of past students that helped them grow in confidence and ability, as well as the tips previous mentors have shared with me.

Why is it so different to learning other skills?

Learning to code is often likened to learning a language or an instrument. So methods such as spaced repetition are regularly recommended to learn new programming languages, just as you would with learning any language. As much as this is a helpful way of learning, it is important to acknowledge the differences between learning a programming language and human language. The main difference being:

There is no margin for error when writing code.

Let’s say, for example, you are learning to speak French. You practice your French by making conversation with a fluent French speaker. If you were to mispronounce a word, or jumble up the order of words in a sentence, it is likely the other person will still understand what you were trying to say and a conversation will continue. Unfortunately, a computer does not have that sense of intuition. There is no “close enough” in programming — only right or wrong. That’s what makes it so difficult.

If you were to ask any person with coding experience, I’m certain they would be able to recall multiple times they were stuck on a silly bug for hours if not days because of a spelling mistake or syntax error. And if they can’t… well they’re lying ! I’ve personally felt the embarrassment of being stuck with broken code for hours, only to realise I wrote “docmuent” instead of “document”, or raged when I couldn’t connect to my server only to realise it was running on port 8888 instead of 888. A human can understand what was meant to be said, but a compiler does not have that ability.

The unforgiving nature of code is what makes it such a difficult thing to learn. It is also the reason why it is vital to develop a handful of important skills that both limit mistakes made, and enable you to solve and debug errors in order to move forward from those mistakes.

What skills should I learn?

If you are trying to learn to code, it is important to first learn the following four things:

Core programming concepts
Problem solving strategies
How to debug your code and
Core features of your chosen language

Core Programming Concepts

It is one thing to copy out an answer you saw on Stack Overflow. It is another to understand what you are writing and what it is accomplishing. It is near impossible to learn how to code without first understanding fundamental components that code is made of. Good things to research first are:

Variables & Primitive Data Types
Compound Data Types (Strings, Arrays, Lists, HashMaps)
Memory Allocation
Loops
Boolean Logic

There are various online courses available to teach you these concepts, as well as countless Youtube videos. For the most part, these are transferable skills across different languages.

Videos by “The Coding Train” are what I watched when I first started learning. Another great resource is “Code Academy” if you are looking to challenge yourself and receive feedback.

Problem Solving Strategies

Once you’ve got the core concepts down, you should spend some time practicing completing functions to expose yourself to different scenarios and generate your own strategies for how to overcome them.

Expose yourself to popular searching or sorting algorithms. Practicing implementing well known algorithms will assist you in developing a better understanding of computer science concepts. Plus, the more practice you get, the better you become at problem solving. This may take a bit of time to improve at, but it can also be very fun.

Here are some fun resources to practice with:

Cracking the Coding Interview: unpacks common questions given in coding interviews.
Coding Bat: I used this all the time when I got started. Getting a gold star next to completed problems also feels super rewarding.
Leet Code: Another great tool for practicing interview questions.
Geeks 4 Geeks: Fantastic write-ups unpacking popular algorithms and core programming concepts. Great for refreshers on topics you may not have visited in a while.

How to debug your code

When your code breaks it is important to ask yourself: do I understand what I’ve written? Is this broken because I lack understanding on the topic?

Odds are, you will encounter many MANY errors throughout your journey. Experienced programmers still come across various bugs and challenges they need to unpack every day. The difference between experienced and unexperienced developers is that the former have effective strategies on how to debug and unpack issues in their code.

The best way to debug your code (especially as a beginner) is to print variables to your console or using debug tools built into the IDE you’re working in. You will gain a better understanding of your code by stepping through it line by line to find the source of your issue. Tracing things in your head can also get super tricky and complex. Try creating memory diagrams and tracing your variables on a piece of paper as you step through code.

The more experience you have encountering problems, the better equipped you’ll be with dealing with them in the future. Don’t feel disheartened if you are making a lot of mistakes initially — we all make mistakes, and the learning curve is different for everyone. Take each mistake as a learning opportunity — you’ll be surprised how quickly concepts will come to you later when faced with similar problems

Mike from Code Academy highlights some great debugging strategies to practice when getting started.

Core Features of your Language

Do a bit of research on the language you want to learn. This isn’t exactly a step, but more something you should be doing and learning by default when learning concepts and practicing problem solving. No doubt you will come across various errors and bugs you cannot explain. By researching syntactical standards of the language of your choice you will be able to identify these mistakes earlier. Maybe try and organise a time to chat with someone who has experience with that language and ask for their tips.

Another thing to consider is what type of things you are wanting to build. This will impact which language will be the most appropriate to learn. If you are planning to build iOS apps, Swift would be a worthwhile language to consider learning. If you were hoping to build websites, Javascript would be more appropriate. Do your research and ask for advice. There are so many languages and tools out there, it is important to try and find the one with the most appropriate features and functionality to suit your goal product.

* * *

Extra Tips

Get yourself a mentor. There is nothing better than having a person to explain your problems to without fear of feeling stupid. Their support will be invaluable throughout your journey.
There is no indignity in asking for help. I know I keep repeating myself, but mistakes are part of the learning process. It does not make you dumb, it makes you efficient and resourceful.
Get yourself some buddies. Learning to code is much easier when you are doing it with a group of people.
Teach someone else. Teaching is one of the best ways of learning, so once you feel comfortable with topics, have a go at teaching someone else what you’ve learnt.
Start good habits early. Things like naming your variables and functions meaningful things, leaving code comments and using version control. Future you will thank you.
Take notes. There are resources all over the place, try and collate some notes just for yourself to reference.
Google is not always your friend. Knowing how and what to search is something that comes with experience. Instead of searching for a solution, search for things to help you better understand your problem so that you can come to your own informed solution.
Buy a rubber duck. I’m serious. Tell it all your problems, and in explaining your problem you might answer your own question.
This is a bit of a stretch goal, but look into testing. It is important to trial how your code responds to a variety of different edge cases to ensure it works the way you think it does.
Lastly, and most importantly, don’t expect to know everything straight away! Imposter syndrome is so so common in the computing and engineering community. My friend Grace wrote an amazing piece on Imposter Syndrome I’d recommend reading. It is easy to compare yourself to someone who seems to know everything. But try and remind yourself that everyone started somewhere and everyone has been in the position you’re in now. Its a sucky feeling, but if you persist with it and invest the hours, you can be just as knowledgable as your friend with the insanely busy Github profile.

The best and worst thing about programming is that the learning never stops, and technology continues to evolve and change. Be patient with yourself, set up a study plan, and practice, practice, practice!