Beware of Developers Who Do Negative Work - <AUTHOR> http://blog.professorbeekums.com/2016/12/beware-of-developers-who-do-negative.html <comment><USER2> 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.

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

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

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

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

<comment><USER4> Of course there are developers who bring problems to projects.

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

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

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

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

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

</comment></comment></comment></comment></comment></comment><comment><USER5> _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.

<comment><USER6> This is definitely true on both ends.

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

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

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

<comment><USER8> Logic in the Database has the following issues:

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

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

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

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

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

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

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

and a whole lot more.

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

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

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

<comment><USER9> All of that apart from 5 is totaly wrong

<comment><USER10> What's the solution for source controlled database logic?

<comment><USER11> What's the problem with source controlled database logic?

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

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

<comment><USER13> I don't understand what's hard about mass-overwriting your previous stored procedures with new ones.

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

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

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

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

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER15> 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.

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

</comment></comment><comment><USER17> 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).

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

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

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

<comment><USER21> What is this reasoning?

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

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

<comment><USER23> So, the question that makes the difference should whether he writes blog for himself or for his readers?

[replace "blog" by "code"]

<comment><USER22> Anyone can read their blog! Since anyone can learn Latin, if they feel like it.

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

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER24> > _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.

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

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

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

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

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

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

<comment><USER25> That CS fundamentals and programming are easy to teach is a myth that keeps being perpetuated and I don't understand why.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

</comment></comment></comment></comment></comment></comment></comment><comment><USER26> 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.

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

<comment><USER28> > that they don't pay attention to writing simple, good code.

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

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

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

<comment><USER29> > The negative contribution developers I find are those that don't challenge > the formulation of the problem.

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

</comment></comment></comment></comment><comment><USER30> 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.

<comment><USER31> I work in finance and I've seen the same thing happen. I guess it's more common than people realise.

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

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

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

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

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

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

</comment><comment><USER32> 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.

</comment><comment><USER33> 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.

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

</comment></comment><comment><USER35> 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_.

</comment><comment><USER36> 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".

</comment><comment><USER37> _" 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.

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

<comment><USER22> More questions: where were the code reviews and testing to show that this work should have shipped?

</comment></comment></comment><comment><USER39> > 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...

</comment><comment><USER40> 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.

<comment><USER18> CI does nothing to prevent bad developers checking in bad code. You just end up with equally poor unit tests.

<comment><USER41> True. Code reviews and standards are the tools to use in this case.

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

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

</comment></comment></comment></comment></comment><comment><USER42> > 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".

<comment><USER43> The unwritten assumption is the influential dev. had less say so with the streamlined process which thereby would reduce their power in the company.

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

</comment></comment></comment><comment><USER44> 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?

<comment><USER18> Unless the are in a junior/graduate position then they are probably not on a fast growth curve.

</comment></comment><comment><USER45> 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?

</comment><comment><USER46> 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. :)

</comment><comment><USER47> 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.

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

</comment></comment><comment><USER48> 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.

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

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

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

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

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

</comment></comment></comment></comment><comment><USER51> 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.

</comment><comment><USER52> 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.

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

1 - proper onboarding

2 - standardized code

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

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

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

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

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

</comment><comment><USER53> 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.

</comment><comment><USER54> 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.

</comment><comment><USER55> 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.

</comment><comment><USER56> 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."

</comment><comment><USER57> 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.

</comment><comment><USER58> 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.

</comment><comment><USER59> This article is the stuff of Imposter Syndrome nightmares.

</comment><comment><USER60> 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.

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

</comment><comment><USER62> So, I ought to beware of those plan9 guys, eh?

</comment><comment><USER63> I'm surprised developers still do this in an era of 'frequent commits'

</comment><comment><USER64> 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!

</comment><comment><USER65> > 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.

</comment><comment><USER66> Who is the professor?

</comment><comment><USER67> Maybe these developers that produce "negative work" think your code sucks. Ever consider that?

<comment><USER68> What's your point exactly?

<comment><USER69> 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").

</comment></comment></comment><comment><USER70> 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.

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

<comment><USER70> I'm honestly not sure what you mean here. I can't make sense of it.

<comment><USER71> Thanks Jason.

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


Ask HN: Stock trading company that was hiring Hadoop Engineers in NYC? - <AUTHOR>

About a year ago, a firm was hiring Hadoop engineers in NYC. The company had no clients and was involved in stock trading. There were no prescribed hours, generous pay, excellent benefits.
I've tried numerous searches on Google, through my browser histories, etc and haven't turned up anything.
Can anyone recall that company's URL? <comment><AUTHOR> It was <http://www.janestreet.com/></comment>


Evolutionary maths [2007] - <AUTHOR> http://plus.maths.org/content/evolutionary-maths

<comment><USER2> Unfortunately, I do not have access to Klessinger, Szczerbinski, Varley, 2007, the publication mentioned.

I have a suspicion, though, that this research would be much more productive if the researches had deeper understanding of philosophy, especially of mathematics and language, and subjects such as symbolic logic and model theory.

Few years passed since my last studies in this area, and I have practically no neuroscience knowledge, but the simplest bet would be to say that the operator/verb example are just special cases of the relationship between objects.

The bootstrapping process might be explained by the fact that in mathematics we encounter purer form of this mechanism. In case of language, there might be much more distractions, making it harder to muscle this one particular area.

</comment><comment><USER3> Churnalism pops up again, its proverbial ugly head once again raised for the cliches, its existence in this article thoroughly destroying its validity right down to its core assumptions, so that nothing remains to rise from its ashes.

How long has it been since the "Amazonian tribe that cannot count" has been refuted? What is the name of this "Amazonian tribe?" How did the anthropologist hear of the existence of this tribe? How did he contact with it? How long did he study with it? How many people did it claim before it was made extinct by logging operations?

So many other questions that I'll bet could not be answered because that damned "Amazonian tribe that can only count in binary" never existed.

<comment><AUTHOR> The book "Here's Looking at Euclid" (entitled "Alex's adventures in Numberland" in the UK) by Alex Bellos documents a conversation with Pierre Pica, currently investigating the Pirahã in the Amazon, a tribe that apparently has no interest in counting, and appear not to be able to count accurately:

<http://news.ycombinator.com/item?id=2210392>

Copyright seems to have expired on the excerpt that was in the Guardian, but it's pretty well discussed in this recent book.

You can find much of Pica's work on-line if you choose. Here is one reference:

<http://www2.cnrs.fr/en/319.htm>

In short, I'm unconvinced that this is sheer and pure "churnalism," or that the Amazonian tribe that cannot count" really has been refuted.

ADDED IN EDIT:

Alex's book is here:

<http://www.amazon.co.uk/gp/reader/0747597162#reader-link>

and you can click on the "Search Inside" at left and search for "Pica."</comment></comment>


Amit Gupta needs you - <AUTHOR> http://amitguptaneedsyou.com/ <comment><USER2> _IGNORANCE:_

The concept of donating bone marrow terrifies me. I imagine a doctor drilling into my skeleton and using a large needle to suck out the gooey stuff that makes my blood. It sounds absolutely horrific.

If I were ever to consider doing this, someone would have to educate me to the point where my _perceived_ safety is high. Right now I know that this probably won't kill me, but I don't understand it enough to trust it. I imagine that I am not the only person in this situation.

I also felt terrible writing this. My fear is absolutely petty compared to the fear of being struck down by leukemia. Perhaps that's why I felt obligated to share.

<comment><USER3> Hi oconnore,

I'm an Acute Mylogenous Leukemia (AML) survivor and a Level 2 ambassador with the National Marrow Donor Program. I'd like to thank you for your honesty, as a lack of awareness (and the resulting fear) is one of the biggest obstacles the NMDP faces when trying to recruit donors. Your perspective really is something that I think a lot of people feel but don't necessarily share, and I commend you for having the courage to do so. It's a step in the right direction for finding the right means of educating the public.

I'll try to respond to some of your questions as best I can, but please keep in mind that I am not a doctor and while I have received volunteer training from the NMDP, any thoughts expressed in this post are my own.

Your bone marrow is the mechanism in your body that generates blood cells. Blood is composed of a few different parts -- red blood cells, white blood cells, platelets and plasma. Red blood cells carry oxygen throughout the body, plasma is the liquid, platelets help in clotting to prevent bleeding and white blood cells act as the carriers of the body's immune system.

What happened with me (and likely with Amit) is that at some point a mutation occurred within my bone marrow so it began generating malformed white blood cells. Instead of behaving like a normal immune system these mutated cells did nothing but fill up my blood stream, inhibiting the growth and transport of normal white blood cells and platelets. As a result I began to get progressively sicker, with bruising appearing over my body. As you can imagine this situation gets very dangerous very quickly, as doctors told me that if I hadn't gone into the ER when I did I ran the risk of bleeding in my brain while walking to class.

Chemotherapy was used to effectively kill off all aspects of my blood -- white blood cells, red blood cells, platelets included. The hope here was for chemo to wipe out as much as it could in hopes of eliminating all traces of cancer in my bone marrow. Due to the human body's natural resiliency, after chemo eventually the bone marrow would start to regenerate. The hope was that after this regeneration happened no cancer cells would be reproduced.

For me, it was a waiting game: undergo chemo, wait to see if cancer reappeared. I did this six times (2 inductive rounds, 4 consolidation rounds). Thankfully after those first two rounds I was in the clear. I've been in remission for a little over four years now, and I still go into the doctor for regular blood tests.

While I'm not exactly sure of the medical reasons why bone marrow transplants are needed, I do know that a very simplistic view of them is that they're necessary when chemotherapy is not enough. Whether it's because the chemotherapy is ineffective or specific DNA markers or whatever, there are times when the body's natural bone marrow is no longer effective in producing normal blood cells. It's a dangerous procedure for the recipient (because of the possibility of the body rejecting the transplant) but it's not considered in circumstances where other viable alternatives exist. It really is something of a last resort.

For donors, joining the registry is painless and extremely simple. The NMDP asks you to check against a preliminary health screening ([http://www.marrow.org/Join/Medical_Guidelines/Medical_Guidel...](http://www.marrow.org/Join/Medical_Guidelines/Medical_Guidelines_for_Joining_the_Registry.aspx)), understand the commitment (<http://marrow.org/Join/Your_Commitment.aspx>), and fill out a form with some medical/contact information to make sure that you can be contacted in the event of a match. I read a statistic that less than 50% of those currently within the registry (1) can be contacted successfully and (2) are willing to donate once a match is found. (<http://www.ij.org/about/2903>) The form asks for your contact information and the contact information of two others who do not live with you, just in case you happen to move elsewhere at a later date. The NMDP takes privacy very seriously, and will not solicit you or others with the contact information you provide.

The form comes with a swab kit consisting of four cotton swabs. These swabs are processed by the NMDP to match donors and recipients by specific DNA markers. To register, you simply swab the inside of your cheek with each swab, for 20 seconds each. Put the swabs back into the kit and then they're sent off for processing. That's it; a form and four cheek swabs.

A donor's commitment when joining the registry is to be on the registry until they're 61, although they can remove themselves from the registry at any time.

Given the specific DNA markers used to match donors and recipients, realistically the chances are that you will never be called to donate marrow. According to the FAQ here (<http://amitguptaneedsyou.tumblr.com/faq>), the NMDP puts the odds at 1 in 540.

If you do one day receive a call to be a donor, there are currently two main methods of bone marrow donation. The first, Peripheral Blood Stem Cell (PBSC) donation, is used in over 70% of cases and is described in detail here: [http://www.marrow.org/Registry_Members/Donation/Steps_of_Don...](http://www.marrow.org/Registry_Members/Donation/Steps_of_Donation.aspx#step2). Another good reference is this site: <http://helpingtami.org/asian_bone_marrow_and_pbsc.html>, which despite the cartoonish graphics, serves as a pretty accurate representation of what PBSC entails. You get a shot for a few days that kicks up your normal bodily process of bone marrow production into overdrive, to the point where bone marrow cells enter your bloodstream. You donate blood, after which bone marrow cells are irradiated out. The blood is then put back into your body. I've personally received the shot (called Neupogen) that is used to kick up your bone marrow production over 30 times, as it was used following each of my rounds of chemo. A common side effect of the drug is that it makes you a bit achy and sore, as if you had gone on a long hike the day before. I did not feel any significant discomfort on neupogen to the point where I couldn't go about my day as normal.

The other procedure is extracting bone marrow from your hip bone, which is performed under general anaesthetic. It is also depicted on the helpingtami.org link above. 30% of bone marrow donations are performed this way, and I believe it's usually due to restrictions of the recipient. Receiving a bone marrow transplant can be extremely taxing on the human body, and if a patient is too young or old for PBSC a bone marrow extraction is requested in its place. Admittedly this process is more invasive, and as a result donors are put to sleep. Doctors use special, hollow needles to extract little bits of bone marrow from your hip, and because the needles are small it does require a lot of sticks to collect enough marrow for a transplant. I've also had this procedure done to me, albeit in a lesser volume -- it's the same process used to perform bone marrow biopsies. I was awake for the procedure both times and received local (vs. general) anaesthetic. Needles are needles so there was discomfort, but it was very quick -- like a hard pinch. Patients are sore for a few days afterwards, more so than PBSC, but recover quickly. Donors perform a full health scan before donating in the interests of their own well being as well as the patient, so if you're not healthy enough to donate and recover, you will probably not be allowed to get to that point in the first place.

When donors join the registry they commit to donating to anyone in need, not just the person the drive is in honor of. So although a local drive may be in honor of Amit, the power of the awareness being raised by the publicity of his sickness is that there are people who have never heard of Amit Gupta that will have their lives saved by his efforts, perhaps even decades from now. I know that Amit is a very important person in the technical community, but please remember that everyone who needs a donor is the most important person in the world to somebody -- a parent, a sibling, a child or a best friend. In that regard I believe that everyone who has someone in their life that they love more than themselves can empathize with what it must be like to be powerless to help that person in their time of greatest need.

Please consider joining the bone marrow registry. It truly is the opportunity to save someone's life.

<comment><USER4> I have been unable to donate blood because I take Avodart. Is this the same for donating bone marrow? I am 70 years old in good health and am a B+ blood type email@example.com

<comment><USER3> Hi waltl, unfortunately bone marrow registration is limited to donors between the ages of 18-60. Please see this page for more information: [http://www.marrow.org/Join/Medical_Guidelines/Medical_Guidel...](http://www.marrow.org/Join/Medical_Guidelines/Medical_Guidelines_for_Joining_the_Registry.aspx#Age). Thanks for your willingness to help!

</comment></comment></comment></comment><comment><USER5> Wow... unlike most things on the web, thanks for providing a way for non-USA people to get involved! <http://amitguptaneedsyou.tumblr.com/help-around-the- world>

</comment><comment><USER6> Who is Amit Gupta? That question doesn't seem to be answered on the site and the name isn't familiar to me.

<comment><USER7> A lot of people here say he is very well known in the community and he is a great person. My first question was why haven't those people stepped up. Maybe there is a matching issue, I don't know. If not then they should. I would have.

<comment><USER8> I have. He and I won't match, but I will with someone and I look forward to the opportunity to help someone in need.

<comment><USER7> Great person you are, Sir.

</comment></comment></comment></comment><comment><USER3> Hi all,

Long time reader but never posted before. If anyone here will be attending, I'll be manning the National Marrow Donor Program booth registering donors this Saturday, October 29 at TEDxMidAtlantic in Washington DC (<http://tedxmidatlantic.com/>). While the booth is intended to be in Amit's honor, I strongly encourage any minorities to join the registry, as the need is severe across all ethnic groups. I'm an AML survivor myself (though no BMT, chemo-only), and I can't emphasize enough that the decision to join the registry is opening yourself up to the opportunity to literally save someone else's life.

</comment><comment><USER9> Not that it will matter to the trolls, but it's worth noting:

The vast majority of championing for this cause is happening on behalf of Amit, not by Amit himself. He was actually quite reluctant to be public about his condition, and has only stepped forward at the encouragement of people close to him.

While Amit is at the center of this effort, the narrative has quickly widened to address the much larger issue of underrepresented populations in the bone marrow database. The impact of the efforts inspired by Amit's situation will be felt far beyond that of one person.

Even as he fights for his life undergoing intense chemotherapy and all kinds of difficulties most of us have no appreciation for, he continues to do the best he can to help people.

Anyone who does that deserves not just our respect and admiration, but our attention and participation.

If anyone feels like being self righteous, they might do well to channel that energy into doing something that helps the world instead of leaving insidious comments on a thread.

</comment><comment><USER10> I applied for a kit when I first heard about this, but the kit's been sitting on my desk for a couple days.

I just went ahead and did the swabbing. It was very simple, took only 2 minutes, and was completely non-invasive. (It was also completely free.)

If you haven't signed up yet, please do so. Even if you don't care about Amit (I have no idea who he is), you might be able to help someone else in need.

<comment><USER11> I did the same, but have not swabbed.

My primary concern is that of privacy. I don't really trust that a record of my DNA/swab test won't end up somewhere it's not supposed to be.

<comment><USER12> You leave DNA everywhere you go. Every time you sit in a chair, every time you drink from a cup, pee in a public urinal, open a door handle ... You give blood tests to your doctor, and don't demand to see the privacy policy of the lab and all the handlers in between.

You worry too much. :) No one wants your DNA - and if they wanted it they could easily get it. Take the test and possibly save a life.

Edited: to add a smiley face and improve the tone, since this was intended to be a "don't worry be happy" message and not "you're a bad human being". Sorry about that.

<comment><USER13> You might or might not be correct, but it's quite difficult to get your point across with that kind of a tone. Talking in favor of someone suffering from leukemia doesn't automatically grant you rights to spew personal insults at someone.

<comment><USER14> I didn't see any personal insults, mostly just logic delivered unapologetically.

<comment><USER13> I don't know when exactly the post was edited, but the version that was there when I replied did contain personal insults and had a much harsher tone.

Now it's turned out to have arisen from good intentions, so all is well.

</comment></comment></comment></comment></comment></comment><comment><USER15> I have registered for the test kit. I really appreciate the way amit and friends have set up the campaign. This gives maximum chance for him to survive and also helps other victims as well, since they might contact you if some one else needs help. Good luck Amit, I hope you will pull through it.

</comment><comment><USER16> There have been some great results in the news recently regarding CAR T cells in the treatment of Chronic Lymphocytic Leukemia. I think this one might be a winner.

<http://news.ycombinator.com/item?id=2873604>

<http://penncancer.org/cart-19>

From what I understand about this treatment, blood is removed from the patient and 'infected' with a harmless HIV virus that has been modified to attach a molecule to T cells. This molecule binds to a receptor (CD19) on the cancer cell, thereby creating T cells that attack the cancer cells. The treated blood is injected back to the patient and the patients body creates more of these cells on it's own- effectively creating an immune response to the cancer cells.

Do you think a subset of HN readers could somehow facilitate a project that could help the labs researching ( or planning on researching ) methods for expanding this method of treating cancer? I would like to ( and inspire people here to ):

1) find the available labs that can best perform the _steps_ required for this treatment _process_. Basically, get a list of labs.

2) help expedite iterative methods for techniques that: a) speed the development time of the specific _step(s)_, and/or b) broaden the efficacy of the overall treatment _process_ ( ie. treat other cancers ). Basically, list the _steps_ in the _process_ and see if there is a way to make them faster, better.

3) create tools that allow the people and labs working on this _process_ to communicate as efficiently as possible. Basically, learn how the different labs work and write tools that streamline their collaborative workflow.

I have a feeling there are many smart people on this site with free time ( ie. visiting this site often ), technical resources, and organizing skills that could make this happen- fast. Shoot me an email with questions/comments/complaints if you don't want to comment on this thread; I want to help.

</comment><comment><USER17> Does testing from the swab kits match you up with anyone in need of bone marrow? I have a coworker with leukemia too and I'm sure many others here know of similar situations and it'd be great to have a resource that works for everyone. Posting individual stories doesn't scale very well.

<comment><USER18> Yes, it enters you into the National Marrow Donor Registry. Posting individual stories works better than statistics because it motivates people _much_ more (yet another quirk of our psychology).

<comment><USER19> "A Single Death is a Tragedy; a Million Deaths is a Statistic"

</comment></comment></comment><comment><USER20> If South Asians are severely under-represented in the US bone marrow donor registry, can't we just buy bone marrow from donors in (say) India?

<comment><USER21> There are numerous ethical issues surrounding the commercial/free-market trade of human organs.

Most simply:

\- There is, naturally, demand for bone marrow transplants in India. What are the moral and ethical implications of denying someone there (of presumably lower economic ability) a transplant so they can supply someone in the US (of presumably much higher economic ability)? If they were swimming in an excess of willing donors, perhaps this would be less of an issue, but I don't know _any_ country in the world where there is a surplus of bone marrow donors.

\- What incentive structure does this create, and what does it mean for us if we legitimize commercial organ trade? How many donations will be voluntary, or will we see an explosion in "donations", forced upon the disenfranchised and vulnerable?

I'd be _very_ wary of walking down the path of commercialized organ trade.

<comment><USER22> Interestingly though, this isn't "organ" trade, because the resource in question is replenished by the body within a few weeks. So it isn't _really_ depriving anyone of anything to donate bone marrow.

</comment></comment></comment><comment><USER23> Call me paranoid, but can you use a slightly different name in the registry to keep the prying hands of the state off your voluntary DNA sample? Has there been any known cases of the police using this registry to obtain evidence for prosecutions?

</comment><comment><USER24> Hi, im working on a bone marrow drive for Amit in Chicago. If you want to help drop me an email (edit: I put my email in the profile).

<comment><USER25> Hi: HN doesn't support private messages, and it doesn't show your email address by default. If you want to let people message you, you have to explicitly put your email address in the about field in your profile (here: <http://news.ycombinator.com/user?id=inuhj> )

</comment></comment><comment><USER26> I joined one of the drives a week ago in New York. Swabbing your cheek is easy, filling out the form is easy, and even though the odds are I'm not a match for Amit, I may one day be the match for someone else.

From what I understand, the procedures for donation have gotten simpler and less invasive all the time. Giving up a day for the chance to save someone's life is an absolute no-brainer. Easiest decision I'll ever make.

Go get on the list.

</comment><comment><USER27> Does anyone have any updates on his search?

<comment><USER28> I have been monitoring this for a few weeks. No luck thus far (as of 10/24). Seth Godin has been a pretty big champion, though, and I think that helped really get the word out there.

</comment></comment><comment><USER29> I don't understand why blood, marrow, and organs have to be donated. I agree that the concept is discussing, but in a life and death situation people should be able to pay to "encourage" a donor.

Already there are a lot of people who go to third world countries to buy organs. If it was legal to buy organs people wouldn't have to risk the unsanitary operation condition.

Furthermore, seeing as giving blood or marrow is less dangerous there should be no reason not to allow people to buy them.

</comment><comment><USER30> I'm not in the US, and I'm a white Caucasian, so it won't be any help to Amit. But when the Australian Red Cross phoned me up this morning to set an appointment to donate blood I also told them I wanted to get registered as a bone marrow donor. Until yesterday, I had no idea they could now extract bone marrow cells via blood. Excellent timing on both the post and the phone call!

</comment><comment><USER31> Once someone with AML gets a marrow what does their 1 year prognosis look like? I computed cancer "yield" a year ago based on cancer data from the state of New York, and Leukemia is (unfortunately) a pretty devastating cancer:

[http://d0j.blogspot.com/2010/05/cancer-incidence-and- state-o...](http://d0j.blogspot.com/2010/05/cancer-incidence-and-state-of-new- york.html)

</comment><comment><USER32> I'm boring white western European, but signed up and should get my swab kit in 2 weeks. Maybe I can help someone else.

</comment><comment><USER33> Sad! I am south asian and I just tried to register - they refused to sign me up as I have had hepatitis B in the past. In India, this is so common that people don't even know they have had it (I came to know about it 10 years after having it). I just remember having 'jaundice' once.

<comment><USER34> If you've had jaundice as a kid in India, it was probably hepatitis A, in which case you are allowed to join. Probably worth double checking.

<comment><USER33> I came to know about it after 10 years because I went to a doctor in the US for some check up. Thanks for cross-checking though

</comment></comment></comment><comment><USER35> There will be a bunch of folks at FailCon in SF today. I encourage everybody to get a test.

</comment><comment><USER36> I know some other people on the list, and was looking at signing up, but got really annoyed that all the registries seem to demand a third party or multiple third party contact info in order to submit a sample.

<comment><USER37> They do this so that they have more ways to contact you if you are a match some day. Apparently not being able to contact matches, due to outdated contact info, is a big problem. Like, on the order of 50%. It's still annoying but at least it has a legit purpose.

</comment></comment><comment><USER38> Why not go to a good private hospital somewhere in South India.

Amit probably has a better chance of finding a matching donor there and the procedure, I'm assuming, is less expensive than over here.

</comment><comment><USER39> I just registered for a bone marrow match drive tomorrow at OSU. While I'm 100% sure I'm not a match for Amit, I hope that many people show up, and that I'm a match for someone.

</comment><comment><USER40> while i think the cause is great, i can't help but feel a little sad that it has taken this event to spur everyone in the community to a more philanthropic direction. many of us here are looking to become rich and successful and forget that in many ways, we are already very wealthy.

honestly, i think it's a good time to think of all the positive things we can do with what we have - including using our technical knowhow to make the world a better place for those less fortunate.

</comment><comment><USER41> Amit is a pal. One of the nicest guys you'll EVER meet. Period.

</comment><comment><USER42> Just got the wife's permission and signed up, wish us luck.

</comment><comment><USER43> Hope it works out for him.

</comment><comment><USER44> Isn't this a bit selfish?

</comment><comment><USER45> If this works out for him, it would be cool to see him champion other peoples' life-threatening needs as shamelessly as he's doing his own.

<comment><USER45> Sad to see my comment being downvoted because people disagree with it. The point that I was making was that he's shameless about his needs. Most people who have needs like his can't create this type of platform and exposure to be heard.

And it is shameless. Why do I care about amit gupta, and why are all his promotional materials centered around HIM, and not acute leukemia? People suffer every day who can't be heard like this, is it so wrong to bring up that uncomfortable fact?

To the people saying, "well what he's doing is good for others, too!" Yes, I agree. But face it, he never would've done this had he never got acute leukemia. So my original hope remains: "if this works out for him, it would be cool to see him champion other peoples' life-threatening needs." With him seeing the direct benefit of these efforts on his life, it would be cool if he maybe took it a step further and continued it for others.

<comment><USER46> You keep saying "shameless" as if it's exceptional in some way. Why should he feel shame about trying to not die?

<comment><USER45> shameless: 2\. done without shame; without decency or _modesty_

modesty: 1\. having or showing a moderate or humble estimate of one's merits, importance, etc.;

<comment><USER47> A) I think modesty no longer becomes a factor when you are desperately trying to save your own life.

B) Sure, the design is a little flashy (I think it looks great, by the way), but I don't think he is being terribly immodest. He's not bragging about his accomplishments, he's just trying to get people to sign up as bone marrow donors, and he's using his personal plight as motivation.

<comment><USER45> He's not morally wrong, I'm saying the nature of what he's doing is shameless. Clearly this is an important issue to him, but he's vastly overestimating his importance to everyone else. That's fine. I'm just calling it like I see it.

<comment><USER48> Adrew, really curious here, how would you go about if you were in his shoes?

<comment><USER45> If I was Amit, I would've included other sufferers in the campaign, instead of hoarding the attention all to myself. Many others could have benefited from this massive amount of exposure.

<comment><USER9> Everyone who gets swabbed is added to a national database and can be matched to anyone else who needs a donor.

The efforts happening on his behalf are, by and large, very consciously being done with this in mind. They are increasing awareness of underrepresented populations in the bone marrow database and making a much larger impact.

Also, these efforts are being coordinated and implemented by volunteers on Amit's behalf. Amit himself is not running this show. People who have better things to do than troll the internet are.</comment></comment></comment></comment></comment></comment></comment></comment></comment>


Five Tremendous Apple vs. Adobe Flash Myths - <AUTHOR> http://www.roughlydrafted.com/2010/04/10/five-tremendous-apple-vs-adobe-flash-myths/

<comment><USER2> Thrill as the corporate partisan sets up the straw men and then knocks! them! down!

Nobody serious is saying "Adobe's going to to get Apple" nor that "Apple owes Adobe" nor that "Apple has a legal obligation to support third parties" nor that Apple has a moral obligation to offer the choice. At the very least, these are not consensus arguments in the debates over Apple's new language restrictions and decision to not allow Flash.

Dilger really should link to examples of these opinions he purports to be exposing as myth; examples in serious posts by people with some credibility or skin in the game, not "some anonymous schmuck with a hotmail account" (as he calls his commenters.)

</comment><comment><USER3> I think people are forgetting how long it took to get Flash on Linux.

All platforms are beholden to Adobe to get Flash ported. As a business, Adobe can't support every OS and device that appears. Where's Flash for Android? Oh, it's coming...

HTML5/JavaScript is a more open technology and we finally have several good browsers. Most come with source! Today Java is even more open, and no one is complaining. You can download the source for Java, but you can't get the Flash source.

Apple is accelerating the adoption, and hopefully the evolution, of HTML5. In two years, perhaps even one, no one is going to miss Flash on the iPhone and iPad.

<comment><USER4> Apple absolutely does anything they can to avoid their platform being beholden to another vendor's technologies. Their execs have spoken on this several times; it's a key part of their strategy. They have a strong confidence that the results will be better if they take pervasive responsibility for their customers' experience. We'll see. Everything's a tradeoff.

It seems perfectly reasonable to me for developers to be wary or even turned off by Apple's tactics. But just as people complain about Apple hindering innovation with these moves, I think there's something to be said for somebody getting out there and trying out a different model [can "open systems" as a model be a monoculture?] than just putting out a platform and then disclaiming responsibility for how it's used. Not saying the results will necessarily be better, but for somebody to try a different model doesn't seem outrageous in a world where there are many intensely competing platforms. If Apple dominated mobile devices, it'd be much easier for me to see these moves as outrageous. As is, they're one option among many and as a result of their policies their platform has both unique benefits and drawbacks.

</comment></comment><comment><USER5> I haven't even heard of some of these Myths. "Apple owes Adobe a living"? "Adobe's gonna get Apple"?

I see consoles as a completely different topic. The iPhone allows any developer to sign up and develop (for example, that 9 year old kid that wrote some apps). I guess if Sony spent a huge amount of resources porting games to Xbox and Microsoft waited until a week before release to screw them over I'd hate Microsoft even more.

Furthermore, I don't like being lumped into the group that "seemed completely cool with Microsoft's reign over the entire PC market". It sounds like the author believes that everyone who disagrees with Apple's latest moves are brainless Adobe fanboys. I believe most developers (myself included) disagree with the ability to control the method of development rather than the output (review process). It also seems that Apple waited this long on purpose (days before CS5 release) - almost trying to screw Adobe over as much as possible. This screwed over countless developers.

</comment><comment><USER6> "Never mind that such accusations have never been thrown about when the subject was developing titles for the Xbox 360, Wii, PlayStation 3, or any other game console. Those developers must not only use the languages and tools the vendor outlines, but typically must also pay thousands of dollars for licensing fees, specialized development hardware, and jump through a variety of other hoops."

You have to pay for development kits, true, and you have to link with the standard libraries, but the language and tools you use aren't restricted.

All the TRCs/TCRs are outlined ahead clearly ahead of time and for the thousands of dollars you get support and a working dialogue between the developer and the platform holder.

</comment><comment><USER7> Could someone please turn on Erlang mode?

</comment><comment><USER2> Dilger sloppily conflates the two very distict arguments over Flash on the iPhone platform and the new restrictions that dictate the languages you may use when writing native apps for the platform. Unsurprisingly, as the former is a reasonable business decision, whereas the logic of latter remains controversial, regardless of the Adobe angle.

Frankly, in looking over his 2010 posts, Dilger seems to be little more than a foot soldier in General Gruber's PR backchannel army. There's precious little critical thought, and loads of partisan, fawning obeisance to All Things Jobs.

<comment><USER8> Which shows that you don't read Gruber much at all... He is positively scathing in his assessments of Dilger's various wacky theories. Dilger truly is an Apple fanboy - he has never to my knowledge, found a single fault in any Apple product, or business initiative.

Linking him to Gruber is a gross injustice to Gruber, who does actually criticize Apple when he feels that they have made a mistake.

</comment></comment><comment><USER9> Rather inflammatory article. Some good points, but he confuses Apple "supporting" languages with "banning" them. Big difference.

</comment><comment><USER10> Whoa, common sense _and_ a sense of recent history. Amazing...

</comment><comment><USER11> That article is flamebaiting bullshit. The title is correct but only ironically.

<comment><USER12> Can you elaborate on that?

<comment><USER11> ...it's complete bullshit? ;)</comment></comment></comment>