Thursday, October 25, 2018
(aka surviving entry-level dev employment)
I've loved every second of my job at Hatch Apps (we're building something pretty awesome!). In this post, I share the most important things I learned during my first year as a developer. Each developer’s experience is different, and my experience may not reflect that of others, but I hope it helps anyone who is wondering.
Landing your first development job after your coding bootcamp is an incredible feeling. You should be proud of the hard work you put into it, and profusely thank anyone who helped you get there. Celebrate your reinvention!
After that’s done…
You’re Not (and Will Never Be) Done Learning
The first rumor to dispel is that that you can rest on what you learned in coding bootcamp. You cannot. The bootcamp gave you a foundation on which to build. Resting on your bootcamp laurels is a recipe for mediocrity in the development world. Now that the coding bootcamp did it’s job, it’s time to do yours.
During your first week, someone on the development team at your company will probably introduce you to the stack (the various parts of the technical product), showing you around the tech, explaining how your workflow should typically go, and starting you out with a few smaller, easier projects to get your feet wet. Don’t expect to be submitting pull request for major product features. You’ll probably have a good month of getting used to things, more or less.
Expect to have a lot of feedback during this time. It’s natural for you to code the way you were taught, but companies are by nature going to be more professional and desire cutting-edge tech to solve their problems. You learned vanilla JavaScript, some jQuery, and maybe touched on a newer framework like Vue or React. You will probably rarely ever code completely in vanilla JS (or jQuery for that matter). You will be asked to take those fundamentals and learn the modern technologies that undergird your company’s success.
In my experience, it was the Friday of second week where I let my inexperience shine: I built a search results page where the result would be a card with info on the front, but could be flipped to reveal more info on the back. I constructed what I thought was a solid JS object using jQuery, but boy was I wrong: Our lead developer pointed out my poor construction, and stayed for an extra hour after work with me to show me how to do it the right way. I soaked it in, did deeper learning/research, and never made the same mistake again.
Over-Communicate
This might be a result of my previous decade in the communications field, but I cannot stress how vital good communications skills are in your new role. The people you’re working with are knowledgeable and be among your best resources for learning. Sure, do plenty of your own Googling for an answer, but if you can’t figure it out, definitely ask someone. Get over that feeling of “looking stupid” with your questions. Be honest about what you know and can do and what you don’t know and can’t do (yet!). You are allowed to bother others often at the start of your job, but it won’t be tolerated as much maybe a few months in. You demonstrated and sold your employer in the interview on your ability to learn new things, so you have to be able to do it!
Be prepared to fail quickly and embrace it. One of the worst things you can do is agree to some timeline to deliver a build (that works!), only to deliver it and have it not be anything up to standards of the other developers or other parts of the business. Working on a development team means understanding how your smaller part fits into the broader picture, and that your build is something that the overall product depends on. If it requires small tweaks to get it into good shape, okay. If it requires a complete rebuild, not good! That is time and money wasted. Inoculate yourself from this pitfall by choosing moments where your colleagues are at a good stopping point in their work, and ask them how they would approach your build.
Read a Reddit or StackOverflow thread on development topics and you’ll quickly realize: developers (especially experienced ones) are very opinionated about code and the best way to do it. This is a good thing! There definitely is a way to do things, but there more often than not is a better way to do things. It can be intimidating as the junior person on the team, but you need to be willing to admit what you don’t know and ask questions. It’s a sign of a self starter who is eager to learn.
Become Efficient
A couple of months into your first dev job, you’ll notice your skills improving by leaps and bounds. You will produce stuff that is well-structured and behaves beautifully on the screen.
You might also notice (as I did) that each build seemed more taxing than the last: you’re doing the same setup steps, making similar functionality from scratch in two different projects. In my experience, I was starting from scratch each time and spent a lot of time configuring a build before I actually got into putting code into the editor. Then there is the classic scenario of being stuck on a problem, getting very frustrated, and proceeding to copy and paste all of the StackOverflow solutions with green check marks (aka throwing everything at the wall). This is suboptimal.
Begin to notice how there are so many tools, libraries, and packages out there to help you do your job most efficiently. It was about 4 months into my first dev job that this hit me. Instead of trying to code a scroll-triggered event in Vue with a vanilla JS method, I pulled in a library to easily get the job done. Of course there will be strong opinions about pulling in dependency after dependency, but this was a fairly lightweight solution that gave me three or four hours of my coding life back, and we've had no issues with the dependency months later.
I also started to look more deeply into the why and how something worked. For instance, when I stumbled upon JavaScript’s higher order functions like filter() and map(), I didn’t understand them, but I was using them in a couple of my builds. I noted them and went back to the documentation for those functions to understand at a deeper level what they actually did. Since I develop mainly in JavaScript, I found the You Don’t Know JS book series to be the holy grail. It dives very deep into the language and what’s going on under the hood. It can be intimidating at times, but take it in chunks (and look up small concepts that don’t make sense to you before proceeding!).