Welcome to My Blog

Why Writing Generic Code Is a Waste of Your Time(and Everyone Else’s) To all the developers out there painstakingly crafting “reusable” and “future-proof” code: stop. I know that’s a bold statement, but hear me out. As someone who’s spent years in the trenches of software development, I understand the appeal. Writing generic, reusable code feels like an achievement. It’s elegant, it’s clever, and it makes you feel like you’re building something that will stand the test of time. But here’s the uncomfortable truth: most of the time, your generic code will never be reused. And when it is, it’ll probably be the source of more problems than solutions. The obsession with writing reusable code has become a badge of honor in our industry, but it’s also one of the most overrated and counterproductive habits a developer can have. In the name of “future-proofing,” we waste hours solving problems we don’t have, over-engineer solutions for imaginary scenarios, and create abstractions so convoluted they make onboarding new team members a nightmare. Let me tell you why your time would be better spent writing simple, problem-focused code — and why the pursuit of generic reusability is often the enemy of good software development. First, let’s talk about why we’re so drawn to the idea of reusable code. Developers love it for the same reasons we love clever hacks and elegant algorithms: it makes us feel smart. It’s like solving a puzzle — finding that one abstraction that can handle every possible use case. And, of course, there’s the dream of saving time in the future. Who wouldn’t want to write a piece of code once and use it forever? But here’s the thing: the future you’re planning for rarely arrives. Most of the time, the next project has slightly different requirements, and your “generic” solution either doesn’t fit or requires so much customization that you’d have been better off starting from scratch. And let’s not forget the cost of writing reusable code. It’s not free. Every minute you spend making your code “future-proof” is a minute you’re not solving the actual problem in front of you. And let’s be honest: how often does the “future” you’re planning for actually happen? Then there’s the issue of complexity. The more generic you make your code, the harder it becomes to understand. What could’ve been a straightforward function call now requires a PhD in abstract logic to decipher. Good luck debugging that in six months. And good luck explaining it to the new hire who just joined your team. I’ve seen this play out in real life more times than I can count. One project I worked on had a developer who wrote what they proudly called a “universal API handler.” It was a thing of beauty — modular, abstracted, and capable of handling any API endpoint you could throw at it. Until we needed to add authentication. And rate limiting. And custom error handling for a specific endpoint. What should’ve been a simple change turned into a week-long ordeal of patching, refactoring, and overriding logic. In the end, we scrapped the whole thing and wrote a purpose-built handler that took a day to implement and worked perfectly for our needs. This is the reality of generic code: it’s rarely as reusable as you think it is, and when it is, it’s often more trouble than it’s worth. So what’s the alternative? It’s simple: solve the problem in front of you. Write clear, straightforward, and purpose-built code. If — and only if — you find yourself solving the same problem multiple times, then consider refactoring for reusability. This approach isn’t just faster; it’s also more maintainable. Your future self (and your teammates) will thank you for writing code that’s easy to understand and adapt. The obsession with generic code is, at its core, an ego thing. We want to feel smart, to create something that lasts, to leave our mark on the codebase. But good software development isn’t about stroking your ego — it’s about solving problems efficiently and effectively. So next time you’re tempted to write that “universal” function or build that “one-size-fits-all” module, ask yourself: am I solving today’s problem, or am I just showing off?

Photo by - Kenny on UnsplashAI tools like GitHub Copilot are everywhere now, and yeah, they’re impressive. I can’t deny that. They’ve changed the way I work, the way I code, and even the way I think about coding. But here’s the uncomfortable truth: they’ve also made me question whether I’m getting too comfortable. Too reliant. Too… lazy. And I’m not saying that lightly. I’ve caught myself skipping the hard questions, letting the tool do the thinking, and just clicking “accept.” It works, right? But does it really? Here’s the thing about coding: it’s never been just about getting something to run. Anyone can do that. It’s about figuring out why it works, why it’s the best solution, why it fits into the bigger picture. AI doesn’t care about any of that. It’s fast, it’s functional, but it’s not thoughtful. And if I let it, I stop being thoughtful too. That’s what scares me. Because when you stop asking “why,” you’re not really coding anymore — you’re just… typing. I’ve seen it happen. AI spits out some code, and it’s easy to just go with it. It looks fine, it works, and you’ve got deadlines to meet, so why not? But then you dig deeper, and you realize it missed something important. Maybe it doesn’t handle edge cases. Maybe it’s impossible to read. Maybe it scales terribly. It’s what we call “vibe coding” — just trusting the AI’s output because it feels right in the moment. But that’s not how great code gets written. That’s how shortcuts turn into long-term problems. And yet, I don’t believe for a second that AI is replacing developers. It can’t. Writing great code is about solving problems, making decisions, understanding trade-offs. It’s about creativity and intuition and knowing when to break the rules. AI doesn’t do that. It doesn’t understand nuance or context or people. But here’s the thing: if we rely on it too much, we might lose our ability to do those things too. And then what? What happens when we stop being the problem-solvers and start being the people who just approve whatever the machine spits out? It’s not just about coding, either. As a leader, I’ve seen how this shift is changing what people expect from us. Clients don’t just want code anymore — they want expertise. They want insight. They want someone who can help them figure out what they actually need, not just someone who can build it. And honestly? AI can’t do that. It can’t replace the human side of what we do. But it does mean we need to step up. My role as a leader has shifted. I’m spending less time worrying about production and more time helping my team focus on what really matters — creativity, problem-solving, and strategy. But it’s tough. How do you keep a team sharp when AI is doing so much of the heavy lifting? How do you make sure they don’t fall into the same trap I’ve caught myself in — getting comfortable, getting lazy? For me, the answer is staying curious. AI can give you an answer, sure, but it’s up to you to ask, “Is this the right answer?” And we need to keep building the skills that AI can’t replicate — creativity, critical thinking, collaboration. Those are the things that make us human, and they’re the things that make us valuable. AI is just a tool. A powerful one, yeah, but it’s not the whole picture. Still, I can’t help but wonder: are we slowly trading mastery for convenience? Are we letting the craft of coding — the joy of building something from scratch — fade away without even realizing it? I don’t know. But it’s something I think about a lot. Because if we’re not careful, the future of coding might look a lot less human. And honestly? That’s not a future I want to be part of.

Since I started my journey as a young leader already almost 3 years ago, I’ve often found myself navigating the delicate balance between supporting my team and maintaining professional boundaries. It’s a challenging line to walk, where empathy meets the need for clear, effective leadership. This balance is crucial, as crossing it can lead to blurred roles and expectations, both for me and my employees. When I joined a podcast as a guest last month, this topic came up and had me thinking. So I thought I’ll share my thoughts here: Photo by Kelly Sikkema on UnsplashLeadership, at its core, involves guiding and inspiring others to achieve common goals. It requires a deep understanding of team dynamics and individual motivations. However, it’s easy to slip into a therapist-like role when team members bring personal struggles into the workplace. Especially trends like “servant leadership” and “gentle leadership”, made it much more challenging to separate work life reality of leadership and personal support reality of every individual. While being a supportive leader is important, it’s equally vital to remember that we are not trained therapists and that we also have a business context. So to be an efficient, yet empathetic leader, I found the following guidelines very helpful: Setting boundaries One of the key lessons I’ve learned is the importance of setting boundaries. As leaders, we should foster an environment where team members feel comfortable sharing challenges, but we must also recognize when to redirect them to appropriate resources, such as HR or professional counseling services. You are not alone in this. Make sure to not be blinded by a false pride. This approach ensures that team members receive the support they need while allowing us to focus on our primary role as leaders and mentors. Maintaining objectivity Emotions can run high in any team, and being empathetic is part of being a good leader. However, it’s crucial to avoid becoming emotionally entangled in team members’ personal issues. By staying objective, we can provide clearer guidance and make decisions that benefit the team as a whole. It’s fine to share personal experiences, if you feel comfortable, as it might help to create stronger bonds, but be careful not to get invested too much. Clear communication Setting expectations about our roles and the limits of our support can prevent misunderstandings. Encouraging open dialogue about work-related issues, while being transparent about the boundaries of personal support, helps maintain a healthy professional environment. Make sure these expectations are always in a shared presence. Bring them up, when personal topics come up. Make clear, when you don’t feel comfortable consulting on specific topics. Sure we should be servant leaders. This does not mean to give up our own needs. I learned to use these tools to navigate the fine line between leadership and therapy. This way we can create a balanced environment that fosters both personal growth and professional success. It’s about being present, understanding, and guiding without overstepping into roles we’re not equipped to handle. This balance not only enhances our effectiveness as leaders but also empowers our teams to thrive. Stay true to yourself and communicate open and honestly.

6 things I learned from fatherhood that make me a better leader Photo by Steven Van Loy on UnsplashWhen I became a father the first time in 2019 and then the second time in 2023 it (obviously) changed my life dramatically. On the one hand it got much more serious as there are now small humans depending on me. On the other hand, I am able to enjoy a lot of lovely moments and experiences with my children. Since then my children taught me a lot of valuable things, five of them, which impact my work life as a leader, I want to share with you today: 1. Punishment is Senseless — Patience is Key I vividly remember moments when my daughter simply refused to cooperate, whether it was bedtime or getting ready for daycare. My initial instinct was frustration, but I quickly realized that punishment wasn’t the solution. It is hard for humans and especially for children, to connect delayed consequences (i.e. tired in the morning, hurried daycare) to current actions. Acting with pressure only created resistance and didn’t address the root cause. Instead, patience and understanding worked wonders. As a leader, I’ve carried this lesson into my work. When team members struggle, it’s rarely because they don’t care — it’s usually because something deeper is at play, like a lack of clarity, confidence, or support. Leading with patience and curiosity has been far more effective than resorting to punitive measures. 2. You Cannot Force Learning When my kids started exploring the world, it became clear they would learn things in their own time and in their own way. No matter how often I tried to “teach” my toddler something, it only stuck when she was ready and curious about it. Forcing it was futile. In the workplace, the same principle applies. You can’t force people to grow or adopt new skills overnight. Instead, it’s about creating an environment where learning is safe, encouraged, and aligned with their intrinsic motivation. Letting people take ownership of their development is far more powerful than micromanaging their progress. 3. You Get What You Give Parenting is a mirror — when I’m calm, engaged, and empathetic, my kids respond in kind. When I’m rushed or distracted, their behavior reflects that energy back at me tenfold. This principle holds true in leadership as well. The energy and attitude you bring to your team directly influence their morale and productivity. If you show trust, respect, and enthusiasm, your team will mirror those values. The environment you cultivate determines the culture you get. 4. There is No “Right” — Embrace Unexpected Perspectives One of the most surprising and humbling lessons I’ve learned from my kids is how often they arrive at conclusions that are completely valid, even though I would have never thought of them. Their unfiltered logic and fresh perspective constantly challenge my assumptions. For example, my daughter once asked why the sky doesn’t have a lid if it’s a “room.” It was such a simple, innocent question, but it made me pause and think about how we adults frame things versus how children interpret the world. This lesson has been invaluable in leadership. Sometimes team members come up with ideas or solutions that I would have never considered. Rather than defaulting to “this isn’t how we do things,” I’ve learned to listen, stay open, and let those ideas challenge my perspective. Often, the “right” answer is simply one I hadn’t seen before, and those moments of discovery are where real innovation happens. 5. Allow Them to Fall As much as I’d love to shield my kids from every stumble and scraped knee, I know those moments are essential for their growth. Watching them fall is hard, but it’s necessary for them to build resilience and confidence in their abilities. The same goes for teams. As a leader, it’s tempting to step in and fix things before they go wrong. But if we don’t let our teams face challenges and learn from their failures, we rob them of the opportunity to grow. It’s through falling and getting back up that we develop true strength and capability. 6. The Power of “Why?” Finally, if there’s one question my children have mastered, it’s “Why?” While it can be exhausting answering it for the hundredth time, I’ve come to appreciate how this relentless curiosity pushes me to think deeper and clarify my own understanding. In leadership, fostering a culture of “Why?” — encouraging your team to question assumptions and seek meaning — leads to better decisions and stronger alignment. It reminds us to stay curious, challenge the status quo, and ensure our actions align with our purpose. Parenthood has been my greatest teacher, and its lessons have transformed the way I lead. By embracing patience, fostering growth, mirroring positivity, staying adaptable, and encouraging curiosity, I’ve found a leadership style that feels both authentic and effective. It’s not about being perfect — it’s about being present, intentional, and willing to grow alongside those we guide.

To all of you wanting to start a software engineering career: Good luck. As a developer-turned-director in the tech industry, I’ve seen firsthand how artificial intelligence (AI) is transforming the way we live and work. The rise of AI has already changed the software engineering craft in an unsustainable way — a way that might be destructive for the future of our profession. No matter if you are just starting out or are already steadily working as a software engineer, you know about the ongoing discussion regarding entry-level roles: “You need a minimum of 3–5 years of experience.” This issue has been magnified even more with AI entering the realm of writing and reading code. When I look back at my time as a junior software developer, I enjoyed the freedom of being allowed to make mistakes. I worked with more experienced colleagues on tasks to learn how to do things properly from their real-life experience. Nowadays, I would call this a luxury we have to fight for. With the technology and AI we have right now, tech projects that previously required teams can now be done by one experienced person alone. Additionally, the technology seldom makes mistakes and learns faster from them than we humans do. So what business value do we developers have now that it is much cheaper to “pay” the AI? My prediction for the years to come is that the development craft will become more about convenience, and to succeed as a developer, you will need all the soft and social skills. We already see this with the “3–5 years of experience” requirement. What I, as a manager, mean when I include this in a job offer is that I am looking for someone who has enough experience to not just have theoretical knowledge, but to have experienced the real-life pains and pleasures of working as a software developer in the market. Someone who can explain complex technical topics in a simple way — essentially, someone who knows that software development is more than just talking to a machine and following tutorials. I am looking for someone who can make their own decisions and, most importantly, explain why they made them. So this is my message to all the soon-to-be software engineers out there: If I were you, I would not focus on learning another framework or building another Todo app to prove your worth. Instead, focus on building expertise so that you can consult businesses on technology rather than writing code yourself. You should be able to solve problems and communicate those solutions in an approachable way. I already hear you saying, “Easier said than done.” That’s right. Software development is much, MUCH harder nowadays than it was 3–5 years ago. But if you have a passion for problem-solving and technology, and if you are not just in it for the “easy money,” then don’t be discouraged. Invest in your passion and develop those soft skills to be successful. If you want guidance on where to start or how to successfully apply your skills, I am happy to have a conversation with you. You can reach me through LinkedIn and email.

“This is legacy code, I need at least double the time to do changes there. We should rework it.” Should we? As a seasoned veteran in the software industry, I’ve navigated the treacherous waters of legacy code more times than I care to count. Reflecting on these experiences, I’ve come to see legacy code not just as a technical challenge but as a main element in the ongoing dialogue between past and future development practices. The term “legacy code” often conjures images of outdated, cumbersome software that’s more trouble than it’s worth. Yet, my journey has taught me that the story of legacy code is far richer and more nuanced than its reputation suggests. Legacy Code: A Personal Reflection In my early days as a developer, legacy code was something to be avoided at all costs — a relic of past efforts that seemed to hinder more than help. However, as I grew in my career, my understanding of legacy code evolved. I began to see it not just as code that had outlived its support cycle but as a testament to the evolution of our craft. To me, legacy code means “Code written before a major change in how we write code in a given context”, marking a fascinating shift from being product- and support cycle-centric to emphasizing coding styles and patterns. It’s all about the money One of the most poignant lessons I’ve learned is the business reality shadowing legacy code. From a stakeholder’s perspective, the crux of the matter boils down to cost — legacy changes often come with a hefty price tag, attributed to the complexities and technical debt accrued over time. This realization was a turning point, prompting me to look beyond the code itself and consider the broader economic implications. The Rebuilding Dilemma: A Reflection on Costs and Continuity The idea of rebuilding software from scratch is a tempting one, especially when faced with the daunting task of updating legacy systems. Sure, superfically it might seem like a goot option, especially for long running systems, where high costs will accumulate over time. However, experience has taught me that this approach is a double-edged sword. Rebuilding might offer a temporary reprieve, but it’s essentially a cycle, birthing new legacy code destined to become tomorrow’s challenge. So I learned to focus on strategic thinking in managing legacy systems. A Personal Strategy for Legacy Code My approach to dealing with legacy code has become more nuanced over the years. I’ve learned the importance of evaluating each situation through a multifaceted lens — considering not only the technical aspects but also the impact on business operations and future development. Here’s how I navigate these decisions: Assessing Impact Over Technology: Understanding the business value of legacy code has become a cornerstone of my decision-making process. It’s about recognizing when to preserve and when to innovate. Evaluate long term costs: Learn from past numbers and estimate long term costs for running and changing the legacy system in the future to being able to make proper decisions Embracing Incremental Improvement: I’ve found that gradual, thoughtful modernization of legacy systems can be more effective and less disruptive than the “Big Bang” approach. Hybrid Approaches: Adopting a blend of old and new, maintaining stable legacy components while integrating fresh technologies, has been key to balancing innovation with reliability. Some call it “Zombie”-Systems. Well sometimes it’s worth keeping things alive. Legacy Code as a Companion in Growth I’ve come to view legacy code not as a burden but as a companion in the continuous evolution of software development over time. It’s a reminder of where we’ve come from and a guidepost for where we’re going. By embracing the lessons legacy code offers, I can navigate the delicate balance between preserving valuable knowledge and effort while pushing forward into new technological frontiers. My journey through the landscape of legacy code was one of discovery, challenge, and ultimately, personal and professional growth. What’s your opinion?

In the rapidly evolving landscape of today’s business environment, a notable shift towards individualism has sparked a widespread discussion. Phrases such as “Gen-Z is hard to handle in a business context” are becoming increasingly common, reflecting a broader conversation about the changing dynamics within professional settings. This shift towards individualism, particularly pronounced over the past two years with the revolution in gender identities and personal expression, presents both opportunities and challenges, especially in the realm of teamwork. Understanding the Call for Understanding As a seasoned professional with years of experience working across diverse teams, I’ve observed firsthand the power of diversity in creative collaboration. In my experience the inclusion of varied perspectives typically improves outcomes, underscoring the value of individual contributions within a collective effort. The rise of individualism however, has also led to the emergence of extreme viewpoints, which while necessary for societal evolution, can strain and even destroy team dynamics and work relationships. The core issue lies not in the promotion of individualism per se but in how it’s integrated into team settings. When individualism is emphasized at the expense of collective goals, or when it’s ignored altogether, the foundation of effective teamwork begins to erode. Team Building in the Age of Individualism Effective collaboration requires more than just assembling a group of talented individuals. It demands a deliberate and thoughtful approach to team building, one that acknowledges and integrates the diverse strengths AND weaknesses of its members. This process varies significantly across teams; some may require minimal effort to grow together, while others might need extensive team-building initiatives. To navigate the complexities of modern teamwork, a balanced approach is essential. This involves recognizing and valuing individual contributions while fostering a sense of belonging and shared purpose. Especially in this age of remote work. It’s about creating an environment where personal achievements contribute to, rather than compete with, team objectives. Organizations must strive to cultivate a culture that celebrates diversity while maintaining a clear focus on collective goals. This is no easy task. But one worth fighting for! Reimagining Teamwork for the Future As we continue to grapple with the implications of individualism in professional contexts, it’s clear that the path forward requires adaptability, understanding, and a recommitment to the principles of teamwork from all sides. By embracing the strengths of individualism while mitigating its potential to disrupt team cohesion, we can unlock new levels of creativity and efficiency. Ultimately, the success of teamwork in this new era will depend on our ability to balance the celebration of individual differences with the pursuit of common goals. In crafting this dialogue, organizations and team leaders must play a pivotal role, guiding their teams through the complexities of this transition with empathy, vision and understanding. Only by doing so can we ensure that the evolution of individualism serves to enrich our collective endeavors rather than detract from them. I am looking forward for a future where we can value each other without the need to impose opinions and values onto others. The team goal should not overshadow individual goals, but unite them behind it.

Leadership is a complex and often controversial topic. While some believe that leadership is about inspiring others and serving the greater good, others see it as a means of gaining power and control. The truth, however, is that leading does indeed mean gaining power, and it’s time we stopped pretending otherwise. Power is a fundamental aspect of leadership. A leader who doesn’t have power is simply not effective. Power gives a leader the ability to make decisions, allocate resources, and shape the direction of the organization. Without power, a leader is merely a figurehead, a symbolic representation of the organization but with little actual authority. Of course, there’s a difference between having power and abusing it. A good leader uses power to serve the needs of their team, to make decisions that are in the best interests of the organization, and to create a positive and productive work environment. A bad leader, on the other hand, uses power to further their own interests, to control and manipulate others, and to create a toxic work environment. However, even good leaders need power to lead effectively. They need the ability to make decisions, allocate resources, and shape the direction of the organization. They need the power to remove obstacles, to motivate and inspire their team, and to create a culture of success. Leadership is not just about having a positive attitude and a vision for the future. It’s also about making things happen. It’s about taking action, making decisions, and shaping the direction of the organization. To do this, a leader needs power. They need the power to allocate resources, to make decisions, and to remove obstacles. Power is not something that can be given. It must be taken. A leader who waits for someone else to give them power will never have it. They must seize the power and use it to create change. This requires courage, determination, and a willingness to take risks. So leading does indeed mean gaining power. It’s time we stopped pretending otherwise and acknowledge that power is a fundamental aspect of leadership. The challenge for leaders is to use power for good, to serve the needs of their team and to create a positive and productive work environment. The true test of a leader is not whether they have power, but how they use it. What are your thoughts on the relationship between leading and gaining power? Share your thoughts and opinions in the comments below!

In the last decade, as a software developer, you’ve undoubtedly encountered the vital role of design principles and the art of crafting clean, readable code. But in our current tech-driven world, brimming with emerging tools and frameworks, I’ve started to question the enduring relevance of these practices. As a developer, I’ve witnessed firsthand how the lines between good and great coding are blurring. I’d argue that the importance of clean code, file structuring, and design patterns is diminishing by the day. The Rise of AI Co-Coders Take, for instance, the surge in popularity of AI co-coders like GitHub Copilot. These tools have become more than just novelties; they’re reshaping industry standards. We as software engineers are in the late stages of adapting to these tools, learning collectively how to harness their full potential. My own journey with these AI assistants has been eye-opening. One hard thing Relying on AI for Coding: A Personal Account In my day-to-day coding, the dependence on tools like Copilot has grown exponentially. Complex structures, such as try-catch blocks and promise handling, are now effortlessly managed by AI. Jumping into new tools and frameworks is easier than ever. The absence of Copilot, due to connectivity issues or environmental incompatibilities, leaves a noticeable gap. It’s akin to losing a valuable collaborator, highlighting just how integral these tools have become in my day to day workflow. This reliance extends beyond writing to understanding code. When approaching new codebases, I often lean on Copilot for guidance and explanations. At times, I find myself merging code from various files to one to provide Copilot with the necessary context, and the clarity of the code in these instances isn’t always pristine. I was easily able to make changes in 6–7 year old code with deprecated dependencies I did not even know existed. It’s a stark reminder of how AI tools are reshaping our interactions with code, clean or otherwise. The Paradigm Shift — the future is ‘ugly’ Reflecting on my teaching experience in web basics — HTML, CSS, JavaScript — I’ve always stressed the importance of indentation and spacing for human readability. However, with AI’s involvement, the future might look drastically different. I envision receiving one complex, ‘uglified’ file, created by AI, and using these tools to decipher, modify, and extend it. The process will involve guiding the AI to format and adapt specific parts of the code, testing and refining as needed, and ultimately maintaining the efficiency of the machine-generated code. I only need to care about the “What” and not anymore on the “How”. Conclusion: The Changing Value of Clean Code My experiences lead me to believe that the significance of clean code, file structuring, and design patterns is diminishing in the AI era. While some argue that developers may become redundant in the future, I believe our role is simply evolving. We must embrace and become adept with AI tools like Copilot. This isn’t about replacing our skills but enhancing them, shifting our focus from syntax to problem-solving. As we adapt to this AI revolution, we’re not just plowing fields with horses anymore — we’re learning to pilot advanced machinery in the vast landscape of coding.

The Head of all Heads: When everyone becomes a leader — how do we build teams in the future? This is the story of a software engineer. He progresses fast through the software engineering career ladder. After several years working in his field and many appraisals from his manager, he is faced with a tough choice: As the salary for an engineer in the company cannot go above a certain limit, they can only offer to promote him to Head of. He takes the offer, but right after that the trouble starts. He will attend more meetings, as he must decide for the whole department now. He spends less time working on coding and more time on keeping up with the market. After several years, he’s more skilled in making calls than in being the expert needed to guide his team. End of story? I know this scenario from personal experience and from my network. And I can assure you that it happens way too often. If you look at the engineer’s story, it’s about handing out a Head title only to justify a pay rise. This devalues both the position of the leader and that of the engineer since expertise is not valued if you‘re more efficient with your tasks. What I’d rather want to see though, is titles reflecting expertise, experience, and knowledge instead of salary level. Of course, we like to label things, so we can communicate more easily. I also expect certain things when I talk to a Head instead of a senior software engineer. I will approach the Head with management topics and the engineer with technical questions. But what if they never wanted to be in that position in the first place? If they can’t fill out the leadership role as in what is expected of it? As the surrealist painter Magritte declared: “Ceci n’est pas une pipe”–yes, appearances can be deceiving. But I’d rather have a company telling me that more expertise does not equal more money, than being forced into a role just to keep me. My life is about living with ease and creative exploration. Therefore, I value my leadership title because it gives me possibilities to explore. This is why I’m also fast in dishing out titles. I do not care if you want to be called Head of if you carry the responsibility. If I have a technical question about some nitty gritty engineering topics, I will approach the senior engineer, not the team lead, whom I only contact about the project in general. This is what the title Head of does: it devalues expertise. For me a Head is only important to keep things running and to escalate issues. Titles therefore help me make everyday decisions. From craftswoman to manager: If all people worked in the same quality, there would be no need for managers. That’s why I don’t care about your title if you keep up to agreements and responsibilities. For me this is just a tool to help companies justify unfair pay, which is a huge problem. If a person does a really good job, they are always worth their time. But to keep up the facade of equal pay, companies cannot give them a raise and instead they make them a Head to justify their salary to some higher ups. That’s an issue on its own since others have management expectations from a person with a certain title when the person sometimes probably only just wants to keep engineering. No interest and no skills for leading people. Still, they are being pushed into a role to work around a broken system. I am not ashamed to say that I am a friend of unfair pay, if you’re paid according to the quality of your work. No need to come up with titles: you’re allowed to earn more than other people above you and that’s that. “Ceci n’est pas une pipe” — all the other approaches are just for show.