4 ms·

> Programming isn't that hard if you just do it right. That's not a tautology. In fact, it's actually worth pointing out, especially to junior engineers who ge

> Programming isn't that hard if you just do it right. That's not a tautology. In fact, it's actually worth pointing out, especially to junior engineers who get frustrated by how hard everything is, that it actually doesn't need to be that hard if you, well, do it right. Obviously that's not productive feedback without actually helping them be better, but it's far from a tautology. For anyone wondering, a tautology is a statement that is logically true by construction, rather than contingently true because of the way the world is. For example, "Programming isn't that hard if it's easy" would be a tautology. Constructing a counterexample by changing programming to something else shows that this was not a tautology to begin with: "Sending a man to the moon isn't that hard if you just do it right," which is obviously false, because even if you do it right that's objectively difficult. Programming is hard, but we make it much harder than it has to be by doing it spectacularly wrong in many ways, both individually and collectively.

braythwayt 7y ago
I think that you are speaking of a logical tautology, while I am speaking of a linguistic tautology. If I am correct about this, we are both right. A logical tautology is, "A statement that is true by necessity or by virtue of its logical form." A linguistic tautology is, "A phrase or expression in which the same thing is said twice in different words." In formal debating, for example, you can call someone out for either type of tautology.
- inimino 7y ago
  Because we express logical statements in English, these two kinds of tautologies overlap. (If we were using a formal language we could express tautologies like !(A && !A) without using English.) If you say "All bachelors are unmarried", this is true both because of the meaning of the words, and because of the logical structure implied by the words. In either case, if you state a tautology, you state something which is true in all possible worlds, given the definitions of the words, at least. Someone can then call you out for stating a tautology, which is to state something that is vacuously true, that is, you've made a statement about the nature of reasoning itself, in any possible world, but you haven't said anything at all about the world we're actually in. So you're wasting your breath even though what you say is unassailably true. (Note that in mathematics, the tautologies are precisely the theorems with their premises or axioms! So this is by no means always useless.) The problem with calling out tautologies in common life, however, is that the danger of identifying a false tautology is very high. When someone says "Either X happened, or it didn't." you may be tempted to say "tautology!" but in fact they are probably making some kind of oblique point or highlighting a flaw in someone else's argument, etc. In other words, tautologies may be vacuous as statements about the world within a logical framework, but as speech acts in the real world, they always come with a motivation and that can usually be expressed in a non-tautologous way. For example, "A or not A" can be expanded charitably to "A or not A, and this is relevant to the topic at hand", which is not a tautology anymore. In this case, if you do something right, it's not extra hard, which is kind of a tautology. But there's a point in saying it, which is that it doesn't have to be that hard... if you do it right. And that's not true of everything or in every possible world, hence not a vacuous statement.
deleted 7y ago
[deleted]
MaxBarraclough 7y ago
> That's not a tautology. In fact, it's actually worth pointing out, especially to junior engineers who get frustrated by how hard everything is, that it actually doesn't need to be that hard if you, well, do it right But this boils down to If you build systems using a high level of skill and foresight, it's easy to do. This is of course not a tautology, but a contradiction. I agree that inexperienced developers can, as it were, 'make life hard for themselves', but that's (trivially) due to their inexperience. I don't think there's a silver bullet for inexperience. Over-engineering is bad, as is under-engineering. Fuzzy principles like 'YAGNI' can't be applied without skilled discernment, which means experience. > Programming is hard, but we make it much harder than it has to be by doing it spectacularly wrong in many ways, both individually and collectively. I think I agree with this, but it depends on specifics. What sorts of things are you thinking of?
- rocqua 7y ago
  > If you build systems using a high level of skill and foresight, it's easy to do. The point being made here is not necessarily a flippant 'git gud'. Instead, it is a statement that problems are tractable, and that getting some things right up-front can have good pay-offs down the road. In other words, don't give up and try to figure out what is good and bad practice.
  - inimino 7y ago
    Yes, "don't give up" is the main thrust. However, if an individual exists in an environment where bad practice is rewarded and good practice is scorned, the advice needs to go beyond individual practice. We need to not give up on the environment, and that in turn requires hope that a better environment is possible and within our reach, as an individual, a team, and a discipline/craft/practice. This is a hard problem.
- inimino 7y ago
  > But this boils down to If you build systems using a high level of skill and foresight, it's easy to do. Yes. > This is of course not a tautology, but a contradiction. It's not quite a contradiction! If you bill $1 for changing the bolt, and $9,999 for knowing which bolt to replace, this shows that the work is easy, but the experience required to make the work easy is not easy. If the master can draw it in seven strokes, but you don't see the seventy thousand strokes they did before, it looks easy, and in fact it is easy, for the master but not for the novice. > I agree that inexperienced developers can, as it were, 'make life hard for themselves', but that's (trivially) due to their inexperience. I don't think there's a silver bullet for inexperience. That's right. However, we can also make life hard for each other, and there are some solutions for that that are better than doing nothing. > Over-engineering is bad, as is under-engineering. Fuzzy principles like 'YAGNI' can't be applied without skilled discernment, which means experience. Yes. This is why we have code reviews, design reviews, pair programming, and so on, but these aren't silver bullets either and there is no silver bullet, but if these things lead to increased awareness of why and not just what and how, then we can accelerate the process of acquiring that discernment. As Dijkstra said, if it goes to the grave with you and you didn't pass it on, you didn't really do your job as a senior engineer (paraphrasing). >> Programming is hard, but we make it much harder than it has to be by doing it spectacularly wrong in many ways, both individually and collectively. > I think I agree with this, but it depends on specifics. What sorts of things are you thinking of? Using the wrong tool for the job. Using too many tools for the job. Using tools that do not afford mastery, because they are too complex for anything built on top of them to be comprehensible. This is all quite abstract. A specific example: we (the JavaScript community) had a good thing in that JS was a small, human-scale, useful and commercially valuable language with applications beyond its initial environment on the web. We got excited and built the npm package archive, and filled it up, and now we have unmaintainable, incomprehensible piles of trash piled upon trash that can't possibly be used as a foundation for anything reliable, performant, or maintainable. This is unfortunate. What's even more unfortunate is that this piled-up-trash approach still has momentum, still lets people get useful work done, and still has some value to the community. So we keep using it, and even keep piling more on. It takes considerable effort to step back from all this, take a collective mulligan, and start over with a principle of taking things away to make things better, rather than adding more hacks to hide existing hacks. This is one example of many, but I mention this one because I was there when JS was simpler and better and I watched as we made it markedly worse. I would have recommended JS as a first language to beginners when node.js and npm were new, and I did, but I cannot now recommend them in good faith, because they have become antagonistic to quality and to mastery of the craft.

braythwayt 7y ago

I think that you are speaking of a logical tautology, while I am speaking of a linguistic tautology. If I am correct about this, we are both right. A logical tautology is, "A statement that is true by necessity or by virtue of its logical form." A linguistic tautology is, "A phrase or expression in which the same thing is said twice in different words." In formal debating, for example, you can call someone out for either type of tautology.

inimino 7y ago
Because we express logical statements in English, these two kinds of tautologies overlap. (If we were using a formal language we could express tautologies like !(A && !A) without using English.) If you say "All bachelors are unmarried", this is true both because of the meaning of the words, and because of the logical structure implied by the words. In either case, if you state a tautology, you state something which is true in all possible worlds, given the definitions of the words, at least. Someone can then call you out for stating a tautology, which is to state something that is vacuously true, that is, you've made a statement about the nature of reasoning itself, in any possible world, but you haven't said anything at all about the world we're actually in. So you're wasting your breath even though what you say is unassailably true. (Note that in mathematics, the tautologies are precisely the theorems with their premises or axioms! So this is by no means always useless.) The problem with calling out tautologies in common life, however, is that the danger of identifying a false tautology is very high. When someone says "Either X happened, or it didn't." you may be tempted to say "tautology!" but in fact they are probably making some kind of oblique point or highlighting a flaw in someone else's argument, etc. In other words, tautologies may be vacuous as statements about the world within a logical framework, but as speech acts in the real world, they always come with a motivation and that can usually be expressed in a non-tautologous way. For example, "A or not A" can be expanded charitably to "A or not A, and this is relevant to the topic at hand", which is not a tautology anymore. In this case, if you do something right, it's not extra hard, which is kind of a tautology. But there's a point in saying it, which is that it doesn't have to be that hard... if you do it right. And that's not true of everything or in every possible world, hence not a vacuous statement.

deleted 7y ago

[deleted]

MaxBarraclough 7y ago

> That's not a tautology. In fact, it's actually worth pointing out, especially to junior engineers who get frustrated by how hard everything is, that it actually doesn't need to be that hard if you, well, do it right But this boils down to If you build systems using a high level of skill and foresight, it's easy to do. This is of course not a tautology, but a contradiction. I agree that inexperienced developers can, as it were, 'make life hard for themselves', but that's (trivially) due to their inexperience. I don't think there's a silver bullet for inexperience. Over-engineering is bad, as is under-engineering. Fuzzy principles like 'YAGNI' can't be applied without skilled discernment, which means experience. > Programming is hard, but we make it much harder than it has to be by doing it spectacularly wrong in many ways, both individually and collectively. I think I agree with this, but it depends on specifics. What sorts of things are you thinking of?

rocqua 7y ago
> If you build systems using a high level of skill and foresight, it's easy to do. The point being made here is not necessarily a flippant 'git gud'. Instead, it is a statement that problems are tractable, and that getting some things right up-front can have good pay-offs down the road. In other words, don't give up and try to figure out what is good and bad practice.
- inimino 7y ago
  Yes, "don't give up" is the main thrust. However, if an individual exists in an environment where bad practice is rewarded and good practice is scorned, the advice needs to go beyond individual practice. We need to not give up on the environment, and that in turn requires hope that a better environment is possible and within our reach, as an individual, a team, and a discipline/craft/practice. This is a hard problem.
inimino 7y ago
> But this boils down to If you build systems using a high level of skill and foresight, it's easy to do. Yes. > This is of course not a tautology, but a contradiction. It's not quite a contradiction! If you bill $1 for changing the bolt, and $9,999 for knowing which bolt to replace, this shows that the work is easy, but the experience required to make the work easy is not easy. If the master can draw it in seven strokes, but you don't see the seventy thousand strokes they did before, it looks easy, and in fact it is easy, for the master but not for the novice. > I agree that inexperienced developers can, as it were, 'make life hard for themselves', but that's (trivially) due to their inexperience. I don't think there's a silver bullet for inexperience. That's right. However, we can also make life hard for each other, and there are some solutions for that that are better than doing nothing. > Over-engineering is bad, as is under-engineering. Fuzzy principles like 'YAGNI' can't be applied without skilled discernment, which means experience. Yes. This is why we have code reviews, design reviews, pair programming, and so on, but these aren't silver bullets either and there is no silver bullet, but if these things lead to increased awareness of why and not just what and how, then we can accelerate the process of acquiring that discernment. As Dijkstra said, if it goes to the grave with you and you didn't pass it on, you didn't really do your job as a senior engineer (paraphrasing). >> Programming is hard, but we make it much harder than it has to be by doing it spectacularly wrong in many ways, both individually and collectively. > I think I agree with this, but it depends on specifics. What sorts of things are you thinking of? Using the wrong tool for the job. Using too many tools for the job. Using tools that do not afford mastery, because they are too complex for anything built on top of them to be comprehensible. This is all quite abstract. A specific example: we (the JavaScript community) had a good thing in that JS was a small, human-scale, useful and commercially valuable language with applications beyond its initial environment on the web. We got excited and built the npm package archive, and filled it up, and now we have unmaintainable, incomprehensible piles of trash piled upon trash that can't possibly be used as a foundation for anything reliable, performant, or maintainable. This is unfortunate. What's even more unfortunate is that this piled-up-trash approach still has momentum, still lets people get useful work done, and still has some value to the community. So we keep using it, and even keep piling more on. It takes considerable effort to step back from all this, take a collective mulligan, and start over with a principle of taking things away to make things better, rather than adding more hacks to hide existing hacks. This is one example of many, but I mention this one because I was there when JS was simpler and better and I watched as we made it markedly worse. I would have recommended JS as a first language to beginners when node.js and npm were new, and I did, but I cannot now recommend them in good faith, because they have become antagonistic to quality and to mastery of the craft.