DEV Community: Andrey Platov

Source Code is Poison

Andrey Platov — Wed, 10 Apr 2024 08:29:22 +0000

Many people believe that source code is an asset. It is not. I'm not the first to suggest this idea; there are numerous articles on the internet asserting that source code is not an asset -- it's a liability. However, I want to take this a step further and say that source code is not just a liability -- it's poison.

It's funny how many people and teams, deep down, understand this at a very intuitive level but never raise the issue or even discuss it. And yet, the shared (incorrect) notion of source code as an asset prevails. This is a significant problem.

Let's start with the definition of an asset. According to Investopedia, an asset is a resource with economic value that an individual, corporation, or country owns or controls with the expectation that it will provide future benefits.

Source code is indeed a resource. So, what's the economic value of source code? It lies in the value of the software that can be developed from it. However, the software is not the source code. The software is the product that can be used to solve problems or provide value. The source code is merely a means to create the software.

Another common misunderstanding is that to build more features, faster, or better (whatever that means) software, you need more source code. This is a deeply flawed notion that is prevalent among engineers, managers, and business owners: more code equals more features. This is completely wrong.

More code simply means more code and nothing else. Let me illustrate this point with a very simplistic example. I could write three lines of code adding three "features", and then I could write one line adding many more features, including those three:

const feature1_add5(x: number) => x + 5;
const feature2_add10(x: number) => x + 10;
const feature3_add25(x: number) => x + 25;

Or we could do it like this:

const better_add(x: number, y: number) => x + y;

You might think this is a silly example, and of course, everyone would choose the latter, but you're wrong. Almost every large codebase uses the first approach. I have never seen a codebase where 50%-90% of the source code could not be discarded, destroyed, and replaced with a small fraction of lines. This includes prominent open-source projects, Fortune 500 companies, and various startups, and it happens for many different reasons.

Why is more source code bad? Because source code is what ultimately kills you, kills projects, products, and companies. Complexity only increases, and you need to continue developing it, you need to maintain it, and you need more and more people to do that. More people means more communication, more coordination, more bugs, more problems. And more problems mean more time to solve them, more money to pay for that time, more stress, more frustration, more burnout.

Eventually, any codebase dies because of its source code. Some companies start calling it "legacy code" and attempt to rewrite it from scratch. This is a quite common scenario. Some companies do this every 3-5 years. And they never learn. They never learn that source code is not an asset -- it's poison. It's a poison that may kill a company, project, product. And then, after tossing out the "legacy" codebase, they start producing new poison very enthusiastically. It's ironic that the faster they produce it, the faster they meet their demise.

Of course, there are exceptions. There are very few people who understand this. Take the Linux Kernel as an example. This is a great example. But there is Linus Torvalds, who understands that source code is poison and works with it as everyone should. The only way to work with source code is the same way people work with dangerous chemicals.

You need to be very careful, very responsible, and very professional. Try to contribute to the Linux Kernel, and you will see how challenging it is. Attempt to contribute something, and you will quickly realize how sternly you will be rejected if you're not careful enough.

OK, that's the Linux Kernel, but I'm pretty sure your manager's name is not Linus. Your manager is the opposite. I believe they want you to contribute more code, any code, and perhaps will even reward you with achievements and bonuses for the number of lines you contribute. That's common, but also very ironic. People giving kudos to each other for making things worse, which ultimately leads to downfall. And they seem to want this to happen as quickly as possible.

And a few more words about poison. In small amounts, poison can serve as a great cure. Ancient medicine widely used poison to heal people. Poison is good in small amounts. But in large amounts, it kills. Source code is exactly the same. We can't ship products without source code. And in small amounts, source code is awesome. But large amounts of code are lethal.

OK, let's summarize:

More code does not mean more features. In fact, it's the opposite; if you always aim to minimize the size of your codebase, you can end up with many more features implemented in a much smaller codebase.
Source code is not an asset. It's a liability. It's poison. It's a dangerous chemical. It's a weapon of company destruction. You should avoid producing it as much as possible. If you can eliminate some code from your codebase right now, just do it.
You should not be thankful to anyone who adds more code to your codebase, but you should be very thankful to anyone who removes code from your codebase. This is the only way to survive.

Zed and AI will save us millions... and you might soon lose your job

Andrey Platov — Tue, 09 Apr 2024 20:57:57 +0000

The software engineering world has changed a lot, but it seems like both workers and companies haven't fully caught up yet. Recently, I've been having a lot of fun using Zed. It made programming enjoyable for me again, just like it was many years ago. Some people think Zed is just another unfinished editor, but that's not right. Zed is an AI tool. If you're not using Zed with GitHub Copilot and OpenAI GPT, you're not using it correctly, and you likely don't need Zed at all.

Working with AI now feels like coding alongside a really cool, productive, and smart partner who's always there. For example, I recently wanted to add Huffman coding to my toy project. The last time I worked with Huffman encoding was about 30 years ago, so without AI, I would've needed to spend some time looking things up on Wikipedia and other places. With Zed and GPT, I added Huffman encoding to my project literally in 5 minutes. You can see the result here on GitHub.

What does this mean? It changes everything. Imagine I'm a manager at a tech company, and I decide to add Huffman encoding to see the effects of compression in my library. Normally, it would take several meetings just to decide if we really need it and if we have the resources for it. Then, someone might be assigned to look into it, which also involves planning resources. This person would likely spend days evaluating different libraries. A week later, I might expect something to be done, maybe not. With AI, I had it working in my project literally in just 5 minutes. This is a huge deal.

But the impact is even bigger. AI is now better than 95% of software engineers in the world at many tasks. Take the Huffman example and try to compete with ChatGPT on implementing algorithms like that. This would be hard for many engineers and take much longer. If you disagree, just ask next candidate to write Huffman coding on coding interview and enjoy her suffering. Sure, GPT's output may require some tweaks, but overall, I'm achieving results 10 to 100 times faster than when working with humans, and often with superior quality.

Current hiring processes are outdated. If you're still making engineers do tasks like reversing linked lists or solve other Leetcode problems in interviews, you're missing the point. GPT-4 can do these tasks better. If you're asking about "system design" in interviews, you're even more behind. GPT-4 will probably give better answers than almost any engineer you could hire. This is a huge shift in the industry, and many people will start realizing this soon.

I do not want to say you should rely on ChatGPT's opinion on design of your system. Moreover you should not, and this is why real engineers are still needed and will be in more demand than before. But the point is that the hiring process is outdated and needs to be changed. You should not ask engineers to solve Leetcode problems or reverse linked lists in interviews. Why would you hire a mediocre coder when GPT-4 can do it in seconds for $50 a month?

I'm really happy with these changes. It's a big boost for the industry, but it's also going to change things a lot. Likely, 95% of software engineers (as most people think of the job) will be out of work soon. They're just not needed anymore, and they're falling short in the tasks they're currently doing. Industry should rethink software engineer role and focus them on what's really important. It's not about writing code anymore.

Think about how AI is changing software engineering like the tractor changed farming. Sure, we still have farmers, but they don't need to do the hard work in the fields themselves anymore. Their job has changed to managing the farm, making important decisions, and planning for what's coming. They don't need to rely on physical strength -- they need to be smart and know how to use the machines.

This is pretty much what's happening with software engineers now. They don't have to spend all day writing code. Their role is shifting towards project management, deciding what needs to be done, and preparing for the future. If your engineers are still spending days on something AI can do in a few minutes, it's like being that farmer who still uses a horse to plow the field. The world has moved on, and so should the role of the software engineer.

If you want to be productive, not only with coding tasks but also with everything related to teamwork, including collaboration and project management, you should try Huly. Huly aims to be the Zed of project management and team collaboration.

We're not quite there yet, and Huly's current process management capabilities are somewhat similar to what Linear, Asana, Jira, and others offer. However, we're passionately working on it. Stay tuned, and you'll see how Huly will positively change the lives of many teams.