“I don’t know if I’m smart enough to do this, but I will give it absolutely everything I have” are the words I constantly remember telling myself in the first few months of starting my job as a software engineer. After graduating from college, I started full-time work as a programmer only 2 weeks later.

I was scared by how much I didn’t know. My education had taught me all of the basics I needed to know how to code, but I felt extremely unprepared for what developing software in the field would look like. I was used to the extent of what I needed to know being a few chapters of a textbook. I was used to writing code that passed a set of test cases or checked boxes on a rubric and then would never be touched again.

I quickly learned 2 important things after starting my software engineering journey:

 1. You can never know everything about software engineering. You have to constantly be learning new things.

 2. Code is constantly changing. The real value of the code you write is that it is readable and will be easy to change in the future.

I have had no shortage of jobs throughout my life. I’ve been working consistently since I was 16. At every other job I have had, I always remember eventually getting to a point where I knew just about everything I would need to know to do my job without having to ask anyone questions. Being a software engineer is different from all of the other jobs I have had in that way: there is no way you can know everything about how to do your job. You are faced with new problems almost every day. Your whole job is solving problems. You can become better at coming up with solutions to them, but at the end of the day, you will be facing new issues constantly. Not to mention, new industry standards and tools are being developed and released daily.

At first, I found myself constantly questioning if I actually deserved to be a software engineer. I was embarrassed that I didn’t know the answers to questions off the top of my head or that the first solution I came up with was not the best one to solve a problem. But once I acknowledged that nobody writes code and creates software without trial and error, I felt that shame melt away. I realized that my worth is not knowing how to do everything correctly the first time, but my ability to figure out what is going wrong and how to fix it. I have also found that I am getting faster and faster at figuring out a good solution with the more problems I solve.

The second hard lesson I learned was that software is constantly changing. The solution you are using to solve a problem right now may not be the best solution available in 5 years. You have to make sure that when (not if) your code needs to be changed, the person doing so can read what you have written and change parts of it as easily as possible.

I didn’t realize this until I was thrown into a large new codebase and asked to fix bugs or add/remove features. Sometimes it felt easy, and other times it was extremely difficult. The difference wasn’t the functionality of the code, since it all (mostly) worked. It was about how it was organized. Code with good comments and the functionality properly separated out was eons easier to work with than parts of the code without these things. It was way easier to change the way we accomplish some task if the logic that accomplishes that task is separated out into its own functions or objects instead of that task’s logic being intermixed into the logic of other tasks. After suffering through my first large code refactoring, I realized that I wanted to make that process as easy as possible for the next person who has to do it.

When I first started at my job, I found myself getting many code review comments asking why I was organizing my code in a certain way or why there were so few comments explaining why I made the choices I did. I realized that the readability and maintainability of my code highly contributes to the value it brings. Even if the code I create works perfectly fine for the time being, if it is impossible for someone else to understand and change in the future, it will be useless.

All of this to say, I’ve learned so much in my first year as a programmer. I was inspired to start this blog to encourage myself to continue learning and growing as a developer. I hope this was relatable and helpful to some, and I can’t wait to start contributing more to this site.