Hacker News new | ask | show | jobs
by thinkersilver 3120 days ago
That's a pretty big 'if', though. Hiring good people is difficult. Having bad people is more common and that may be the justification for methodologies.

They don't exist to make good people more productive but to make mediocre hires marginally productive.

2 comments

That is a very astute observation and I do agree with it. I would argue though, that a lot of mediocre people are actually very smart, but have been trapped under micromanagement all their lives. As a result, they constantly expect to be told what to do. They have the ability to think cogently, but believe it imprudent to do so. I've hired a couple of "non-performers" in my firm from corporates, and once they've been thrown in the deep end a couple of times, they're actually pretty productive.

To be honest, my own senses were numbed by being a yes-man at a corporate job. My job title made it sound like I ran the world, but much of the work I was made to do was simply idiotic. And I was very happy to toe the line because it was easy, you could always spread blame and I didn't have to think much. Then I realised I have a limited amount of time on this planet and decided to do something more useful with my time...

I feel like this actually explains a surprising amount of things that look silly at face value.

Another example I've talked a lot with my colleagues is company wide coding style definitions. They usually have stuff like "never ever use goto", but then you have Linux kernel code using goto, and it seems all weird. But here too the coding convention that feels "stupid" to the rockstar coder is in place to make the code of the summer intern even remotely usable after they are gone.

Not that it is implied but it isn't just the "summer intern" that needs some coding convention guidance sometimes. It can be as useful as coming onto a project and at least you have some chance at (mentally) parsing the code/project without a huge melting pot of styles across all parts of the project (you'll obviously still get some but with convention you at least start from a slightly better place).
Goto is often used in assembler and low level C code that essentially mocks assembler, but spaghetti for procedural and OOP styles.

I actually found a goto in a C# project I took over this year and one of the first things I did was change it to a while loop with a break.

goto is used in pure c code as a substitute to exceptions, to prevent unnecessary repetition of the resource deallocation code. Even in C++ code, it is often way faster than exceptions. Goto is not scary.
The point is that exceptions should be used for exceptional cases only.

Most situations (e.g., early returns) for which resource management would be handled by a goto are already addressed by RAII.