What I Learned My First Week at My First Dev Job

One day I'm filling out job applications, doing Leetcode until my head is doing somersaults, and then the next day I'm in.

To think that just about a year ago I wrote about my fears of even attempting to look for a developer job, and now I'm looking back at my first week as a professional software engineer.

It's still hard to believe, even though the reality of my day-to-day is so familiar and tangible.

This post is for anyone still on the outside looking in. I'm one of the most guilty of imposter syndrome, and worry everyday if I'm capable of doing this job.

Thankfully, my first week flew by and a lot of my initial concerns are dissipating. Most surprising was what actually seemed to be important to the position - which had much less to do about code than I previously thought.

Even though I only have one week under my belt, here's some things that I'm wishing I'd spent more time focusing on in preparation for the position.

Communication is Key

I'd seen terms like "Agile" or "Scrum" thrown around Twitter or Reddit programming circles, but I never quite paid attention because I didn't make the connection on their importance to a person's ability to code in a team.

Without a doubt, Scrum has been the biggest focus of my first week.

And if you really think about it, it makes so much sense and flies in the face of the independent and isolated nature of the process of learning how to code.

From Wikipedia entry on Scrum (software development):

"Scrum is an agile process framework for managing complex knowledge work, with an initial emphasis on software development, although it has been used in other fields and is slowly starting to be explored for other complex work, research and advanced technologies. It is designed for teams of ten or fewer members, who break their work into goals that can be completed within timeboxed iterations, called sprints, no longer than one month and most commonly two weeks, then track progress and re-plan in 15-minute time-boxed stand-up meetings, called daily scrums."

To properly think of Scrum, I put it in terms of a modern military.

In the past, an Army would be made up of large battalions of specific units - infantry are foot solders, cavalry are mounted units, etc.

But the modern military has gotten more complex and sophisticated, relying more on speed and agility rather than blunt force and numbers.

Instead of large battalions of specifically skilled units, there's been a movement towards "commando groups." These groups are a mix of all different skilled units - it may include a few small infantry Platoons, supported by a couple of mounted units, a few air support units, etc.

By, taking a giant army, and parsing it down to smaller versions of itself, it creates a powerful unit that can more rapidly deal with issues in the field.

Scrum uses a similar mentality for software development. Instead of front-end engineers working independently from back-end engineer, Scrum Teams are a mix of five or so people with complimentary skills trying to solve specific tasks in two to four week cycles called Sprints.

It's like parsing down a large corporation into a bunch of startups.

There's a lot of structure in the system, which includes daily meetings, meetings every other week or a month, one-on-one meetings, etc, and a focus on good documentation of work done and work to be done.

Basically, my biggest misunderstanding of the job was just how much I'd be working with other programmers, business people, an administrators who don't necessarily know what I'm doing.

It became clear right away that the fundamental aspect to my job is knowing how to collaborate, not just write good code.

I realized that I'd made a mistake of not taking opportunities to do Hackathons, and instead focused on the specifics of the language I would be working with.

In hindsight I see that going to meetups could've prepared me better for the position.

Github, Jira, and Coding Standards

These could also fall under the umbrella of collaboration, but I set it off to its own space because this is more about collaborating via your code, rather than the management of collaboration.

I am truly intimidated by Github. While Github Desktop has made it much simpler to manage local and remote repositories, it's still not the easiest thing to wrap my head around.

This will definitely come as things go, but in the meantime here's an awesome site to help you learn about Git Branching, and other features of Git: https://learngitbranching.js.org/

Jira is a service that keeps track of tasks that are determined in Scrum meetings. Truthfully I haven't had to work with it yet, but knowing that it will be vital I wish I would've invested more energy into learning it ahead of time.

Think Trello, but that can easily be tied into code.

And with there being such an obvious emphasize on readability, knowing how to maintain documentation and adhere to coding standards is vital.

Here's a few resources that I've been using daily - I work in VueJS so these are mostly specific to that framework, but there should be equivalent ones for whatever framework or language you work with:

The A11Y Project Checklist (Accessibility)
VueJS Style Guide

Also, in my project we're using Storybooks, which is a tool for developing UI components in isolation. I had never worked with it before the project, but I could see it being a great item to add to your resume:

StorybookJS

Testing and Thoughtful Development

The days of my independent Mad Max-like programming is over.

Another perk of being isolated is the ability to write whatever you want, however you want.

Being part of a team changes all of that, and one of the many decisions you'll have to keep in mind with your code is if it'll be digestible by other people.

As I start diving into the codebase it dawns on me more and more that there is going to be a lot of eyes looking at what I've written. And whatever that is it needs to be understood easily and quickly.

While everyone agrees testing is important, and especially vital in Scrum development, it's such an easy thing to toss aside because it can become a perceived sticky spot.

While I'm okay with testing, it's an area that I wish I had spent even more time focused on. Being expertly fluent in writing tests will make writing code an absolute breeze. Plus it will make it much easier for others to work with what you've done.

Not to dive too deeply into it, but from what I've seen, when Test Driven Design is coupled with Component Driven Design, it makes writing tests a whole lot easier.

Some VueJS testing resources:

Vue Test Utils Documentation
VueJS Testing Handbook
Jest Docs

Also check out my previous post about an awesome book on testing by VueJS Core team member and author of Vue Test Utils Edd Yerburgh: Treasure Map to Vue Testing Gold

Can't wait to see what week 2 brings!