Job Readiness - Working with Senior Engineers

Learning Goals

• Identify aspects of effective technical communication in professional development environments
• Practice implementing research, documentation and communication when encountering technical roadblocks

Warm Up

Think about a time that you gave guidance or advice to someone else, or someone asked you for help/assistance with a problem that they had. What information did you need to best support the person you were trying to help? Be prepared to share in breakout rooms!

Working with More Experienced Engineers

As entry-level developers, you are not expected to be experts in software development. You likely will be working on teams that have more senior developers who can be a resource for you as you begin your career. However, there are a few things to understand about working with more experienced, senior developers…

• They don’t have all the answers: More experienced developers are not giant answer keys. However, since they have more experience, they likely have encountered the same or similar problem that you have. In fact, they are likely going to follow similar steps to get “unstuck” that we coach you on at Turing!
• They don’t always have time/space to help you at that exact moment: More senior developers are usually pretty busy. You can’t count on them to drop everything they are doing to help you at that moment. How can you maximize your time together with them when you can find time to connect?
• They expect you to be resourceful: One of the best ways to stand out early in your career is to demonstrate your resourcefulness and initiative. What steps are you taking to help YOURSELF and be a good steward of company resources? What do these traits mean to you?

How to Prepare for the Realities of the Job NOW

Approaching your time as a Turing student like a “job” will make you better prepared for your first paid role as a developer. You will inevitably face some complex problems during your time here that will prepare you for the realities you will face on the job. Let’s break it down…

Trying to Get Yourself “Unstuck”

The next time you are stuck, try the Rubber Duck Debugging method to break down a problem into smaller parts.

• Find an inanimate object in your household (I use a golf ball that I drew eyes on)
• Speaking OUT LOUD to your “duck”, explain the following, step by step:
  • What were you trying to do?
  • What were you expecting to happen? Go through your code line by line to explain how each piece works.
  • What happened instead? What errors did you encounter?
  • What resources or documentation have you consulted to try to solve your problem?
• The magic of this approach is that you may be able to identify and solve this problem on your own by going through these steps!

When It’s Time to Call In Reinforcements

While the Rubber Duck Debugging Method can get you out of a lot of jams, you may still be in a place of unproductive struggle or the Panic Zone.

While part of being a developer is growing your ability to persevere, at a certain point it isn’t productive. As a rule of thumb, if you’ve been struggling with something without making any tangible progress after 20-30 minutes, it is time to reach out for help! “Making tangible progress” includes making some adjustments to your code and getting a new error message, for example.

At this point, it is probably best to reach out for help to a more senior engineer while on the job. But what is the most effective way to do that?

As we mentioned before, more senior developers aren’t superheroes - they don’t magically have all the answers and require a lot of context and specificity to really understand what you are struggling with. If you cannot provide the context or specificity around your process/approach, they won’t be able to help you!

To get to that level of context/specificity, it helps to have gone through the “Rubber Duck” questions on your own and document your answers and steps you have tried. Having these answers and other context provided in a clear, organized way will allow a more experienced developer to diagnose the problem quicker or help point you in the right direction to figure it out on your own.

Tips for Documenting Your Approach

1. Capture the answers to the “Rubber Duck Debugging” questions to ensure that you are clear on what you’re trying to do and that you can articulate it to someone else who hasn’t been working on the problem as long as you
2. Take screenshots of the error messages you are encountering and any relevant code that you are working on.
   • On your laptop, the keyboard shortcut Windows Logo + shift + S will allow you to select a part of your screen to capture and save the screenshot on your desktop. You can then drag and drop this image to Slack.
3. Utilize tools like Github to share your code with others to allow them to dig into the code itself and experiment with your repo
4. When using Slack to share code, - code snippets should not be formatted as plain text. Very short snippets should be formatted as inline code and …

    longer snippets 
    should be formatted 
    in code blocks.
   

   • When asking your question in Slack, to write the inline code, use a single backtic (next to the 1 on your keyboard) on either side of the word or phrase. For a longer snippet of code, use three backticks on either side of the code block.
5. Format your question in easily digestible chunks. You can use the keyboard shortcut shift + return to create a new line without sending your message in Slack. If you have more context to provide, give a TL;DR (Too Long, Didn’t Read) in the main channel, then thread your details in manageable chunks. Another strategy is to use bold text and/or emojis strategically to highlight key information or questions.

The Code Help Slack Channel

We just rolled out the #code-help channel for you to use when you encounter problems and want to use your peers and instructors for help. This is where you should be practicing this approach for documenting your process and capturing the context/specificity of your questions.

Your instructors may ask you to reframe or revise your question to include all of the relevant parts before providing guidance or support. Again, if you start practicing now for how you will perform on the job in the future, it will serve you huge in the job hunt process!

Practice!

Now’s your chance to practice posting a technical question in the new #code-help channel.

1. Start by forking this repl that currently is throwing an error.
2. Try something to get you closer to resolving the error. Even if you already see what the problem is, pretend that you don’t and think of a step that would get you closer to figuring out the problem. Not sure what to try? Adding a Console.Log, adding a breakpoint, or looking up some documentation is a great first step!
3. Post a question in #code-help. Try to use the tips we just covered to craft an exceptionally clear message!