4 A DAY IN THE LIFE OF A FRONT-END DEVELOPER
The preceding chapters looked at the tools, methods and techniques employed by front-end developers. However, we are yet to discuss how these are used in day-to-day employment. This chapter therefore looks at what a front-end developer might expect to do in a day.
There is no typical day in the life of any developer, let alone a front-end developer. I have therefore included a bit of everything in this day to illustrate all the possibilities of the job, so this is going to seem like a very, very full day. Please do not think that I am always this busy all day and please do not let this put you off joining the profession. On an average day, I would likely spend a bit of time on one or two features of the discipline, but in far greater depth.
You will notice that I break my day up into multiple short chunks. These breaks are deliberate; taking mini-breaks improves focus and concentration and is better for your body as well, allowing you the chance to move around.
I work exclusively from home in my current role and have done so for the past couple of years, but the structure of my day has not changed much since I began to work from home, except that I now no longer need to commute for a couple of hours each day.
MORNING
08:00–09:30
I generally start my day by checking any work-related emails that came in during the evening and night.
I know that some people check their emails when they are away from work, but I caution against that. I find that if I do check my work emails, then I do not really relax but instead find myself preparing for the coming day when I should be relaxing.
After checking emails, I either pick up the tasks I have been asked to address via email or continue with the jobs I was engaged upon when I downed tools the previous day. I sometimes deliberately leave something in progress so that my subconscious can have a crack at it during the night.
I also spend some time looking over pertinent front-end-specific items via Feedly and click through to read the full article when they are relevant to me. I only look at them in greater depth when I need to take a break later in the day. These professional ‘distractions’ keep me updated, help me generate new ideas and, occasionally, help me find a solution to any current frustrations.
09:30–09:45
At 09:30 my colleagues and I have our stand-up. Stand-ups are a mainstay of Agile, which I discussed in Chapter 3. It is the de facto approach to development at the time of writing, and you will more than likely work within its dictates if you have not already done so.
I say that Agile is a standard within development, but it appears that it is reaching into other areas of human endeavour. Most recently, I heard from a friend in nursing that what were once called ‘handovers’ are now known as stand-ups.
Our stand-up is online, and we are all usually sitting down and talking over Skype. It lasts no more than 15 minutes and involves us each discussing what we did over the previous day as well as outlining what we plan to do over the coming day. It is also an opportunity to briefly discuss any development problems or issues that we’re facing and seek help from other members of the team. It is important to note, though, that issues are not discussed in length but introduced and then discussed further in a follow-up conversation with only the relevant members of the team attending and offering help or suggestions.
At this stand-up, I note that I have resolved a couple of issues which were raised during our user acceptance testing1 and also found and resolved a bug that was only evident in Internet Explorer 11 (I needed to replace an ES6 arrow function with a regular JavaScript function which had been written by another developer). I also detail what I plan to do during the rest of the day.
09:45–11:00
I have been asked to look at a form we have been working on for a client. It is a long and complicated form and requires the user to upload several pieces of evidence before it can be submitted. There has recently been an issue with the form, with users being unable to progress despite providing an answer to a required question, so I have been asked to correct the problem. This issue highlights the importance of thorough testing before the release of new code – had the developer who changed the validation on the form tested it themselves, they would have seen the issue. It also highlights the importance of understanding the business case for the requirement of the information as the client had changed their mind about the importance of collecting something which previously had not been required.
After relaxing the validation on the form to allow users to progress, I take a break to stretch my legs and make a pot of coffee to drink during the next hour or so.
11:00–11:30
At 11:00 we have a regular developer meeting to go over any issues raised in the stand-up, to look at possible solutions to blockers and impediments, and sometimes to show off.
Taking pride in your work is admirable. Although we generally frown on showing off, displaying something that you have just accomplished is essential.
You are hopefully being paid significant amounts of money for your labours, and it is crucial that not only your co-workers but also the stakeholders among your employers can see your worth. Not only will that help them to justify paying you but it will also prompt them to think in greater depth about what they want from you. If you can provide evidence to show that you can take an idea and make it work elegantly, then they will be far more likely to think of ways in which you can stretch your creativity in the future. Being challenged in this way will improve your engagement in your work and prompt more significant learning and understanding.
As part of the meeting, there is a question about why we have opted to use a flexbox layout (see the relevant section in Chapter 3) on a project. I came to this particular project after many of the significant design decisions had already been made, so I am more than a little interested in the rationale for this choice as well. It seems as though there was a requirement for elements to align within a container – no matter the width of the device used by the user; each part was a fixed width but on wider screens there needed to be a gap between items, whereas on narrower devices the elements needed to wrap appropriately. In this instance, the items were dashboard widgets, and their height is fixed to a multiple of a base unit. Thus the wrapping could get complicated. One possible solution to the issue would be to use a masonry layout where variable-sized blocks of content are pieced together into a whole. We decide to research how to implement a masonry layout during the next sprint.
11:30–12:00
One of my tasks today is to try to figure out why a table is not displaying correctly. We are using DataTables to enhance a table, but for some reason the first row is not displaying correctly. I fix the table in question by putting back the thead element and its child tr and children th items that an over-zealous fellow developer had removed.
I consider the effect the developer was trying to achieve by styling the first row of the table in the way they did but instead style the elements in CSS using the vw measurement unit. They have used DataTables and styling the row in the way they did not only broke DataTables but also cut the ordering functionality, as DataTables would have considered the row as a row which should be ordered.
The vw measurement unit was introduced in CSS3 and is widely supported (Deveria, n.d.-b). It is an interesting unit of measurement, with 1vw representing 1% of the viewport width. I have been using it extensively of late to ensure that thead text is understandable on smaller screens.
LUNCH
By my reckoning, I have been working for something between three and three and a half hours nearly solidly, so I need a break. I have a busy remainder of the day ahead, so I go off to the gym and shops to get something to eat. I then walk the dog on my return.
AFTERNOON
14:00–14:30
I am looking forward to the next tranche of work, which is tweaking some images for inclusion in the current project so that they fit within the page and will continue to do so regardless of the resolution of the user’s device. I decide to use a raster image in this context as the image is a photograph.
I feel justified using a JPEG, but I make sure I reduce the quality and thus the size of the image to not cause too many issues for those users with a slower internet connection.
14:30–15:00
I finish writing a report on the results of some user research I carried out a little while ago. I email this research to the internal product owners, being careful to include all relevant parties and include anonymised evidence to support my conclusion that using a single table to collect data would be better than using multiple tables.
15:00–16:00
A quick check of the shared calendar reminds me it is nearly time for our sprint retrospective.
Each team will be different, but in my current team there is a front-end developer (me) and there are at least three other developers who are classed – in our team at least – as full-stack developers. Additionally, there is our Scrum master, our software architect, our designer, a representative from our product owners and a smattering of representatives from quality assurance (QA).
A retrospective is held at the end of an Agile sprint to reflect on what went well and what could be improved for the next sprint. We look at how many tasks we have finished and what is remaining, and we also note that communication has again been key in accomplishing our goals, with QAs particularly praised for seeking clarification regarding testing the work we undertook. There are few stories left to be classified as done2 and these are carried over into the next sprint.
16:00–17:00
Our retrospective is recorded on an Ideaboardz (https://ideaboardz.com). I look forward to my day’s work tomorrow. I know that there are some things that I will have to research and plan this evening so that I am prepared for tomorrow morning’s sprint planning meeting, where we will define and specify the work we will be doing in the next sprint. I know, for instance, that I will be spending some time displaying data to users – data which has been supplied to me about a process in the application in JSON format.
1 User acceptance testing (UAT) is carried out to confirm that the application matches the required specification. Our UAT is carried out by a team internal to the business but separate from the development team, so perhaps it should not be classified as UAT, except that the business also uses our product in its day-to-day operation. UAT is a feature of Agile.
2 In Agile development, ‘done’ should really mean ‘DONE!’ (Waters, 2007).