Hi! I’m back!
I took a 6 month hiatus from blogging, primarily because I originally viewed it as a tool to get a job…and then I got a job! I received an offer 2 weeks after graduating bootcamp in December (merry Christmas to me!) and started as a junior developer in January. 6 months in and I’m LOVING it. Since beginning, I’ve learned a ton, and I would like to document in some way. So here I am! While this blog was certainly effective for landing a job, I also think it’s a useful tool for me to articulate what I know about various pieces of technology, develop metaphors to help me understand them better, and fill in the gaps in my knowledge that are inevitably revealed in the writing process.
I wrote up a list of topics I plan on covering in future weeks (python magic methods, security vulnerabilities, jquery, selenium, git…) but for now my mind is on what advice I would give to Maddie-from-6-months-ago: fresh out of bootcamp, and starting at a new company as a junior developer for the first time.
Tip 1: Write down any unfamiliar words you hear, and research them later.
On my first day, I attended stand-up at 10am just like I have every workday since then. Now, it’s a helpful way to get an idea of what everyone on the team is working on…but on the first day it genuinely sounded like everyone was speaking Italian (…and I don’t speak Italian.) After that first standup, I made a list of all the words I hadn’t understood, and I kept adding to that list throughout the first few weeks. Eventually, I would go through and search them in our team Confluence (note: Confluence was DEFINITELY one of my mystery words) and on Google. I was just looking for the basics. I learned that Confluence is a tool to “create, collaborate, and keep all your work in one place.” Great! Next! This made stand-up start to feel more like it was being spoken in French (…I dabble.) Nowadays, I feel fluent. I definitely can’t tell you everything about the Bugsnag API, for instance, but if someone mentions Bugsnag in passing I at least have a reference point.
Tip 2: Make yourself a git cheatsheet and tape it next to your monitor(s).
Git is an extremely common version control system (don’t know what that means? Add it to your list right now!) It’s also a tangled web of commands that don’t always work how you intend them to…and there’s no ‘git undo’ command. I am absolutely not a git expert, but one of the best things I did in my first few weeks of contributing is make myself a handy cheatsheet that makes me SEEM kinda like a git expert…or at least git competent. The contents of this cheatsheet depend on your level of expertise. I already had the basics memorized (git checkout, git pull, git add, git commit…) My cheatsheet is more of an, “oh heck I have made a terrible mistake, please help me” kind of guide. Here are the contents of my cheatsheet:
- Discard all commits on branch: git reset –hard <last good sha>
- Discard last x commits: git reset –hard HEAD~x
- Add a change to commit without editing message: git commit –amend –no-edit
- See files in a commit: git show –stat <sha>
- Only merge one commit into a branch: git cherry-pick <sha>
I add to this list whenever I realize that I’ve googled the same thing more than a few times. I just added git cherry-pick to my list this week.
Tip 3: Embrace the search-entire-codebase feature in your text editor.
I’d say that I search my entire repo about 1 jillion times per day. Here’s my workflow for locating the code I need to edit for a ticket: find a key word in the ticket, and search the entire GIANT repo for it in my code editor (I use Sublime.) It’s actually pretty fast. Obviously, the quality of your key word is…key. If you have to dig through every instance of a function that gets called 1000 times, pick something more unique to search. One time I accidentally searched my entire codebase for the word ‘if’…and I crashed my editor.
I also use this method to find where functions I’m working with get called from. It’s a very helpful way to trace backend code back to the frontend so I can test it.
Tip 4: Figure out a method to keep track of your tickets.
My company uses Jira for ticket creation, and there are built-in tools in place to manage tickets. You can save customized searches to help you locate specific tickets, and create personal dashboards based on the searches you write. Here’s a simple search to find tickets that are ready to be worked on or currently in progress, and assigned to me:
While I definitely use my dashboard, I also found that a tracker in my notebook works best for me. The current version has my tickets on the y-axis and the stages of development on the x-axis. I like to check off the stages as my tickets moves closer to production so I can see at a glance where all my tickets are at any one time (even if they’re currently assigned to QA). If you prefer digital tracking, that’s cool too – just get a system that works for you, because losing track of a ticket is no fun.
Tip 5: Write down notes and questions for each bug (especially on Fridays!)
I like to jot down notes for the larger tickets that I work on so I have somewhere to reference when I return to the ticket later on. As you likely gathered from my ticket tracking system, I prefer pen-and-paper notes, but I can see this working equally well digitally. A lot of times, my notes are just relevant files and what calls them. Sometimes, I make a to-do list based on the ticket’s technical specs to make sure I don’t miss anything. This is SUPER helpful on Monday mornings when I sit down to work on ABC-1234 and don’t have to re-find where the function I’m editing lives in my repo. It also helps me articulate better questions for senior devs when I get stuck.
These 5 tips have helped me stay productive and organized in my first 6 months as a developer, and I know that I’m going to learn many more strategies over the next months (and years!) of my development career. What tips have helped you most at work?