you. They aren’t hiring you so they can
be your teacher, either. They don’t really want to explain anything to you. For
them, it’s money and time they would
rather not spend.
So your goal, then, is to get your clients to fix the code base so that the code
itself becomes more obvious and easier
to read. This will help not only you, but
everyone else. As such, focus on asking
for documentation and code source fixes.
Okay, so you’ve got the tickets out
and you’ve asked the client to fix their
source code and address other problems. So what now? Sit back and relax!
You wait for the tickets to be resolved
and don’t sweat who is resolving the issues; that’s not really our business.
Now, your employer may decide to
kick the problem back to you, asking
you to solve it on your own. That’s fine,
so long as you’re getting paid for it and
the employer expands the scope of your
work. Instead of fixing bugs, you’re
now documenting some functionality
or refactoring this and that.
As you create tickets and blame everyone else around you, you will continue to
create smaller and smaller scopes. Eventually, you may find that the tickets can
be fixed in a half hour or less. And keep
in mind, when I say “blaming everyone
else,” that doesn’t mean shouting at other people. It simply means not beating
yourself up for problems you didn’t create, and shifting responsibility for poorly written code to the original source.
Being lazy can take a lot of effort
(seriously). We are programmed not
to be lazy. Some people will resist the
call. They might feel ashamed (stop
it!). They want to be perfectionists (only
perfect what you’re paid to!). Or maybe
you lack the passion needed to be lazy
(get a new job!).
Comments
This is unacceptable practice from
ACM’s professional ethics guidelines.
Zerocracy promotes no altruism and
no help. This practice violates the core
mission of ACM as an organization, which
is “Contribute to society and to human
well-being, acknowledging that all people
are stakeholders in computing.” I request
ACM to retract this article. Computing
professionals have the obligation to
behave in an altruistic manner and help
each other for both advancement of
business productivity, human well-being,
and advancement of computing systems.
Zerocracy is a disgraceful movement for
computing profession.
—Mehmet Suzen
Mehmet, can you please elaborate on how
exactly “contribute to society” leads to the
conclusion that we are obliged to behave in
an altruistic manner?
—Yegor Bugayenko
I think this policy is created to end the
abuse on the client’s behalf. #NoAltruism
does not mean that in Zerocracy people
would create software to support terrorism.
Engineering is not altruistic, is precise. The
Zerocracy policies are meant to create an
efficient culture, not people without values.
I think Mehmet misunderstood what
#NoAltruism means.
—Eduardo Portal Geroy
“Computing professionals have the
obligation to behave in altruistic manner
and help each other for both advancement
of business productivity, human well-being,
and advancement of computing systems.”
As much as they have an obligation to not
waste their time for free, increasing the
engineering level in the company, helping
others do their job, and saving time to help
others and contribute to society in their free
time, doing really altruistic things, not what
you are talking about.
—Nikita Puzankov
“Computing professionals have the
obligation to behave in an altruistic manner
and help each other.”
There’s a difference between purposeful
altruism as a means to improve the system,
and blind altruism as a fanatic ideology.
The thing we need to keep in mind is, the
human psychology is never without its flaws,
no matter how hardcore a saint you would
be trying to play here. I myself have seen
numerous examples of a biased altruist
doing much more harm than a selfish but
rational person in a similar situation.
Zerocracy is about regulating those
psychological flaws, not trying to abolish
them, which would most certainly end in
(yet another) wasted effort. Being truthful
with oneself, first and foremost, is the
key in building all sorts of constructive
professional relationships. Ignorance of
that is bound to amplify guilt and fear in
performers many times in the end, which
might be appealing to certain moral
fundamentalists who believe a scared
programmer’s guilt complex is like some
sort of a virtue. The truth is, it just doesn’t
work out like that.
—Ilyas Gasanov
This occurs whether one is a consultant
or contractor, or a salaried employee
of the organization that owns the software.
I have been both.
Even within the organization that owns
the software, the deep thinking required
to document otherwise undocumented
systems or to fix underlying design problems
is discouraged, and the attitude of “fix the
immediate problem” prevails. This causes
the organization’s maintenance costs to
increase steadily over time as technical debt
piles up unaddressed, deeper and deeper.
This works similarly to the principle
of conservation of energy, which pops up
in infinitely varied guises whenever one
attempts to create a perpetual motion
machine: it is always thus regardless of
which trendy or modern “methodology”
is used in an attempt to manage the
problem solved without doing the actual,
necessary work.
In the end, one is doing one’s client
or one’s employer a disservice by not
warning them that a failure to solve the
deeper problems will cost far more in the
long run than any immediate savings they
will realize by ignoring those problems for
the present.
—Robert Watkins
Yegor Bugayenko is founder and CEO of software
engineering and management platform Zerocracy.
© 2019 ACM 0001-0782/19/11 $15.00
“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.”