My First 30 Days as a professional software engineer

After leaving the Army, learning to program and moving to Los Angeles, I found my first software engineering job working on monetization products (ummm…advertising) as a front end web engineer, spending most of my day coding in React.

When I joined my team, my first project was to replace some of the views on our website with components from an internal library created by designers at our company. I had to change an old boxy UI to a new rounded one.

Old confusing UI- hitting the up caret actually increases the hour, which is the opposite of what you would have expected. Also, to change the time from ‘PM’ to ‘AM’, you have to click the ‘PM’ text, which is not intuitive.

New UI with rounded elements. This UI is also connected to an internal library and will receive updates as the library is updated.

Pretty simple for a starter project right? I told my Product Manager that the entire task should take no more than 15 minutes.

4 hours later on internal company chat…

jdeng [13:22:01]: hey guys, i think i found a bug in the hour dropdown. In the UI you can't select hours earlier than 4pm. cant figure out why.

The problem was the new dropdown only kinda worked, some of the time. It would fail to select a new time under specific conditions.

When I tried to select 6pm, it worked. 2pm, it went back to the default selected time of 4pm. What was going on? I had a flight to the east coast that afternoon, so I closed my laptop and made a note to look at the problem again in the evening.

Once I landed and opened up my laptop that evening, the dropdown menu seemed even more broken. Not only could I not select hours earlier than 4pm, every time I tried to select an hour prior to 10pm, the select element would default back to 4pm.

The more I looked, the more I was convinced that the code should work, but for some stupid reason, it didn’t work. I decided to checkout our website in production, to see if there was any differences. The hour dropdown element didn’t work in production either. Oh sh*@.

jdeng [21:44:15]: uhhh... i think i found a bug with the model in the hour dropdown in datetime picker in production- it doesn't select hours earlier than 10pm. This is similar to the problem I was dealing with this afternoon.

A teammate quickly responded that the bug was actually expected behavior. The dropdown was used to select the start and end times for advertisements in our app. We didn’t allow advertisers to start campaigns within 3 hours of current time, because we needed time to make sure they didn’t contain graphic language or abusive content.

So I had spent half a day chasing a bug that wasn’t bug. During my first 30 days as a software engineer I had a lot of similar embarrassing moments where I egregiously wasted time doing something stupid. But learning by experience is a necessary, if expensive, activity. So, in the hopes that this helps others, here’s what I’ve learned from my first 30 days as a professional software engineer:

1. Ask dumb questions

Before I started my job, I read this blog post by Paul Graham about how makers (i.e. coders, designers, creatives) can best make use of limited time in a day. PG argues that unlike managers, who thrive in 1 hour scheduled blocks, engineers do best by focusing on one task for long uninterrupted blocks. I came to the conclusion that to maximize my output, I should avoid meetings and put on noise-cancelling headphones and figure out how to most efficiently put the contents on my brain into a computer for 10 hours each day.

I wasn’t getting a lot done. I was at my computer for a long time each day, but I would get stuck. And because I assumed that the other engineers I was working with didn’t want to be bothered, I tried to avoid interrupting them to ask questions. A lot of times I would delay asking questions, until like right after standup when I would corner our senior front-end engineer and ask him a batch of questions.

It was this fear that cause me to follow fruitless searches for an answer (like the hour dropdown “bug”), when I could have just asked someone for answer in a couple minutes.

The lesson is that it’s impossible to know everything about a big software project on day one. It takes days, and help from the people working on the project to get caught up. It’s a necessary part of on-boarding onto a new job and people expect it.

2. Make it cheap to change your mind

When I first started, I was checking in a lot of code, but the code I submitted was heavily commented by my reviewers, who would often suggest a fundamentally different approach, causing me to dump most of my work. One module I spent two days painstakingly refactoring was deleted because we didn’t need it anymore — there was a better approach.

The senior programmers on my team seemed to be so much more productive. They didn’t have to delete their code, or waiver between two different approaches. Instead they did their analysis before writing their code, letting them change their minds while it was cheap to do so, in terms of engineering time. They made the code that they wrote actually count.

Now, I tried to do more analysis before I jump into coding a feature or refactoring existing code. I tried to come up with at least two approaches for comparison’s sake and asking in-progress code review to get feedback from team members on an approach before completely committing to it.

3. To make this a sustainable career, you have to be nice to yourself and others

When I first started, I was very hard on myself. It was a steep learning curve, and I felt that I was not contributing enough to my team. I would work until I was tired, go home and feel bad about the contribution that I had made that day.

But I think programming growth requires a lot of times that feel like plateauing, and it is counterproductive to beat yourself up about it.