
Beware of Developers Who Do Negative Work - beekums
http://blog.professorbeekums.com/2016/12/beware-of-developers-who-do-negative.html
======
ThePhysicist
Considering that the author writes on his resume that he lead several teams,
it startles me a bit to see how easily he puts all the blame on the developer
and none on the other team members (including him) and the management.

The way I see it, as a senior developer or team lead it is your job to make
sure that your junior level programmers are doing good work, and if they
don't, you either help them to improve or (if that's not possible) let them
go. Whenever I hear a story like "this person did bad work for six months so
we had to delete all his code changes and let him go" I immediately know that
something is very wrong with the management of the software project in
question, as in a good team structure it's just not possible that a single
person does "negative work" for several months, let alone a year without being
noticed.

Also, whether a developer will do good or bad work does not only depend on
his/her ability, but also on the circumstances under which he/she works. Some
people need more oversight and a tighter feedback loop to be productive, while
others can work in a more independent way. In any case, with a good team
process it is really hard for a single person to do negative work, and if it
happens it's usually the fault of at least several people (due to lack of
clear standards, missing feedback cycles or lack of ownership).

So if you're a senior developer or team lead, don't put the blame on other
programmers, but instead ask yourself how you can build a process that makes
it really hard for individual programmers to do bad work.

~~~
guitarbill
> let them go

Erm, that isn't how corporations work. First, team lead doesn't mean manager,
and even then in some companies, first and second line have very little to
say. HR needs to be involved, etc. Which creates more work. There are the
people who simply don't care. Contractors on a gravy train or outsourced
people. I've been there, there is nothing you can do in this case.

I think it's fair to say from your resume/LinkedIn that you have been shielded
from such effects for most of your career. Consider that a blessing, but don't
assume you always have so much control over your environment. A lot of us are
more like mercenaries, making good money out of bad situations while we can.

~~~
ThePhysicist
That's a valid point of course, thanks for pointing this out! I assumed that
the organization in which you work is at least partially functional and that
management has an interest in ensuring good working conditions, which as you
say is not always the case.

But even if you're not in a position to do hiring/firing decisions there is
still a lot you can do to make it harder for other people to do bad work. One
of the easiest things is to agree on a standard for your codebase with the
other developers, and create a process through which you monitor this standard
(e.g. through code reviews).

If that's not possible due to resistance from management or a dysfunctional
organization, you should consider leaving that position as soon as possible as
it is not a good environment to work in (and as the author says, luckily there
are enough opportunities for good programmers these days). But again, the
problem here would not be the single bad programmer, but the setup of the
whole organization, which is unfortunately much harder to fix.

~~~
guitarbill
I agree. Funny story with the code review, we had that. But several devs kept
submitting broken/bad code, so they could tell their manager "oh, I'm waiting
on a code review". The loss of productivity due to other devs trying to do
constructive code reviews was staggering.

One guy was asked to leave a project after he submitted 17 updates to the same
commit, and all of them failed basic (and luckily automated) linting. Another
contractor titled all his commit messages a single word: "update". I've even
worked on a project where the build system was "maintained" by contractors -
talk about a conflict of interest. You can imagine how transparent it was.

~~~
ptero
Of course there are developers who bring problems to projects.

However, many of the problems are organizational: I have seen some projects
place sizeable incentives on any bug fixes (e.g., highly value number of such
submissions / week), which encourages people to do quick fixes for simple
things, not important ones and does not penalize for poor performing software
and convoluted code. If one finds itself in this environment, IMO it is best
to run away.

I wonder why such organizational behavior is very difficult to change -- I
have seen, twice, smart people brought in to clean up a project stuck in this
state. They were given freedom to run it the way they saw fit (upper
management knew the project is failing) and both times they failed to change
it.

~~~
guitarbill
> I wonder why such organizational behavior is very difficult to change -- I
> have seen, twice, smart people brought in to clean up a project stuck in
> this state. They were given freedom to run it the way they saw fit (upper
> management knew the project is failing) and both times they failed to change
> it.

It's a good question. I think it's often a hard sell, that the change, while
more work in the short run is less effort in the long run. Why should I care?
I'm still getting paid the same. Of course, that's a facile argument and easy
to refute: professional development.

In my experience organisational behaviour has a root cause. You have to find
that and understand it to change it, you can't just change the organisational
behaviour but leave the root cause. To an outsider, the root cause probably
isn't obvious. Heck, sometimes by the time you understand it yourself, you've
been there so long you might as well move on. But often, it's also the devs
who refuse to get political. Who understands the system better, and why should
somebody else fix it? But then the obvious excuses happen. "Too busy", "Not my
problem", "Nothing I can do". Devs start leaving the project or the company.
Now, it's never going to get changed. Apathy is the worst symptom.

------
userbinator
_An even more egregious form of negative work is a developer who is stuck
using out of date programming practices AND has a large amount of influence at
a company._

At the other extreme is the developer who is so entranced by "newer is better"
mentality that they rewrite everything in an attempt to conform to "latest
best practices", increasing complexity massively while introducing a bunch of
bugs and huge dependencies no one ever actually needed. I've experienced that
(and had to undo the mess) a few times.

Relatedly, just as there are "10x" developers, there are "-10x" as well --- it
takes the average developer 10 times as long to fix as one of these takes to
break.

~~~
renolc
This is definitely true on both ends.

At a previous company, the tech influencers believed in the archaic "do
everything in the database." While we were technically using the .Net stack,
we weren't allowed to do any actual business logic in C#. Instead it had to
all be done in MS-SQL procedures (or at least at much as possible with very
little CLR glue).

Similarly at my current company, we had a product were the initial devs wanted
to jump on the RXJS and Socket.io bandwagons. The only problem was the rest of
the company was using standard REST endpoints and promises to do the same
thing, so any new devs who joined that team suddenly had massive cognitive
overhead they had to overcome. Any changes to the codebase we're done by
people who only half understood what they were doing, and so the complexity
compounded. Thankfully, I was given the chance to rewrite the whole codebase
to match what our other products looked like, so now the code is much more
sane to work with.

~~~
indexerror
Can you explain why you feel that "do everything in the database" is archaic?
A lot of logic (especially authentication logic) can be put in the database
only. Not to mention that I won't trust anything that only has application
level security, and nothing at database level to check/limit it.

~~~
Illniyar
Logic in the Database has the following issues:

1\. it doesn't work well with source control

2\. deployments, rollback, replication, synchornization - they don't work very
well with db procedures

3\. unless you connect directly to the db, then you must have some logic on
the serverside, usually you end up replicating logic from the db to the
serverside

4\. Databases languages (even advanced ones like PL/SQL) are not expressive
enough

5.It's much easier to scale out the server then the database (and if you are
using Oracle/Sql-server etc... also cheaper), and you don't want your
database's cpu to be clogged with logic code execution

6.Unit testing (or any testing) is extremely difficult

7.Debugging is hard and convoluted (also it doesn't usually work inside your
IDE)

and a whole lot more.

Nothing is absolute or completely obsolete, but it is considered a bad
practice for a long time by most industry professionals.

As far as I know the most popular article about it is:

[https://blog.codinghorror.com/who-needs-stored-procedures-
an...](https://blog.codinghorror.com/who-needs-stored-procedures-anyways/)

~~~
lostboys67
All of that apart from 5 is totaly wrong

~~~
m_t
What's the solution for source controlled database logic?

~~~
coldtea
What's the problem with source controlled database logic?

Have your statements (including those that create stored procedures on setup,
migrations, etc) on text files, and just load those into your Git or whatever.

~~~
lmm
The problem is ensuring deployment matches up. It's very easy to end up with
subtle differences between a newly deployed database instance and a database
instance that was deployed with an old version and then updated. For code you
would think very hard before deploying each version as a patch to the previous
version - it's easy and effective to just deploy the code afresh each time,
with a complete artifact built from a specific VCS tag. It's much harder to do
that with databases; the tooling just isn't there and it's hard to ensure that
you wipe out previous logic but retain previous data, because data and logic
are commingled. You could possibly build a system for this kind of thing, but
the standardized tooling just isn't there.

~~~
jholman
I don't understand what's hard about mass-overwriting your previous stored
procedures with new ones.

You're right about non-SProc code; just deploy all of it. Do the same thing
with SProc code!

What's tough about keeping all your code in files that start with "CREATE OR
REPLACE FUNCTION <funcname>", and just firing them all at the DB (within a
transaction, if you like)?

I don't actively advocate putting all the code in sprocs, but I can see
advantages. I also don't advocate using PHP, and yet people demonstrably build
some great websites with it.

~~~
rejschaap
Your approach is a bit naive. You will accumulate a lot of crud if you don't
drop any function you deleted or renamed. This crud could even set people up
for making mistakes, like using a function that shouldn't exist and does stuff
that harms the integrity of the data.

------
ianbicking
I would fault this article for treating each developer as a being
intrinsically good or bad. I've seen people I know are very talented (based on
past work) become negative developers. Depression is a common cause. If they
are underperforming they may react to their own self-disappointment by acting
defensive and resisting change of the inclusion of anyone they think may judge
them. I think there's many destructive feedback cycles that can turn a good
developer into a negative developer.

~~~
throwaway1892
Also devs can have different skill level in différents areas. One could be a
rock star at the server stuff and do a poor job at the UI/web stuff (or any
other possible version of this).

So that's another layer of variation to take into account.

------
gumby
I have one exception to the "convoluted code" developer. I worked with a guy
whose code was pure spaghetti. Mostly write-only code.

BUT: if a customer had a crisis he was the person to send. Amazingly quickly
he would suss out the problem and get things running -- making the customer
happy and rescuing the SLA. And he could explain what the problem was so
someone else could implement it again, properly, perhaps in 10X the time, and
ship the patch to all the customers.

In other words: if the river was rising and the dam was leaking, this guy
would stride in confidently and jam his fingers into all the holes, saving the
city. Not a long term or scalable fix, but preventing disaster.

(I'm pretty sure 50% of developers on HN have used this guy's code BTW).

~~~
flukus
> Amazingly quickly he would suss out the problem and get things running --
> making the customer happy and rescuing the SLA

Probably skills they learned reading their own code. I've noticed it with
other people, the ones he can quickly debug spaghetti are the ones that will
create more of it. It's why they stick around, management likes them because
the can solve problems, they just don't see the creation of yet more problems.

~~~
firebones
On the surface, I think you're describing fire-fighters (who are loved for
solving high-visibility problems), but in retrospect, I think these are also
developers with very high reading comprehension and reasoning abilities. That
may not make them great designers and architects (though some are), but they
can see code for what it is and fix it, as in "The Big Lebowski", "in the
parlance of our times" (in other words, in a way that fits the code as it was
originally written).

~~~
Aeolun
I mean, if you understand spaghetti code just as easily as any other code, why
wouldn't you write it? It would make no difference to them.

~~~
MAGZine
What is this reasoning?

If you know the right way and wrong way to build a bridge, you'd build it
wrong, because it makes no difference?

~~~
falsedan
More like, if you know English and Latin, why not blog in Latin, since it
makes no difference to your ability to enjoy your posts.

~~~
user5994461
So, the question that makes the difference should whether he writes blog for
himself or for his readers?

[replace "blog" by "code"]

~~~
falsedan
Anyone can read their blog! Since anyone can learn Latin, if they feel like
it.

(Yes, I know I'm representing a terrible argument.)

------
matt_wulfeck
> _So if the cost of a developer who does negative work is so high, how do
> they get hired? Part of it can be explained by an interview process that
> needs improvement, but a less talked about part is the temptation to lower
> hiring standards._

I've seen plenty of people who can reverse binary trees or fizzbang etc who
are terrible additions to teams and do "negative work". That's because having
a grasp of CS fundamentals and know how to contribute to a team are totally
different skills.

The way to overcome this is not smarter and/or more challenging interview
questions, but by hiring engineers that come recommended by other engineers.
This is _by far_ the greatest indicator of a successful engineer I've ever
seen. Nothing comes close to it. As far as I care, if someone I work with and
respect recommends someone else that's enough for me to give them a try
without even needing to whiteboard.

~~~
bad_user
Even though CS fundamentals and contributing in teams are somewhat different
skills, in my experience the terrible developers that contribute negatively to
the project tend to be those that do not have a good grasp of CS fundamentals.

I mean, some problems we are faced with are very, very challenging and if
somebody can't figure out how to reverse a binary tree or do a FizzBuzz, then
what can he do?

Also I'm hearing this advice to hire engineers recommended by other engineers
quite often, however speaking as somebody constantly engaged in hiring
decisions at our company, I must say that recommendations _don 't scale_.

You see, outside the SF bubble of course, our friends are mostly not into
software development and we engineers are kind of introverts, goes with the
territory, so we don't have that many friends or acquaintances anyway, except
for people that we meet on the Internet, which usually live in another city or
country. If an employee can produce one good recommendation, that's way, way
above the average. It's such a rare event actually that such employees need
reward.

This advice also misses the point. The problem is that our industry is
constantly growing and there aren't enough good people to go around. Which
means we have to take the plunge and hire beginners as well. Investing in the
education of beginners is the only way a company can scale in talent. But even
then you need a filter. You can't hire anybody that walks through that door,
as firing people is a serious drag on morale and a net loss for the company.

So what filter can you apply to beginners? CS education of course, or in other
words what people should have learned in school.

~~~
guitarbill
It's hilarious, because our best hires are people who had no CS education.
Meanwhile, some of the worst hires were CS grads.

Things that are hard to teach: Can you work in a team, especially if some of
them are remote workers? Can you leave your ego behind? Can you deal with the
corporate BS that gets in the way of programming? Can you think of the user,
use-cases, business value, etc of the feature/product you're developing? Can
you digest technical information?

Things that are not hard to teach: CS fundamentals, programming (given a basic
understanding of logic).

I won't go as far as to say a CS education is harmful, but it isn't a good
indicator, either. Personally, I find CS, in trying to validate itself as a
"science" (which it is not, no scientific method, just like maths isn't
science, but still valuable), makes stuff over-complicated and relies on
terminology far too much.

And by focussing on it, you lose a huge pool of potential applicants.

~~~
bad_user
That CS fundamentals and programming are easy to teach is a myth that keeps
being perpetuated and I don't understand why.

I'm also involved in an education program for children and as a matter of fact
computer science is among the most difficult subjects to teach, right up there
with math. Yes, you can increase interest and engagement by better teaching
methods (e.g. playing and building games), but that CS is hard is
indisputable.

> _Can you work in a team, especially if some of them are remote workers? Can
> you leave your ego behind?_

In our line of work, working as an individual on your own piece is actually
what happens in 90% of cases. The other 10% you have to cooperate with your
team to make decisions and to reach compromises on points of intersection, on
protocols, on best practices, etc.

But if we are honest with ourselves, collaboration in our industry means
having contention / concurrency in the development process and that doesn't
scale and minimizing contention leads to better productivity. This is why we
hate open spaces, why we ended up with micro-services, or why we split big
teams in smaller teams. It's all about achieving parallelism by _reducing_ the
needed collaboration.

Don't take offense in me saying this, but team work is a _soft skill_ that
isn't hard to teach or learn at all. So lets be blunt. You're talking about
assholes and having assholes really depends on your company's culture and what
gets tolerated. If you don't tolerate assholes, some people will change their
attitude, some will leave and the rare few will have to be fired, but such
cases are rare.

~~~
guitarbill
* Big-O. It's basically enough to know when an algo is going to perform horribly - e.g. O(n^3) - and even then you might choose it because it's simple or your n is currently small. Anyway, senior dev or architect can make this call way better than any grad could, CS or not.

* Data structures. Many high-level languages now have better basic data-structures than many devs could write, even if they know the theory.

I could continue, but most people do fine without these CS 101 basics.
Besides, good/interested people will ask questions about the code base and
will read up on these concepts when mentioned. Doesn't take a genius.

> but team work is a soft skill that isn't hard to teach or learn at all

Let me get this straight. You're saying that behaviours you might have
established in your teens, and so held unconsciously for almost 10 years by
the end of your degree, those are easier to change than something you just
learned? Something that people can teach themselves as a hobby, and often do?

But, if soft skills are really that easy to teach, I have several, lucrative
opportunities for you. Meanwhile, CS courses online are a dollar a dozen or
free. Honestly, if you could write up some stuff about this, I'm sure several
people on HN would appreciate truly actionable advice on how not to
accidentally be an asshole. Even better, if you can somehow make great devs
into great managers, that's also worth gold.

I will admit that good teachers really help with both maths and CS, and good
teachers are rare. Luckily, I had a good mentor by accident when I was 14.
This year, our team has been to twelve local schools to help teachers make it
more fun. And yeah, some kids struggle, just like any subject, but most
actually have no issue at all picking this stuff up. Not worried in the
slightest about the next generation's programming skills.

~~~
lmm
> But, if soft skills are really that easy to teach, I have several, lucrative
> opportunities for you. Meanwhile, CS courses online are a dollar a dozen or
> free. Honestly, if you could write up some stuff about this, I'm sure
> several people on HN would appreciate truly actionable advice on how not to
> accidentally be an asshole. Even better, if you can somehow make great devs
> into great managers, that's also worth gold.

To be fair a lot of people seem to have their personal identity invested in
poor communication abilities, or see it as somehow "fake" to work on them.
E.g. I see _How to Win Friend and Influence People_ recommended here, but
you'll see a lot of people who refuse to read it on principle.

~~~
guitarbill
"How to Win Friend and Influence People" is a bit dated, but has some good,
actionable advice. I find when people hear about negotiations/promotions/job
offers they've missed because of poor communication abilities, and change
their tune quickly.

But once you're into adulthood, it's rare to get constructive feedback about
social skills (even from friends). So it can be catch-22, especially if you
aren't very attuned to the reactions of others. It isn't that they don't want
to change, but if you aren't charismatic or confident, you're going to have
different outcomes in the same situation, so it's self-reenforcing. And
infuriatingly, the intrinsically high-charisma people don't know what's
needed.

A book I can recommend is Keith Ferrazzi's Never Eat Alone. I find the name-
dropping cringe-worthy, but it made business relationships click for me, which
got me to do more social stuff, etc.

------
agentultra
The "convoluted code" gauge is a double-edged sword. You could also be working
at a company with developers who have no experience with the benefits of
functional programming. In this scenario it's those who write nested loops,
branching if-statements, and mutating side-effects that are in charge and
you're the bad developer for using fold and map. You could be seen as an
elitist who likes to write clever, obfuscated code that nobody else can
comprehend.

Not all positive contributions are worthwhile. One could simply blend in and
add one more level of nesting, one more conditional, and mutate a few things
here n there. After all, everyone knows what a for-loop is, right? Staying
productive is important!

Well... until your most productive hours are spent chasing down errors you and
your team designed.

~~~
woah
Functional programming does have some useful syntax and principles that can
make code easier to reason about. But a much bigger red flag is if a developer
is so fixated on a certain programming philosophy or methodology that they
don't pay attention to writing simple, good code.

~~~
alkonaut
> that they don't pay attention to writing simple, good code.

Amen. If you have a complex problem to solve, and the style is between
obfuscated FP and complex OO, the choice is already a bad one. If the code
can't be written very clearly, probably the problem is posed wrong, or
shouldn't be solved because the maintenance costs will be too high anyway.

The negative contribution developers I find are those that don't challenge the
formulation of the problem. This takes some confidence to rather challenge a
manager with a better design, rather than actually write a complex solution to
a problem to get a pat on the head.

So the most dangerous developers in my book are those that like the pats on
the head they get from solving complex problems by writing complex solutions.

~~~
jakub_g
> The negative contribution developers I find are those that don't challenge
> the formulation of the problem.

Couldn't agree more. Furthermore, sometimes the best code is _no code at all_.
If the code has 0 lines, it will not contain bugs, and will not take time for
bug fixing and maintenance.

------
lordnacho
Good points. Regarding how such people come to influence, you have to remember
a lot of people, especially in startups, are not hired through a process at
all.

I worked with a guy for many years who was as described in this article.

He can't code and he can't do any math, despite holding a phd. He can talk
about math and he can talk about code, but we're talking excel level skills
when what you need is someone with a modern ML level skillset.

He made all the decisions about which trading strategies were worth pursuing
and which ones weren't, despite the presence of plenty of more qualified
people.

How could this be? First of all, the boss of the fund did not have the skills
to judge who could write a trading strategy, and who couldn't. So he was stuck
with recommendations from other people who also didn't have this skill,
leading to this hire. He also relied on his bias towards people of his own
ethnic group, which benefitted this chap we're talking about greatly.

Essentially, broken feedback. Someone who can't judge relying on the judgement
of someone who isn't competent but has his ear.

I'm sure this has happened to a lot of folks. Probably you need a somewhat
larger organisation for there to be enough informed people to point fingers,
and you need some luck for the culture to be such that a complaint would
actually come through rather than be suppressed.

~~~
soVeryTired
I work in finance and I've seen the same thing happen. I guess it's more
common than people realise.

------
d--b
Maybe the guy was really dumb or "awful" as the author puts it, but I think it
is wrong to blame it all on the hired developer.

It's like in sports, there can be great players underperforming because of the
wrong team / wrong coach.

When a team hires a person, there is a decent amount of time during which the
hired person's code is not coherent with the hiring team's. During that
period, the hired person must be trained so that the code can match the
quality standards / spirit of the team. During that time, other devs have to
mentor the new dev, which in itself is "negative work".

What the author is really saying here is "beware of the developer that needs
training". Of course it'd be better if all new hires didn't need any training,
but it is unrealistic.

Training is necessary for all new hires, not because people don't code
properly, but because their coding style not necessarily match the hiring
team. You can hire a very experienced developer who you feel spends too much
time on testing, while your team has a more "move fast a break things"
approach to dev. Or having people who are used use design patterns, because it
worked in their previous workplace. There is always some time required to
adapt.

Hiring a developer and have him check in 2 things in a period of 6 months is a
failure of the entire team. If the guy was so awful, that should have been
spotted in the first 2 weeks. And his "awful" code would certainly not have
gone through to production.

------
pipio21
As an entrepreneur and former manager and engineer I find this analysis too
simplistic.

In particular he talks about outdated methods making work negative and while I
agree, most of the time I find the opposite problem: most programmers wanting
to use the new language of the Week.

The new language of the Week was so great and saved so much time on some area
but because it is not production ready you are forced to fill the gaps and do
a ton of work that would never be necessary with the mature language in other
areas, like installing libraries and dependencies, resolving conflicts that
nobody had solved before because so few people use the new language...or just
debugging the new language itself.

Also as a manager it is your job and responsibility to make things work. If
you can't see the problems before they happen and manage it it is your fault,
not the developer's.

People have a lot of psychological delusions and faults, but as a manager you
study them and if you are good could handle it easily. If a soccer team is not
well organized is not the responsibility of the players.

If a person has a tendency to use outdated software like the player wanting to
dribble to much, you correct it and basically everybody is happy. When things
go good and you have success everybody is happy.

------
analog31
While the concept of negative work is certainly instructive, my misgiving is
that it's probably difficult or impossible to measure the overall value added
(or subtracted) by any worker in a complex organization.

My guess is that most of us have our positive and negative moments, and
hopefully the positives outweigh the negatives.

~~~
skylark
Great point. While articles would have you believe that programmer skill is
bimodally distributed (good vs. bad), it actually follows a normal curve like
most other things. We all make some good decisions and some bad decisions
everyday.

I'm sure we can all find a piece of code we wrote a year or two ago that makes
us cringe a little bit.

------
maus42
The blog post reiterates what everybody probably already knows; similar
content gets posted on HN semi-regularly.

On the other hand, I've also heard that most of interns' / junior devs' first
projects end up shelved (i.e. net contribution = 0).

From a viewpoint of a mediocre developer, a far more interesting question is
how to get into the feedback loop where you actually _learn_ from your
mistakes and the quality of your contributions _improves_.

------
beejiu
The solution to this problem is code review. Good developers do not want bad
code in the codebase. If you give them authority to stop bad code getting in,
it won't.

Unfortunately, 'negative work' developers are often perceived by the rest of
the organisation to be doing good work. They can make quick changes and
deliver results fast. It is almost impossible to measure the real impact a
developer's changes has, but easy to measure how much they are doing week-by-
week. Therefore, the only practical way to make the issue apparent is by
stopping the bad code getting in.

So when the developer says my work is "done", it sits in code review for
another 2-3 works until it is "done done".

------
tyingq
_" He made 2 changes to the code base over his 6-month tenure there."_

And the context implies those were the only 2 changes/check-ins. Seems odd
that nobody questioned the low output.

~~~
jim_d
This seems strange to me as well. How were they planning/tracking the work
that needed to be done for their project?

~~~
falsedan
More questions: where were the code reviews and testing to show that this work
should have shipped?

------
mschuster91
> An even more egregious form of negative work is a developer who is stuck
> using out of date programming practices AND has a large amount of influence
> at a company.

Well, out of date may also be seen as "battle proven". Just look at the JS
scene and Angular 1 vs 2 (not to mention the boatload of now dead frameworks,
tools etc)... often enough sticking with proven tech instead of hipster dung
is the more long-term viable solution. But of course to do this, managers and
developers have to adopt a long-term view (one or two years) instead of a 2
week sprint...

------
dankohn1
There's this magical process called continuous integration that internalizes
the impact of bad (or, more likely, misguided) developers. Don't let them
merge their branch until all tests pass. If their commit breaks something
while all tests still pass, then direct them to write the missing tests.

~~~
flukus
CI does nothing to prevent bad developers checking in bad code. You just end
up with equally poor unit tests.

~~~
pryelluw
True. Code reviews and standards are the tools to use in this case.

~~~
jim_d
I've found that code reviews are one of the best ways to increase code
quality. Even just talking with other developers about why they've done things
is helpful in thinking about simpler options and keeping things closer to the
architectural vision.

~~~
pryelluw
Just questioning the implementation is enough to improve quality. Plus it
helps people grow without putting them on the spot (if done right).

------
Chris2048
> one influential developer didn’t like any kind of change and they were
> allowed to veto any forward progress

I'm a little skeptical, it feels like I'm only hearing one side of a story.
How does the author justify the characterization "didn’t like any kind of
change".

~~~
theparanoid
The unwritten assumption is the influential dev. had less say so with the
streamlined process which thereby would reduce their power in the company.

~~~
Chris2048
could be, but I assume a dev with veto power would be a senior dev?

Did they just say "No! I don't like change", with arms crossed; or did they
have more to say about their reasons?

We only hear the authors conclusions, not the original evidence; yet usually
'veto powers' are given and respected for a reason.

------
stevehiehn
You are making the calculation at a point in time. What if the 'bad' developer
is on a fast growth curve and in only a few months time will be a net gain for
the company?

~~~
flukus
Unless the are in a junior/graduate position then they are probably not on a
fast growth curve.

------
ashish_b
This guy is so negative. The word 'bad' itself fills you with so many negative
connotations. What were the reviewers doing when so called bad developer was
pushing code?

------
gbvb
Without sounding like a curmudgeon, "An even more egregious form of negative
work is a developer who is stuck using out of date programming practices AND
has a large amount of influence at a company. " can happen when new developers
come up with ways of re-writing applications without understanding the full
problem statement or spending the time to understand the existing codebase.
Usually, they might have worked on a small to medium sized projects and show
up to work on a project with millions of lines of code with teams in different
geographies and expect to change things across the board. When the same
explanation has to be given the 15th time, you can turn into a toad and start
saying "NO" first. :)

------
hibikir
It's true that not all developers make positive contributions, however, I
think that blaming "lowering hiring standards", as the author said, is a
complete red herring.

There is such thing as hiring without doing even the most basic test for
technical competency: Last year, at a different job, I worked with a guy that
though the best way to implement a CRUD service was an nginx plugin, and when
faced with a real programming language, managed about 4 lines of code a week,
and not good ones. But that's an extreme case of not even checking.

In practice, we have to face that all that our quest for more stringent hiring
standards is not really selecting the best, but just selecting fewer people,
in ways that might, or might not, have anything to do with being good at a
job. Let's go through a few examples in my career:

A guy that was the most prolific developer I have ever seen: He'd rewrite
entire subsystems over a weekend. The problem is that said susbsytems were not
necessarily better than they started, trading bugs for bugs, and anyone that
wanted to work on them would have to relearn that programmer's idiosyncrasies
of the week. He easily cost his project 12 man/months of work in 4 months, the
length of time it took for management to realize that he had to be let go.

A company's big UI framework was quite broken, and a new developer came in and
fixed it. Great, right? Well, he was handed code review veto to changes into
the framework, and his standards and his demeanor made people stop
contributing after two or three attempts. In practice, the framework died as
people found it antiquated, and they decided to build a new one: Well, the
same developer was tasked with building new framwork, which was made mandatory
for 200+ developers to use. Total contribution was clearly negative.

A developer that was very fast, and wrote working code, had been managing a
rather large 500K line codebase, and received some developers as help. He
didn't believe in internal documentation or on keeping interfaces stable. He
also didn't believe in writing code that wasn't brittle, or in unit tests:
Code changes from the new developers often broke things, the veteran would
come in, fix everything in the middle of the emergency, and look absolutely
great, while all the other developers looked to management as if they were
incompetent. They were not, however: they were quite successful when moved to
other teams. It just happens that the original developer made sure nobody else
could touch anything. Eventually, the experiment was retried after the
original developer was sent to do other things. It took a few months, but the
new replacement team managed to modularize the code, and new people could
actually modify the codebase productively.

All of those negative value developers could probably be very valuable in very
specific conditions, and they'd look just fine in a tough job interview. They
were still terrible hires. In my experience, if anything, a harder process
that demands people to appear smarter or work faster in an interview have the
opposite effect of what I'd want: They end up selecting for people that think
less and do more quickly, building debt faster.

My favorite developers ever all do badly in your typical stringent Silicon
Valley intervew. They work slower, do more thinking, and consider every line
of code they write technical debt. They won't have a million algorithms
memorized: They'll go look at sources more often than not, and will spend a
lot of time on tests that might as well be documentation. Very few of those
traits are positive in an interview, but I think they are vital in creating
good teams, but few select for them at all.

So I think that it's better to be a bit less stringent early, make take homes
part of the interviews, and just learn that it's OK to fire people if they
aren't working out.

~~~
guitarbill
> I think that blaming "lowering hiring standards", as the author said, is a
> complete red herring.

I've seen it done, far too often. Management-only hiring interviews because
devs were being "too stringent" and it was "time-sensitive". A guy who had
"contributed to the Linux kernel", but his FizzBuzz implementation didn't
work. Of course, management didn't notice, only by luck did a dev look at the
whiteboard after the interview.

Or, even if they haven't lowered, someone slips through the cracks. They then
usually bounce from team to team, happily collecting paychecks. Then, after
they've been around for years, having worked on so many projects, management
considers them senior somehow. Everybody thinks "can't be that bad if nobody
has fired him", and thus firing never occurs.

------
rokosbasilisk
After reading the article, I feel like a code test and discussion and or
whiteboard would have filtered the type of developer they mentioned who is a
net negative on the code base.

~~~
greglindahl
I've seen devs that passed a code test and discussion that had this problem.
For example, you can interview someone on a good day, when most of their days
are bad days.

I don't think there's a magic interview style that prevents this problem.
Corrective action and fast firing if necessary have worked for me. And
whatever you do, don't impose onerous procedures on all of your devs because
one of them screws up on a regular basis!

~~~
beekums
> And whatever you do, don't impose onerous procedures on all of your devs
> because one of them screws up on a regular basis!

This is a really important point. Creating processes for the lowest common
denominator just stifles every other developer.

~~~
Karunamon
Seconded. Sometimes the answer to a mistake being made is not to take on a
boatload of process in an attempt to make sure it can't happen again, it's to
slap the hands of the offending person and say _don 't do that_.

------
benjaminRRR
There are both upstream problems (hiring the wrong people) and downstream
problems (having process to catch garbage before it gets into mainline). You
need both as you will inevitably make a bad hire somewhere along the way. For
downstream prevention you need good processes to catch poor quality code.
We've found that automated (static analysis [we like sonarqube]) plus
consistent human code reviews goes a long way to ensuring a high quality code
base.

------
GoToRO
The way I've seen it happen is this: you have some developers, some are good,
some are not that good. The good developers leave, the bad stay. In time that
bad developer will be the only one on the team that has 10 years experience.
It will be the only person that knows all the little details of your project
and so he will even get a management position, or a senior title. Of course,
all those details should be documented somewhere but they are not.

------
at-fates-hands
The funny thing is I read a the first few paragraphs and thought two things. .

1 - proper onboarding

2 - standardized code

My first gig as a developer was at a place that hammered out some 2,000
websites a year. When you start to think about that number, you get a
headache. That roughly meant that our devs were required to cut up a psd, code
and integrate 15-18 sites a month.

In order to do this, you need to have really strict standards. You need to
have a stable, repeatable process in place to be able to handle that many
sites in a year.

Two things the company did to ensure this was to first to have a two week
training. Then you did pair programming for another two months. By the third
month, you were far enough along where you knew the standard templates, the
naming conventions, the JS conventions and you stuck in that lane and didn't
do anything outside of that without a senior devs approval.

This lead to having standardized code for every site that was built. You could
pull out a site that was developed two years ago and easily change or update
the code because everybody coded the same way so it was easy to dig into the
code and find or change something. The advantages were obvious. Minimal cross
browser issues, standardized coding by developers, faster dev times, less
errors and weird coding issues like the author points out. It literally came
down to then how fast a dev can code and how productive he can be.

Sure, it was a little repetitive and boring at times, but the efficiencies
were undeniable. That company was the last place I worked at where they went
to such great lengths to train and standardize their processes. I've since run
into many of the issues the author points out because of the lack of coding
standards and training new devs to those standards.

------
jonaldomo
Sounds like you have no process: Before task is assigned, there should be a
technical design and acceptance criteria. All code should be peer reviewed.
All code should have an attached unit test. All code should be tested in a dev
and cert environment.

------
sextus_prop
Interesting, just recently read about similar concept from Chris Hadfield's
book "An Astronaut's Guide to Life on Earth". He puts all team newcomers intro
three categories minus ones, zeros and plus ones. Basically minus ones will
think they always know better and do not spend effort on familiarizing
themself with existing system, they also ignore epistemological category of
"unknown unknowns". Chris recommends always to strive for being a zero at
first.

------
kelvin0
TL;DR: Some devs introduce toxic code in your codebase, you shouldn't hire
them.

However, it seems to me proper code reviews and mentoring would have prevented
that in the first place? That's an important responsibility for the 'good'
devs, and you can't simply complain after the fact if you aren't proactive in
that sense.

------
ArkyBeagle
If A. Random Developer _can 't tell_ that/if her changes work before checking
them in, then ... how are they to justify checking them in at all?

A first alternate to actually testing things might be "conformance to a model
of Best Practices for changes that we think might - maybe - do minimum
damage."

------
alphanumeric0
For certain definitions of what is considered a positive contribution.

If the resident developer A has used the wrong approach to solving a problem
and developer B comes along and uses a better approach, dev B could be seen as
introducing something overly complicated and less understandable.

------
rurban
I call them destructive, or previously also "negative busfactor". Without the
few bad apples in my community the product would actually get better, but so
far it continues to decline over the last 15 years.

------
ctack
This article is the stuff of Imposter Syndrome nightmares.

------
partycoder
Well, I've met people that have created decades worth of work through
technical debt.

When you reach that point it is easier to just start over.

------
dreamcompiler
Absolutely true. Bad developers are not the ones who don't carry their weight.
Bad developers pull the whole team backward.

------
0xdeadbeefbabe
So, I ought to beware of those plan9 guys, eh?

------
sriram_iyengar
I'm surprised developers still do this in an era of 'frequent commits'

------
edblarney
There is another kind of pernicious developer: the one who writes large
amounts of seemingly effective, but ultimately bloated code.

What we often fail to realize is that 'code = cost'. Once written, code has to
be maintained, and every line adds to the inherent complexity of the system.

I think we are all familiar with that old IBM (OS/2?) allegory of the dev who
mostly spent time removing code from the system, and had to justify his salary
because they were measuring 'lines produced' as a metric. If you can 'remove a
line of code' from software and it still 'does the same thing' ... well,
that's definitely worth more than adding code :).

Anyhow, it's worth considering that 'number of lines of code' is really quite
a bad measure of anything.

Second - some people are really bright, but they struggle with clarity etc..
Perhaps it would be appropriate to put someone like this on a bug clearing
team? They can 'solve problems' by tracking down issues, and hopefully fix
them. 'Fixing' code is often much safer than writing new code as the patterns,
standards, practices are already 'in place'.

It's a rather a paradoxical and intriguing business, writing code!

------
joshuaNathaniel
> Bad Developer spends 5 hours writing convoluted code. Other 4 developers on
> the team each spend 10 hours each trying to figure out how it works.

Data please.

------
atomical
Who is the professor?

------
crispytx
Maybe these developers that produce "negative work" think your code sucks.
Ever consider that?

~~~
jerf
What's your point exactly?

~~~
Ace17
I think cripytx might be suggesting that the negativity of one's work might be
subjective. In software development, this idea has proven to be a very
dangerous one. And it's false.

Take a perfectly well-written module, it's always possible to transform it
into objective crap. Just for fun, here are some recipes for C++: \- add to
the module a dependency on a framework (e.g to use QString instead of string
just because the dev is more familiar with QString) \- replace implicit memory
management with explicit one (e.g just because the dev doesn't like
unique_ptr) \- reformat some parts of the source files one's own coding style
(e.g because the official one isn't good anyway) \- inline every function
that's only called once (e.g why the need to factorize if it's only needed
once?) \- up-front convert functions into function templates (e.g one day
someone might need the generic version!) \- "optimize" the code (unroll loops,
inline calls) without profiling it (e.g this part can't be profiled anyway
because it doesn't take enough time)

Let's take one module (module A), apply these recipes, you get module B. At
first, A and B both have the exact same number of features, and the exact same
number of bugs. However, as time passes, the stability of both will quickly
diverge, the cost of new features will also quickly diverge.

It doesn't require more work to directly create module A, because it's
actually about _not_ doing some things ; however, it certainly requires more
knowledge. Developers directly creating module B are implicitely relying on
the ability of their team to transform it into module A. And _this_ will
require work. This is negative work, i.e work that should have been done but
hasn't (also known as "technical debt").

------
jasonlotito
Not all developers make positive contributions, but no single developer in a
team of developers can make a non-positive contribution. They can't, because
as a team, you've decided to allow this person to make contributions alone.
You need to own that contribution. If you don't want to that responsibility,
there is a solution: code reviews.

Anything that gets submitted is literally something you've agreed to support
and are okay with being in the code base.

~~~
d_rwin
I have seen the type always conform to a style or structure. The designers
like to talk to design bent leads on devevelopment and manage only a subset of
issues that could materialise. A dev team for three or more years brings a
better structure to code and developement. Just the fact, the leisure time
well spent in code and banter bring enough structure to the team. I guess you
have to know your team better than your desk-jockeys.

~~~
jasonlotito
I'm honestly not sure what you mean here. I can't make sense of it.

~~~
d_rwin
Thanks Jason.

It is a little vague, I admit. The team strength in any scope or structure,
well defined is 'A Win'.

