https://anselm-hannemann.com/writings/tools-won-t-solve-it-for-you
Today I read a LinkedIn post by Dan Neciu about XSS still being a real-world problem. That’s one perfect case to show why you either need to:
The underlying problem here always was and still is the same. With more tools and the growing complexity of the web platform and its technologies, it becomes harder to discern what’s truly important. It’s crucial today for front-end developers to know how to use and build web apps with:
Now, tell me this is not already quite a lot to learn and keep in mind. The problem is that we’re still missing the base here for web apps, which today is also known as »Vanilla Web«:
The job market wants developers to build modern web apps in a short amount of time. If you ask AI to build a web app, you’ll get a next.js web app with wild, copy-pasted spaghetti code. It‘s tempting to just use this, but sooner or later, you run into problems like a vulnerability, or you don’t even understand how to extend the code for a new feature anymore.
Career titles for funIn the past years, career titles have changed a lot. While ten years ago there were junior and senior levels, now you also have principal or lead developers. Nowadays, there are a lot of senior developers out there. Who still hires a junior or even offers people an apprenticeship? Sadly, way too less companies. Instead, you hire Senior developers in the hope that they can work on their own and build great products.
What I see is that the title »Senior« just means that people already have a couple of years of experience in building for the web. It does not say much about how good they are in terms of architectural thinking, incorporating common standards, acknowledging how a web browser works. It does not mean they know what accessibility or web performance means or how the CSS cascade works. While there are many devs out there with that level knowing about this, I even saw principal engineers missing such fundamentals.
Level up with Vanilla Web fundamentalsIf you want to give your career a boost, level up by learning the Vanilla Web.
If you want to ensure your company’s web apps are good, let someone external have a look at it regularly. You’re not only doing yourself as a company a favour because it can avoid security, privacy, accessibility or performance issues before they get public but also your teams and employees who can learn from such audits and improve.
Today I read a LinkedIn post by Dan Neciu about XSS still being a real-world problem. That’s one perfect case to show why you either need to:
The underlying problem here always was and still is the same. With more tools and the growing complexity of the web platform and its technologies, it becomes harder to discern what’s truly important. It’s crucial today for front-end developers to know how to use and build web apps with:
Now, tell me this is not already quite a lot to learn and keep in mind. The problem is that we’re still missing the base here for web apps, which today is also known as »Vanilla Web«:
The job market wants developers to build modern web apps in a short amount of time. If you ask AI to build a web app, you’ll get a next.js web app with wild, copy-pasted spaghetti code. It‘s tempting to just use this, but sooner or later, you run into problems like a vulnerability, or you don’t even understand how to extend the code for a new feature anymore.
Career titles for funIn the past years, career titles have changed a lot. While ten years ago there were junior and senior levels, now you also have principal or lead developers. Nowadays, there are a lot of senior developers out there. Who still hires a junior or even offers people an apprenticeship? Sadly, way too less companies. Instead, you hire Senior developers in the hope that they can work on their own and build great products.
What I see is that the title »Senior« just means that people already have a couple of years of experience in building for the web. It does not say much about how good they are in terms of architectural thinking, incorporating common standards, acknowledging how a web browser works. It does not mean they know what accessibility or web performance means or how the CSS cascade works. While there are many devs out there with that level knowing about this, I even saw principal engineers missing such fundamentals.
Level up with Vanilla Web fundamentalsIf you want to give your career a boost, level up by learning the Vanilla Web.
If you want to ensure your company’s web apps are good, let someone external have a look at it regularly. You’re not only doing yourself as a company a favour because it can avoid security, privacy, accessibility or performance issues before they get public but also your teams and employees who can learn from such audits and improve.
Freelancers are often no great marketing people. In a call with my friend Tobias, we realized we've been part of the problem. We found out one of the reasons why freelancers are challenged more and more to get jobs over the past years: We failed to share the value of Freelancers to our customers.
The employee vs. the freelancerThere’s a fundamental difference between most employees in a company and a freelancer working with many clients over time, always living with the uncertainty of losing a project suddenly.
Freelancers have to think about building a successful enterprise that pays your living and ensures a calm and continuous workload. They have to organise themselves, find solutions for edge-cases and live from solving problems that others can’t solve. They are often in projects to challenge the status quo.
Employees care about the goals they get from their managers and strive to do their work best in the agreed amount of time. They have to ensure to not work over-time, to be nice to colleagues and to their managers. Their main goals are to create a safe work environment for everyone, keep institutional knowledge in the company and provide useful work that’s requested by e.g. managers.
Sometimes freelancers see this as conservative mindset but it’s not: It’s certainly a good idea to be in a calm mode and ensure that you work together nicely with all your colleagues so the team and jobs stay consistent.
For the past years most freelancers failed to share success and customer value stories. Instead of sharing about the benefits, the value of our work, they (me, too) shared technical blog posts or ranted over technical problems. How should companies and people working on projects know why hiring a freelancer might be the success story for them?
I myself realized this a couple of times when influential people from big corporations (or small companies) were surprised that they could hire me. And while we talked about it, I realized that decision makers in companies simply never thought about hiring externals and don’t exactly know how to do and what for.
What can freelancers do for companies?For a big German corporation I helped them architect an entire website ecosystem for their global infrastructure. As they did hire an agency before and the project failed, they realized that they don’t own enough knowledge and therefore hired initially five freelancers (later more). We built teams with internals and together made decisions and could create a well working architecture while coaching employees to keep the knowledge in the company. The project was acknowledged as highly successful and leading example by the corporation and outside by media and other companies.
I usually am hired to help building new projects or help with existing projects or teams. For myself, I can help with the following things:
Analytical reviews and problem solving
This is mostly a combination of the former two topics. As freelancer in a company, I try to find out how to best help the team and company:
Agile management and coaching
Most of the companies I join, I realise that they struggle with project management and clear focus on building value and how to define good goals. It’s not that they don’t try but as someone with an external view, independent of managers, I can often help finding out the real issue behind processes and then, together with the managers and the entire team, redefine processes, workflows to be effective: Calm work, solid processes that don’t waste time and high quality results.
The costs aspectI was hired by a startup that had built their MVP but struggled with huge performance issues. They realized that I’m able to help them and within the first four weeks we shipped a 200% performance improvement to production. I had to do all the coding on my own and it was coming with quite a few challenges as it was a widget integrating into other websites. However, the startup could quickly see less customer complaints about performance. We continued working together and I helped them find frontend talent, build teams and scale their frontend application over the next years. I accompanied the startup for four years, sometimes full-time, sometimes only a few hours a month, depending on their needs.
A freelancer is not necessarily cheap to hire. But compared to the full real costs of an internal employee it’s usually not more expensive.
However, a freelancer is hired for gaps in the company. This means they start immediately while companies still search 3 months for an internal position. A freelancer stays until the project ends or the end of the agreement is reached. Often you hire freelancers for e.g. 6 months — so you get a lot of value but only pay half a year.
Beyond the costs, here’s your main Return of Investment (ROI)If you hire an experienced person, it enables your employees to be so much more effective that the costs are negligible compared to the benefits you get as company. A good freelancer takes care to do a good job — it’s his reputation and most freelancers do their job with passion.
Most freelancers stay for a while until things get stable. Then they switch to another opportunity where they can again add their value. I’ve had it a couple of times that I’ve been at the same company again and again for different projects. In between, I worked on a different project and could gain more experience.
I was asked to help a company stabilizing their frontend codebases by introducing a component library. While I spent some time solving this, we realized they have a more urgent challenge where I could help them. A customer asked for accessibility compliance and they struggled to get up to speed here. I helped them audit the relevant application, suggested a roadmap and detailed plan how to solve this and within just three months of time, we managed to fix over 95% of the problems. The team and employees learned a lot and appreciated that I was able to not only help them fix a problem but also coach them so they can now continue working on
Do you have thoughts on hiring freelancers? Let me know! Do you think I can help your team or company? Send me an email!
✈️ I rarely find good analogies but this one I think is spot on:
The Autopilot Paradox
Most of the time, commercial planes fly themselves. Autopilot can handle take-off, cruising, and even landing.
But would you board a plane if told there were no pilots in the cockpit? Probably not.
Because a pilot’s job isn’t just to move a joystick or push buttons. Their mission is to take responsibility when things fail, to decide in uncertainty, and to ensure safety.
I see the same parallel in software development today.
Writing code may increasingly be handled by AI. But the true value of a developer is not typing lines of syntax — it’s abstracting logic from reality, making systems work in practice, and being accountable when they don’t. Tools will keep evolving. The purpose remains.
And just as no one feels safe on a plane without pilots, no company should feel safe relying on technology without professionals who understand it — and take ownership when it matters most.
Would you fly in an airplane without pilots as safety backup? Using AI is going to be part of any company with developers but you still need people who can review AI’s results, take over if something goes wrong or are able to optimise further.
I’ve helped so many teams and companies with the real challenges. It’s usually not a code-specific problem to solve but the organisation of building a product, from idea to market, not only to "production".
You need to build the right thing with proper quality in an appropriate time and budget frame. This is not easy but possible.
This is what you have Lead Engineers, good Agile Masters or specialised Freelancers (like me) for. Send me an email if you want to hire me for your company.
Within CSS you now can do so many things that were the subject for using a pre- and postprocessor like Sass, Less or PostCSS. The latter is still useful in many cases today but the former are less and less important for these reasons:
I’ve been using only PostCSS for years and it’s more than enough. Usually to optimise file size or to produce fallbacks automatically for older browsers. The benefit is that I could almost always just publish the bare source files as well and the website works. And I could switch tools easily at any time.
Cynism points:✈️ I rarely find good analogies but this one I think is spot on:
The Autopilot Paradox
Most of the time, commercial planes fly themselves. Autopilot can handle take-off, cruising, and even landing.
But would you board a plane if told there were no pilots in the cockpit? Probably not.
Because a pilot’s job isn’t just to move a joystick or push buttons. Their mission is to take responsibility when things fail, to decide in uncertainty, and to ensure safety.
I see the same parallel in software development today.
Writing code may increasingly be handled by AI. But the true value of a developer is not typing lines of syntax — it’s abstracting logic from reality, making systems work in practice, and being accountable when they don’t. Tools will keep evolving. The purpose remains.
And just as no one feels safe on a plane without pilots, no company should feel safe relying on technology without professionals who understand it — and take ownership when it matters most.
Would you fly in an airplane without pilots as safety backup? Using AI is going to be part of any company with developers but you still need people who can review AI’s results, take over if something goes wrong or are able to optimise further.
I’ve helped so many teams and companies with the real challenges. It’s usually not a code-specific problem to solve but the organisation of building a product, from idea to market, not only to "production".
You need to build the right thing with proper quality in an appropriate time and budget frame. This is not easy but possible.
This is what you have Lead Engineers, good Agile Masters or specialised Freelancers (like me) for. Send me an email if you want to hire me for your company.
Within CSS you now can do so many things that were the subject for using a pre- and postprocessor like Sass, Less or PostCSS. The latter is still useful in many cases today but the former are less and less important for these reasons:
I’ve been using only PostCSS for years and it’s more than enough. Usually to optimise file size or to produce fallbacks automatically for older browsers. The benefit is that I could almost always just publish the bare source files as well and the website works. And I could switch tools easily at any time.
Cynism points:I do like code reviews.
If my customer and teams let me spend time on it, I’m able to see issues in automation workflows, code quality and knowledge gaps in the teams or workflow issues in general.
💡 The catch is, you need to spend time and thoughts into proper code reviews. Only then the world of seeing possible improvements opens up for you. Check out the code, not only look at it, open dev tools, use a screenreader and so on.
💌 If you need someone looking into your engineering department to improve the happiness of your people and effectiveness or work, send me a message. I still have time this year.
I do like code reviews.
If my customer and teams let me spend time on it, I’m able to see issues in automation workflows, code quality and knowledge gaps in the teams or workflow issues in general.
💡 The catch is, you need to spend time and thoughts into proper code reviews. Only then the world of seeing possible improvements opens up for you. Check out the code, not only look at it, open dev tools, use a screenreader and so on.
💌 If you need someone looking into your engineering department to improve the happiness of your people and effectiveness or work, send me a message. I still have time this year.
As a freelancer helping larger companies achieve their goals, I’ve gained a lot of insights into how people work. And I know many people — including me — have said this for over a decade but it bears repeating: We have fantastic JavaScript (TypeScript included) developers who can build impressive solutions to complex problems. But there are still very few frontend developers today who truly know how to write semantic HTML and build with accessibility in mind. This is more important than ever, especially with the European Accessibility Act (EAA) now being enforced across Europe.
In almost all of the projects I’ve been working on, people relied on component libraries like MUI, Mantine or similar for their React software. If we implemented custom markup, it was mainly a div-soup that actually contained the relevant semantic information — just not in HTML but in custom data attributes. Now when we’re talking about accessibility, it’s the same idea that many developers come up with: Let’s add more informational attributes. Let’s add focus handling.
Adding code is easier than refactoring it. To add bits of code, you don’t need to fully understand everything. To refactor, you need to.
It’s the same old problem of software engineering: Adding code is easier than refactoring it. To add bits of code, you don’t need to fully understand everything. To refactor code, you need to.
How to convince people about semantic markup and accessible codeI’ve tried to convince people with simple arguments about accessibility, machine-readability, robustness of a codebase but it never had the effect I intended. What really worked was doing a demo with a Screenreader showing them that I close my eyes and navigate through the project using nothing else than the screenreader. Usually, this has the effect of people being surprised that anyone can use such an assistive technology (known as e.g. "screenreader") and how bad the status of the application is in terms of accessibility.
Next step is to explain that accessibility is a step-by-step process. You can’t just do it right from the beginning, especially if you’re just starting. It’s iterative and learning by doing:
No one said that accessibility is easy. Even semantic code is not always trivial to achieve in modern web applications. You can tell your manager and reference me (or any other dev working in the field), if needed. It’s not your fault that you didn’t know about it before, frontend development has become so complex that focusing on specific parts is good.
If there’s anyone to blame though there’s no need, it’s Product ownership. As a Product owner, I have the power to decide which quality my software should have. If I decide for quick development, it’s no wonder to have poor semantics or accessibility. If I set accessibility standards and tell the team about it, they can and will handle that.
Start somewhereWith new laws going into effect these days, it’s easy to get overwhelmed by the requirements. It’s good to comply with WCAG 2.2 Level AA but please start and improve step-by-step. If you’re owing a complex web app, this is not a one-off thing, it’s not done in a few days but will take weeks or months to do it right. Nevertheless be aware that every single improvement that adds to semantics and therefore accessibility adds to the user experience of many people. It may not be perfect yet but it will become if you strive for it.
Change people’s mindsNothing is as powerful as seeing people changing their minds and way of thinking within a few months. Suddenly, people refer to contrast, use a screenreader, ask which UX-pattern is better or realise how complicated and unintuitive the current product is for newcomers.
Use the power to unblock and improve your team’s workflowsFinally, there’s a good chance that during this process it gets more clear how unrefined and unclear the Acceptance Criteria, the Product Value for the customer for a specific feature were in the past. Refinements will take a bit longer but QA easier and faster than before with less bugs or follow-up improvements being introduced.
Take the opportunity to analyse your current workflow (no matter if Scrum, Kanban, or other) and improve it based on where you see a lack of resources, process blockers. As hybrid-role person (Scrum Master and Frontend developer) I helped my teams pointing it out and starting to improve it. The result? People are happier and can work in a calmer mode. Managers are happier because the team effort is more predictable and the result is more stable, often of better quality.
What’s this all about? Accessibility is a core part of building products that work for everyone. It can help people becoming better developers, product owners, QA-testers, UX-designers.
As a freelancer helping larger companies achieve their goals, I’ve gained a lot of insights into how people work. And I know many people — including me — have said this for over a decade but it bears repeating: We have fantastic JavaScript (TypeScript included) developers who can build impressive solutions to complex problems. But there are still very few frontend developers today who truly know how to write semantic HTML and build with accessibility in mind. This is more important than ever, especially with the European Accessibility Act (EAA) now being enforced across Europe.
In almost all of the projects I’ve been working on, people relied on component libraries like MUI, Mantine or similar for their React software. If we implemented custom markup, it was mainly a div-soup that actually contained the relevant semantic information — just not in HTML but in custom data attributes. Now when we’re talking about accessibility, it’s the same idea that many developers come up with: Let’s add more informational attributes. Let’s add focus handling.
Adding code is easier than refactoring it. To add bits of code, you don’t need to fully understand everything. To refactor, you need to.
It’s the same old problem of software engineering: Adding code is easier than refactoring it. To add bits of code, you don’t need to fully understand everything. To refactor code, you need to.
How to convince people about semantic markup and accessible codeI’ve tried to convince people with simple arguments about accessibility, machine-readability, robustness of a codebase but it never had the effect I intended. What really worked was doing a demo with a Screenreader showing them that I close my eyes and navigate through the project using nothing else than the screenreader. Usually, this has the effect of people being surprised that anyone can use such an assistive technology (known as e.g. "screenreader") and how bad the status of the application is in terms of accessibility.
Next step is to explain that accessibility is a step-by-step process. You can’t just do it right from the beginning, especially if you’re just starting. It’s iterative and learning by doing:
No one said that accessibility is easy. Even semantic code is not always trivial to achieve in modern web applications. You can tell your manager and reference me (or any other dev working in the field), if needed. It’s not your fault that you didn’t know about it before, frontend development has become so complex that focusing on specific parts is good.
If there’s anyone to blame though there’s no need, it’s Product ownership. As a Product owner, I have the power to decide which quality my software should have. If I decide for quick development, it’s no wonder to have poor semantics or accessibility. If I set accessibility standards and tell the team about it, they can and will handle that.
Start somewhereWith new laws going into effect these days, it’s easy to get overwhelmed by the requirements. It’s good to comply with WCAG 2.2 Level AA but please start and improve step-by-step. If you’re owing a complex web app, this is not a one-off thing, it’s not done in a few days but will take weeks or months to do it right. Nevertheless be aware that every single improvement that adds to semantics and therefore accessibility adds to the user experience of many people. It may not be perfect yet but it will become if you strive for it.
Change people’s mindsNothing is as powerful as seeing people changing their minds and way of thinking within a few months. Suddenly, people refer to contrast, use a screenreader, ask which UX-pattern is better or realise how complicated and unintuitive the current product is for newcomers.
Use the power to unblock and improve your team’s workflowsFinally, there’s a good chance that during this process it gets more clear how unrefined and unclear the Acceptance Criteria, the Product Value for the customer for a specific feature were in the past. Refinements will take a bit longer but QA easier and faster than before with less bugs or follow-up improvements being introduced.
Take the opportunity to analyse your current workflow (no matter if Scrum, Kanban, or other) and improve it based on where you see a lack of resources, process blockers. As hybrid-role person (Scrum Master and Frontend developer) I helped my teams pointing it out and starting to improve it. The result? People are happier and can work in a calmer mode. Managers are happier because the team effort is more predictable and the result is more stable, often of better quality.
What’s this all about? Accessibility is a core part of building products that work for everyone. It can help people becoming better developers, product owners, QA-testers, UX-designers.
There are countless articles why developers should not focus on Frameworks too much and instead learn to understand the underlying languages. But I think rarely we can find good reasons except that Frameworks come and go. To me, the main reason is different: You won’t be a master at frontend development if you don’t understand underlying mechanisms of a language.
A usual stack today is React together with countless layers in between the language and the framework itself. CSS as styling method is not used natively but via JavaScript tools that translate it into native CSS. For JavaScript we nowadays write an opinionated Framework language mix using TypeScript which by itself is translated to native JavaScript in the end again. And while we all know the comfort of these tools and languages, there are many things that make it easier if you understand a browser’s ecosystem:
In the past years I had various situations where TypeScript developers (they called themselves) approached me and asked whether I could help them out with CSS. I expected to solve a complex problem but for me — knowing CSS very well — it was always a simple, straightforward solution or code snippet:
Nowadays people can write great React and TypeScript code. Most of the time a component library like MUI, Tailwind and others are used for styling. However, nearly no one is able to judge whether the CSS in the codebase is good or far from optimal. It is magically applied by our toolchain into the HTML and we struggle to understand why the website is getting slower and slower.
Most of the performance basics I learned ten years ago are still the most relevant ones today. Yet, most developers don’t know about them because we use create-react-web-app or similar things. Put Cloudflare on top to boost performance and reduce costs. Yes, that works for your website and little project.
What companies expect when they ask for a web dashboard serving real time data for their customers is different: It should be a robust, well working application that is easy to maintain. That means we need to combine the developer experience (React, TypeScript, all the little helpers) with the knowledge of how browsers and networks work. And only then we can boost performance, write accessible code, load dynamic data in a proper and safe way and provide fallbacks in case something goes wrong.
In cases of emergency like an Incident with the service, I’ve seen the difference often enough between people who exactly know where to look at, start debugging and go further, and those who try to find out in panic what’s going on here, hoping that a restart or re-deployment with reinstalled dependencies will help bring the service back to life.
And that means in the end again: If you know CSS, you also know the style framework. If you understand JavaScript, TypeScript is not a big problem for you. And that makes you a Senior or Principal.
There are countless articles why developers should not focus on Frameworks too much and instead learn to understand the underlying languages. But I think rarely we can find good reasons except that Frameworks come and go. To me, the main reason is different: You won’t be a master at frontend development if you don’t understand underlying mechanisms of a language.
A usual stack today is React together with countless layers in between the language and the framework itself. CSS as styling method is not used natively but via JavaScript tools that translate it into native CSS. For JavaScript we nowadays write an opinionated Framework language mix using TypeScript which by itself is translated to native JavaScript in the end again. And while we all know the comfort of these tools and languages, there are many things that make it easier if you understand a browser’s ecosystem:
In the past years I had various situations where TypeScript developers (they called themselves) approached me and asked whether I could help them out with CSS. I expected to solve a complex problem but for me — knowing CSS very well — it was always a simple, straightforward solution or code snippet:
Nowadays people can write great React and TypeScript code. Most of the time a component library like MUI, Tailwind and others are used for styling. However, nearly no one is able to judge whether the CSS in the codebase is good or far from optimal. It is magically applied by our toolchain into the HTML and we struggle to understand why the website is getting slower and slower.
Most of the performance basics I learned ten years ago are still the most relevant ones today. Yet, most developers don’t know about them because we use create-react-web-app or similar things. Put Cloudflare on top to boost performance and reduce costs. Yes, that works for your website and little project.
What companies expect when they ask for a web dashboard serving real time data for their customers is different: It should be a robust, well working application that is easy to maintain. That means we need to combine the developer experience (React, TypeScript, all the little helpers) with the knowledge of how browsers and networks work. And only then we can boost performance, write accessible code, load dynamic data in a proper and safe way and provide fallbacks in case something goes wrong.
In cases of emergency like an Incident with the service, I’ve seen the difference often enough between people who exactly know where to look at, start debugging and go further, and those who try to find out in panic what’s going on here, hoping that a restart or re-deployment with reinstalled dependencies will help bring the service back to life.
And that means in the end again: If you know CSS, you also know the style framework. If you understand JavaScript, TypeScript is not a big problem for you. And that makes you a Senior or Principal.
A good team is formed of trust, willingness to improve and agility to adapt plans and try out new things:
For a long time I believed that a strong team is made of stars — extraordinary world-class individuals who can generate and execute ideas at a level no one else can.
These days, I feel that a strong team is the one that feels more like a close family than a constellation of stars.
A family where everybody has a sense of predictability, trust and respect for each other.
A family which deeply embodies the values the company carries and reflects these values throughout their work.
But also a family where everybody feels genuinely valued, happy and ignited to create. — Vitaly Friedman
Let’s handover the best possible.
The best work for other people who take over our work at a later point. Why? It saves time and reduces interruptions during work, but most importantly, it will make you and the person using your work happier.
Good code is like a love letter to the next developer who will maintain it. Addy Osmani
Developers are not paid to write code. People get hired to make wise, solid and effective decisions.
It sets a long-lasting relationship with the company, the product, team members, or even customers. We are part of what we build: Effective solutions or just some product.
For effective solutions, we need to discuss in the team, bring up problems and ideas, verify them and find creative ways to work on the right things with the minimum effort possible to serve a high-quality product.
Developers are not paid to write code. People get hired to make wise, solid and effective decisions.
It sets a long-lasting relationship with the company, the product, team members, or even customers. We are part of what we build: Effective solutions or just some product.
For effective solutions, we need to discuss in the team, bring up problems and ideas, verify them and find creative ways to work on the right things with the minimum effort possible to serve a high-quality product.
A good team is formed of trust, willingness to improve and agility to adapt plans and try out new things:
For a long time I believed that a strong team is made of stars — extraordinary world-class individuals who can generate and execute ideas at a level no one else can.
These days, I feel that a strong team is the one that feels more like a close family than a constellation of stars.
A family where everybody has a sense of predictability, trust and respect for each other.
A family which deeply embodies the values the company carries and reflects these values throughout their work.
But also a family where everybody feels genuinely valued, happy and ignited to create. — Vitaly Friedman
Let’s handover the best possible.
The best work for other people who take over our work at a later point. Why? It saves time and reduces interruptions during work, but most importantly, it will make you and the person using your work happier.
Good code is like a love letter to the next developer who will maintain it. Addy Osmani