3 ms·

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

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.

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.