I work ed as a developer for over five years. This doesn't make me an expert, but I think I've made enough mistakes to share with you. Here are 10 things a developer should never do.
1) Be a perfectionist
Nothing is perfect, and I'm sure there is no "perfect code " either.
Development is an iterative process. You write code, test, get feedback, refactor , and repeat. What works today may not work tomorrow. Therefore, programs must be flexible and easily changeable (that's why they are called software ).
I'm not saying that you should give up the pursuit of perfection. You just need to be mindful of writing code that is too complex and cohesive.
Being a professional is not the same as being a perfectionist. It's more about being optimally good most of the time .
2) Ask for time to refactor
Code refactoring is the process of restructuring existing code without changing its external behavior. Without refactoring, code begins to smell bad, which means it is difficult for other developers to understand and use.
As developers, we know that refactoring is always worth doing after functional ity has been implemented. The problem is that non-technical team members don't care about such things. They often tell you: “We are a fast-growing company, we need to focus on adding functionality first.” But after a while, the code becomes unsupportable and you start begging for time to refactor.
There is no need to ask for separate time for refactoring. Do it within the framework of implementing functionality.
3) Don’t understand what “legacy code” is
The web development ecosystem is known for its rapid changes. I remember one of my past project s that used Next.js 10. By the time I started working on it, version 11 had come out with new features and improvements. Suddenly, my version 10 project started to look outdated.
Many people incorrectly think that “legacy code” means old code, but this is not true. According to Michael Feathers, author of Working Effectively with Legacy Code, legacy code is code without tests. If you can't test the code, you can't refactor it. If you can't refactor, you can't support it.
The “old” Next.js project had decent test coverage and worked fine. It was "well maintained code" and not "legacy code". Please don't chase new tools just because they're new and shiny. Remember that Github continues to run on Ruby on Rails, which is 17 years old.
4) Consider functional programming to be the best
Yes, functional programming is new, all the cool kids are doing it, but that doesn't mean it should be used everywhere.
For example, when working on a Flutter project, it may not be worth using it at the user interface level. Frequent use of fully functional code at the interface level can cause performance problems due to unnecessary re-renders. Flutter is designed to be used in an object-oriented programming style, and should be used that way.
But this doesn’t mean that you should completely avoid functional programming or any other cool thing. In the same example, you can use functional programming at the business logic level, where it is better suited. Just consider the context you're working in and choose the appropriate tool.
5) Blindly follow “best practices”
Clean architecture, principles of SOLID, DRY, KISS, YAGNI, TDD , BDD, CI/CD, etc.
There are many best practices in software development. They are made with good intentions, but should not be followed blindly.
For example, TDD (Test-Driven Development) is a great practice for making sure your code works as expected. But if you're working with languages that support REPLs, like Clojure or Python, you might not need to use TDD for everything.
The only goal of TDD is to get feedback as quickly as possible. If you can get feedback without writing tests, then TDD is not needed (although you do need to write tests!).
6) Deal with difficulties alone
I've seen many junior developers eager to demonstrate their so-called "problem-solving skills." They often struggle to solve a problem that has already been solved by others. Please don't be like that. Don't reinvent the wheel.
The world's greatest minds are those who stand on the shoulders of giants.
When you start working in a team, you realize that you can learn a lot from your teammates who have more experience than you.
They are your "giants". Jump onto their shoulders and don't waste time jumping to the ground. Now your goal is to aim for higher giants.
7) Fall into an uncontrollable “flow”
Have you ever experienced a state of “flow”? This is a state of mind in which you are completely immersed in a task, feeling energized and focused. As a programmer , getting into a state of “flow” can feel like the code is writing itself and you are just an intermediary.
But be careful—you can end up writing “too much” code. I often find myself over-designing when I'm in the flow . Not only me, but Robert Martin, the author of Clean Code , also experienced counterproductivity while in flow.
To intentionally interrupt flow, I recommend the Pomodoro Method, where you work for 25 minutes and then take a five-minute break. This helps you stay focused and avoid burnout.
8) Don't move your body
Working as a software engineer is not easy. You will spend hours sitting in front of the computer, typing on the keyboard and looking at the screen. It's easy to forget about your health when you're in the flow. But remember, your health is the most important thing. The brain is useless if the body does not work as it should.
Try moving every 30 minutes (or 25 if you use the pomodoro method). Get up, stretch, walk and drink water.
9) Forgetting how cool it is to be a programmer
When I started programming, it turned me on so much. I created stuff, solved problems, and learned new things every day.
But over time, I started to forget how fun programming is. I was too focused on writing “clean code,” following “best practices,” and solving “hard problems.” More often than not, I couldn’t really write my own code because I was working on someone else’s code and the company’s code. Where did my creativity go?
You should always remember how much fun it is to be a programmer. I know it's hard, but try to find time to work on your own projects, learn new things and create something cool. At your workplace, try talking to your teammates about new and interesting technologies, even if you don't use them in your project. This will help you stay motivated and inspired.
10) Be a “coder”, not an engineer
There is a difference between a "coder" and a "software engineer". A coder is someone who writes code, and a programmer is someone who solves problems with code. I have two good reasons why you shouldn't be a coder:
The so-called “coders” will be replaced by AI in the future (in fact, they are already being replaced). I know this is controversial, but unfortunately it's true
People don't care about your code, they care about how well you solve their problems.
Be a “problem solver” who uses code as a tool. Understand the problem, find the best solution and implement it with code. This is what a software engineer does.
Conclusion
These 10 things are based on my personal experience, so I don't expect everyone to agree with me. But I hope you find this helpful. Write in the comments if you have anything to add. Thank you for reading!