Good points. You seem to be confirming what I've long suspected: that things that seem easy on a system you have experience with, but seem hard on a system you don't have experience with, may be more a function of the experience than the system.
I remember many years ago when I was first learning Windows 95 that I had to go and ask experts a lot of questions on how to do things. Now it all seems so easy - except when Microsoft shuffles the deck chairs for no good reason. For example, I've just been forced to use Office 2013 [sigh].
Every time I set path variables in Windows I'm struck by how difficult that would be to find if I didn't happen to know where it's done. Likewise, when I've tried Linux, there are a lot of things such as the standard directory layout that probably seem obvious to Linux veterans, but seems a bit mysterious to me. For example, things like "usr" and "bin" suggest something, but what's that "etc" thing all about? (Don't bother answering - I'd use Google or Wikipedia if I really cared.)
You may be the exception, but most of us who graduated from college make use of at least part of what we learned there every day on the job. In my own case, I learned a lot of math and theory in college that's essential to what I do, even though most of my daily work revolves around skills I've learned since I graduated from college.
So, although college isn't for everybody, it's done some of us quite a lot of good. I think employers recognize that a formal education and a degree do add value, and although they might miss the occasional prodigy by requiring credentials rather than experience only, that's a price they're willing to pay.
In my own case, I had only a couple of classes on programming in college, which was many years ago. Nearly all of what I know about software development was acquired through self-study and experience. I happen to know a little bit about cryptography due to side projects, but I've never once come across it as part of my job - except in the casual sense of encryption features of common thing like zip files. So why would any employer expect me to know it unless it was on my resume or a qualification for the job I'm applying for?
Exactly. For example, most embedded microcontroller software doesn't use cryptography at all. Hopefully, all such interview questions would be tailored to the job being filled and to the applicant's resume.
One thing I can think of that seems to me like it should be common knowledge among software developers are CRCs. Even so, there are probably many qualified software developers who have no knowledge of those - and don't really need to.
Your weightings of 90% culture and 10% technical seem a bit off to me, but I agree with the general concept. Having just one person on a team who is a problem can really drag everybody else down. I left my last job because of such a person, and also because of how badly management handled the conflicts we had.
Having made some "cultural" mistakes myself over the years, I developed a motto that "It's more important to get along with others than to get your work done." It took me a long time to figure that out. Most of the time when I wasn't getting along with others it revolved around me being irritated that they were impeding my progress. Having made that mistake a few times, and having suffered some Pavlovian conditioning as a result, I realized that getting the job done was optional but getting along with others wasn't. Seems obvious now.
That said, I've also worked with some very pleasant people who produced very little, and that's also not ideal. So, the best thing to hire for, IMHO, is someone who has the right balance of social and technical competance. Again, I wouldn't shoot for 90/10 - maybe 40/60 would be better.
Please, oh please - can we at least skip over Linux Vista?
Actually, many years ago I tried to run Red Hat 6 (IIRC). I was new to Linux so I knew there would be a learning curve. But after a great deal of misery, I finally discovered that there was something fundamentally broken about the then-current version of GCC, and there was no possible way for a newbie like me to compensate. So, maybe that was the "Vista" moment of "the GNU/Linux system".
Since then, I've tried several Linux distributions and generally had a much better experience. Usually, I end up playing some of the games for awhile that come with it such as Tetris, then I try to get some basic Firefox plugins installed and maybe try to get audio to come out. After failing at those things, I go back to Windows. Then, a few years later, hoping that "easy" things have somehow magically gotten easy, I rinse and repeat.
Which reminds me - I haven't done all that for a couple of years. Heck, maybe 2015 finally will be my personal year of the Linux desktop.;-)
Correction: I see now on Wikipedia's ALGOL page that blocks were introduced in ALGOL in 1960. So maybe ALGOL influenced Dijkstra rather than the other way around.
It's no surprise that goto's are used sparingly - and generally only with very good reason - by modern programmers. Dijkstra's paper is dated 1968, which is about the time ALGOL was invented. ALGOL which was the first block-oriented language. Heck, maybe its design was even influenced by Dijkstra's paper - who knows?
Given a language that supports blocks (and all modern languages do), there's little reason to use gotos. Instead, you use blocks and related goto-like constructs such as break, return, try/catch, etc. Anything but a literal goto.
IIRC, the CPython source code has a few goto's in it. I remember that Tim Peters once defended that as being the best solution (in C, at least) for certain very exceptional situations. It's no coincidence that they're used very, very sparingly there. And maybe they wouldn't be needed at all in CPython if C had a try/catch construct - like Python itself.
In my own case, I've used them mostly when transliterating some ancient FORTRAN code into C. Rather than untangling the code into blocks, it was simply easier to replicate the goto's. At the time, I actually had to consult K&R to brush up on C's goto syntax. Also, the FORTRAN code I was working with was proven and needed little maintenance, so removing the goto's was more likely to make it worse than to make it better.
Let's assume you can only actually consume...pick a number...$5 million. Next, let's also assume that you would do what so many other rich folks do with money that they can't consume: buy monuments to yourself at your alma mater. Just picture it: "Jeremi Hall" would be proudly displayed above the door and also on a little brass plaque on the side. Just think how many more monuments you could buy with $500 million than with $40 million.
Here's another way to look at it. I see the main benefit of making a lot of money as being that when the government takes most of your money away, what's left is still more than you need. Offhand, it seems like that $5 million you might actually spend is pretty likely to be leftover from the $500 million you theoretically "won". But if you only win $40 million...well...all bets are off...
Personally, I prefer to play the stock market to the lottery or any form of literal gambling. I prefer to play in a "casino" where the odds are in your favor, assuming that don't trade often enough that brokerage commissions tilt the odds against you. That $1000-2000 you mention could work for that.
The only game I like to play where the odds are against me is pinball. It's comforting, somehow, to know that no matter how well you play, you'll never win your money back. Pinball is tilted that way.
Not such a great proposition when you consider that your chance of being killed in a car accident on the way to the store exceeds your chance of winning the big one.
If people were prone to feeling unlucky to the same degree as they're prone to feeling lucky, gambling would never have had to be made illegal in most jurisdictions. Perhaps the same asymmetrical perception of expected value explains why people get involved in heroin.
Let's assume it's all about the entertainment value of the fantasy of winning. Then, it's perfectly logical: for the same $2, a $500 million jackpot provides 12.5x the entertainment of a $40 million jackpot.
Or as Dirty Harry might say:
I know what you're thinkin' - is it 500 million or only 40? You just gotta ask yourself one question: do I feel lucky? Well, do ya' punk?...
Thanks for being a good sport. Actually, with "7734", I guess I'm showing my age. That was the preferred form on the early TI calculators which had 7-segment LEDs. But I see now on my more modern LCD calculator that it has hooks on the 7's, which doesn't render as well as your "1134".
Like all parasites, lawyers are an inherently conservative species, and registering a trademark is a conservative move. IANAL, but you don't actually even need to register trademarks, just use them in business and they become yours. Registering is just a formality that may help in some extreme legal circumstances. And, yes, the Coke folks have probably registered "Diet Coca-Cola". Since the cost of registering a mark is so low, there's really no reason not to for any sort of large organization. Besides, after you do that, you get to use the nifty little circled "R".
In my own case, I run a small business out of my home in my spare time, and I claim several trademarks which I have never registered. Since the business is so small, the cost of registering isn't worth it - unlike Diet Coca-Cola and Windows 365. I'm relying on the fact that I've claimed the trademarks on my websites over the years and used them in commerce - which is really the essential element of any trademark. If there's ever any dispute about my little trademarks, we can always use archive.org to prove when I first used them to anyone who cares.
Again, IANAL, but I play one on TV. When your business is as small as mine, it's good to have an amateur lawyer on staff (me), even if he has no formal legal training or credentials.
Registering a trademark is cheap, especially for any outfit that's large enough to have their own lawyers already on staff. So, there isn't much percentage in trying to read anything big into the registering of a trademark. In this case, they would need no greater reason to trademark "Windows 365" than the fact that they already have some related trademarks.
My own thought was to use 7-zip to make strongly encrypted 7z files, but somebody can suggest something better. In particular, it would be nice if such a tool could automatically do the uploading/downloading to/from the storage provider, which 7-zip doesn't do.
You assume the software is bug free to begin with.
No, I assume that making ostensibly non-funtional changes to functioning code is more likely to introduce bugs than to accidentally remove them. The primary goal at that stage is to not make it worse.
Anyway, with all that experience you have with theorem proving and compiler design, etc, I can see why you don't bother with any automatic aids to assure that changes don't accidentally make things worse.
In my own case, I often do what I call "code algebra", which are small refactorings that are intended to leave the functioning of the code unchanged. Unfortunately, try as I might, I sometimes make mistakes along the way. That's why I seek mechanical help where available - and why I so greatly admire those of you who don't need any.
I really gotta look into that theorem proving and compiler designing stuff - maybe that's the piece of the puzzle that I've been missing all these years.
Agreed. I bought a mid-range Nikon DSLR a couple of years ago (after having spent many years in film photography as a Nikon guy), but I end up still mostly using either my aging Canon prosumer G9 point-and-shoot or the cheap cell phone that's in my pocket.
Sadly, my old vintage Nikon lenses aren't nearly as useful as I thought they would be because even though some are nominally compatible, you give up so many automatic features that even those aren't very useful. So much for Nikon's famous backwards-compatible lenses. I haven't invested in modern Nikon lenses except for the ones that came in the camera kit because I'm not a serious enough photographer to fork out the dough.
Given all that, and since most of us already have more megapixels than we ever need, there doesn't seem to be much reason to buy any new digital cameras until one breaks.
Then you start working by removing dead code, indenting, do static and run-time code analysis to find bugs, then merge duplicate code. Start with the more mechanical parts first. Once you get that working and bug free you basically have the new version 1.0.
I didn't see anything about tests? How will you know it is "working and bug free" without them?
In my experience, one of the most dangerous things you can do is to change working code in a mechanical way that should be safe. Whenever I do that, I always use something to make sure the code is unchanged. If the change is strictly cosmetic, something like Beyond Compare can be used for that. Otherwise, you need module tests that fully characterize the existing code via functional testing with complete condition/decision coverage. Or, maybe there's some tool that can be used to compare code at the level of its abstract syntax tree or whatever to ensure that its functionality is unchanged. (Does anybody know of something like that? - a Clang tool, maybe?)
Of course, this is taking a very conservative approach. But doing "safe" changes manually on a large (or even medium) code base without some sort of automated safety net is a sure way to introduce difficult-to-find bugs. Caveat emptor.
Slashdot Mirror
Don't worry about replacing the battery - they'll be selling you a new car with thinner sheet metal long before the battery wears out.
Good points. You seem to be confirming what I've long suspected: that things that seem easy on a system you have experience with, but seem hard on a system you don't have experience with, may be more a function of the experience than the system.
I remember many years ago when I was first learning Windows 95 that I had to go and ask experts a lot of questions on how to do things. Now it all seems so easy - except when Microsoft shuffles the deck chairs for no good reason. For example, I've just been forced to use Office 2013 [sigh].
Every time I set path variables in Windows I'm struck by how difficult that would be to find if I didn't happen to know where it's done. Likewise, when I've tried Linux, there are a lot of things such as the standard directory layout that probably seem obvious to Linux veterans, but seems a bit mysterious to me. For example, things like "usr" and "bin" suggest something, but what's that "etc" thing all about? (Don't bother answering - I'd use Google or Wikipedia if I really cared.)
You may be the exception, but most of us who graduated from college make use of at least part of what we learned there every day on the job. In my own case, I learned a lot of math and theory in college that's essential to what I do, even though most of my daily work revolves around skills I've learned since I graduated from college.
So, although college isn't for everybody, it's done some of us quite a lot of good. I think employers recognize that a formal education and a degree do add value, and although they might miss the occasional prodigy by requiring credentials rather than experience only, that's a price they're willing to pay.
Clearly, you don't live in Lake Woebegon. All the children above average there.
In my own case, I had only a couple of classes on programming in college, which was many years ago. Nearly all of what I know about software development was acquired through self-study and experience. I happen to know a little bit about cryptography due to side projects, but I've never once come across it as part of my job - except in the casual sense of encryption features of common thing like zip files. So why would any employer expect me to know it unless it was on my resume or a qualification for the job I'm applying for?
Exactly. For example, most embedded microcontroller software doesn't use cryptography at all. Hopefully, all such interview questions would be tailored to the job being filled and to the applicant's resume.
One thing I can think of that seems to me like it should be common knowledge among software developers are CRCs. Even so, there are probably many qualified software developers who have no knowledge of those - and don't really need to.
I guess it's not entirely surprising that employers can't find good people for cheap.
Your weightings of 90% culture and 10% technical seem a bit off to me, but I agree with the general concept. Having just one person on a team who is a problem can really drag everybody else down. I left my last job because of such a person, and also because of how badly management handled the conflicts we had.
Having made some "cultural" mistakes myself over the years, I developed a motto that "It's more important to get along with others than to get your work done." It took me a long time to figure that out. Most of the time when I wasn't getting along with others it revolved around me being irritated that they were impeding my progress. Having made that mistake a few times, and having suffered some Pavlovian conditioning as a result, I realized that getting the job done was optional but getting along with others wasn't. Seems obvious now.
That said, I've also worked with some very pleasant people who produced very little, and that's also not ideal. So, the best thing to hire for, IMHO, is someone who has the right balance of social and technical competance. Again, I wouldn't shoot for 90/10 - maybe 40/60 would be better.
Please, oh please - can we at least skip over Linux Vista?
Actually, many years ago I tried to run Red Hat 6 (IIRC). I was new to Linux so I knew there would be a learning curve. But after a great deal of misery, I finally discovered that there was something fundamentally broken about the then-current version of GCC, and there was no possible way for a newbie like me to compensate. So, maybe that was the "Vista" moment of "the GNU/Linux system".
Since then, I've tried several Linux distributions and generally had a much better experience. Usually, I end up playing some of the games for awhile that come with it such as Tetris, then I try to get some basic Firefox plugins installed and maybe try to get audio to come out. After failing at those things, I go back to Windows. Then, a few years later, hoping that "easy" things have somehow magically gotten easy, I rinse and repeat.
Which reminds me - I haven't done all that for a couple of years. Heck, maybe 2015 finally will be my personal year of the Linux desktop. ;-)
Correction: I see now on Wikipedia's ALGOL page that blocks were introduced in ALGOL in 1960. So maybe ALGOL influenced Dijkstra rather than the other way around.
It's no surprise that goto's are used sparingly - and generally only with very good reason - by modern programmers. Dijkstra's paper is dated 1968, which is about the time ALGOL was invented. ALGOL which was the first block-oriented language. Heck, maybe its design was even influenced by Dijkstra's paper - who knows?
Given a language that supports blocks (and all modern languages do), there's little reason to use gotos. Instead, you use blocks and related goto-like constructs such as break, return, try/catch, etc. Anything but a literal goto.
IIRC, the CPython source code has a few goto's in it. I remember that Tim Peters once defended that as being the best solution (in C, at least) for certain very exceptional situations. It's no coincidence that they're used very, very sparingly there. And maybe they wouldn't be needed at all in CPython if C had a try/catch construct - like Python itself.
In my own case, I've used them mostly when transliterating some ancient FORTRAN code into C. Rather than untangling the code into blocks, it was simply easier to replicate the goto's. At the time, I actually had to consult K&R to brush up on C's goto syntax. Also, the FORTRAN code I was working with was proven and needed little maintenance, so removing the goto's was more likely to make it worse than to make it better.
Let's assume you can only actually consume...pick a number...$5 million. Next, let's also assume that you would do what so many other rich folks do with money that they can't consume: buy monuments to yourself at your alma mater. Just picture it: "Jeremi Hall" would be proudly displayed above the door and also on a little brass plaque on the side. Just think how many more monuments you could buy with $500 million than with $40 million.
Here's another way to look at it. I see the main benefit of making a lot of money as being that when the government takes most of your money away, what's left is still more than you need. Offhand, it seems like that $5 million you might actually spend is pretty likely to be leftover from the $500 million you theoretically "won". But if you only win $40 million...well...all bets are off...
Personally, I prefer to play the stock market to the lottery or any form of literal gambling. I prefer to play in a "casino" where the odds are in your favor, assuming that don't trade often enough that brokerage commissions tilt the odds against you. That $1000-2000 you mention could work for that.
The only game I like to play where the odds are against me is pinball. It's comforting, somehow, to know that no matter how well you play, you'll never win your money back. Pinball is tilted that way.
Not such a great proposition when you consider that your chance of being killed in a car accident on the way to the store exceeds your chance of winning the big one.
If people were prone to feeling unlucky to the same degree as they're prone to feeling lucky, gambling would never have had to be made illegal in most jurisdictions. Perhaps the same asymmetrical perception of expected value explains why people get involved in heroin.
Let's assume it's all about the entertainment value of the fantasy of winning. Then, it's perfectly logical: for the same $2, a $500 million jackpot provides 12.5x the entertainment of a $40 million jackpot.
Or as Dirty Harry might say:
I know what you're thinkin' - is it 500 million or only 40? You just gotta ask yourself one question: do I feel lucky? Well, do ya' punk?...
Thanks for being a good sport. Actually, with "7734", I guess I'm showing my age. That was the preferred form on the early TI calculators which had 7-segment LEDs. But I see now on my more modern LCD calculator that it has hooks on the 7's, which doesn't render as well as your "1134".
(Let's see if Mr. Spock gets the joke this time, with a second joke thrown in. ;-)
7734!
Math is not a human language. If you contend it is, try expressing emotions with it.
May I use factorials?
Like all parasites, lawyers are an inherently conservative species, and registering a trademark is a conservative move. IANAL, but you don't actually even need to register trademarks, just use them in business and they become yours. Registering is just a formality that may help in some extreme legal circumstances. And, yes, the Coke folks have probably registered "Diet Coca-Cola". Since the cost of registering a mark is so low, there's really no reason not to for any sort of large organization. Besides, after you do that, you get to use the nifty little circled "R".
In my own case, I run a small business out of my home in my spare time, and I claim several trademarks which I have never registered. Since the business is so small, the cost of registering isn't worth it - unlike Diet Coca-Cola and Windows 365. I'm relying on the fact that I've claimed the trademarks on my websites over the years and used them in commerce - which is really the essential element of any trademark. If there's ever any dispute about my little trademarks, we can always use archive.org to prove when I first used them to anyone who cares.
Again, IANAL, but I play one on TV. When your business is as small as mine, it's good to have an amateur lawyer on staff (me), even if he has no formal legal training or credentials.
Registering a trademark is cheap, especially for any outfit that's large enough to have their own lawyers already on staff. So, there isn't much percentage in trying to read anything big into the registering of a trademark. In this case, they would need no greater reason to trademark "Windows 365" than the fact that they already have some related trademarks.
Good question. I asked something similar in a comment the last time this question was asked, only about a week ago but nobody provided an answer. Maybe we'll get one this time.
My own thought was to use 7-zip to make strongly encrypted 7z files, but somebody can suggest something better. In particular, it would be nice if such a tool could automatically do the uploading/downloading to/from the storage provider, which 7-zip doesn't do.
You assume the software is bug free to begin with.
No, I assume that making ostensibly non-funtional changes to functioning code is more likely to introduce bugs than to accidentally remove them. The primary goal at that stage is to not make it worse.
Anyway, with all that experience you have with theorem proving and compiler design, etc, I can see why you don't bother with any automatic aids to assure that changes don't accidentally make things worse.
In my own case, I often do what I call "code algebra", which are small refactorings that are intended to leave the functioning of the code unchanged. Unfortunately, try as I might, I sometimes make mistakes along the way. That's why I seek mechanical help where available - and why I so greatly admire those of you who don't need any.
I really gotta look into that theorem proving and compiler designing stuff - maybe that's the piece of the puzzle that I've been missing all these years.
Agreed. I bought a mid-range Nikon DSLR a couple of years ago (after having spent many years in film photography as a Nikon guy), but I end up still mostly using either my aging Canon prosumer G9 point-and-shoot or the cheap cell phone that's in my pocket.
Sadly, my old vintage Nikon lenses aren't nearly as useful as I thought they would be because even though some are nominally compatible, you give up so many automatic features that even those aren't very useful. So much for Nikon's famous backwards-compatible lenses. I haven't invested in modern Nikon lenses except for the ones that came in the camera kit because I'm not a serious enough photographer to fork out the dough.
Given all that, and since most of us already have more megapixels than we ever need, there doesn't seem to be much reason to buy any new digital cameras until one breaks.
Then you start working by removing dead code, indenting, do static and run-time code analysis to find bugs, then merge duplicate code. Start with the more mechanical parts first. Once you get that working and bug free you basically have the new version 1.0.
I didn't see anything about tests? How will you know it is "working and bug free" without them?
In my experience, one of the most dangerous things you can do is to change working code in a mechanical way that should be safe. Whenever I do that, I always use something to make sure the code is unchanged. If the change is strictly cosmetic, something like Beyond Compare can be used for that. Otherwise, you need module tests that fully characterize the existing code via functional testing with complete condition/decision coverage. Or, maybe there's some tool that can be used to compare code at the level of its abstract syntax tree or whatever to ensure that its functionality is unchanged. (Does anybody know of something like that? - a Clang tool, maybe?)
Of course, this is taking a very conservative approach. But doing "safe" changes manually on a large (or even medium) code base without some sort of automated safety net is a sure way to introduce difficult-to-find bugs. Caveat emptor.