Intro#

A collection of advice that no one explicitly tells you about performing well in your first tech job.

There will come a day (perhaps on your first day, or maybe even every single day) when you are given a task that you have absolutely no idea how to even begin to tackle. If your first response is to panic, keep reading.

Fundamentals of debugging#

🖨️ Print Statements: Use Them (Intelligently)
A very popular approach to debugging is to simply add a bunch of print statements. This can be done at varying degrees of sophistication:

1. console.log('here') - caveman approach but it works.
2. assert(result == 42) - simple and effective. Note that your code will likely exit at the first failed assertion, which may or may not be what you want.
3. Logger.info('Extracting the file...') - nice! Not only can you configure the Logger to print any useful additional information you want, but you can also just leave these logs in your code because they (most likely) won’t be printed in production.

⚠️ Error Messages: Read Them
Read it. No, really, read it. And understand it. Sometimes the error is just a typo, an incorrect import path, or expired credentials. Don’t spend hours moving files around and adding print statements - read the error message first.

🐞 Debuggers: Learn Them
Learning how to use a debugger is one of the best things you will ever do for yourself as a junior developer. You will never need to console.log() ever again, seriously. You can look up debuggers for your specific language or IDE, or watch the best video I could find about debugging:

Snooping for information#

🔍 If you work at a moderately-sized company, you most likely have access to a ton of written content. You can look up keywords about your problem in:

1. Internal documentation like a Confluence, Notion, or other Wiki-type platform. Some companies even have their own internal search engine.
2. Slack messages - you’ll be surprised how many times someone has already asked the same question in some random channel.
3. Codebases - maybe someone else has already written a working implementation of what you’re trying to do. Try filtering by file extension (e.g. .py for Python files).
4. Document editor i.e. the platform people use to actually write some of the internal documentation. I’ve found some interesting tidbits by searching up keywords on Google Sheets.

🌐 If your error message is generic, i.e. it does not contain company-specific information, you can also try:

1. Google - specifically look for results on StackOverflow, Reddit, or GitHub Issues.
2. Claude AI. The other AI tools suck for coding, but Claude is pretty good. Deepseek is great because it lets you follow its train of thought, but it’s down often. Try to use AI only for understanding concepts or generic issues rather than copy-pasting code, which could get you in trouble.
3. Open-source code if applicable - one of my internship projects got derailed because of a bug that was only mentioned twice in the GitHub Issues of the open-source software I was using.

Many search engines like Confluence support search syntax

Talk to a rubber duck#

🐤 Before you reach out to a human, try explaining your problem to a rubber duck. Alternatively, pretend you’re doing a presentation about your problem to a child. This practice often reveals logical gaps in your understanding. It’s very likely that you will have an “aha!” moment halfway through your explanation, because you realized something you just said doesn’t make sense.

While you’re at it, maybe you could even add the explanation to a README or to a document, so other people can benefit as well.

Finding the right person#

👥 When you’ve exhausted your independent problem-solving options, it’s time to reach out for help. Here’s a recommended escalation path:

1. Your fellow junior teammates - they might have faced similar challenges recently or when they were onboarding.
2. Your senior teammates - they tend to be very busy, but oh-so-knowledgeable.
3. People on other teams - if your problem is something your team doesn’t have enough experience with. You can find them by asking your teammates, searching Slack messages, or looking at the commit history of relevant codebases.
4. Your manager - they likely have 10-20 years of experience, so who knows what they might know !
5. Other Slack channels or forums - if no one has been able to help you by now, write an open call for help in relevant channels and cross your fingers.

⏰ While you wait for whoever you contacted to respond, beware of the ticking clock:

• Expect to wait about 2-4 hours for a response, in the meantime try to work on something else or learn something new
• If you’re both in-office, try to find them in person
• If 12-24 hours have passed, send a follow-up message or tag them in a relevant thread
• If 24-48 hours have passed, send them a 15min meeting invite - it creates a sense of urgency that some people respond to more than a Slack message. But also, it’s time to try messaging someone else.

Important - how to DM people#

💬 Don’t ask to ask - the way you ask for help can greatly impact how quickly and effectively you receive it. A good sample DM might look like this:

Hi! I'm working on the auth service migration (JIRA-1234) and running into an issue with the token validation.

I've already:
- Checked the API docs
- Verified my credentials
- Tried the solutions from the internal wiki
- Added logging to track the token flow

Could you help me understand why the validation might be failing even though the token format looks correct?

On communication and visibility#

📢 Being visible doesn’t mean showing off - it means being transparent about your work and contributing to the team’s knowledge base. Some reasons to strive for visibility include:

1. Leaving a trail of your work - this is useful for yourself during performance reviews, and for your teammates if you need to take extended time off or leave the team.
2. Improving team efficiency - your teammates can learn from your process instead of having to make the same mistakes from scratch.
3. Social capital - not only does openness and transparency make people want to help you, but it also creates a sense of competence which might lead to more impactful projects or opportunities being tossed your way.

🔕 You want to be visible without being noisy. Some ways to do this include:

• Commenting on PRs even if you’re not assigned as a reviewer, or even if it’s your sister team’s PR. Make sure to leave thoughtful comments and use “we” language, for example: Could we consider using async/await here? It might help us handle errors more elegantly.
• Posting updates in public channels, for example a short celebration message in the team channel when you hit a milestone in your project.
• Sharing documentation - for example: updating an old README or team wiki, creating a runbook for a common problem, building a knowledge sharing doc, or sharing your notes about a complex concept you worked on.
• Mentioning others who have helped you! This could be during regular standup or in a public Slack message.

Final words#

Hopefully some of these strategies are helpful to you.

🧀 The key takeaway is : your goal is not to never need help - it’s to need help on increasingly complex problems! The best engineers are not those who never get stuck - they are those who have mastered the art of getting unstuck :-)

Have a meme before you go, courtesy of smbc-comics