Michael Whidby

A new quick Cypress blog post about my "should read" assertion https://lnkd.in/eUC3ryaS

22

3 Comments

Tech debt causally harms cost-of-change and meantime to adapt to market. You release a defect free, fully functioning piece of software that will *never change* but its code design is a mess. Would you care about tech debt? NO! Why? Because you don't need to change it. It works. It could be written in Whitespace or BrainF**k. Who cares. Nobody is going to look at it. What if it had a tiny change maybe once a year? How much would you care then? A bit more. Maybe Whitespace is ruled out but if it took a couple of days to work out what was happening would there be any business value in paying down the debt? 1 week of refactoring would take nearly 3 years before you break even. Not worth it. This isn't a hypothetical, I have built and maintained software which fits this exact scenario. When does the debt start to have a negative affect on cost-of-change and meantime to adapt to market? Once a quarter? Once a month? Now imagine that you are making hundreds of changes a day. How much is that tech debt costing your business now? And this is assuming that the software is 100% bug free and perfectly functioning. Now extend that, you are making hundreds of changes a day and the internal quality issues are causing you to create bugs which has the knock on effect of harming the user and customer's productivity. Devaluing your product. What's the cost of that debt to your business now? As engineers we need to talk more about how we are protecting and investing in technology in order to reduce cost-of-change and meantime to adapt to market, rather than talk technical debt. Because if we don't need to change or change rarely, then technical debt is not a problem.

39

11 Comments

💡 The Untold Power of Hard Work: Why Effort Outshines Talent 💡 Early in my career as a project manager, I had the opportunity to work with two distinctly talented team members on a high-stakes project. 🌟 Team Member A: A naturally brilliant coder who could solve complex algorithms in minutes. 🌟 Team Member B: Not as gifted but relentlessly hardworking, always staying late to refine their skills and triple-check their work. Just days before the deadline, an unexpected challenge threatened the project’s success. Guess who stepped up? The hardworking team member. Their commitment, preparation, and grit turned what could have been a crisis into a moment of triumph. This experience taught me a lesson I carry to this day: 🚀 Hard work beats talent when talent doesn’t work hard. Key Takeaways: 1️⃣ Talent may open doors, but hard work ensures you walk through them. 2️⃣ Consistency and effort transform potential into lasting results. 3️⃣ In the face of challenges, persistence triumphs over complacency. 💡 “Success is the sum of small efforts, repeated day in and day out.” – Robert Collier Let’s celebrate the power of hard work and inspire each other to keep pushing forward. 💬 Have you ever witnessed hard work outshine talent? Share your story in the comments-I’d love to hear how effort and determination made the difference in your journey! #HardWork #TalentVsEffort #Leadership #GrowthMindset #Success. #Inspiration. #SkillArbitrage Ramanuj Mukherjee Abhyuday Agarwal SAURABH RAJ

15

2 Comments

I once asked a lead engineer on Angular: Which is better: Angular or React? His response: "Both require good engineering to be effective." So, my developer friends, consider this a reminder that "frameworks" like Diátaxis are fine, but they still require good engineering--such as UX, information architecture, style, maintenance processes, and so on--to create great documentation experiences for your customers. Alas, the framework alone isn't enough.

35

7 Comments

The latest Qwen2.5 Coder models outperform Sonnet and 4o on some benchmarks. Try it on Wingman today!

4

Lessons learned from a technology migration https://lnkd.in/ghpHeqee

2

1 Comment

https://lnkd.in/gu46i_EN Instead of discussing VSA - Vertical Slice Architecture Discuss team organization. The ability for a few developers to split off within their larger team And work on a feature full-slice. Full-stack, but with teamwork Martin Fowler spells it out well that because of Conway’s Law, this will impact our Architecture And even a backend architecture-only change will typically shine through to the front-end — Monolith vs Microservice? Who cares? If you need a website, build a website If you need a desktop app, build a desktop app If you need a mobile app, build a mobile app Use full-slice development. And you can more easily use other architectures. Like Hexagonal Architecture: The father of microservices — Then designs & patterns should be used

6

1 Comment

🌟 Attention Engineering Managers and Technical Leaders! 🌟 In just two weeks, on June 28th at 10 AM PDT, I’m excited to host an interactive roundtable on Feature Flags and Delivery in conjunction with ELC! 🚀 Why Attend? This is a collaborative discussion where your expertise and curiosity are key! Whether you're experienced or eager to learn, your contributions are invaluable. 🔍 Discussion Points: - Decoupling Processes - Boosting Team Efficiency - Optimizing Feature Delivery - Tracking Platform Usage Expect rich conversations on best practices, unique implementations, methodologies, and the latest tools enhancing feature flagging and delivery. Who Should Join? - Engineering Managers - Technical Leads - DevOps Engineers - Software Developers This roundtable is your chance to: - Share your experiences - Gain new insights - Network with peers - Discover practical recommendations RSVP Now and mark your calendars for June 28th at 10 AM PDT! Let’s collaborate and elevate our skills together! #EngineeringManagement #TechLeaders #FeatureFlags #DevOps #SoftwareDevelopment #TeamEfficiency #TechRoundtable

11

Woah there, "hiring juniors is about making your entire team better" is exactly the kind of unhelpful, oversimplified headline that needs an A4 sheet of caveats adding. Juniors are a massive investment and the suggestion that simply hiring them will make the team stronger is not right at all. Processes that support the career development of more junior engineers aren't accidental byproducts, they're deliberate. Senior engineers need to be provided the time, headspace, training and support to coach, mentor and develop their more junior colleagues. You know what doesn't work? Hiring juniors into overstretched/under-resourced teams where the seniors are overcommitted and under pressure to meet aggressive deadlines. And I've seen this more times than I care to mention. In the scenario where you've got small teams that are under pressure, and the existing engineers don't have time or headspace to coach someone junior, you are *always* better hiring another senior. Someone who reaches autonomy faster will always be better in that situation. If you hire a junior into that team you won't get better code reviews, more innovation or a richer culture of learning. You'll end up with an under-developed junior who struggles to progress their career, and some seniors who feel like they're doing the junior a disservice by being unable to support them properly. It's horrible. And I've been there. Were we all juniors once? Yep. Should *every* team hire juniors? Absolutely not.

4

It can't be a coincidence that my favorite band, LinkinPark, is celebrating their comeback in the same year I decided to step away from my current leadership role to become a software engineer again. Damn, it feels good hammering some lines of code on the keyboard while listening to LinkinPark again. 😅🤘🎵 Why did I change my role, you ask? The short answer: less talking, more doing. I’ve always loved leading creative teams and helping people shine. But leadership isn’t only about a title or a place on the organizational chart — it’s about setting an example and inspiring others. As a Principal Software Engineer at Shopware, I see my role as one where I can lead by example, pushing boundaries and driving innovation from the frontlines. It’s a hands-on approach, focused on building and making things happen. This is not a step back, but just another chapter in my career and not the last time I will try to be a good leader. "Heavy is the crown". https://lnkd.in/emHAJXkj

44

Good post. I’ll just add that over-engineering and under-engineering are more orthogonal dimensions than the opposites. One can have neither or one or both. Ditto with “best practices”. A third dimension, almost completely divorced from the above two. This, of course, if you’re working on something tangible and nontrivial. If what you need is another “RESTful API” with “AI capabilities”, deployed via Kubernetes and Terraform, monitored with ELK, and developed and maintained by high-churn mid-to-senior engineers, then by all means use all the best practices you are aware of, and don’t forget to get all the agile coaches within reach onboard!

7

3 Comments

Join me for an interesting session on #devex and how to think about organizational and engineering metrics.

15

Let’s just store and pass this around as a CSV is one of the mistakes that I made in my career. At some point though you too will probably deal with CSV files since they are easy to create and everyone thinks they know how to work with them. After all you can open them in anything and basically anyone can see the data. Let’s talk about 3 of the pitfalls and I’ll give you a couple of ideas on how to work around them. ❇️ They have no defined schema. Best case you have a header but it’s not like any of those columns are not null let alone have a data type defined for them. ❇️ Parsing isn’t straight forward. How to handle escape characters and other issues isn’t always clear. Different parsers handle it differently. ❇️ Trying to have a complex structure in a CSV file is a mess. Most of the time with complex structures I’d challenge the data modeling work that has been done but frequently that can’t be helped with source systems and sometimes it’s just necessary. My main recommendation here is to avoid CSV and other unstructured data whenever possible. This means if you are receiving it the first step is to convert to something with more structure. However, since at some point you’ll be forced to work with it, make sure your testing is thorough and the data contract is as well defined as it can be. What has helped you when working with unstructured data?

3

3 Comments

> "But isn’t it a little strange that despite so much information, teams and companies continue to be so challenging for most leaders? (1) Teams and companies are notoriously complex and difficult. (2) Reading and listening to content provides an illusion of learning. (3) Most leaders are on their own and don’t have good role models." I like how Paulo emphasises the importance of developing your coaching skills to support your teammates: > "Coaching is all about helping other people change (in some way). And we have an innate tendency to resist change. A good coach learns how to spend time in the other person’s mind, curious about their belief systems and mental models until it becomes second nature to do so." Just as a skilled guide equips you with a map and compass, a coach, mentor, or supportive external group can furnish you with the tools and frameworks needed to navigate your journey. They can also help you identify hidden obstacles that might otherwise impede your progress.

1

As an engineering leader you may have to step away from code for extended periods of time and it can be *very* hard to get back into it. You lose context, projects change, tech changes and sometimes it’s just anxiety that you’ve lost your touch. I have found that AI tools can really help get through this. Copilot, ChatGPT, etc can help jog your memory and refresh your skills in a short period of time.

11

Tech leaders should have the courage to ask seemingly foolish questions. It's important to remember that you're not the most knowledgeable person in the room and that you don't have to have all the answers. Your role is to support the team so they can do their best work. Being proud of their contributions is important, and having a big ego will only get in the way. Additionally, leaders asking foolish-sounding questions helps the team feel comfortable following suit. In my experience, some of the most brilliant solutions have been developed by simplifying a complex problem constructed from seemingly outlandish questions and ideas. Be brave, and don't fret about sounding foolish; your team's growth and results matter most. 

20

Are you looking to improve your development team's focus and accelerate cycle time? 🤔👨‍💻 My latest blog post gives a concise overview of why vertical slicing could be the solution you've been looking for! 🚀💻 With a few examples of its benefits, you can quickly assess whether this approach is right for your team. 🔍💡 As a special bonus included all of the Lucidchart and Noun Project links 👇 #verticalslicing #softwaredevelopment #developmentefficiency #productivityboost

15

Wow, y’all. What a conference! 14 sessions in 2 days and my brain is 🍝! But dang, are those noodles tasty! Props to all the folks who put together such a valuable learning experience at Agile & Beyond - it was my first time attending and I’m very much looking forward to returning next year! #agile #agileandbeyond2024 #detroittech #detroittechnology #itconference #agilebusiness #techcommunity

21

2 Comments