Worth Following – Podcast by Adrian Stanek

Hello, fellows, and welcome to today's podcast. I want to delve into a topic crucial for anyone involved in development, whether on a team or within an entire organization: the relentless loop of deadlines. Deadlines are often seen as a tool to drive productivity, providing that external push to get things done. However, this constant rush can develop into a habit that, while initially practical, eventually creates a cycle of stress and stifles innovation.Throughout my career, I have observed how teams thrive when given the autonomy to innovate and take ownership of their work rather than being confined by rigid deadlines. When prioritizing continuous improvement and frequent feedback over chasing deadlines, we reduce stress and foster a culture of responsibility and creativity. This approach bridges the gap between development and business, creating a cohesive, effective, and motivated team.But we need to be on time!!!Being on time and deadlines are two different pairs of shoes. Deadline is a practice and often an organizational habit. Being on time is a responsibility, something we commit to.Every time we invested time and thought into the process, we came out with something more valuable. Every time we solely focused on deadlines, we took the shortest route to get stuff done; often, we took shortcuts when the timeframe was too narrow. Which resulted in adverse long-term effects on NFRs. How do we balance deadlines and innovation?We cannot just switch to something different when we have developed a deadline habit as a team, organization, or company.In fellowships and mentoring, this is often the main topic. A person or a team understands that a switch is necessary, but the way to change the bad habits is hard.It is too late; engineers realize that the quality of the code base is below the defined quality or recognize that they are constantly rushing from one deadline to the other.More problems occur over time because this practice doesn’t provide time to get things into shape.Engineers take short-cuts:* Avoiding Tests* Skipping refactoring* Avoid improvements* Ignoring technical debt.Management became used to defining timeframes based on estimations, based on half-baked requirements, and shallow context. It’s then up to the engineers to find ways to mitigate this tension.What really worries me is when engineers defend deadlines.I don’t really know what I should think at that moment. It’s often based on a thought like * “We were successful once when we set ourselves a deadline. We keep on doing that.”* “If a company perpetuates the narrative that 'the business needs it, or else it's over,” – it's a sign that you've been misled. Such an organization isn't open to change. It operates in a way that remains detached from engineering, making it easier for them to justify their decisions without emotional investment. If this is the case, consider leaving the company.Unfortunately, that ignores the harmful long-term effects on our qualities and working culture. Responsibility and Ownership are the first victims of this practice. Why should a person take ownership of something that is:* Time budgeted.* Fixed in scope.* Fixed in execution.* Already pre-defined in the requirements.It’s just something an engineering team will work down to make it happen to a specific date: the deadline.The results of this lack of ownership will be:* No care for tests* No care for quality* No care for feedback.* No care for improvement.* No care for resilience & maintainabilitySimply put, no one cares at some point; people slowly burn out, and you won’t see something until it’s too late: Quit quitting.The solution is simple yet hard to understand.We need to trust that software engineers, who get paid well, can take responsibility and ownership while keeping timelines in mind.By its nature, development describes an iterative, exploratory process, not a timeframe. Developers can handle that well, but you need to let them.Rephrase deadlines to timelines or milestones. Communicate why getting a specific set of features is essential until X.But don’t use this as a deadline to squeeze more development performance out of the people. Instead of narrowing down timeframes and making deadlines harder to meet, provide more leeway to keep qualities and let improvements happen.You will see a constant, positive process, which will still work in months to come. You will have a good chance to prevent a legacy state, a problem nearly every company I know personally has.Start to trust your developers, rethink your expectations, and understand software and product development as an exploratory process. Include everyone and remove the huge gap between engineering and business.Key takeaways* Deadlines often create a cycle of stress and limit innovation.* Deadlines should be used sparingly and only in critical situations.* Building a culture of trust reduces the need for constant deadlines.* Autonomy and ownership foster creativity and responsibility in tea

Imagine joining a new team as a fresh junior developer, only to find yourself in a senior-dominated environment where every team member boasts over 40,000 hours of experience. The workflows and practices are tailored to these elite performers, leaving juniors struggling to keep up through no fault. The complexity of technology is a given, but the dynamics within the team are entirely within the team's control.Why do silos and heroism become daily challenges? Often, the baseline is set too high, aiming for maximum efficiency by creating a senior-only team. This approach, while well-intentioned, often backfires, especially in smaller companies, leading to high turnover, isolation, problem concealment, and toxic work environments. The result? A stagnant team mired in unnecessary complexity.True senior developers simplify complexity and empower others to excel. In this podcast, we'll explore how to do just that, focusing on creating an inclusive, efficient, and resilient team environment. Join us as we dive into the principles of the Average Developer approach, where the focus is on enabling all team members to contribute effectively and grow together.Read the full article: This is a public episode. If you'd like to discuss this with other subscribers or get access to bonus episodes, visit blog.adrianstanek.dev/subscribe

Ownership isn't just a principle; it's the cornerstone of a thriving team.Hello, fellows! As an employer and tech lead, I've learned the immense value of fostering an environment where developers take genuine ownership of their work. This realization came from my experiences—seeing firsthand how a sense of responsibility can transform routine tasks into personal missions. When developers feel this connection, they push boundaries, maintain high standards, and innovate with a profoundly personal vigor. Ownership isn't just a principle; it's the cornerstone of a thriving team, where quality and innovation are embedded in every task.Provide Boundaries For DevelopersSetting the proper technical boundaries has been pivotal in this journey. Initially, 'boundaries' seemed like a restrictive concept, but I've seen them as essential frameworks for creative and effective development. As tech leads, our challenge is to establish these frameworks thoughtfully—defining the scope and letting our developers explore the how within these confines. This delicate balance demands that we guide rather than dictate and support rather than control.Reflecting on my path, I've embraced the role of a leader who provides clear strategic direction and then steps back, allowing developers the space to innovate and take ownership. This approach is not just about improving productivity; it's about nurturing a culture of engagement and loyalty. This is the essence of our role: building not just software but a resilient, proactive, and committed community. Let's carry this ethos forward in our daily practices and continue to enrich our teams and projects. Thank you, everyone—let's make it another day of meaningful progress!Key Takeaways:* Foster Ownership: Encourage developers to take responsibility for their projects, transforming their roles from mere participants to proud owners.* Define Boundaries Thoughtfully: Establish clear, flexible boundaries that stimulate creativity and effective problem-solving.* Lead by Guiding: Opt for a leadership style that guides and supports, rather than micromanages, to cultivate independence and initiative.* Cultivate a Culture of Commitment: By allowing developers autonomy and input, develop a team culture that breeds loyalty and long-term engagement.* Encourage Continuous Learning: Promote an environment where learning and development are integral, helping developers stay current and innovative.* Balance Freedom with Framework: Provide enough structure to maintain direction without stifling creativity, allowing developers to explore solutions within a guided context.* Communicate Clearly and Consistently: Ensure that all team members understand the vision, goals, and expectations, fostering a unified direction and effort.* Recognize and Reward Initiative: Acknowledge the efforts of developers who go beyond the call of duty, reinforcing their sense of ownership and contribution.snackableCTO is a reader-supported publication. To receive new posts and support my work, consider becoming a free or paid subscriber. This is a public episode. If you'd like to discuss this with other subscribers or get access to bonus episodes, visit blog.adrianstanek.dev/subscribe

Hello, Fellows! Welcome to today's Walk&Talk, where we delve into the ever-evolving world of our front-end tech stack, particularly in the context of the State of JS 2023 survey. As we review and reflect on our technology choices, it's crucial to understand the foundational qualities that drive these decisions. Substitutability, ecosystem robustness, and developer availability are just a few critical factors we consider to ensure our tech stack remains stable and future-proof.The following qualities (NFRs) are essential to determine:* Ecosystem richness* Developer availability* Community interest* Continuity* SubstitutabilityOver the past year, changes might seem minor, but looking at a broader span of three years, significant shifts emerge. For instance, a decline in Angular's developer availability might prompt us to reconsider its use in new projects. When evaluating our stack, we ask the key questions: Would I use this tech today if I were starting fresh? And if not, what would I change?Our reliance on React remains strong despite exploring alternatives like Vue or Svelte. However, the potential of web components, frameworks like Google Lit, and vanilla JS also cross our minds, albeit with reservations about their ecosystems and developer onboarding challenges.A critical part of our tech stack is the meta-framework. While Next.js has served us well, its shift towards server-side rendering raises concerns. Alternatives like Vite, with its flexibility and future promise, are on our radar. Though we don't need an immediate switch, we are hypothesizing and testing it for the future.We are also evaluating our testing frameworks, considering a shift from Cypress to Playwright due to its ease of use. Similarly, we've transitioned from Recoil to Zustand for state management, as Recoil's experimental status no longer aligns with our needs.Our tech stack review isn't about favoritism or trends; it's about strategic, long-term decisions that ensure the sustainability and success of our products. This approach helps us stay flexible, informed, and prepared for the future, balancing innovation with stability.Thank you for joining me today. I hope you find these insights valuable. I invite you to read my full article and participate in the survey at the bottom. Your feedback is critical to me.Stay tuned for more updates, especially about our work with Cloudbar. I'll share more about our daily operations, decision-making processes, and successes and challenges. Let's continue this journey together, embracing change and striving for excellence in our tech endeavors.Have a great day, and see you next time!AdriansnackableCTO is a reader-supported publication. To receive new posts and support my work, consider becoming a free or paid subscriber.Continue Reading This is a public episode. If you'd like to discuss this with other subscribers or get access to bonus episodes, visit blog.adrianstanek.dev/subscribe

Hello Fellows,Reflecting on the last 15 years running my tech company, I’ve realized that managing infrastructure can often become a black hole for time and resources. It’s been quite the journey—from being the 'boss' handling servers with our admin in a tiny data center to now, where cloud solutions have lifted many burdens off our shoulders. Yet, despite these advancements, I see many small companies still overwhelmed by unnecessarily complex setups.I remember the days when managing infrastructure felt like a badge of honor—complicated AWS configurations, late nights fixing server issues, and backup tapes almost becoming part of the family! But let’s be honest, was all that complexity really worth it? I thought it was necessary for a long time until I realized how much it distracted us from our core mission: Creating value for our customers.Switching to Platform-as-a-Service was a revelation. It dramatically simplified our operations, cutting costs and freeing our team to focus on what we do best. In my upcoming video, I want to share this journey with you. Why keep wrestling with infrastructure when you can streamline it and get back to innovating?Stay tuned📣 In the next article, I will discuss how we implement Platform-as-a-Service with SMB companies and our “cloudbar” B2B products. With Zero Ops-Personel.Additionally, I am talking about this topic on LinkedIn and YouTube.I wish you a great weekend, Adrian This is a public episode. If you'd like to discuss this with other subscribers or get access to bonus episodes, visit blog.adrianstanek.dev/subscribe

Hello, fellows!Today, I want to share some thoughts on my mind lately, especially as we navigate the complex decision-making world. I’ve realized that understanding is at the heart of every good decision we make, whether in our roles as CTOs, tech leads, business owners, or any other position that requires us to look at the big picture.I’ve learned that to understand something deeply, we must go through a cycle of acting, failing, succeeding, and reflecting. This isn’t just a theory for me; it’s something I’ve experienced firsthand. Sometimes, I’ve made decisions that didn’t pan out the way I’d hoped, but each failure has taught me invaluable lessons. Conversely, every success has reinforced what works and guided me toward better choices. It’s not about getting it right every time; it’s about continuously learning and growing.It’s easy to feel pressured to make quick decisions, especially when time is of the essence. But I’ve found that taking the time to learn and understand before deciding can make all the difference. It’s not about getting it right every time; it’s about continuously learning and growing.I hope my reflections today inspire you to embrace this learning cycle in your own journey. Let’s continue to act, fail, succeed, and, most importantly, understand.By the way, I have just started to create additional content on YouTube.I would appreciate your support on YouTube as well! 😀 In the shorts section, you will find multiple times weekly short clips on:* Software engineering & development* CTO topics* Software Entrepreneurship* MentoringsnackableCTO is a reader-supported publication. To receive new posts and support my work, consider becoming a free or paid subscriber. This is a public episode. If you'd like to discuss this with other subscribers or get access to bonus episodes, visit blog.adrianstanek.dev/subscribe

Hey everyone,Have you ever felt frustrated with the traditional project-based approach to software development? I know I have. I'm excited to share my thoughts on a game-changing concept: customized SaaS. Imagine a world where your software grows with your business, constantly evolving to meet your needs and driving real value at every step.In this video, I'll discuss why I believe tailored SaaS is the future. We'll explore how it fosters continuous innovation, strengthens the bond between business and engineering teams, and ensures long-term success. It's about moving away from the rollercoaster of one-time projects to a stable, sustainable model that benefits everyone.Let's dive into this new way of thinking together. I'm really looking forward to your feedback and thoughts. If this resonates with you, please share, subscribe, and let's start a conversation about how we can shape the future of software development.Thanks for tuning in!Adrian📣 YouTube ChannelWatch Short Clips + Longform on my I want to dive more deeply into topics based on my experience, which connects both the worlds of Software Engineering + Business. Since I am both an entrepreneur and a developer, I developed a specific set of skills and a bunch of learnings I want to share. Simultaneously, I will talk more about what we are working on. 🍪 Subscribe to my channel :)Takeaways for Entrepreneurs (Business Side)* Continuous Value Delivery: Customized SaaS allows for continuous value delivery, ensuring your business stays competitive and responsive to market needs.* Stronger Partnerships: Foster a collaborative relationship with your engineering team, ensuring alignment on business goals and visions.* Reduced Risk: Subscription-based models reduce upfront costs and financial risks associated with traditional software development.* Flexibility and Scalability: Easily scale your software solutions as your business grows without needing large, one-time investments.* Faster Time to Market: Leverage pre-built components and platforms to launch your products quicker and more efficiently.* Ongoing Improvements: Benefit from regular updates and improvements, keeping your software up-to-date with the latest features and technologies.* Budget Predictability: Monthly subscription fees provide more predictable budgeting than large, sporadic payments for traditional projects.* Customer-Centric Approach: Continuously gather customer feedback to refine and enhance your product, leading to better customer satisfaction and loyalty.* Focus on Core Business: Let your engineering team handle the tech while you focus on growing and scaling your business.Takeaways for Software Engineers (Tech-Side)* Agile Development: Embrace the true spirit of agile by delivering continuous value and iterating based on feedback.* Ownership and Responsibility: Develop a strong sense of ownership and responsibility for the product, leading to higher quality and more innovative solutions.* Collaboration with Business Teams: Work closely with stakeholders to understand their needs and align technical solutions with business goals.* Continuous Learning and Improvement: Regularly refactor and improve the software, staying ahead of technical debt and enhancing your skills.* Stable Work Environment: Enjoy a more stable and predictable work environment compared to the ups and downs of project-based work.* Cutting-Edge Practices: Implement modern development practices such as DevOps, test-driven development, and continuous delivery.* Transparency and Credibility: Maintain transparency with stakeholders about progress, challenges, and potential risks, building trust and credibility.* Innovation Opportunities: Leverage the freedom to experiment and innovate, driving the development of unique and effective solutions.* Sustainable Engineering Culture: Contribute to building a sustainable engineering culture prioritizing long-term success and continuous growth. This is a public episode. If you'd like to discuss this with other subscribers or get access to bonus episodes, visit blog.adrianstanek.dev/subscribe

This concept, often misunderstood or underestimated, is pivotal in shaping the success and harmony of our software development teams. Our recent podcast episode featuring Zac Beckmann and Jonathan Schulz delved deep into the intricacies of engineering culture and its impact on hiring, team dynamics, and overall productivity.Engineering Culture: The Backbone of Effective TeamsOur conversation began with exploring what it means to foster a healthy engineering culture. Zac Beckman, a seasoned CTO, emphasized that building an engineering culture isn't just about ticking off technical skills. It’s about nurturing smart, problem-solving individuals aligned with the team’s goals and mission. This alignment ensures that every team member feels valued and connected to the bigger picture, which is crucial for long-term satisfaction and productivity.Jonathan Schultz brought a fascinating perspective from his experience in staffing and team development. He highlighted the importance of understanding a company's core values and how they should permeate its culture. It's not just about having a playbook but ensuring that this playbook reflects and reinforces the company’s aspirations and values. This alignment between aspirations and reality forms the foundation of a robust engineering culture.Navigating Challenges with a FrameworkA recurring theme in our discussion was the importance of having a structured framework to guide decision-making processes. Whether assessing new hires or determining project priorities, having a clear, documented process helps teams stay aligned and focused. Zac and Jonathan both stressed that such frameworks are not about rigidity but providing a clear pathway for collaboration and problem-solving.One of the key takeaways from Zac’s insights was that a playbook or framework should facilitate team involvement and ownership. Teams are more invested in the outcomes When they are part of the vision and strategy development. This holistic approach ensures that everyone understands their role and contribution, making navigating challenges easier and staying motivated.The Balance Between Individual and Team GrowthAnother critical aspect we touched upon was the balance between individual career trajectories and team goals. Jonathan pointed out that leaders must keenly know their team members' career aspirations and growth. Regular, transparent conversations about career development are essential. This helps retain top talent and ensures that team members feel their growth is supported, even if it means eventually moving on to new opportunities.Zac shared a practical approach to dealing with the inevitable "no" situations. Rather than outright refusal, framing it as a discussion about trade-offs—what can be deprioritized to accommodate a new request—can be more productive. This approach fosters a collaborative environment where everyone feels their input is valued and considered.In ConclusionOur deep dive into the topic of engineering culture was enlightening, and it reinforced the notion that a robust and healthy culture is the backbone of any successful team. It's about more than just getting the job done; it's about creating an environment where everyone feels connected to the mission, valued for their contributions, and supported in their growth.I encourage you to listen to the full episode and reflect on how to foster a robust engineering culture in your teams. Whether you're a leader or a developer, your actions and attitudes are critical in shaping the culture around you.Thank you for joining us in this important conversation. Let's continue to build, innovate, and grow together with a strong engineering culture as our foundation.Best, Adrian This is a public episode. If you'd like to discuss this with other subscribers or get access to bonus episodes, visit blog.adrianstanek.dev/subscribe

Hey everyone, Adrian here.Today, I want to share some thoughts on a topic close to my heart: developer credibility. It's about how often we need discipline to get things done and how we deal with that little voice saying, "I'll do it tomorrow" or "I just want to watch Netflix."The Struggle with CredibilityWe recently discussed developer credibility on Our Tech Journey with Denis Čahuk, Zac Beckman and Jonathan Schultz, additionally inspired by a story from a fellow entrepreneur on Twitch who shared his story. Though a bit sad, his story reflects a reality many of us face. I've been in this business for 24 years and have seen—and made—plenty of mistakes. It's amazing how quickly a few bad decisions can threaten an entire company, affecting everyone's livelihoods.To keep a company running smoothly, we must act maturely and responsibly. Good communication and teamwork are essential. Blaming others for problems is easy, but reflecting on our actions is more productive. Are we doing everything we can to make things better? Are we taking ownership, mentoring others, and introducing good practices? Before pointing fingers, we need to ensure we’re doing our part.Self-ReflectionMany developers struggle with responsibility, often finding excuses instead of taking ownershipThink about it: Are you someone others can rely on? Do you consistently contribute positively, even when no one is watching? Many developers struggle with responsibility, often finding excuses instead of taking ownership. This lack of discipline and abundance of resistance—like the kind Steven Pressfield talks about in "The War of Art"—is a common issue.Discipline vs. ResistanceHow often do you feel inspired to work? How often do you have to push yourself to get things done? If that inner voice of resistance is frequent, it might be a sign to work on your trustworthiness. I face this challenge myself, sometimes failing to post on LinkedIn despite promising to do so. It's okay to slip up occasionally, but overall, we must strive to be reliable and consistently contribute to our surroundings—our family, colleagues, and peers.🍪 Finding the right balance is essential, and more importantly, trying to improve consistently – that is a safe recipe for becoming more credible.💪 Overcome your Resistance and subscribe 😀Responsibility and OwnershipTaking responsibility and ownership is crucial for a company's success. As developers, we must act like engineers, caring for our coding tasks and the broader company environment. Being responsible and communicative can elevate our team's credibility, making business stakeholders more likely to trust our insights and decisions.Becoming a Trustworthy DeveloperTo be trustworthy, we must contribute to our surroundings—friends, family, colleagues—before pointing fingers at others. It might be time to move on if we've genuinely tried to improve our environment and still find it unchangeable. However, before reaching that point, we must take full responsibility for our actions and their impact on the company.Have you?A Final ThoughtReflect on your inner resistance and discipline. We can improve our team's credibility by consistently acting responsibly and setting a positive example. This improvement will make stakeholders more likely to value our input and decisions. As developers, we must bridge the gap between technical expertise and trustworthiness, becoming reliable partners rather than just service providers.Thanks for joining me in this reflection on developer responsibility and credibility. Let’s keep striving for excellence and trustworthiness in our professional lives. Have a lovely Sunday,AdrianSeeking guidance? Whether it's a collaborative journey for your team or a personalized 1-on-1 mentoring experience, I'm here to help. Reach out, and let's find the perfect fit for you. This is a public episode. If you'd like to discuss this with other subscribers or get access to bonus episodes, visit blog.adrianstanek.dev/subscribe

Hey everyone, Adrian here, welcoming you back to another episode with . It's been an exciting journey exploring the depths of developer experience with all of you. Today, I want to share why this topic resonates deeply with me and why I believe it's essential for every developer, manager, and tech enthusiast.When discussing developer experience, we're not just discussing the tools or code we use. It's about the culture we create, the motivation we instill, and the joy we find in our daily work. I've always believed that a happy, motivated developer is a productive developer. Our discussions have highlighted the importance of fostering an environment where innovation thrives, feedback is valued, and every team member feels empowered. These elements transform a good team into a great one, and I'm thrilled to continue this exploration with all of you. So, let's dive in and uncover more insights to enhance our developer experiences together!🍪 DevEx (DX) is more than just picking the right IDE and Framework; it’s a holistic quality of the environment you have created and the culture that then grew based on that. This is a public episode. If you'd like to discuss this with other subscribers or get access to bonus episodes, visit blog.adrianstanek.dev/subscribe

No long post this time, just as a little Friday reminder:As software engineers, entrepreneurs, leaders, or just individuals, we should contribute to our environment, family, peers, and company.We are more than just the next ticket or fixing an important bug. Think beyond.Maturely doing this while taking responsibility leads to a form of ownership, which will make you credible.Enjoy your weekend, and take the time to recharge. This mindset of ownership and credibility can carry through all aspects of life, not just work.Take Aways* Responsibility and Ownership: Taking ownership of your work and actions is crucial. It's about more than just fulfilling tasks; it's about ensuring the company's success and contributing to something greater than yourself.* Avoid Finger-Pointing: Pointing fingers and blaming others is counterproductive. Instead, focus on creating a positive environment and introducing practices that promote teamwork and collaboration.* Continuous Improvement: Self-reflection and discipline are vital to growth. Continuously ask yourself if you are trustworthy, contribute to others, and are reliable when it counts.* Effective Communication: To ensure smooth operations, communicate clearly and frequently. This helps prevent misunderstandings and builds trust within the team.* Teamwork and Mentoring: As a leader or team member, encourage and mentor others. Set a good example by demonstrating responsible behavior and contributing to a positive workplace culture.* Earn Trust through Actions: Trustworthiness is earned through consistent and reliable behavior. Being a role model can inspire others and foster a supportive environment.* Contribute Beyond Work: Your impact goes beyond the workplace. Contribute to your family, peers, and the broader community to build a well-rounded approach to responsibility and ownership.Have a nice weekend 👋,Adrian This is a public episode. If you'd like to discuss this with other subscribers or get access to bonus episodes, visit blog.adrianstanek.dev/subscribe

In this episode, I delve into the transformative power of Platform-as-a-Service (PaaS) for small teams. I share my perspective on how PaaS liberates us from the time-consuming tasks of managing infrastructure, allowing us to concentrate on innovation and delivering value. Discover why adopting PaaS can be a pivotal move for small teams eager to scale and innovate efficiently without the burden of traditional IT overhead. Join me as we explore making technology serve our creative and business goals, enabling us to focus on what truly matters. This is a public episode. If you'd like to discuss this with other subscribers or get access to bonus episodes, visit blog.adrianstanek.dev/subscribe

Introduction: The Evolution of Web DevelopmentAs a developer with two decades of JavaScript experience, I've witnessed the evolution of web development languages firsthand. The shift from JavaScript to TypeScript is not just a trend but a strategic move towards mature software engineering practices. It's about creating a robust, scalable, and maintainable codebase that can support the dynamic needs of businesses today.Yes, of course, a team of great developers who are disciplined daily and focused on the code base and principles can achieve great results without TypeScript. The point is that with TypeScript, the average Developer can do the very same.The art of reducing complexity and creating work usable by less skilled colleagues is essential to Software Engineering.Type Safety: A Game-Changer for Large-Scale ApplicationsIt drastically minimizes runtime errors by identifying issues early in the development cycle, thereby saving time and reducing costs associated with debugging and fixing errors post-deployment. This early error detection is especially valuable in complex projects where errors can significantly impact the final product. The strict typing system and compile-time error checking ensure that the code is more reliable and easier to maintain, making TypeScript a strategic tool for developing robust, scalable, and maintainable applications.Enhancing Team Efficiency and Reducing Technical DebtFrom my perspective, TypeScript's greatest contribution to the business is its ability to reduce technical debt and enhance team efficiency. Its strict typing system and compile-time error checking ensure our code is clean, well-documented, and easy to maintain. This speeds up the development process and makes it easier for new team members to understand and contribute to existing projects.Keen on a deep dive into this topic or exploring others? I'm offering a 90-minute mentoring session exclusively for SnackableCTO fellowship members. Let's connect and unlock new insights together!Facilitating Collaboration Through InterfacesAnother key development team member, Camila, points out how TypeScript's interfaces have revolutionized how we plan and communicate project requirements. These interfaces act as contracts between different parts of our application, ensuring everyone on the team understands the system's architecture. This clarity is invaluable in a collaborative environment, leading to more efficient development cycles and a higher-quality end product.TypeScript and Modern Technologies: A Synergistic RelationshipIntegrating TypeScript with modern technologies like GraphQL illustrates its flexibility and power. By providing a strongly typed environment, TypeScript enhances the capabilities of these technologies, enabling more complex and reliable applications. This synergy is key to staying ahead in the competitive web development landscape.Conclusion: Why TypeScript is the FutureThe transition to TypeScript represents a significant leap forward in web development practices. Its emphasis on type safety, scalability, and collaboration aligns perfectly with the needs of mature software engineering and business objectives. As a Software Engineer, I advocate for TypeScript as a tool and a fundamental part of our development philosophy, ensuring our projects are successful, maintainable, and future-proof.🍪 I cannot imagine working in a full-scale app with JavaScript anymore.Best,AdrianSeeking guidance? Whether it's a collaborative journey for your team or a personalized 1-on-1 mentoring experience, I'm here to help. Reach out, and let's find the perfect fit for you.Continue reading with: This is a public episode. If you'd like to discuss this with other subscribers or get access to bonus episodes, visit blog.adrianstanek.dev/subscribe

From My Heart to Yours: The Essential Unity of Business and DevelopmentLet's talk heart-to-heart for a moment. I've walked through the corridors of many companies and seen the same scene repeatedly: business and development teams moving in parallel universes, barely intersecting. It's a sight that's both disheartening and deeply frustrating. Because, in my bones, I know these worlds aren't just connected; they're inseparable. They're like two halves of the same heart, pumping life into the body of a company.We're All in This TogetherImagine a world without "business people" on one side and "developers" on the other. Instead, there's just us - a team dreaming big and working hard to make those dreams a reality. In this world, developers feel it when sales hit a snag, too, because their work directly impacts sales. Conversely, if development faces hurdles, the sales team feels the pinch because they've got nothing to sell. We're in this together, for better or worse.Feeling the Pinch of DisconnectionThe business world, with its focus on budgets, deadlines, and concrete outcomes, often clashes with development's adaptive, iterative natureI've felt the tension, the frustration, and the stress of being caught in the no-man's-land between a rigid business plan and the fluid, “dynamic” world of development. It's like navigating a boat with a fixed rudder in shifting seas. The business world, with its focus on budgets, deadlines, and concrete outcomes, often clashes with development's adaptive, iterative nature. This clash isn't just counterproductive; it's damaging. It leads to missed deadlines, frazzled nerves, and projects that veer off course.A Cultural RevolutionWhat we need is nothing short of a cultural revolution. A shift from a fragmented, departmental mindset to a cohesive, unified team spirit. Imagine a company culture where everyone - from the CEO to the newest intern - sees themselves as part of a single, integrated team. Where challenges in development are tackled with the same urgency and commitment as challenges in sales because they're our challenges.This isn't about blurring lines; it's about erasing them. It's about recognizing that in the fluid, unpredictable journey of bringing a vision to life, we all need to be flexible, open-minded, and, above all, united.A Personal Plea from a CTOAs a CTO, I've straddled these worlds and felt the weight of bridging this gap. It's a task that's both daunting and deeply personal. It's more than aligning projects; it's about aligning hearts and minds towards a shared purpose. It's about fostering an environment where business acumen and development agility coexist harmoniously.Let's Make It Happen🍪 culture isn't just a buzzword; it's our company’s compass.So here's my plea to you, from the depths of my heart: let's break barriers. Let's build companies where unity isn't just an ideal; it's our reality. Where we celebrate our shared achievements and face our challenges shoulder to shoulder. Because when we do, we unlock the true potential of what we can achieve together.In this journey, culture isn't just a buzzword; it's our compass. It guides us, sustains us, and ultimately defines us. Let's commit to a culture of understanding, respect, and shared responsibility. Let's build companies and communities where everyone feels valued, understood, and integral to our success.Together, let's not just dream of a better way; let's make it our reality.snackableCTO is a reader-supported publication. To receive new posts and support my work, consider becoming a free or paid subscriber.Adrian,stackableCTO, Mentor, and CTO webbar.dev This is a public episode. If you'd like to discuss this with other subscribers or get access to bonus episodes, visit blog.adrianstanek.dev/subscribe

Hello, everyone. Today, I want to discuss Progressive Web Apps (PWAs) and why PWA is a good fit. I believe we should make it a year of PWAs. The current shift in acceptance toward PWA technology from major browser providers signals new opportunities, especially in the small to medium-sized business sector.You'll find separate iOS, Android, and web teams in many startups and organizations—even a backend team. Often, these are small groups of developers, not large teams, all working within a limited budget. But what is the ultimate goal? To create apps that offer users a great experience. So, why the default to native apps?Modern web’s feature-richness (Capability)Consider the advances in web technologies and devices. Today, we have a vastly different scenario that allows most user requirements to be met within a browser. Except for some edge cases like heavy GPU usage, PWAs can handle various functionalities, from image processing to WebRTC.Modern web applications provide features like push notifications, now available in PWAs, eliminating the need to develop native apps just for such capabilities. Offline first capabilities ensure that apps remain reliable and functional even without an internet connection, thanks to Web workers and other advanced browser features.Going Cross-PlatformWith a PWA, you manage a single code base that works across all devices via the web view. This uniformity is efficient and cost-effective, which we should all learn about. Over the next two weeks, follow us on our tech journey through my blog and LinkedIn for detailed information about PWAs.We'll discuss the strategic, tactical, and operational aspects of implementing PWAs, demystifying the technology, and turning theory into practice. I'll share my experiences as an early adopter in the SaaS sector, where we've used PWAs for years instead of native apps, saving money and avoiding numerous problems.PWA vs. Flutter (The Big Alternative)Progressive Web Apps offer a strategic advantage over Flutter, particularly regarding developer availability and search engine discoverability. The widespread familiarity with JavaScript simplifies the hiring process and allows for a larger pool of developers than Dart, which is specific to Flutter. PWAs are accessible through any web browser, ensuring a broad reach and eliminating the need for multiple codebases. Additionally, their seamless updates and SEO friendliness give them an edge in user acquisition and retention without the constraints of app stores.While Flutter may provide superior performance for complex applications, PWAs are increasingly closing the gap with offline capabilities, push notifications, and a native-like user experience. The evolution of web standards continues to enhance their capabilities, making PWAs an attractive option for businesses aiming for efficiency, reach, and ease of development and maintenance.📣 A detailed (less biased 😀) comparison between Flutter and PWA will follow this week. Subscribe to get notified!Stay tuned for our first session this Wednesday at 4 PM Central European Time, where we'll talk live for two hours with Denis Čahuk. You're welcome to join, comment, and share your experiences. Many in my LinkedIn audience have used PWAs, but most have not. I will show you why PWAs are a great choice for this year and beyond.See you on Wednesday, and I wish you a great week ahead. Goodbye, everyone. 👋Adrian,stackableCTO, Mentor, and CTO webbar.devsnackableCTO is a reader-supported publication. To receive new posts and support my work, consider becoming a free or paid subscriber. This is a public episode. If you'd like to discuss this with other subscribers or get access to bonus episodes, visit blog.adrianstanek.dev/subscribe

… personal opinions are shaped by individual experiences and preferences, professional opinions should be rooted in a broader context.In the ever-evolving landscape of technology, the distinction between personal and professional opinions is not just important – it's essential. As someone deeply immersed in this field, I've come to appreciate the intricate dance of balancing personal preferences with professional judgments, especially regarding front-end development.The Weight of Experience and OutcomesIn my journey through technology, I've always emphasized the significance of experience in shaping opinions. It's not just about what tools we use, React, Vanilla JS, Tailwind, or SQL, but the outcomes they drive. * How do they impact business goals? * What's their effect on team dynamics and user acceptance? * Are they enhancing or hindering maintainability? These are the exemplary questions that guide my professional viewpoint. Every project and technology stack I've worked with has taught me the multifaceted nature of tech decisions.Personal vs. Professional: A Delicate BalanceThe line between personal likes and professional advice can often blur. However, I firmly believe in the necessity of separating the two. While our personal opinions are shaped by individual experiences and preferences, professional opinions should be rooted in a broader context. They should consider the strategic, tactical, and operational impacts of a technology choice. This is especially true when recommending technologies like Tailwind or ORM systems – it's not just about what we like but what is most suitable for the given context.Clip: Professional opinions evolve through constant learning, adapting, and integrating diverse perspectives.A Holistic View of TechnologyDiscussing technologies like Tailwind, I've always strived to present a balanced perspective. Yes, there are advantages – ease of use, efficiency, and perhaps a better fit for certain projects. But it's equally important to discuss potential drawbacks. The key is understanding how technology fits different environments and meets diverse needs. This holistic view is what I advocate for in professional circles.The Dynamic Nature Of Professional OpinionsOne of the most exciting aspects of working in tech is that our opinions are never static. They evolve with each project, each challenge, and each success (or failure). This dynamic nature of professional opinions is something I cherish. It keeps me learning, growing, and staying relevant in a constantly changing field.Clip: Professional opinions transcend personal preferences, offering insights for understanding technology's impact in diverse contexts.Onward and Upward: The Journey of Continuous LearningI recommend Steven Pressfield's "The War of Art" to peers and colleagues as a testament to the journey of professional growth. As I continue to discuss modern web development, I aim to delve deeper into the nuances of personal and professional opinions. It’s not just about having a viewpoint but understanding its foundation and impact.The following quotes from the book highlight very important aspects:“The amateur plays for fun. The professional plays for keeps. To the amateur, the game is his avocation. To the pro it's his vocation. The amateur plays part-time, the professional full-time. The amateur is a weekend warrior. The professional is there seven days a week.”"Turning pro is a mindset. If we are struggling with fear, self-sabotage, procrastination, self-doubt, etc., the problem is, we’re thinking like amateurs. Professionals don't take their failures personally.""Turning pro is a mindset. If we are struggling with fear, self-sabotage, procrastination, self-doubt, etc., the problem is, we’re thinking like amateurs. Professionals don't take their failures personally."by Steven Pressfield, The War of Art | Turning ProTo all my fellow tech enthusiasts and professionals: let's embrace this journey of continuous learning and thoughtful discourse. Our field thrives on diversity of thought; through this rich tapestry of experiences, we can grow as professionals.Clip: Professional opinions are multi-layered, blending strategic, tactical, and operational insights for well-rounded decision-making.snackableCTO is a reader-supported publication. To receive new posts and support my work, consider becoming a free or paid subscriber. Thanks for your attention!Adrian, snackableCTO 🍪Looking for a Mentor?With 24 years of multi-domain experience as a CTO, entrepreneur, and software developer, I am a Fellow-Type mentor dedicated to your professional growth. We'll progressively and continuously work through your challenges through our weekly calls and Slack support.🍀 My goal is to empower you with the understanding and tools you need to solve these issues yourself.I'm not here to fix problems for you; I aim to enable you to tackle them independently. Explore my articles and videos to understand who I am and how I can assist you on y

🍪 Read the full article.In the latest episode of our podcast, 'Our Tech Journey– Vanilla vs. Frameworks,' we explore the dynamic world of front-end web development. Joined by Denis Čahuk, a technical and leadership coach, and Camilla, a junior front-end developer, we discuss the evolving practices and technologies in the field. Our conversation spans a range of topics, from the basic use of vanilla JavaScript to the complex functionalities of frameworks or libraries like React.Throughout the episode, we delve into the practical benefits of TypeScript, underscoring its role in improving team dynamics and project management. We also emphasize the importance of coding best practices, particularly focusing on linting and the establishment of clear coding standards.A pivotal aspect of our discussion is the strategic dimension of technology choices in a business context. We shed light on how the selection of frameworks such as React is influenced by business strategy, going beyond mere technical considerations.This episode presents diverse perspectives, covering strategic decisions at a high level and detailed coding practices. It is tailored for a wide audience, from developers and tech enthusiasts to anyone curious about the intricacies of modern web development. The insights shared aim to provide valuable knowledge to experienced professionals and those new to the field.We also mentioned Tailwind CSS, which will be the upcoming episode. Take a look at my article regarding Tailwind.React & Clean Architecture #1 – Denis’s take* TypeScript in Team Environments: Discussing the advantages of TypeScript for enhancing collaboration and project coherence in team settings.* Comparative Analysis of Vanilla JavaScript vs. Frameworks: Delving into the merits and drawbacks of using vanilla JavaScript as opposed to popular frameworks like React.* Best Practices in Coding and Linting: Sharing insights on the importance of adhering to coding standards and best practices, particularly in linting and code quality.* Role of Frameworks in Business Strategy: Emphasizing how the choice of a framework like React is deeply intertwined with business strategy and not just based on technical factors.* Evolving Landscape of Web Development: Exploring the current state and future trends in web development, focusing on the dynamic nature of technologies and practices in the field.* Practical Insights for Developers: Providing practical advice and insights for both seasoned professionals and newcomers to the field of web development.React & Clean Architecture #2 – Adrian’s takeReact & it’s ecosystem – It’s a business decision Frontend & Modern Web StandardsMy perception of Frontend / Backend Ratio is about 80/20snackableCTO is a reader-supported publication. To receive new posts and support my work, consider becoming a free or paid subscriber. This is a public episode. If you'd like to discuss this with other subscribers or get access to bonus episodes, visit blog.adrianstanek.dev/subscribe

In this episode, we welcome Bryan Finster, a veteran software developer from Defense Unicorns with nearly 30 years of rich experience in the field. Bryan takes us through his journey from the early days of DevOps in the 90s to the challenges of adapting to less frequent delivery cycles in subsequent roles. He shares pivotal insights on the evolution of his mindset towards continuous delivery and the crucial role of customer feedback in software development. Additionally, Bryan emphasizes how often the real issue lies in outdated requirements rather than just software bugs, shedding light on the perishable nature of backlog items in a rapidly changing market. Don't miss this opportunity to learn from Bryan's extensive experience and discover how to navigate the complexities of modern software development more effectively.Special Thanks to Co-Host Denis Čahuk and I recommend to follow 🔮 Crafting Tech Teams! Read the article:snackableCTO is a reader-supported publication. To receive new posts and support my work, consider becoming a free or paid subscriber. This is a public episode. If you'd like to discuss this with other subscribers or get access to bonus episodes, visit blog.adrianstanek.dev/subscribe

So, will we be replaced soon by AI as developers? It's a great question, and I believe no defined answer exists. On the other hand, there are already many important things for us developers to understand and things we can practice to make it less likely to become substituted one day.In the live session "Will AI Replace Developers," we discussed this topic in detail and how we utilize tools like chatGPT and GitHub Copilot to aid our work, improve it, and learn while doing it.Together with Denis Čahuk we discussed this exciting topic!🟢 Listen on SpotifyRead the full ArticleAI acts like a "Highly intelligent, but careless, slightly confused, apathetic colleague with dementia"Because AI is not a software developer or engineer; it doesn't make decisions or even stop you from making mistakes.Looking for a Mentor?With 24 years of multi-domain experience as a CTO, entrepreneur, and software developer, I am a Fellow-Type mentor dedicated to your professional growth. We'll progressively and continuously work through your challenges through our weekly calls and Slack support.🍀 My goal is to empower you with the understanding and tools you need to solve these issues yourself.Find me on MentorCruise.com.snackableCTO is a reader-supported publication. To receive new posts and support my work, consider becoming a free or paid subscriber.Recommendation: This is a public episode. If you'd like to discuss this with other subscribers or get access to bonus episodes, visit blog.adrianstanek.dev/subscribe

In this episode, we tackle the tech industry's reluctance towards Friday deployments, revealing how this apprehension often points to immature DevOps practices. We delve into the transformative power of continuous delivery and the crucial role of a feedback-oriented culture in software development.This podcast serves as a call to action for developers of all levels to view end-of-week deployments as a testament to their team's maturity and capability. Join us in exploring how embracing Friday deployments can reshape our approach to software delivery and strengthen our DevOps culture.Special Guest: Tobias Mende Hosts: Denis Čahuk Adrian Stanek Camila MerinoA 🎄 holiday special: 30% off for all mentor resources on this blog forever.Read the Full Article: This is a public episode. If you'd like to discuss this with other subscribers or get access to bonus episodes, visit blog.adrianstanek.dev/subscribe

In this episode, we delved deep into the concept of DevOps, mainly focusing on its application in small and medium-sized businesses. We explored the essence of DevOps as a culture and mindset, emphasizing the importance of end-to-end responsibility, continuous integration, and delivery. We highlighted the distinction between mere programming and being a software developer, stressing the significance of understanding and addressing business problems. The DevOps ChallengesWe also discussed the challenges and practical strategies for implementing a DevOps culture, such as minimizing handoffs and fostering a collaborative environment. The conversation also emphasized the importance of learning, iterating, and making proactive changes to improve processes and workflows.During our discussion, DevOps in the context of small businesses was defined as follows:* DevOps as a Culture and Mentality: It was emphasized that DevOps is not just a role or a team but a cultural shift in how technology and business processes are approached. It involves a holistic view of the entire product lifecycle, from development to deployment and operation.* End-to-end Responsibility: The importance of having end-to-end responsibility in DevOps was highlighted. This means owning the process from beginning to end, including development, deployment, monitoring, and maintenance.* Application Beyond Large Enterprises: It was pointed out that the principles of DevOps are not confined to large organizations but are equally applicable and beneficial to small businesses. DevOps in small businesses involves streamlining processes, enhancing collaboration, and improving efficiency.* Practical Implementation: For small businesses, implementing DevOps means adopting continuous integration and continuous delivery and fostering a collaborative environment where different disciplines within the tech team work closely together.* Business Alignment: DevOps in small businesses was also discussed in terms of aligning technology processes closely with business objectives, ensuring that the technical aspects of product development directly support the company's overall goals.Listen to on: 🟢 Spotify🔴 Youtube🔮 Take a look at Denis Čahuk Newsletter regarding our last event around DevOps:Learning more about DevOps in Denis Čahuk Book Club! This is a public episode. If you'd like to discuss this with other subscribers or get access to bonus episodes, visit blog.adrianstanek.dev/subscribe

As software developers, it's crucial to understand that well-being and burnout are not just trendy buzzwords but significant aspects that impact our professional and personal lives. In our conversation with Richard Donovan , Denis Čahuk and Camila Merino, we've delved deep into these vital topics, probing their nuances and implications in our field.As a software developer, ask yourself if you prioritize your well-being, or do you often relegate it to a lower status amidst your myriad responsibilities? This introspection is crucial in an industry that is as demanding as ours.👉 Stay tuned for the newsletter on Sunday, “Deep-Dive: Own your Well-Being. “My personal experience with burnoutlosing control over our work-life balance significantly contributes to finding ourselves in negative situations as software developersI overlooked the importance of managing stress effectively for a long time. This neglect often led me to a point where my stress levels became unmanageable, overshadowed by a relentless pursuit of "more important" tasks. This pattern, where one's well-being is consistently sacrificed for professional demands, is a common trap among developers and entrepreneurs. Does this scenario resonate with your experiences?As entrepreneurs or developers, we find ourselves in a position of vulnerability, essentially around the clock. This constant exposure to high-stress situations without adequate coping mechanisms or support systems can lead to burnout – a very real and debilitating condition, not a mere myth.Furthermore, losing control over our work-life balance significantly contributes to finding ourselves in negative situations as software developers. When we fail to establish boundaries or recognize our limits, we inadvertently set ourselves up for a cascade of adverse outcomes, including burnout and decreased productivity. Therefore, it's imperative to develop strategies to manage stress and prioritize well-being, not just for our health but also for our effectiveness and longevity in the field.Looking for a Mentor?With 24 years of multi-domain experience as a CTO, entrepreneur, and software developer, I am a Fellow-Type mentor dedicated to your professional growth. We'll progressively and continuously work through your challenges through weekly calls and Slack support.🍀 My goal is to empower you with the understanding and tools you need to solve these issues yourself.I'm not here to fix problems for you; I aim to enable you to tackle them independently. Explore my articles and videos to understand who I am and how I can assist you on your journey.Find me on MentorCruise.com. This is a public episode. If you'd like to discuss this with other subscribers or get access to bonus episodes, visit blog.adrianstanek.dev/subscribe

Welcome to the latest episode of the CTOFellows Podcast, where technology leaders come together to explore high-level topics and challenges in the tech world. In this episode, our hosts, Camila Merino and Denis Čahuk of 🔮 Crafting Tech Teams , join me in a deep dive into the complexities of legacy system migrations and modernization.The article “About Legacy Migrations with Strangler Fig” on MondayTomorrow, I will release the new article as a Newsletter issue. Stay tuned for the feedback from the LinkedIn Audience and what we have learned through the sessions.Watch the Full Live Stream👉 Watch on YouTube.👉 Listen on Spotify.comClip Preview “Don’t Only Rely On Discipline”The Strangler Fig ApproachWe discuss the nuances of transitioning from legacy systems to more modern, efficient architectures. Our conversation covers various topics, including the Strangler Fig pattern, the critical path for successful migrations, and the role of continuous delivery in these processes. The Strangler Fig approach, coined by Martin Fowler, is a software development method for gradually transitioning from a legacy system to a new system. It involves incrementally replacing parts of the old system with new functionalities, akin to how a Strangler Fig tree envelops and supplants a host tree. This method maintains system functionality during the transition, reducing the risks associated with a complete overhaul. It facilitates continuous modernization and learning, ensuring that the new system doesn’t morph into a replica of the old, monolithic architecture it replaces. This approach is particularly valuable in complex environments where an immediate complete system replacement is impractical or risky.Choosing the right target platform for migrationsWe also delve into the practical aspects of choosing the right target for migration, focusing on cloud-native solutions and the benefits of Platform as a Service (PaaS) for small to medium-sized businesses.Not just for seniors!Our discussion is not just technical; it’s also about the people behind the technology. We highlight the importance of team dynamics, the challenges junior developers face, and how to foster a culture of continuous learning and improvement.Join us as we navigate the journey from recognizing the need for migration, defining the migration path, and successfully executing it while maintaining the spirit of the original system. Whether you're a seasoned CTO, a budding developer, or just interested in the evolving landscape of technology leadership, this episode offers valuable insights and practical advice.Watch the full episode 🍪Thanks for reading, and have a great Sunday!Adrian 🍪snackableCTO is a reader-supported publication. To receive new posts and support my work, consider becoming a free or paid subscriber.Looking for a Mentor?With 24 years of multi-domain experience as a CTO, entrepreneur, and software developer, I am a Fellow-Type mentor dedicated to your professional growth. We'll progressively and continuously work through your challenges through our weekly calls and Slack support.🍀 My goal is to empower you with the understanding and tools you need to solve these issues yourself.I'm not here to fix problems for you; I aim to enable you to tackle them independently. Explore my articles and videos to understand who I am and how I can assist you on your journey.Find me on MentorCruise.com. This is a public episode. If you'd like to discuss this with other subscribers or get access to bonus episodes, visit blog.adrianstanek.dev/subscribe

Dive into this episode where we delve into the essentials of tech leadership that nurtures and unlocks the full potential of developers. Learn how a culture of continuous learning and mentorship can transform your team into a dynamic force for innovation and growth. Gain actionable insights from industry veterans on creating a resilient, self-reliant team ready to tackle the tech world's evolving challenges. Join us for a session rich with strategies for fostering a thriving tech environment. This is a public episode. If you'd like to discuss this with other subscribers or get access to bonus episodes, visit blog.adrianstanek.dev/subscribe