Software Development

Home /
Categories /
Software Development

Programming with LLMs for programmers - Beyond the Hype

Programming with LLMs for programmers - Beyond the Hype

Introduction

The field of software development is currently abuzz with discussions about Large Language Models (LLMs), AI agents, and autonomous systems. New libraries and frameworks emerge daily, each promising to revolutionize our coding practices. However, amidst this flurry of buzzwords and complex tools, it’s easy to overlook that many programming tasks involving LLMs can be accomplished with a straightforward approach; it’s not rocket science. While crafting production-ready LLM-based systems is not trivial, using LLMs as part of a system is quite manageable, especially if you avoid over-reliance on the abundance of dedicated frameworks.

The Hacker Way

A few days ago, Paweł Wrzeszcz sent me Erik Meijer’s talk “One Hacker Way” (watch here) from the GOTO Conference in Copenhagen. It is a very provocative talk, which is great. It questions the Scrum method and challenges the status quo in Agile. Given that Scrum is a dominant framework in software development, a critical view is healthy, especially as Agile has become a significant business machine over the past 20 years. When implementing Agile at Scale, core ideas can easily become distorted. (Check out Dave Thomas’ “Agile is Dead” talk here).

Natural Course of Refactoring online on InfoQ

I am so delighted that the article about Natural Course of Refactoring is live. It is a very simple, yet powerful idea about refactoring (but not easy after all) and I hope this way it will reach more people than ever before. So please retweet it and share it wherever you can.

Building Knowledge in a Team: Main Mistakes and Strategies

Introduction

For IT leaders, the topic of knowledge management is often unexplored territory. There is a silent assumption that it happens on its own. While it’s true to some extent, as software developers, we constantly need to learn new things to stay relevant. However, it’s not enough if only some team members learn independently. For a team to work efficiently, they need consistent and up-to-date knowledge. Cutting-edge technology skills alone have limited value.

Simple, Complicated, Complex and Chaotic Systems, in Other Words Cynefin. And How Does It Relate to Software Development?

Intro

You might have already come across terms such as complex systems, complicated systems, or complex adaptive systems; especially, if you have read Management 3.0 by Jurgen Appelo or heard about Ken Schwaber’s ideas about the applicability of Scrum. It might sound intriguing, but finding logic in it is difficult without some background theory. This is the point at which Dave Snowden’s Cynefin concept comes in handy. This concept is based on complex systems theory, anthropology, evolutionary psychology, and, last but not least, cognitive psychology.

Simple, Complicated, Complex, and Chaotic Systems: The Cynefin Framework

Perhaps you’ve previously encountered concepts such as complex systems, complicated systems, or complex adaptive systems, for instance when reading Jurgen Appelo’s Management 3.0, or when considering Ken Schwaber’s thoughts on the applicability of Scrum. This might sound intriguing, but it can be difficult to find logical sense in it if one lacks a certain theoretical foundation. This is where it’s worthwhile to examine Dave Snowden’s concept called Cynefin, which is based on complex systems theory, anthropology, evolutionary psychology, and cognitive psychology.

Truth Does Not Exist (Proofs Neither)

Since my response to Sławek’s post has grown quite lengthy, I decided to also publish it here. Please read his post first, as my commentary only makes sense in its context.

Master... Master...

The Role of the Scrum Master

In the real world, there are many variations of this role. Sometimes it’s a person from the team, sometimes a manager, sometimes someone from outside the team, sometimes a specialist in being a Scrum Master, and I’ve even seen it as a rotating role within the team. So, who is it really? What’s the purpose?

Estimation Is Not a Commitment

Estimation Is Not a Commitment

You’ve probably heard that estimation is not a commitment. Sometimes in teams using estimation techniques, some form of accountability for the accuracy of estimation emerges. This is unfavorable for several reasons:
a) firstly, estimation is an approximation (with some probability), not a definitive result;
b) secondly, when accountability kicks in, project games emerge;
c) there are at least several factors causing estimation to differ from the actual time spent on a given task:

Don't Be Too Quick, Start Thinking!

Don’t Be Too Quick, Start Thinking!

Sometimes I feel like the world has become too fast. Everything happens so quickly that we switch to autopilot and stop thinking about why and for what purpose we are doing a task. Are we doing it in the way we imagined, or the way someone else suggested?

The Big Lie About Clean Code and Unit Testing

Introduction

Many people are convinced that waking up early, say at 5:00 AM, is an unrealistic fantasy for them. They believe that their nature and their body are constructed in such a way that it’s impossible. I used to belong to this group of people.

So How’s It with Architecture - Up-Front Design or Evolutionary Architecture?

So How’s It with Architecture - Up-Front Design or Evolutionary Architecture?

Where does architecture currently stand? We can say that there are two classic approaches:

The Property of Complex Systems

The Property of Complex Systems

This morning, while driving to work, I encountered a much longer traffic jam than usual. “Well, with such cold weather, everyone is probably driving more cautiously,” I thought, as I slowly crawled along the Łazienkowska Route. After several minutes, I noticed from a distance that there was an accident on the opposite lane, with police and paramedics doing their work. On my side, nothing particular was happening. But still… Drivers were simply slowing down to see what was happening on the other side. No one was stopping, they were just looking. And as a result, the stretch that usually took me 5 minutes this time took 20 minutes. After passing this point, the traffic sped up significantly and flowed normally.

A Few Words About Naming – Methods (In Progress)

Note: This article is a work in progress!

Maybe the topic seems trivial and worn-out, as everyone knows that you need to create clear, unambiguous names. However, it’s still a greatly neglected area. Teams are still far from understanding that the most depends on naming. No refactoring has as much power as changing a name. It is primarily the names, if used correctly, that form what is called self-documenting code, creating a clear language in the source code of the system you are building.

Case of Scope Creep - A Simple Introduction to BDD Part 4

Introduction

In the dessert of JBehave, Behaviour-Driven Development, and the calculator (yay), we present the last part of our series.

Implementation - A Simple Introduction to BDD Part 3

Introduction

Continuing our journey with JBehave and Behavior-Driven Development (BDD), today we will move on to implementation. We’ll also explore some of the interesting features of this tool.

The First Story - A Simple Introduction to BDD Part 2

Starting the Brain

We are ready to dive into Behavior Driven Development (BDD). Let’s kick off with JBehave and get things rolling.

A Simple Introduction to BDD Part 1

A Simple Introduction to BDD Part 1

Today marks the premiere of my screencast, which is essentially my initial foray into video blogging and sharing insights in this format.

The Natural Order of Refactoring Under the Microscope Part 5: Evolution of Architecture

Architectural Evolution

An essential next step, at a much higher level of abstraction, requires a deep understanding of the system. Based on emerging patterns and developing domain objects, over time we realize the need to modify the architecture. Architectural patterns or the introduction of other architectural mechanisms can assist us. Such transformations may include:

The Natural Order of Refactoring Examined Part 4: Refactoring to Patterns

The Natural Order of Refactoring Examined Part 4: Refactoring to Patterns

By following the steps outlined previously, we begin to see a more structured solution, predominantly consisting of methods grouped into classes. It’s now time to apply object-oriented principles, such as those encapsulated by the SOLID principles. We analyze the code for patterns of repetition, the need for flexibility, and code smells, and introduce design patterns where appropriate.

The Natural Order of Refactoring Under the Microscope Part 3: Extract Method

Analyzing Class and Method Responsibilities

In the next step, we examine the responsibilities of individual classes and methods, checking if they align with the intended responsibility of the class. It is best to analyze all methods and group them based on performing similar operations. We look for a place for these in other classes or a new class. Remember: if there is a significant private method in a class (longer than 3-4 lines), it should be moved to another class.

Natural Order of Refactoring Explored Part 2: Compose Method

Compose Method

Analyzing methods, such as the one presented in Part 1, often leads us to understand the main points of the algorithm contained in them. This insight paves the way for the next step: try to split a large method into smaller steps by extracting them into separate methods (refactoring using the Extract Method). Thus, the original method will consist of a sequence of calls to these new methods. With the right naming conventions, you can achieve code that reads like a book.

The Natural Order of Refactoring Under the Microscope Part 1

Refactoring is an age-old problem—perhaps not the best word given the relatively short existence of software engineering as a discipline. Everyone knows refactoring should be done, but nobody seems to have the time for it.

Clean Code

The Importance of Clean Code

There are ongoing philosophical discussions on whether clean code matters and if it is worth investing time to read it. I won’t engage directly in this debate. Instead, a small example should suffice:

A Manifesto Against Developers

A Manifesto Against Developers

I hate you because:

You focus on the features of your IDE instead of the features your client/user needs.
You consider typing at the keyboard as thinking.
You waste countless hours manually testing your code.
You spend more time struggling with frameworks than delivering value to end users.
You code for hours without asking yourself, “What am I really doing?”
You naively believe that technologies and tools will solve your problems.
You naively believe that a good algorithm is more important than a good understanding of requirements.
You naively believe that your intuition is enough for writing good code.
You naively believe that you can manage the complexity of the system piece you’re working on.
You agree to unrealistic deadlines.
You write poor code and rationalize it with various excuses (because there is no time).
In your head, you create code snippets without really knowing what needs to be done.
You guess what needs to be done rather than clarifying.
You mindlessly follow the technology you use.
You don’t understand the tools and technologies you use.
You isolate yourself in your piece of code, breaking contact with the world.
You think it’s all the fault of managers or clients and believe you can’t do anything about it.

… even though I love you because I am a programmer myself.

The Natural Order of Refactoring - A Conceptual Sketch

The Natural Order of Refactoring

In software development, refactoring is a disciplined technique for restructuring an existing body of code, altering its internal structure without changing its external behavior. This process, often visualized in a conceptual sketch, can help developers understand the natural flow and order in which refactoring should occur.

How to Transform Your Programming Approach Using Refactoring

Announcing My First Book

I am pleased to announce that BNS IT has published its first book, authored by me. It’s titled “How to Completely Transform Your Programming Approach Using Refactoring.”

Strategies of Excellence: The Simplest Possible Environment

Download the full PDF version of the article here.

Implementation Patterns Part 1

Download the full PDF version of the article here.

Code Cleanup: Not Just About Refactoring

Introduction

Blogspot unfortunately disappoints me when it comes to publishing source code, which is especially important for topics concerning coding style. Perhaps some of you have experience or ideas on this matter. I use the tool http://formatmysourcecode.blogspot.com/2006/02/paste-your-text-here.html, but still, Blogspot occasionally distorts the post.

Code Cleanup: Not Just About Refactoring Part 3

Introduction

Due to formatting issues on the blogspot, it is advisable to read this article as a PDF file. You can download the PDF version of the article here.

Cleaning Up Code: Not Just About Refactoring Part 2

Due to formatting problems with code on Blogspot, it is recommended to read this article in PDF format. You can download the PDF version of the article here.

Code Cleanliness: More Than Just Refactoring Part 1

Initially, my intention was to create an article about refactoring. However, the more I pondered the subject, the clearer it became that I would not be writing solely about refactoring. It’s about something much more significant—conveying a vast amount of knowledge, essentially experience, related to code creation. Code that not only works or is well-designed but is most importantly easy to read. When we achieve this skill, we stand on the threshold of professionalism. Programming professionalism.