Today I'm going to walk you through a Typical Developer Day.
Now I know there's different types of companies.
But in this video, there's going to be some main concepts that most likely you're going to see in all
forms of work you do as a developer - whether it's for a company or a startup or freelance similar work
patterns are going to be seen.
And I want to take you through that because I'm assuming you're taking this course because you want
to become a developer or you want to upgrade your skills.
And it's important to know what a current workflow is and also what to expect to decide if this
is for you or not.
So let's get started.
It's 9:00 A.M. now and as you can see I've created this great diagram of myself coming into work,
It's 9:00 A.M. and I have here what I call a Trello board and I can show you right over here what it is.
Usually when you work on big projects, in order to stay organized, people have this what they call
'Kanban style' where there's a list of things To Do what people are working on.
And then there's a Done list.
So usually in the morning you come in and the first thing you want to do is you want to make sure that
any changes that have been made while you were home or a night maybe have teams that are overseas that
have worked while you were sleeping.
Well as you know we want to always go to
git checkout master
And you should know how this works by now.
If not make sure you check out the previous section.
I would do something like git pull to make sure that everything is up to date.
All right.
And now I have everything up to date.
Do you also want to see if there's anything that's maybe you're still working on that hasn't been resolved?
If you remember from previous videos, I have a couple of pull requests and one of the ones was the conflict
one
and we remember that -well, this branch that I was working on Marcy told me that we don't really need
that change so there's no files changed.
I can clean up what I've been working on by just closing my pull requests I'm going to delete this branch
so that now going back to my workflow I'll just have master that I'm working on.
Everything is up to date.
All right so pretty good.
Maybe I'll move this conflict branch that I was working on.
I'll just move it to done and say that you know I'm -I'm done with it.
So the team knows that I am no longer working on this branch. 9:00 A.M. is done.
And 10:00 A.M. rolls around and I have over here usually what happens is something called a stand up
where team members and everybody that's involved in a project or whatever you're working on meets to
get everybody's updates and usually everybody stands around and you see over here that there is an
SM that is usually a scrum master or a manager or a director that usually organizes the meeting and
takes the lead.
And what we all do is just say "hey this is what we did yesterday."
"This is where we're going to do today."
Or maybe if you're blocked on something and you're having an issue maybe you can ask some team members
and usually in this meeting you also have this scary looking person which is actually the PO which
is the product owner.
So that is anybody that it could be a client that has vested interests that is money on the line for
this project to be built.
It could be your your CEO it could be whoever is owning the product whoever wants to make sure that
their product gets finished and gets finished on time but is also built properly.
That's the product.
So you have a quick stand up meeting and usually around 10:30.
You'll go back to work you'll be working on something like bugs or new features and the way you do that
is well you go back to a board like this and see what's on the To Do list.
And usually they're all small chunks and you know let's say I want to update the read me old drag that
in here and to let everybody know that I am working on the updating the reading.
You know if I'm updating the read me I'll do something like 'git branch update-readme' and I'll just
git checkout that branch and I'll start to work on that feature or bug whatever it is.
All right and let's say that -you know, I have had my lunch.
I'm feeling very happy I got a lot of work done and I actually finished my readme task, well in that
case I will actually submit a PR or a pull request which we've seen in previous videos where I'll do
the classic 'git add' command then 'git commit' then I'll be 'git push'
up to github all my changes and then what we usually tend to do is if we go back to github
we'll have people that like yourself or other team members that see that.
There's a couple of pull requests Let's review a pull request so that is code that maybe yourself or
others have done and I see over here that I have a nice little person who came and refactored our background
generator. So we would view the file changes and we see here that they have fixed a bunch of our background
scripts to include the new ES6 syntax which is very very nice.
We review everything, if we want to comment that's great.
But you know what, these changes look really good.
So I'm going to say Approve, do the @ sign and
"Thank you for this-
-These changes.
It looks great. Merging now."
So I've submitted my review
and everything looks good.
If there's any issues then I can let them know that we need a couple more things fixed but everything
looks good here.
Some companies will pass it off to something called QA with that does Quality Analysis essentially making
sure that the changes that we've implemented doesn't affect our web app.
It still works on the phone.
It still works on all the browsers and making sure that our features or bugs are fixed.
So that usually happens and if everything passes then woohoo, our PR gets approved by our team.
The QA says Yep everything's looks good.
You're happy with what you've done and your PR and then you can finally merge in to master and when
that's done we go back to the Trello board and we can just say that Update the Readme is done.
The team knows that you're all good to go and it all starts back up the next day where you get in, make
sure that there's nothing outstanding due.
You go to the meeting.
You look through that To Dos, grab a piece of feature or a bug that needs working on.
And you start working on it.
And I know it doesn't sound very exciting from the way that I'm describing it right now, but
it is a ton of fun.
Whether you're building a product yourself or you're the only owner you still are using these techniques
to just keep yourself accountable making sure that tasks are getting done because being a web developer
is all about breaking up big tasks like building Netflix into small manageable chunks and each day you're
just working one chunk at a time to write some JavaScript,
Maybe some CSS, maybe some HTML, to build this one great big product.
And that's it.
That's a typical day of a web developer.
I know it's always good to know why you're getting yourself into some of the tools that companies use
and some of the workflows.
So hopefully this video was useful to you.
I'll see you in the next one, byebye.