undefined | Better HN

0 pointstabtab6y ago0 comments

It's a matter of economics of the labor pool. Companies often want high-skilled developers on the cheap, and then act surprised when they can't actually find any at their offer level (or they have poor people/team skills). Nor do they often want to pay and/or wait for training. Maybe there is a good reason they do that but from our techie perspective can't see. Unless you walk a mile in an owner's shoes, it's hard to say. Either way, they probably won't change this pattern, and thus one should code for a lower common denominator. We can't re-code the world.

0 comments

2 comments · 1 top-level

TeMPOraL6y ago· 1 in thread

> Either way, they probably won't change this pattern, and thus one should code for a lower common denominator.

Why? Unless they get push back from the HR/upper management, it's the tech team that makes this decision, in big part by setting expectations and minimum accepted competence level. It's thus the technical team that can change this pattern, by not making itself to code to the lowest common denominator, by setting standards, by embracing perpetual learning as part of the job.

Setting an appropriately high bar for both ourselves and our future teammates is part of the job too. Our non-technical bosses ain't gonna to do this for us - how could they? They don't have the necessary technical expertise; they depend on us to provide it.

tabtabOP6y ago

There is the theory that 5 highly skilled developers can do the job of 10 average developers, but in practice this often doesn't pan out. I'm not saying it never works, but it just doesn't seem to be a sure-shot strategy.

Part of the reason is that "soft skills" such as getting along with the team, writing well, understanding likely user behavior and the domain, making smart trade-offs, etc. also matter, and often times the technically "elite" lack these. Software development should be viewed as making tools for humans, not really for machines, and understanding humans is part of this.

Regarding your debugging edit: If one wants to spread the use of functional, perhaps finding a making a good guide and tutorial on debugging it would be helpful. I seem to be applying my imperative debugging thinking to it, and it doesn't fit well. I need to overhaul my debugging mind, not just my code mind.