Quick Reads (Under 5 Minutes)

A new prompt I’m finding necessary to include in response to a proposed code generation suggestion from the new “reasoning” models, “Are any of these suggested code changes in excess of requirements?

After a day or two of adapting to the difference, I am finding good success with the new claude sonnet 3.7 reasoning model for complex troubleshooting. It does a better job of replicating my priorities in subsequent responses like incremental change validated through tests.

It is less predictable and can do really strange veering turns. Review changes carefully, Commit frequently and be ready to revert in case you miss something like renaming of variables, inserting test code into production code, or other random nonsense. That’s actually an indicator that the work your doing is directed enough that you should move back to the non-reasoning model.

I am pessimistic about the class definition of Human but find hope in many of the instances.

Advice to software developers unsure about generative AI:

First, learn how to use AI to accelerate your own learning. Learning is the most important aspect of your job — and the least valued by those who employ you.

Second, use it to reduce effort you find tedious. Focus your labor on what you can uniquely do and enjoy doing. Rather than worry about what AI means for your career, use it to help craft the work you want.

Then, and only then, incorporate it into solutions for other people. You’ll have acquired the experience and empathy to use AI in ways that help others get their job done.

Pairing with generative AI is like carrying on a conversation with a deeply learned, adept, and patient co-worker who is distract-able , forgetful and believes in faking it till you make it.

If you don’t use a quality discipline like TDD, no problem. Remain open to the possibility you haven’t mastered it.

So, before debating what it is or isn’t with others who have put in that time — or using managerial power to stop people doing it…

Ask questions and listen.🙏🏻

Resolving an open ended coding challenge within the agreed upon time box feels great but it just reinforces the role luck plays in our standard for good work.

Completed writing code to analyze an abstract syntax tree of .NET 4.0 VisualBasic code with a current CSharp application. Learned a lot about assembly management, .NET version compatibility, and the crazy nested tree VB syntax generates compared to CSharp. Some head slappers.

Saying Scrum prevents you from doing XP is like saying a you can’t drink soup out of a mug.

Scrum and XP aren’t analogous. Scrum is a framework for organizing teamwork. XP is a set of principles and supporting practices for crafting quality software.

Scrum doesn’t provide guidance on how to code. It does place an expectation for transparency and continuous improvement which, along with strong engineering practice (like XP), can lead to predictable output, and maybe even success given sufficient insight into something that is actually useful to build.

But this is all moot since “Agile is dead” and growing numbers of people are looking for some other world view to unsuccessfully adopt instead.

Exposing my code to peers who are more talented craftspeople than I am doesn’t take every ounce of perspective and ego resilience I have. Just much of it… At the end of the day though, given the choice between failing on my own or someone else’s terms, I’d rather just not fail.