One Year Dev Anniversary

Originally published at https://thomasstep.com/blog/one-year-dev-anniversary

A couple of weeks ago I hit my first anniversary of working full-time as a software developer, and I wanted to share a little bit about what I have learned this past year. I am going to separate this into meta information and more technical information. Most of what I am going to talk about was foreign to me a year ago. I wanted to recap this year mostly for myself but also to share with others so that maybe they can know what to expect during their first year.

My first topic is learning and development. If you don't want to read this entire post, at least read this paragraph. Learning and personal development are paramount. College doesn't teach you everything you need to know. I didn't go to a bootcamp, but I guarantee they don't teach you everything you need to know. Senior devs who have done this for decades don't know everything. It's fine if you don't know everything. That's why there are so many tutorials and guides. The key for me is that I learned how to learn. I learned how to read documentation. I learned how to read old code. I learned how to search Google better. I learned which devs have reputable blogs. I learned how to actually learn from a YouTube video. Then I did what I needed to do. After I got my "normal" work down, I went and learned more. I was introduced to areas in this field that I didn't know existed, you will too. If you are interested in them, go learn about them. The more you can learn, the more valuable you are. Doors will start to magically open when you take time to learn and practice. The compliment to learning and development is execution. I learn by breaking things, just not in production. I like to spend time reading about a library or concept, but if I never do anything with that knowledge, then what's the point? For me, doing something helps more than reading about it.

In addition to learning and development, I learned that learning concepts and abstractions is an extremely powerful tool. Once I learned an abstraction, the underlying code didn't matter that much anymore. Once I abstracted certain functionality out, I could build faster. I love to understand what is going on behind the curtains, but sometimes it is unnecessary. Learning AWS helped me come to this conclusion the most. There are so many details that AWS can abstract out of your way and it does a great job at it. For code, there are also great abstractions. That's pretty much all a library is.

I wish I had a timer for how much time I spent on code reviews this last year. I still remember my first pull request with my new team. I was anxious. I tested everything, then tested again, then tried to break it. Before I made the pull request I reviewed it myself. I looked for styling mistakes, typos, anything. I made changes, then reviewed it all over again. When I finally thought that there was no possible way for my first pull request to have any problems, I made the pull request. There were problems. Nothing big, but there were problems. Now when I make pull requests I limit myself to only reviewing it once. I still test and test though. I want my code to be of high quality, but I don't want to spend unnecessary hours spilling over every character. If it works well, if my tests cover happy path and edge cases, if I think it's robust enough to handle some bad input, I make the pull request. I know my teammates will probably bring something up, but that's the purpose of code reviews. Don't sweat pull requests and code reviews, just get them out there.

Before I started working full-time I remember hearing so much about Agile. To be honest, I still don't understand why devs make such a big deal about knowing Agile, following Agile, preaching Agile. All Agile is, is the way for a business to track the productivity of software development. Once there is a metric against how productive a team can be, the goal is to increase productivity. But none of that has to fall on a developer. That's the point of a manager. To me, the Jira board is just the central hub where I go find work after I finish a feature. I work as efficiently as I possibly can. Other than that, Agile does not get in the middle of a normal day of my development.

One helpful outcome of this past year is my set of processes. I have processes for everything. Starting a new feature, testing before making a PR, deploying code, creating infrastructure, everything. I also have a general process to my day, but meetings like to get in the way of that. Despite what I just said about not making Agile a big deal, one of the things I love about the Agile process is the iteration. After you get those productivity metrics, you iterate on them to make them as good as you possibly can. Taking that idea and applying it to my processes has brought me value and efficiency. I write tons of scripts to help me with this. I have some bash scripts that are only one line (although most were initially made with a more complex solution in mind) to keep me consistent. The way that I write commits, the way that I name variables, the way that I deploy and test infrastructure, all of my processes are constantly being tuned. There are tools out there to help us devs with this and I use some, but I also love custom making them. There's a beauty in making something for yourself that you can rely on every day and improve. When the tools are not there to help me though, I still have a set of processes to keep me working at maximum efficiency.

Most of the code I write on a day-to-day basis now is Javascript. I am a backend dev so I guess it would be Node. Either way, I don't know why people hate on Javascript. I remember seeing a picture of the cockpit in SpaceX's Dragon 2 using JavaScript this year and people thought that was wild. For certain applications, I think Javascript is perfectly fine. It's just a tool in a developer's toolbox. I have heard other developers say that JavaScript is a kiddy language. The hate seems unfair to me. However, I am not tied to JavaScript. I learned to program with C++. I routinely use Python for various tasks. I have used Ruby and Java before. I don't understand why some people choose to identify themselves with one language. "I am a JavaScript developer". Or "I am a senior Java dev." Do you only know one language? If I ask you to use Go are you going to shrivel up? Back to a previous point, if you learn the concepts of programming, those concepts can be applied to any language just with different syntax. I am a developer. I know how to program things. That's it. I don't only know how to program in C. If you truly know the concepts behind all of this, then the language is just a layer of abstraction on top of it. Of course, certain languages have certain nuances and features, but the basics can be carried over just about anywhere. This paragraph turned into more of a rant than a "lessons learned" excerpt. If you stuck with me through all of that, thanks. On to the next one.

One activity that I did not think I would get into or enjoy was side projects. Whether or not devs should spend their free time working on side projects seems to be up for debate. My opinion is to do them if you enjoy doing it and don't do them if you don't enjoy doing them. I have learned so much from my side projects that I do not think I would have learned from my full-time work. I have been keeping a diary of sorts for my web application side project called Elsewhere that I plan on publishing some time in the future in which I am keeping track of what I have learned and decisions I have made while building it. I have learned about frontend work, working with a PaaS like Vercel, DNS, MongoDB, and OAuth. There are numerous topics I have learned about that I know I am forgetting right now. The point is that I have been able to experiment and learn on my own without the pressure of making sure that everything is complete enough and in a state that the business would be proud of. If there is a topic I want to learn about and implement, I can. There are no rules because I'm the boss. If you are on the fence about starting a side project, I say do it. The time you spend will be well worth it.

Another topic I remember hearing a lot about before I became a full-time developer was git. I knew git, but there is so much out there about it that I was not sure I understood it. Hearing "do you know git?" was a common enough occurrence to make me think that I didn't. If I could go back and talk to myself, I would say don't worry about it. There is no reason to over complicate git. If you understand git's purpose and you run through a few tutorials you are probably good-to-go. Knowing about branches, commits, and pushes is probably enough to get you working with git. Everything after that can just be searched for when you need it. Most teams will come up with a branching strategy or use a common one like GitFlow, so there is not a reason to stress over that either.

One of the most commonly used acronyms that I had heard going into my full-time job was CI/CD. I thought it was so scary because I had never practiced it before. My first ticket was to create a Jenkins server in AWS and build out our team's CI/CD pipeline. I had a rough time with this. I had never done any of this before. I did not know AWS, I did not know Jenkins, I did not know CI/CD. I am so glad I picked up that ticket though. Knowing these kinds of software development processes is crucial to any business. Being able to get code running on top of infrastructure and getting that infrastructure and code to both automatically deploy whenever a dev pushes is super powerful. There are still people who's entire job is centered around deployments. I automated it all out. In my opinion, CI/CD is the process with which all software should be developed. If the dev team knows how to operate with a CI/CD process, software can get out the door so much quicker. From now on, I will do everything I can to set up proper pipelines from the beginning for any project I am ever a part of. Learning the CI/CD process and how to develop with it can help boost productivity a ton.

My last lesson learned this past year was learning the cloud and AWS. Last year I knew nothing about AWS. I had heard about the cloud, but I just thought it was some huge abstraction that was way over my head. I thought I would never be able to learn AWS. While learning what "the cloud" really is, was not an easy task, it was possibly my most rewarding. I highly recommend learning at least a little bit of AWS. If your project/application runs in AWS, learn how. It is an extremely rewarding journey. Knowing what I do now, I can take so much advantage of my knowledge. It seems like some devs are completely averse to getting anywhere near infrastructure. "That's just a scary word that the ops team throws around." I am now the ops team and the development team. I can start and ground zero and have a working application deployed with AWS in such a short amount of time because I understand how it all works together. Naval Ravikant said this in one of his podcasts "The robot army is already here—code lets you tell them what to do." I love this quote. AWS (and the other cloud providers) let you take control of an army of computer slaves whenever you want to. The only way to control them though is to communicate to them through writing code. If you can summon that army (control resources in AWS) and you can command that army (writing code), you can do powerful things. Most people only want to do one. Why not learn both?

If you have stuck around this long, I appreciate your attention. I have learned tons this year, and I look forward to my recap for next year. Software development is a fun game that we get to play, but we only get to play if we can keep up.