What is the working day of a coder like? Is it more enjoyable to work on a permanent product or to move constantly from product to product? We talked about this with Xolo’s Java developer Egon Naarits.
My workday starts at 9 a.m., when I arrive at the office. We have the option to work from home, but I prefer working at the office because we have better working conditions there than I could ever achieve at home.
First, I review what information has been exchanged in Slack or by email and whether there are any important messages for me, then I check the status of my ongoing tasks. These are tasks that have been assigned to me, or that I have chosen myself from the available jobs. And these can be at multiple stages in the development process. First, a job will be ‘in progress’, then ‘in code review’, then ‘in testing’, and only after testing is completed will the work be finished for the developer.
For me, the activities that are of the highest priority are ones that I can move from one status to another. For example, if my code is in review and someone has made proposals for improvements regarding the code, I will check these first thing in the morning and make the necessary corrections so that the reviewer could accept the changes and send the code into testing. Other priorities include jobs where a solution I have developed is in testing and where errors have been found or additions are needed. Then I will fix the code as soon as possible and send it back to the tester. These are the things I always handle first so that I wouldn’t become a bottleneck for the team.
If everything is in order, I usually continue developing my current project where I left off the previous day. Sometimes questions will have been left the day before for the analyst, sometimes for the architect, and sometimes for our internal users. In that case, I try to communicate with them as soon as possible. Other times I start with a complex technical problem that I got stuck on the previous day, which I try to find a solution for by communicating with my colleagues or conducting research, and sometimes all it takes to concentrate properly is a clear head in the morning.
For a developer, no working day is the same as the one before. Each day brings new tasks or technical problems, which often requires improving your knowledge and learning new things. It keeps your mind fresh and frees you from the burden of routine.
Before Xolo, I had never worked at a startup, mostly just big corporations. At first, I was afraid that the processes might not be entirely fixed. In a startup, there might be more confusion, stress, and low-quality code due to time pressure, but Xolo has proved to me that it can be quite the opposite.
I’ve seen here that if the right people do things properly and with passion from the start, the code of your product can indeed be appropriately commented, uniform in style, and of consistently high-quality. Here, this has been facilitated by the use of both Wiki-based coding style guides as well as code reviews and code analysis tools.
We also have a well-established development process that works very well for a company of our size. We have been given an appropriate working environment and just the right tools; stress levels are lower than at any of my previous workplaces thanks to good management and job planning, and there is no external time pressure. We get to decide for ourselves what is currently important for the development team and what needs working on.
In most cases, the work is divided into smaller tasks, which makes it easier to gauge the volume and allows you to roughly predict when the job might be finished. At the same time, we also always have some bigger pieces in development, which can take several months to complete. These are also like small sub-projects that are divided between different developers by theme.
We get to decide for ourselves in what order we build the solutions, what technologies we use when we update the frameworks, how we put together the different pieces of the software, and how we organise the development. We get to use modern technologies and tools. The result is a more efficient working environment, where the developer can create more added value and will have greater prospects for personal development.
As a contrast, in projects done as a subcontractor for large corporations you often need to provide accurate time assessments to be correctly compensated for your working hours. It is very difficult to do that accurately because you might encounter unexpected problems during work. As such, projects are mostly won by the lowest bidder in procurements. This creates a constant pressure: the time and budget are almost always limited. You often have to make sacrifices somewhere when writing your code, even though no developer wants to do that. Then you lose additional time preparing all kinds of reports for the client. All of these things cause more stress.
When developing your product, however, you do not have to deal with most of these problems, which means you can fully focus on building your applications and writing better code. Moreover, since you see the development of the entire company up close and understand the big picture, you develop a stronger bond and sense of ownership with the product – you are a key part of the whole process.
Working in a project-based software company has its perks too, of course, but at the moment I prefer the atmosphere of startups, the lack of bureaucracy, and developing a platform. I feel that I have been able to produce higher quality work here and develop a lot personally. I have discovered that working at a startup company is nothing to be afraid of, and joining this team has been one of the best decisions of my career.
Photographer: Siim Seglinš