Follow us on Twitter at http://twitter.com/blogCACM
The Communications Web site, http://cacm.acm.org,
features more than a dozen bloggers in the BLOG@CACM
community. In each issue of Communications, we’ll publish
selected posts or excerpts.
Clients want to keep costs low, and
if they can, they will pass costs onto outside companies. That’s why we decided
to “get lazy” and only do what we are
paid to do. We won’t go out of our way
to improve a project, refactor, or fix code
unless we are getting paid for it.
And when we find ourselves with a
task in front of us and we don’t understand how to solve it, we usually don’t
blame ourselves. This is especially true
if the problem has something to do
with legacy code. See, here’s the thing:
we weren’t paid to understand the legacy code. We were paid to add a feature,
solve a bug, or whatever.
Suddenly becoming experts in a
project’s legacy code would be outside
the scope of our work, and since we’re
lazy, we’re not going to venture outside
of our assignment unless we’re paid to
do so. A project shouldn’t expect you to
be intelligent or tech-savvy, as far as the
legacy code is concerned. Instead, you
need to focus on closing tickets.
It’s not your fault if the code is a
complete mess, or the bug is serious,
or you can’t estimate how much time it
will take to understand the legacy code,
let alone how to fix the bug. So whose
fault is it? The first guilty party is the
code itself. And the clients overseeing
the code are also at fault.
Once you accept that, you can put
together a basic report by creating
new tickets. This report could be
lazy-simple:
˲ There is no documentation for
Class Y, can’t figure out how it works.
˲ Library Z is in use but why aren’t
you using library B?
˲ This algorithm is a complex mess,
can you explain what it does?
˲ The class naming rules are incoherent, can you provide documentation?
Suddenly, your initial “report” is instead a list of questions. You can’t provide
the answers because you don’t honestly
know them and you are too lazy to figure
it out. Answering these questions falls
outside of the scope of work you were
hired for, so it is reasonable to expect
the client to provide documentation.
Now, you might have noticed a com-
mon thread in the questions here. I
didn’t ask for help. I didn’t ask some-
one to create something for me. Pro-
grammers will often reach out for help,
saying something like “which library
should I use for this task?”
Here’s the thing: your clients aren’t
hiring you so they can do your work for
Yegor Bugayenko
Lazy Developers Are
the Best Developers
http://bit.ly/2lEC9KE
July 15, 2019
We are taught from a
young age that the hardest workers enjoy the most success. Hard work pays
off, or so we are told. But “hard work”
can be a bit problematic for software
developers, because it often means going well above and beyond the original
scope of the project.
This is especially true when it comes
to understanding legacy code. When
you deal with legacy code, you often find
yourself having to engage in so-called
“deep thinking.” You are expected to understand large problem scopes before
you even begin trying to fix the small
bugs. For a long time, this stressed me
out. Then I got an idea: be lazy.
At my company, Zerocracy, we practice a #NoAltruism policy. We, quite literally, think only about ourselves and
our personal profit. This might sound
a bit harsh. Isn’t it better to play nice
and try to appease your clients? In an
ideal world, maybe. But here’s what we
have learned about clients: they also
practice #NoAltruism.
The Benefits
of Indolence
Yegor Bugayenko explains his realization that
software developers should go neither above nor beyond.
DOI:10.1145/3360907 http://cacm.acm.org/blogs/blog-cacm