Have you ever wondered what goes on behind the scenes at a tech conference? While attendees marvel at the seamless flow of talks and workshops, there's a dedicated team working tirelessly to curate the program. I have been part of the committee for both the JS Nation as well as JS Nation US conferences for close to a year now, time to spill the tea! 🫖

Enter the Program Committee – the unsung heroes responsible for crafting the conference agenda and ensuring a memorable experience for all.

As developers most of the actual work is done behind the scenes (or screens). This is not just for backend development, but goes for frontend development just as well. Consider all the time, effort and planning that goes into executing a technical solution or building an interface. Aligning between multiple stakeholders or comparing technical solutions and routes before implementing, goes largely unnoticed.

In most cases, what the end user sees, is just the tip of an iceberg! With "going public" I mean proudly exposing the underside of that iceberg. Not for the sake of the end user, but for your self. You should always consider contributing to your personal brand!

As the year draws to a close, it is an opportune time to contemplate the accomplishments of past years in order to gain a better perspective. Looking back on my achievements, I feel a sense of pride and gratitude for all that I have accomplished, with the help and support of those around me.

This year, many things that were previously in progress seemed to fall into place, leading me to pursue a new career direction that focuses more on engaging people rather than code. This is a path that is better suited for me at this stage in my career.

I've been a web developer for over a decade (feel old yet?). Over my career I've gradually moved from an entry level junior at a web agency where I learned not to drop tables, jQuery (yes) and the woes of supporting ie6 even!

Over the years I've grown in experience and have been focused more on becoming a well rounded frontend specialist, having adopted the Vue.js / Nuxt.js tech stack for the past four years and considered expert enough to been invited to speak at conferences and writing a book.

When the year closes, it's always a good moment to reflect on the past years achievements to see the bigger picture. If I look back to my achievements, I am proud and grateful for all I've achieved with support of people around me.

A lot of things that have been in the works seemed to click this year and directed my career into a new path, more focussed on engaging people over code. Something that suits me at this point in my career.

I saw this post, by Erik Flowers while scrolling the LinkedIn feed which resonated with some thoughts that have been floating in my mind without anything to latch on to. But now those thought found something to root.

I am currently working as a "software engineer" (commonly also referred to as "frontend developer") and although I like to label myself more as an "interaction developer" my main domain consists of designing software architectures and writing code. My background has always involved some level of getting involved with the user experience (UX) aspect. And while that may seem something that sticks out, I feel it is both to build good software and unfortunately also something that is not commonplace.

Last week I had the opportunity to speak at VueJS Amsterdam ❤️ together with a colleague of mine. It was my first time doing a talk at such a big event and thought to share my journey, and give you considerations for when you will be giving a first talk!

Small disclaimer: I am by no means an expert in speaking, but that’s exactly why I think this post gives you insights for starting out. Also, the talk we gave was about a certain technology, but I think this article is generic enough to apply for any topic.

Tech job interviews. They are a very important part of the continuity of an organisation and the trajectory can wildly vary per company. I want to highlight a couple of tips for both interviewer as interviewee, from my perspective as having done both on several occasions.

Let's take a look at the companies' perspective. I think this perspective hold most value for both parties. Usually we can break down the interview process in a couple of steps, which boils down to the following phases:

With the right processes and tooling, it becomes a lot easier to share code between developers. With the right amount of documentation in the right place, you also flatten the learning curve for onboarding developers to get up to speed. This reduces the risk that responsibility lies with a single developer (read: a single point of failure) and encourages developers to share, contribute, review and refactor code. Just make sure you have ample coverage so that you confidently can refactor, with minimal impact on existing features.

Any software project tends to grow in complexity over time. Without a good development strategy, sooner of later the quality of projects can erode.

What’s your best advice on how to make an impact?

This tweet from Una Kravets got me thinking: how do you make an impact?

Software development has such a high velocity compared to other industries because ideas and concepts can be shared so efficiently. I think the best description is the expression: “Standing on the shoulders of giants”: Make smart use of the work of your predecessors and colleagues. Use that also when acquiring knowledge: you don't have to do everything yourself. The development community is very large and helpful and a lot of information is easily accessible.

If anything was indicative of the frontend community in 2016, it was the term JavaScript Fatigue. What does it mean? The number of JavaScript frameworks has exploded over the past period. Indeed, it is an overwhelming number of new methods, tools and techniques available to us as developers. What can you do to keep your head above water or even take advantage of these rapid developments?