A good programmer is lazy/efficient

Where’s the line between being efficient, being lazy, and taking shortcuts which are inadvisable?

A programmer looks for ways to make their own life easier. In the best case this means we write code to automate manual tasks and save ourselves time; we look for standard libraries instead of reinventing the wheel with each project; we bring up problems early because we see what a pain in the ass it will be if nobody thinks of that until too late.

In the worst case we copy-paste code without thinking about whether it makes sense; we use libraries but don’t check their quality and never update them; we skip detailed testing in favor of a superficial ‘looks fine to me’.

If we go too far in the “right” direction we end up spending inordinate amounts of time optimizing code that already works, whether this is for a minimal performance boost or just because the code doesn’t conform to the programmer’s sense of clean or pretty code.

If we go too far in the “wrong” direction we put code online which is buggy, or we make QA’s life miserable because they have to keep rejecting code based on bugs which should have been caught by the most cursory of tests.

A mature software development team will have safeguards in place: code reviews, a testing culture, automated tests, actual QA positions instead of just project managers or stakeholders who do the testing. This guards against going too far in the wrong direction. Being too lazy is a hindrance to the career, as well; no one wants to work with someone who doesn’t pull their weight.

Aside: It's odd to realize that programmers who have started in their career in the last five to ten years may have even "grown up" with unit tests and automated testing, making it second nature to them in a way it still isn't to me. In my career, I have had a one-day workshop on unit testing sometime around 2013, and until my current position, never worked for a company which supported their use.

How do we make sure we’re not over-optimizing? Of course it makes sense, for example, to plan your design for a new project before you start, but where do you draw the line? How many people should be involved? When is it worth it to spend an hour figuring out the most optimal design for a database table with four people?

A lot of factors play into this and the nature of the project should determine the answers. How reliable does the end product need to be? Does it need to be highly scalable and performant? How difficult will it be to change later? A small website project will have very different answers than code for a piece of equipment where software updates are difficult to apply once it’s released.

That’s the key to figuring out a healthy balance: take the time to weigh the risks and benefits of what you’re doing as a matter of habit and challenge others to do the same.