This point is particularly salient: "Either Comment Nowhere, or Comment Everywhere". It reminds me of people who highlight so much of the textbook that the unhighlighted words actually stand out.
I've been working on old SQL code written 10 years ago, and the original developer used comments as a way to track his to do list (e.g. --TO DO: fix this procedure). It's safe to say that stuff isn't going to get done.
That is more like a paper version of the "I select text when I'm reading it" behavior rather than a way to signify importance. I know some people who rage-close websites if they can't select text.
I don't consider you weird! But I do do this. I have a large screen and a wandering mind, so it helps me keep my place and thus read faster than if I don't highlight.
I do it pretty often, in fact I was doing it as I was reading GPs comment and had a good chuckle. It started out as a way to differentiate which line I was on in dense text since I have some vision problems and it just sort of become a habit.
Anecdote time: I do this, and I know it's weird. You just have to look around to see that almost nobody else does it (and it drives people I'm around nuts with the constant clicking).
I think it started in like 1998 when I was a kid using ancient slow browsers on tiny fuzzy monitors over dialup speed internet. I'd be in the middle of reading an article/forum/etc and something would make me lose my place, like a picture (finally) loading above, or trying to scroll at 7 fps and the page jumping way past where I was (I never trusted pgdn), and it would be quite the chore to find my place again. So I started selecting around where I was reading, especially before scrolling, just so I can easily find my place again and it just became a habit.
Now I'm using a giant WQHD monitor at 144 Hz using the fastest page renderer in the world (webrender), so I really don't have those excuses anymore, yet the habit remains. At this point it's probably more ADD and habit than anything else; if I'm not selecting text, I'm fidgeting with something, a pen, usb drive, etc.
I agree. Mine is mild, but having that hilight save the endpoint of my last thought for me to find when coming back to attention is hugely beneficial for me
I never really noticed that I do this. On paper books, I remember I didn't use a highlighter, but used to drag a pencil down the right margin, as I went through the page.
Every line is its own factory in its own class split across three different files. There are so many layers of abstraction that your codebase looks like a hall of mirrors.
Or you can be one of those guys who obsessively has to use every feature in C++, especially brand new ones that have shaky support across different compilers.
Look at the data??? Why would I do that?? While the feature I'm building isn't useful to me, I know exactly how I would use it if it was, so that's exactly how all my users are going to use it. Duh!
The "premature optimization is the root of all evil" thing is totally blown out of proportion. I think what they're saying is don't use that quote as a reason to write garbage slow code.
To me #5 is talking about the myth that surrounds premature optimization. That is - this idea that thinking through data patterns (or other basic aspects of code) early on is a waste of time. It's usually not.
Making the choice to work with collections that can be accessed in O(log n) rather than O(n^2) is a trivial optimization.
Maybe you don't need to scope out every subroutine, but taking the time to review the basic performance features is something we can all strive to do.
Several times I've heard novice programmers cite the "premature optimization" saw as an argument against doing things that weren't optimization at all. Handling edge cases correctly, for example, or throwing exceptions instead of returning incorrect results, or handling two input formats instead of one, or tolerating trailing whitespace on input.
"Optimization" means "making code run faster without changing what it does". If you're changing the code's behavior in an observable way, that's not optimization.
I think the author's point is that even if "premature optimization is the root of all evil" is true, that doesn't mean you write a naive, brute-force solution for every problem.
I think there is a difference between "premature optimization" and putting thought into what you are actually asking the computer to do when you write some code. You aren't hand unrolling loops and rewriting stuff in assembler on the first pass, you're thinking to yourself "doing it this way is going to require n! iterations, but if I restructure my internal data layout I can reduce it to n log n at the cost of only a few megabytes of memory."
The trick here is that you have to understand what each tool is doing before you use it, and that's the opposite of what computer languages are driving towards these days. There is a big push towards abstracting away the actual work, potentially so the compiler can apply optimizations under the hood, but this requires the programmer to either know tons of details about what the compiler does, or to trust it implicitly and hope they don't write code that is grossly inefficient. Or maybe what you do is grossy inefficient, but it can be automatically parallelized well so you don't notice it too much.
There’s a difference between abstaining from language features and writing things in obtuse ways “because performance,” vs. putting some thought into how the process is going to work and making reasoned choices.
The full Knuth quote: "We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%"
Keywords: small efficiencies.
How it's usually used: I shouldn't think about performance up front at all.
Counterpoint: small inefficiencies add up, ruining throughput and latency in a bigger codebase.
Nothing teaches this better than seeing code making thousands of ephemeral objects in Java in a heap profiler and getting GC stalls with no big place to fix.
To me, #5 is calling out developers that write sloppy, thoughtless and obviously inefficient code and then claim premature optimization when someone comments on the quality of that code.
I am getting a bit annoyed by holier than thou coding evangelists.
Writing good code is hard,
writing good tests is hard,
writing good docs is hard,
and even harder is writing code to do the right thing.
If someone has lots of exploratory code, trying out different approaches to a problem, maybe producing some performance comparisons, maybe exploring that weird API the other part of the company is offering, these are all valid reasons to not follow a prescriptive methodology.
Yes, having short iterations with working software as a deliverable is great.
Having close contact with your user base for fast feedback is great.
Having continuous integration so that at almost any point we can see genuinely where we are is great.
But honestly, after those three, which I think compare to "use memory managed languages" in the list of genuinely useful software engineering innovations (and let's face it, none of them are software but process, and they are all arguably the same thing - fast feedback loops) I struggle with the religious zeal for pair programming or other "must haves".
it's not they aren't sensible practises, but with a gun to your head, you need to carefully choose what to throw away.
Trying to simplify my argument:
There are no silver bullets left in the software pistol. we can make our code as sweet as we like but the value will come from building the right thing, not building the wrong thing in the right way.
So just strive to write code that _just_ accomplishes your objective.
> writing good tests is hard
So just write tests that are good enough to cover the code you've written.
> writing good docs is hard
So just write docs that are good enough to explain what's necessary to the audience for the doc.
I personally don't see the linked article as evangelical - but maybe that's because I'm brainwashed by the message it. But to me a 16 point list doesn't read at all like a silver bullet.
I agree with all of this, but none of the points in this post are evangelical, they are just things that should be always considered. You can then evangelize about how to achieve each point. You can follow every one of these (or rather, do the opposite of all of these) and still write awful code.
I know it is meant to be satirical, but the reality is there are trade-offs involved with each of these points. I don't think it is wise to treat any of them as absolute rules.
Maybe someone smarter than me could write about the trade-offs involved with each and when to break the rules.
65 comments
[ 309 ms ] story [ 1064 ms ] threadhttps://www.youtube.com/watch?v=4XpnKHJAok8&t=1339s
Edit: Now that I think about it, it isn't the re-writing I mind so much, it is the prospect of re-debugging
Yeah, it's a foreach loop. I remember my keywords.
# Set x to 1
x = 1
...not even kidding.
I don’t even highlight as I read, but I would close such a page out of principle.
(I am sure the people who do it consider those who don't weird!)
I think it started in like 1998 when I was a kid using ancient slow browsers on tiny fuzzy monitors over dialup speed internet. I'd be in the middle of reading an article/forum/etc and something would make me lose my place, like a picture (finally) loading above, or trying to scroll at 7 fps and the page jumping way past where I was (I never trusted pgdn), and it would be quite the chore to find my place again. So I started selecting around where I was reading, especially before scrolling, just so I can easily find my place again and it just became a habit.
Now I'm using a giant WQHD monitor at 144 Hz using the fastest page renderer in the world (webrender), so I really don't have those excuses anymore, yet the habit remains. At this point it's probably more ADD and habit than anything else; if I'm not selecting text, I'm fidgeting with something, a pen, usb drive, etc.
Highlighting text as I read helps me out when I'm having trouble focusing on the page.
Making the choice to work with collections that can be accessed in O(log n) rather than O(n^2) is a trivial optimization.
Maybe you don't need to scope out every subroutine, but taking the time to review the basic performance features is something we can all strive to do.
"Optimization" means "making code run faster without changing what it does". If you're changing the code's behavior in an observable way, that's not optimization.
The trick here is that you have to understand what each tool is doing before you use it, and that's the opposite of what computer languages are driving towards these days. There is a big push towards abstracting away the actual work, potentially so the compiler can apply optimizations under the hood, but this requires the programmer to either know tons of details about what the compiler does, or to trust it implicitly and hope they don't write code that is grossly inefficient. Or maybe what you do is grossy inefficient, but it can be automatically parallelized well so you don't notice it too much.
The problem begins where deadlines are too close to fix minor inefficiencies...
Keywords: small efficiencies.
How it's usually used: I shouldn't think about performance up front at all.
Nothing teaches this better than seeing code making thousands of ephemeral objects in Java in a heap profiler and getting GC stalls with no big place to fix.
Writing good code is hard,
writing good tests is hard,
writing good docs is hard,
and even harder is writing code to do the right thing.
If someone has lots of exploratory code, trying out different approaches to a problem, maybe producing some performance comparisons, maybe exploring that weird API the other part of the company is offering, these are all valid reasons to not follow a prescriptive methodology.
Yes, having short iterations with working software as a deliverable is great.
Having close contact with your user base for fast feedback is great.
Having continuous integration so that at almost any point we can see genuinely where we are is great.
But honestly, after those three, which I think compare to "use memory managed languages" in the list of genuinely useful software engineering innovations (and let's face it, none of them are software but process, and they are all arguably the same thing - fast feedback loops) I struggle with the religious zeal for pair programming or other "must haves".
it's not they aren't sensible practises, but with a gun to your head, you need to carefully choose what to throw away.
Trying to simplify my argument:
There are no silver bullets left in the software pistol. we can make our code as sweet as we like but the value will come from building the right thing, not building the wrong thing in the right way.
So just strive to write code that _just_ accomplishes your objective.
> writing good tests is hard
So just write tests that are good enough to cover the code you've written.
> writing good docs is hard
So just write docs that are good enough to explain what's necessary to the audience for the doc.
I personally don't see the linked article as evangelical - but maybe that's because I'm brainwashed by the message it. But to me a 16 point list doesn't read at all like a silver bullet.
- click-bait title
- authoritative tone
- devoid of insights or new information
- arguments that are either badly argued or blindingly obvious
“Classes less than 9000 LoC have to be combined and do not deserve their own file.”
“Method documentation is just because it is required. Contents can be just the method name.”
“Code reuse is king. If you need different functionality but share at least a field just override all methods and do not call base.”
“Just access the resources you need but don’t bother deaccessing, someone else can do that for you.”
“Method names are worthless, their IDE will suggest them anyway.”
“If you need new functionality but do not want to break the old just add another field and an if statement to enter a new code path.”
\\ cheesy US presenter voice \\ Today! in another episode of code reviews at the office!!
Disclaimer: love my job and my colleagues :)
Oof.
is way more common in my code than it should be.“If you refactor a method without increasing its cyclomatic complexity don’t bother sending for review.”
Unless this was cheeky sarcasm in which case you shouldn't replace the previous point just add this one.
Maybe someone smarter than me could write about the trade-offs involved with each and when to break the rules.
[1] https://github.com/Droogans/unmaintainable-code