3 ms·

One point I’d like to add which a lot of people disagree with is that we should all focus on writing simple and easy to understand code. Enigineers shouldn’t wo

One point I’d like to add which a lot of people disagree with is that we should all focus on writing simple and easy to understand code. Enigineers shouldn’t worry too much about optimizing code unles there is a good reason to do so. I’d say about 1% of my code has ever required me to return and optimize it.(I usually write apis that are utilized by end user apis). Most of the time my code is more than fast enough and user concerns are more around bugs related to requirements. In the few cases I have had to optimize its usually been a super obvious problem. For instance there was a Scala API that looped over a list of lists and called the Scala built in find function. That function is linear and incredibly slow I just converted the first list into a hashmap took a call that took 30 seconds to under 3 seconds still slow but order of magnitudes faster. It’s usually been silly stuff like that. All of this of course depends on the domain you are working in some applications require you to squeeze out every millisecond in which case most of this won’t apply to you.

jackmott 9y ago
>.(I usually write apis that are utilized by end user apis). When that is the case you need to think long and hard about performance, because it needs to not just be fast enough for you, on your machine, but on any conceivable end users machine, for any conceivable end users idea of what responsive enough performance is, for any conceivable end uer's work load, which might be vastly different or larger than anything you intended. further I don't think it is always the case that faster code is less simple. Often the faster option is more simple. Avoiding unnecessary complexity is often a win for performance too, and understanding memory locality and how the garbage collector work allows you to make smarter default choices which often have no net impact on simplicity
pvg 9y ago
One point I’d like to add which a lot of people disagree with is that we should all focus on writing simple and easy to understand code. Enigineers shouldn’t worry too much about optimizing code unles there is a good reason to do so. A lot of people don't disagree with this. It's the basis of one of the most-repeated programming adages ever, with its own 40+ year literature of talmudic interpretations, guided meditations and contrarian-yet-ultimately-supportive takes.
- Shorn 9y ago
  I want to write a bot that analyzes all of the Stack Overflow posts by Brian Goetz(https://stackoverflow.com/users/3553087/brian-goetz https://stackoverflow.com/users/3553087/brian-goetz) and count every time he's responded to "Should I...." / "Which is better/faster..." questions with "just write the code that is simplest and easiest to read". It must be in the hundreds by now.
userbinator 9y ago
we should all focus on writing simple and easy to understand code That is an optimisation. I've found that the simplest solution is usually the most efficient.
- virgilp 9y ago
  This is a good-sounding statement, so it "feels true". But, if you stop to really think about it... It's probably false in most circumstances [1] [1] If by "efficient" you mean time-efficient. If you pick your own efficiency metric, then yes, sure, I guess so...
- mnm1 9y ago
  "I've found that the simplest solution is usually the most efficient." If this was true, we'd all be using bubble sort and searching databases without indexes, row by row. I can think of very few algorithms or even situations where this is true.

jackmott 9y ago

>.(I usually write apis that are utilized by end user apis). When that is the case you need to think long and hard about performance, because it needs to not just be fast enough for you, on your machine, but on any conceivable end users machine, for any conceivable end users idea of what responsive enough performance is, for any conceivable end uer's work load, which might be vastly different or larger than anything you intended. further I don't think it is always the case that faster code is less simple. Often the faster option is more simple. Avoiding unnecessary complexity is often a win for performance too, and understanding memory locality and how the garbage collector work allows you to make smarter default choices which often have no net impact on simplicity

pvg 9y ago

One point I’d like to add which a lot of people disagree with is that we should all focus on writing simple and easy to understand code. Enigineers shouldn’t worry too much about optimizing code unles there is a good reason to do so. A lot of people don't disagree with this. It's the basis of one of the most-repeated programming adages ever, with its own 40+ year literature of talmudic interpretations, guided meditations and contrarian-yet-ultimately-supportive takes.

Shorn 9y ago
I want to write a bot that analyzes all of the Stack Overflow posts by Brian Goetz(https://stackoverflow.com/users/3553087/brian-goetz https://stackoverflow.com/users/3553087/brian-goetz) and count every time he's responded to "Should I...." / "Which is better/faster..." questions with "just write the code that is simplest and easiest to read". It must be in the hundreds by now.

userbinator 9y ago

we should all focus on writing simple and easy to understand code That is an optimisation. I've found that the simplest solution is usually the most efficient.

virgilp 9y ago
This is a good-sounding statement, so it "feels true". But, if you stop to really think about it... It's probably false in most circumstances [1] [1] If by "efficient" you mean time-efficient. If you pick your own efficiency metric, then yes, sure, I guess so...
mnm1 9y ago
"I've found that the simplest solution is usually the most efficient." If this was true, we'd all be using bubble sort and searching databases without indexes, row by row. I can think of very few algorithms or even situations where this is true.