Fog Creek Software
Discussion Board

no respect...

I was browsing through a book, and he's talking about testers vs. developers:

I agree with him -- people involved in testing are very touchy about being told their not real developers (especialy at microsoft where they seem to insist the hardest that testers are developers). 

Is this in fact true, are developers and testers equaly good at development.  In fact I don't believe this, if your good at development then a company will hire you as a developer. Why would they hire you to test somebody else's code.  Just like if your a good chef, they aren't going to hire you as a waiter.

But this is not to say that testers aren't important.  Their vitally important, but I don't understand why Microsoft and others pretend that testers are as good at software development.

Friday, July 23, 2004

A Good Tester is a Developer.
A Good Developer is a Tester.

You can't be one without the other and still be good.  To categorize these as two separate things is just plain stupid.

I always image people writing code and not testing it.  I just can't believe that it's true.  I test every line of code I write.  I test the applications I write.  I test the UI's I write.  I test everything.  There are no developers out there worth their weight that blindly write code.

Oh this is rich
Friday, July 23, 2004

I always figured that when people say developers don't test code, they mean they don't unit test, or don't test properly.

Are you saying that there are developers out there who write, compile, and submit code without once ever executing it?

My code has nearly as many debug lines as executable ones, sometimes.

Friday, July 23, 2004


they're not real...  not  "their not real"

if you're good at...  not  "if your good at"

if you're a good chef...  not  "if your a good chef"

Testy Tester
Friday, July 23, 2004

Chef/Waiter is a bad parallel; perhaps a better one is Writer/Editor.  Any writer should edit their own work, but an editor can look at the bigger picture and with a different frame of refence to ensure that the writer is saying what they intended, clearly and cleanly.

Friday, July 23, 2004

Maybe more like Chef/Food critic.

One is not greater or proficient than the other.  The two jobs require different sets of skills, although some do cross over.

Friday, July 23, 2004

> Are you saying that there are developers out there who write, compile, and submit code without once ever executing it?

It's called "cleanroom development": write and submit code without executing (or even compiling) it.

Christopher Wells
Friday, July 23, 2004

"I test every line of code I write.  I test the applications I write.  I test the UI's I write.  I test everything.  There are no developers out there worth their weight that blindly write code."

There is a breed of programmer, big about a decade ago, that roughly throws a bunch of code into a compiler, hits build, and then they go through all of the errors and warnings, fixing it up until the compiler is happy with it. When the code compiles they call it a success - surely their code is good.

I suspect the same issue is happening with the testing realm nowadays - build a couple of test cases and then throw together a class. If it passed the tests (and developers usually delude themselves into thinking their tests have total coverage, which is hilariously laughable in all but the most trivial xunit sample cases), well then you're a studious, impressive programmer that clearly builds perfect code. It's a crutch that allows for sloppy programming, because once all the little test nodes are green you're sure you made great code.

I am not saying developer testing is either bad or good, but this nonsensical, furrowed brow righteousness that extensive self-testing makes you a great programmer is laughable.

Dennis Forbes
Friday, July 23, 2004

"Rich" is absolutely correct.  Our testers write automation tests using RMI methods on the client and server.  It is stinking awesome. It is the only way to make things work, IMO.

Unfortunately, this is not the norm.  Many companies view testing as "running through the UI". Both the testers that get hired as such and the managers that do this type of hiring ought to be spanked.

I would probably put this "mentaility" as a litmus test for F'd companies.

Just one developer's opinion.

Friday, July 23, 2004

When I'm developing code, I generally add in lines to give me a very detailed debug log for auditing every last step of the process.  If you take a look at my current project at , you'll see that at the bottom of the page is a pretty extensive play-by-play of everything the code did on its way to generating the page.  The log gets even longer if you submit a registration form (even if you submit it empty.)  This is the approach I take to most of my projects, now.  As I go, I'll be adding even more logging to this project.  Of course, once I hit v1.0 and put the code into "production", I'll flip the debug switch to 'off' and the little red box goes away.  But while working on the codebase, the detailed log of execution is invaluable.

Friday, July 23, 2004

Testy Tester,

You missed:
They're vitally important... not "Their vitally important"

Maybe you should seek a job as a developer since you're obviously not cut out for work as a tester. :-)

Yet another anon
Friday, July 23, 2004


And, I also missed the lack of a question mark at the end of a sentence that was actually a question and not a statement.

"Is this in fact true, are developers and testers equaly good at development." 

Oh well, VBA here I come. 

Testy Tester
Friday, July 23, 2004

A good developer is a good tester.....true!

A good tester is a good developer.....hmmm....kinda true but not in the sense you mean..

A good tester will know how to develop good test scripts and test cases using the tools at hand (JUnit, Winrunner...) but  that does not mean he is as good as developing the main body of code and I will even go out on a limb and say that it is a problem.

If I develop something in C++ I do not want the damn tester to read my code and try and find bugs....I have peer code reviews for that.  I want the tester to develop good test cases and automated scripts which will exercise the functionality and confirm it is according to spec. 

I know it  is seems nice to have a tester who can tell you the bug and also tell you it is because you did a if ( i = 3 ) instead of if ( i == 3 ) but believe me in the long run these kind of testers are big headaches to a development team.

It takes a special kind of person to write code and it takes a special kind of person to test it.  You can call both of them "developers" but rarely there is a person who is good at both

Code Monkey
Friday, July 23, 2004

"if ( i == 3 )" is an immediate no-hire.

Dave Benson
Friday, July 23, 2004

The dumbest fucking thing I've ever heard.

Friday, July 23, 2004

+++"if ( i == 3 )" is an immediate no-hire. +++

Why, exactly, is that?  Who says he's talking about C?

Granted, I hardly have occasion to compare variables to literal integers (and have a hard time coming up with a scenario where you'd want to), but why an immediate no hire?

Friday, July 23, 2004

And I do mean it.  The most despicable least common denominator pile of stinking shit ever to grace the halls of software.

I mean PHB braindead stupidity.  Lameass ought to be horse whipped and gutted mind-numbing stupid.

Damn stupid.

Friday, July 23, 2004

hoser - care to clarify what you're remarking on? :)

Friday, July 23, 2004

What he means (and I guess he wouldn't hire Dennis Ritchie) is that some dumbass 'might' write if( i = 3 ) instead of if( i == 3 ).

Never mind that the compiler checks the syntax for you and gives a warning. Nope, you're going to get a lamer set of "coding rules" at this man's company. You're going to be a "resource" here, not an engineer.

Lemme tell ya something.  I had some great coding questions during the last 4 weeks on the interview trail.

Here was a list of the best questions asked:
. Write a sorted tree struct with add and ascending print functions.
. The pirates problem
. Write a card deck class and optimal shuffle (minimum calls to rand()) method.

No one gave a flying F whether you used

if( i == 3 )


if( 3 == i )

MF'ing stupid ass PHB Lamer.

Friday, July 23, 2004

Ok hoser-

if (i != 3)


Greg Hurlman
Friday, July 23, 2004

Oh, yes another really good interview question:

Design a DMA engine for handing MPEG motion vectors.

And others:

Design a restaraunt reservation system.
What are the functons of a boot loader?

A players hire A's.
B hires C's.
C's have their heads up their collective asses.

Friday, July 23, 2004

yes, much happier.

Friday, July 23, 2004

Sorry hoser, no hire. We also don't hire little potty mouths. THe clients don't appreciate it.

"if ( i == 3 )"

Has several problems with it.

First, anyone with a modicum of experience would write:

if (3==i)

...instead. The first version shows one has little practical development experience.

Second, we don't like to see magic numbers.

No. Hire.

Dave Benson
Friday, July 23, 2004

"Never mind that the compiler checks the syntax for you and gives a warning."

Sloppy thinking. Poor development skills. No... Hire.

Dave Benson
Friday, July 23, 2004

Good engineers think, they do not obey.

Go hire your pathetic "team".

Friday, July 23, 2004

Already did. Great products. Profitable company. Pay in the 90th percentile. Happening city. It's groovy all around.

Dave Benson
Friday, July 23, 2004

Oh, yeah, I'm a deluxe contractor with money coming out the wazoo and the Queen of Sheba to boot.

You wouldn't Hire K&R.

Friday, July 23, 2004

I've spoken to Dennis and he uses the "if (NAME == x)" idiom as well. Any reputable developer with a modicum of experience does as well.

Glad you are doing with with, Sheba is it now? Sounds like a fun place - we have dress up days a couple times a year as well. There is Halloween of course but in June we have a masked ball. Everyone has a great time.

Dave Benson
Friday, July 23, 2004

I think it depends on the type of testing being done.  I am doing an internship with a QA group at a large company and have spent a fair amount of my time developing test case code to simulate the customer interaction the internal APIs of a product.  All of our tests are implemented in an automated test package that is used for both new feature and regression testing.  I read feature specs and write test specs which are approved along with the feature spec.  I would consider this development work.

Jon Lindbo
Friday, July 23, 2004

Dave, you're not as good as you believe. There are legitimate arguments against the structure that places the constant value first in equivalence tests. For a start, it breaks the logical appearance of the code. It does this in order to overcome a weakness of the language. Whether this is valid is a judgement call, not a hard and fast rule.

I see also that you use caps for your constant names. Dave, that's an old fashioned concept. Please explain why constants need to be named upper case.

Your claims about income don't mean much. Enron made heaps too.

Moron spotter
Friday, July 23, 2004

Gotta say, I've coded in C and C++ day in and day out for 5+ years, and the assignment vs. comparison thing just isn't a problem.  It's just not. Maybe it's a problem at the places you've work, but not where I've worked.

The "no magic numbers" thing I agree with, even for numbers that you know will never ever change. The biggest reason is it makes it hard to grep the code for those for the value, making maintainance much harder and error prone. And also, sometimes those numbers you thought would never ever change, do change and its damn hard to search the 100k lines of source code for "3" without getting a zillion wrong hits.

But even then I wouldn't say "NO HIRE" like some geeked out Soup Nazi. I would be suspicious of the candidate's other coding practices, but it wouldn't put me off. If any hire you make can consistently writes working robust code, then you are half way to a great engineer.

Friday, July 23, 2004

You're all morons and you're all fired!

Friday, July 23, 2004

>"if ( i == 3 )"
>Has several problems with it.
>First, anyone with a modicum of experience would write:
>if (3==i)

Bull that is just a matter of choice. The problem is that you are syntax zealot. I am sure you will not hire someone because they do not put braces as per your style

>.instead. The first version shows one has little practical development experience.

Nope it shows how little code you have practically seen.

>Second, we don't like to see magic numbers.

Really...once again without knowing the context to say this is a mark of a fanatic.  In some cases it is perfectly OK to use magic numbers rather than having to hunt one hundred files to find the #define or const. The trick is when you are using the same magic number multiple times in the same context it is better pulled out and defined.

I would take  if ( !i )  anyday over over protective diaherria crap like

#define COUNT_OF_ZERO  0

if ( i == COUNT_OF_ZERO )

But then Engineers understand that

Also there are cases like if ( sizeof(int) == 4 ) where it is perfectly ok to use "magic numbers" precisely because it is a  magic number!

(infact one should always use 0 and 1 as magic numbers)

No. Hire.

Code Monkey
Friday, July 23, 2004

"First, anyone with a modicum of experience would write:

if (3==i)"

Not quite. I've 20 years of experience and never saw that technique until 2-3 years ago. It's *not* a universal thing.

But then, I use lint, so I don't waste time worrying about crap like that. (And  writing code that reads counterintuitively [is that a word?]).

Basing hire vs. no-hire on *any* one technique or issue is ludicrous. None of us knows everything.

Friday, July 23, 2004

Ideally one could have a situation like American football, one person plays defense while the other tries to score a goal. The defender probes the weaknesses of the code, and the other takes that feedback and reacts.

Then the sides at some point can switch; play against others.

Unfortunately, this can of course get really stupid, if you have just one unreasonable person.. but in personal projects with someone, I can approximate it. Comes down to being able to choose the person you engage.

There are companies who seem to have this at a good level, such as IBM's Black Team described in Peopleware.

Tayssir John Gabbour
Saturday, July 24, 2004

Incidentally, there can be problems... like if one person likes to get things right immediately, while the other likes to write voluminous code and make it pretty later. It's a real burnout sometimes.

This is why my favorite mode is to play this game alone, attacking my previous day's ideas or whatever, with tests where I really twist the screws on corner cases.

Incidentally, the if( 3 == i ) thing... for bare, unlovin' languages like C, you get idioms. You start seeing idioms clustering at the limits of a language. It's important to realize that. I neither agree nor disagree with a No Hire; I have sarcastic thoughts about both sides. But whatever, people hire who they hire, just like people marry who they marry. This myth of the General Hiring Practice needs to be put to rest.

Tayssir John Gabbour
Saturday, July 24, 2004

Dave Benson - get off your high horse. Plenty of excellent C/C++ coders disagree with you on this point. It's a judgment call, plain and simple. If you prefer it one way, fine. If you want that to be the coding standard for your shop, fine. But a no hire because he disagrees with you on a marginal issue? Give me a break. Now, asking him _why_ he codes it this way and then judging the quality of his answer would be fine. If he hasn't even heard of the other style, or can't give any reason why he prefers one to the other, then I can see that being a negative. But if he knows both styles and is willing to follow your standards while working on your code (even if he prefers the other style on his own) then who cares?

Hard-and-fast coding rules are a bad idea. "Magic numbers"? Try to avoid, sure - but it's also not nice to have a million #defines at the start of a file or in a header and then have to hunt around for them. If a number is used once, a comment saying what it's for should be sufficient. Agreed a #define should be used if the same constant is sprinkled through the code. Likewise, global variables are *usually* a bad idea - but if not using a global would make your code twice as complicated, it's silly not to. Likewise with gotos - if you can replace a 10-level nested if statement (nearly impossible to read) with a couple of gotos, then do it. (Of course, in C++ rather than vanilla C, you could probably use a try/throw/catch construct instead.)

Frankly, Dave, when you make these posts it sounds like you have a stick up your ass. I suggest you consider how your workplace sounds to prospective employees who read this board. No programmer wants to be treated as a code monkey. And no programmer wants to work in a stiff and formal environment. You may have coders now, but if the job market ever picks up, you're going to have trouble finding them.

Saturday, July 24, 2004

*attention developers*

Testers nowadays read and crit the functional spec alongside coders and gain signoff based on test rigs developed in their own sweatshops.

Testers are approvers who speak managerese and work equally well with internal, outsourced or expatriate developers. They don't care much about code syntax - it's performance that matters.

My advice? learn to test & starve the buggers.

Respect them?  Tough ask. They do save your bacon at the price of your pride (and I can be induced to go on at length about the good old days when testers were called clients).

Different skillset? Nah. Set a thief to catch one. Dissing another coder's external user experience is actually fun but coding internals are irrelevant.

Testers actually don't need your respect as testing is ramping and coding is walking out the door.

Time to make the move?

Saturday, July 24, 2004

I forgot to ask - how far OT can a thread get? There's more pin-dancing angel-counting Titanic deckchair rearranging spouts above than I've seen since gosh.

It's not rpm or cubic inches boys,  it's how fast from A to B (and get paid).

Saturday, July 24, 2004

What??  You don't care about whitespace and which side of the equality the constant goes?

No soup for you.

brrrrrr, cold
Saturday, July 24, 2004

Dave - what makes you think anyone'd want to work for someone that anal retentive? Jeez.

if (i==3) vs (3==i) has never been an issue for me. If I found it caused me problems I'd probably bother writing it the other way round, but believe it or not it doesn't. I can tell == from = and have had few if any errors from this in the last few years.

If I worked for someone who demanded this I'd probably write a script to parse and convert all my code into the 'acceptable' format for them. And I'd make it fucking obvious that I was using a script to do this just to make a point of how ridiculously small-minded and irritating the demands were.


If you treat people like code monkeys all you'll get are code monkeys. Smart people like to look at the big picture and can recognise that matters of style are just personal preference. If something really bugs them they write a fricking macro to reformat the code for them

Saturday, July 24, 2004

Dave's probably top code monkey at an accounting firm where accountants tell him how to do his development. The only bits he has control over are coding standards.

Go Dave.

Moron spotter
Saturday, July 24, 2004

Would *somebody* hand me the freaking net already!!

Dave Benson
Saturday, July 24, 2004


It seems amazingly difficult to say "I disagree" in a respectful way to some people. Or argue in a normal way.
Even though it is seemed perfectly normal in some of the places i've worked.

Well, if you even cannot discuss small things like coding rules, without personal attacks...
Must be a lot of fun with all you guys in a team, and the real hard decisions have to be made...

"He doesn't agree with us! Kill him! Let the dogs out!"

Out of range error
Monday, July 26, 2004

*  Recent Topics

*  Fog Creek Home