20 ms·

Beware of Developers Who Do Negative Work

255 points by beekums 10y ago

hibikir 10y ago
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.
- mixmastamyk 10y ago
  > My favorite developers ever all do badly in your typical stringent Silicon Valley interview... My life story, sniff.
- guitarbill 10y ago
  > 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.
crispytx 10y ago
Maybe these developers that produce "negative work" think your code sucks. Ever consider that?
- flukus 10y ago
  That's possible, but if the code is sitting there for years without bugs then it is doing positive work.
- jerf 10y ago
  What's your point exactly?
  - Ace17 10y ago
    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").
userbinator 10y ago
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.
- sna1l 10y ago
  +1 to this. I used to work with a guy like that and it created a ton of tech debt. He would write new services using a new technology for each one, not to documenting or maintaining any of them.
  - Yhippa 10y ago
    What's sad is that it looks great on his or her resume to do that. That developer might leave a trail of carnage but they don't care--on to the new shiny job for them. It never catches up.
    - firebones 10y ago
      While I agree with you, who is in control there? Who lets the developer pick the tech and leave a trail of carnage? Neomaniacs gonna succumb to neomania. The bigger question is why the system permits that, rather than steer those urges to try something new into useful experiments that might advance the status quo.
    - Spivak 10y ago
      I can't really blame developers for this -- they're just responding to incentives. So long as hiring managers penalize candidates that don't have experience with trendy stacks then your actively doing your employees a disservice by prohibiting them. The only thing I can perosnally do to combat this problem is be conscious of it, not engage in that kind of hiring behavior in my office, and hope that the culture changes. Giving employees opportunities for side projects helps somewhat. Allowing for gradual migrations to new technologies helps as well.
rokosbasilisk 10y ago
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.
- thescribe 10y ago
  This is a good counter-argumnent to the frequent article decrying whiteboard tests.
  - beekums 10y ago
    I feel like whiteboarding is really essential when talking about how code should be written, but most whiteboard tests are about writing code on the whiteboard. There's a big difference between the two activities.
    - pryelluw 10y ago
      Good point. The whiteboard should be used to discuss the problem and the solution. Not the actual code.
  - tensor 10y ago
    How does a whiteboard test speak to documentation and code quality? By definition pseudo code is not production code and writing production style documented and compiling code on the whiteboard sounds like a terrible idea.
  - ryhamz 10y ago
    Only if you assume it actually works, which is the most blatantly circular logic in this thread. This guy could have said "I feel like a daily prayer in the server room would filter bad devs" and it would be just as proven as his feeling about whiteboarding.
    - rokosbasilisk 10y ago
      maybe if prayer required some coding ability
dankohn1 10y ago
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.
- arcticbull 10y ago
  Sometimes they are in politically privileged positions and you can't get rid of them, ask me how I know.
  - trustfundbaby 10y ago
    How do you ... know?
    - notwhereyouare 10y ago
      while I'm not arcticbull, I worked for a period of time with somebody who was a minority and completely horrible at their job. Everytime my boss tried to get him fired, HR pushed back
      - Spooky23 10y ago
        Solution is easy there -- promote away.
        Karunamon 10y ago
        Please no. That might get them out of your hair (maybe), but then you've just put someone incompetent in a position where they can exercise it even further. I think people doing this is the direct cause of some head-scratchingly awful middle managers I've had to deal with..
        falsedan 10y ago
stevehiehn 10y ago
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?
- greglindahl 10y ago
  A developer on a fast growth curve generally responds well to corrective action: hey, let's work together to make you a winner in our environment, instead of the person whose bugs are caught by your coworkers. I've had successes and failures trying this strategy.
- rokosbasilisk 10y ago
  I work as a contractor for a bunch of local businesses and I think I can safely say, companies absolutely hate taking that kind of risk. A bad developer or hire can produce bad work, be an hr nitemare and also destroy team dynamics.
- jerguismi 10y ago
  Really difficult to know. Employees are about the most difficult investment there is.
- flukus 10y ago
  Unless the are in a junior/graduate position then they are probably not on a fast growth curve.
tyingq 10y ago
"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 10y ago
  This seems strange to me as well. How were they planning/tracking the work that needed to be done for their project?
  - falsedan 10y ago
    More questions: where were the code reviews and testing to show that this work should have shipped?
maus42 10y ago
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.
edblarney 10y ago
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!
agentultra 10y ago
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.
- taeric 10y ago
  To be fair, many debugging tool chains are crap with folds and maps instead of loops. And code is rarely written in anger, but often debugged that way.
  - agentultra 10y ago
    Isn't that the truth! Debugging can bring out the worst in the best of us. Luckily I don't often have to debug code from functional programmers. The errors are usually mitigated by design and often easier to spot or reason about than in a function with a dozen branches mutating the object behind a pointer. The reason I call it a double-edged sword is because the majority will determine what is normal or acceptable. If you come to their office expecting to reveal the shadows on the wall you may very well find yourself looking for another office elsewhere. The harrowing difficulty is in bridging the gaps between each other and our differing approaches to developing software.
    - oselhn 10y ago
      You can write functional code with dozens of branches too. In my opinion this is because functional programmers are usually enthusiasts and good programmers. If all programmers start to write functional code you will hate it too.
benjaminRRR 10y ago
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.
jasonlotito 10y ago
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 10y ago
  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 10y ago
    I'm honestly not sure what you mean here. I can't make sense of it.
    - d_rwin 10y ago
      Thanks Jason. It is a little vague, I admit. The team strength in any scope or structure, well defined is 'A Win'.
- plorkyeran 10y ago
  Producing a lot of code which has to be reviewed without ever actually landing any of it is itself a non-positive contribution. Code reviews are wonderful and I'd never want to go back to working on a team that didn't do them, but they do take time from the reviewers.
  - jasonlotito 10y ago
    That's true, though I was specifically focused on actual code contributions that make it into a production branch.
ianbicking 10y ago
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 10y ago
  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.
- lolc 10y ago
  Thanks for verbalizing the unease I felt after reading the article. I would have been unable to express it so well.
gumby 10y ago
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 10y ago
  > 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.
  - joeguilmette 10y ago
    It's a balance you need to run. But as a PM, spaghetti fixers are indeed very nice to have around. Keeping an eye on technical debt is important though.
    - flukus 10y ago
      The hardest part isn't the technical debt, it's detecting when spaghetti fixers are actually adding features to the product.
      - joeguilmette 10y ago
        This is another great point. Our support team is directly linked to a spaghetti fixer, this is great bc bugs are squished instantly. But sometimes a new checkbox appears and that is a real problem.
alphanumeric0 10y ago
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.
sriram_iyengar 10y ago
I'm surprised developers still do this in an era of 'frequent commits'
analog31 10y ago
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.
- Insanity 10y ago
  This is pretty much how I feel about it as well. Sometimes you'll deal with a more complex system where bugs might creep in even for an experienced developer, that then end up needing bugfixes for a week to come. Yet you might also write code that does it's job great (mostly) without bugs a week later.
- skylark 10y ago
  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.
- runevault 10y ago
  I've known people who created negative work. Back when the economy was tanking in 2008 into 2009, we fired 3 developers at my job, the rest of us ended up getting more work done than we did when also having to deal with the work of those 3. One of the 3 you could argue about, but the other two 100% caused extra work from having to clean up after them regularly. At least one of which was somehow a senior developer and the other was either dev or senior so neither had the excuse of being new/junior devs, and had been around for a few years by that point so they had time to learn.
beejiu 10y ago
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".
matt_wulfeck 10y ago
> 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 10y ago
  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.
dreamcompiler 10y ago
Absolutely true. Bad developers are not the ones who don't carry their weight. Bad developers pull the whole team backward.
mschuster91 10y ago
> 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...
joshuaNathaniel 10y ago
> 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.
d--b 10y ago
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.
sextus_prop 10y ago
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.
lordnacho 10y ago
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 10y ago
  I work in finance and I've seen the same thing happen. I guess it's more common than people realise.
  - deleted 10y ago
    [deleted]
  - deleted 10y ago
    [deleted]
- arvin 10y ago
  > 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. The Dunning–Kruger effect in action.
- adekok 10y ago
  > 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. Which is why it's important for managers to understand the technology that they're managing. I ran into this 25 years ago. I knew someone who went to an MBA school. He spoke up at a party and said "I now have great management skills and can manage anyone!". My response was "No, because when you have a technical disagreement in the team, as manager, you have to make the final decision. And if you don't understand the issues, you're left deciding based on what, popularity of the engineers involved?"
ThePhysicist 10y ago
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 10y ago
  > 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 10y ago
    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.
Chris2048 10y ago
> 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 10y ago
  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 10y ago
    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.
ashish_b 10y ago
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?
partycoder 10y ago
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.
GoToRO 10y ago
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.
ArkyBeagle 10y ago
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."
deleted 10y ago
[deleted]
ctack 10y ago
This article is the stuff of Imposter Syndrome nightmares.
atomical 10y ago
Who is the professor?
jonaldomo 10y ago
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.
pipio21 10y ago
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.
kelvin0 10y ago
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.
at-fates-hands 10y ago
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.
gbvb 10y ago
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. :)
0xdeadbeefbabe 10y ago
So, I ought to beware of those plan9 guys, eh?
rurban 10y ago
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.

255 points by beekums 10y ago

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.

mixmastamyk 10y ago
> My favorite developers ever all do badly in your typical stringent Silicon Valley interview... My life story, sniff.
guitarbill 10y ago
> 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.

crispytx 10y ago

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

flukus 10y ago
That's possible, but if the code is sitting there for years without bugs then it is doing positive work.
jerf 10y ago
What's your point exactly?
- Ace17 10y ago
  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").

userbinator 10y ago

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.

sna1l 10y ago
+1 to this. I used to work with a guy like that and it created a ton of tech debt. He would write new services using a new technology for each one, not to documenting or maintaining any of them.
- Yhippa 10y ago
  What's sad is that it looks great on his or her resume to do that. That developer might leave a trail of carnage but they don't care--on to the new shiny job for them. It never catches up.
  - firebones 10y ago
    While I agree with you, who is in control there? Who lets the developer pick the tech and leave a trail of carnage? Neomaniacs gonna succumb to neomania. The bigger question is why the system permits that, rather than steer those urges to try something new into useful experiments that might advance the status quo.
  - Spivak 10y ago
    I can't really blame developers for this -- they're just responding to incentives. So long as hiring managers penalize candidates that don't have experience with trendy stacks then your actively doing your employees a disservice by prohibiting them. The only thing I can perosnally do to combat this problem is be conscious of it, not engage in that kind of hiring behavior in my office, and hope that the culture changes. Giving employees opportunities for side projects helps somewhat. Allowing for gradual migrations to new technologies helps as well.

rokosbasilisk 10y ago

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.

thescribe 10y ago
This is a good counter-argumnent to the frequent article decrying whiteboard tests.
- beekums 10y ago
  I feel like whiteboarding is really essential when talking about how code should be written, but most whiteboard tests are about writing code on the whiteboard. There's a big difference between the two activities.
  - pryelluw 10y ago
    Good point. The whiteboard should be used to discuss the problem and the solution. Not the actual code.
- tensor 10y ago
  How does a whiteboard test speak to documentation and code quality? By definition pseudo code is not production code and writing production style documented and compiling code on the whiteboard sounds like a terrible idea.
- ryhamz 10y ago
  Only if you assume it actually works, which is the most blatantly circular logic in this thread. This guy could have said "I feel like a daily prayer in the server room would filter bad devs" and it would be just as proven as his feeling about whiteboarding.
  - rokosbasilisk 10y ago
    maybe if prayer required some coding ability

dankohn1 10y ago

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.

arcticbull 10y ago
Sometimes they are in politically privileged positions and you can't get rid of them, ask me how I know.
- trustfundbaby 10y ago
  How do you ... know?
  - notwhereyouare 10y ago
    while I'm not arcticbull, I worked for a period of time with somebody who was a minority and completely horrible at their job. Everytime my boss tried to get him fired, HR pushed back
    - Spooky23 10y ago
      Solution is easy there -- promote away.
      - Karunamon 10y ago
        Please no. That might get them out of your hair (maybe), but then you've just put someone incompetent in a position where they can exercise it even further. I think people doing this is the direct cause of some head-scratchingly awful middle managers I've had to deal with..
        falsedan 10y ago

stevehiehn 10y ago

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?

greglindahl 10y ago
A developer on a fast growth curve generally responds well to corrective action: hey, let's work together to make you a winner in our environment, instead of the person whose bugs are caught by your coworkers. I've had successes and failures trying this strategy.
rokosbasilisk 10y ago
I work as a contractor for a bunch of local businesses and I think I can safely say, companies absolutely hate taking that kind of risk. A bad developer or hire can produce bad work, be an hr nitemare and also destroy team dynamics.
jerguismi 10y ago
Really difficult to know. Employees are about the most difficult investment there is.
flukus 10y ago
Unless the are in a junior/graduate position then they are probably not on a fast growth curve.

tyingq 10y ago

"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 10y ago
This seems strange to me as well. How were they planning/tracking the work that needed to be done for their project?
- falsedan 10y ago
  More questions: where were the code reviews and testing to show that this work should have shipped?

maus42 10y ago

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.

edblarney 10y ago

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!

agentultra 10y ago

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.

taeric 10y ago
To be fair, many debugging tool chains are crap with folds and maps instead of loops. And code is rarely written in anger, but often debugged that way.
- agentultra 10y ago
  Isn't that the truth! Debugging can bring out the worst in the best of us. Luckily I don't often have to debug code from functional programmers. The errors are usually mitigated by design and often easier to spot or reason about than in a function with a dozen branches mutating the object behind a pointer. The reason I call it a double-edged sword is because the majority will determine what is normal or acceptable. If you come to their office expecting to reveal the shadows on the wall you may very well find yourself looking for another office elsewhere. The harrowing difficulty is in bridging the gaps between each other and our differing approaches to developing software.
  - oselhn 10y ago
    You can write functional code with dozens of branches too. In my opinion this is because functional programmers are usually enthusiasts and good programmers. If all programmers start to write functional code you will hate it too.

benjaminRRR 10y ago

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.

jasonlotito 10y ago

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 10y ago
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 10y ago
  I'm honestly not sure what you mean here. I can't make sense of it.
  - d_rwin 10y ago
    Thanks Jason. It is a little vague, I admit. The team strength in any scope or structure, well defined is 'A Win'.
plorkyeran 10y ago
Producing a lot of code which has to be reviewed without ever actually landing any of it is itself a non-positive contribution. Code reviews are wonderful and I'd never want to go back to working on a team that didn't do them, but they do take time from the reviewers.
- jasonlotito 10y ago
  That's true, though I was specifically focused on actual code contributions that make it into a production branch.

ianbicking 10y ago

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 10y ago
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.
lolc 10y ago
Thanks for verbalizing the unease I felt after reading the article. I would have been unable to express it so well.

gumby 10y ago

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 10y ago
> 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.
- joeguilmette 10y ago
  It's a balance you need to run. But as a PM, spaghetti fixers are indeed very nice to have around. Keeping an eye on technical debt is important though.
  - flukus 10y ago
    The hardest part isn't the technical debt, it's detecting when spaghetti fixers are actually adding features to the product.
    - joeguilmette 10y ago
      This is another great point. Our support team is directly linked to a spaghetti fixer, this is great bc bugs are squished instantly. But sometimes a new checkbox appears and that is a real problem.

alphanumeric0 10y ago

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.

sriram_iyengar 10y ago

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

analog31 10y ago

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.

Insanity 10y ago
This is pretty much how I feel about it as well. Sometimes you'll deal with a more complex system where bugs might creep in even for an experienced developer, that then end up needing bugfixes for a week to come. Yet you might also write code that does it's job great (mostly) without bugs a week later.
skylark 10y ago
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.
runevault 10y ago
I've known people who created negative work. Back when the economy was tanking in 2008 into 2009, we fired 3 developers at my job, the rest of us ended up getting more work done than we did when also having to deal with the work of those 3. One of the 3 you could argue about, but the other two 100% caused extra work from having to clean up after them regularly. At least one of which was somehow a senior developer and the other was either dev or senior so neither had the excuse of being new/junior devs, and had been around for a few years by that point so they had time to learn.

beejiu 10y ago

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".

matt_wulfeck 10y ago

> 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 10y ago
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.

dreamcompiler 10y ago

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

mschuster91 10y ago

> 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...

joshuaNathaniel 10y ago

> 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.

d--b 10y ago

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.

sextus_prop 10y ago

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.

lordnacho 10y ago

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 10y ago
I work in finance and I've seen the same thing happen. I guess it's more common than people realise.
- deleted 10y ago
  [deleted]
- deleted 10y ago
  [deleted]
arvin 10y ago
> 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. The Dunning–Kruger effect in action.
adekok 10y ago
> 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. Which is why it's important for managers to understand the technology that they're managing. I ran into this 25 years ago. I knew someone who went to an MBA school. He spoke up at a party and said "I now have great management skills and can manage anyone!". My response was "No, because when you have a technical disagreement in the team, as manager, you have to make the final decision. And if you don't understand the issues, you're left deciding based on what, popularity of the engineers involved?"

ThePhysicist 10y ago

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 10y ago
> 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 10y ago
  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.

Chris2048 10y ago

> 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 10y ago
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 10y ago
  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.

ashish_b 10y ago

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?

partycoder 10y ago

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.

GoToRO 10y ago

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.

ArkyBeagle 10y ago

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."

deleted 10y ago

[deleted]

ctack 10y ago

This article is the stuff of Imposter Syndrome nightmares.

atomical 10y ago

Who is the professor?

jonaldomo 10y ago

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.

pipio21 10y ago

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.

kelvin0 10y ago

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.

at-fates-hands 10y ago

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.

gbvb 10y ago

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. :)

0xdeadbeefbabe 10y ago

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

rurban 10y ago

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.