(Reiterating some things others have said already, I'm sure.)
A "Software test engineer" job can mean pretty much anything, and you should find out before accepting.
It can be focused on finding bugs, or on ticking off a list of tests to have passed before shipping.
It can be close to the code, or with the product as a black box.
It can be detailed functional tests, performance tests, or big statistical simulations running for days or weeks.
It can be work together with the developers, or completely isolated from them.
It can be manual GUI testing, automated, or with a complex mix of test tools
The tester can be (perceived as) a low-level grunt, or as the person who knows the product the best;
the end users' only representative.
Pity, because some of that is written by actual physics professors and talks about speculative (but possible) areas of real science, which is what you seem to be demanding in your fist sentance there.
He wasn't -- he was rather pointing out that Frankenstein doesn't rock because of its scientific accuracy.
Oops. sorry, I meant to infer that I love Frankenstein - not because it "predicted" anything but because it showed how Dr. Frankenstein was ultimately confronted by his creation and, in a way, became the model for God for the "monster". That the monster found atheism because his creator was fallible. Please don't take my rant wrong -- science fiction is not about the "future" it is about the human condition.
No need to apologize; what you meant was clear (although I too missed it at the first reading...)
You're a douche. In an economy where many people have been unemployed for so long that they're just dropping out of the workforce altogether, you're fretting over "FUD" because your company did a normal thing and switched products?
*Which* economy, and what nice? There's plenty of work for programmers here in.se, if you have some experience.
I work in the embedded area (however you define that) and don't have to touch Windows apart from the odd MS Word document.
We don't produce Open Source, but the target environment is Linux and other non-Windows things.
That article reads like a list of every stupid idea a project manager has ever had. Here's an idea: keep the status meetings to once a week major changes in the project, keep individuals informed of changes that affect them as they happen,
If it's scrum, there are no such external changes, so that becomes unnecessary.
Also, weekly status meetings tend to suck. The only good thing with them is that they only happen once a week... until the situation becomes serious and the PHB decides to have them twice a week.
and let the workers do the work. When we're done, we'll update the feature/bug tracking system to indicate that we're done and move on. The tracking system will then notify the next person down the line (QA, build, PM, whoever) that something is ready for them,
One (minor) problem which the daily meeting which I've noticed is that it can decrease the quality of the contents of those tools:
"Oh, didn't I pick up that ticket? No big deal; I told you at the meeting yesterday that I'm working on it."
and if they have questions they can come talk to us directly, one on one.
They will have to do that anyway; the meeting is not the right place for detailed technical questions.
It's supposed to make you *aware* that there's a question you have to ask *later*.
Go back to the agile manifesto, and screw off with all the buzzword-laden process crap.
You probably didn't RTFA, but where's the buzzword-laden process crap in all this, and how does it contradict the agile manifesto?
Do you all even talk to each other? Like, getting up and vocalizing rather than fucking off on Facebook all day?
That is a really stupid point. Yes developers get up and talk, but usually to just one or two at a time through the day. The value of the (incredibly brief) standup is that everyone hears what everyone else says, all at once.
True. But there *is* a danger though that the daily scrum meeting hinders communication.
I work in a semi-scrum team, and I have a tendency to postpone talking to someone or calling some problem to
everyone's attention until the meeting.
And then at 15:00 the meeting focuses on something else (like making the burn-down chart look good),
and you don't have time to explain your problem in enough detail.
The daily meeting must not be the main means of communication in a small team.
Hey, wait! I recognize that brand of anger mixed with ignorance! You are the Dijkstra asshole!
I wish it had been a brand of anger mixed with insight; then he would have been Dijkstra.
Me too! Instead, I did it on a random day where I was bored, about 4 years ago. Took about 2 hours and I haven't thought about it since.
I did it on January 1st this year -- had a HE tunnel already, but started using the routed/64 on my home network.
Some of my internet traffic (1% or so) goes over IPv6 -- mostly the Debian security updates since my browser (Opera; embarrassing) doesn't support IPv6.
The really neat thing about brain teasers or puzzles or the bizarre questions you sometimes encounter like "How many pigeons are there is Manhattan" is that they are a very good way to judge someone's unstructured problem solving ability. How someone approaches this kind of a problem is a good proxy for their ability to debug hard technical issues or their problem solving ability in general.
This is really not true. My response to questions like that improved dramatically when I read an article that explained questions way out of left field like that are intended to test your problem solving ability, so do your best to estimate an answer and explain your thought process. Reading that article didn't make me better at debugging hard technical issues, but made me dramatically better at handling off-the-wall interview questions nimbly. You're not measuring what you think you're measuring.
Or, you could say it measures whether you've read Jon Bentley's Programming Pearls or not.
It ends with a bunch of questions like that (because he feels estimation is an important skill).
Dave, can I just say one thing? Nice work. Thank you.
Yes -- thank you for allowing me to tinker with a sane computer in the pre-Linux era.
I've said it before and I'll say it again:
most competent programmers I meet (in the embedded niche) turn out to have
used an Amiga in their youth. I'm grateful for that, too.
Well, if you turned on the Amiga without media, all you got was a screen saying to insert a disk. But if you did load workbench, you might have gotten a programming environment. Amiga's included Amiga Basic through Amiga OS 1.3, which was pretty equivalent to Mac Basic. I remember sharing programs with a friend who had a Mac. You're absolutely right that it was less discoverable than the C=64. You had to find it, it wasn't in your face.
Right, using the Amiga the right way (at least before Workbench 2.0 and hard drives)
meant creating your own boot floppies with the Workbench stuff discarded in favor of ARP and various
other third-party utilities from the Fred Fish repository.
I never used a C64, but I can imagine that a "factory defaults" Amiga would feel empty to a C64 user.
Look at all the case: statements in a switch - they're all GOTOs (the case: is a label). So are your virtual method tables. The break; statement also does a goto to the next instruction after the enclosing set of statements (switch, for, whatever).
Uh, those are *not* gotos. GOTO is a statement GOTO label
and nothing else[1]. switch, break, continue and run-time polymorphism
may or may not have some problems in common with goto but there is no logic which says that if you
accept one of them you must not criticise goto.
[1] Modulo variants WRT where the label is allowed to be: in the same function, anywhere in the same
source file, and so on.
One of the key difficulties is if you are including attachments in encrypted e-mails. This often results in your e-mail being quarantined by (depending on your viewpoint) over judicious anti-virus software as it is unable to scan the encrypted e-mail and guarantee it is virus-free. Your e-mail never arriving rather defeats the purpose of sending it in the first place.
Surely you're not talking about OpenPGP here -- I'm pretty sure the whole body is encrypted there and noone can tell if it's one long piece of text or a dozen attached.exe viruses.
Also, citation needed. I don't see why an anti-virus company would be smart enough to acknowledge the
existence of encryption, and at the same time stupid enough to forbid it.
..."session keys". The content is encrypted with a random number (the session key), and this random number is in turn encrypted with the recipients' private keys. As the content is usually compressed too before encryption, the result may even be a smaller e-mail than without...
Thats really neat -- is it part of the regular email clients?
Create a page document shows guidelines on how to submit bug reports, and send an email to all users that says that this is where the guidelines for filing bug reports live.
When you get a report that doesn't help, close the report with a referral to said document.
Better, have a form letter ready saying:
"You filed this bug report, but we cannot do anything about it yet because vital information is missing.
Specifically:
[list of common reasons; you place a checkmark at those which apply before mailing the response]
Please also see $document. Regards, the programmers."
Useless bug reports are no big problem if you can keep track of them, and is allowed to ignore them
until the submitter fills in the missing information.
For Windows developers at least, there is one spectacular piece of the OS to make use of for bug reports. Mini-dumps. So awesome I wish Linux had an equivalent.
Uh, Linux and the rest of the Unix world has had it for 30+ years. It's called a "core dump".
Take a look at WP's article on Robert Heinlein and then at SFE's. Both have useful material. [...] The SFE article is more useful if you're looking for critical commentary, since POV (point of view) is verboten on Wikipedia.
And this is a major difference. The SF Encyclopedia sucks in many, many ways but at least if you look
up (say) an author you get a mainstream overview of his writing (I suppose "critical commentary" is the right term). With the WP you get hard facts but still can't tell if this might be an author worth reading.
The SFE article on Theodore Sturgeon was excellent.
It's more ignorant to think that users need to know the underlying system or how URL is formed to use computer or internet. Truth is, no one wants to have to learn things they don't care about. While you may think it's essential for everyone to know how computers operate, many people think otherwise.
An URL is not "how computers operate" -- it *is part of the user interface*.
And the important parts are harder to understand than the concept of a phone number or any number of other things
which people seem perfectly able to cope with.
(The worst problem in that area is probably not browser user interfaces but server admins who produce garbage URLs.)
But I found those questions trivial without a calculator, how you'd manage to fail with a calculator is beyond me.
Yes -- when I first read the summary, I assumed it was questions about things like long division -- algorithms which you learn as a kid, then forget because you never use them.
But the actual questions were common-sense ones which you *do* exercise in normal adult life.
True. I wish more C++ programs aimed towards a more Smarter-C-Than-C style instead of the typical style of wanting to use every feature and use them badly
Here I agree...
(templates I hate because they're misused to very often, the language was just fine without them).
... but here you're talking crazy, or what you've seen falls into the "and use them badly" category.
The language was *not* fine without them. For one thing, it had no string types, no containers and no standard library except the C subset.
The lack of these things in real-world C++ environments until 2000 or so was *incredibly* damaging.
C++ provides several very fundamental features which make it hugely superior to C: inline functions, better const semantics, reference types, and templates.
C has had inline functions for at least a decade. [...]
They aren't widely used though, in the projects I've seen (except the Linux kernel).
Part of my job is to replace ugly, unsafe multi-line macros with inline functions...
something which was only made possible earlier this year (2011), when we ditched our
last C compiler which didn't understand C99.
Which brings us back to part of TFA: it's hard to change a language which is widely used,
and harder to make the programmers use the new stuff.
(Personally I still think it's the way to go.)
What does it matter? If you don't want to use it, it never gets in the way.
Did you read what he wrote?
He believes the browser would be better if Opera's developers could focus on just doing a browser, rather than
a browser-and-mail-usenet-bittorrent-client-and-...
We have SCTP which was intended to replace TCP except nobody seems to care.
Some telecom standards are built on SCTP (we use it at work).
Not sure if it's all that great though -- a lot of its problems are probably hidden by the fact that
few care about it, and that it's used in isolated, high-quality networks.
At the end of the day the concept of TCP is not rocket science - there is a limit and diminishing returns to what more can be done twoard making TCP a perfect reflection of the concept of TCP. [---] In my opinion we need more IP protocols to better handle varied use cases more than we need a new TCP.
And we need application-level protocols on top of TCP which suck less,
and implementations which suck less.
You need some elemental understanding of TCP to use it efficiently, and from what I've seen, most programmers
don't have it.
PS. As I recall it, last time Getty was in the media with his buffer bloat theory, several high-profile TCP experts (e.g. John Nagle) criticized him. We may be reacting to nonsense here.
Slashdot Mirror
A "Software test engineer" job can mean pretty much anything, and you should find out before accepting.
It can be focused on finding bugs, or on ticking off a list of tests to have passed before shipping.
It can be close to the code, or with the product as a black box.
It can be detailed functional tests, performance tests, or big statistical simulations running for days or weeks.
It can be work together with the developers, or completely isolated from them.
It can be manual GUI testing, automated, or with a complex mix of test tools
The tester can be (perceived as) a low-level grunt, or as the person who knows the product the best; the end users' only representative.
Pity, because some of that is written by actual physics professors and talks about speculative (but possible) areas of real science, which is what you seem to be demanding in your fist sentance there.
He wasn't -- he was rather pointing out that Frankenstein doesn't rock because of its scientific accuracy.
Oops. sorry, I meant to infer that I love Frankenstein - not because it "predicted" anything but because it showed how Dr. Frankenstein was ultimately confronted by his creation and, in a way, became the model for God for the "monster". That the monster found atheism because his creator was fallible. Please don't take my rant wrong -- science fiction is not about the "future" it is about the human condition.
No need to apologize; what you meant was clear (although I too missed it at the first reading ...)
You're a douche. In an economy where many people have been unemployed for so long that they're just dropping out of the workforce altogether, you're fretting over "FUD" because your company did a normal thing and switched products?
*Which* economy, and what nice? There's plenty of work for programmers here in .se, if you have some experience.
I work in the embedded area (however you define that) and don't have to touch Windows apart from the odd MS Word document. We don't produce Open Source, but the target environment is Linux and other non-Windows things.
That article reads like a list of every stupid idea a project manager has ever had. Here's an idea: keep the status meetings to once a week major changes in the project, keep individuals informed of changes that affect them as they happen,
If it's scrum, there are no such external changes, so that becomes unnecessary. Also, weekly status meetings tend to suck. The only good thing with them is that they only happen once a week ... until the situation becomes serious and the PHB decides to have them twice a week.
and let the workers do the work. When we're done, we'll update the feature/bug tracking system to indicate that we're done and move on. The tracking system will then notify the next person down the line (QA, build, PM, whoever) that something is ready for them,
One (minor) problem which the daily meeting which I've noticed is that it can decrease the quality of the contents of those tools: "Oh, didn't I pick up that ticket? No big deal; I told you at the meeting yesterday that I'm working on it."
and if they have questions they can come talk to us directly, one on one.
They will have to do that anyway; the meeting is not the right place for detailed technical questions. It's supposed to make you *aware* that there's a question you have to ask *later*.
Go back to the agile manifesto, and screw off with all the buzzword-laden process crap.
You probably didn't RTFA, but where's the buzzword-laden process crap in all this, and how does it contradict the agile manifesto?
Do you all even talk to each other? Like, getting up and vocalizing rather than fucking off on Facebook all day?
That is a really stupid point. Yes developers get up and talk, but usually to just one or two at a time through the day. The value of the (incredibly brief) standup is that everyone hears what everyone else says, all at once.
True. But there *is* a danger though that the daily scrum meeting hinders communication. I work in a semi-scrum team, and I have a tendency to postpone talking to someone or calling some problem to everyone's attention until the meeting. And then at 15:00 the meeting focuses on something else (like making the burn-down chart look good), and you don't have time to explain your problem in enough detail.
The daily meeting must not be the main means of communication in a small team.
Hey, wait! I recognize that brand of anger mixed with ignorance! You are the Dijkstra asshole!
I wish it had been a brand of anger mixed with insight; then he would have been Dijkstra.
Me too! Instead, I did it on a random day where I was bored, about 4 years ago. Took about 2 hours and I haven't thought about it since.
I did it on January 1st this year -- had a HE tunnel already, but started using the routed /64 on my home network.
Some of my internet traffic (1% or so) goes over IPv6 -- mostly the Debian security updates since my browser (Opera; embarrassing) doesn't support IPv6.
dhcp6 is evil. just enable route advertisements
How would a DNS server's IPv6 address be advertised in such a manner? I can't look it up myself due to the SOPA strike.
There is an RFC for that. I can't recall which one, but you can tell radvd(8) to hand out DNS addresses.
Java has changed the face of mobile computing within the past decade.
Java didn't change it; cell phone vendors just implemented support for Java and nothing else, for reasons which are still unclear to me.
This is really not true. My response to questions like that improved dramatically when I read an article that explained questions way out of left field like that are intended to test your problem solving ability, so do your best to estimate an answer and explain your thought process. Reading that article didn't make me better at debugging hard technical issues, but made me dramatically better at handling off-the-wall interview questions nimbly. You're not measuring what you think you're measuring.
Or, you could say it measures whether you've read Jon Bentley's Programming Pearls or not. It ends with a bunch of questions like that (because he feels estimation is an important skill).
Dave, can I just say one thing? Nice work. Thank you.
Yes -- thank you for allowing me to tinker with a sane computer in the pre-Linux era. I've said it before and I'll say it again: most competent programmers I meet (in the embedded niche) turn out to have used an Amiga in their youth. I'm grateful for that, too.
Well, if you turned on the Amiga without media, all you got was a screen saying to insert a disk. But if you did load workbench, you might have gotten a programming environment. Amiga's included Amiga Basic through Amiga OS 1.3, which was pretty equivalent to Mac Basic. I remember sharing programs with a friend who had a Mac. You're absolutely right that it was less discoverable than the C=64. You had to find it, it wasn't in your face.
Right, using the Amiga the right way (at least before Workbench 2.0 and hard drives) meant creating your own boot floppies with the Workbench stuff discarded in favor of ARP and various other third-party utilities from the Fred Fish repository. I never used a C64, but I can imagine that a "factory defaults" Amiga would feel empty to a C64 user.
Look at all the case: statements in a switch - they're all GOTOs (the case: is a label). So are your virtual method tables. The break; statement also does a goto to the next instruction after the enclosing set of statements (switch, for, whatever).
Uh, those are *not* gotos. GOTO is a statement
GOTO label
and nothing else[1]. switch, break, continue and run-time polymorphism may or may not have some problems in common with goto but there is no logic which says that if you accept one of them you must not criticise goto.
[1] Modulo variants WRT where the label is allowed to be: in the same function, anywhere in the same source file, and so on.
Both PGP and S/MIME are end-to-end encrypted. Not very useful for webmail users.
*Webmail* is not very useful for webmail users.
One of the key difficulties is if you are including attachments in encrypted e-mails. This often results in your e-mail being quarantined by (depending on your viewpoint) over judicious anti-virus software as it is unable to scan the encrypted e-mail and guarantee it is virus-free. Your e-mail never arriving rather defeats the purpose of sending it in the first place.
Surely you're not talking about OpenPGP here -- I'm pretty sure the whole body is encrypted there and noone can tell if it's one long piece of text or a dozen attached .exe viruses.
Also, citation needed. I don't see why an anti-virus company would be smart enough to acknowledge the existence of encryption, and at the same time stupid enough to forbid it.
..."session keys". The content is encrypted with a random number (the session key), and this random number is in turn encrypted with the recipients' private keys. As the content is usually compressed too before encryption, the result may even be a smaller e-mail than without...
Thats really neat -- is it part of the regular email clients?
The good ones, yes.
Plain and simple.
Create a page document shows guidelines on how to submit bug reports, and send an email to all users that says that this is where the guidelines for filing bug reports live.
When you get a report that doesn't help, close the report with a referral to said document.
Better, have a form letter ready saying:
"You filed this bug report, but we cannot do anything about it yet because vital information is missing. Specifically:
[list of common reasons; you place a checkmark at those which apply before mailing the response]
Please also see $document. Regards, the programmers."
Useless bug reports are no big problem if you can keep track of them, and is allowed to ignore them until the submitter fills in the missing information.
For Windows developers at least, there is one spectacular piece of the OS to make use of for bug reports. Mini-dumps. So awesome I wish Linux had an equivalent.
Uh, Linux and the rest of the Unix world has had it for 30+ years. It's called a "core dump".
Take a look at WP's article on Robert Heinlein and then at SFE's. Both have useful material. [...] The SFE article is more useful if you're looking for critical commentary, since POV (point of view) is verboten on Wikipedia.
And this is a major difference. The SF Encyclopedia sucks in many, many ways but at least if you look up (say) an author you get a mainstream overview of his writing (I suppose "critical commentary" is the right term). With the WP you get hard facts but still can't tell if this might be an author worth reading.
The SFE article on Theodore Sturgeon was excellent.
It's more ignorant to think that users need to know the underlying system or how URL is formed to use computer or internet. Truth is, no one wants to have to learn things they don't care about. While you may think it's essential for everyone to know how computers operate, many people think otherwise.
An URL is not "how computers operate" -- it *is part of the user interface*. And the important parts are harder to understand than the concept of a phone number or any number of other things which people seem perfectly able to cope with.
(The worst problem in that area is probably not browser user interfaces but server admins who produce garbage URLs.)
But I found those questions trivial without a calculator, how you'd manage to fail with a calculator is beyond me.
Yes -- when I first read the summary, I assumed it was questions about things like long division -- algorithms which you learn as a kid, then forget because you never use them. But the actual questions were common-sense ones which you *do* exercise in normal adult life.
True. I wish more C++ programs aimed towards a more Smarter-C-Than-C style instead of the typical style of wanting to use every feature and use them badly
Here I agree ...
(templates I hate because they're misused to very often, the language was just fine without them).
... but here you're talking crazy, or what you've seen falls into the "and use them badly" category. The language was *not* fine without them. For one thing, it had no string types, no containers and no standard library except the C subset. The lack of these things in real-world C++ environments until 2000 or so was *incredibly* damaging.
C++ provides several very fundamental features which make it hugely superior to C: inline functions, better const semantics, reference types, and templates.
C has had inline functions for at least a decade. [...]
They aren't widely used though, in the projects I've seen (except the Linux kernel). Part of my job is to replace ugly, unsafe multi-line macros with inline functions ...
something which was only made possible earlier this year (2011), when we ditched our
last C compiler which didn't understand C99.
Which brings us back to part of TFA: it's hard to change a language which is widely used, and harder to make the programmers use the new stuff. (Personally I still think it's the way to go.)
What does it matter? If you don't want to use it, it never gets in the way.
Did you read what he wrote? He believes the browser would be better if Opera's developers could focus on just doing a browser, rather than a browser-and-mail-usenet-bittorrent-client-and-...
We have SCTP which was intended to replace TCP except nobody seems to care.
Some telecom standards are built on SCTP (we use it at work). Not sure if it's all that great though -- a lot of its problems are probably hidden by the fact that few care about it, and that it's used in isolated, high-quality networks.
At the end of the day the concept of TCP is not rocket science - there is a limit and diminishing returns to what more can be done twoard making TCP a perfect reflection of the concept of TCP. [---] In my opinion we need more IP protocols to better handle varied use cases more than we need a new TCP.
And we need application-level protocols on top of TCP which suck less, and implementations which suck less. You need some elemental understanding of TCP to use it efficiently, and from what I've seen, most programmers don't have it.
PS. As I recall it, last time Getty was in the media with his buffer bloat theory, several high-profile TCP experts (e.g. John Nagle) criticized him. We may be reacting to nonsense here.