Beware of Developers Who Do Negative Work

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

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.

Yet you might also write code that does it's job great (mostly) without bugs a week later.

I get that HR might need to verify that this person is being fired for the right reason and that no discrimination is in play (which might happen unwittingly), but just keeping someone employed because they are a minority is not a good solution.

On a related note. If I was a minority, I would think that I was just being hired or kept on the team because I am a minority and not for my technical ability. This behaviour from HR would further encourage that thinking.