Early Excitement
When you start your journey as a software developer, you tend to get excited about actually writing code. You enjoy seeing your code actually works. Sometimes you observe it as a piece of art. This can make you tend to write more and more code just for the fun of it. Maybe you are writing code for a demo project, or you are learning a new technology or framework. In such cases it could be healthy to do so. It's nice to have that feeling of excitement. It helps you battle the challenges of learning. I would call these activities an experimenting with the code.
Real World Projects
Unfortunately, this is not going to be the case in real world projects. Here, I mean software that are actually running in production state and have real users using it. Users that actually depends on the software to solve real world problems. Those users actually paid, or still paying subscription fees. Therefore, there is not much room here for learning or experimentation.
Writing code for real projects feels a bit different. Most of the time, you will NOT get the chance to start a project from scratch, unless it's a startup company that haven't yet released its product. You will not get the opportunity to try or work on some part of the project that you enjoy. You will get paid to solve problems.
When you start working on a real project, you should be expecting to write code that adds a specific feature, fix production bugs or refactoring functions for performance reasons. You write your code alongside other people code, otherwise known as maintaining the code. Different developers collaborate and can equality contribute to parts of the project written by different developers. Developers that may no longer employed to the company.
Unit Testing
Yes, you read that heading right, unit testing. Back then, when you were just experimenting with some demo projects, you didn't actually need any testing at all. Writing unit testing in demo or personal projects will just hold you back, slow you down, and eventually will just demotivate you from keeping up with technology trends.
Otherwise, maintaining a production, real world application, puts a lot of pressure on you. You don't want to be that developer who crashed the production server. You don't want to introduce sneaky bugs that silently affects the business logic and introduce incorrect application state in the long run. Believe me, debugging bad application data caused by a silent bug can be a nightmare. It consumes time, resources and most importantly, your peace of mind.
Your best friend here is unit testing. Maintaining a well-tested code should lift a lot of tension and uncertainties while you are writing code. If you broke another part of application, the automated tests would inform you. Writing tests for your code, could also help remove that huge feeling of responsibility towards your code. You will no longer be the one who can only maintain this feature. Now every other developer working on the same feature, can confidently maintain and refactor your code.
Finally
Software in general is used by different kinds of users. The daily life of users could be positively or negatively affected by the quality of the specific software they are using. Ensuring a well maintained, well tested code base will eventually maintain customers at a decent level of satisfaction. Which also affects overall success of the company and the software.
Top comments (0)