Two years into my first software engineering job

Chung Nguyen — Sat, 19 Jan 2019 23:36:56 +0000

In the blink of an eye, I'm now at my second anniversary at my first engineering job. I thought it would be a good opportunity to sit down and gather my thoughts (since I never did the first anniversary write-up).

High-level background info:

I'm 37 years old, work in Silicon Valley, have a BA in English, and had over 12 years of experience in customer-facing roles before going to Hackbright Academy (an all women's coding bootcamp in San Francisco; blog post on the experience) and then becoming a software engineer.

In the spirit of scrum retrospectives, let's list the things that went well, didn't go well, and could be improved over the past two years. Starting from negatives to positives.

Not well:

I continue to have bouts of impostor syndrome. Every now and then I'll be working on a big, highly-visible feature and think, "Holy crap, why would they give me this project? Don't they know I've only been coding for less than two years altogether!?!!!!!?!? I STILL DON'T KNOW HOW TO TRAVERSE A GRAPH ON THE WHITEBOARD." And when that happens, I let the thought come and go and remind myself, "Chung, this isn't the first highly-visible feature that you've worked on. And the last one you worked on, you delivered it on-time and to-spec. You'll most likely do the same on this project, too."
I still make bugs. (Read: HOLY CRAP, I'M HUMAN AFTER ALL!) I refer to it as "job security" to lighten the mood but, they happen and they are oh so humbling.... And I'm learning to accept this truth (while still trying to minimize the bugs).

Well:

I've learned so friggin' much. When I first started at my job, I was on the backend team and had to ramp up on Java. (We learned Python at Hackbright.) Six months in, I ended my backend rotation and went over to the frontend team and had to learn Angular and fully embraced my love-hate relationship with Javascript. I have: updated the DB schema, checked a ton of code that now lives in production (and a lot even in the main dashboard of our product), optimized code for performance, created API endpoints, implemented Apollo client in our codebase to use GraphQL. The list goes on and on. This is definitely the thing I love about software engineering and look forward to doing more.
My codebase knowledge + my hyper-organized tendencies (evidence) = ridiculous productivity. I think back on when I first started and I struggled so much with everything. (Ugh CSS. Ugh installing Node.) Now I'm able to restructure how we parse a ton of entities and generate a brand new page / component within a week's time. All the while, helping to review code, answering questions*, and moving projects along. Hooray, productivity!
- * Segue about answering questions: Remember how I mentioned that I worked in customer-facing roles for 12+ years? Turns out that answering technical questions doesn't really require a lot of specific technical knowledge, but rather 1. a keen eye (thank you, BA in English) and 2. a boatload of patience. When folks come over to ask me questions, I patiently listen (even though I have no idea what the actual answer is) and half of the time, by the end of telling me, they'll have figured it out. Or as they walk through it, I'll spot a typo or an errant space and boom! problem solved.
I've been rewarded for my hard work, from a raise, promotion, and winning the "Values in Actions" award at the company-level. It's really nice to be recognized and appreciated for my contributions.
Before making the decision to quit my comfortable job, going to a bootcamp, and venturing into a career I didn't know much about (at age 35!), I was legitimately worried that I wouldn't like it. I'm happy to report that after two years: I love it! The computer-facing work suits my introverted heart nicely (read: not client-facing, not a ton of meetings). And the detailed, technical work itself is challenging and highly addictive for someone like me.

Improvements:

I feel my learning plateauing lately, which is natural, but I shouldn't let that inertia build. There's still so much I want to learn, and I need to prioritize that.
I definitely haven't hand-lettered as much punny code as I could:

See on Twitter

See on Instagram

Yep, that about sums it up. Two years gone in a flash. And if this diagram that I drew of Ken Mazaika's post still holds true, I'm officially an "experienced dev". Woohoo!

See on Twitter

Managing Your Personal Sprints w/ Trello

Chung Nguyen — Sun, 22 Jul 2018 18:58:40 +0000

Your hyper-organized developer is back to share something I've been using since August 2017 that has kept me extremely productive and put-together.

Background: I work in a team of about 12 people (as part of a larger Engineering Department) and we develop using the Agile Scrum framework. This means there are these meetings:

Sprint grooming
Sprint planning
Sprint retrospective
Sprint Telecommunications

Okay, maybe not that last one. But lots of ceremonies and such surrounding the framework. The thing that matters most to me is that I know EXACTLY what I need to do and get done in any given sprint so that I can deliver them on-time and on-spec.

We manage our sprints with Jira, which works fine for managing at the team / department level, but for personal use, I find it misses some very key things:

Easy searching of tickets
The ability to take personal notes (and, let's be honest, to gripe about 💩)

Enter: Trello.

Here's a Trello template board for you to use!

Main uses:

I keep a lot of deployment notes and IDE keyboard shortcuts on this board. I don't deploy every day but when I do, I like having my deployment links and info in one place. Also, I jot down all of my test accounts as well as their respective environments here.
Each ticket I have on Jira corresponds with a Trello card. I have a template card ticket that I copy and make for every new ticket in the sprint. It's relatively optimized because I just need to copy+paste the entire ticket number and name from Jira over to Trello. There's also a link to the Jira ticket in the Trello card for when I need to refer back or to update my entire team on progress.
I try to kanban it and have only one card in 'doing' state. This helps me stay focused on seeing the task through to its conclusion.
I also keep tabs of my merge request (MR) in the Trello card itself. This has helped me a lot in finding code from previous implementations quickly and easily. Feature X that I built in November 2017? Yes, I have the link to the MR so I can quickly recall what specific code was introduced.
And I basically use the browser Ctrl + F to search the Trello board all the time. Whenever someone asks what happened with XYZ, it takes me about 5 seconds on my Trello board to give them more info.
Most importantly, I can keep private notes on my Trello board / cards. Comments on Jira tickets are 'public' and can get ridiculously confusing for folks when a ticket is in-progress. Do CS, PMs, other devs, and the entire company at-large really need to know the five things I'm investigating right now to fix this problem? Most likely not. I had no other place to note these things and Trello has been such a lifesaver in this regard. And, as a hyper-organized person, being able to put down what I think will be the to-do items in a checklist and marking them as done as I go along? Satisfying AF. ✅

Hope this info and the Trello template board are helpful for you to stay organized!