A Day in the Life of an Experience Developer

by | May 4, 2020

What follows is the account of an Experienced Developer, more specifically a Frontend Developer, going through their day. While each day is different, this post shows how a typical day might play out.


You wake up, squinting your eyes at the sunlight coming into your room through an opening in the curtains. brrrrt brrrrt You hit snooze a few times. You’ve never really been a morning person. You go through your morning routine, thinking of what the day might bring. “That’s right, we’ve got a brainstorm session today. It’ll be really interesting to hear everybody’s ideas. I hope I can come up with some good ones myself.”

“Got to go, my train leaves in 10 minutes!”, you exclaim, quickly grabbing your coat as you dart out the door. You’ve been travelling to work with the train ever since you started your career. The train subscription is paid for, why would you go through the stress of traffic jams anyway?! You arrive at work fresh, having had the time to think up some ideas for the brainstorm session. You’ve read up on design systems a while ago and think it might make sense to look into this a bit more for upcoming projects.

You choose one of the free desks at the Digital Studio, plug in your laptop and hook it up to the external screen. First things first however, and you go grab a coffee. After a quick catch-up with some of your client coworkers you sit down at your desk. There’s some pull requests to review, so you take the time to go through the changes, providing comments where you have input or can suggest a better approach. Some of your comments concern potential bugs in the code, others are merely suggesting improvements to code style & naming. They all serve to improve the quality your team delivers, so you don’t hesitate to share your thoughts. You had an open pull request of your own and it too has some comments with suggested improvements. You note down the suggestions you’ll apply, while explaining your point of view on others.

Before you realize it, it’s time for the Daily Stand-up meeting. During this 15 minute meeting, each team member shares what they’ve worked on yesterday, what they will work on today and what is blocking their progress. You’re feeling confident, yesterday was very productive and today you’ve already processed several pull requests and expect to finalise a new web component. You need some input from the Studio’s UI Designer – Jen – though, you want to make sure your work shines on each type of device and currently it’s looking a bit wonky on tablets. The SCRUM Master lets you know Jen will be available on-site in the afternoon. When the stand-up ends, you contact her to ask if they have 10 minutes after lunch for a quick alignment and they happily oblige.

You get back to your desk, put on your headset and blast your favourite tune. You crack your knuckles. “It’s game time!”, you think, as you fire up Visual Studio Code and continue where you left off yesterday. Naturally you notice some oddities, taking a fresh look at your work you reorganise a few things, add a line and remove two others.

After an hour or two of coding a reminder pops up. The brainstorm session you were thinking about this morning is almost starting. Together with people from various roles, you’re coming up with ideas for a new project currently in the concept phase. Some ideas are fresh: “Let’s use beacons to make the application location-aware inside of the client’s buildings, we’ll be able to guide users to an exact location”. Others are more tried: “We could add a to-do list, so the user can keep track of their personal to-do’s”. Some are way out there: “If we’re thinking of making the app location-aware inside the building, we could also add LED strips into the building’s corridors to act as markers. The user won’t even have to look at their phone to find their way!”. Flashbacks to the corridors found in old-school video games enter your thoughts, but you push past them.

All ideas are mapped across a matrix to identify their appeal versus feasibility given this project’s constraints. You suggest to start building a Design System tailored to this client as part of the project. It would help build a consistent user-interface, while serving as a building block for any visuals that need to be created later. It would also be a great reference for later projects. Your idea is marked as both appealing and feasible.

After the brainstorm session has ended it’s time to get back to the user story you were implementing. You finish writing tests to cover the story’s acceptance criteria, when you notice a test that just isn’t working, it’s always failing. “What’s going on here?” you ask yourself. “I swear this was working earlier!” That’s when it hits you, the acceptance criteria specify that an error message needs to be shown when the user specifies a negative number in a certain field. The test is checking for this behavior, but you haven’t implemented this. Five minutes later you’ve corrected the component’s behavior in this scenario and all tests are now green.

“Hi, you wanted to have a chat?” Jen asks. “Oh yes indeed, I had some concerns regarding its visualization on tablet screens. Let me show you.” You take a look at the current visualization together and agree that it needs some optimalizations. Jen suggests to lay the component out in a way that makes the best use of the available screen real estate. You apply a few small changes in the CSS & HTML structure and achieve the desired result. You take a moment to review the end result across all types of screens: mobile, tablet, desktop and media wall. It looks really sleek and the visualization is beautiful in any scenario. With this done, you push your latest changes to the repository and create a Pull Request so your team members can review your work.

With your story up for code review, it’s time to head home. You check in on the others in the studio before heading out. Tom’s working in the bean-bag as always, you almost didn’t notice he was there. No doubt he’s looking into some upcoming integrations for the Studio’s back-end devs to sink their teeth into. Jen’s still working on some amazing looking content, she’s using one of the extra large screens so it’s just large enough for you to be impressed but not large enough to read the text. You’d have to stand next to her to find out, but decide against it as she seems focused and you don’t want to interrupt. You’ll figure out soon enough in one of the all-hands meetings.

There’s some really cool work being done, you can’t wait to see it in the end-user’s hands. You head back home by train, getting some reading in on the way. You think about the adventures tomorrow may bring. “I wonder if I’ll get any remarks on my Pull Request?”


If you enjoyed this read, check out What is the Digital Studio? or How a frontend developer and a UI designer can work efficiently together in a Digital Studio for more information on some of the concepts mentioned. If this seems like something you’d be interested in, feel free to check out our open vacancies and join me in one of our Studios!

Designing Mixed Reality experiences: 6 lessons learned

Designing Mixed Reality experiences: 6 lessons learned

Mixed reality (MR) technology has the potential to revolutionize the way we interact with the world around us. By blending the physical and digital worlds, MR technology allows for the creation of immersive and engaging experiences that were once unimaginable. However, in order for MR technology to be truly successful, it is crucial for UX designers to carefully consider the user experience. By incorporating intuitive interactions, seamless immersion, and engaging aesthetics, designers can create MR experiences that are truly revolutionary. By taking the time to carefully consider the UX design of an MR experience, designers can help to create truly immersive and engaging experiences that will keep users coming back for more.

read more