Table of content
Disclaimer
Recently I’ve watched a video JetBrains AI Launch Event that actually triggered me to write this article. Before I go on, I just want to state that I’m well aware that this video actually reminded me of some previous experiences and I want to point out that my intention here is not to criticise JetBrains. I’ve actually been using JetBrains tools for a long time and I will continue to use them. In general, I like the AI tools that are being developed today and I love how I can benefit from them in writing, coding and generating images for blog posts.
Intro
The video JetBrains AI Launch Event explains how the JetBrains team integrated AI into their IDE to improve user experience and help developers with everyday work. And I encourage everyone to watch the whole video. The thing in the video that didn’t resonate with me was the marketing pitch. I’m talking about promoting AI tools to solve the issue of writing sloppy code which is hard to read and/or understand. I don’t think that this was their intention, but this is something that I’m afraid of and something that I went through with different technologies and practices.
In the video, there is a talk about how AI can help us understand the code that someone wrote poorly. This is a great feature when facing such poorly written code. I fear that new generations of developers will not see clearly the problem of poorly written code because they will have a tool that will partially solve this problem, making it easier to understand and not forcing us to improve it. I fear that in similar scenarios, AI will become a crutch instead of a solution.
JetBrains AI Launch Event - 14:54
JetBrains AI Launch Event - YouTube
JetBrains AI Assistant is now publicly available! To find out more about AI Assistant, including our current plans, visit https://jetbrains.com/aiIn this spe...
youtube.com
“… this part is really interesting for me, someone else wrote the code, maybe I wrote the code a long time ago and you walk up to like what is this code doing, you just spent a lot of time looking through the entire code base because, Jody this includes the context, right …”
I understand that marketing aims to make products and services desirable, presenting them as solutions that can address various needs. I believe we should constantly remind ourselves of things that can enhance our collective growth. It's my belief that we should strive to learn from the mistakes of others rather than repeating them. Here are some mistakes that I have experienced in my career.
Sloppy code
Whenever I write sloppy code, it always comes back to haunt me. I find myself struggling to read or comprehend it after some time. To assess the quality of my code, I adopt the strategy of temporarily switching off my analytical mind and swiftly reviewing the newly written code to understand its flow.
At times, the code I produce is difficult to extend or test. Heavy refactoring seems to be the only remedy in such cases, but a more effective solution to this problem lies in proactive planning. This involves creating diagrams (I’m using PlantUML) because we all know that "months of programming can save us hours of planning."
In the context of project development, it's widely acknowledged that comprehensive test coverage is essential. With unit tests, integration tests, and end-to-end tests at our disposal, ensuring the robustness of a project is a common practice. However, I encountered challenges such as issues, bugs, and a low-performing development team while working on a project with many integrated tests. This realisation became apparent to me after watching J.B. Rainsberger's presentation titled "Integrated Tests Are A Scam".
When I’m thinking about sloppy code, a paragraph written by Robert C. Martin (“Uncle Bob”) in the book Clean Agile: Back to Basics comes to mind:
Chapter 1: Introduction to Agile
Agile Overview
Decreasing Quality
Everyone knows that you can go much faster by producing crap. So, stop writing all those tests, stop doing all those code reviews, stop all that refactoring nonsense, and just code you devils, just code. Code 80 hours per week if necessary, but just code!
I’m sure you know that I’m going to tell you this is futile. Producing crap does not make you go faster, it makes you go slower. This is the lesson you learn after you’ve been a programmer for 20 or 30 years. There is no such thing as quick and dirty. Anything dirty is slow.
The only way to go fast, is to go well.
So we’re going to take that quality knob and turn it up to 11. If we want to shorten our schedule, the only option is to increase quality.
Conclusion
I hope this article will shed light on the potential problems that may arise when relying on AI tools to solve our problems and the importance of education and developing skills. While AI undoubtedly offers valuable assistance in deciphering complex code, developers must strike a balance, avoiding dependency on these tools at the expense of understanding and addressing the root causes of sloppy code. The key takeaway here is that in the pursuit of efficiency, developers must view AI as a supportive tool rather than a substitute for the craftsmanship required to produce clean, maintainable code.
Top comments (0)