New to a coding career?

Here’s for you..

I’ve made a lot of mistakes and am definitely in reflection mode as I look back over my career. I’ve consolidated a few, hopefully helpful, tips for others just starting out.

First thing I’ll say is that being new is something you don’t always get to experience. So try to enjoy it! I’ve realized a critical piece of being a new coder is questions. How you ask them, when you ask them, the context of asking them, and the answers you get. For that reason, I’m going to spend quite a bit of time on that topic.

Making dumb (no, seriously) mistakes

People say there’s no such thing as dumb questions. But there really are dumb questions. It’s something I’ve had to learn throughout my career. Sometimes you really can shoot yourself in the foot by asking something that causes a person to assume a certain level of technical ability that may or may not accurately represent who you are or where you’re at. Yes, ask questions. Yes, put yourself out there. Yes, be brave; it’s okay to be embarrassed.

BUT

Look things up first. Do your research. Make sure you’ve thoroughly digested what you’re actually confused about asking. You’ll also get more out of the response if you know fully where the gap in your understanding is.

Never say never, BUT

I would say it’s basically never a good look to ask for help immediately before diving in first. It’s super easy when you’re overwhelmed and you have a coworker who seems kind/approachable to ask question after question without even considering/researching first. Coworkers/mentors can get burned out really quickly in a short amount of time by questions you could’ve mentally/physically took note of and easily googled. Before asking, I would recommend asking yourself :

• Is this something that I could find the answer to online through a short amount of research?
• Is this something I could resolve on my own through reading documentation, studying the codebase, reading through the README, etc.
• How much of my coworker’s time have I already taken up today?
• Is this something I could save for tomorrow, or is it a blocker refraining me from being able to complete my tasks?

Along those same lines, when you do approach a coworker/mentor with a question; again, before asking, I would recommend going through these bullets:

• Have I spent an adequate amount of time attempting to research and resolve this on my own?
• What is my actual question? Do I have a specific question in mind or am I taking my coworker’s time up with something generic and confusing that isn’t going to achieve my goal of getting unblocked?
• Am I actually blocked from being able to complete a task or am I just curious the answer to something? If the second, analyze whether this is the right time/place to ask.

Take Notes

If a coworker has taken their time and energy to explain a concept to you, reward them/thank them by taking detailed notes. A lot of times you’ll have the same question/problem arise over and over again, and it’s a great look for you if you’re not repeatedly asking the same question. It also will help the next new person if you document out common issues that have arose for you. It’ll be an awesome way to pass on that knowledge to future teammates.

The Approach

Okay. The approach. You’ve gone through the checklist, you have a question you’ve deducted is something worth asking your coworker. My recommendation based on experience is this :

First and foremost, let them know the exact problem/blocker you’re trying to resolve. Then, let them know what you have so far. Always attempt the problem first. Even if it’s a bad attempt and you end up scratching it, it’s good for them to see that you’ve already put effort into it, and they can also guide where you went wrong (if you scratch it) or how to build from what you have (what often happens). Starting out, I would get embarrassed thinking I was way off track and lo and behold, my coworker ends up writing out again what I had already had but deleted thinking I was way off-base. Help them help you by letting them see how far you got/explaining why it was the wrong approach. Both are helpful.

If you didn’t get far enough in your question/blocker/problem to have an attempt to show them, have research ready. Research can look like documentation articles you’ve read, stack overflow links you’ve already looked through, or solutions you have already attempted that didn’t resolve the issue and why. You can send code snippets, links, etc. so that your coworker knows you’ve already put in the work and also knows what hasn’t worked. The worst is when they send you all this stuff you’ve already tried.

Ask First

Always ask first if the coworker has a minute to help you with something. I think it’s good to check in if they have time before posting your question. This is different if you’re posting in a dev channel or a similar questions channel. In that case, I would just include as many details as possible.

Here’s an example of something I would post as far as the approach.

I’m working on ____ ticket (include the Jira/Trello link to the ticket you’re working on if applicable/available). My blocker is, I can’t seem to get the mobile view to respond on the Galaxy S5 screen size without changing the way the list is formatted. I’ve tried _____, _____, ____ and looked at ____ on stack overflow, but none of those seemed to resolve the issue. My next step was looking into ____, what do you think?

Another example

I’m getting this weird message in the terminal when I try to run my local environment. **Include screenshots of the terminal, local environment, network tab, console, any screenshots that would be helpful**. I’ve researched this error and most people say to try ____ but I’ve tried that and it didn’t seem to work. Any ideas?

What’s great about asking for help is that a lot of times, you both can figure something out new together. It can be a really fun experience I think if done in this way. I’ve had to learn the hard way how to ask, so I really do recommend following that sort of format before just jumping in and asking.

Document everything

Write down everything you can. Document it all out. It’s helpful for you to remember everything you’ve learned, it’s helpful for future employees coming in down the line, and it also could potentially help the company if it is formatted in a readable way. It saves everyone, including yourself, a ton of time if you can document well.

REFRESHING LIVE SITE

Man.. this still happens at least once a week. I always joke to myself that I’ll be a real engineer when I cease to refresh the live site looking for changes. All I’ll say here is that it happens to everyone, don’t feel bad about this one. You’ll just be sitting with this face quite often :

Always look for ways to improve the company

If you’re confused about something, chances are you’re not the only one. If you can think of a way to make something easier to remember, or documented more clearly, always look for those opportunities to help out. New employees often times see more flaws/room for improvement than the oldest employees. It’s a critical time your first few weeks because you have completely fresh eyes on everything. Write down ideas for improvements that could be made. You don’t have to bring them up right away, but eventually after a few months, I think it’s well worth revisiting the list you made and seeing if there are ideas you can pitch to the team of ways to improve the application, documentation, company, etc.

I don’t recommend bringing up all your ideas of improvements right away because you don’t have context yet. I think it’s better to gather all the context, work on the application a while, and then see how relevant your initial findings were. A lot of times you end up seeing why some of the flaws haven’t been fixed yet after you’ve gotten more of the context of what you’re working on is. I still think having those fresh/new eyes is extremely valuable though and well worth documenting out.

Assume the Best

I would start off day one assuming the best intentions of everyone. If everyone is complaining about the boss, or this one coworker, or the way the codebase is set up, I would actively try to be the positive reinforcer in the room. From day one, I would act as an active contributor to the team.

Especially if this is your first job in the industry, it’s easy to feel intimidated and withdrawn like you might not have a “right to speak yet”. But the newest team members voice is truly valuable. And the more you can speak up, the more you’ll bond/build credibility not only with coworkers, but with management. A lot of times too, as I mentioned, what you bring up could be a perspective the team hadn’t considered before because they’ve been too inundated with the product. So, even if it seems obvious to you, it might not be to everyone else.

That’s it! Those are my main tips! Good luck on your job and congrats on getting into coding! 🤘🏼 Feel free to leave comments/disagreements/tips below!