Discussion about this post

User's avatar
Shweta Shah's avatar

I have faced this situation in my previous company. I don’t get it. Developers who shipped code quickly by ignoring standards, overlooking requirements, and writing bloated code were rewarded because it showed they delivered results. However, they were breaking the system with incomplete features and inefficient code, which led to an increase in technical debt.

Is this a good practice? I’m concerned because I believe in writing perfect code.👀🫥

Expand full comment
Stuart's avatar

Some great points made here and I'm inspired to think differently about my role, recognising myself as a "change agent".

However I would say that this is not mutually exclusive with well written code and that the main point of well written/tested code is in future maintenance.

I've all too often been the victim of highly praised developers who were able to implement a lot of incredible changes and features to the software. But they moved on, leaving me to deal with an absolute mess of software often so flawed that it needed completely re-architecting, let alone re-writing. These flaws became very obvious to all once these people had left. The pain and hassle that they left behind by their technical decisions after their references had been written became apparent when changes were later needed, bugs started appearing, and scalability became more relevant.

So while I agree that we shouldn't dwell too much on perfect code, we should always be considerate of future requirements and those code maintainers who follow in our footsteps.

Expand full comment
4 more comments...

No posts