How to be a better junior: an overview
I realize that not a lot of actual first-time juniors will read this article. However, I'm convinced that anybody who works in a team and has to deal with people (either more experienced or less experienced) will find this text useful. So, here it goes!
Hey, have you just landed your first job in tech? First of all, congrats! Second of all, after the initial excitement passes, don't panic. Everything's gonna be fine. Yes, you don't know these people with whom you share an open space; you're not familiar with the project they're expecting you to work on; you have no previous experience with the frameworks and languages used - that's all fine. We all start somewhere.
When I got hired by Spectory, I found myself in a pretty difficult position. It was my first real office job. I didn't know what to expect. I also didn't speak Hebrew well and was too embarrassed to admit it to anyone. The first weeks were tough, man. But this period in particular taught me something I wouldn't have learned any other way. So let me share these tips with you.
It's important to understand that you're not completely alone on your quest. You've probably been introduced to at least one person in your team, so talk to them. Ask questions and listen carefully. They're working on the same project as you, and they want the project to succeed, so they'll do their best to educate you, be sure of it.
But here is an important caveat: If you rely too much on others helping you, you don't learn a whole lot. Besides, at some point you become annoying to those around you. One thing new developers often forget is that they're not anybody's responsibility - apart from their own. Yes, all this is stressful for you. But this is difficult for everybody else as well; they have work to do and there is a junior constantly bothering them with questions and complaints. "I tried everything, and it doesn't work!" First, if you need help, make an effort to articulate the problem as clearly as you can. But more importantly:
You have no idea how many problems I solved - or helped solve - by just entering a correct set of keywords into a Google search engine. That's right - I don't know everything, and I forget a lot. So I do a lot of googling, as does every single developer with Internet access, junior or senior, unless they work with some really exotic or cutting-edge technology. And, chances are, your designated helper will google your question too. Therefore, the next time you encounter a problem save time and that of others by googling it yourself.
By the way, as it turns out, googling is not as easy as it sounds, and often I wish someone would just hand me a top-notch "How to google" article. In general there is not much to say, though. The only thing that helps us in sending out a promising Google query is understanding exactly what your problem is.
There are three things you should to know in order to search successfully for answers: what you're doing, what you want to achieve and what is the actual result. Sometimes you run a shell command and get an error output - google the error if it's unclear what could've caused it. Sometimes your search will require more knowledge.
It's easy to understand stuff when you've worked with it for some time. More often than not, though, we have to work with technologies, tools, libraries or language constructs we didn't know existed until two minutes ago. There's one important point that I want to make: Not to state the obvious, but when dealing with the unknown, make yourself acquainted with it as soon as possible. Read documentation and look up code examples. Devote half an hour of your day to learning more about things you don't fully understand or have not yet encountered.
Why am I emphasizing this? Because people tend to misunderstand the "learn by doing" concept. Practice makes perfect, that's true - but no practice is healthy when it's all mindless copy, cut, and paste. So, come on, educate yourself.
Since I adopted these principles (God, I sound like a 60-year old, don't I?), my life has become much easier. Yes, this text is for developers who are facing new challenges, but not really. It's about unfamiliar things, curiosity, communication, and problem solving.
These are things we encounter a lot in our everyday lives, so it makes perfect sense to apply some techniques in dealing with them. And as developers, we're damn good in applying techniques.