My First Year In Web Development

A year in web development has flown by. So what have I learned?

Agile

I didn’t know what to expect coming in with no experience in Agile. I guess I didn’t have any expectations. After a year, I have formed a few opinions.

On the surface, I think Agile works for what it should do. It provides an iterative and collaborative approach to software development. It also seems to create a smooth process with the creation of tickets, developers picking them up, and ticking off the acceptance criteria, with the added flexibility of adjusting requirements very quickly.

The iterative improvement of each sprint is also something I think is very valuable.

I think it works.

Ideally, each sprint will become better than the last. I think to get the best out of this approach, an improvement in the process of identifying how to improve the sprint will yield the biggest benefits. Agile-ception. If there’s not this improvement, a big benefit of Agile, I think, is lost.

Now, I have only experienced Scrum. So this means sprint planning, ticket refinement, and retrospective meetings, also including ticket estimations with story points.

To me, Scrum tends to create observability of what the team can achieve, which I believe has a cost in time, thereby reducing what the team can actually achieve. In other words, the ticket estimations in sprint refinement, and bringing a set amount of tickets into the sprint, actually leads to a decrease in what can be achieved.

Story pointing costs story points. Observability costs story points.

I also think that Scrum allows bottlenecks in the path to a ticket being done, to almost be swept under the rug. If there is a bottleneck in deployment, at the end of the sprint with no tickets being done, this bottleneck will resolve itself. Potentially a problem never seen.

Probably a good action to come out of a Scrum retrospective would be to try Kanban. I have not experienced it, but, to borrow a term from chemistry, it seems to have the potential to determine the ‘rate-determining step.’ We can then reallocate resources or work on processes to improve this bottleneck; we are forced to.

Now, I think one important thing to keep in mind in Kanban is developer burnout. The slowdown after a sprint in Scrum allows a respite.

I guess there are many solutions to this.

Even if Kanban is tried for a few sprints, maybe improvements to the Scrum process can be identified or highlighted.

Organisation and Planning

I started development with just a notebook. A page for each ticket, general notes, and learnings in the back that I need to be aware of. Now, I have a Notion setup based on the excellent PARA method, gradually refined to my needs.

This, I feel, has a significant benefit in relieving cognitive overhead and generally being more productive. I am now using this not just for work-related things but also for my personal life.

I have a system that my mind trusts, so I can now quickly offload any articles or libraries I come across (there are great browser extensions for this), tasks that need to be done, or a quick thought, which allows my mind to relax. I don’t have to have a background process running to keep these things in memory.

There are still improvements to be made. More simplification. Overall, though, it is a huge improvement over a notepad.

If you are not using something like Notion, I would highly recommend it. It’s not just a to-do list and a note-taking app. It’s a mental storage and organisational companion.

Aggregation of marginal gains.

Borrowed from the excellent book Atomic Habits, the concept of aggregation of marginal gains stands for continuous self-improvement, not just on the larger, more obvious things, but also on the smaller things that, in the long run, will add up in ways which we may not expect.

I have built a recurring task in my Notion setup that occurs every week, to reflect on the week, and to create a small task that will have a small improvement in something. This is the 1% improvement, if you will, as discussed in the Atomic Habits book.

This could be anything from implementing a new shortcut, to asking an insightful question to someone. Many of these currently include slowly learning more Neovim shortcuts and commands, as moving from VSCode to Neovim as an editor has been a flurry of marginal gains.

I think as a developer, not only having the mindset of continual improvement, but also having processes in place to incorporate them into the daily flow is a must.

Perspectives and Teamwork

This first year has also highlighted to me the many different perspectives people can have. Everyone has different perspectives, we know this, but how can we begin to understand these if we are not exposed to or experience the things other people do?

Experiencing others’ tasks, I feel, leads to much better communication, which is vital in any team. Not just between developers, but product owners and stakeholders, and everyone in between. Communication, I feel, is often the rate-determining step. How can I encourage better teamwork and communication is something I will be thinking more about.

From a developer standpoint, I have taken to learning the Rust programming language to give me different perspectives on development. Rather than just seeing things as a ‘JavaScript developer,’ I can already see how my perspective has changed. I no longer see myself as a ‘Web developer’ but more as a ‘Software Developer,’ with programming languages being just tools to be able to provide a solution. I do sometimes like to abstract further into being a ‘Problem solver’ rather than a ‘Software developer.’