What does my typical work week as a web dev like

all right so I kind of wanted to do a day in the life of a web developer video and I just want to kind of give you the an actual real life perspective of like what does a web developer do all day five days a week for eight hours a day um you know you see these videos people like getting out of bed and doing their day in the life and pouring coffee and putting their shoes on and like they literally tell you absolutely nothing about what it's like to be a web developer so now I say I work remote so my perspective is probably going to be a little bit different from other people's perspective although I think a lot of people work remote these days I've been working remote for like almost like nine years now so I just get up some days I have like 10 minutes to spare and I get on my computer and I start working right other days I get ready you know get drink some water make a coffee whatever and then I get on my computer but the the gist of like what does a web developer do every day I think the first thing I need to kind of explain is the scrum methodology so a lot of different software projects will do different things and there's agile there's waterfall there's scrum there's kanban there's a lot of different like processes you can follow as a team to try to deliver uh software our team happens to follow like kind of like a scrum type of methodology where if you don't know what this is basically every week or two you plan out a Sprint and in the Sprint you pull out some stories that you think you're going to work on or hopefully that you can finish within those two weeks and then as you finish them you get them reviewed you get them deployed and then you can mark that thing as done now we're doing kind of like a kanban mix with the scrum I think we're I would say we're kind of more doing kanban so kanban so let me take a step back because I think I just jumped ahead so now that you kind of understand what scrum is every day when we get to work you know typically you check your emails like I'll have like a bunch of spam emails and stuff it takes me like five minutes to get through them but then I also go and check our slack channel right so at work we all discuss and you know collaborate on slack which is very similar to Discord so honestly like I could just show Discord um in slack we have channels on the left some of it is for related to Tech discussion some is related to project discussion and all of our members are in the Discord channel that we can cut a message with a PM a private message or a direct message whatever you want to call it and then we also have our clients right so we work on a project where we have clients that we have to talk to and they are also part of our slack channel so if you ever have a question for the product owner who happens to be on the client side of our team then we can just go ahead and ask them a question about like hey is this is this drop down kind of the containing the correct information that you expected the drop down to have is this button doing what you'd expect it to have then we also have our ux in designers in the black as well that we collaborate with uh every day so basically again the day in the life is you look at your emails you check to see if there's any slack messages but then you typically start the day with something called a stand-up so I kind of like filled out a mock calendar like this is just all bogus stuff here but on this mock calendar typically every morning around the same time you have something called a stand-up this is a scrum um I guess you could say a ceremony or scrum meeting that happens we're basically for 15 minutes and our cases ours run a little bit longer like 30 minutes you tell everyone what you're doing um what you're working on and kind of explain to your team if there's anything that's blocking you or if you have any issues and you need help now I I honestly don't really know what the purpose of this is especially since we have slack and we can communicate via instant message I feel like this is more of an archaic thing that we did in the past when people didn't really collaborate that well and they didn't know how to talk to each other um but we still do it anyway you get together every morning you talk about what you're doing you talk about what the goals are for the quote unquote Sprint how are you going to achieve those goals and then in our um and like I said every Project's different so in our standup we actually demo daily work to our product owner right so our product owner is our client and when we work on a feature whether it's like a third of the way done or half of the way done we will show that work to the clients and the ux members and all the other developers so that we're all on the same page of what this feature does where's the status of the feature and are we on the right path right so typically Instagram like you do like a main review at the end of your Sprint which is where you share all these features and you know the stakeholders can go and see what you've implemented and what you finished but along the way like we want to get that daily rapid feedback from our product owner who really understands how the product should work and understands all the users who are using the product so we kind of do like daily demos if possible about any new features in our stand up and then what standups is done we typically go about our daily uh work right so I'm gonna talk about these other things in a bit but for our daily work basically we use something called zenhub so I have an extension set up in Chrome called zinhub and when you go to GitHub you get this tab that you have access to when you click it you get this cool little like flowchart workflow of all your stories I guess you could say so the way that scrum kind of works is you break up your work that needs to be done into something called user stories and every user story you usually just explains like what we need to do like what what does the user need and it tries to give high level bullet point overviews of like what we need to add right so for all these user stories they have different states right so typically you have all these new issues on the left where you just create new issues no one's worked on them yet no one's even really thought about them it's like it's kind of a placeholder staging area for issues but at some point the product owner takes these issues and tries to figure out which ones are the most important and he pulls them into the product backlog and typically prioritizes them with the most important or relevant meaning at the top and then going down in order uh is the the least important right it's kind of setting the stage of like what are we going to work on when we start finishing and popping stuff off the top of this stack and he'll come through he'll make sure it's all like cleaned up a little bit and everything seems fine but once he's done his work on like writing these stories which I'm not going to click on one yet but once he's like written out like what the story needs to do we will do something as a team called backlog refinement okay so here I have a meeting that's like an hour or two backlog refinement where as a team we all get together and we kind of read through these stories and we make sure that nothing is like out of the ordinary nothing is too crazy that can't be implemented sometimes you write a user story and all the developers are looking at be like no this is not going to work like this is just technologically not possible or sometimes a user story will be like uh rated like a I don't know a one or something and it's actually like really hard um and then also typically in backlog refinement I think our team does something called estimations where you basically read through this story and as a developer you kind of just get a a rough feeling of like it's just easier is this hard and you just throw a number at it right so typically we use like the Fibonacci sequence one two three five eight thirteen and if this is a really hard story like you know it's going to take like a week or two or three yeah out of 13 on it if you think it's going to take two days you add one on it now technically you're not supposed to map estimates to you know time that it takes but that's usually what it always boils down to let's be honest but just kind of don't spend too much time with estimates just throw a number out there that you think meets what the story would be okay so that's backlog refinement you don't have to do the story pointing in the backlogger if I'm in but I think you just have to do it before it gets into your Sprint and again we don't really do Sprints in our project so I'm just kind of talking about something that we don't even do but I wanted to make sure that you guys are familiar with it okay so that's backlog refinement now Sprint planning is basically the the team will go and look at the product backlog and they will pull in enough stories that the team feels comfortable with that they could finish all in a Sprint and again a Sprint is either a week or two it depends on the team and if you can finish let's say these two stories in a Sprint then that's all you put in your Sprint backlog so once you you know plan out the Sprint like you figure out what stories are you actually going to work on as a team the Sprint starts and then you and your other developers and your ux will start working on stories either together individually I don't know it's up to you and our team we like to do a lot of pair and mod programming so after we've done these meetings and whatnot and we're kind of done with stand up we will join a zoom we have a we use zoom at work where basically you can do like you know voice to voice uh webcam the webcam chat and we have breakout rooms where you can join different breakout rooms and every breakout room has a different subset of developers and you know ux people working together on one of these stories okay so that kind of the day in the life of like that's kind of it right there after stand up and after all these other meetings which I'll explain these two in a bit um we basically just work on coding and implementing okay so like in this case let's say that we started the Sprint I went ahead and grabbed this story and I wanted to work on it right so I go ahead and click on this I would sign it to myself I'd read through it and I try to understand it so this is kind of how our stories are mapped out I kind of dumbed this down but you usually start off with like a sentence or a description that kind of explains what this story is for like who it's for why is this important like why would I need a teacher to be able to find graded out submissions or non-graded submissions and then usually you have a bullet point list of acceptance criteria these are things that us developers work towards meeting and once you feel like you can check this little acceptance criteria off the story is done right so you didn't you get it you merge it into your main branch you ship it whatever in the PO and your QA team can review it along the way now something that we do on our project that we have something called a definition of done so before you can actually mark this story as done these are some things that have to be finished on the story right so the code has covered with unit tests feature is covered with integration tests code meets quality standards defined by team now typically most of these are going to be set up in CI CD and they're all automated but we do have a checkbox here just to like manually remind people that hey you need to write unit tests for your stuff you need to integration test your stuff we have a check for making sure that all new interfaces are tested with palli or ax for accessibility uh the app it has acceptable Lighthouse scores you want to make sure your app runs fast so you have all these additional things that we do which a developer might feel like you know they might forget sometimes so we have this definition of done and no story can be called done until we've done all these things right so that kind of helps not shove work out too fast and make sure that the quality control on our stories are high we believe a lot in unit testing integration testing and all types of testing so we want to make sure the stuff we write is actually solid but once you've worked on the story okay so what we typically do is you will go to vs code and you will check out some type of Branch for your feature and then you will start working on implementing the feature right so so nothing too you know out of the ordinary here it's just coding right you have to basically go back and keep reading through this story that you're trying to work on and you just Implement whatever views you'd need you implement whatever features you need to make those acceptance criteria pass write whatever tests you need write integration tests and then when you're done what we do is we make something called a pull request and by the way like I said as we do a lot of pair mod programming so we are going to zoom with a bunch of other developers usually two or three total and we are all working on the same Branch so we'll do rotation so someone will drive for 10 minutes and then we'll push the code and someone else will take over and we'll swap people's machines and since we're using Zoom we can all look at the same like screen share basically um and that's how we kind of operate so we'll be in a zoom for like a couple hours a day sometimes all day sometimes less depending if you want to go heads down and you just want to listen to music and code it's really up to you we're not really strict about a lot of this stuff but the more that you pair and the more that you knowledge share I think the better the team composition will be and the better the project will be so that's kind of what we do and then once you're done with the the feature you think you're done you need to get it deployed somewhere so the product owner in whatever QA team might have can go in tear your story apart and find all the bugs that you did not cover with unit test integration tests um additionally I'll say we have once once the story is brought into the Sprint backlog that's when you're technically supposed to have your ux and designer start looking at it in adding designs for the story right the story is supposed to be super super dumb and generic and it's not supposed to tell you how to implement it if you have acceptance criteria that says a user can click on a button a user can navigate to a page then your acceptance criteria are not written properly because now you're prescribing someone else who's not an expert in ux and design and Engineering is prescribing how the story needs to work how the feature needs to work and this is why we have a ux team their job is to figure out and talk to the actual users what would work best for the users so we try to keep these as dumb as possible so that the development team can actually start talking to users and designing and building the correct solution for the user specifically now it really depends on the team if you're a product owner and you like know you know exactly what your users will need then yeah I guess it's fine that you can start adding a couple of um sentences that kind of prescribe how the solution is but the idea is if you prescribe too many solutions here you're going to kind of tarnish the creative mindsets of your Dev team and they're not going to be able to implement it implement the best solution basically if someone tells you that they need a page you get tunnel vision all you do is you start working on a page when maybe what they needed is a modal maybe they needed a tab another tab with a tab panel maybe they needed some type of side panel you don't know the product owner doesn't know and that you know it's up to the dev team to figure that out anyway I went on a tangent there but once you're done with the story we make something called a pull request to your develop Branch or your main or your master Branch whatever you want to call it and the moment you make the pull request um this is going to run a bunch of automated checks okay so in our case I just set up one just to kind of show you but in our project we use Circle CI and GitHub actions where basically we run a bunch of tests over your code base we run linters over your changes and you can go into the GitHub actions you can look to see like Okay can this actually run npm build successfully sometimes your npm build will fail and you don't know that until you actually like make a PR because you forgot to run it locally sometimes your test will fail because you forgot to run the entire Suite locally so we have all of these checks run in circle CI and in GitHub action so that we make sure that the code is a high quality now once all your checks pass like you will have like 10 or 15 of these and you'll see a bunch of green arrows and everything will be green once everything's good we then wait for other people who haven't worked on the story to come along and hopefully review it okay so they'll come through and they'll read through all your file changes and try to understand like okay what did they change did they change something um the proper way are they doing things to our code standards Etc so kind of flipping that if it was me doing the review I'm trying to read through the code and try to just point out any high level design issues I don't like to point out any type of nitty-gritty like nitpicky stuff about like oh you should have used the four each instead of a for Loop here like I don't care I really don't care as long as everything is tested everything is like proper in terms of our clean architecture we try to follow um and there's nothing like blatantly wrong with the design that is going to bite Us in the butt when we deploys the pro those are things I'm looking for anything that's lower level and like nitpicky I'm hoping our linters will find and also whatever type of uh Security checks we have and code quality Runners that that we have set up will find as well there's a lot of things out there a lot of tools out there that you can run in your CI CD pipeline that check your code for Quality like such as like cyclomatic complexity um if you're doing things improperly in your JavaScript or if you have wrong syntaxing or yaml files Etc so I don't really care to review for that stuff I just want the higher level like is this a good solution and hopefully along the way like people are communicating in slack and talking about what they're implementing so that it's not like you know two weeks out we get this PR that has a tons of changes although we have been doing that a lot in our projects where we have big PR's with tons of changes um just the way that our project kind of operates unfortunately but the idea is you're supposed to make a bunch of these PRS for your story over and over and over again you have a bunch of small PR's People review them you get them merged in and you do continuous integration and our project we don't we don't do that unfortunately we don't really do continuous integration like we used to due to the nature of our project but once everything's good and people have reviewed and you have some reviewers check off on your story you basically merge that in and that's going to kick off another pipeline sequence where basically we take the code that was just changed and we automatically deploy that to an environment in our code base we have a Dev a staging a test uh we have like another environment for our client and then we have production so there's a bunch of different environments that we can deploy to and once the code is deployed to that environment we basically move um this story to review QA so we'll kind of just move it over and then at that point we know that the product owner should be looking at that the QA team should be looking at it they'll go through and they'll find any issues and bugs and they'll move that back to in progress if they find something wrong with it and then that process just keeps going back and forth the idea is to like hopefully not have to do that too much because if the story is written good enough there's not a bunch of thrashing back and forth because the developers can read through the story and Implement exactly what the product owner wants exactly what the users will need if the story is not written well then that's when you might get a bunch of back and forth or if the devs just Miss stuff sometimes we just miss stuff we're human right we don't always code perfectly every time but sometimes we'll miss something or Implement something incorrectly or a bug was introduced which is found and we'll just move that back to in progress and keep working on it and we keep doing that process until it's fully finished everything's done the definition of done is done and uh at that point when it's all done we will then promote that to a higher environment so for example when we did the merge we're not going to be merging to Maine we'll probably merge to like a test environment or a staging environment or a Dev environment and once it's checked off and everything's good we'll take the dev environment and we'll promote it to the higher the next higher environment such as staging your test and then when test is all good we'll promote that to another further environment such as prod which is where the users will be able to use our feature and start interacting with it now we do a lot of other stuff as well like sometimes we'll do feature Flags where we don't want the user to be able to access the feature just yet but we do want to get deployed to prod just to make sure that we got it all set up ready to go and then we can just basically go into a database and turn a Boolean from false to true and then all the users has access to that new feature again everything we do on our project is all automated with terraform and infrastructure as code we deploy everything to Amazon and we use a bunch of different Services there we use like Lambda API Gateway Cloud front Cloud we use these cloud formation we don't use that anymore we use open search we use dynamodb like we use a lot of stuff in Amazon to kind of set up the entire system so a deploy can take a little bit of time I think it takes about like 10 minutes to fully deploy the entire application the Amazon just because how many like moving Parts there are and then of course there's the quality control checks beforehand and then after we do some smoke tests so overall it takes like 30 40 minutes to do a full deploy or from start to finish but that's kind of the uh the flow so we kind of just do that every day uh for the week until we finished all of the stories that are in our Sprint now sometimes if someone's sitting around twiddling their thumbs you can start pulling in some more work which is why we kind of like the whole idea of scrum just doesn't make sense to me um because you're always gonna have people sitting there waiting for more work unless you can just grab work off the backlog right and if you want to increase your throughput then yeah you want developers just keep on grabbing off the product backlog and working on stuff but let's say you finish all the stories within the first week of a two-week Sprint like what do you guys do well you just keep bringing in more stories so I think combine makes more sense logically in my head the whole idea of scrum is basically I think to do like metrics and analytics and tracking against your team and your performance that's just what I think it is I know other people say oh no it's not for that it's you know to make a quality product and stuff now I think it's more of like tracking your team and really making sure that you're trying the best you can to figure out and solve all these stories but half the time you don't even finish them within the Sprint so it's just a big waste of time to like do all this Sprint planning for stuff that you know you're not going to finish and stuff always comes up when you're working on stories where you can't actually fully finish it you don't successfully complete all the stories in the Sprint so like what's the point you keep doing that over and over again and then what you end up doing is you just start grabbing less stuff to start your Sprint with because you want to make sure you finish all the stories in your Sprint and now you just start off with a bunch of less work and you're really just your throughput is just going down but again that was another tangent so day in the life I talked about stand up what we do every day we meet we do Sprint planning to figure out what needs to go into the Sprint if you're doing proper scrum uh we do backlog refinement that go through stories and make sure that all the developers can vote on them and give them estimates and make sure that the story seems like it's written properly and no one has any questions about anything but once you finish your Sprint and you fully deployed all your stuff to production then you have something called a Sprint demo review where basically you get into a meeting you demo off all the work that you've done to some stakeholders um you know typically you're working with a product owner but depending on the size of your company you might have a bunch of other investors or stakeholders who want to see the progress of your project and they will come every week or two weeks and they want to see those features so we'll demo those features to them they'll give us feedback and then we'll take that feedback and again just inject that back into our our cycle of making new stories refining stuff making sure we organize what it needs to be the highest priority because depending on how you do the demo and depending on the feedback you get the priority of your your items might change you might introduce a bunch of new issues you might need to grab those and put them to the highest of the backlog because if your investor is like Elon Musk and he says he wants this then that's probably going to skew what you're going to work on next and then after you've done the Sprint after you've done the demo we do something called a retro where everyone gets together and talks about their feelings and they talk about how did the last Sprint go are there any things that we could potentially improve on what were some things that went really well what were some things that we excelled in what are some things that we did not excel in and we kind of just like talk as a team to try to figure out pain points in our process to improve it from my experience to the Retro is usually hit and miss usually it's just a bunch of people trying to squeeze out ideas to work on and um kind of just a waste of time in my opinion but honestly like the Retro if you're let me take a step back and not sound so negative but the idea of the Retro is to increase uh you know psychological safety be able to talk to your team collaborate with your team be communicative if that's the word uh with your team and really like try to improve okay it's not for you know making people feel bad it's not for like trying to answer to the man of like why did you guys not get the Sprint done it's just a way to like do some introspection and be like okay these are a couple things we hit along the Sprint that really slowed us down what can we do next Sprint to make sure that we don't run into similar pitfalls that's like the only point of the Retro and also to celebrate the features that you got deployed to production right you have to kind of reward yourself for the hard work you did and that's the idea of the Retro now granted I think um I'm not really a person likes to talk about their feelings and how Stuff went like I just want to do my work but the Retro I think if your team is good and can collaborate and communicate over slack daily and do it multiple times a day and like really talk about issues the moment they arise I don't think the Retro is that important because you're on slack all day you're on Zoom all day you can talk about these issues you have stand up all day to talk about issues you have all this time after stamp to make meetings to talk about issues that you can try to resolve problems and whatnot yeah so that's kind of like the day in the life I know it's most of it's coding if you see all this white space from nine to five white space is coding time where you're basically in a zoom chatting with your other developers trying to problem solve trying to fix bugs trying to get those things deployed out um and your deployment Cycles will change depending on the project and how large-scale project you are if you're on a startup you might deploying to prod multiple times a day if you're not on a startup you're on like an Enterprise you might be deploying the prod every two weeks or something but that is the gist of what I do every day I sit down I do these same meetings every week doesn't change it's the same stuff sometimes we'll change the start times or end times of some of these meetings if we need more or less time but for the most part we do the same stuff begin the work we look at the story that we're working on we continue on it from yesterday we just keep on trying to fix it we get it deployed and then we do the same thing so that is a day in the life of a web developer and again I'm just one perspective and every team does stuff very very differently but I just wanted to kind of share that Insight with you all in case you haven't ever worked in a professional web development environment and you're not really sure what to expect so this is what you can expect if you're working on some type of scrum methodology but again this is just one perspective leave a comment below if your company or your team does something similar with the scrum and the Retro and all that and if you use any of the same tooling that I mentioned such as zenhub or if you do kanban I'm kind of interested in hearing how you guys do things and maybe it'll like enlighten me to other approaches I really like GitHub actions it's really cool so make sure you check out that if you wanted to actually like set up quality control in your code that's about it yeah if you enjoyed watching this video give me a thumbs up subscribe comment Bell who cares and then also if you want to join my Discord and ask me a question directly or talk about this further feel free to I have a Discord it's in the description of the video and you can also join if you're just stuck in react or stuck in learning how to code in JavaScript or whatever you want to kind of get some help along the way we got a lot of people in the Discord who are willing to help you out if you have any questions that you're stuck on have a good day happy coding

Channel: Web Dev Cody

Views: 164,019

Keywords: web development, programming, coding, code, learn to code, tutorial, software engineering

Id: KHX4jXDKgE4

Length: 26min 42sec (1602 seconds)

Published: Fri Nov 04 2022