Things I believe to be true
-
In no particular order of importance, things I believe to be true. I was going to go for 99, and nail them to the forum door, but that would have taken me far afield. I got it about a third of the way at least. 1. That the odds of a bug being in a piece of code is represented by this formula (B=P^2), where P is the number of times that code is cut and pasted, or searched and replaced. 2. That, given there is always many times more need for software to be developed than there are highly experienced developers, most software will in large part by written by less experienced developers. So anything that can improve their odds is probably a significant win. 3. That, #2 shouldn't mean make it *easier* in terms of doing it without having to understand it (software development and certainly the problem domain), it means make it safer, so it's harder for them to shoot themselves in the foot. Even better, help them become as quickly as possible one of those experienced developers. 4. That most everything in a programming language that is designed to reduce verbosity at the cost of explicit expression of user intention and semantics will, on average and other things being roughly equal, make software less reliable. 5. That, as corollary to #4, anything added to a programming language that increases the programmer's ability to express intent and semantics will, on average and other things being roughly equal, make software more reliable. 6. That software developers, while maybe not as widely varied as the population as a whole, are still widely varied. What it takes to get the best out of any given developer will be somewhat unique. However, human nature being what it is, those groupings of individuals we call organizations and companies will never actually be able to create such optimal conditions because of the need for conformity and an inability to allow people close to the pavement to make up their own rules long as they produce results, at least once the number of people in that grouping gets over a fairly small number. 7. That, related to #6, this means that many of the potentially best developers will never come close to their potential because they may well be the furthest from the norm. 8. That ultimately we software people (at least those working at a serious level) are in the business of complexity management, that almost as much of that complexity (maybe as much) comes from the humans involved as the tools, and that human nature (being what it is) will never allow us to really substantiall
-
In no particular order of importance, things I believe to be true. I was going to go for 99, and nail them to the forum door, but that would have taken me far afield. I got it about a third of the way at least. 1. That the odds of a bug being in a piece of code is represented by this formula (B=P^2), where P is the number of times that code is cut and pasted, or searched and replaced. 2. That, given there is always many times more need for software to be developed than there are highly experienced developers, most software will in large part by written by less experienced developers. So anything that can improve their odds is probably a significant win. 3. That, #2 shouldn't mean make it *easier* in terms of doing it without having to understand it (software development and certainly the problem domain), it means make it safer, so it's harder for them to shoot themselves in the foot. Even better, help them become as quickly as possible one of those experienced developers. 4. That most everything in a programming language that is designed to reduce verbosity at the cost of explicit expression of user intention and semantics will, on average and other things being roughly equal, make software less reliable. 5. That, as corollary to #4, anything added to a programming language that increases the programmer's ability to express intent and semantics will, on average and other things being roughly equal, make software more reliable. 6. That software developers, while maybe not as widely varied as the population as a whole, are still widely varied. What it takes to get the best out of any given developer will be somewhat unique. However, human nature being what it is, those groupings of individuals we call organizations and companies will never actually be able to create such optimal conditions because of the need for conformity and an inability to allow people close to the pavement to make up their own rules long as they produce results, at least once the number of people in that grouping gets over a fairly small number. 7. That, related to #6, this means that many of the potentially best developers will never come close to their potential because they may well be the furthest from the norm. 8. That ultimately we software people (at least those working at a serious level) are in the business of complexity management, that almost as much of that complexity (maybe as much) comes from the humans involved as the tools, and that human nature (being what it is) will never allow us to really substantiall
tl;dr Better in your blog than here where it'll disappear soon.
-
In no particular order of importance, things I believe to be true. I was going to go for 99, and nail them to the forum door, but that would have taken me far afield. I got it about a third of the way at least. 1. That the odds of a bug being in a piece of code is represented by this formula (B=P^2), where P is the number of times that code is cut and pasted, or searched and replaced. 2. That, given there is always many times more need for software to be developed than there are highly experienced developers, most software will in large part by written by less experienced developers. So anything that can improve their odds is probably a significant win. 3. That, #2 shouldn't mean make it *easier* in terms of doing it without having to understand it (software development and certainly the problem domain), it means make it safer, so it's harder for them to shoot themselves in the foot. Even better, help them become as quickly as possible one of those experienced developers. 4. That most everything in a programming language that is designed to reduce verbosity at the cost of explicit expression of user intention and semantics will, on average and other things being roughly equal, make software less reliable. 5. That, as corollary to #4, anything added to a programming language that increases the programmer's ability to express intent and semantics will, on average and other things being roughly equal, make software more reliable. 6. That software developers, while maybe not as widely varied as the population as a whole, are still widely varied. What it takes to get the best out of any given developer will be somewhat unique. However, human nature being what it is, those groupings of individuals we call organizations and companies will never actually be able to create such optimal conditions because of the need for conformity and an inability to allow people close to the pavement to make up their own rules long as they produce results, at least once the number of people in that grouping gets over a fairly small number. 7. That, related to #6, this means that many of the potentially best developers will never come close to their potential because they may well be the furthest from the norm. 8. That ultimately we software people (at least those working at a serious level) are in the business of complexity management, that almost as much of that complexity (maybe as much) comes from the humans involved as the tools, and that human nature (being what it is) will never allow us to really substantiall
-
In no particular order of importance, things I believe to be true. I was going to go for 99, and nail them to the forum door, but that would have taken me far afield. I got it about a third of the way at least. 1. That the odds of a bug being in a piece of code is represented by this formula (B=P^2), where P is the number of times that code is cut and pasted, or searched and replaced. 2. That, given there is always many times more need for software to be developed than there are highly experienced developers, most software will in large part by written by less experienced developers. So anything that can improve their odds is probably a significant win. 3. That, #2 shouldn't mean make it *easier* in terms of doing it without having to understand it (software development and certainly the problem domain), it means make it safer, so it's harder for them to shoot themselves in the foot. Even better, help them become as quickly as possible one of those experienced developers. 4. That most everything in a programming language that is designed to reduce verbosity at the cost of explicit expression of user intention and semantics will, on average and other things being roughly equal, make software less reliable. 5. That, as corollary to #4, anything added to a programming language that increases the programmer's ability to express intent and semantics will, on average and other things being roughly equal, make software more reliable. 6. That software developers, while maybe not as widely varied as the population as a whole, are still widely varied. What it takes to get the best out of any given developer will be somewhat unique. However, human nature being what it is, those groupings of individuals we call organizations and companies will never actually be able to create such optimal conditions because of the need for conformity and an inability to allow people close to the pavement to make up their own rules long as they produce results, at least once the number of people in that grouping gets over a fairly small number. 7. That, related to #6, this means that many of the potentially best developers will never come close to their potential because they may well be the furthest from the norm. 8. That ultimately we software people (at least those working at a serious level) are in the business of complexity management, that almost as much of that complexity (maybe as much) comes from the humans involved as the tools, and that human nature (being what it is) will never allow us to really substantiall
-
That seems to be about right for me.
-
In no particular order of importance, things I believe to be true. I was going to go for 99, and nail them to the forum door, but that would have taken me far afield. I got it about a third of the way at least. 1. That the odds of a bug being in a piece of code is represented by this formula (B=P^2), where P is the number of times that code is cut and pasted, or searched and replaced. 2. That, given there is always many times more need for software to be developed than there are highly experienced developers, most software will in large part by written by less experienced developers. So anything that can improve their odds is probably a significant win. 3. That, #2 shouldn't mean make it *easier* in terms of doing it without having to understand it (software development and certainly the problem domain), it means make it safer, so it's harder for them to shoot themselves in the foot. Even better, help them become as quickly as possible one of those experienced developers. 4. That most everything in a programming language that is designed to reduce verbosity at the cost of explicit expression of user intention and semantics will, on average and other things being roughly equal, make software less reliable. 5. That, as corollary to #4, anything added to a programming language that increases the programmer's ability to express intent and semantics will, on average and other things being roughly equal, make software more reliable. 6. That software developers, while maybe not as widely varied as the population as a whole, are still widely varied. What it takes to get the best out of any given developer will be somewhat unique. However, human nature being what it is, those groupings of individuals we call organizations and companies will never actually be able to create such optimal conditions because of the need for conformity and an inability to allow people close to the pavement to make up their own rules long as they produce results, at least once the number of people in that grouping gets over a fairly small number. 7. That, related to #6, this means that many of the potentially best developers will never come close to their potential because they may well be the furthest from the norm. 8. That ultimately we software people (at least those working at a serious level) are in the business of complexity management, that almost as much of that complexity (maybe as much) comes from the humans involved as the tools, and that human nature (being what it is) will never allow us to really substantiall
31. Having read 1, 2, 3 and 29, 30, I believe 4 through 28 are probably true as well.
Latest Article - Slack-Chatting with you rPi Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny Artificial intelligence is the only remedy for natural stupidity. - CDP1802
-
In no particular order of importance, things I believe to be true. I was going to go for 99, and nail them to the forum door, but that would have taken me far afield. I got it about a third of the way at least. 1. That the odds of a bug being in a piece of code is represented by this formula (B=P^2), where P is the number of times that code is cut and pasted, or searched and replaced. 2. That, given there is always many times more need for software to be developed than there are highly experienced developers, most software will in large part by written by less experienced developers. So anything that can improve their odds is probably a significant win. 3. That, #2 shouldn't mean make it *easier* in terms of doing it without having to understand it (software development and certainly the problem domain), it means make it safer, so it's harder for them to shoot themselves in the foot. Even better, help them become as quickly as possible one of those experienced developers. 4. That most everything in a programming language that is designed to reduce verbosity at the cost of explicit expression of user intention and semantics will, on average and other things being roughly equal, make software less reliable. 5. That, as corollary to #4, anything added to a programming language that increases the programmer's ability to express intent and semantics will, on average and other things being roughly equal, make software more reliable. 6. That software developers, while maybe not as widely varied as the population as a whole, are still widely varied. What it takes to get the best out of any given developer will be somewhat unique. However, human nature being what it is, those groupings of individuals we call organizations and companies will never actually be able to create such optimal conditions because of the need for conformity and an inability to allow people close to the pavement to make up their own rules long as they produce results, at least once the number of people in that grouping gets over a fairly small number. 7. That, related to #6, this means that many of the potentially best developers will never come close to their potential because they may well be the furthest from the norm. 8. That ultimately we software people (at least those working at a serious level) are in the business of complexity management, that almost as much of that complexity (maybe as much) comes from the humans involved as the tools, and that human nature (being what it is) will never allow us to really substantiall
I can't find mention of Firefly, so you may want to make some revisions. [edit] It's a bit much to discuss, BTW. Maybe if you made one or two statements per posting, and gave us a day or so to work through them, before posting the next -- a TIBtbTOTD, as it were [/edit]
I wanna be a eunuchs developer! Pass me a bread knife!
-
I can't find mention of Firefly, so you may want to make some revisions. [edit] It's a bit much to discuss, BTW. Maybe if you made one or two statements per posting, and gave us a day or so to work through them, before posting the next -- a TIBtbTOTD, as it were [/edit]
I wanna be a eunuchs developer! Pass me a bread knife!
Maybe I've discovered a way to post something semi-opinionated on the internet and not get attacked as an infidel. Just saturate their sensors and they can't see what I'm saying.
-
In no particular order of importance, things I believe to be true. I was going to go for 99, and nail them to the forum door, but that would have taken me far afield. I got it about a third of the way at least. 1. That the odds of a bug being in a piece of code is represented by this formula (B=P^2), where P is the number of times that code is cut and pasted, or searched and replaced. 2. That, given there is always many times more need for software to be developed than there are highly experienced developers, most software will in large part by written by less experienced developers. So anything that can improve their odds is probably a significant win. 3. That, #2 shouldn't mean make it *easier* in terms of doing it without having to understand it (software development and certainly the problem domain), it means make it safer, so it's harder for them to shoot themselves in the foot. Even better, help them become as quickly as possible one of those experienced developers. 4. That most everything in a programming language that is designed to reduce verbosity at the cost of explicit expression of user intention and semantics will, on average and other things being roughly equal, make software less reliable. 5. That, as corollary to #4, anything added to a programming language that increases the programmer's ability to express intent and semantics will, on average and other things being roughly equal, make software more reliable. 6. That software developers, while maybe not as widely varied as the population as a whole, are still widely varied. What it takes to get the best out of any given developer will be somewhat unique. However, human nature being what it is, those groupings of individuals we call organizations and companies will never actually be able to create such optimal conditions because of the need for conformity and an inability to allow people close to the pavement to make up their own rules long as they produce results, at least once the number of people in that grouping gets over a fairly small number. 7. That, related to #6, this means that many of the potentially best developers will never come close to their potential because they may well be the furthest from the norm. 8. That ultimately we software people (at least those working at a serious level) are in the business of complexity management, that almost as much of that complexity (maybe as much) comes from the humans involved as the tools, and that human nature (being what it is) will never allow us to really substantiall
And, just to throw another one in there: 31. That every new post I make on this form will get marked as potential spam and held.
-
Maybe I've discovered a way to post something semi-opinionated on the internet and not get attacked as an infidel. Just saturate their sensors and they can't see what I'm saying.
Dean Roddey wrote:
Just saturate their sensors and they can't see what I'm saying.
Doesn't that retract the whole point of posting to begin with?
Wrong is evil and must be defeated. - Jeff Ello
-
In no particular order of importance, things I believe to be true. I was going to go for 99, and nail them to the forum door, but that would have taken me far afield. I got it about a third of the way at least. 1. That the odds of a bug being in a piece of code is represented by this formula (B=P^2), where P is the number of times that code is cut and pasted, or searched and replaced. 2. That, given there is always many times more need for software to be developed than there are highly experienced developers, most software will in large part by written by less experienced developers. So anything that can improve their odds is probably a significant win. 3. That, #2 shouldn't mean make it *easier* in terms of doing it without having to understand it (software development and certainly the problem domain), it means make it safer, so it's harder for them to shoot themselves in the foot. Even better, help them become as quickly as possible one of those experienced developers. 4. That most everything in a programming language that is designed to reduce verbosity at the cost of explicit expression of user intention and semantics will, on average and other things being roughly equal, make software less reliable. 5. That, as corollary to #4, anything added to a programming language that increases the programmer's ability to express intent and semantics will, on average and other things being roughly equal, make software more reliable. 6. That software developers, while maybe not as widely varied as the population as a whole, are still widely varied. What it takes to get the best out of any given developer will be somewhat unique. However, human nature being what it is, those groupings of individuals we call organizations and companies will never actually be able to create such optimal conditions because of the need for conformity and an inability to allow people close to the pavement to make up their own rules long as they produce results, at least once the number of people in that grouping gets over a fairly small number. 7. That, related to #6, this means that many of the potentially best developers will never come close to their potential because they may well be the furthest from the norm. 8. That ultimately we software people (at least those working at a serious level) are in the business of complexity management, that almost as much of that complexity (maybe as much) comes from the humans involved as the tools, and that human nature (being what it is) will never allow us to really substantiall
Dean Roddey wrote:
4. That most everything in a programming language that is designed to reduce verbosity at the cost of explicit expression of user intention and semantics will, on average and other things being roughly equal, make software less reliable.
Every time a language update includes "shortcuts" that pack more stuff into 1 line of code, the reliability goes down and the duration to produce Production level executables goes up. On my current project, this is case in point. We tear apart such code in order to be able to debug it.
-
Dean Roddey wrote:
4. That most everything in a programming language that is designed to reduce verbosity at the cost of explicit expression of user intention and semantics will, on average and other things being roughly equal, make software less reliable.
Every time a language update includes "shortcuts" that pack more stuff into 1 line of code, the reliability goes down and the duration to produce Production level executables goes up. On my current project, this is case in point. We tear apart such code in order to be able to debug it.
Yeh, I've had people say, "why on earth are you breaking that into three lines when it could all just be statement?" And the answer is, so I can see intermediate results in the debugger. I don't care if it looks less attractive to read. And I certainly don't want to have to change it and change it back every time I need to see those intermediate results, and risk introducing errors.
-
Dean Roddey wrote:
Just saturate their sensors and they can't see what I'm saying.
Doesn't that retract the whole point of posting to begin with?
Wrong is evil and must be defeated. - Jeff Ello
Actually, caring enough about other people to worry if they read your posted wisdom is so 2010s. The internet has now moved beyond the 'look at me' phase, and is now moving into the 'just me' phase.
-
In no particular order of importance, things I believe to be true. I was going to go for 99, and nail them to the forum door, but that would have taken me far afield. I got it about a third of the way at least. 1. That the odds of a bug being in a piece of code is represented by this formula (B=P^2), where P is the number of times that code is cut and pasted, or searched and replaced. 2. That, given there is always many times more need for software to be developed than there are highly experienced developers, most software will in large part by written by less experienced developers. So anything that can improve their odds is probably a significant win. 3. That, #2 shouldn't mean make it *easier* in terms of doing it without having to understand it (software development and certainly the problem domain), it means make it safer, so it's harder for them to shoot themselves in the foot. Even better, help them become as quickly as possible one of those experienced developers. 4. That most everything in a programming language that is designed to reduce verbosity at the cost of explicit expression of user intention and semantics will, on average and other things being roughly equal, make software less reliable. 5. That, as corollary to #4, anything added to a programming language that increases the programmer's ability to express intent and semantics will, on average and other things being roughly equal, make software more reliable. 6. That software developers, while maybe not as widely varied as the population as a whole, are still widely varied. What it takes to get the best out of any given developer will be somewhat unique. However, human nature being what it is, those groupings of individuals we call organizations and companies will never actually be able to create such optimal conditions because of the need for conformity and an inability to allow people close to the pavement to make up their own rules long as they produce results, at least once the number of people in that grouping gets over a fairly small number. 7. That, related to #6, this means that many of the potentially best developers will never come close to their potential because they may well be the furthest from the norm. 8. That ultimately we software people (at least those working at a serious level) are in the business of complexity management, that almost as much of that complexity (maybe as much) comes from the humans involved as the tools, and that human nature (being what it is) will never allow us to really substantiall
Wow- The truth is out there!
Quote:
4. That most everything in a programming language that is designed to reduce verbosity at the cost of explicit expression of user intention and semantics will, on average and other things being roughly equal, make software less reliable.
Please could we have that posted on the wall of all rooms where the C++ ISO committee meets!
-
Wow- The truth is out there!
Quote:
4. That most everything in a programming language that is designed to reduce verbosity at the cost of explicit expression of user intention and semantics will, on average and other things being roughly equal, make software less reliable.
Please could we have that posted on the wall of all rooms where the C++ ISO committee meets!
Of course there are a lot of folks out there now who will argue to the death that this is outdated thinking. I wonder how many of them come from JavaScript or some such and have never written anything of significant size and supported it for many years?