A Day in the Life…

I’ve had a couple of people recently ask me what it is like to truly work as a full stack software engineer. Like every person in tech talking to the non-techies they’ve asked me if I hack things, to which I respond no (and if you keep asking then don’t be alarmed when your social media accounts start posting about lucrative bitcoin opportunities). I remember not too long ago when I too had no clue how tech worked at all, and I was another person using the software without actually understanding what was going on behind the scenes. As I hope to have explained in my last post, we talked about the frontend and backend and how all of that works (or doesn’t) to present the user with the online experiences they know and love (or don’t). With the “what are you even talking about” out of the way, I can start talking about the daily routine of a software engineer (from my experience of course), explaining the day-to-day of a coder and all the fun challenges that come with it.

`Life’s a marathon, not a ${wordWeAreTalkingAboutNext}`

You guessed it! Sprint. “But Liam, what does software engineering have to do with this ‘sprint’?” I hear you ask, and to this I answer “I’m not sure, ask the product manager”. If you are involved in tech in any capacity I’m almost positive you have heard of sprints. Back in the day when a company wanted to build some software, the people in charge would walk in and say “hey, we have an idea for this software and need this huge thing built, we are starting at the beginning and ending when it’s fully built, any questions?” It started with the idea of what the company wanted the software to do, then was given to whomever to design it, followed by the coders wrote it up, tested it, and then kept it going with maintenance. This is called the Waterfall method. Some people still like it, however I personally don’t and most tech companies that I have heard of prefer the other approach: Agile.

Looking at the picture above, I think you can get the gist of how Agile is different from Waterfall. The whole process can be summarized as so: While Waterfall is a top-down (oh..I get it now) and sequential approach, Agile is a cyclical and fast-paced approach aiming at getting as many immediately-needed tasks done as possible in a short period of time. Waterfall is similar to a marathon in the sense that while building, you know the end is somewhere pretty far away and you should try to not die from exhaustion trying to get there. Agile, however, breaks up the long building process and organizes the pieces into much smaller cycles of planning, defining, designing, testing, and deployment. Some companies try to split the work into two-week periods, some do three, and keep in mind that the length can change depending on what you’re trying to do. Since Agile focuses on short bursts of efficient speed rather than a much longer, linear development, they refer to these short bursts as “sprints”! So you can think of Waterfall like a marathon, and Agile like a….really fast run. Sprint planning is essential when working on a project with the team, because the team needs to find the sweet spot between not enough work and too much work. If you take on too much work, you can feel like you’re drowning and failing despite the progress you may have made. Conversely, if you take on too little work, you’re letting other teams down since they are relying on you to do your part. The goal is for it to be challenging yet rewarding, and every team’s metric is different. The important thing is that the team finds a place where they feel challenged, but also like they can manage the work and can feel proud of their work after the sprint is done. This takes some time as you have to calibrate your efficiency as a team, so if you are currently transitioning to this, please be patient!

The reason I started with sprints is because this is the groundwork for what you are going to work on throughout your time. Proper sprint planning means including the team in the discussions, as they are the ones who know if they can do whatever is being promised in however long they are given. As a software engineer, this is a very cool perk (in my opinion) as you can have a say in regards to what you are going to be working on, as well as connect with other members of the team you don’t interact with as frequently. Also, learning to efficiently plan and manage efficiency is a great tool that everyone can benefit from, so the more people who can contribute, the better the team will be.

Engineering!

Onto the fun part! Engineering is the main part of being a software engineer and it is definitely a fulfilling job. I personally think that it’s really cool that someone can talk about an idea that they have and someone could figure out how to write code to make that a reality. Like the first people who looked at a river and wished there was a way to walk across it, software engineering is the bridge (I had to, sorry) between ideas and reality in this day and age. But how does this translate to the average day of a coder?

Remember the sprints we talked about earlier? That establishes the game plan for the next couple of weeks. For example if we wanted to build a messaging system, it would start with the requirements of “we want the ability to send messages from one person to another” (hopefully with more detail). From there, a designer would make a mock of what they want it to look like, and pass it to the software engineer(s). The engineers would then be responsible not only for implementing the code to send the message, save the message, etc., but also writing the code to make an exact copy of the design provided by the designer! They take the ideas that other people have come up with, and bring it to life.

“But how does code get written? Do you just write sentences?”. The answer is no, unless you are using Python. There are different programming languages, and they are used for different things. A common saying you hear in tech is “the right tool for the job”, but what does that mean? It means that each language has its strengths and weaknesses, and depending on what you’re trying to do, you should figure out what language best suits your needs. This example will hopefully shed some more light on the concept: You are a businessperson, and you have to come up with the best strategy for selling something to the potential buyer. You think the typical compliments and negotiating tactics you use would work well, so you try them out but to no avail. You are then made aware that the person you are talking to is located in Japan. Hopefully they know some English, but wouldn’t it be better if you did the same thing you were doing, just using a different language to be more effective? In that case, I’d recommend using a translator who can speak Japanese to help with your negotiations, since it seems like the appropriate tool for the job. Picking a language is the same concept. You can pretty much do the same thing in every language, it’s only written differently. However if you wanted to write a video game that needs to be incredibly fast and efficient to make sure it is playable and decided to use the slow powerhouse language that can handle massive amounts of data, you probably won’t have a fun time with that. If you wanted to handle massive amounts of data that needs to be carved up and processed like a McDonald’s factory, and decided to go with the coding equivalent of a scalpel, you’re not going to have a fun time with that either.

Picking a language is hard to do until you have some experience. When you learn one language and get the logic under your belt, learning other ones becomes a lot easier to do. Like I said before, the logic is all the same, it’s just how you write it that’s different. After you learn your second language, or maybe third, you start to see that there are things that are easier and harder to do with each. After more time you learn the intricacies of each language, and can make a better decision about which one to use. Normally when you join a company, however, they have already chosen a language and you will use that one, since it is a lot of work to upend everything you’ve already done and rewrite it in another language. It would be terrible if you just wrote a 100-page paper on Nietzsche, and then your professor told you it would be better to translate that into German because philosophy papers written in German are “in” right now.

No matter what language you or your company has decided to code in, you have a lot of freedom in terms of how you write the code. And as you learn how to write better code throughout the projects you work on, you find new ways of improving code you’ve already written! Some piece of the code that you write that took you 200 lines the first time could be reduced to 50, and then later on maybe you could figure out how to write it in 10. Software engineering is a very fulfilling job as you are actively benchmarking your process every time you write, and you can look back and see how much better you’re getting when you’re eventually tasked with fixing some buggy code you wrote.

The next question is probably “But how do you figure out how to get better? Do you ask your senior developers for help?”. Depending on the structure of your company, sometimes you can, but they are normally busy doing more complicated work as they have a lot of time and experience under their belts. Going to the senior dev can be good if you’ve hit a wall, but there are other things you can do first. The great thing about working on technology is that you can use technology to help you answer your questions! The internet probably contains the answer you’re looking for, because someone has most likely run into the same problem you are on currently. With this knowledge in hand, there are two places to go: the documentation and Stack Overflow! When writing code, you always use other code that’s been written by other people and packaged for public use. With the publication of the package, hopefully the people have written documentation on how to use it. You can use the documentation to see how the pieces are written and how they all come together. This is a lifesaver when using new code for a new project, and really helps you learn about how the package uses code in order to solve what it is trying to do. Reading through it can teach you a lot, especially if you are new to using the language. Stack Overflow is another tool you can use. If you’re familiar with Reddit, it works like that. If not, think of it as a message board where people can post questions, ranging from vague topics to specific errors returned from the computer, and other people can respond with solutions. Every single programmer uses Stack Overflow, and if you were to skip this suggestion and ask your senior developer, chances are if they didn’t know the answer they would go on Stack Overflow to find it. It’s a great crowdsourced repository of questions and answers, and it helps to become familiar with how to navigate it.

Bugs!

“Computers are stupid. They do exactly what you tell them to do.”

– The computer I told to write this

I’m sure everyone has heard of bugs before. If you haven’t, the concept is pretty simple: it’s something unexpected that happens in your code. Every company that writes software has bugs, and the money comes in when they’re small enough for people not to notice too often. I recently came across a bug when streaming a movie the other day, which I can use as an example. A common feature when watching a show online is that moving the mouse causes the options to pause, play, or skip appear over the screen (thanks frontend!) and then disappear after a couple of seconds so you can watch the show. When I paused the show and pressed play, however, the buttons didn’t go away! Instead of getting on the phone to call my lawyer for a damages claim, I decided to figure out how I could fix it. I asked myself “what is the normal behavior of these buttons?” and came to the conclusion “these buttons are to pause and resume a show”. So when they didn’t go away the first time, what did I do? I pressed pause and play again and it worked! While I’m waiting for the job offer from this company to come through, I’ll tell you a bit more about how bugs fit into the life of a software engineer.

The term “bug” actually has a really cool history. You can read more about it here, but back in the day when computers were a giant machine that took up a whole room, the computer scientists kept running into errors. Upon further inspection, Grace Hopper found a literal bug in the machine causing the errors! The term has stuck around to convey the idea of unexpected functionality in code despite the removal of actual insects from the machinery (I’d still carry bug spray when going on Facebook though).

So where do bugs show up when you’re working as a software engineer? Everywhere! Every piece of code you write will probably do something unexpected if used in a way that was unintended or given the wrong data. We can use this for example: You’re at a restaurant and the waiter asks if you would like some pepper on your food, and to say “when”. After 15 minutes, and your plate has disappeared into the pile of pepper, you realize that the waiter should probably have been told what to do when the person never says “when”. The waiter would probably also be lost if you said “who what where why” when you’ve had enough. The important part is making sure the code you write is both limited in what it will react to in the first place, and also that it can properly handle unexpected behavior throughout the execution of the code. For example, had the manager said “if the person doesn’t say when to stop, stop after 20 seconds” the first scenario could have been avoided. Had the manager said “as soon as they say anything, stop giving them pepper” then the second scenario could have been avoided. But what if they don’t say anything, and instead just make noises? Technically they haven’t said anything, so the waiter would keep peppering. If the person said “that’s enough, thanks”, what do you think would happen? The waiter would keep going, because the person hasn’t said “anything” yet. I hope this example highlights how specific you have to be when creating the logic for your code.

Dealing with bugs is a form of engineering: engineering a solution to the solution you have already created. Since computers cannot think for themselves, they do exactly what you tell them to, not what you meant them to. That is the key takeaway from dealing with bugs. Rather than going ahead and starting to write the code, the engineer needs to think about what they are trying to solve and come up with a way that both provides a solution to the problem and effectively handles any issues that may arise. A lot of engineers (myself included) find bugs to be quite irksome, as we all wish the code could have just worked in the first place. But being presented with code that doesn’t work, especially when yelling at the screen saying that it should work (we’ve all been there, let’s be honest), is one of the best ways to learn as it is showing the engineer that they need to think everything through. And once they learn how to avoid that bug, they will be much more inclined to write future code in a way that prevents that error from happening again.