Do you want to find out what it’s like to be a coder? Here’s a detailed description of my daily routine as a Laravel (PHP)/VueJS (JavaScript) web developer.
Stand Up
Stand up? I did stand up sometimes since I had a standing desk, but this standup is the name of a little meeting we had every day.
Every day, first thing in the morning, the web development team had a standup. Each person gave a quick little summary of what they did the previous day and what they planned to do on that current day.
Thankfully, not every company has these standup meetings, but the one that I work for did. Standups aren’t my favorite thing, but they are a good time to ask questions and set up meetings for the day, a necessary evil, I guess.
Tickets
If I don’t have any tickets assigned to me, I’ll look for a ticket that hasn’t been taken and assign it to myself. A ticket is basically something to do. It can be a small task or a fairly large project. I like the bigger tickets because they’re a lot more interesting. Originally, we had to “size” tickets (guess how long it would take to complete), but that didn’t work very well. It was always difficult and awkward to size them. “So, how long do you think this little ticket will take to complete? ” “Hmm, I don’t know. Maybe 3 days? Throw in a day or two for testing.” “Okay, what about this fairly large ticket?” “Hmm, I don’t know. Maybe 3 days? Throw in a day or two for testing.”‘
Basically, 3 days become the magic number, and we just decided to do away with sizing.
Every ticket is different. As a web developer, you rarely do the same thing twice. That’s another reason sizing tickets was so difficult.
If web developers never do the same thing twice, then how do they master their skill? I basically take everything I have learned and apply it to the new situation. It might be similar to being a detective or a forensic scientist. Every situation is different, but you learn your tools really well, and some situations have similarities that can be applied to other situations.
Some tickets are bug fixes. These are my least favorite tickets to do. They involve a lot of troubleshooting.
Some tickets are for new features. These are my favorite tickets to do because I get to write code and create something new instead of trying to figure out why someone’s code (possibly my own) isn’t working.
Bug tickets are my least favorite to do, but they are really where pair coding shines. Misery loves company. Working with someone else makes bug tickets much more enjoyable, and it makes finding a solution feel a lot more rewarding.
Tech debt tickets can be enjoyable. They involve refactoring old code. That might sound boring, but it’s easy to get lost in making the code more efficient and easier to understand.
Besides working on tickets, we also have a couple different meetings, some regularly scheduled and some as-needed.
Story/Ticket Kickoff
One as-needed meeting is the ticket kickoff. Ticket kickoffs are great motivators to help me get started on a ticket.
If I schedule a ticket kick off, I’m always motivated to understand the ticket as much as possible. It’s my ticket, after all, and I need to know more about it than someone who isn’t working on it. The ticket kickoff is really just a time to make sure you understand what you’re supposed to be doing. In programming (and every day life), it’s easy to miss something or read something into a ticket that someone else created. Everyone on the team is allowed to write tickets, and some are not as detailed as others. It’s a great time for someone to tell you that you’re completely misunderstanding it which has happened.
Code Review
After we finished working on a ticket, we usually set up a group code review.
I really think we should have a phrase for meetings to review current progress, something like a mid-code review, but we don’t have that, unfortunately.
During a code review meeting, the web development team reviews some code that someone has been writing. So, it’s very aptly named. It sounds intimidating, but it’s actually one of my favorite types of meetings, besides ticket kickoffs and general pair coding. During code reviews, you can ask other team members questions and verify that you didn’t pick the worst way to accomplish something.
Pair coding is my favorite type of “meeting” if it can be called that.
Pair coding usually involves one person “driving” while the other person offers helpful feedback. It sounds counter-productive but, ultimately, it’s not. It can be a lot more productive and enjoyable than working on your own. That’s because sometimes you run into a lot of road blocks. If you’re working on your own and you run into these road blocks, you can quickly become discouraged and stop working altogether, but if you’re pair coding, the other other coder can provide his input which is very encouraging. It’s also possible to waste a lot of time talking, but that rarely happens.
Sprint Meetings
The regularly scheduled meetings are called Sprint meetings and they usually happen every other week. There’s nothing too special or exciting about them. They’re just your normal 9-5 job meetings.
Well, that’s pretty much it. It’s not every thing, but it’s a good picture of what I do as a web developer.
Thanks for reading!