Tag Archives: coding

work

My GenAI Toolkit: Lessons from 2024

This past week, OpenAI announced o3; all reports suggest they’ve achieved some form of AGI. I’m struggling to wrap my head around this because AGI always seemed like a distant future concept, not something that’s here now. But let’s set that aside for a moment and examine how AI has shaped my 2024.

My primary use for Generative AI (GenAI) this year has been in communications. Despite considering myself a good communicator, having English as my second language sometimes leaves me fumbling for the right words. Grammarly helps, but GenAI takes it to another level. Here’s how I use it:

I start by crafting my messages as I always have, aiming for clarity and audience appropriateness. Then, I turn to ChatGPT, which is fine-tuned with my custom instructions and memories of prior interactions, to enhance my prose. The result? My words, but amplified – like my brain on steroids. Sometimes, I need to tweak the output, but it’s usually spot-on.

For work, ChatGPT is also my go-to for creating user stories for my agile backlog. With a prompt I’ve perfected and a keyboard shortcut, I can turn a few bullet points into a nearly complete user story in seconds. I might remove some overly ambitious acceptance criteria, but it’s mostly ready to go.

When I need to craft a precise prompt for a unique task, I turn to Claude Sonnet through Perplexity. Sonnet excels at understanding my goals and generating detailed prompts that I can then use with other AI tools. For one-off tasks outside my daily routine, I compare outputs from various AIs, picking the best elements from each after generating the prompt.

Shifting gears to another aspect of my work, coding has not been a major part of my job this year, accounting for less than 10% of my activities. However, I’ve relied on Sonnet for both personal projects and quick Proofs of Concept (PoCs). I also used Sonnet for code review to ensure quality before sending pull requests.

Now, let’s talk about Perplexity. It has become my go-to search engine, especially for troubleshooting. It combines the base-model AI knowledge with real-time search results, providing insights far beyond what Google can offer. As a pro subscriber, I can access multiple models but stick with Sonnet. Perplexity gives me access to the model since I don’t have a Claude subscription.

Lastly, there’s Grok. As a premium subscriber on X, I use Grok-2 for its superior image generation capabilities – four high-quality images at once, and fast. The recent integration of Grok into X’s interface is a game-changer for context understanding on social media. Plus, Grok’s ability to pull from X’s vast data pool makes it an excellent tool for quick updates on trending topics. And, for those times when I need an unfiltered, straightforward answer, Grok delivers without the annoying woke agenda that sometimes colours other AI outputs.

At the end of the year, the cost of all these AI tools isn’t trivial, but the productivity and work quality boost justifies it. If I had to choose just one for budget reasons, I’d pick Grok. It’s cost-effective, and given its rapid development pace, I believe it will soon close the gap with other models.

To drive home my point about Grok’s versatility, I’ve used it to refine this very post you’re reading now. Grok’s assistance in restructuring, enhancing readability, and generating this closing paragraph demonstrates its capability as a comprehensive tool for content creation and editing. It took more manual updates than ChatGPT usually does, but it’s still good. I hope this insight helps if you’re still figuring out how best to leverage GenAI in the coming year.

work

Letting Go of the Chainsaw: Lessons from Firefighters for Software Engineers

I am reading this excellent book called Range, and I just went through an interesting chapter where the author reports some studies that were looking at why some firefighters die trying to outrun a fire while carrying heavy chainsaws, axes and other equipment. Should they have dropped those, they would have survived.

Emotional Attachment to Tools

One possible explanation is that their tools are so intrinsically linked to their identity as firefighters that they become almost like an extra limb on a subconscious level. People don’t realize those tools are not part of their being and can be dropped.

The book mentions one firefighter who noticed what was happening and knew he had to throw away his saw but felt compelled to carefully put it down – while trying to escape a ravaging fire. Still, he pushed the feeling aside, dropped his saw and survived.

The Sunk Cost Fallacy

When reflecting on this, the sunk cost fallacy also came to mind, which is “the phenomenon whereby a person is reluctant to abandon a strategy or course of action because they have invested heavily in it, even when it is clear that abandonment would be more beneficial.”

Letting Go of Past Investments

We can draw some valuable lessons from those examples in software engineering and operations. For instance, many people may feel emotionally attached to the tools, frameworks, and programming languages they have used throughout their careers. This attachment can be so strong that they become resistant to change, even when it’s evident that adopting new and more efficient technologies would yield better results.

Engineers may also hesitate to switch to a new technology or platform, fearing that the time and effort spent learning and working with their current tools would go to waste. However, it’s essential to recognize that technology is constantly evolving, and what was once cutting-edge may now be outdated. In these cases, it’s crucial to let go of past investments and focus on adopting new solutions to deliver better outcomes.

To succeed and keep improving, we need to be adaptable. Just as the firefighter who survived realized he had to drop his chainsaw, software engineers should be open to discarding tools or practices that may be hindering their progress or efficiency. It might be challenging to let go of something integral to your work, but doing so can open up new opportunities for growth and success.

Fostering Improvement

In team management and collaboration, fostering a culture that values continuous learning and improvement is essential. Encourage team members to explore new tools, frameworks, and methodologies to help the team become more efficient and deliver higher-quality software. By creating an environment where individuals feel supported in their pursuit of growth, you’ll be better equipped to handle the ever-changing landscape of software development.

Lastly, communication is vital when applying these lessons to your teams. Make it a point to regularly discuss new technologies, trends, and best practices with your team. 

Conclusion

Encourage open conversations about the tools and processes currently in place, and be willing to make adjustments if they no longer serve the team’s best interests. By fostering a culture of transparency and adaptability, you can help your team thrive in an ever-changing industry and drive continued success.

devops

Shift Left

Note: This article was originally written for my blog in Portuguese back in 2021.

Shift Left is a practice in software development where the aim is to find defects as early in the process as possible. A study from NIST shows that the cost of finding and fixing defects increases exponentially the farther it is found in the development cycle. Therefore, the ideal scenario is to find defects as early as possible, ideally in the design phase.

As a DevOps professional, a large part of my work has been focused on code quality in our business unit, which primarily develops code for embedded systems, FPGAs, industrial automation, and industrial robot controllers. Given the nature of our products, the cost of developing high-quality code is immense, and each release cycle is exceptionally long.

To solve these problems, our team has been working to implement a Shift Left approach by following these steps:

Writing Unit Tests Concurrently with Code

Writing unit tests concurrently with the code is the most critical part of Shift Left. Developers should not wait for the next phase, testing, to see if there are any obvious bugs in the code. Instead, most testing should be done in the implementation phase through unit tests that must be run constantly. This also helps ease the test team’s workload and lets them focus on more important things than testing the basics.

Code Review

The next step is code review. Developers should create a branch, write the code (including tests), and send it for review instead of merging it directly into the trunk. Code review allows for the early detection of bugs and can prevent these issues from propagating to later stages of development, saving time and resources. Code review allows developers to learn from one another and share best practices, resulting in better code quality and more effective teamwork, again addressing them on the left. See Google’s best practices for code review.

Pre-Commit

Human beings don’t like to have their work criticized, so pre-commit hooks can reduce criticism’s human element. Using pre-commit, a bunch of tests can be pre-programmed to run in the code about to be committed. Linters, tools that check for leaking secrets, styling tools, and others can be used. Pre-commit does not allow code to be pushed if it does not pass QA on the developer’s machine. It ensures that the basics are covered before the code goes into review.

Text Editor and Plugins

The text editor/IDE that the developer uses is as far left as possible. Developers can use various plugins and tools to improve the code. For instance, Microsoft Visual Studio Code is an excellent editor with many useful plugins, including language servers, linters, and AI-based plugins like Co-pilot, Sourcery and TabNine. Sonarlint, a Sonarqube plugin, can analyze code and display issues as soon as the user saves it.

By following the steps outlined above, software development teams can significantly reduce the number of defects that make it to the testing phase. While no single solution guarantees perfect code, combining the tools and techniques discussed and a strong focus on code quality can help minimize the total project delivery cost and time. For further information on how these steps can help reduce defects and improve the overall quality of code, I strongly recommend reading Steve McConnell’s book Code Complete. Take action today to improve your software development process and achieve better outcomes for your team and business.