This content originally appeared on DEV Community and was authored by Ash
It's been 6 weeks since my first day as a real-deal, steadily employed frontend engineer. In those 6 weeks, I've made mistakes, felt stupid, learned a lot about living, production-level code, and myself. I've also seen that becoming a developer, no matter the path you take to get there, can only teach you so much about actually entering the industry and stepping into large projects built by multiple teams of knowledgeable individuals over several years.
If I could go back and give me from 6 weeks ago any advice, as a new engineer embarking on her first journey with an official title, I'd have a few things to tell her, aside from the reminder to pick up extra coffee.
1. Try not to call attention to, or apologize for, your lack of experience.
On my second day, after completing the nails-on-a-chalkboard process of setting up a laptop, the associated SSO/SAML accounts, and configuring my IDE and VPN, I happily cloned down the first repo I was to work in. Opening it I was immediately intimidated by the number of directories and files, and a tech stack comprised of many packages and libraries that were new to me.
For a time I let that intimidation get the best of me, apologizing about a half dozen times to one teammate or another for my lack of prior knowledge, and I hesitated to pick up tickets and jump into working. Then I remembered I'm human - I can't possibly know everything there is to know about every library that hits npm, and navigating living code you had no hand in writing is difficult.
It's like reading a multi-volume series, with all the fan-fic, the canon side-stories, the limited release collaborations - and then trying to figure out how you can not only add to that but make it better. There's a lot, and there's definitely a learning curve. Give yourself understanding, and if you need to reach out for guidance, try to remove the extra noise from your messages. Leave out the explanations and just ask your question as directly as possible, chances are your coworkers already know you're a junior without you reminding them.
2. Your coworkers are a resource - but a limited one.
This point stands no matter what level of developer you are - coworkers are there to give pointers, discuss sticking points, troubleshoot, and share the load, but there are only so many hours, and so much energy, in a day. Thankfully, Google doesn't rely on a squishy, gray, biological CPU - we can ask it questions, and endless variations of those questions, until the cows come home.
In boot camp, I learned that it's almost always better to do your homework and brute force a solution that needs refinement than to implement nothing at all and ask someone else how to do it. Go forth and Google. Try things out, break stuff, figure out why it broke, and fix it - pull the problem apart.
If you're still at an impasse, get in the habit of giving others context - a screenshot is only a prt sc and ctrl + v press away - and draft your questions. You'll be surprised how often this practice will lead you to an answer without ever pressing send. While you shouldn't be afraid to ask your coworkers questions and to learn from them, you should be respectful of their time and mindful of their mental energy.
3. Document, document, document
Developers know the value of good documentation, which is why it's ironic that so many of us struggle with it on a personal level. Being in the habit of documenting your process and your day, especially as a junior developer, will do loads for recall and concentration, and make it look like you have your stuff together.
There are numerous ways to go about documenting the day, but keep in mind that the best documentation is shareable and ctrl + f-able - unlike the barrage of sticky notes collecting on your desk, or abbreviated, barely legible scribbles in the margins of a notebook. Using a planning app like Trello you can create cards and easily drop in screenshots, attach notes and checklists, and if needed, share all of it with a peer.
This approach helps me keep track of what was discussed and decided in meetings throughout the week, and creates a running log of the tasks I've completed. Once done with a card, it can be archived, creating a very handy backlog in the case that another developer has questions on code you implemented, removed, or changed.
4. Don't take anything personally.
Rarely in life is anything really about us as individuals, and this is doubly true come code review time. Your code will be scrutinized, and you shouldn't be surprised or upset when parts of it don't hold up to the magnifying glass. Chances are your coworkers didn't open your PR with the intent to destroy your self-esteem, so take these moments as a learning experience. Make suggested changes and try to understand why they were suggested in the first place. Keep your ego out of it.
5. Don't stop learning.
I identify as a completionist. There's something about checking things off a list that gives me a sense of accomplishment. But this personality trait is a double-edged sword that comes with a competitive streak, and a predisposition to tunnel vision. I wasn't on the job long before I caught myself logging several more hours than the expected 8 am to 5 pm in an attempt to get more done, but the effort wasn't yielding the expected result.
For starters, I couldn't reach out for hints and pointers because my coworkers were logged off, attending to their mental well-being and personal lives. Furthermore, I was neglecting my own and wasting time spinning my tires trying to understand a tech stack from inside a legacy project, instead of building my own.
Our coworkers simply don't have the time to teach us everything we have to know about the projects we're stepping into - no matter how intimately they might know themselves. If you're struggling to reason about your company's tech stack, try to find a Udemy or YouTube course that utilizes a similar one. When the working day is over, and your coworkers have called it a night, consider spending that hour or two of extra work there.
Don't forget that part of being a developer is a commitment to being a lifelong student, and understand that nothing you learn is useless or single scope. So keep reading articles, stay up to date on what's making waves, support and utilize the community of remote educators this industry has built, and keep hacking on your passion projects.
Breaking into a new industry is hard work. Once you succeed in landing a job it's easy to get swept up in the tide of new information, self-doubt, and confusion that comes with it. Keep in mind that all the things you did while job hunting, like building hobby projects, learning new frameworks and fundamentals, and updating your resume, all still apply - they've just shifted from the main burner.
While you're at it, don't forget to enjoy the here-and-now. When you first started on this journey, perhaps struggling to write a for-loop or understand recursion, you probably imagined how great it would be once you got to where you are right now, getting paid to code. So while you stress about the holes in your knowledge and how long it will take to get to the next benchmark, know that it's all a part of the process - and all you have to do is keep going.
This content originally appeared on DEV Community and was authored by Ash
Ash | Sciencx (2021-09-19T19:46:01+00:00) 5 Things I’ve Learned in 6 Weeks on the Job. Retrieved from https://www.scien.cx/2021/09/19/5-things-ive-learned-in-6-weeks-on-the-job/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.