So you're trying to break into the industry and spending all your nights and weekends on code exercises, building your portfolio, and just generally being a sponge for all knowledge. Then...you get the job.
First, congratulations for your hypothetical self. But it turns out you've only won half the battle. As a senior engineer who's hired multiple juniors, the first year as a full time developer can be tough. I've seen it work with both fantastical success and seen people struggle.
What makes the difference?
It's not pure technical know how. It's knowing how to ask for help. It's knowing how to help your manager, who is not an expert in nurturing junior developers, help you develop. Luckily, there are strategies you can follow. Here are FIVE that will definitely help.
Tip 1: Ask and You Shall Receive
If you're new at something, you naturally fear the things you don't know to know. So you'll worry about looking like an imposter if you ask the "wrong" question or just too many questions. I've seen developers get stuck and thrash for days in silent frustration rather than ask for help. Worst of all, I've seen some developers glorify this sinkhole of futility as a rite of passage.
Junior developers err on the side of asking for too little help rather than too much
Banging your head on the wall for more than a few hours is not helping you learn nor helping your company. Ask, but ask intelligently and involve others progressively. Don't throw your hands up in the air. Push your team to give you just enough help to you get unstuck and keep going. This feels kind of abstract, so let's try a real example.
Let's imagine you are stuck on a coding problem. You're even unsure as to whether your approach makes sense. Either way, you just feel lost. So here's what your next morning standup update could be:
Hi everyone, so I'm currently working on X feature. I'm not sure how to approach it. But right now, I'm trying Y. I'm going to keep at it this morning, but if I don't make good progress. Would it make sense to grab someone else from the team really quickly to talk through it and get me unstuck?"
If I managed this team, this would blow me away. You've essentially done my job for me. I don't have to pry open your current status to figure out whether there is a risk to manage. You haven't thrown up your hands and just tossed it to someone else. You haven't given me a bullshit answer. You've identified a challenge, established at timeline to work on it, and then recommended the next step that involves the least amount of resources to keep you progressing. This is called "managing up" and it's a tremendous skill whenever you are in a new field.
Tip 2: Write Now, Worry Later
So you do figure out a solution to the problem mentioned above. You feel relieved. That was hard! You proudly submit a PR for review. The next day you wake to find that a senior developer has requested a dozen changes and asks that you rethink your whole approach. You feel like you've just been punched in the gut. Your self-confidence is shot to hell. Can you even do this job?
The real tragedy here is that the senior engineer may have no idea they caused any emotional turmoil. They're just in their own little world tackling a task list, but with a little bit of empathy they could make a huge difference. What if one of those notes looked like this:
Hey, I know this is a lot, but that's expected. You're learning and you've made a ton of progress. If you have any questions, I'm happy to help.
Empathy matters. Without a note like this, the junior developer becomes terrified of their next PR. This is a bad place to be.
So what's the solution?
There are a couple of solutions here. One is to "manage up" liked we talked about in the last tip. Ask for weekly or biweekly check ins with whomever is your lead so that you can just ask "Hey, how am I doing?", "Where can I improve?". If they have criticism, listen to it. It's better than guessing or worrying.
The second is to just understand that code is inherently flawed. All the talks in the world you've listened to about how we can do "coding right". Yet all those same presenters have the same problems in their code bases as you. It's just how this business works. Don't get me wrong. Shitty code is very different from flawed code written by people trying their best. There are a lot of shades of grey here.
You just have to internalize that you only figure out the right path by trying a lot of the wrong ones. That means you can't be afraid of your code. Some of it will suck. If it's a process to learn, then get through it as quickly as possible. Give it your best shot. Feel the pain of debugging it and then iterate till it's less painful.
Tip 3: Go Deep, Not Wide
When you're starting, learning too many things can actually hurt you. You can try all the JS frameworks, fiddle with Docker and Kubernetes, and play with CSS. All the things! This is also how most bootcamps work. They'll spend just a few weeks on a multitude of technologies in order to market how many things you'll learn. In the end though, you might not know enough of any one thing to contribute on a team.
You only need one foot in the door, so get good at one thing to start
Figure out the one thing you're tried that you really enjoy. It could be CSS and design. It could be DevOps. It could be iOS development. Whatever! Then ask your team lead to give you work in that area and just focus on learning how to do that thing at an advanced level.
You'll very quickly gain credibility with your team because you've now got a domain where they can ask you for help. You'll feel more confident and now have a strong foothold to buy time to learn all the adjacent technologies.
Damn, you must like to read if you're all the way down here. Don't worry the last two tips are super short
Tip 4: Don't Put Your Teammates on a Pedestal
Earlier we talked about getting help. So let's say you pair with a senior developer and they give you a recommended approach. You try it out, but it doesn't seem to work. Are you just implementing it wrong or is the approach faulty? You don't want to disappoint or contradict the senior developer, so you shoehorn it in. You write a bunch of hacky, clumsy code to make it work. Upon review, the developer who gave you the approach sees its flaws and changes his mind. You have a palm in face moment.
Senior developers make just as many mistakes as junior ones
The big tip here is that if something is painful to you, that means its actually painful and that's valuable information. You get to have an opinion because you also live in this code base. The most valuable thing you can do is articulate that pain. You'll be amazed at how often your pain points will match others even if they've been silent about it.
Tip 5: Pseudocode is your Friend
Most senior developers generally don't write pseudocode before writing the actual code. They've been doing this so long, they can maybe even think in code. If that's not you yet, then here's a little practical tip that can sometimes do wonders.
Don't think through the logic and syntax at the same time
Try just putting comments where the code will go describing it. Let it read like human phrases or sentences. Once you have that down, just translate each comment into the syntax of the programming language. You're making it easier for your brain to do one thing at a time, which means it can be more efficient.
Yeah, this tip is a bit of an outlier since it's not some grand concept. But it does work. Try it!
That's all folks. Super practical, simple tips to help you succeed.
Top comments (0)