Day in the life of
Lead Developer – Alexey Malkov
Being the lead developer in the company, I mostly spend mornings catching up on emails and Trello and Jira dashboards. We use Trello mainly to communicate design elements and this usually involves the client directly sharing their thoughts and revisions. Jira is more for programming work for our internal processes, guiding development processes, debug and logic. Using both helps produce a final report and keeps remove the guessing work away from the client.
A couple of hours will be allocated to debug and to re-schedule some workflow. Teams are dynamic and juggling resources is important to avoid missing schedules especially when there are unforeseen events and pesky software bugs. In order to offset some unpredictability, I would always try to create buffers and squeeze out as much bonus time as possible, and the only way to do it is to fill idle teammates.
In the afternoon, there are more unscheduled surprises such as compatibility issues, bugs, unexpected human factors (e.g. sickness, child birth, and others), or client emotions. It is very often that previous projects discover new bugs and provided we give clients a warranty for robust functionality, those have to be attended to immediately post-production and this can weigh in on a regular day. Clients and team members may present various news so I have to be ready to deal with that too.
Evenings are usually when I can disappear from dashboards and other professional communication. During this time I can truly focus on programming which will be 2-5 hours and produce or optimize functional code.
The benefits of being a lead developer in a company enable wider control over projects in terms of functionality and design, create agility and ability to adjust clients expectations as well higher pay obviously. More often than not, clients will accept some degree of change to their expected results. If I find that we can save time and resources by producing a more efficient approach to the usability of the app or a program, I will attempt to delegate that with the client. Clients will usually accept.
The disadvantage to that is the amount of chaos that presents itself, especially when there are more heads involved in the process, usually extending my responsibilities into after hours. There are very significant examples of chaos, mainly occurring due to miscommunication and over-commitment. The worst is when completely wrong functionality and design are produced by team members on a tight deadline. Another painful example involves deviation of client’s expectation as they tend to get quite creative, not immediately, but some time after the completion of the plan. Some clients would like to add new requirements and although we do position ourselves as a customer-oriented and agile company, we simply have to refuse quite a bit and return later. All in all, as there are more people involved in a project and there is no clear leadership, things tend to get demoralized quite quickly. To be precise, more heads relate to a longer chain of command and agencies in between revisions.
Software Engineering Managers are responsible for managing the design and development of software applications. They manage the daily activities of team members working on a project.