GitHub

“there are so many of these Day in the Life type videos about software engineering and they try to tell you what it's like to be a software engineer mine included but we're all kind of failing at it I wrote down everything I did as a software engineer for a month and I broke it down into categories we have coding writing documentation designing meetings networking code reviews Career Development collaborating and I also wrote down how much time I spent on each item so the first one I pushed up a PR for fixing some tests so I put this in the coding category this makes it sound like I broke the tests but the tests were disabled and originally broken and I was fixing them I did not break them but it did take me a while to figure out what they were and what they meant so then I had to spend some time creating some diagrams to understand all the different things that were happening in these tests and that took some time three hours and we put that in writing documentation because someone will look at these diagrams when they want to review some integration tests and they'll know exactly what they mean and then sometimes you have meetings where you refine requirements or you were fine the work that needs to be done you consider you know here's the list of tasks that we want to do we'll walk through each task and it'll be the tasks for the week and we'll walk through each task can say is this worth doing and then we'll also be like is this worth doing right now maybe it is worth doing but not but maybe later we'll also make sure like everyone understands the work that needs to be done and how you would implement it how you would do it so that's an hour meeting um and then sometimes you just have fun things like tea time where you network and they bring snacks and then you spend some time networking so 30 minutes for that you should probably have put we'll put hours so people know and this really isn't an order I sometimes forgot to add things and so then I would just like add it at the end like stand up we usually have that in the morning that takes like 30 minutes everyone like walks around or talks about what they did and then I reviewed every people so reviewing other people's code uh so it took about 30 minutes and I this was a PR or pull request so someone put up their code for review they added a service call so adding more data to our service to make it more sophisticated more complex I reviewed their code probably approved it a secondary index is like something you would add on a database and so some databases allow you to have them some don't add there is a use case where we need to add something like that to one of our databases and so I collaborated with another co-worker I put that in designing because we were trying to figure out like how if it wasn't available like could we like how are we gonna do that in order to access our our data in a different way then you have the one-on-one with the manager I put that in career development that's a 30 minute meeting and the career development is important because I have these coding in the park coding in the apartment imagine how many more clicks it would get if it was coding in the apartment as a senior engineer more clicks that would be great as a software engineer you will calculate results in some way so I collaborated I put this in collaborating versus um designing which was this other one this is because I was trying to understand how this part of the code base works and so we had a meeting just to talk about it and like kind of go through the code very useful highly recommend setting up meetings with your co-workers to go through things you don't understand sure you could take the week and review the code and understand it but it's just a lot faster if someone else understands it and they are nice and can explain it and that also allows you to ask questions I did review it a little bit before this meeting but um yeah it's helpful to talk to collaborate oh then this is something that sounds very difficult parallelizing pipelines it's not it was like a key word that I could use in parallel and it just and then I reformatted everything and then bam they were paralyzed so it took me one hour because you have to test it you have to set the pipeline and we put that in coding then I worked with some A co-worker on some testing they had a couple weird scenarios they needed to test and so collaborated with them on that there was something very confusing about a set of requirements or this user story so I reached out and then I also reached out to product about these analytics I wasn't sure if we were using them anymore if people still needed them we have a lot of data that we store and I'm trying to figure out how we can store less of it if we're not using it and then you stand up so this whole thing this is one week I'll take you through one week so you can see kind of and it ends like down here we'll go through maybe maybe we'll go through two weeks after designing things with the co-worker we pitched it to the tech lead of like this is how we want to do this thing with the index and then we also have some ideas on how to make data easier to read through diagrams and so we went over that with the tech lead and kind of got the feedback on it so then we can pursue it start writing the requirements for it get the rest of the team involved and then there's a lot of Legacy code that I'm working with in this code base and so I wrote some stories or some requirements same kind of thing tasks that then the team will review as a whole in a refinement meeting so I wrote this and then that took me 30 minutes front end wanted to test some things and they needed permissions and so I researched how I could give them permissions to do a certain thing and then I created more requirements and then I created more documentation on ha on this like secondary index thing how we were going to tackle this problem so that way when I present this to the team they will know what I'm talking about and they can like follow a visual I updated more tests then I created some templates for generating and sending test notifications notifications are kind of difficult to test because they're generated by the back end and the front end doesn't really make a request to request the data they're just notified and we tell them about they we notify them about something so that took a while to figure out how to do and integrate I put up a PR for that and then answered some comments about it and then I created the documentation so front end could use these scripts this one I put at the bottom deployments this is every week typically a team does deployments where you deploy all the features or all the things you worked on too the main servers the main system so customers can access it and that can take some time if it's not something there's a term cicd that gets thrown around sometimes about how if you just add the code to your GitHub repo and then you know you push it up to this one place and then automatically it goes to customers and there's no manual testing it's all automated you have a ton of tests to make sure you're not breaking anything some people do that we are not there yet and so we manually do our deployments a lot of the pieces are automated but it does take some time to manually test certain scenarios just because they're harder to create so we put in four hours for that some teams don't deploy their own code but now that a lot of Hardware is becoming virtualized meaning you as a software engineer can like go into a config file or go onto a website and like change what specs are being used for your servers and spin up your own servers and put your code on them without ever touching the hardware physical machine itself it means software Engineers are now having to do it uh versus some other team mysterious team so very important to learn about devops if you have not yeah so that was one week um I did not document Monday which is why the hours are a little low uh but if we go to this next week I think I worked more closer to 40 hours so that was good and you know there's some things I missed in there you're not going to write every single thing you do during the day like I didn't put lunch in there so looking at this next week um I'm only gonna go this is a week I think I was on call so that means I had more stuff relating to the on-call category which is like the devops category it's the category where we're deploying stuff to This Cloud to our servers getting our changes out and this a lot of times can also mean like if something goes wrong with the service like something alerts are going off or all of a sudden your main the like button on Facebook isn't working the people on call would be the ones to investigate that and if it's a really bad problem then everyone on the team would probably investigate it and stop what they're doing but the idea of on-call is you have one person in theory on call so that they can just deal with the issues and if your team's big enough you're not on call that often and I really hate being on call it's not my favorite it seems unimportant unnecessary you're not developing anything new which is why I don't like it and a lot of times when people come into to the support Channel they'll ask about something they'll say here's this bug this thing isn't working and I'll be like we already know about that issue and that that is what it's like to be on call A lot of it was like starting discussions collaborating reviewing PRS reviewing other people's code helping with deployment planning updating documentation for an initiative there's something weird that happened and so looking into that looking into more alerts creating requirements demoing stuff demoing stuff is actually a pretty it's something that's really important to do because you could be writing all this code developing all these features and if no one knows about it it's not useful setting a new TTL for records and our database there was some transforming we want to do to a response and so I had to write like Json encoding um so you can encode characters or you can unencode those characters or unescape them the wrote some code around that sometimes I'm just helping people like I helped one co-worker with some Cloud login stuff put that in the collaborating category I did some networking I went to a networking event for two hours you know wasn't really not working it was more recruiting but that's another category in here networking and then I wrote some integration tests some more coding more testing some of the stories I wrote about removing code I implemented and then just removed the code there was a question about an open 22 port on one of our servers no it's not good and so I made sure to fix that usually you might open that up for some testing um but you gotta be remembered to close the port I guess I just kept writing tests because this time I wrote I spent two hours writing more integration tests but this time for the logic and then like I found a bug in one of these tests where I was using the wrong app test annotation and it was giving me this really weird error and so I shared this in the channel and this was more interesting like I was writing all these tests and I was trying to figure out a better way to write these tests and I you created this pattern for them that uses abstraction so like I would write some of the core functionality for the feature of how you would test it and how you would import mocks and one class class and then in the other classes it was more like specific use cases of those data and so then I extended that and that step functionality and created this pattern to make sure everything was being tested correctly so we would no longer have missing integration tests and then this is kind of interesting so we have this Legacy system and we need to add a feature to it but no one's touched this code in six months and even then it was like removing a very very small thing we haven't deployed this code in a long time and so I'm working with product and with other people in order to figure out how we're going to add this one thing to the Legacy system it's a very small feature but it kind of brings up the question of should you rewrite the Legacy system are you going to continue developing on it should you moderate modernize it or will you take that tax every single time you work on it and that it's just gonna take a long time to develop stuff for it because it is a legacy system okay this time I found a there was a bug about data types and so it's a Serial serialization bug where basically we were getting data from this one service and then when we import it into our microservice we serialized the data and we basically say for each piece of data it's going to be this day data format and one of those data formats worked in our code base but for our clients where we just returned some of that data they wanted it to be a different data type and so that serialization was breaking some things so we had to fix those things but then for other clients like they didn't want that fixed and so figuring out how to create this specific solution for one client you could also just negotiate with that one client and be like you can just accept this data like stop telling us it's wrong or it's not good all the other clients like it but they you know we fixed it for them I did sell a lot of pipeline changes this week so there were certain resources that were preventing our deployments from moving as quickly as they could so we removed some things so that way when we do a hotfix when and that's when like the initial deployment doesn't work and we want to hot fix it with a different release yeah and that's pretty much it so after writing all these different things I created this other sheet that essentially breaks down all the different things with the hours included of how much time was spent in each category so here we had 27 uh it's about a good portion was spent coding was spent on the implementation basically writing tests uh so a lot of coding there writing documentation was also a really big percentage 16 I did spend a good amount designing things and then the rest of it was kind of small a little bit of career development a little bit of networking code reviews some meetings a little bit of collaborating a good portion spent looking into alerts being on call doing the deployments and then researching writing requirements this was week one and then if we look at week two pretty similar in the time spent coding and so it's like 17 oh maybe not that similar but still good chunk of the pie is spent coding a little bit less writing documentation and it was just more time spent in meetings and more time spent code reviews more time networking more time collaborating and so by cutting down some of the coding I did some more some extra stuff in the other categories but it's pretty similar and then this next week the third a little bit more time spent on call and you can do on-call activities without actually being the person on call it's really good for visibility outside of your team because you're the point of contact when something goes wrong with the service or if people have information on how the service Works to be a person people know from your team that can help solve problems is good even if you are not actively contributing to the code base which you probably already are as much as I don't like it I know it's something I should be doing and then coding another big chunk of it usually it's about a fourth of even if you look at week four it's usually about fourth 25 percent of what you do writing documentation a little bit more meetings and so I think this is more like designing stuff or with the demos and then you know not a ton of code reviews than any of these weeks probably the most was nine percent up here and then you look at week four a lot of coding not so much in the other categories a lot less collaborating some research meeting some writing more documentation this was a lot less on call not really writing any requirements but writing some documentation but yeah a lot of time was put into that blue category coding so less time was spent on everything else and so if you look at the average this is the average of what I did in a day as a software engineer and so here we have about 30 of the time you're actually coding as software engineer and then you're spending 14 of your time on call doing devops doing deployments and so it's really important to like learn that stuff if your team does do deployments so that's CI CD that's infrastructures code that's Cloud Google Cloud AWS all of that that's Docker that's containerization and then it's also like triaging and being able to like look stuff up in your logs understand your dashboards and be able to report out on them if certain issues happen to your code base or to your service and then knowing who to pull in from the other teams if you see this one alert go off like who do you talk to who do you contact about 12 in meetings and so you're not in a ton of meetings as a software engineer it says 20 because it's like 20 hours um so 20 hours over the full four weeks that I documented this but I did spend 12 hours collaborating with people so I think that's pretty good I think this data is really important so people understand that software engineering is not just coding it's a big portion of it but you also have to write the requirements sometimes about the things you want to develop and kind of make them a little bit more specific so other Engineers can easily like pick it up and do it it is a lot of writing documentation and explaining what you're doing to other co-workers and so that's kind of the collaborating the writing documentation you're also just Googling so the researching making sure you're using the right tool to solve a given problem and you're using that tool in the appropriate way in a way that's going to help your use case and be maintainable and easier to add on to or change in the future career development I should probably be doing more of and networking those should probably be a bigger pieces of the pie but if you're unhappy with your job I encourage you to look at this chart do this yourself I'll provide something down below for so it's easy for you to create this type of chart if you're unhappy with your job create this and be like yeah maybe I'm unhappy because I spent 30 percent of my time writing integration tests or I really don't like being on calm and so maybe I need to lessen figure out how to lessen this this little piece of the pie and maybe you really like collaborating so you're trying to figure out how to move stuff out of the writing and integration tests and coding category and put it into the collaborating category or the career development category or the research category if you really like doing research on various things this is also good if you have someone new joining your team and you want to explain what it's like to join this team now in order to get promoted you're probably going to need to change this graph there's the implementation phase and this is where a lot of entry-level Engineers spend their time and a lot of mid-level Engineers too in order to get to the higher levels you have to be involved in the design and the analysis processes you have to be involved in more of the software development life cycle the design and Analysis it's a lot more thoughtful you have to really think about if your solution is maintainable is it going to be easy to contribute to is it going to stand the test of time by the time you get to the implementation a lot of that has already been figured out decided for you so when you pick up a certain task to do a certain thing to add to your code base you're worried about how do I make this technology do this thing versus the more broad of our company has this problem how do we fix it or we want to make more money on this product what can we build in order to do that or maybe product has that idea and you have to tell them what microservice it should go into and how it should be integrated what design are you going to use in order to implement it will it be polling will it be asynchronous what team should actually build it and this implementation piece it's directly related to this coding piece of the pie so you may need to do less of that in order to get to the next level and and do more of the designing and the writing the requirements and unfortunately being in the meetings which which is not a great and kind of boring all right that's it for this video I hope this gave you a little bit of a better idea of what it's like to be a software engineer and I'll see you next time happy coding”