First off, the day has to start with coffee. Strong coffee. Some would argue even the strongest coffee. And that's because you know what's coming. You have a day full of daily standup's, meetings, pull requests and bugs galore to fix. The coffee helps.
I've worked at companies where you had to be at your seat for the 8am meeting every single day. This typically meant getting up at the crack of dawn to fight through city traffic. But I've also worked at companies who had no such policies, and where coming in at 12pm was equally as welcomed as coming in at 5am. Find those companies.
Whatever your in-out times might be though, the day typically starts the same way.
Daily standup
If you can manage to win the battle on the highways, then you'll make it just in time for the morning standup meeting. Standing is optional, but participation is typically mandatory. But much of that will depend on your manager, or scrum master really.
Daily standup's are where you and your team let each other know what you are individually working on. This is also the time to bring up any issues or challenges that you are facing in your project. Though no one ever does. Typically, everyone essentially says the same thing followed by "it'll be ready later this week". Whether it is or isn't ready by end of week, is debatable.
Not to say that daily standup's don't have a place in software engineering, because they do. But they function much better in highly tight-knit teams who essentially work on the same codebase. Many times though, managers will put on the scrum master hat and attempt to take a crack at this project management style on highly distributed teams that don't work on the same projects. In which case, you won't find these standing sessions very enlightening.
If you work in a non-agile, non-scrum office environment though, then there's a good chance that you won't have to deal with these things. In which case, you might be able to sleep in after your late night of multiplayer gaming sessions.
Replying to emails
That's right. Emails. No coding just yet like the YouTube videos might suggest. Working on real-world projects typically means that you are just one part of a whole team of people. That could include other developers, project managers, product managers, designers and QA testers. And they all essentially rely on you to help them do their jobs.
Most of those people have no idea how your application works on a technical level. But you do. You're the full-stack person who has studied the website from top to bottom.
Most emails are essentially "Can we do this?" in nature. And they take a while to get through, because often times, you don't really know the answer yourself.
"Can we? Maybe?". Coming up with a response often times involves diving into the code and running test scripts, querying data and then converting the technical speak into human language.
This can often times take a few hours away from the morning, but it's an important part of any web developers life. If the business team has no recommendations or projects lined up, then you don't really have any work to do either. So ensuring that they have everything that they need is crucial for growth.
Getting the latest code
After the emails are sent for the morning (they'll be back later), it's time to code, kind of. The first thing one typically does, particularly when working with a team, is to grab the latest code changes from the repo.
And this isn't always a 5-minute click and go kind of task. Sometimes, things go south after getting latest. Your code might have compiled last night, but right now, there's random configuration errors littering the console and you can't make any sense of it.
You ask your teammates if anything major was changed, and everyone assures you that nothing was added that could cause such errors. Well. You have to keep looking now.
This is where that morning coffee really makes the most sense. You can either rollback your changes to the previous version, though you will inevitably have to fix the issue, or you can run through each error message one at a time looking for the culprit.
While this isn't a daily occurrence, it does happen more often than you would think. It's just another part of working with a team on a rapidly changing project.
Meetings and meetings
The title of this article specifically mentioned "full-stack" developer for a reason. And that's because a lead, senior or full-stack developer typically has to wear many many hats at a company. Everything from database reporting to designing the UI/UX is possible.
That typically means more meetings. If you are meeting with a member of the business team, then generating and discussing reports are frequent in nature. That usually means working with various database reporting tools. If you are working on the UI/UX, then meeting with the designer might be in order in order to finalize a design.
You might think that this is a part of the above mentioned morning standup. But I assure you it is not. The morning standup is mainly for the development team that work on the same project and that need to keep each other informed on a daily basis.
Meetings in general can happen on a whim at your cubicle or at someone else's desk on another floor or in the fancy meeting room with the high tech projector. On average you are looking to spend at least an hour on these meetings.
Debugging
On any given day, there's probably a giant list of bugs or issues queued up to fixed at some point in time. Some of those, are higher priority than others. And they demand your attention.
Debugging is a huge part of the job for a web developer. Particularly on a larger and more established website. There are more features that could potentially break and there is much more data coming in to the database around the clock.
What's a typical debugging session look like, you might ask?
More often than not, a bug is reported by someone on the business team or the QA team. Perhaps they visited the homepage and the newsletter sign up fails to load. It might work fine for you and it might work fine for the developer next to you. But to someone on the 3rd floor, it's broken and it's high priority to fix.
Alot of times debugging really means investigating. You can't fix what you don't know is broken for a fact. Technically, that's referred to as reproducibility. You do what you can in order to reproduce this error on your local machine. This could take seconds, or it could take hours depending on the nature of the bug.
This isn't an every day kind of task, but do expect that you will be doing similar in nature at least a few times per week.
Refactoring code
If you work in an agile development environment where specifications change daily and features are added and removed on a whim, then you will inevitably end up polluting the codebase to some extent.
But don't worry, this isn't a bad thing. It's pretty much expected for the most part. It's a part of the whole agile workflow. But that means that at some point in the week, you will have to dive in to the code and clean up whatever mess was left behind.
You might have to delete code, or to modularize code or maybe even just comment on anything that isn't clear to the reader.
I personally enjoy refactoring. Even this blog requires weekly refactoring sessions as much of the development indeed follows a very agile methodology.
Usually, there isn't a task item generated for this process and it sort of happens at the discretion of the developer working on the particular project. It's sort of an unspoken rule though, because not doing it can lead to disaster down the line.
Writing new code
If there is still time in the day and you are up for it, then now's the time to really get down and write some new code, assuming that you have a new feature that needs implementing that is.
Tasks at this level usually require multiple days of consistent work, along with meetings, code reviews and demo's. And before any of that, high levels of planning.
It's not like in the movies at all. Remember, a company is paying you to maintain a website. Essentially you are getting paid to do pretty much everything I listed in this article, not just write some code.
Going to a meeting and debugging a newsletter form error is equally as important as building a new feature or a new page.
And that's pretty much a typical day as a full-stack web developer. It's busy, it's involved, it's more social than many would think and it probably involves multiple cups of coffee throughout the day to keep you going.