Story of a Lazy Developer
Have you ever met a software developer with messy hair? Or have you ever met some that never take a bath? Or are you one of them? Congratulations! You’ve met the requirement to be a good developer. Remember when Bill Gates said that he only chooses a lazy person to do a hard job. Because a lazy person will find an easy way to do it. Lazy people tend to do something efficiently because they don’t have time to do unimportant things.
The perks of being a lazy developer
Being lazy doesn’t mean doing things poorly. It’s the opposite. A lazy developer would not create a hard-to-maintain code, undocumented code, or spaghetti code. Because they know that sometime in the future they will go back again to that code. If they created the code in the best way possible. They will not waste their ‘precious’ time to re-study their code in the future.
Lazy developers know how precious every code that they make is. Hence, they created the code as simple and elegant as possible. They will not reinvent the wheel but also avoids using unnecessary frameworks and libraries.
Lazy developers only focus on important things. Because they value their time, they work only on necessary things. Sometimes doing nothing is better to focus your mind more. Because the hardest part of being a software developer is thinking.
Automate Repetitive Task
Lazy developers hate doing repetitive tasks. They easily get bored and want to end things quickly. One way to achieve this is using automation. There is some saying “you could have done the task in 6 minutes but instead, you automated it for 6 hours”. I think that’s only partially true. Because that 6 hours you make for automation will save you repetitive 6 minutes. Which if we sum that repetition, it could be more than 6 hours. And if you’re lazy you know which one’s better.
Examples of Lazy Programmers
Take an example in ZebraX especially on the front-end side. We implement Prettier together with Eslint to automate the formatting process for our code. We don’t have to think about the spacing, the indentation, the forgotten variables that we don’t use, the forgot-to-remove ‘console.log’ and so much more when we finished coding. Prettier and Eslint will do the job for us. Imagine if we do this manually. There will be so much time wasted that could be used for more important things.
We also have our own CI/CD pipeline with Jenkins, so we don’t need to spend time deploying our code manually to our development, UAT, or production server. Every time we merge Pull Request on our Git repository, the code will be built and deployed automatically on our environment. In that way, we only need to focus on our code, no need to go into our server and deploy it manually every time we have changes in our code.
Not only that, but we also use SonarQube integrated with Jenkins in our GitHub projects. Every time we make a Pull Request, SonarQube will automatically review our code. SonarQube will detect duplicated code, coding standards, unit tests, code coverage, code complexity, comments, bugs, and security vulnerabilities. This also comes in handy because sometimes reviewing code can be a little bit frustrating and it’s very possible to miss it if it’s done manually.
