DEV Community: Joran Quinten

Thermodynamics and Software Development: Wrangling Entropy and Order in Code

Joran Quinten — Sat, 29 Jun 2024 09:15:17 +0000

In the wild world of software development, just like in thermodynamics, entropy is always lurking. Understanding these scientific principles can give us some insights into taming and improving our codebases.

Let’s throw on our lab coats and dive into how the laws of thermodynamics can jazz up our approach to software development! 🧪

The First Law of Thermodynamics: Conserving Effort and Resources

The first law of thermodynamics, aka the law of energy conservation, tells us that energy can’t be created or destroyed in an isolated system—it just changes forms.

Conserving Effort in Software Development

Think of energy as all the effort and resources we pour into building and keeping our code in shape.

Managing Conservation

To make the most of our efforts, try these practices:

Effort Redistribution: A certain amount of efforts spent on maintenance and improving remains the same. So automate those boring, repetitive tasks like testing and deployment to free up developer time for the cool, creative stuff.
Technical Debt Management: Regularly tackle technical debt. Ignoring it might save effort now but will cost way more in the long run.
Knowledge Sharing: Spread the wisdom across the team with code reviews, pair programming, and solid documentation. This ensures no one person is a single point of failure and keeps things running smoothly.

The Second Law of Thermodynamics: Embracing Entropy

The second law of thermodynamics tells us that entropy (or disorder) in a system only increases over time. In simpler terms, *things naturally get messier *(sound familiar?). Plus, heat doesn’t move on its own from a cold body to a warm one.

Entropy in Software Development

Entropy in our coding world is that creeping complexity and disorder in a codebase. As we pile on new features, fix bugs, and refactor, things tend to get more complicated. Without a plan to handle this mess, the codebase can become a nightmare to understand, maintain, and expand.

Managing Entropy

Here’s how to keep the chaos in check:

Regular Refactoring: Regularly tidy up and improve your code structure. Refactoring cuts down complexity and boosts readability, making the code easier to manage.
Code Reviews: Conduct thorough code reviews to make sure new changes stick to established standards and best practices. This helps keep unnecessary complexity at bay.
Automated Testing: Use automated tests to catch regressions and make sure changes don’t cause new issues. Tests act like a safety net, maintaining order in the codebase.
Documentation: Keep clear and up-to-date documentation. Good docs help developers grasp the system’s design, reducing the mental load when dealing with complex code.

Given the second law of thermodynamics, you need to spend resources to fight the natural mess. If you let things slide, your software will turn into an unmanageable beast.

The Third Law of Thermodynamics: Approaching Order

The third law of thermodynamics says that as a system’s temperature drops to absolute zero, its entropy (disorder) hits a low, stable point. For most systems, this means they become super ordered.

Absolute Zero in Software

In our coding universe, absolute zero is like reaching peak stability and minimal complexity. While hitting absolute zero is impossible (this would be the equivalent of a blank HTML page), aiming for minimal entropy is a worthy goal. This means striving for simplicity, clarity, and efficiency in our code.

Striving for Minimal Entropy

To get closer to this ideal state, try these strategies:

Simplicity: Keep it simple, stupid! Simple code is easier to understand, test, and maintain.
Trimming excess: If code isn’t needed anymore, chop it out. Don’t just comment it out—remove it entirely. Version control makes this easy, so aggressively cut out unused features, functions, or parameters. Unused code just adds to the mess.
Modularity: Design systems to be modular, where components are loosely connected and highly cohesive. This reduces overall complexity and makes changes easier to manage.
Consistency: Stick to consistent coding styles, naming conventions, and architectural patterns. Consistency cuts down the mental overhead needed to work with the codebase.
Continuous Improvement: Always look for ways to improve. Regularly assess and refine your processes, tools, and techniques to strive toward minimal entropy.

Conclusion

By understanding and applying the principles of thermodynamics to software development, we can better handle the natural complexity and entropy in our systems. Embracing practices that cut down complexity and boost order helps create more maintainable, efficient, and robust software. Just like in thermodynamics, acknowledging and managing entropy is key to achieving long-term stability and success in software development.

Acknowledgement

This topic came to life after reading “Explaining Humans” by Dr. Camilla Pang. She draws parallels between human behavior and the laws of thermodynamics. While reading it, I started seeing those connections with software development too. If you’re into (popular) science books or curious about human behavior, I highly recommend this book!

Vitest In-Source Testing for SFC in Vue?

Joran Quinten — Tue, 16 Apr 2024 14:51:07 +0000

Vue adopted a Single File Component philosophy, which has some benefits over splitting concerns, which you can read up on in the official Vue Docs. From a SFC philosophy, you’d want everything that relates to your component in a Single File. So let’s explore this take with our component tests as well, because why would your tests be any different than your scripts, template or styles?

We’re going to leverage a feature that Vitest offers, out of the box, to a Vue example code base. Bear in mind that this approach would be applicable to other implementations that leverage Vitest just as easy. Also, this is a thought experiment. Vitest docs officially do not recommend this approach, but I think it’s an interesting approach to investigate.

Let’s set up a small Vite Vue project

For a TLDR; The code can be found on https://github.com/joranquinten/experiment-vue-pure-sfc if you’re only interested in the end result.

We’ll keep it simple, because it’s about exploring a concept. You can create a small boilerplate using the following command:



npm create vite@latest vue-pure-sfc

Be sure to select the Vue framework (or your framework of choice) and, well, the rest of the config is up to you. Running the npm install and npm run dev commands should at least net you with the default template.

Next we’ll install Vitest and happy-dom to the project by running:



npm install --save-dev vitest happy-dom

We’ll add a vitest.config.ts file with the following contents, where we merge the default Vite config and extend it with Vitest specific settings:



import { defineConfig, mergeConfig } from 'vitest/config'
import viteConfig from './vite.config'

export default mergeConfig(viteConfig, defineConfig({
    test: {
        globals: true,
        environment: 'happy-dom',
    },
}))

For testing Vue specifically, we’ll install Test Utils:



npm install --save-dev @vue/test-utils @vitest/coverage-v8

And if you use Typescript and don’t wan’t your editor to squiggle about the it and expect missing from the types, just install the Jest types to your project:



npm install --save-dev @types/jest

We’ll add a testing script to our package.json to execute our tests with ease:



...
scripts: {
  ... abbreviated
  "test": "vitest --dom --coverage",
  ... abbreviated
}
...

Now we can run our tests from the terminal with the command:



npm run test

It will fail horribly, since we don’t have any tests. Yet!

A Counter Component

As usual when we want to showcase some interactive component, we’ll create a simple counter. There is a simple example even in the boilerplate, but for testing purposes, let’s create a new one. We’ll create a file in the ./src/components folder and name it Counter.vue. It easiest if you grab the contents from the example repository: https://github.com/joranquinten/experiment-vue-pure-sfc/blob/master/src/components/Counter.vue

In the ./src/components/HelloWorld.vue file we’ll add it to the template, just to quickly show you that it’s working, see: https://github.com/joranquinten/experiment-vue-pure-sfc/blob/master/src/components/HelloWorld.vue

The Counter accepts a minimum and maximum value and can be incremented, decremented or reset if it’s dirty. Simple enough.

We can also add our unit tests the usual way, in a separate file, such as ./src/tests/Counter.spec.ts with testing methods that validate the features of the component: https://github.com/joranquinten/experiment-vue-pure-sfc/blob/master/src/tests/Counter.spec.ts

Having all this in place, we can check whether our component works by running our test command in the terminal:



npm run test

Now it will run a test file and should return a successful result.

This is great! We have a component and it’s tested with full coverage. Neat! From SFC perspective, we have all the logic that belongs to the component in one place, right? Well, not the tests. So we could debate whether a unit test (or specification) is part of the component, but we can safely state that they are very closely coupled!

In-Source testing to the rescue!

With Vitests In-Source testing feature, we can actually achieve this! There’s a caveat though. The script setup notation basically encapsulates the defineComponent function. We want to do something extra here, so we’ll convert the script setup notation to the more explicit Composition API notation. We’ll first store our component in a variable before exporting it. The reason for that will become clear!

Obviously, we’ve already have our tests in place, so we can easily test our little refactor with our existing tests:



npm run test

Everything checks out. Now we have some wiggle room to include more scripts into our component, namely our testing scripts! 🤯

Before the end of the script tag, we can import our testing packages like so:



<script lang="ts">
// ...the whole bunch of Composition API code

import { shallowMount } from "@vue/test-utils";
if (import.meta.vitest) {
  const { it, expect, describe } = import.meta.vitest;
  describe("Counter Pure SFC", (): void => {
    // ... Pay close attention here! 🧪 👀
  }
}
</script>

Now we can move the contents of our Counter.spec.ts file from the describe block to the describe block in the Vue component and remove the Counter.spec.ts file altogether!

With a final tweak of the vitest.config.ts, we can have it ingest and execute the test blocks in our .vue files as well:



import { defineConfig, mergeConfig } from 'vitest/config'
import viteConfig from './vite.config'

export default mergeConfig(viteConfig, defineConfig({
    test: {
        globals: true,
        environment: 'happy-dom',
        includeSource: ['src/components/**/*.vue'], 
    },
}))

Not on production!

And to make sure our test code doesn’t end up on production, we can update the vite.config.ts accordingly:



import { defineConfig } from 'vite'
import vue from '@vitejs/plugin-vue'

// https://vitejs.dev/config/
export default defineConfig({
  plugins: [vue()],
  define: { 
    'import.meta.vitest': 'undefined', 
  }, 
})

By setting the import.meta.vitest to undefined it will collapse the if statement and remove it from the production build. 😇

Now, by running the command for testing:



npm run test

You get to execute the components specification from inside of the component!

Single File Components with embedded Tests?

So, let’s recap on this whole experiment, from SFC philosophy, would is make sense to embed your tests?

Well, no. Although theoretically a specification can be considered part of the component, it’s not part of the core feature that the component unlocks. While it can be helpful to have the docs available when refactoring a component, it decreases the overall readability of the component. In this case I’d say that clear concise component code is more valuable in your code base than being an SFC extremist.

Embedding the tests doubled the lines of code from 78 to 156!

That’s excluding the conversion from script setup notation to the more verbose composition API. And the tests aren’t even that extensive! 🙀

This was just a silly experiment, to see how In-Source testing capabilities would affect the way we think about components. There may even be valid use cases where this can be very helpful: for very complex utility functions it could add to the readability and understanding of said function. And, spoiler alert: the Vitest docs also do not recommend using this for Component testing.

If you are interested in the setup, have a look at the repository to run the code for yourself!

The Role of a Program Committee Member: A Behind-the-Scenes Look

Joran Quinten — Tue, 19 Mar 2024 13:04:15 +0000

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.

Understanding the Program Committee's Responsibilities

So what does the committee do, exactly, apart from getting together in top secret meetings ahead of a conference?

Keeping Up with Trends

One of the primary tasks of the Program Committee is to stay up to date with the latest trends in the industry. From emerging technologies to evolving methodologies, we aim to include topics that resonate with our audience and reflect the current and future state of the JavaScript ecosystem.

Crafting a Cohesive Program

We ensure that every talk, workshop, and panel discussion aligns with the conference's goals and objectives. We review submissions to curate a diverse and engaging program that caters to attendees of varying backgrounds and interests.

Advocate for Diversity and Inclusion

Diversity is not just a buzzword – it's a guiding principle of our committee. We strive to represent a broad spectrum of voices and perspectives, fostering an inclusive environment where everyone feels valued and heard.

Identifying Potential Speakers

Scouring the tech community for standout speakers is a thrilling yet challenging task. Whether it's reaching out to industry giants, GOATS or discovering rising stars, we're constantly on the lookout for individuals who can inspire and enlighten our audience.

Leveraging Expertise

Each member of the program committee brings their unique expertise to the table. We all have JavaScript expertise and everyone brings something extra to the table. My personal perspective brings particularly frontend development, UI / UX design or engineering management topics to the table. Our diverse skill sets enable us to cover a wide range of topics and ensure a well-rounded program.

My Role on the Committee: A Personal Perspective

As a member of the program committee, I play a role in shaping the conference agenda. From participating in group discussions to reviewing content submissions, I actively contribute to the creation of an engaging program.

Staying Informed and Engaged

Staying informed about the latest trends and advancements in the field is key to fulfilling my role effectively. I dedicate time to research and networking, ensuring that I can provide valuable insights and recommendations to enhance the conference experience.

Promoting the Conference

Beyond program development, I actively promote the conference via social media channels and professional networks. By spreading the word and generating excitement, I help attract top-notch speakers and ensure a successful event.

The Path to Becoming a Committee Member

My journey to joining the program committee began with a simple connection – speaking at the JS Nation conference. Through continued engagement and collaboration, I was invited to join the committee, expanding my involvement in the tech community.

Perks and Rewards

While the role of a program committee member comes with its challenges, the rewards are plentiful. I’ve gotten to meet people like Wes Bos, Kyle Simpson, Evan You, but also people who are very passionately working on their tools or products and happy to chat. It's an enriching experience that offers numerous benefits.

The Cost of Commitment

Very little in life comes for free and this is no different. From attending meetings to sifting through and reviewing 400+ submissions per conference, it demands time, effort, and dedication. Yet, the opportunity to shape the future of tech conferences makes it all worthwhile.

In conclusion, being a member of the program committee is both a privilege and a responsibility. It's a chance to make a meaningful impact, connect with fellow enthusiasts, and contribute to the vibrant tapestry of the tech community. So, the next time you attend a conference, if you encounter us, take a moment to high five one the dedicated individuals behind the scenes – the Program Committee. ✌️

Strategies to reduce complexity

Joran Quinten — Thu, 22 Feb 2024 10:56:43 +0000

Software development is a craft and we can follow many routes to achieving a specific goal. Having this freedom allows us to create simple solutions for very complex problems. That same freedom has a flip side, where very complex solutions can be applied to very simple problems!

To be clear: I don't think anybody purposefully sets out to create complex solutions to simple problems (unless part of an artistic discovery). I think it is a sign of lack of understanding of a certain domain or technology. I also think there are several strategies you can apply to reduce complexity!

Recognizing that complexity originates from lack of understanding, means that reducing complexity is only possible once understanding is increased. Let's take a look at a couple of strategies you could apply.

Long road to success

First of all: it is not an easy journey. The first step is recognizing you have a problem and identifying the size of it. Even then, it can be difficult to convince other stakeholders to invest time on gradually resolving the issue. Doing so without a clear plan is even more difficult, so I'm listing a couple of strategies to possibly use when battling complexities.

Break it down

One of the first steps is to, before the work starts, you spend time to break down a feature into the smallest possible bits and pieces. It has two advantages: it forces you to spend some time on thinking about the feature and what the feature should look like. The second advantage is that smaller parts potentially can already be implemented, deployed and add value in iterative steps. Preferably, you involve multiple people into breaking it down, to get a conversation going on the topic. That in turn has the benefit of sharing knowledge across multiple contributors.

Ideally you would incorporate the "can it be smaller" mantra in your daily workflow and preferably before you start building. However, this can also be applied after the feature has been delivered, as part of the refactoring process.

Separation of concerns

In line with breaking a feature down into multiple smaller ones, it might result into a logically separation of concerns, which means that components or services have a very singular role and purpose. This means that these individual parts also set you up for future success, because small additions to a isolated component are much easier to oversee than inserting a feature into a spaghetti-ish code base. Predictability of the landscape increases, which again, reduces complexity.

Separating or isolating components can happen in several levels: it can be done on a component like level, or in more extreme cases, could also mean revisiting your architecture.

Refactor as a learning experience

Considering that complexity creeps in when we lack understanding, refactoring is not just a means of reducing complexity, it serves a double purpose as well, where it allows for getting more familiar with a landscape. Sometimes you just have to build something first before you can optimize (or simplify) it. That's perfectly fine! The risk in practice is that development is considered done when it's functional and deployed to production.

This can be the result of a MVP mindset, but consider that an MVP is not meant to remain in that state: it's meant to test out a concept or idea with the intent of learning from the process and applying those learnings.

Refactoring or revisiting a solution can help in being able to look at a problem in hindsight and from a different perspective. You will see new ways of solving issues and will recognize patterns that emerged organically while you were working on the solution. Having this perspective allows you to group them more logically.

I'd recommend refactoring as part of a shared effort, using multiple people to work on the refactoring process.

Pair, mob, extreme!

Working on a solution by yourself, could mean you become part of the problem. Sometimes you can lose the overview since you're zoomed in on getting a feature working. Pairing up with one or more additional developers serves a couple of purposes: you get the benefit of a hive mind of problem solving abilities. Individuals tend to have a certain area of expertise or interest, which leads to biased solutions. By collaborating on a feature at the same time, you'll be able to combine expertises which evens out a natural bias, adds multiple perspectives to a solution and obviously benefits the increased shared knowledge between contributors.

There are numerous advantages of forms of multiple people simultaneously working on an issue. If you're not experienced with these forms, I encourage you to experiment with fully adopting them for at least a three month period and see how you experience it.

Simplify the landscape

This is a bit of an escape hatch, but could very well be a viable long term strategy. If you've attempted the above strategies, but experience continuing returning complexity, it might mean that the landscape simply isn't able to facilitate your goals. Obviously this is more difficult to change and highly depends on the influence and resources you have at your disposal.

If your reach is not big enough to control changes in the landscape or architecture, it might be worth considering adding specific new parts. Maybe the benefit of building and maintaining your own set of microservices is worth the effort if you're able to exert more control in smaller, more manageable areas.

Keep it Simple, Stupid!

The KISS acronym is very well known, but not widely adopted. In daily development, rabbit holes of spaghetti code can be very luring. Complexity can stem from lack of understanding or lack of following up on experiments.

The above strategies are no one size fits all, but hopefully serves as an inspiration for strategies to improve. Reducing complexity takes time and effort, but it is also an essential part of future-proofing your software, so it should be treated with the same (if not more) attention as crunching out new features.

Winning at CFPS: How to stand out at tech conferences

Joran Quinten — Wed, 06 Dec 2023 23:38:02 +0000

If you've ever been to a tech conference, you know the thrill of being part of a gathering where ideas flow faster than the coffee. Whether you're a seasoned conference-goer or a first-timer, the journey from submitting a Call for Paper (CFP) to standing on stage is a rollercoaster of excitement, nerves, and hopefully, success.

So what's a CFP precisely?

Let's start with the basics: CFP stands for Call for Paper, a process where conferences invite potential speakers to submit proposals or ideas for talks. The CFP period is a battleground, and the early bird truly catches the worm.

Early birds

Submitting your topic ahead of the crowd might just score you a sweet spot on the conference agenda. Why? Because conferences love to hype up their events by announcing speakers and their intriguing topics in advance. If you're the first to submit a particular topic that interests the committee, chances are you will at least be considered, simply because of your excellent timing!

How to Stand Out

Now, imagine this: there's a conference, and they've received a mountain of CFPs, maybe even 500+. How do you ensure yours stands out? You can follow two paths.

You could go niche, but be cautious – too niche might be too risky. If you're in the web game, consider diving into accessibility, performance, or security – areas that are like hidden gems waiting to be discovered. Bonus points if you angle your talk to the conference's tech stack if applicable.

If you're not as comfortable or knowledgable about these niche topics, you may very well have a strong opinion about mainstream topics. In this case though, competition is much more fierce and you need to convey your topic in a clear way to the committee.

The Power of Reputation

Having a reputation in your field is like having a VIP pass. If you're recognised as an expert, you might even get an invitation to speak without breaking a sweat. Not everyone dares to step onto the stage, so if you do, you're already ahead of the pack.

Crafting the Perfect CFP

The title is your first impression – make it count. A clear yet creative title is your golden ticket to grabbing attention. The short description is your elevator pitch – concise, non-ambiguous, and a teaser of the knowledge bomb you're about to drop.

The longer description is your playground. If choices are tough, this is where you make the difference. Unsure? List your talk's index or slide titles to give a taste of your talk's journey to better inform the committee. If they're reading the description, they already have some interest.

Don't forget the extras – previous talks, social media profiles – they're like your CFP's credentials.

To Recycle or Not to Recycle?

We know how much time it takes to create a talk and we appreciate that practice makes perfect. It’s not a bad thing to submit a talk to multiple conferences. But when you do so, bear in mind that repeating the same topic for a similar audience, it devaluates your submission.

💡 Pro tip: You can keep the core of a talk similar, but modify theming to better fit with the conference of choice it shows you're aware of your audience!

The Dark Side of Standing Out

Typos and readability matter. Even if English isn't your first language, clear communication builds trust. And please, resist the temptation to let AI write your description – it's like bringing a robot to a human party.

Remember, your online presence matters. Your views on social media can impact the conference's reputation, so tread carefully.

The Final Stretch

With these tips, you're armed and ready to conquer the CFP jungle. Just remember, popular conferences swim in CFPs, and rejection isn't a personal attack. If your talk doesn't make the cut, follow up for feedback – it's valuable feedback for your next CFP adventure.

Good luck out there! 🖖

Navigating the Vue.js Book Writing Odyssey: Striking a Balance Between Code and Education ⚖️

Joran Quinten — Tue, 26 Sep 2023 08:49:18 +0000

Since embarking on the journey of crafting my book, "Building Real-world Web Applications with Vue.js", I've realised that writing educational content is an art in itself. 😅
While I've been accustomed to producing the occasional article for my personal website, which usually convey my musings or delve into specific topics, the task of creating a book called for a different approach.
Let me walk you through my process and share insights that could prove valuable to budding authors and educators.

The Crucial Role of Structure

The journey started with the creation of a well-structured outline for the book, encompassing all the topics we aimed to address. This outline turned out to be indispensable in keeping the scope of each chapter in check. Scope creep is real, especially when your goal is to teach and deliver comprehensive projects.

Once I had the initial drafts of the first chapters, I settled into a working methodology that suited me. While it may not be a one-size-fits-all solution, I believe it's worth sharing. I call this the "Works for Me Approach™"!

Given that the book is centered around Vue.js projects, each chapter revolves around constructing a self-contained project, encompassing a diverse range of topics. When initiating a new chapter, I revisit the teaching objectives to refresh my memory on the fundamental concepts I intended to convey.

A Methodical Approach

I kickstart the chapter by building the app as a prototype, complete with all the necessary features. Throughout this process, I inevitably find myself refactoring certain sections and making adjustments to ensure everything functions seamlessly. If the chapter contains technology I'm not entirely familiar with, I often will (and need to) refer to documentation to adopt best practices, ensuring I can pass on this knowledge accurately.

On occasion, due to constraints in complexity, I might need to develop custom implementations or wrappers around libraries. While I'd prefer to avoid such scenarios, they can become necessary to present a realistic picture of a production-ready project.

Throughout the development phase, I maintain a dedicated Notion document for each chapter, recording installation steps, decision points, and notes to replicate the building process when it comes to writing the content. My objective is to deliver the software with full feature completeness, but it doesn't have to be polished yet.

Balancing Software and Process

One common challenge I've encountered is explaining large code blocks. In typical software development, as we all know, you don't start with the perfect solution from scratch; you build, test, optimise, add new features and refactor all the time. When it comes to teaching, you're walking a tightrope between showcasing the process of software creation and sharing the final solution.

Depending on the topic, I decide which aspects to highlight from both the process and the solution. I believe it's important to not give the impression that everyone crafts optimal, well-structured code right from the outset.

Embracing Creator Mode

Once the initial project is complete, I transition into "creator mode". This involves utilising the example code to rebuild the solution from scratch while meticulously documenting each step. I don't adhere to a strict plan during this phase, but I ensure the code runs without errors after each step. This way, readers can follow along and verify their progress with confidence.

Lessons Learned and Future Revisions

Through this process, I've learned that teaching complex topics with extensive code blocks can be challenging. To mitigate this, I strive to write code that's as readable as possible, adhering to Clean Code principles, and augment it with comments that bridge the gap between the reading material and specific code features.

Additionally, I've come to appreciate the significance of screenshots and incremental code pushes to a public repository, which I reference in each chapter. These elements provide readers with visual clarity and a hands-on experience.

At this point, I feel more at ease in creating this type of content. While it's undoubtedly labor-intensive, it's also an opportunity to explore techniques beyond my daily routine, enhancing my comprehension of these concepts.

I'm fully aware that what I'm building has a limited shelf life. Software evolves, ushering in new concepts and best practices. This necessitates future revisions to keep the content aligned with the evolving landscape.

The Path Forward

In my case, I'm primarily creating written content, but I can envision these steps being equally applicable to the creation of video tutorials. If I were to embark on a video tutorial series, I'd likely utilise the chapter notes as a blueprint for crafting the videos.

Who knows, a video tutorial series might be on the horizon?

Writing this book has been an enriching journey, and my hope is that these insights will assist fellow educators and authors in their own endeavours.

Stay curious and continue sharing! 🖖

Career Development in Web Development

Joran Quinten — Thu, 20 Apr 2023 16:54:59 +0000

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.

Lately though, I've found myself more and more transitioning into a lead role. And I've noticed some key differences in my day to day activities and responsibilities. To help you, fellow developer, navigate your own career path, I think it makes sense for my to write about my journey.

Organic path

Now my journey has not followed a predetermined path or goal. I was happy starting out where I did. The only constant was that once I reached my personal potential within an organisation or project, I started to look at different opportunities. Those new opportunities would be tied to a certain step up: in compensation, benefits, topic and new growth possibilities. I did not set out to become a lead developer at Jumbo!

I have been lucky enough to always been able to find something that aligns with where I was at that point in time. It wasn't the most efficient path, to be honest though. The most strides I think I made at my current organisation, where I started as a humble frontend developer (with seniority) but was also given the space to tap into my other talents.

Being given space is only part of the equation: you also need to use that space! I've been actively collaborated on the founding of some key projects at Jumbo, because I expressed interest in doing them and by being visible within the organisation.

Visibility is key

This is a lesson I learned while I was working as a consultant. In order to grow in a consulting organisation: you need to actively work on self promotion. Just doing a good job at a client is not enough. Especially in large organisations. If people don't know you exist, you will not be considered for any opportunity. It's as simple as that. So that means actively contributing to the organisational proces. You can do this in any way that suits you, as long as it connects you to peers or (even better) superiors. As part of an organisation, you are a tool or product that helps facilitate the primary business proces. By connecting, you become a more valuable thing in an organisations' inventory.

Taking that knowledge with me has helped me in actively promoting myself in any other project or organisation that I've worked with. It's not about pretending, but about highlighting your qualities and aspirations.

Goals and KPIs

I don't like personal development plans. What I do like is a long term vision with clear short term goals. I believe you should be able to set and reset goals on, say, a monthly basis.

In order to lay down goals, you need a long term vision for yourself and align it with organisational goals. For me, a long term vision has always revolved around creating visibility and engagements about my work and the organisation I'm working with. This usually ties in nicely with promotional and hiring goals of an employer. If those are aligned, you can create a space for yourself to expand in a certain direction.

This is why I have been doing public speaking events, collaborate with educational institutions. I apply that experience also to internal connections and collaborations. All these activities, that are not part of my primary role, I get to do in agreement with my coach/mentor/manager, because I can show that they contribute to my long term vision.

Evaluating

Growth is usually measured in achievements and compensation. I tend to plan quarterly meetings as performance reviews to discuss the things I've achieved in the past period. I always keep a record of my activities and the outcome. Usually, I set the agenda for these meetings and provide the points I want to discuss upfront as well as the outcome. This helps me to structure the conversation around the things I want to address.

Make it your own journey

In many organisations there are clear and formal definitions of what you need to achieve for any role. You can use these to map your short term goals and milestones. I would recommend though, to look at a long term vision for yourself. Something that can extend your current position and organisation your working with. If you have that, you can validate if any of the steps in between contribute to that vision. I think that helps massively in growing yourself.

UX is not about design (at all)!

Joran Quinten — Mon, 19 Dec 2022 10:35:39 +0000

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.

From my educational background, I've followed a curriculum that used to dedicate equal amount of time into domains that can be summarised as software, design and communications. A perfect mix of complementary disciplines I think. From that background, and my experience as being part of different software building teams and organisations, gives me some credit in weighing in a bit.

So what's all this fuss about?

Well, as Erik points out, UX is not the same as designing a pleasant interface. It is, as the name implies, all about the user. And more specifically, about how the user experiences your product or service. With that emphasis, it is actually very strange that UX is so misinterpreted by so many. We've all seen profiles like "interface designer", "frontend engineer", "backend engineer", "quality assurance", "data analyst" arise, because these are important roles when you're building software from the development perspective.

But who are we building software for?

Exactly.

Focusing on the customer is focusing on where the money is. It is, from that context, very strange indeed that we even allow to hire UX positions and allowing them to do pixel pushing in creating visual designs!

So to my mind, and since it seems nothing is set in stone, we can start to "armchair imagineer" what a UX should contribute to software development. I am personally inclined to think the discipline spans everything dealing with users and should be an omni channel discipline. For the sake of this argument however, let's focus on creating software.

I actually have a lot to work with already, since Erik wrote up an excellent article on Medium where he lists some desired responsibilities:

Field research
Face to face interviewing
Creation of user tests
Gathering and organising statistics
Creating personas
Product design
Feature writing
Requirement writing
Graphic arts
Interaction design
Information architecture
Usability
Prototyping
Interface layout
Interface design
Visual design
Taxonomy creation
Terminology creation
Copywriting
Presenting and speaking
Working tightly with programmers
Brainstorm coordination
Design culture evangelism

This is quite an extensive list, but I'd like to make it even longer, because I feel it is coloured by a traditional "design" background. I'd like to add the following, which has more of a technical background:

Drafting performance budgets
Security policies design
Responsive design
Support advocate
A11y advocate
Progressive Enhancement advisor
Search Engine Optimiser
Design / developer facilitator
State architecture design

I have a feeling there's an even bigger extent, but these topics cover a lot of ground already and serve a secondary purpose. I can't speak for the responsibilities that Erik lists, but let me explain what I mean with my additions:

Drafting performance budgets

We know that performance is a driving factor in how a user perceives software and how it heavily affects their behaviour while using your product.

Security policies design

Nothing impacts the brand value more than a data leak or breach where users find out just how much of their personal data was handed over in good trust. Damaging this trust could potentially lead to devastating damage to your softwares and organisations reputation.

Responsive channels design

I'm not just talking about how a component or website scales in a web browser, but also how it scales across platforms. Are you exposing key features on web and also an app? Also for a smart watch? How about voice assistants? Responsiveness means being able to react to different platforms just as much as the size of the platform. This segues nicely into the next one:

Support advocate

If we support across apps, are you considering the different types of agents and devices using your software? A low end phone has less resources than latest flagship models. When serving web environments, what browser memory can you work with to have a decent experience?

A11y advocate

Bear in mind that 15% of the worlds population has some form of impairment. 3.44% Of the worlds' population has some form of visual impairment. That's 275 million people. Doing exclusively layouts and pixel pushing is a solid means of excluding users. That why accessibility matters and plays a vital part in your software. Generally, a11y scales well with UX.

Progressive Enhancement advisor

For all the bells and whistles in your software arsenal, you'd have you consider how you could improve a users' experience with embedded technologies, or how to fallback when some technology is not supported.

Search Engine Optimiser

One of the important entry points to any web application is organic search results. Therefore, one of the important users, albeit a non human visitor, are crawlers. How do crawlers perceive your software? Do they encounter errors? Duplicates? How do you deal with those?

Design / developer facilitator

Okay, here I might have some overlap with the "Working tightly with programmers" point, but I feel it's not just important that the UX person has a tight relation with programmers, I think it's just as important as designers (as well as any other discipline).

State architecture design

When you have multiple platforms in your domain, how do you deal with or handle the current state of what the user is doing? Do you have silos or are platforms able to take over the tasks of their counterparts? How is that managed and what part of the state is shared?

Support advocate

Who makes the decisions on what platforms and technologies to support? Are you doing native iOS but not Android? Does dat mean that Android users get a web app? Does a web app offer the same kind of user experience as an app?

The purpose

So, as I was teasing before this list, it's extensive for another reason: there's no way that a person can do all of these things. It doesn't mean that the list is too long. It means that user experience is embedded in basically everything that we do while building software.

I could even argue that the Developer Experience (DX) is also part of the UX responsibility (it's just another type of user, right?). Including the DX means writing docs, guidelines, linter rules, pipeline optimisation, git flows, automation, backup strategies. The list goes on (I can do this all day).

Now what?

So this is a problem. The field of UX can be defined as "everything", simply because everything we do has some form of effect on the user. Otherwise there's no point in doing it, right?

In my mind, the way that we could make this work is by adding a bit of UX awareness to every software building discipline that we have, where we assume that with some education and understanding, we can improve the UX while coupled to the teams' efforts in an iterative way. Step by step, building on the expertise of domain experts. There are gaps to fill obviously, since we'd need to educate those domain experts, and then still they will not have all of the resources or knowledge to say, conduct a face to face interview.

For me, this could lead to a UXer being a coach or mentor to a team. To help them guide the decision making process, facilitate communications and help with understanding the users' needs. On top of that role, there should still be room for doing the specialties, such as the face to face interviews, taking the lead in user tests etcetera.

The list of responsibilities is long. We could draft long lists of tasks for developers as well and we don't expect them to be experts in everything, because we expect different specialisation from developers.

Change the paradigm

I agree wholeheartedly with Erik that the "designer" moniker does not cover the responsibilities of a UXer at all. Get rid of it. Taking the list I see just as much tasks that tie to an architect, facilitator, manager, advocate or analyst moniker. The UX Designer concept has been rooted in our minds with the wrong meaning, so we should change.

All you UX "Designers", I challenge you to pick a new title. One that suits your specialty but please don't call yourselves designers anymore.

Automated Moderation using OpenAI

Joran Quinten — Mon, 12 Dec 2022 11:39:55 +0000

To get started, you need to sign up at OpenAI and generate a key. Next we'll setup a simple Nuxt project. Just use the following command to scaffold out a starter project and adding the openai package (nuxt docs prefer using yarn but feel free to follow the npm or pnpm steps):

npx nuxi init openai.moderation
cd openai.moderation
yarn install
yarn add openai
yarn dev -o

This should result in the starter project running on (typically) http://localhost:3000. Now open the project in your favourite IDE, and let's get started!

Configure the key

Create an .env file in the root of the project containing this line (replace with your personal key):

OPENAI_API_KEY=ALWAYSKEEPSECRETSTOYOURSELF

Next, open the nuxt.config.ts and make sure it looks like this:

export default defineNuxtConfig({
    runtimeConfig: {
        OPENAI_API_KEY: process.env.OPENAI_API_KEY,
    },
})

Setting up the API

In order to communicate to the OpenAI endpoint, we'll need a server of our own. In Nuxt, adding an API endpoint is just as easy as adding a file in a server/api folder. So first create that folder structure and place the following in a file called moderate.post.ts:

export default defineEventHandler(event => {
    const body = await readBody(event)
    return body?.message
})

This will just return whatever we post to the /api/moderate endpoint (Nuxt will set up the routing for us).

The input component

We're going to create a small component that just takes in text input and will hit the endpoint we've set up when submitting, so that we can validate the response.

Create a Moderate.vue component in a components folder in the root of the project.

Let's start by defining the scripts using the script setup notation:

<script setup lang="ts">
const input = ref("");
const result = ref([]);

const onSubmit = async () => {
  const response = await $fetch("/api/moderate", {
    method: "post",
    body: { message: input.value },
  });
  result.value.unshift(response);
  input.value = "";
};
</script>

First, we're setting up handle to take care of the input and the result and we're defining a hander to call the endpoint we've already setup, appending the input as a message property on the body. (The .value refers to the mutable and reactive reference)

Now we'll add a template with:

A small form containing an input;
A submit button that will call the onSubmit handler;
A place to display the output of the endpoint

You can style it however you want, it's however not really the purpose of this tutorial. Just go ahead and paste this below the script tag:

<template>
  <div>
    <div class="input">
      <input type="text" v-model="input" />
      <button type="submit" @click="onSubmit">Validate moderation</button>
    </div>
    <div class="output">
      <ul>
        <li :key="i.id" v-for="i in result">
          {{ i.results }}
        </li>
      </ul>
    </div>
  </div>
</template>

Now save this file and let's load the component on the app.vue, by replacing it's contents with this:

<template>
  <div>
    <Moderate />
  </div>
</template>

You should now see the component running on your localhost. Once insert some text and hit submit, it should be returned by our own endpoint and show up in the component as part of the list item.

Adding intelligence

Finally we'll update the moderate.post.ts file to make use of the OpenAI capabilities. The moderation API is one of the more straightforward ones, so it's a good one to get started with. Instead of returning the body.message immediately, we'll first configure the OpenAI client by instantiating it with the key. Then we'll query the endpoint with the contents of the message. This means we also need to change the handler to an async function! The file should look like this:

import { Configuration, OpenAIApi } from 'openai';

// it's an async function now!

export default defineEventHandler(async (event) => {
    const body = await readBody(event)

// setup the configuration

    const configuration = new Configuration({
        apiKey: process.env.OPENAI_API_KEY,
    });

// instantiate the openaiClient

    const openaiClient = new OpenAIApi(configuration);


// Make the call to the moderation endpoint

    const res = await openaiClient.createModeration({
        input: body?.message,
      });


// return the result

    return res.data
})

That's it. So you now have the opportunity to test this out be being very aggressive towards the input field. You should see an assessment of your input by various categories and grades, similar to this example:

{
  "id": "modr-XXXXX",
  "model": "text-moderation-001",
  "results": [
    {
      "categories": {
        "hate": false,
        "hate/threatening": false,
        "self-harm": false,
        "sexual": false,
        "sexual/minors": false,
        "violence": false,
        "violence/graphic": false
      },
      "category_scores": {
        "hate": 0.18805529177188873,
        "hate/threatening": 0.0001250059431185946,
        "self-harm": 0.0003706029092427343,
        "sexual": 0.0008735615410842001,
        "sexual/minors": 0.0007470346172340214,
        "violence": 0.0041268812492489815,
        "violence/graphic": 0.00023186142789199948
      },
      "flagged": false
    }
  ]
}

If you're done with this example, one of the fun ways to play around with OpenAI is by using the image generation API. With the basis we've laid you should be capable of either modifying the existing code, or making your own integration in a framework you prefer.

Using these sort of tools could help you a lot when dealing with publishing user generated content. Bear in mind though, that this is just an example and not a real world implementation. Also, as OpenAI suggests, always keep some human eyes on hand when dealing with these sort of things. A valid use case for this example would be to preemptively flag submissions before publishing.

Using AI to reduce the load in humans without completely removing them, would be sensible and a good use of current capabilities. AI, just as humans, still has flaws, but we can utilise it to assist us in simple tasks.

Playwright versus Cypress

Joran Quinten — Thu, 08 Dec 2022 09:00:58 +0000

I was seeing a lot of Playwright mentions in my timelines recently, so I decided to investigate what the fuss was all about. Playwright, as it turns out, is a tool for executing end to end (e2e) tests, similar to Cypress.

With Cypress being my go to tool to integrate e2e tests, I figured I could do a comparison on the two, to see which better fits my needs at this point.

I want to stress that both tools are very good at what they do, apart from edge case scenario’s I don’t see a direct need to migrate existing projects from one to the other.

Having said that, let’s talk about end to end testing. If you are working on complex applications it becomes increasingly difficult to maintain quality in existing features. Introducing a change that affects an existing feature is commonly known as a “regression bug” and you want to avoid it at all cost!

Before the dawn of automated tools, these type of tests were done by hand, by a human tester which had to navigate entire flows and screens to assess whether all of the normal flows and edge cases were still functioning. You can imagine the scale of these tasks!

Enter automated e2e tests. As a developer or tester, you can write and automate these tasks (and as we know, you should!) so you that the entire test suite of features can do the heavy lifting for you, without losing concentration or human error.

Similarities

Having done a quick side by side comparison, the similarities are most obvious. Cypress and Playwright both automate the testing for you and integrate nicely with your development flow. Since they’re both JavaScript based, the language and selectors are very familiar to developers. Although Cypress is a bit more of it’s own flavour of selecting, nothing to fret about honestly.

Both of the frameworks are open source packages which you can easily install on your projects and execute in any pipeline, in a visual interface or from a terminal. They both offer component testing, feature testing, screenshotting, adjusting the viewport in different mainstream browsers (Playwright offers Webkit). Both have forsaken ie11, which is something we shouldn’t even address anymore these days (the hurt is still there 😢).

Bottom line is that basically they both offer similar capabilities with minor differences. The support for Webkit by Playwright might be a deal maker for some, depending on the investment in 100% cross browser quality assurance.

Differences

So can we try and spot some differences? It’s the little things where Playwright is a bit more optimised for delivery. It has a bit of a larger package size than Cypress (expanding with adding more browsers), but has less dependencies as a whole. Fewer dependencies means slightly quicker installs in an automated runner.

Playwright also uses the async await pattern when it comes to assertions, rather than what Cypress does in terms of retrying assertions. Playwright also allows you to run several browsers concurrently, which potentially saves heaps of time depending on the coverage you’re after.

And there’s one other thing that Playwright does really well, and that’s supporting multiple pages and domains and setting contexts. This is very useful when dealing with third party features that are part of your flow (dealing with popups, iframes and such).

These differences to me indicate to me that Playwright will scale very well in bigger setups that what I’ve been trying out for now, since a lot of these small decisions amount (especially over time and at scale) to shorter duration of executing the test suite.

A verdict?

Again, for general or small to mid scale usage, Cypress is just fine. Especially if you already have your test suites up and running (I think it’s reasonable to expect more changes coming the Cypress in the future too).

On the other hand, if you’re either starting a new project or haven’t invested a lot yet in setting up your tests, or if you are working on large scale projects, I’d put my money on Playwright. It seems to be specifically tailored to address the pain points that you’d have on larger scales, where every extra second of run time amounts to big numbers at scale.

While the documentation and community of Playwright is emerging, you can expect it to grow as well and with the support of Microsoft on the product you know it has a solid foundation as well.

The Importance of Crossing the Disciplines

Joran Quinten — Sun, 30 Oct 2022 14:57:35 +0000

When you're part of a "modern" software building team, changes are, it is being referred to as "multi disciplinary" or "cross functional". This is to indicate that the team is made up of backend developers, frontend developers, some design role(s) and maybe somebody in charge of metrics and KPIs or some additional, specialised roles.

The thought process here is that if you do that, the team can be completely in control of their responsibility (maybe add some DevOps terminology in there then, as well). Which makes for agile teams.

This is usually fine and dandy when you're in a relatively small environment, since lines are short and by default you are in close contact with your team mates as co workers. It doesn't always scale well though, this concept. Imagine 10+ teams which work for the same organisation. Sure, within the teams' setup, there's still a common goal, but now there are more factors at play: you have to cross align certain goals between or across teams. You need to roll out a uniform branding. Maybe you're dependant on APIs from another team.

Communication channels increase exponentially as employees increase (Sandoe, 2001)

For every team or discipline that's added to an organisation, there's an exponential increase in communication channels. That escalates quickly and is anti scalable!
I've also seen smaller agency like companies fall into this trap, where little margins create a desire to rapidly waterfall through the traditional steps of creating a website or app.

To combat this, companies start to adopt something like the Spotify model in some form or another. Which makes sense right? You want to facilitate those communication lines. Organisations form chapters, tribes and other cross team groups to align on the common ground between those members, which is usually technology based.

That's where things get hairy, because it starts to shift to alignment and communications from what was originally aimed at facilitating a teams' needs and goals, to whatever is on the radar for a certain domain. It takes time and focus away from the team!

As a result, since we're all creatures of habit, I've seen that the alignment on technology level starts to supersede the alignment on domain level. When the communication within a team starts to decline, you are dangerously close to creating small waterfalls within your teams. Which I've seen happening in multiple organisations on several occasions.

By these small waterfalls I mean that processes move one way, with little upstream feedback or communication. This is tempting, but on the long run less efficient than the more agile approach most companies strive for. Where the obvious reasoning is that: software is complex and it is impossible to foresee all complexities before you start a next phase.
In time, this means that the original idea of having a cross functional team, is not providing the value you would expect and could (in worst case scenarios), lead to friction within a team.

As the teams working at Spotify will tell you: the Spotify model is not set in stone. It is constantly changing and also being adopted to the users' needs. So please don't go around creating tribes and chapters if you have no need for them, treat it as inspiration rather than gospel. (Even if you Google for the "Spotify Model", Spotify itself is very absent of the results.)

The core principle should still be to enable those teams in optimal communications within the team. The alignment on tech should just play a supporting role. Make sure that your designers, developers and business analysts stay on the same page and are working together instead of passing down work to each other. This is what I mean with crossing disciplines. Keep crossing those boundaries, because that's how you can co create to build amazing stuff.

Let your designers cultivate an understanding of what the purpose of a microservice is and allow your backend developers to understand performance from a UX point of view, rather than a metric measures in ms. In the end, what you're building is always reliant on multiple factors and disciplines to be successful. The most successful solutions come from teams who have a common understanding of each other strengths and purpose.

Maintaining a Component Library at Scale

Joran Quinten — Thu, 06 Oct 2022 08:11:19 +0000

Before we dive into the topic, a little bit of context would be necessary because we're going to talk about a solution that works for our organisation. Having context helps you in deciding if and what would work in your situation.

So at the company I currently work for, we cater to a big audience. As a big company, we also have a big stake in IT solutions to get our businesses running. A lot of our software and tooling is build in house.

In fact, there's a whole department of IT specialists, collaborating on digital products. To accelerate our web product development, we've built and are maintaining our own component library.

We're using VueJS as our framework of choice, and yes, there are off the shelf solutions we could apply. But we didn't. And we think we have very good reasons for doing the heavy lifting ourselves.

We have a need for more specialised components.
We believe that a component library should match the brand and not the other way around.
We know our customers better than from the perspective of a generic set of components.

Design System

Our component library is an essential part of our design system. It helps us with aligning designers, developers and other stakeholders in teaching us to speak the same language. The goal of the design system is facilitate with quickly building applications according to the rules we've set out.

Putting the customer first 🏆

Our philosophy is to put the customer first. A way of supporting that is by providing an Omni Channel Experience. This means that from a customers' perspective, you have the most seamless interaction with any of our products or service because you are dealing with the company as one entity. To make that as seamless as possible, it just makes sense to use and reuse components and their interactions as much as possible. Because for the online part at least, you then have a familiar interface to deal with.

So we've established that a component library makes absolute sense and we even encourage to reuse not just visual components, but also more elaborate interactions, strengthening the Omni Channel Experience across our solutions.

Now it takes effort to build and maintain a component library. You could do this with a dedicated internal team, working around the clock on adding new features via requests and maintaining the product.

A distributed approach

We did something else. We took a distributed approach, where every team using the library is also part of that team in a way. In practice, what could happen is that you work on a feature and simply use a component to fulfil the business need. Or you find that a component is not capable of meeting requirements. In that case, what happens is that a developer modifies (expands) the component and uses the latest version to fulfil the feature. The library is being improved based on business features.

We believe this benefits us, because of a couple of reasons that fit within our companies' philosophy.

Having this setup establishes an investment in the library. Since you're using and building it, you have a responsibility to keep it purring like a happy kitten.
A distributed approach also ensures that knowledge is distributed across the development teams.
We have short feature cycles on the library, because as a developer you have the freedom and responsibility to modify the library when needed. There's no dependancy on another team.
These small increments are immediately released, which means that other teams immediately benefit from any improvements.

Rules and guidelines 🎲

If you want people to play, you need to set clear rules.

And we did. The most important one is about communication. Share upcoming changes, issues you're facing and share successes!

If you're adding features or new component, also ensure the reusability of the addition. Since you're adding from a business feature point of view, it is likely you need to do some decoupling of the feature and underlying component.

To ensure the quality we set out to automate as much as we can, which seems obvious if you think about it. Anything repetitive should be automated. This doesn't only save time, but it also serves as a more objective way of measuring additions. It's less opinionated than sifting through a pull request when somebody has a bad day.

So this works really well! We're improving our component library on a daily basis, by small increments that everybody can immediately use. This is great!

What about ..? 🤔

There is, of course, a caveat. What happens when you need to work on bigger topics? We do need to upgrade dependencies every now and then and that is something that doesn't fit in with the concept of improving by adding features. There's also the DevOps related activities that fall in similar categories, or even adding or replacing tooling solutions. These are no daily challenges, but they do pop up on a regular basis. Turns out, we have a fitting solution for that as well.

We are encouraged to spend 30% of our time on stuff that is not team related but helps the company in the long run. That is a generous amount of time, if you think about it. What we see happening is that people feel responsible for the library. So when some of these issues arise, people seek each other out to solve the issues. The nice part is that people from completely different teams are seeking each other out to work on a common task from their own interest and motivation, which is awesome.

We've now been employing this way of working for a couple of years. During that time we've seen the library grow and tooling come and go.

The distributed model works for us!

Original article (with slides) on my personal blog