RockIT

In the world of software development, two terms often arise when discussing the qualities of experienced professionals: engineering and craftsmanship. While we sometimes use these terms interchangeably, they represent distinct skill sets and mindsets.

Emily Bache and Dave Farley published the video What Is A Software Engineer? | Craftsmanship Movement Was A “Step Backwards”. It inspired me to write this post with a different opinion: combining the two approaches leads to superior software development.

In the fast-paced world of software development, maintaining code health while delivering new features is a constant challenge. One strategy that has emerged as a crucial practice is refactoring. However, the traditional approach to refactoring can often clash with the demands of project timelines and stakeholder expectations.

In this post, we’ll explore how sustainable refactoring techniques can help strike a balance between code health and feature delivery.

Software developers face a constant challenge: the communication gap between them and customers. TLDR: customers will never speak the developers’ language. While both parties strive for the same goal—creating valuable, functional software—their perspectives, priorities, and vocabularies often differ. In this post, we’ll dive into the reasons for this difference, explore the implications, and discuss strategies for bridging the gap.

Previously, we talked about potential issues switch-case can cause, and what to do when the type affects only data, or behavior, too.

Now that we are switch-case ninjas, we can go even further and see how to tackle when the type code and the behavior change dynamically at runtime.

Previously in the series, we saw that AI tools have limitations. We also discussed maximizing our productivity by using them to write code - without shooting ourselves in our legs.

In this post, we’ll cover one more piece of the puzzle: how they can (or can’t) help us to refactor.

In the previous post, we saw the limitations of AI developer tools. Yes, they are not perfect. However, they are still able to improve our productivity significantly.

This time, we’ll dive into how we can effectively use them to achieve a better development experience, higher-quality output, and faster delivery.

In the world of software development, understanding software behavior is crucial. It’s not just about writing code; it involves various steps and artifacts. In this post, we’ll dive into the different ways to describe what a software product does, showing how they all connect to depict software behavior.

With the rise of ChatGPT, Bard Gemini, GitHub Copilot, Devin, and other AI tools¹, developers started to fear that AI tooling would replace them. Even though their capabilities are indeed impressive, I don’t fear our jobs will go away in 2024.

We’ve previously dived into the complexities and maintenance challenges of switch-case and saw a refactoring technique for simple scenarios.

Today, we’ll raise the bar a bit and focus on situations when our type code affects behavior. We’ll use pets to demonstrate the concepts.

In the previous part, we had an overview of why switch-case could be hard to maintain. This part will focus on the simplest scenario: when type-code only affects data, not behavior. We’ll do this by modeling a pizzeria.