Shea Paris

Most bugs don’t get fixed. They get patched. A quick change. Ticket closed. Everyone moves on. Until the same issue shows up again… just slightly different. So another patch goes out. This isn’t progress. It’s debt. Teams aren’t solving problems—they’re avoiding the root cause to stay fast. And over time you end up with a system full of “fixes” that no one trusts. If you’re fixing the same problem twice, you didn’t fix it. You just delayed it.

2

AI needs to be understood as accelerator, not a replacement. Software ecosystems are complex enough and require thoughtful planning and execution to keep things running for our business partners. We solve problems for the business, not create more.

2

Retiring from Software Development: A Few Final Thoughts After many years in software development, I’ve decided to retire. I’ve been fortunate to spend most of my career doing interesting work, surrounded by thoughtful and collaborative peers, and supported by managers who had my back. That combination made all the difference. Before I step away, I wanted to share a few principles I have learned over the years. Philosophy of Development * Less code means fewer bugs * Functional often beats object-oriented * Invest time learning your tools' capabilities and shortcuts * Make searchable project and daily notes for yourself * Read Code Complete or other solid coding guides * Handle runtime errors thoughtfully * Troubleshooting * Simplify the problem * Build a logical chain of hard evidence * Modify broken and working code or environments toward each other until something gives Managing Upwards * Ask "Why are we doing *this*?" * Ask "Why are *we* doing this?" * Share your personal and team successes; don’t assume others will notice * Follow the spirit, not just the letter: "Don't let the process become the thing" (Bezos) * Watch out for people behaving according to how they are measured (Campbell’s Law) * Ask so-called "dumb" questions in meetings Thanks to everyone I’ve worked with along the way. In the end, the journey matters more than the destination, enjoy the ride! If any of this resonates with you, or if you have your own principles you’ve lived by, I’d love to hear them. Feel free to share your thoughts.

2,657

138 Comments

I think I’m starting to see convergence on common workflows. Hopefully this gets us to a point where it’s the process and pattern that matters, not the specific tools. The more things change, the more they stay the same?

5

1 Comment

https://lnkd.in/gDG_yQga I mentioned to several ex-coworkers a year ago that really good QA folks are going to be great at Specification Driven Development (SDD) as they can be the layer between the daydreamers and the end product. But, if you are a good developer and a great daydreamer, you can daydream reality if you implement SDD methodology.

2

Most scaling issues aren't technical, they're contractual. I've seen systems with solid codebases fail because ownership, versioning, and deprecation rules weren't explicit. Changes get shipped too quickly and then nobody knows who is allowed to change what. The fix isn't a new framework, the fix isn't code at all. It's the boring things: - Clear ownership - Versioned contracts - Agreed change windows Scalability fails socially before it fails technically. Longer Version Here: https://lnkd.in/geEak2Np https://lnkd.in/gpbi_s3J

5

2 Comments