6 Surprising Facts I Learned After 2 Years of Programming
2. Clean code is a dream
I started learning software development at college about seven years ago. I have been developing software professionally for two years. When I look back, there is a gap between now and my past. In two years, I will probably be better than I am now too.
However, there are some facts that I believe will be true as long as I keep doing this job. If you don’t know them yet, you can be sure they will have a serious positive impact on your career. In this article, I will discuss these facts. Let’s start with pair programming.
1. Pair Programming and Mob Programming Help You Improve More Than You Think
I did not know these approaches early in my career. I had only read about them in books and had some reservations.
“How can two programmers write code together? Wouldn’t it be inefficient to write code as a team?”
I had questions like these in the past. However, after I started to apply these approaches, I realized that every software developer should apply them. While doing pair programming, we learn a lot from our partners. Since we develop together as pair, we can spread the business to the team more easily. It is a win-win for everyone.
Of course, as with everything, it is important to apply pair programming correctly. I suggest reading this great article by Martin Fowler about pair programming.
2. Clean Code Is a Dream
The title of this section can be a little misleading. Let me explain. While developing software, we all (hopefully) ensure that the code is reliable, manageable, and clean. But one thing I’ve learned is that there is always something better. You may think that the code you wrote is perfect, but history shows that a new paradigm or a new approach is always coming. Take a look at Java code before Java 8. You will understand what I mean. This doesn’t show that the old code is bad. We just have to admit that clean code is too subjective and we apply best practices to make it as objective as possible.
The key idea we must adopt here is to apply continuous refactoring and keep technical debt to a minimum. I suggest reading Clean Code by Robert C. Martin to get a better perspective about clean code.
3. Do Not Pass on Code Reviews
I think we all agree on this. In code review, we can get feedback from our teammates and see our mistakes. In addition, code reviews can be very useful to learn about topics/approaches we do not know. I also see code reviews as a chance for developers to socialize.
I take care to point out not only the things I see that are wrong but also the aspects that I think are good and inspiring.
When there is no ego in the team and everyone understands each other, code reviews definitely increase the quality of our work.
4. Tests Are As Important as Your Code
Unfortunately, I did not understand the importance of writing tests during my college years. I was more focused on writing code and developing algorithms. After starting my career, I saw that code without tests does not make sense. In order to ensure quality, I learned that every code you write should have unit tests — and even then, it should be supported with automation tests.
When you write your tests and support them with a good CI/CD pipeline, you can deliver better code.
5. Do Not Leave Understanding Business Logic for Another Time
This is a situation I observed in people who are just starting out. I used to do it sometimes too. We focus so much on technologies, frameworks, and languages that we sometimes forget the output of our work. In fact, what kind of technology we use in the background doesn’t matter to our customers. The important thing for them is that the project does its job correctly.
Software developers can sometimes forget the importance of business requirements. I think that knowing the business logic is very important in understanding the project and the customer, and we should definitely not delay it.
6. Think as a Team
One of the most important topics in software development is being able to think as a team. All responsibilities should be equally distributed among the team and every individual in the team should have team awareness. I have been very lucky in this regard as well. I learned that we shouldn’t think individually in the team. And as a team, we must embrace both success and failure. That’s the only key to success.
Thanks for reading. Feel free to leave a comment.
