blogpost advent 2024

src/en/blog/2024/12/at-the-helm-as-a-front-end-lead-developer.md

@@ -0,0 +1,93 @@
+---
+title: At the helm as a front-end lead developer
+date: 2024-12-19
+author: Arjan Eising
+summary: What does it take to be a front-end lead developer? An overview, personal experiences, tips, and tricks.
+categories:
+  - Advent calender
+key: advent-2024-arjan
+---
+
+And then, all of a sudden, I was a lead developer.
+
+The client I worked for a few years ago had several major features planned. A large codebase with significant technical debt and an urgent need for refactoring. From “higher up,” there was a desire for a single point of contact to oversee the progress and complexity of the project. The front-end team was a solid group of seven developers, with diverse knowledge and ideas.
+
+There was a need for one captain at the helm, and that became me in the role of front-end lead developer.
+
+In the past few years, I’ve been a front-end lead on multiple projects. In this blog post, I’ll outline the complete picture of that role so that you’re prepared if you ever step into the position of lead developer. These are areas you can focus on and develop yourself in with books, courses, or conferences.
+
+## What does it involve?
+
+Partly, you deal with the (front-end) technical side of what you’re building. You support the entire team to make that happen. You keep an eye on the big picture of the infrastructure and set a clear goal on the horizon. Outside the team, you’re a point of contact for various people, such as product owners, partners, and business stakeholders.
+
+The exact responsibilities vary depending on the company. Perhaps there are multiple front-end leads for different teams, or there’s a tech lead overseeing both the front-end and back-end.
+
+In summary, the role consists of:
+
+- Code
+- Infrastructure
+- People and Interactions
+
+I’ll address these in reverse order.
+
+## People and Interactions
+
+While front-end development already involves collaboration with other disciplines, stepping into a lead role adds more weight to the process. Before major new features are built, they are conceptualized, broken down, designed, reviewed, improved, and rethought. Even when things become more concrete, as a lead, you can influence how the team approaches these tasks.
+
+Throughout these processes, you're constantly reasoning and persuading. Sometimes you're coaching or mentoring. Above all, you’ll spend a lot of time in meetings.
+
+### Coaching and Mentoring
+
+How do you effectively support your team members in their work? In their development as developers? What’s holding them back from being productive in a team? How can they gain a fresh perspective on things? How can they get to know themselves better? What’s really going on with someone?
+
+Not everyone is a natural-born coach. For me, deliberately seeking training in this area has been beneficial.
+
+The world of coaching and mentoring can be quite broad when it comes to self-improvement. One of the most important lessons I’ve learned is to listen to understand, rather than to respond. After someone finishes speaking, resist the urge to immediately suggest something. Instead, ask clarifying questions.
+
+### Meetings and Agendas
+
+More responsibility means more alignment, often with a larger group of people. More meetings. You may also feel the need to coordinate how/what/when certain technical tasks will be developed.
+
+Sometimes this is necessary, but often less so. Without clear boundaries, your calendar can quickly fill up with meeting invites from others.
+
+Keep a close eye on your schedule and deliberately set aside time for the tasks you want to complete daily. For example, block time for code reviews or even for taking breaks.
+
+Of course, not everything needs to be a meeting. Asynchronous coordination, such as in a Slack thread, can be highly effective and accessible.
+
+### Collaborative Engagement
+
+How do you work and collaborate effectively? Do the same discussions happen repeatedly, with the same people dominating the conversation? Is everyone truly heard, and is there openness to new ideas?
+
+From the agile world, I was introduced to Liberating Structures, which include various methods to engage a group based on an invitation. For instance, inviting participants to brainstorm in smaller groups.
+
+Liberating Structures help me quickly mobilize a group to tackle an issue, ensuring that everyone involved has a chance to contribute. This contrasts with traditional meetings where a few dominant voices often steer the discussion.
+
+The [Liberating Structures website](<(https://www.liberatingstructures.com/)>) contains a wealth of information, and I highly recommend experiencing it firsthand at a meetup, such as the [Liberating Structures User group](https://www.meetup.com/liberatingstructures/) in the Netherlands.
+
+## Infrastructure
+
+Someone needs to ensure technical reliability and chart a clear course. As a lead developer, it’s your responsibility to use your leadership and insight to keep the ship seaworthy.
+
+This involves various areas, such as security, privacy, accessibility, and dependency management. Periodically, you’ll need to review (or delegate a review of) the codebase. Additionally, you’ll need to set goals in these areas that the team can work toward. Maintaining a broad knowledge of architecture, infrastructure, and technology is crucial, even if you’re not building everything yourself.
+
+A great time to review documentation is just before a new developer joins the project. They need to understand how everything fits together. There should be documentation to introduce, set up, and develop the project. The onboarding process is an excellent opportunity to update and refine documentation. A fresh perspective can invigorate both the team and the codebase, often leading to meaningful improvements.
+
+Another indicator of infrastructure health is how often team members point out problematic areas. Keeping track of this feedback gives you more leverage to implement improvements in a timely manner.
+
+What could be better?
+
+What _must_ be better?
+
+## Code
+
+At the end of the day, you’ll likely write much less code yourself.
+
+Most of your time in the codebase will be spent sharing knowledge through pair programming and pull requests. For every interesting piece of code you could write, think about who on the team could do it instead. The best candidate might not be the fastest but rather the one who could learn the most from the task.
+
+It’s important not to become a bottleneck for the rest of the team. Avoid taking on too much work yourself, as it could lead to long turnaround times. A common mistake is trying to do all the code reviews yourself, which can quickly create unnecessary pressure.
+
+You might focus on smaller tasks, such as those that seem less urgent but have been lingering for a while.
+
+## In Conclusion
+
+Maybe you prefer to stay anchored and keep your focus on code. Or perhaps you’re ready for the challenge of taking the helm. Either way, you’re never alone, and hopefully, the above offers a useful glimpse into the role of a lead developer.

src/nl/blog/2024/12/aan-het-roer-als-front-end-lead-developer.md

@@ -0,0 +1,91 @@
+---
+title: Aan het roer als front-end lead developer
+date: 2024-12-19
+author: Arjan Eising
+summary: Wat komt er bij kijken een front-end lead developer te zijn? Een overzicht, persoonlijke ervaringen, tips & tricks.
+categories:
+  - Adventskalender
+key: advent-2024-arjan
+---
+
+En toen was ik ineens een lead developer.
+
+De opdrachtgever waar ik enkele jaren geleden werkte, had diverse grote features op de planning staan. Een grote codebase met aanzienlijke technical debt en een dringende behoefte aan refactors. Vanuit “hogerop” was er behoefte aan een vast aanspreekpunt over de voortgang en complexiteit van het project. Het front-end team bestond uit een solide groep van zeven developers, met uiteenlopende kennis en ideeën.
+
+Er was behoefte om één schipper aan het roer te hebben, en dat werd ik in de rol van front-end lead developer.
+
+De afgelopen jaren was ik op meerdere projecten een front-end lead. In deze blogpost schets ik een totaalplaatje van die rol, zodat je voorbereid bent als je zelf aan de slag gaat als lead developer. Het zijn zaken waar je op kunt focussen om jezelf in te ontwikkelen met boeken, cursussen of conferenties.
+
+## Wat komt er bij kijken?
+
+Deels houd je je bezig met de (front-end) technische kant van wat je aan het bouwen bent. Je ondersteunt het hele team om dat voor elkaar te krijgen. Het totaal plaatje van de infrastructuur houd je in de gaten; je zet een stip op de horizon. Buiten het team ben je een aanspreekpunt voor allerhande mensen, bijvoorbeeld product owners, partners en mensen van de business-kant.
+
+De exacte invulling is anders per bedrijf. Wellicht zijn er meerdere front-end leads voor verschillende teams. Of is er een tech lead die zowel de front-end als back-end overziet.
+
+Kort samengevat is het:
+
+- Code
+- Infrastructuur
+- Mensen en interacties
+
+Ik behandel ze in omgekeerde volgorde.
+
+## Mensen en interacties
+
+Waar je als front-end ontwikkeling al samenwerkt met andere discipline, komt er als lead meer gewicht in de schaal. Voordat grotere nieuwe dingen gebouwd worden, worden ze uitgedacht, opgeknipt, ontworpen, doorgelicht, verbeterd en weer uitgedacht. Ook als het concreter wordt, kun je als lead invloed hebben op hoe dat binnen het team opgepakt wordt.
+
+Tijdens die processen ben je voortdurend aan het argumenteren en overtuigen. Soms aan het coachen of mentoren. Bovenal is het heel veel overleggen in meetings.
+
+### Coachen en mentoren
+
+Hoe help je mensen in je team effectief met hun werk? Met hun ontwikkeling als developer? Wat weerhoudt ze ervan productief te zijn in een team? Een andere blik krijgen op zaken? Zichzelf leren kennen? Wat speelt er echt bij iemand?
+
+Niet iedereen is een geboren coach, voor mij heeft het gewerkt bewust training in deze hoek op te zoeken.
+
+De wereld van coachen en mentoren kan best een breed onderwerp zijn om jezelf in te verbeteren. Een van de belangrijkste lessen die ik heb geleerd, is luisteren om te begrijpen in plaats van luisteren om te reageren. Nadat een ander uitgepraat is, niet direct iets te willen suggereren, maar juist om vragen te stellen ter verduidelijking.
+
+### Meetings en agendas
+
+Meer verantwoordelijkheid betekent meer afstemming, vaak met een groter aantal mensen. Meer meetings. Ook zal er een drang ontstaan zelf af te stemmen hoe/wat/wanneer bepaalde dingen op technisch vlak ontwikkeld gaan worden.
+
+Soms is dat noodzakelijk, vaak iets minder. Zonder duidelijke grenzen kan je agenda snel overladen raken met meeting-uitnodigingen van anderen.
+
+Houd je agenda strakker bij en plan bewust tijd in voor zaken die je dagelijks wilt afronden. Blok je agenda bijvoorbeeld met momenten om te code reviewen. Of wanneer je pauze moet nemen.
+
+Natuurlijk hoeft niet alles een meeting te zijn. Asynchrone afstemming in bijvoorbeeld een Slack-draadje zijn heel waardevol en laagdrempelig.
+
+### Betrokken samenwerken
+
+Hoe werk en overleg je samen? Zijn het vaak dezelfde discussies, met dezelfde mensen aan het woord? Wordt iedereen echt gehoord en is er een open houding voor nieuwe ideeën? Vanuit de agile hoek kwam ik in aanraking met Liberating structures, die behelsen meerdere recepten om een groep aan het werk te zetten op basis van een uitnodiging. Bijvoorbeeld een uitnodiging om te brainstormen, waarbij in kleinere groepjes aan de slag gegaan wordt.
+
+Liberating structures helpen mij een groep in mum van tijd aan het werk te zetten met een vraagstuk, op een manier dat iedere aanwezige betrokken is en input kan geven. Dit in tegenstelling tot een klassieke vergadering, waarin slechts een paar mensen met het hoogste woord de discussie bepalen.
+
+De [website van Liberating structures](https://www.liberatingstructures.com/) bevat veel informatie, ik kan het aanraden het mee te maken bij bijvoorbeeld een meetup van de [Liberating Structures User Group](https://www.meetup.com/liberatingstructures/) in Nederland.
+
+## Infrastructuur
+
+Iemand moet zorgen voor technische betrouwbaarheid en een duidelijke koers uitstippelen. Als lead developer is het aan jou je leiderschap en inzicht in te zetten om je schip zeewaardig te houden.
+
+Dit zal zijn op basis van diverse gebieden zoals beveiliging, privacy, toegankelijkheid, het bijhouden van dependencies. Periodiek zul je een goede blik door de codebase moeten (laten) doen. Ook zal er op al deze vlakken een doel moeten worden gesteld waar het team naartoe kan werken. Het is essentieel om je kennis van architectuur, infrastructuur en techniek breed te onderhouden, zelfs als je niet alles zelf bouwt.
+
+Een goed moment om de documentatie te beoordelen is vlak voordat een nieuwe developer aan het project begint. Diegene moet weten hoe een en ander in elkaar zit. Er moet documentatie zijn om het project in te leiden, op te zetten en aan te ontwikkelen. Tijdens onboarding heb je een mooie gelegenheid om documentatie op peil te brengen en aan te passen. Een frisse wind waait door het team en de codebase. Wellicht vloeien er betekenisvolle verbeteringen uit.
+
+Een andere meetlat is de frequentie waarin teamleden onderdelen aanwijzen als problematisch. Als je dit bijhoud, heb je ook extra slagkracht om verbeteringen tijdig door te voeren.
+
+Wat zou beter kunnen?
+
+Wat _moet_ beter?
+
+## Code
+
+Onder aan de streep schrijf je mogelijk veel minder code.
+
+Het grootste gedeelte van je tijd in de codebase zal zijn om kennis over te dragen tijdens pairings en in pull requests. Van elk stuk interessante code die je zou kunnen schrijven, kun je na gaan denken wie in het team dit het beste kan doen. Het beste kan zijn in een kort tijdsbestek, maar juist ook waar het meest geleerd van kan worden.
+
+Belangrijk is om niet een bottleneck te zijn voor de rest van het team. Neem dus niet te grote zaken op je bordje, want dan is de doorlooptijd erg lang. Een veelgemaakte fout is alle code reviews zelf te willen doen, wat al snel tot een kunstmatige werkdruk leidt.
+
+Je zou kleine tickets op je kunnen nemen, bijvoorbeeld taken die minder urgent lijken maar al langer blijven liggen.
+
+## Tot slot
+
+Wellicht blijf je liever voor anker en hou je jouw focus het liefste bij code. Of je wordt uitgedaagd aan het roer te staan. Natuurlijk sta je er nooit alleen voor, dus hopelijk is bovenstaande een nuttig inkijkje in de rol van lead developer.