by Austin Tackaberry
What I’ve learned six months into my first job as a self-taught software engineer
In this post, I will share my experiences and give advice now that I am six months into my first job as a self-taught software engineer.
Note that this post will not be focused on how to get a software engineering job. Check out my previous post, How I went from Newbie to Software Engineer in 9 months for more information on that.
Note also that this is just one data point regarding my experiences with one company!
I remember when I was looking for a job and was absorbing a ton of reading materials regarding the tech industry, learning programming, and success stories, my main focus was finding out how to get a job. But I was always a little curious what it was like once you actually got the job. The purpose of this post is to try to answer some of those questions.
What was the first day, first week, first month like? Are there skills to learn that might not help for the interview but would help once you started working? Even if I get a job, how would I know that I’ll be able to do it and do it well?
I work as a software engineer at a company called Human API in San Mateo, CA. It is a healthcare tech startup with ~35 employees that focuses mainly on the user-centered exchange of healthcare data. I was hired as a software engineer focusing on the front end, using technologies such as React, Redux, and Sass.
The first day was pretty surreal. I had dreamed about working as a software engineer for a while, and it kind of still felt like a dream on the first day. There was an ice breaker treasure hunt for me to do that involved talking with everyone in the office.
I was given a “New Hire Success Plan” that included things such as:
- First day - get laptop configured, go to welcome lunch
- Week 1 - be able to draw diagrams of how the products work, get familiar with agile, complete onboarding
- Week 2 - build something using our public API, fix a bug, add an enhancement
- Month 1 - start taking ownership over my part of the product
- Quarter 1 - take ownership over my part of the product
But mostly, as you might expect, the first day involved getting my laptop set up with the proper environment.
The first week was mostly more of the same. Still getting all of my accounts set up correctly, finishing reading through onboarding documents, etc.
It felt so weird coding during the day on a weekday! I was also still getting used to the typical Bay Area startup perks. My tech lead kept calling me the “React expert” because I was hired as the main frontend person on that particular team. I’m not sure if that’s what he thought I was or if he was just trying to set the bar high. In any case, I tried to roll with it.
I was also learning about the agile process. We had daily 15 min “stand up” meetings where everyone would stand and talk about what they were working on, and if their work was “blocked” by anyone.
That was something I was semi-worried about when I was applying to jobs:
Is it bad if I don’t know agile, scrum, velocity, product increment, sprint, retro…?
In my opinion, you don’t need to know what any of those things mean before you start your job. It might help in an interview because the interviewer might subconsciously think you are more credible if you do, but in reality, you could learn it in less than a day on the job.
By this point I was doing some real development and actually contributing to the team. I was learning how to work with the designer, product management, and other software engineers. I started working from home on occasion which was awesome. I found that working from home occasionally made me way more productive in general. No one seemed to care when you came into the office or when you left which was a stark difference from my previous company. I also had WAY fewer meetings than I did in my previous job.
I hadn’t used Sass before, so I watched some videos and read some docs. It’s pretty similar to CSS, so that wasn’t a big deal. The project I was working on was fairly new, so there wasn’t a strict, standardized git workflow. Honestly, at that stage of the product, it was surprisingly similar to the way I would develop my portfolio projects. There was another thing I was semi-worried about…
Do I know git enough? What if there is some complicated git workflow, and I mess everything up?
I do think it is valuable to get some experience using git on a team. Join a local meetup and make a project, go to a hackathon, contribute to open source. Get familiar with pull, push, merge, rebase. Go through the pain of dealing with merge conflicts. Do some reading on best practices for git workflows.
You could learn on the job, but you’ll be far more effective if you come in having experience with common git workflows.
Another thing I ran into a lot during the first month was trying to find out what I should do when I got stuck. Should I ask someone or struggle through it?
One of the things I was really looking forward to about getting paid to code was having other people around who are smarter and know more than I do, so that I could get help when I was stuck.
When you are learning on your own, you don’t have that luxury, and you have to decide whether you should keep banging your head against the wall in front of you or look for a new wall to bang your head against.
And then I realized…teaching myself how to code gave me a valuable skill. It is a skill to know how long to bang your head against the wall before moving on, finding a workaround or asking someone else. If you always had a room of mentors around to help you with every problem, you would never be forced to go through the painful struggle of deciding what to do next when you are stuck.
Your mindset should NOT be…
Wow, look at this! I have a room of software engineers who can help me!
It should be more like…
I am going to make an active effort to figure this out on my own, and if I need to ask for help, I will tell that person what I tried to do that didn’t work.
By now I have become comfortable with the code, my team, and the company in general. We have had a company picnic, an event at a brewery after a product release, a game night where everyone brought their favorite video games to play, we had the world cup playing at the office, and many more social events. There have been multiple stressful product increment demos as well.
I have learned from a lot of smart people, tried to be vocal within the company, sharing my opinions about how I think we should do certain things. I have been on the other side of technical interviews, been involved with multiple product releases. I also started to get more involved with the backend as that is ultimately what I enjoy the most.
Estimating how long it takes to add features/fix bugs is extremely difficult and it feels like I’m not getting better at it.
I think the most difficult and challenging (yet also fun and rewarding) part of the job is design and architecture. When there is a feature to add, there are a number of ways to do it that instantly pop into my head, but figuring out the best way to do it given the time constraints is very difficult.
Sometimes certain feature additions require many discussions with many people and other times you just have to make a decision yourself even if you can’t think of a good solution because it isn’t worth the time. Then you look at your code 3 months later like:
In this section, I’ve included frequently asked questions that new starters may have.
I have been putting all this effort into learning how to program…How will I know that I will like working as a software engineer?
If you like learning to code, then I think you will like working as a software engineer. That doesn’t mean that all software engineering jobs are great, or that you will love them all. Even if you get a great software engineering job, that doesn’t mean that you will always love every aspect of it.
But if you like building new things, refactoring ugly code, finally fixing a bug that has been bugging you for awhile, you should be good. If you enjoy the struggle of learning to code, then I think software engineering is for you.
Even if I get a job, how can I know that I’ll be able to do it and do it well?
For some reason, I always thought that there was this massive difference between someone who was getting paid to code and me (someone who was not getting paid to code). So naturally, this question popped into my head a lot.
I agree with the cliche advice, “If they hired you, then you are ready to do the job”. I am a firm believer in taking things one step at a time. If you don’t have a job, focus on how to get a job. Once you get a job, then you can focus on doing what you need to do to succeed at that job.
If you are simultaneously worried about getting a job AND your hypothetical performance at the hypothetical job, then you will be adding unnecessary stress and worry to your life.
Are there skills to learn that might not help for the interview but would help once you started working?
I will reiterate and say that my main answer to this question is not to worry about your hypothetical job until it is no longer hypothetical.
However, if you won’t take no for an answer, then I would recommend what I mentioned earlier. Try to work on a project with a team and choose a best practice git workflow.
I’m sure you can find plenty of articles about it if you google “common git workflows”. I don’t have a whole lot of additional advice here other than basic soft skill stuff. Try to get along with your team and everyone in the company from day 1.
What is the main difference between building a project on your own and working on a team at a startup?
It really depends on how mature the product is that you are working on. Most of the differences come with working on a big product that will be used by a lot of people. Here are a few things that you may have not thought about when building your side projects versus working on a production level app in a startup:
- Security - Certainly this isn’t something you have to worry about with your own side projects if you don’t want to. When you are working on a product that is used by many people, web security is extremely important. I wrote an intro to web security that explains web security basics such as CSP, HTTPS, CORS, etc.
- Browser compatibility - You might have to support versions of IE which means you might not be able to use all the fancy latest CSS and might run into some JS problems. With this, comes cross-browser testing which is its own beast.
- Analytics - You might use something like Google Analytics or Mixpanel to get an understanding of conversion and product usage.
- Testing - You certainly don’t have to deal with writing tests in your own projects if you don’t want to. However, testing is essential to writing good code. When learning to code, the longer you wait to start writing tests, the harder it is to make it a habit.
- Blockers - You might rely on someone to build something before you can build your feature. So you might have to think about ways to work around this. If you are a frontend engineer and the API isn’t quite ready yet, you might have to make a mock API so that you aren’t blocked from working on the UI.
- Maintainability - Certainly you want to write good code for your side projects, but the stakes aren’t too high. You probably won’t be maintaining it in a year from now, so who cares if it has no comments and is in one massive file right? When you are on a team, you want a low barrier to contribution. That is, when a new person joins, you want them to be able to read the docs, see the code, and be able to start contributing quickly. If the code is difficult to understand and read, then it will not only take longer for someone to make contributions, but it will also be harder to add features without adding a considerable amount of tech debt.
As I have said multiple times, I don’t think knowing all of this stuff is important before you get a software engineering job. I do think there is value in knowing about it, whether that is because you don’t know if you will like working as a software engineer, or if you just like knowing what to expect.
Also, unfortunately, there are certain interviewers that will ask you some of this stuff. Maybe because they don’t know any better, maybe because they are hiring for a more senior position. It is my opinion that these things can all be learned on the job if you have a solid foundation.