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.
Yes, I was reading that blog and trying to hear the voice of the frustrated junior dev who is blamed for everybody else's poor communication, who is not being supported and who is used as a scapegoat for the company's wider problems (structure, feedback, planning). Someone who spends their days wondering where it went wrong, why no-one is willing to work with them and thinking about how fast can they get out of there.
This article reeks of bullying, passing the buck and misplaced egos, imo. The solution provided is focused on how to avoid hiring 'problem' employees, unfortunately nothing about how to cope with the situation once it has arisen. People can change after the hiring process due to personal reasons, death, divorce, all sorts of things. The author's company does not sound like a good place to work staffed with nice people.
I think calling a developer 'awful' is rarely accurate.
If that developer has only ever made two contributions to the project, then obviously that developer isn't in the right mindset to make useful contributions. I find that when I switch to part-time on a project, my performance degrades. Producing good code requires that you understand the existing code REALLY well (and that implies that you have to spend a lot of time just reading it) - If you don't understand the existing code really well, then you cannot produce good work.
One of the worst things I keep witnessing is managers rushing new employees into finishing tasks quickly - This is really bad because new employees don't understand enough about the code to be productive; when you rush them, you essentially force them to implement dirty hacks which will end up costing way more in the medium and long term.
Most managers don't like to pay engineers to lean/understand stuff - They want to pay for code that works. Engineers should be treated more like managers and less like office cattle.
I've seen so many horrible managers in this industry and they always get away with it by blaming the engineers.
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.
I have dealt with the "negative work" conundrum myself and just wanted to give some insight from my point of view on your comment.
1) It isn't always junior level programmers causing the negative work. When it is a junior level programmer, you are 100% correct that part of the blame (or MOST of the blame) falls on the lead/senior programmer. The lead/senior failed the junior without the appropriate structure, code review, etc to make their code maintainable and "healthy". Happened to me just this year and I let down one of the junior engineers on the team in a massive way and it showed.
2) What happens in the scenario that a senior/lead person is the one creating the negative work? Adding more oversight/tighter feedback loops constrains this person and will make them worse off than not. Anyone can make the argument that this person should not be a lead or a senior, but due to any number of business alterations (organizational changes, leadership changes, culture changes, etc) it is 100% a plausible scenario. What do you do then? How do you manage this piece of the puzzle?
Scenario 2 is where I have seen the most "negative work" created without finding optimal paths for fixing the issues at hand.
You are right but I also can understand his 'influential developer' negativity effect. In my place there's this one influential developer (the Team Lead) that can veto every decisions even though the others juniors/seniors under him already have consensus. He doesn't want the existing process to be altered. Now he's alone as everyone is leaving.
Have you ever had to deal with a bad worker, though? In one company where I was a tech lead we had a guy who did nothing. When I assigned him work, he turned in garbage that someone else had to re-do (often me, working at home). He would go out to his car after lunch and get stoned and then come back in and fall asleep at his desk!
On paper, the team had four developers, in reality, there was only three. It was a huge headache trying to explain to PMs and other managers why our team didn't really have the bandwidth it appeared to have.
I therefore complained to our manager about this guy. The response was long in coming and when it finally arrived, we were to place the non-worker on an "improvement plan" which was mandated by HR. That means I had to work even harder now because I had to put together said plan and basically try to micro-manage this guy while also re-doing all his code. The improvement plan didn't work. His output was just as bad as always. This went on and on for months. Mercifully, the guy was finally let go after almost a year of dicking around.
All of this somehow reflected badly on me, however! My manager didn't like that I "made waves" in the company by requiring this guy to do work. He also didn't like having to smooth over all the ruffled feathers among the other teams who couldn't understand why we were always behind schedule.
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.
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.
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.
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).
> 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.
> 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.
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.
Danger with this is people recommend based on friendship & personal gain as much as competence.
You can end up with mini guilds of ~5 people, who know each other well, and help each other with their career by recommending each other as they migrate from company to company.
Seen this happen twice now. At my current company, someone joined the devops/infrastructure team, then brought 4 over from his network at his previous company. Most are competent, but one seriously isn't, and he's protected by his cabal, who now dominate the team. He's a 'senior' engineer to boot!
> I've seen plenty of people who can reverse binary trees or fizzbang
That's the tests for entry level programmers who are 16-22: It's the basics for writing code (that could be learnt alone with a computer), it doesn't require to have had a programming jobs or to have maintained software in the long term in production.
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.
There is a lot of value in conforming to however the existing code base is written. Some of the worst (in terms of time/money spent maintaining) code I've seen is code that sticks out for being different, even if it's arguably faster / more modern / uses better practices. Some C++ examples because that's in my wheelhouse:
1. Entire code base is "C with classes" or OO, but That One Guy on the team insists on sprinkling functional programming constructs all over the place. Now there's a huge overhead for the rest of the team who need to switch gears every time they encounter that code.
2. That One Guy who insists on doing everything with macros in a code base that otherwise makes very light use of the preprocessor.
3. Company standardized on using the C++ constructor to initialize classes, but That One Guy writes a seperate init() method on each of his classes and leaves the constructors empty.
4. (iOS/Objective-C example) Entire code base uses old-school delegate callbacks but That One Guy needs to write all his stuff using the arguably better block style.
It could be even as silly as:
5. Entire code base uses camelCase for variables and function names, but That One Guy insists on using_underbar_style. Now every time you have to call something or pass a variable around you have that tiny bit of overhead double checking which style needs to be used.
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.
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.
Are you suggesting that all functional code is readable/more readable? It has its merits for sure, but I have seen many functional monstrosities... some that have even caused plenty of negative work themselves!
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.
> 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?"
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.
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.
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.
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.
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".
> 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...
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.
> 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".
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?
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.
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?
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. :)
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.
> 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.
[+] [-] ThePhysicist|9 years ago|reply
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.
[+] [-] kagamine|9 years ago|reply
This article reeks of bullying, passing the buck and misplaced egos, imo. The solution provided is focused on how to avoid hiring 'problem' employees, unfortunately nothing about how to cope with the situation once it has arisen. People can change after the hiring process due to personal reasons, death, divorce, all sorts of things. The author's company does not sound like a good place to work staffed with nice people.
[+] [-] jondubois|9 years ago|reply
If that developer has only ever made two contributions to the project, then obviously that developer isn't in the right mindset to make useful contributions. I find that when I switch to part-time on a project, my performance degrades. Producing good code requires that you understand the existing code REALLY well (and that implies that you have to spend a lot of time just reading it) - If you don't understand the existing code really well, then you cannot produce good work.
One of the worst things I keep witnessing is managers rushing new employees into finishing tasks quickly - This is really bad because new employees don't understand enough about the code to be productive; when you rush them, you essentially force them to implement dirty hacks which will end up costing way more in the medium and long term.
Most managers don't like to pay engineers to lean/understand stuff - They want to pay for code that works. Engineers should be treated more like managers and less like office cattle.
I've seen so many horrible managers in this industry and they always get away with it by blaming the engineers.
[+] [-] guitarbill|9 years ago|reply
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.
[+] [-] phereford|9 years ago|reply
1) It isn't always junior level programmers causing the negative work. When it is a junior level programmer, you are 100% correct that part of the blame (or MOST of the blame) falls on the lead/senior programmer. The lead/senior failed the junior without the appropriate structure, code review, etc to make their code maintainable and "healthy". Happened to me just this year and I let down one of the junior engineers on the team in a massive way and it showed.
2) What happens in the scenario that a senior/lead person is the one creating the negative work? Adding more oversight/tighter feedback loops constrains this person and will make them worse off than not. Anyone can make the argument that this person should not be a lead or a senior, but due to any number of business alterations (organizational changes, leadership changes, culture changes, etc) it is 100% a plausible scenario. What do you do then? How do you manage this piece of the puzzle?
Scenario 2 is where I have seen the most "negative work" created without finding optimal paths for fixing the issues at hand.
[+] [-] erkaes|9 years ago|reply
[+] [-] Clubber|9 years ago|reply
[+] [-] kelvin0|9 years ago|reply
https://www.amazon.ca/Extreme-Ownership-U-S-Navy-SEALs/dp/12...
I recommend the read to anyone working within teams of people.
[+] [-] chrisabrams|9 years ago|reply
That is a very constructive way at looking at things; I think I'll try this out with my team :)
[+] [-] hash-set|9 years ago|reply
On paper, the team had four developers, in reality, there was only three. It was a huge headache trying to explain to PMs and other managers why our team didn't really have the bandwidth it appeared to have.
I therefore complained to our manager about this guy. The response was long in coming and when it finally arrived, we were to place the non-worker on an "improvement plan" which was mandated by HR. That means I had to work even harder now because I had to put together said plan and basically try to micro-manage this guy while also re-doing all his code. The improvement plan didn't work. His output was just as bad as always. This went on and on for months. Mercifully, the guy was finally let go after almost a year of dicking around.
All of this somehow reflected badly on me, however! My manager didn't like that I "made waves" in the company by requiring this guy to do work. He also didn't like having to smooth over all the ruffled feathers among the other teams who couldn't understand why we were always behind schedule.
Stupid, bad management is to blame, not me.
[+] [-] userbinator|9 years ago|reply
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.
[+] [-] ianbicking|9 years ago|reply
[+] [-] throwaway1892|9 years ago|reply
So that's another layer of variation to take into account.
[+] [-] lolc|9 years ago|reply
[+] [-] gumby|9 years ago|reply
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|9 years ago|reply
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.
[+] [-] matt_wulfeck|9 years ago|reply
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|9 years ago|reply
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.
[+] [-] walrus1066|9 years ago|reply
You can end up with mini guilds of ~5 people, who know each other well, and help each other with their career by recommending each other as they migrate from company to company.
Seen this happen twice now. At my current company, someone joined the devops/infrastructure team, then brought 4 over from his network at his previous company. Most are competent, but one seriously isn't, and he's protected by his cabal, who now dominate the team. He's a 'senior' engineer to boot!
[+] [-] user5994461|9 years ago|reply
That's the tests for entry level programmers who are 16-22: It's the basics for writing code (that could be learnt alone with a computer), it doesn't require to have had a programming jobs or to have maintained software in the long term in production.
[+] [-] agentultra|9 years ago|reply
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.
[+] [-] ryandrake|9 years ago|reply
1. Entire code base is "C with classes" or OO, but That One Guy on the team insists on sprinkling functional programming constructs all over the place. Now there's a huge overhead for the rest of the team who need to switch gears every time they encounter that code.
2. That One Guy who insists on doing everything with macros in a code base that otherwise makes very light use of the preprocessor.
3. Company standardized on using the C++ constructor to initialize classes, but That One Guy writes a seperate init() method on each of his classes and leaves the constructors empty.
4. (iOS/Objective-C example) Entire code base uses old-school delegate callbacks but That One Guy needs to write all his stuff using the arguably better block style.
It could be even as silly as:
5. Entire code base uses camelCase for variables and function names, but That One Guy insists on using_underbar_style. Now every time you have to call something or pass a variable around you have that tiny bit of overhead double checking which style needs to be used.
[+] [-] woah|9 years ago|reply
[+] [-] taeric|9 years ago|reply
[+] [-] cx1000|9 years ago|reply
[+] [-] lordnacho|9 years ago|reply
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.
[+] [-] adekok|9 years ago|reply
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?"
[+] [-] soVeryTired|9 years ago|reply
[+] [-] arvin|9 years ago|reply
The Dunning–Kruger effect in action.
[+] [-] d--b|9 years ago|reply
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|9 years ago|reply
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|9 years ago|reply
My guess is that most of us have our positive and negative moments, and hopefully the positives outweigh the negatives.
[+] [-] maus42|9 years ago|reply
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|9 years ago|reply
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|9 years ago|reply
And the context implies those were the only 2 changes/check-ins. Seems odd that nobody questioned the low output.
[+] [-] mschuster91|9 years ago|reply
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|9 years ago|reply
[+] [-] Chris2048|9 years ago|reply
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|9 years ago|reply
[+] [-] stevehiehn|9 years ago|reply
[+] [-] flukus|9 years ago|reply
[+] [-] greglindahl|9 years ago|reply
I've had successes and failures trying this strategy.
[+] [-] rokosbasilisk|9 years ago|reply
A bad developer or hire can produce bad work, be an hr nitemare and also destroy team dynamics.
[+] [-] jerguismi|9 years ago|reply
[+] [-] ashish_b|9 years ago|reply
[+] [-] gbvb|9 years ago|reply
[+] [-] hibikir|9 years ago|reply
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|9 years ago|reply
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.
[+] [-] mixmastamyk|9 years ago|reply
My life story, sniff.