3 ms·

It is counterproductive to cripple the programmers on your team who can handle abstraction to avoid confusing the ones who can't. Why turn 10x coders into 9x co

It is counterproductive to cripple the programmers on your team who can handle abstraction to avoid confusing the ones who can't. Why turn 10x coders into 9x coders or worse just to retain your 1x coders? Or work with the ones having trouble with a pattern until they get it?

steven777400 11y ago
That's the management decision in the article. And I make the same decision. We're not an organization that attracts nor hires rockstars (or, as you say, 10x coders). We have a couple really sharp folks but are predominately staffed by "1x" coders. Therefore, it is important and the responsible thing to do to write all code so that it can be understood and maintained by a 1x coder. Even if it is being written and currently maintained by one of our sharper folks, people move on or change roles, and projects shift to other staff for long term maintenance. Who's going to be maintaining this project in 2-4 years? This project needs to be written with them in mind.
- Jtsummers 11y ago
  I have to ask, where do you draw the line? I had a team lead that disliked me writing things like (in C#, been a bit so forgive errors): List<AClass> original; // perhaps as a parameter to the function List<AClass> filtered = original.Where(x => x.Field > 10); Arguing that I should instead have just used for loops (showed him foreach and he agreed that that was better, at least) like: List<AClass> filtered = new List<AClass>(); foreach(x in original) if(x.Field > 10) filtered.Add(x); Ok, so it's only two lines longer (three if you split the if and its effect, 5 if you also add in braces, 7 if you put opening braces on their own lines). The `Where` version is not that complicated, and only requires understanding one (potentially) new concept for programmers, namely anonymous functions. Wouldn't the briefer, but still clear, code be preferable for maintenance?
  - steven777400 11y ago
    Yes absolutely. I don't say "no functional constructs" nor does anyone else here that I know of. However, composite LINQ statements, especially involving aggregation can and do become confusing. Obviously it's a judgment call but in many cases, breaking out a complex expression into incremental, imperative steps can and does make it clearer. The "rule" I apply is "code should be written primarily for people to read and only incidentally for machines to execute" which, although very subjective, provides a good foundation for everyone to start from.
st3v3r 11y ago
Why would avoiding "map" suddenly decrease the ability of your coders? It's not like writing out the equivalent loop takes that much time.
- pklausler 11y ago
  It's easier for a bug to slip in, like an off-by-one error, when one chooses to write a loop rather than invoke a well-tested abstraction that hides the loop, leading to more time spent later in the development process debugging and fixing the problem.
balamaci 11y ago
Yeah, code that anyone can read is so overrated. PS: Sarcasm.

steven777400 11y ago

That's the management decision in the article. And I make the same decision. We're not an organization that attracts nor hires rockstars (or, as you say, 10x coders). We have a couple really sharp folks but are predominately staffed by "1x" coders. Therefore, it is important and the responsible thing to do to write all code so that it can be understood and maintained by a 1x coder. Even if it is being written and currently maintained by one of our sharper folks, people move on or change roles, and projects shift to other staff for long term maintenance. Who's going to be maintaining this project in 2-4 years? This project needs to be written with them in mind.

Jtsummers 11y ago
I have to ask, where do you draw the line? I had a team lead that disliked me writing things like (in C#, been a bit so forgive errors): List<AClass> original; // perhaps as a parameter to the function List<AClass> filtered = original.Where(x => x.Field > 10); Arguing that I should instead have just used for loops (showed him foreach and he agreed that that was better, at least) like: List<AClass> filtered = new List<AClass>(); foreach(x in original) if(x.Field > 10) filtered.Add(x); Ok, so it's only two lines longer (three if you split the if and its effect, 5 if you also add in braces, 7 if you put opening braces on their own lines). The `Where` version is not that complicated, and only requires understanding one (potentially) new concept for programmers, namely anonymous functions. Wouldn't the briefer, but still clear, code be preferable for maintenance?
- steven777400 11y ago
  Yes absolutely. I don't say "no functional constructs" nor does anyone else here that I know of. However, composite LINQ statements, especially involving aggregation can and do become confusing. Obviously it's a judgment call but in many cases, breaking out a complex expression into incremental, imperative steps can and does make it clearer. The "rule" I apply is "code should be written primarily for people to read and only incidentally for machines to execute" which, although very subjective, provides a good foundation for everyone to start from.

st3v3r 11y ago

Why would avoiding "map" suddenly decrease the ability of your coders? It's not like writing out the equivalent loop takes that much time.

pklausler 11y ago
It's easier for a bug to slip in, like an off-by-one error, when one chooses to write a loop rather than invoke a well-tested abstraction that hides the loop, leading to more time spent later in the development process debugging and fixing the problem.

balamaci 11y ago

Yeah, code that anyone can read is so overrated. PS: Sarcasm.