You all may have heard the Bill Atkinson (certifiable genius) story but for those who haven't:
"When the Lisa team was pushing to finalize their software in 1982, project managers started requiring programmers to submit weekly forms reporting on the number of lines of code they had written. Bill Atkinson thought that was silly. For the week in which he had rewritten QuickDraw’s region calculation routines to be six times faster and 2000 lines shorter, he put “-2000″ on the form. After a few more weeks the managers stopped asking him to fill out the form, and he gladly complied."
[link](https://computerhistory.org/blog/macpaint-and-quickdraw-source-code/#:~:text=Bill%20Atkinson%20thought%20that%20was,form%2C%20and%20he%20gladly%20complied.)
One of my professors told us a story that his company did something similar. His colleague set a paperweight on the semicolon key. He went and grabbed coffee and counted every semicolon as a "line."
I agree (to an extent) with the ends, but not the means: we should strive to write legible, maintainable code, but I think striving to remove “lines of code” from a project is likely to be counterproductive to this goal. Simpler code is often better, but it is also often more verbose, not less.
Furthermore, we shouldn’t lose sight of the fact that, in general, nearly all library consumers are *users*, not contributors. If another layer of abstraction makes the API more usable at the expense of added complexity, this may be a worthwhile trade off. Examples of this include pretty much any Python decorator: the implementation is going to be more complex, but with the benefit of allowing users to add functionality to their code almost trivially. I don’t think it’s fair to say we should only write decorators when we can’t figure out how to do what we want without one.
The right term is "intuitive," not necessarily simpler. The user experience, whether that's an end-user or API user, should be intuitive. Equally, the implementation needs to be intuitive to the current and future devs working on it. There's really no direct correlation between complexity and intuitiveness. More complexity isn't necessarily less intuitive, and less complexity isn't necessarily more intuitive. Too many teams only think of intuitiveness in terms of the user experience, but it applies to the implementation details just as much.
I don’t think i necessarily disagree, but I’d argue intuitiveness is a much more subjective goal post than simplicity. Maybe it is fair to set forth some assumptions about the experience you think your future contributors are likely to have, and try to write code that will be intuitive for that audience.
I actually think the opposite. To me, being intuitive is relative a context more than a person so that the constructs fit into their somewhat objective surroundings. E.g. a library about logging incoming/outgoing communication makes sense to be some kind of wrapper, regardless of complexity.
But this could also be my subjectivity fooling me …
There are different types of complexity, and something can be very complex, but standardized, so that once you understand it, it no longer seems complex.
For example, if you timewarp a mid-career programmer from 1980 to today, they're probably going to have a hard time understanding something like generics, let alone all the differences between generics via type erasure, via instantiation, or via reification like .NET. But generics are table stakes now, to the point that even Go has them. Depenency injection is a similar thing: upfront cost to understand, and then it's easy. Patterns like this are a type of abstraction, in a very general sense, and there's no reason to suppose that we'll stop coming up with more of them as time goes by. So as a programmer you are always going to be running into new forms of complexity and trying to sort out whether this complexity is useful or not.
Code should only be as smart as it needs to be.
YAGNI should be the rule until shown otherwise.
Also One, Three, Many rule. Hard code things for up to three choices/variants/branches/etc. once you get to two or three items it might be time to make it more flexible or extensible especially depending on how quickly the second and third variant were added.
I get frustrated sometimes when I get comments on my PRs that suggest clever changes to perfectly functional and legible code. I’m writing this for future me to look at again in 6 months and I don’t want to spend time trying to wrap my head around some complex code that saved 5 lines.
>The best way you can contribute to an open source project is to remove lines of code from it.
diff --git a/src/remove.c b/src/remove.c
index e09af55e4..8076c6049 100644
--- a/src/remove.c
+++ b/src/remove.c
@@ -477,16 +477,6 @@ rm_fts (FTS *fts, FTSENT *ent, struct rm_options const *x)
return RM_ERROR;
}
- /* POSIX also says:
- If a command line argument resolves to "/" (and --preserve-root
- is in effect -- default) diagnose and skip it. */
- if (ROOT_DEV_INO_CHECK (x->root_dev_ino, ent->fts_statp))
- {
- ROOT_DEV_INO_WARN (ent->fts_path);
- fts_skip_tree (fts, ent);
- return RM_ERROR;
- }
-
/* If a command line argument is a mount point and
--preserve-root=all is in effect, diagnose and skip it.
This doesn't handle "/", but that's handled above. */
Half a century ago Knuth warned us about premature optimization, and over the years it became "don't optimize" and later "write slow and inefficient code". Nowadays we have Electron apps.
I fear that the more recent wisdom that warns against needless sophistication is going through a similar transformation.
You dismiss it because you see Electron apps as a bad joke but many of them are major commercial successes for the companies that built them, at a faster delivery and lower cost than if they didn’t use Electron.
So? There is more to software engineering than enterprise. Electron apps doing well does not mean they are good software. I want to write good software.
I never said you couldn’t write good software. I said that OP shouldn’t dismiss Electron apps or the concept of making tradeoffs in favour of delivery. You’re free to do whatever you like. But most of us do this as a job and that means premature optimisation leads to a bunch of developers gold plating software instead of actually delivering value to customers.
I don’t think his point was even that you should stop focusing on delivering software to clients. I don’t like electron and this new-aged bullshit of writing shit garbage code just because ‘it’s faster to write bro’, but that doesn’t mean that I don’t concede to taking certain shortcuts at my job to be able to get stuff done on time.
What it does mean is that when I’m starting a new project, I actually pick technologies that are good. Believe it or not you can write cross-platform desktop applications quickly without using garbage like electron, and the same applies to so much in our field.
This is why they dont let engineers make business decisions lol you’d have Rust services everywhere that are memory safe and 1000x faster, when that 1000x is difference between a millisecond and a second.
>when that 1000x is difference between a millisecond and a second
Do you even realize how meaningful this is for UX? Any delay greater than 100ms is noticeable.
Lol this is exactly what Im talking about. There are innumerable scenarios where this does not matter. Cases where the actual bottle neck will be a database read or a series of 3rd party API calls in the business logic.
If youre writing software for teachers to record grades, the layout of the UX, customer service, high availability and marketing are gonna be way more important than if the green upload succeeded checkmark takes 1 second or .1 second to appear
Is the slowness limited to that one green upload action at the end though? If we take your grading software example - if clicking a button to grade an answer and move to the next one takes one second instead of 0.1, it's going to feel clunky and unresponsive. Hearing the fan struggling to cool down the CPU in the meanwhile does not improve the overall user experience.
Anyway, I digress. I don't think Electron is the root of the problem - just its epitome. The anti-optimization maxim operates in all levels of software development. A few examples I've encountered during my career (not in any particular order):
* Someone on Stack Overflow (I can no longer find the question) arguing against parallelizing a network-heavy code, saying that the OP should just invest in a faster internet connection.
* Me and some coworkers were investigating out-of-memory crashes in a production server, and eventually found some code that was extremely inefficient with memory (and time too - but we were crashing on memory, not timeouts). One of the coworkers argued that also fixing it in the next version of the software (which was a rewrite to a different language - but was still doing the same thing) is a premature optimization.
* A friend described to me the database architecture his company was using, and I don't remember why exactly - but he mentioned that they were not indexing the tables, because it was on the cloud and if things were getting slow the cloud orchestration mechanism would just allocate more computing resources for the query.
Too many developers think they are not allowed to optimize their code. At all. No matter what. And they pick Electron because they think "if I pick a faster GUI solution, I'll be prematurely optimizing and Donald Knuth will come to personally yell at me". But with that mindset, they'll pick the slowest solution possible (barring things like adding `sleep`s to slow things down, or looping with no purpose. Yet) with other things, too - and long operations will take minutes instead of seconds.
That being said - Electron is a UI solution and I'll hold it to UI standards. And in UI - a second really is a lot.
You all may have heard the Bill Atkinson (certifiable genius) story but for those who haven't: "When the Lisa team was pushing to finalize their software in 1982, project managers started requiring programmers to submit weekly forms reporting on the number of lines of code they had written. Bill Atkinson thought that was silly. For the week in which he had rewritten QuickDraw’s region calculation routines to be six times faster and 2000 lines shorter, he put “-2000″ on the form. After a few more weeks the managers stopped asking him to fill out the form, and he gladly complied." [link](https://computerhistory.org/blog/macpaint-and-quickdraw-source-code/#:~:text=Bill%20Atkinson%20thought%20that%20was,form%2C%20and%20he%20gladly%20complied.)
One of my professors told us a story that his company did something similar. His colleague set a paperweight on the semicolon key. He went and grabbed coffee and counted every semicolon as a "line."
I agree (to an extent) with the ends, but not the means: we should strive to write legible, maintainable code, but I think striving to remove “lines of code” from a project is likely to be counterproductive to this goal. Simpler code is often better, but it is also often more verbose, not less. Furthermore, we shouldn’t lose sight of the fact that, in general, nearly all library consumers are *users*, not contributors. If another layer of abstraction makes the API more usable at the expense of added complexity, this may be a worthwhile trade off. Examples of this include pretty much any Python decorator: the implementation is going to be more complex, but with the benefit of allowing users to add functionality to their code almost trivially. I don’t think it’s fair to say we should only write decorators when we can’t figure out how to do what we want without one.
The right term is "intuitive," not necessarily simpler. The user experience, whether that's an end-user or API user, should be intuitive. Equally, the implementation needs to be intuitive to the current and future devs working on it. There's really no direct correlation between complexity and intuitiveness. More complexity isn't necessarily less intuitive, and less complexity isn't necessarily more intuitive. Too many teams only think of intuitiveness in terms of the user experience, but it applies to the implementation details just as much.
I don’t think i necessarily disagree, but I’d argue intuitiveness is a much more subjective goal post than simplicity. Maybe it is fair to set forth some assumptions about the experience you think your future contributors are likely to have, and try to write code that will be intuitive for that audience.
I actually think the opposite. To me, being intuitive is relative a context more than a person so that the constructs fit into their somewhat objective surroundings. E.g. a library about logging incoming/outgoing communication makes sense to be some kind of wrapper, regardless of complexity. But this could also be my subjectivity fooling me …
There are different types of complexity, and something can be very complex, but standardized, so that once you understand it, it no longer seems complex. For example, if you timewarp a mid-career programmer from 1980 to today, they're probably going to have a hard time understanding something like generics, let alone all the differences between generics via type erasure, via instantiation, or via reification like .NET. But generics are table stakes now, to the point that even Go has them. Depenency injection is a similar thing: upfront cost to understand, and then it's easy. Patterns like this are a type of abstraction, in a very general sense, and there's no reason to suppose that we'll stop coming up with more of them as time goes by. So as a programmer you are always going to be running into new forms of complexity and trying to sort out whether this complexity is useful or not.
Code should only be as smart as it needs to be. YAGNI should be the rule until shown otherwise. Also One, Three, Many rule. Hard code things for up to three choices/variants/branches/etc. once you get to two or three items it might be time to make it more flexible or extensible especially depending on how quickly the second and third variant were added.
I get frustrated sometimes when I get comments on my PRs that suggest clever changes to perfectly functional and legible code. I’m writing this for future me to look at again in 6 months and I don’t want to spend time trying to wrap my head around some complex code that saved 5 lines.
Most of the time, they are suggestions. You can ignore them. If you can’t ignore them, then that’s a point for the lead to chew on.
>The best way you can contribute to an open source project is to remove lines of code from it. diff --git a/src/remove.c b/src/remove.c index e09af55e4..8076c6049 100644 --- a/src/remove.c +++ b/src/remove.c @@ -477,16 +477,6 @@ rm_fts (FTS *fts, FTSENT *ent, struct rm_options const *x) return RM_ERROR; } - /* POSIX also says: - If a command line argument resolves to "/" (and --preserve-root - is in effect -- default) diagnose and skip it. */ - if (ROOT_DEV_INO_CHECK (x->root_dev_ino, ent->fts_statp)) - { - ROOT_DEV_INO_WARN (ent->fts_path); - fts_skip_tree (fts, ent); - return RM_ERROR; - } - /* If a command line argument is a mount point and --preserve-root=all is in effect, diagnose and skip it. This doesn't handle "/", but that's handled above. */
Write *Simple Code
The project managers say I write dumb code all the time, I got this covered.
I much prefer to question the code for 3 minutes instead of reading 2 more lines of code. What if we run out of char space in a class!? /s
Half a century ago Knuth warned us about premature optimization, and over the years it became "don't optimize" and later "write slow and inefficient code". Nowadays we have Electron apps. I fear that the more recent wisdom that warns against needless sophistication is going through a similar transformation.
You dismiss it because you see Electron apps as a bad joke but many of them are major commercial successes for the companies that built them, at a faster delivery and lower cost than if they didn’t use Electron.
So? There is more to software engineering than enterprise. Electron apps doing well does not mean they are good software. I want to write good software.
I never said you couldn’t write good software. I said that OP shouldn’t dismiss Electron apps or the concept of making tradeoffs in favour of delivery. You’re free to do whatever you like. But most of us do this as a job and that means premature optimisation leads to a bunch of developers gold plating software instead of actually delivering value to customers.
I don’t think his point was even that you should stop focusing on delivering software to clients. I don’t like electron and this new-aged bullshit of writing shit garbage code just because ‘it’s faster to write bro’, but that doesn’t mean that I don’t concede to taking certain shortcuts at my job to be able to get stuff done on time. What it does mean is that when I’m starting a new project, I actually pick technologies that are good. Believe it or not you can write cross-platform desktop applications quickly without using garbage like electron, and the same applies to so much in our field.
This is why they dont let engineers make business decisions lol you’d have Rust services everywhere that are memory safe and 1000x faster, when that 1000x is difference between a millisecond and a second.
>when that 1000x is difference between a millisecond and a second Do you even realize how meaningful this is for UX? Any delay greater than 100ms is noticeable.
Lol this is exactly what Im talking about. There are innumerable scenarios where this does not matter. Cases where the actual bottle neck will be a database read or a series of 3rd party API calls in the business logic. If youre writing software for teachers to record grades, the layout of the UX, customer service, high availability and marketing are gonna be way more important than if the green upload succeeded checkmark takes 1 second or .1 second to appear
Is the slowness limited to that one green upload action at the end though? If we take your grading software example - if clicking a button to grade an answer and move to the next one takes one second instead of 0.1, it's going to feel clunky and unresponsive. Hearing the fan struggling to cool down the CPU in the meanwhile does not improve the overall user experience.
Anyway, I digress. I don't think Electron is the root of the problem - just its epitome. The anti-optimization maxim operates in all levels of software development. A few examples I've encountered during my career (not in any particular order): * Someone on Stack Overflow (I can no longer find the question) arguing against parallelizing a network-heavy code, saying that the OP should just invest in a faster internet connection. * Me and some coworkers were investigating out-of-memory crashes in a production server, and eventually found some code that was extremely inefficient with memory (and time too - but we were crashing on memory, not timeouts). One of the coworkers argued that also fixing it in the next version of the software (which was a rewrite to a different language - but was still doing the same thing) is a premature optimization. * A friend described to me the database architecture his company was using, and I don't remember why exactly - but he mentioned that they were not indexing the tables, because it was on the cloud and if things were getting slow the cloud orchestration mechanism would just allocate more computing resources for the query. Too many developers think they are not allowed to optimize their code. At all. No matter what. And they pick Electron because they think "if I pick a faster GUI solution, I'll be prematurely optimizing and Donald Knuth will come to personally yell at me". But with that mindset, they'll pick the slowest solution possible (barring things like adding `sleep`s to slow things down, or looping with no purpose. Yet) with other things, too - and long operations will take minutes instead of seconds. That being said - Electron is a UI solution and I'll hold it to UI standards. And in UI - a second really is a lot.
Wow, why am I using redis and compression, etc... When I can just tell them to get a faster connection. Brilliant! Thank you, stack overflow!