I want to share some things I learned with my first dev job at a small commercial real estate startup. My official title was Associate Full-stack Software Engineer and I worked with about 5 or 6 different applications built with different stacks. Some of the technologies include React, Next.js, Node.js/Express, Ruby on Rails, PostgreSQL, Docker, AWS, Cypress, Auth0, and some others. I hope that this helps give you some insight into some things that you can practice or bring awareness to while you're on your dev path.
Javascript Is A Loosely Typed Language
I never really understood the need for Typescript or Flow libraries until now. Even though we did not use either library in our codebase, I had to fix issues/bugs that involved something as simple as something returning a string versus a number. To the new developer, the browser developer console can show the string of a number 1 versus the number 1 differently. Using typeof <data> can help you discern what type it is. Spend some time and figure out the differences between null, undefined, and void too. While you're at it, make sure your logic with if/else if/else statements are pretty solid and practice the ability to think of edge cases. This is something I am still working on but I was still able to solve issues in my company just because of type issues.
Typescript is something I plan to pick up and I feel like it's a great time since v3.5 was introduced recently. ReasonML is another recent addition which is slightly different from Typescript that's fun to look into if you have the time. I would recommend Typescript since a lot of job descriptions list "React or Angular, Redux, and TypeScript" used in their codebase. As fun as new toys are to play with, you have to understand that there are codebases out there that still have older technologies and it will only benefit you to learn them too. Besides, the underlying concepts are usually the same so when it comes time to pick up something new, you're ready right out of the gate to race ahead.
Commit Early, Deploy Often
I always had already good habit of making meaningful commits when I first learned to code so it helped me out. It's easy when you're coding solo and pushing up your own code. Situations get complicated when you're dealing with CI/CD tools, multiple branches, working with other developers. Some good reasons to push up your code is so that it gets saved in a secondary location (Github), lets other developers review your code earlier, allows the deployment tools (CircleCI, Heroku, or AWS) to run their tests for code errors, and gives your managers a chance to test the features out and give you feedback quickly.
Strangely, I was averse to the permanence that all my code was saved on the interweb forever and I would look back and regret that it wasn't the best code I had written. News flash to the perfectionist developers out there that probably suffer from this but you can find consolation knowing that you can just make new branches and new changes to merge to that branch.
Maybe you really are a perfectionist so commands to delete feature branches are useful. To delete a local branch, try git branch -D <branch name>. To delete a branch on a remote like Github, try git remote push --delete origin <branch name>. Those will help you clean up a bit if you want more control.
Write Helpful PR messages
I feel that most companies will have some guideline on this but mine was not as stringent. I just wrote about the things I did for the PR and the branch that I am submitting the PR to. So my PR might look something like:
When first working on a new feature, it was extremly helpful to send an initial push to the repo with a change to the changelog/release notes. From there, you can make a checklist for yourself using - [ ] which you can start checking off after your finish certain tasks. This helps you keep track of your progress and helpful for other people to see you're really cranking it out. This tip was something I picked up from Lambda School since we had to document what features we built during different project sprints. From my medical days, there's a saying that goes: if it's not documented, it didn't happen. I guess that one stuck to me pretty well.
I found that having the - [x] PR target => development really helped me in messing up from merging into the wrong branch. I'll admit that I did accidently merged into the master branch before but it was resolved pretty quickly.
At the end of 2 weeks, it's also easy to go back and see all the PR's you made and quickly see what you did. There's the Jira, Trello, or Asana board for this usually but being able to reach into the PR and see the exact code I've pushed up helps with explaining the exact features I made for that sprint.
Testing Can Be A Pain
We learned Jest and Enzyme in Lambda School but we used Cypress at the startup. It was another testing tool I had to learn but luckily it was an end-to-end testing library and was easier to pick up in my opinion rather than unit testing or integration testing. I learned that if my tests didn't pass, it wouldn't get deployed since CircleCI build would fail for any failed tests. Sometimes writing the tests took me longer than writing the actual code. With things to learn like fixtures, stubbing, and learning the testing library syntax, it's like learning another complete code language.
If you're able to, familiarize yourself with the different testing libraries. I recommend Jest, react-testing-library, and Cypress. I've read and picked up that Enzyme was falling out of favor since it's convoluted. Nonetheless, many companies are still using it as far as I know. Start writing tests for your apps and know that it is time well spent. I also heard that testing the UI is much more difficult than other tests. Learn what you can and I'm sure your company will have guidelines and other devs to help you out.
Be Open To Adopting New Tools
It was toted that every great developer should know how to work the command line. While I do agree with that, I also agree with learning things that can help you move faster too. See the cool tips below on how I learned the command line to do most of what I need during my average workday. However, my lead developer recommended that I try GitKraken. I was averse to these kind of softwares (GitKraken, Git Tower, Github Desktop) since it simplified the process and would not prepare me well for my dev job. After taking my time and learning the command line codes, I noticed that it's a lot easier for me to click and make changes rather than typing out every single command. Don't forget, you have to look them up sometimes too if you forget.
Take the case of code reviews where I had to hope on Github and navigate to the PR request and use the Github's side by side file comparison to discern the differences between the old repo and the proposed commits. With GitKraken, I loaded up the tab with the repo already opened, can quickly see the changes in a much easier view, and resolve conflicts much faster.
It was also pretty helpful for me to quickly see the own code and files that I have maded changes to before making commits and pushing up changings. Let's admit it...it's quicker for me to click on 3 specific files to the staging area and type a commit message in GitKraken than doing it in my iTerm terminal.
Cool tip: I used the 2 free Udacity courses about Github to learn the ropes. Check out the awesome Richard Kalehoff course's about Version Control with Git and Github & Collaboration.
Cool tip #2: Checkout DataGrip as a substitute for PGAdmin4. It was a lot easier for me to use and load up.
Have A Decidated Developer Browser
My main browser for checking news, visiting websites, financial managment, and other needs is Google Chrome. The browser I develop in is Firefox Developer Console. Besides your normal chrome browser with all your extensions, I would recommend installing other browsers to develop in as well. Why am I doing this? One, it's another popular browser besides Chrome that gets used a lot and lets you experience very subtle visual nuances that you might not see in Chrome as an example.
Two, I store all the quick links on my toolbar on it so I have really quick access to the 6 different repos in the company, the Confluence documenation, the zoom channel we usually have standup on, the CircleCI development apps to see when my apps gets deployed, and about another handful of other links that I use daily. You end up saving time since you don't have to dig through your bookmark history for something that you use everyday anyways.
Lastly, this improves your normal browsing experience on your regular browser since it's not bogged down with all the extensions from your development processes. Imagine loading on about 8-10 other extensions on your main browser when you're not even going to use them during your regular browsing experience. That's a waste of your resources. Put them only on your development browser. Here are some of the development extensions I like: LastPass, ColorPicker, Lighthouse, PerfectPixel, React Developer Tools, Redux Developer tools, and Resize Window and Viewport.
Take Great Notes
I wished that I had taken more notes and started a journal when I first began my job. Since things were moving so quickly, I only managed to jot down useful links about topics that were used in the applications as I was building/fixing them. Regardless, I still do have some great guides and articles written in the official docs or developers that I will always have if the topic comes up again.
Where did I end up keeping my notes? Messaging myself on company's Slack channel was quick solution but I eventually moved it to my free Microsoft Onenote account. I kept all the company related information stuff including related company notes for myself. If I had taken more notes, it would also make it easier to update my resume along the process and to see how much I have progressed. There's no doubt in my mind that I learned a great deal simply by getting into the production code of the company.
Practice Explaning Things Out Loud To Yourself
One thing we did a lot was having to explain our technical implementation to non-engineers. When you can be concise and clearly explain what you did, this gives a chance for people to put more faith in you. It was Warren Buffett that said a degree in communications is one of the most valuable you can get.
There were situations in the code where it was quite complex to explain. For example, we have buildings that were considered premium and non-premium and they used different images/files depending on that classification. Instead of explain the logic of how I implemented my super cool pdf extension detector and convert it to an object, I just told them the rules of how it works. They didn't need to know whether I used an object, array, or any other data structures.
You might have already practiced explaining your code in your coding school or during technical interviews but you should even start talking to yourself if you code solo. It's a helpful skill to develop. I talk to myself when I'm working on algorithms or data structures. I pretend that I'm standing in front of 2 people, one who is technical and another who is non-technical. I feel like if I can explain in a way that they both can understand in their capacity, I've done my job. If they have questions, they'll certainly ask you. Anticipating those questions doesn't hurt your chances either.
Top comments (0)