Gary Holtz

Leadership style is such an overloaded term. I’ve always thought of it less as a label and more as a compass - A set of principles I lean on whenever I’m faced with a decision. The real magic happens when my team understands that compass too. It means they’re not blindsided by my choices, and they can even anticipate how I’ll respond to new ideas. Instead of seeing decisions as random, they see the consistency which then builds confidence and trust.! What guiding principles do you rely on most often when making decisions as a leader?

63

7 Comments

This week, I was re-reading the book "Accelerate" and uncovered invaluable insights. Here are the top 3 takeaways: 1️⃣  **Great Software Delivery = Great Business Performance** It’s not just about IT anymore. Companies that build and release software quickly and safely absolutely crush it in the market. Speed and stability aren’t trade-offs — you can (and must) have both. 2️⃣ **Focus on the Right Four Metrics** Most teams track way too many things. Accelerate proved that four simple metrics — deployment frequency, lead time, change failure rate, and time to restore — tell you almost everything you need to know about team health and business agility. 3️⃣ **Culture Is the Real Secret Weapon** Want faster releases, better innovation, and happier teams? It starts with psychological safety, trust, and empowering people. Tools matter, but culture matters more. #Accelerate #DevOps #Leadership #SoftwareEngineering #BusinessGrowth #ContinuousImprovement

55

I had my first experience with vibe coding over the weekend and here is my story... I had watched some videos and downloaded the needed tools. I have been using AI for a ton of stuff (also in VS Code for code completion and like) but as a pair programmer, this was new. I asked for a small console app in c#, which could download a html file and extract some data from that. First attempt could download the file, but couldn't find the data, next attempt, next attempt, next attempt,... and to make a long story short, it wasn't able to complete the mission - it could not find the data, even though I explained the pattern in which the data was available. So, I found myself having spend 2 hours on getting a program.cs which was around 1000 lines of fairly complicated code to solve a simple task. Next attempt was to write some code (manually) in PowerShell (took me less than 30 minutes and ~ 50 lines). Then I asked AI to create a c# console app that did the same as this PowerShell script. Result was perfect - I wouldn't change a line - it worked perfectly. So... - what did I learn from this. 1. My first prompt was an explanation in english of how to solve the problem and that clearly wasn't detailed enough. 2. My second prompt was the actual answer to the problem (in PS instead of english) and it could understand and solve the problem. If I compare this to human developers. If I had given the first instructions to a junior developer, I think he would have asked me some questions and ended up with a solution to the problem. AI however (at this time) doesn't ask questions - it assumes that it knows and whenever there are chances of ambiguity, it will pick one (any is good) and run with that. (maybe I just don't know how yet) Now, the mother of all mistakes are assumptions... - I would love if AI would tell me about the assumptions it makes or ask me a question whenever there are chances of ambiguity (maybe I just don't know how yet) I have the feeling that AI (at this time) is a very very junior developer without any real life experience, but having enough coding experience to write very complex and working code, who thinks that it knows it all (maybe I just don't know better yet) It feels like the missing part for me is to explain to AI all the things that I normally take for granted (I gotta learn that). I have a few other small projects lined up for vibe coding and will explain about my experiences here as I progress. In the meantime, I am happy to hear about your experiences about vibe coding. What works, what doesn't work, best practices and recommendations... #MsDyn365bc #vibecoding #AI #LLM BTW - this message was untouched by AI (as if you couldn't tell...), but the image was created by AI...

118

29 Comments

Ok Rust, there is a lot I genuinely love about your language design, but can we all acknowledge having self and Self as keywords that mean different things was a horrible decision. I don’t care what the rationalization was - having a key semantic characteristic differ by freaking capitalization is absurd. We shouldn’t sound like philosophers when we write code - “we each have multiple selves, and they represent different meanings”. Anyway, CodeQL has Rust support now, so for all of the security minded devs there is finally a global interprocedural analysis engine at your disposal.

68

23 Comments

OK, I am going to join the fray and weigh in about AI coding assistants. I have about a decade plus of enterprise software engineering experience under my belt, so I think I am competent to talk about this. THE GOOD: * Knowing a particular language or not no longer really seems to matter. I'm a bit rusty at Python. Instead of slowing me down, this literally seems to make zero difference when coding with Windsurf + some LLM (Gemini 2.5, Claude Sonnet, whatever) * Similarly, knowing the language's conventions don't seem to matter. "Make this more Pythonic" and ta da. Seriously, it's magical. * Test boilerplate is easy as pie. I really don't think there's much excuse not to write tests anymore. * Asking it to summarize what a really long class or something actually does is pretty nifty, especially in conjunction with reading through the code. * Commonly used things, like retries or exception handling or whatever, are absolutely effortless. * Rubber ducking with it is very nice. In the absence of co workers to talk to, it provides a really nice listening ear for brainstorming design ideas. It gives helpful feedback and suggests pre-existing libraries and similar open source implementations, saving buckets of time. * It really is autocomplete on steroids. Coding, especially with Windsurf, is an absolute breeze. THE BAD: * Abstraction. Hoo boy. It does not do well at this. Coding with any level of abstraction, especially when you're trying to abstract away hardcoded stuff and shift it to a config pattern is just.... ugh. It is like buddy programming with an incredibly enthusiastic but VERY dull-minded junior engineer. It's awful. If it does do abstractions, they're poorly chosen and clearly ripped off from someone else doing something barely similar. CONCLUSION: Well, that sounds like a lot of good and not very much bad, right? Yes, except the abstraction part is really important when it comes to building maintainable, modular, reusable code. And it's the hard part of coding, really. Does this revolutionize software development? Yes! But abstract thinking is fundamental to human intelligence. It's why our languages are full of metaphor. It's how humor works. And, unsurprisingly, it is how software development works.

520

72 Comments

I really need to find time to write more about developer relations. There are so many things I have to share that could help newer folks in a role like that, more experienced ones to think differently, companies wanting to have devrel, people or other business units working with developer advocates. It would help everyone (or not, I don't have the holy truth but I'm doing that successfully for more than a decade) to better understand what, and how (also why) we do things the way we do them no matter the size of the company. Developer relations is so different that everything else in its approach. It's a fine mix of a lot of things including personal branding, as unintuitive as it could sound. It's a fine art (yeah, it's pretentious of me, but it's true, like many other roles out there that I couldn't even phanthom to be able to do).

28

9 Comments

I thought mentoring would be about giving back to the community. Turns out, it was one of the most selfish things I could do for my career growth. When a junior developer asks "Why do we use Optional instead of null checks?", you can't just say "because it's better." You need to understand the cognitive load difference, the error patterns it prevents, and when it actually matters. Teaching forces you to move from "I know how to do this" to "I understand why this works." 𝗛𝗲𝗿𝗲'𝘀 𝘄𝗵𝗮𝘁 𝘀𝘂𝗿𝗽𝗿𝗶𝘀𝗲𝗱 𝗺𝗲: 🔍 𝗙𝗿𝗲𝘀𝗵 𝗽𝗲𝗿𝘀𝗽𝗲𝗰𝘁𝗶𝘃𝗲𝘀 𝗰𝗵𝗮𝗹𝗹𝗲𝗻𝗴𝗲 𝗲𝘃𝗲𝗿𝘆𝘁𝗵𝗶𝗻𝗴 - Junior developers ask questions senior developers stop asking. "Why are we doing it this way?" often reveals we're following outdated patterns. 🧠 𝗘𝘅𝗽𝗹𝗮𝗶𝗻𝗶𝗻𝗴 𝘀𝗶𝗺𝗽𝗹𝗶𝗳𝗶𝗲𝘀 𝘆𝗼𝘂𝗿 𝗺𝗲𝗻𝘁𝗮𝗹 𝗺𝗼𝗱𝗲𝗹𝘀 - Just like records simplified data classes, teaching has the same effect on understanding. Breaking down complex concepts for others makes you better at recognizing when your own code is too complex. 💡 𝗣𝗮𝘁𝘁𝗲𝗿𝗻 𝗿𝗲𝗰𝗼𝗴𝗻𝗶𝘁𝗶𝗼𝗻 𝗴𝗲𝘁𝘀 𝘀𝘁𝗿𝗼𝗻𝗴𝗲𝗿 - After explaining the same debugging approach multiple times, I realized I had developed a systematic method I wasn't even conscious of. Teaching made my implicit knowledge explicit. 𝗧𝗵𝗲 𝗯𝗲𝗮𝘂𝘁𝗶𝗳𝘂𝗹 𝗶𝗿𝗼𝗻𝘆? In trying to help others become better developers, you become the kind of senior developer that people want to learn from. Start small: Explain your code changes during reviews. Write documentation as if teaching someone new. What's one thing a junior developer taught you recently? #SoftwareDevelopment #Mentoring #CareerGrowth #Java #TechLeadership #ContinuousLearning

51

2 Comments

As I continue to work with AI daily in the work of software development and QA I see these tools evolving in not so surprising ways. Think of something that was once given to you freely and eventually it becomes commodicized. As it’s value become more apparent the more businesses look for ways to slice and dice that item into sellable units. I suspect we will see AI tools evolved much in the same way. As it is, I am now paying for a monthly subscription to Microsoft and likely soon, Google. This gives me greater access and capabilities of these tools. But when was a vendor of services content with a single service level? One interesting and reoccurring challenge I have with AI tools in the way I use them is related to context. When I work with Copilot on some code changes, I need it to retain contextual understanding of the work we have done. Frustratingly, I find Copilot sometimes remarkable at remembering some facts about the work we completed over the last 20-30 minutes and surprised when it seems clueless to something we just completed moment before. Trying to figure this out or predict it seems not possible, as if the tool itself has been programmed to be incredibly useful and then forgets it own name. I’ve even developed my own set of AIAssist tools that have been helpful and that I deploy across my projects. These give me some great advantages that can be implemented very quickly. Even those tools can lead AI to give invaluable insights and then again, seem to be completly ignorant to it’s context and surroundings I can say confidently, at this moment, AI tools that I have access too are incapable of writing long term sustainable applications. They can create simple web pages and scripts but its long term planning seems to be lacking, something I am certain others have seen as well. Our QA community must get real world experience with these tools, it’s not optional and will likely lead some to make a good living identifying it’s weaknesses and why it produces certain defects not common to experienced software architects. Continuing the quality journey with you. Greg

23

4 Comments