Mindset

The key to solving a problem is believing a solution exists and that I am fully capable of reaching it. I have worked in the tech industry as a developer for a little over 2 years and over time I have gleaned patterns in my own behavior. When I think I cannot accomplish something, there is no amount of work that I can put in that will prove me wrong. I will start misreading information or forgetting to do things I have done in the past because this problem is too hard.

To-do lists are super valuable. Break out of mental loops. Slowing down is important. I can get stuck in a mental hamster wheel and keep running the same idea over and over. Write down what steps were taken and which steps have not been attempted.

Make it work. Then make it better. There is a huge cognitive load that goes into building a website, feature, or fixing a problem. Baby steps, baby. Focus on one piece before picking up the next and get to a less stressful place before “enhancing.” I find that carrying too many pieces in my brain will probably result in more bugs than solutions.

Be kind to yourself. I think what has made me a better person and coworker is being kind to myself. Initially when I made a mistake I felt like a failure, a fraud, and like I had let everyone down. But making mistakes is how we strengthen the code for the long run. It prompts opportunities for better documentation, type checking, of refactoring code that may have been confusing. With that toxic attitude I had towards myself, I saw it spreading to how I viewed other people’s mistakes! The world is our mirror, so how we see ourselves is how we see others. I sensed this attitude and decided to change it. An attitude and commitment to compassion is not only better for me but for any organization I choose to be a part of.

Process

I can’t begin to stress how important it is to build process-based habits. Some people debug by immediately asking someone else to help them but this results in short-circuiting the learning process and atrophying debugging muscles. Try something, write down what you attempted and then ask for help. You don’t know what you don’t know.

Read error messages. Initially error messages will look like gibberish and sometimes error messages ARE gibberish (it really depends on what packages or libraries you’re using and how it was implemented), but eventually error messages become clues. I love escape rooms and crime podcasts. Error messages are clues to the next room.
Depending on the error you’ve been blessed with (believe me, you will dread the day something is broken and there are no error messages) you can check all the usual culprits for that type of error. Ultimately what errors you will see will depend on what language you’re using.
1. Imports?
2. Paths broken?
3. Incompatible packages?
Read your code. At first, code will look like nonsense. But if you’re dedicated to this being a game of logic and not of chance, you will learn to read and understand code. Do not copy any code you do not understand, it’s not only more likely to cause problems later on, but it could also cause security issues if you paste nefarious lines into your repo. Like people who learn to read music notes and then learn to compose their own music, developers need to reach a level of fluency so that they can be creative and make new things instead of relying on others or external resources exclusively.
Console.log everything. Or however this happens in your programming language. print or WriteString or cout. Check your assumptions about what is happening. And remember to delete them when you no longer need them.
Check your logic. Chances are that if there’s something working but returning the wrong information then you can work your way backwards through the code to find the root of the problem.
• Let’s say that a request returns a string instead of an object.
• Check where the request is being made.
• If you have access to the server side, check what it’s trying to send to the client.
• If you do not, read the documentation closely to see what it expects as inputs or what methods it has made available to you to transform the data.
Don’t always assume you did something wrong! Sometimes you can find errors in external code.
Read documentation. It’s out there for your benefit. The documentation is a resource to a library or codebase that will make sure you know how to use it without digging into the implementation (although sometimes necessary to do). It’s also the source of truth, if something doesn’t work as it claims to then it’s an opportunity for either the docs or the code to be enhanced.
Write documentation. I always tell new bootcamp grads to practice this. It’s a skill I am still not great at, but I have coworkers who are brilliant at distilling a big problem into a wiki page with graphs or data models that make even the least technical of us clearly understand what needs to happen and how. The code may or may not live after you move on to another role and documentation is essential to keeping code alive. A complex code without documentation is costly to any organization or individual because sometimes it’s easier to just write the code again than to untangle the labyrinth of another engineers mind.
After something works make sure you know why. I think this often happens with younger engineers (I’ve certainly done this). We think ‘Oh, it magically works again! Hooray!‘ and move on to the next problem without fully understanding what fixed the problem or why it was broken in the first place. If time permits, fully understand why something broke, what fixed it, and how to prevent the problem in the future. A stitch in time saves nine. But also, when you know how to solve something you can help someone else solve it, too. Contrary to popular belief, engineering is a very social career that involves constant knowledge transfer.
Just because there isn’t an explicit error, doesn’t mean the code works as intended. Create a robust testing plan for your feature, not what a quality engineer might do (their minds are on another level for this, I swear) but at least some common inputs, some common scenarios that you expect and make sure there are error boundaries for your code. What happens if a value is undefined or if the value is really large or the wrong type, does your program fail gracefully?

Mentorship

Why is mentorship so important? Mentorship takes mindset and habit based process to the next level. A good mentor will help you write code or debug. A great mentor will elevate your sense of self and teach you to see things in a novel way.

Part of future problem solving relies on our toolsets.

Watch your mentors:

• How they work
• What they do
• How they approach problems
• What questions they ask themselves or others
• What is their development setup
• How they comment on pull requests

The majority of people who excel at their jobs are not inherently good teachers so hone your observation skills and create opportunities for knowledge cross-pollination. Maybe with social distancing screen shares can work, but also with social distancing your mentor could really be anywhere in the world.

How to find a mentor?

• Ask a friend/coworker/family member
• Ask in communities you’re a part of
• Sign up for mentorship networks

What is a formal mentorship?

• Before starting set some ground rules
• Set consistent hours
• Commit to a timeframe (weeks/months)
• Have a goal you’re working towards or a skill you’re trying to hone

My personal ground rules for a formalized mentorship relationship:

Understand boundaries from day 1, what they expect of me and what I expect of them.
Respect each other’s time. Come prepared with key discussion points or debugging problems.
Be focused on the goal. For example, if it’s to learn a specific tech stack that will inform each session and discussion, or if it’s to get a certain role or speaking engagement, each session will revolve around deliverables and check-ins. Mentorship time and friend time is different, so don’t waste time by deflecting to social time because you will regret it after you part ways.

I attribute much of my growth and success to my mentors: Vlad, Neha, Keenan, and Andra. For the past 2-ish years I have had direct technical mentorship from these four awesome humans.

Vlad met with me for 2-4 hrs per week to discuss what I was learning in my coding bootcamp and we even played with a Raspberry Pi! I had the honor of showing him React and he picked it up in 5 minutes. #goals.
Neha was my mentor during my 4-month internship at Adobe. She stayed late with me when I broke our website with an infinite loop (noob mistake :p). She helped me normalize my anxiety around being in this new industry.
Keenan is one of my informal mentors on my team. He’s always ready to help and has this effortless way of looking at problems that make every bug feel small and conquerable. He also tells me I’m a good engineer and I think everyone deserves to hear that. I’m lucky to have a Keenan on my team 🙂
Andra is my other informal team mentor. Honestly, it’s a gift to have a female engineer of Andra’s caliber to look up to. It’s not just the code, but the way she speaks in meetings or presents or documents problems. Truly a role model for me.

Now…. not just seek mentorship, also seek to be a mentor. It’s easier to recognize patterns in our own behavior when we observe others. It’s also key for empathy and growth to wear a mentor hat.

Debugging is less scary and daunting if you build a mental and social framework to support you.

TL;DR: