Are you interested in a job as developer at TOPdesk? That’s great! I bet you’re curious to know what a typical day as a developer at TOPdesk looks like. In this blog, I will take you with me on a normal day developing software here at TOPdesk.
We’re quite flexible with starting up in the morning: we should be in before 9:30, but it’s up to you if that is 8:00 or 9:30 and anything in between. Myself, I get in somewhere between 9:00 and 9:30. After I take off my coat, turn on my computer and get a cup of tea (don’t worry, we have coffee as well) I check my email, and wrap up some stuff from yesterday.
The daily stand-up
At 9:45 AM it is time for our daily stand-up meeting. Our department is organized in scrum teams, and all developers are part of a team. Teams consist of programmers, designers, testers and a scrum master. In the stand-up meeting, we update each other on what we’re working on, we identify possible bottlenecks or solutions, and divide the work for the rest of the day. It’s called a stand-up meeting because we are all standing up to avoid that the meeting will take too long. Nobody likes to stand for more than 15 minutes.
After the stand-up it’s developing time! Today, I start working on a new story. We have a huddle about the story with some people of the team. In a huddle, we walk through the story: how will we solve it? What options do we have? How can we split up the work in subtasks? All disciplines (programmers, testers and designers) sit together. We are not limited by our own discipline. After all, programmers have an opinion on design and testability just as well as on coding. This is what makes developing at TOPdesk so interesting: it’s all about collaboration.
After the huddle, the actual developing begins. We often work in pairs: two programmers coding together make less mistakes, produce better software, and have more fun. A programmer and a designer can quickly try out some design ideas and tweak it further.
As a developer, am involved with the backlog. It means that I can influence our product, and I’m not just creating what someone else designs
Lunch time! I’m getting hungry after a morning of developing. Of course, lunch times are flexible. No need to eat if you’re not hungry yet! Some people eat inside, where we have an excellent and extensive lunch every day. This is a great way to meet some people from other departments while enjoying a healthy lunch. I prefer to go outside with some colleagues and get some fresh air and a little walk for a fresh afternoon.
In the afternoon we continue working on the stories. Developing is intensive work, and sometimes my mind needs some distraction to keep a fresh perspective on things. Luckily, we have plenty of options here. We have a Nintendo Wii, an Xbox, a pinball machine, two foosball tables, a dart board and a snooker table. After this, I’m fit for developing again!
End of the sprint
On some days, we have special meetings. The demo for example: after every two or three weeks (this period is called a sprint) a team shows what they have been working on. Stakeholders in the project, which include people from all over the business, and sometimes customers themselves, give input from their perspective. This way we get early feedback that we can incorporate in the next sprint.
Another meeting we do at the end of a sprint is the retrospective. Here, the team looks back at the past sprint and looks for improvements to make each next sprint better than the last.
The backlog contains all the work that we might pick up in the following sprints. Before we can work on those stories, we need to ensure that we all understand what we want to do exactly, and how that will improve the product for our customers. Periodically, interested members of the team improve the backlog together with the stakeholders. We call this backlog grooming. To ensure that it is feasible to make stories on the backlog in a reasonable time, we have a planning poker session where we use poker cards to estimate the complexity of a story.
I really enjoy that I, as a developer, am involved with the backlog this way. It means that I can influence our product, and I’m not just creating what someone else designs.
A lot of my work is developing, writing code. Collaboration is important: pair programming, working together, and thinking of solutions as a team. Programmers, testers and designers all provide their input and all contribute to the final solution. Together with stakeholders I help define the future work, and thereby the future of our product.