If programmers can be held criminally responsible for the misdeeds of their employer (which they carry out), then what about all the assholes on Wall Street with the mortgage backed securities scams and all that...
The really scary part is: those securities weren't a scam. People actually thought they made sense. There are lots of other crazy, similar financial products those same people think make sense today. Approaching 1 quadrillion dollars (no joke) of CDSs. What a mess.
The biggest mistake was to start the description with 'It's a database...'
Remember when Microsoft made that mistake with their "revolutionary new filesystem" that never actually made it to release? There are actually some storage systems that work that way, but they really suck to work with (and tend to only support some tiny number of files, usually less than a million).
You don't know how file systems work, though you were able to summarize about half the concerns, in a way that ignores both the OS-specific driver stuff and all the messy details. That's the thing about storage - the job is 95% about the messy details.
I find too few candidates can even describe to me why doing file access in 2 threads helps. I've just stopped asking, as long as they get that it does help, that's what important these days (now that I don't work in storage!).
Jobs don't pay fixed amounts - the pay varies based on the candidate. Companies, OTOH, have discoverable reputations as to where they pay relative to the industry - though you have to be careful, as that can vary by pay grade. And for sure the first conversation I have with any recruiter includes telling them m current comp, so that we don't waste each others' time.
How it works is very relevant if you care about performance.
You should care about performance.
I'd say there are few areas where in-memory performance still matters, but writing a compiler is the most important!
Or to out it a different way, if a guy claims to have written an efficient sort (part of the C++ STL), now do you care whether he knows how to write one?
You don't seem to get my point at all. There are lots of things the government could spend money on to make things better. You listed some. Great. Few "fiscal conservatives" would argue about most of it (there's always something any given person thinks is a waste). That's not at all the problem.
The problem is you have limited funds and must make hard choices and trade-offs. There may be 20 great things you can do, but you have to pick some set of 12. Someone who's not fiscally conservative is like the manager who I ask "we don't have the resources to deliver all these features this year, what's the priority list - can we stack rank them?" and who answers "they're all priority 1!".
Yes, of course, everyone gets it - cutting spending anywhere will hurt some program that helps some group of people. Debating that is not debating the virtue of fiscal conservatism. The assertion of fiscal conservatives is "keep spending low enough such that you keep debt down to a small % of GDP". You can argue about whether some new tax plan will raise revenue, or that some proposed spending will goose the economy, but that's orthogonal to the assertion that "well, however that works out, let's not spend (much) more than what we actually earn each year".
But voters have lost the will to understand there are hard choices to be made. We've lost that "who needs the government, we can do it ourselves" spirit, and just keep voting for more free shit, with no concern about where it all ends. Well, that's democracy for you - we get the government we deserve.
I've found that about 15-20% of all people in all fields are bad. Medical is one of the few exceptions to that, because of the additional hurdles designed to remove the lower performers.
The guy who graduates bottom of his class from med school is still a doctor. Most people don't meet the bottom 15-20% of doctors, but they're out there: they're the ones who accept Medicaid.
Heh, I wouldn't choose PKI for anything important nowadays. None of the methods are provably hard, and we just have to take the NSA's word that any particular method is. If someone asked me "how PKI works", sure, I could talk about that, but that wasn't the question!
All programming jobs start out paying shit, but there's a huge gap even by mid-career. Maybe companies who hire both pay about the same, but I don't think any of the big software companies that pay top quartile hire devs who are only good for "basic apps" in the first place (or at least they try not to, interviewing being a measurement system with a large error bar).
FWIW, I think that's a mistake. Why trust the opaque "encryption" feature of the application like Excel or acrobat when you can use something well-proven?
Well, if you're interviewing someone from the Office or Acrobat team, you could have a great interview discussion about it! I'd at least ask "why should I trust that - have you worked on that closed source, or had it audited, or something?" Maybe the answer will surprise you.
I've never needed to do any such thing, and it's been 20-mumble years since college, but I can damn well answer such a trivial question, as fast as I can write. If you can't, then IMO you can't solve very basic coding problems. I don't like or use this question, because it's one people memorize, but I'd be quite comfortable rejecting anyone who couldn't figure it out (making allowances if they don't remember C pointer syntax, but still got the approach right).
For what it's worth, the best interview I've ever had was mostly nonspecific questions. In the interest of making the world a better place, here's a few of the questions:
On that blank whiteboard, go draw a system you worked on and explain it.
The best interview question I was ever asked (for a senion dev position) was:
"On that blank whiteboard, go draw this system I worked on and explain it."
Obviously, he wasn't expecting me to answer in an hour what had take a team a months to do, but they had had lengthy discussions about the pros and cons of a variety of designs, and so he could tell beyond just his opinion whether my idea was one of the smarter or dumber ones from that design process.
For the curious, the system was VMware's vmotion - moving a running VM from one host to another without disruption. None of the details were relevant to the job I was applying for, but my design skills and intuitions were. I really enjoyed that interview session.
You aren't evaluating candidates. You are making a common interviewing mistake and fishing for specific answers. You (wrongly) assume that a matching answer is a good answer.
To put it another way, "what do I have in my pocket?" is not a legitimate riddle!
Was about to say the same - that's exactly what I do with my tax guy, who has no technical skills at all. Damn you Hudson for saying something I can't disagree with.
You can do anything in any Turing-complete language, of course, but it's hard to challenge what people are used to. That's why I stopped doing C++ professionally - scoped objects give better resource management and leak prevention than managed code, but the approach is too far from what most C++ coders are used to.
"Data" classes have no promise of consistency, and no business logic (and no interface really). They're just a bucket of fields that travel together. It's rare that we would validate all fields in one place anyhow - there's the trivial stuff like the port being in range, sure, then there's more elaborate but still stateless checks you do further in, then there might be stateful validation that you have to do a DB query for and so on. You pass the data object down through the usual layers of control objects, which understand various things about the system and validate what they can before they do what they need to.
So sure, you could add setters that would do some partial checks up front, but you can't really prove anything beyond "well-formed" - which is a far cry from validation.
"Control" classes are different. They have very strong consistency promises, formal interfaces, don't have setters unless required for some silly framework, take whatever state needed through the constructor, and don't expose their internal state at all beyond perhaps come sort of name or ID. Internal state is often discovered through probing the system or DB queries or whatever the class does to be fully initialized. Ideally all internal state is final anyhow, unless the point of the class is to poll or monitor of some data that constantly changes and take action on it.
The separation of data and control classes is a powerful technique, great for task processing, request servicing, and so on, where you're routing a request through your system in some complex way until it finds the place that can actually do the work requested. The data class has no dependencies to drag in to the place where it's created/submitted (often by code that's very walled off from the codebase where your business logic lives).
Greece cut pay to bunches of govt employees (and pensions) because they couldn't borrow at the rate they needed to pay them, and something had to give. I remember the many riots in the news, but that which cannot be paid will not be paid. Greece has been forced to spend less for many years now, so it's hard to say what range of years you're talking about. Naturally that environment sucked for economic growth, and screwed what was left of the economy, but that which cannot be paid will not be paid.
But my entire point is: we can gradually cut spending starting soon, and avoid cutting infrastructure and the like (defense and "mailing checks to people" is ~80% of US government spending, no need for any less infrastructure building). Or we can wait until we have no choice but to go the way Greece went, because that which cannot be paid will not be paid. We won't of course, because "mailing checks to voters" will continue to be quite popular with voters, and we keep rapidly expanding the pool who gets such checks - I think it's already over half.
In C++ you can at least have the standard that an object is either a class, with all members private and no setters (and a good argument needed for getters), or a struct with everything public, no consistency promises, but often some sort of isValid method or operator to check consistency when needed. You also have macros for boilerplate elimination, and at least vector<int> works, unlike the sad state of container classes in Java (seriously Java devs, that shit was forgivable for one release).
Ada has some really wonderful features that were ignored by other languages because it's so bad in other ways. It's a damn shame. And later contract-based languages like Eiffel were also ignored, which is even more pointless. Java was a regrettable exercise in "let's do C++ without the cruft" instead of "lets pull all the best stuff from academic PL design". Sad, really.
a lot of the serious work is done where the class holds one or more data instances and working variables as well as the logic that will be performed on them.
Sure, but does it really make sense to have getters and setters for those variables? The only such pattern I find common is where you need a getter for some sort of ID or name, something "final" in any case. By "control" class I don't mean static: they often have internal state.
Sure but that's a fairly rare case, at least on the code I work on, where inexpensive field validation (other than not null) is useful. Port of course doesn't need explicit validation either, Java needs unsigned ints, but that's a different rant.
Also, of course, you have a bug in your regex. Also, of course, I once spent a year of my life purging every place in a huge codebase where some idiot thought a network address was an int - TCP does not only layer on top of IPv4! So many DB schema changes for IPv6 support, so few bytes saved by thinking "int" was clever.
Sure, but you shouldn't be reading an uninitialized variable - the compiler should stop that. You sure as Hell shouldn't be passing it to a function, which passes it down through 6 layers until you finally get that null reference exception far from where the bug was - perhaps Java's most common problem. Except of course, the chain usually starts with returning null, and there's just no non-awkward way to enforce that contract in Java.
In the majority of cases, it's just not semantically valid for a data member of function parameter to be null. That it's syntactically valid is just a bug in the language. If it's not a legitimate state, the compiler shouldn't wait for runtime to complain. And certainly you shouldn't have to manually write null-checking code in most cases!
With proper contacts, where every function must declare something special if a value is allowed to be null, the complier should complain any time you try to set a non-nullable value to a nullable result - catch the bug at compile time. Java does a similar check well today, by ensuring at compile time that you can't use an uninitialized variable, even with complex branching. Compile-time null reference prevention should be just as convenient.
But then, Java can't even manage List, so it's not like it's going to get ideas from the past 20 years right.
Maybe it depends on your field. I use them frequently. From functions that take to many arguments to be practical, to systems with many pass-through layers, to task models that go through multiple serialization-deserialization steps, so simply capturing a state or context for asynch servicing. Seems pretty normal for systems programming.
Slashdot Mirror
If programmers can be held criminally responsible for the misdeeds of their employer (which they carry out), then what about all the assholes on Wall Street with the mortgage backed securities scams and all that...
The really scary part is: those securities weren't a scam. People actually thought they made sense. There are lots of other crazy, similar financial products those same people think make sense today. Approaching 1 quadrillion dollars (no joke) of CDSs. What a mess.
The biggest mistake was to start the description with 'It's a database ...'
Remember when Microsoft made that mistake with their "revolutionary new filesystem" that never actually made it to release? There are actually some storage systems that work that way, but they really suck to work with (and tend to only support some tiny number of files, usually less than a million).
You don't know how file systems work, though you were able to summarize about half the concerns, in a way that ignores both the OS-specific driver stuff and all the messy details. That's the thing about storage - the job is 95% about the messy details.
I find too few candidates can even describe to me why doing file access in 2 threads helps. I've just stopped asking, as long as they get that it does help, that's what important these days (now that I don't work in storage!).
Jobs don't pay fixed amounts - the pay varies based on the candidate. Companies, OTOH, have discoverable reputations as to where they pay relative to the industry - though you have to be careful, as that can vary by pay grade. And for sure the first conversation I have with any recruiter includes telling them m current comp, so that we don't waste each others' time.
How it works is very relevant if you care about performance.
You should care about performance.
I'd say there are few areas where in-memory performance still matters, but writing a compiler is the most important!
Or to out it a different way, if a guy claims to have written an efficient sort (part of the C++ STL), now do you care whether he knows how to write one?
You don't seem to get my point at all. There are lots of things the government could spend money on to make things better. You listed some. Great. Few "fiscal conservatives" would argue about most of it (there's always something any given person thinks is a waste). That's not at all the problem.
The problem is you have limited funds and must make hard choices and trade-offs. There may be 20 great things you can do, but you have to pick some set of 12. Someone who's not fiscally conservative is like the manager who I ask "we don't have the resources to deliver all these features this year, what's the priority list - can we stack rank them?" and who answers "they're all priority 1!".
Yes, of course, everyone gets it - cutting spending anywhere will hurt some program that helps some group of people. Debating that is not debating the virtue of fiscal conservatism. The assertion of fiscal conservatives is "keep spending low enough such that you keep debt down to a small % of GDP". You can argue about whether some new tax plan will raise revenue, or that some proposed spending will goose the economy, but that's orthogonal to the assertion that "well, however that works out, let's not spend (much) more than what we actually earn each year".
But voters have lost the will to understand there are hard choices to be made. We've lost that "who needs the government, we can do it ourselves" spirit, and just keep voting for more free shit, with no concern about where it all ends. Well, that's democracy for you - we get the government we deserve.
I've found that about 15-20% of all people in all fields are bad. Medical is one of the few exceptions to that, because of the additional hurdles designed to remove the lower performers.
The guy who graduates bottom of his class from med school is still a doctor. Most people don't meet the bottom 15-20% of doctors, but they're out there: they're the ones who accept Medicaid.
Heh, I wouldn't choose PKI for anything important nowadays. None of the methods are provably hard, and we just have to take the NSA's word that any particular method is. If someone asked me "how PKI works", sure, I could talk about that, but that wasn't the question!
All programming jobs start out paying shit, but there's a huge gap even by mid-career. Maybe companies who hire both pay about the same, but I don't think any of the big software companies that pay top quartile hire devs who are only good for "basic apps" in the first place (or at least they try not to, interviewing being a measurement system with a large error bar).
FWIW, I think that's a mistake. Why trust the opaque "encryption" feature of the application like Excel or acrobat when you can use something well-proven?
Well, if you're interviewing someone from the Office or Acrobat team, you could have a great interview discussion about it! I'd at least ask "why should I trust that - have you worked on that closed source, or had it audited, or something?" Maybe the answer will surprise you.
I've never needed to do any such thing, and it's been 20-mumble years since college, but I can damn well answer such a trivial question, as fast as I can write. If you can't, then IMO you can't solve very basic coding problems. I don't like or use this question, because it's one people memorize, but I'd be quite comfortable rejecting anyone who couldn't figure it out (making allowances if they don't remember C pointer syntax, but still got the approach right).
For what it's worth, the best interview I've ever had was mostly nonspecific questions. In the interest of making the world a better place, here's a few of the questions:
On that blank whiteboard, go draw a system you worked on and explain it.
The best interview question I was ever asked (for a senion dev position) was:
"On that blank whiteboard, go draw this system I worked on and explain it."
Obviously, he wasn't expecting me to answer in an hour what had take a team a months to do, but they had had lengthy discussions about the pros and cons of a variety of designs, and so he could tell beyond just his opinion whether my idea was one of the smarter or dumber ones from that design process.
For the curious, the system was VMware's vmotion - moving a running VM from one host to another without disruption. None of the details were relevant to the job I was applying for, but my design skills and intuitions were. I really enjoyed that interview session.
You aren't evaluating candidates. You are making a common interviewing mistake and fishing for specific answers. You (wrongly) assume that a matching answer is a good answer.
To put it another way, "what do I have in my pocket?" is not a legitimate riddle!
Was about to say the same - that's exactly what I do with my tax guy, who has no technical skills at all. Damn you Hudson for saying something I can't disagree with.
You can do anything in any Turing-complete language, of course, but it's hard to challenge what people are used to. That's why I stopped doing C++ professionally - scoped objects give better resource management and leak prevention than managed code, but the approach is too far from what most C++ coders are used to.
"Data" classes have no promise of consistency, and no business logic (and no interface really). They're just a bucket of fields that travel together. It's rare that we would validate all fields in one place anyhow - there's the trivial stuff like the port being in range, sure, then there's more elaborate but still stateless checks you do further in, then there might be stateful validation that you have to do a DB query for and so on. You pass the data object down through the usual layers of control objects, which understand various things about the system and validate what they can before they do what they need to.
So sure, you could add setters that would do some partial checks up front, but you can't really prove anything beyond "well-formed" - which is a far cry from validation.
"Control" classes are different. They have very strong consistency promises, formal interfaces, don't have setters unless required for some silly framework, take whatever state needed through the constructor, and don't expose their internal state at all beyond perhaps come sort of name or ID. Internal state is often discovered through probing the system or DB queries or whatever the class does to be fully initialized. Ideally all internal state is final anyhow, unless the point of the class is to poll or monitor of some data that constantly changes and take action on it.
The separation of data and control classes is a powerful technique, great for task processing, request servicing, and so on, where you're routing a request through your system in some complex way until it finds the place that can actually do the work requested. The data class has no dependencies to drag in to the place where it's created/submitted (often by code that's very walled off from the codebase where your business logic lives).
Greece cut pay to bunches of govt employees (and pensions) because they couldn't borrow at the rate they needed to pay them, and something had to give. I remember the many riots in the news, but that which cannot be paid will not be paid. Greece has been forced to spend less for many years now, so it's hard to say what range of years you're talking about. Naturally that environment sucked for economic growth, and screwed what was left of the economy, but that which cannot be paid will not be paid.
But my entire point is: we can gradually cut spending starting soon, and avoid cutting infrastructure and the like (defense and "mailing checks to people" is ~80% of US government spending, no need for any less infrastructure building). Or we can wait until we have no choice but to go the way Greece went, because that which cannot be paid will not be paid. We won't of course, because "mailing checks to voters" will continue to be quite popular with voters, and we keep rapidly expanding the pool who gets such checks - I think it's already over half.
Yeah, I have no idea what you're talking about. What "attempted cure" did you have in mind? I was guessing "austerity", but I could only guess.
In C++ you can at least have the standard that an object is either a class, with all members private and no setters (and a good argument needed for getters), or a struct with everything public, no consistency promises, but often some sort of isValid method or operator to check consistency when needed. You also have macros for boilerplate elimination, and at least vector<int> works, unlike the sad state of container classes in Java (seriously Java devs, that shit was forgivable for one release).
Ada has some really wonderful features that were ignored by other languages because it's so bad in other ways. It's a damn shame. And later contract-based languages like Eiffel were also ignored, which is even more pointless. Java was a regrettable exercise in "let's do C++ without the cruft" instead of "lets pull all the best stuff from academic PL design". Sad, really.
a lot of the serious work is done where the class holds one or more data instances and working variables as well as the logic that will be performed on them.
Sure, but does it really make sense to have getters and setters for those variables? The only such pattern I find common is where you need a getter for some sort of ID or name, something "final" in any case. By "control" class I don't mean static: they often have internal state.
Sure but that's a fairly rare case, at least on the code I work on, where inexpensive field validation (other than not null) is useful. Port of course doesn't need explicit validation either, Java needs unsigned ints, but that's a different rant.
Also, of course, you have a bug in your regex. Also, of course, I once spent a year of my life purging every place in a huge codebase where some idiot thought a network address was an int - TCP does not only layer on top of IPv4! So many DB schema changes for IPv6 support, so few bytes saved by thinking "int" was clever.
Sure, but you shouldn't be reading an uninitialized variable - the compiler should stop that. You sure as Hell shouldn't be passing it to a function, which passes it down through 6 layers until you finally get that null reference exception far from where the bug was - perhaps Java's most common problem. Except of course, the chain usually starts with returning null, and there's just no non-awkward way to enforce that contract in Java.
In the majority of cases, it's just not semantically valid for a data member of function parameter to be null. That it's syntactically valid is just a bug in the language. If it's not a legitimate state, the compiler shouldn't wait for runtime to complain. And certainly you shouldn't have to manually write null-checking code in most cases!
With proper contacts, where every function must declare something special if a value is allowed to be null, the complier should complain any time you try to set a non-nullable value to a nullable result - catch the bug at compile time. Java does a similar check well today, by ensuring at compile time that you can't use an uninitialized variable, even with complex branching. Compile-time null reference prevention should be just as convenient.
But then, Java can't even manage List, so it's not like it's going to get ideas from the past 20 years right.
Maybe it depends on your field. I use them frequently. From functions that take to many arguments to be practical, to systems with many pass-through layers, to task models that go through multiple serialization-deserialization steps, so simply capturing a state or context for asynch servicing. Seems pretty normal for systems programming.