I guess all of us have, at times, thought about changing the world somehow and most of us have concluded that this is virtually impossible to achieve. However, as a developer, each one of us can change the code - the code written in the company, the code of an open source project, even the code of a closed source project.
Let’s see how we can change the code in all of those cases.
Change the Code Within Your Company
The first case is the easiest one and it does not require much effort. You just need to do your best to write clean code, with good test coverage, etc.; all best practices you know and/or you like. It’s easy when it’s the code you produce. What about your colleagues? You should actively participate in the code reviews cycle, rather than being a passive observer that later complains about the code quality (I have seen it happening way too often). Give your suggestions on how to improve the code base. You will see, it will make you happy. Also, that will help junior developers to code better and learn new stuff. Be proactive! If possible and, even if it is not in your job description, take an active role in all the main decisions about the software quality and architecture in your company. We all know that, usually, the major decisions are not made in meeting rooms but on the terrace, over a cup of coffee, etc. If you are open and talk to your colleagues, then you will know about, and even be able to take part in, of all the major things happening in the company. Also, don't just talk to developers, but with QAs, PMs, product owners, and colleagues from all other departments. Then you will have a broader look at the company’s needs (and you can gain more friends!). Consequently, your proposals for improvement will carry more weight.
Change the Code of an Open Source Project
If you use such a project and you have found a problem, a bug or an issue that could be fixed, you can always contribute to the project. Usually, these projects are hosted on GitHub and you just need to send a pull request. The members of the project team will be happy to review a new pull request. That’s the beauty of the open source paradigm. Open source projects have the strength to evolve rapidly according to the users' needs. The more people that see the code base, the more likely it is for the code to be improved. Last but not least, you will become a contributor and you can add that to your CV!
You just need to spend some time cloning the project, reviewing it, and finding the piece of code that produces the bug, and of course, fixing it. But believe me, it’s always worth the time and effort. Even if the project is not the best one. You will get to know some new code, you might even learn something from it, and you will have to find a solution to the problem - you can take it as a challenge or a quest.
What to Do About a Closed Source Project?
If you find out a bug, usually, you can report it. If the bug is not critical, odds are that it will not be fixed in the next release; and the release cycles in big companies are too long, anyway. To be realistic, you will be lucky if someone fixes the problem in the next six months. But that’s the case with closed source projects. However, if you report the problem you will know you have done what you can. And that can make you sleep better!
And, Finally, What About All the Bad Projects That You Come Across Now and Then?
If you are in dire need of an implementation and the suggested solution is not good enough for you, you can always implement it yourself. Thank God we are developers and we can always implement a solution by ourselves, or at least try. I can share such a story in another article. Until then, try to make the world (or at least the development one) a better place.