tag:blogger.com,1999:blog-7555958.post113677012625593724..comments2024-03-18T12:52:48.117-07:00Comments on Mini-Microsoft: When Partners CollideWho da'Punkhttp://www.blogger.com/profile/18205453956191063442noreply@blogger.comBlogger129125tag:blogger.com,1999:blog-7555958.post-1153804409889363272006-07-24T22:13:00.000-07:002006-07-24T22:13:00.000-07:00Still don't understand what Mark Ashida and his ma...Still don't understand what Mark Ashida and his management team are doing at Microsoft. NAP is basically unusable,and the Yankee Group marked it "dead on arrival" <BR/>http://www.itbusinessedge.com/item/?ci=16031. <BR/><BR/>Maybe Mr. Khaki needs some tips from Trump!Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-7555958.post-1138488811665746402006-01-28T14:53:00.000-08:002006-01-28T14:53:00.000-08:00"As you probably know, managers tend to make their..."As you probably know, managers tend to make their threats behind closed doors.<BR/><BR/>I did not have a voice recorder with me at the time.<BR/><BR/>He is no longer a manager though. "<BR/><BR/>--<BR/><BR/>luckily that person got identified as a bad manager.<BR/><BR/>In my case, the clown is now a GM and still hits me any chance he can getAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-7555958.post-1137864076381491862006-01-21T09:21:00.000-08:002006-01-21T09:21:00.000-08:00I suggest you review employment law.Well then, lad...<I><B>I suggest you review employment law.</B><BR/><BR/>Well then, lad, where's your lawsuit?</I><BR/><BR/>As you probably know, managers tend to make their threats behind closed doors.<BR/><BR/>I did not have a voice recorder with me at the time.<BR/><BR/>He is no longer a manager though. <BR/><BR/>There are other ways to effect change besides a lawsuit.<BR/><BR/>I pursued the most cost effective route and it worked.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-7555958.post-1137834216843751492006-01-21T01:03:00.000-08:002006-01-21T01:03:00.000-08:00"Please take the NDT HR generalist who acts like t..."Please take the NDT HR generalist who acts like the partner's mistress along."<BR/><BR/>-- <BR/><BR/>agreed.<BR/><BR/>oh, there is more than 1 person who got burnted by NDT (t & j) so don't single the above comment to any one candidate ;-)<BR/><BR/>SherwoodAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-7555958.post-1137823754551761092006-01-20T22:09:00.000-08:002006-01-20T22:09:00.000-08:00>"#3 Jawad Khaki. I was so glad to escape the netw...>"#3 Jawad Khaki. I was so glad to escape the networking team. It is super to see that they still go off and do whatever they want. Way to hit Brian's december 31st date for being IN winmain - not on a slow boat towards it. And where is NAP? Take mr. ashida with you on the way out. FJ."<BR/><BR/>Please take the NDT HR generalist who acts like the partner's mistress along.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-7555958.post-1137731930681925042006-01-19T20:38:00.000-08:002006-01-19T20:38:00.000-08:00>Well, aren't you the model employee, always opera...<I> >Well, aren't you the model employee, always operating at 100% peak efficiency, regardless of your morale or your enthusiasm or your job satisfaction. Never taking a minute from your work day to chat with a coworker or check a personal web site. Always rigorously testing every line of code you check in.</I><BR/><BR/>Except for the last, no, not really. But I don't attempt to justify my failings by blaming others either.<BR/><BR/><I> >Well, I'll call your manager and tell him to stop wasting morale budget on you.</I><BR/><BR/>No problem. Send it to BlakeI. I'm several levels under him, but he'll know who you're referring to.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-7555958.post-1137731366117475622006-01-19T20:29:00.000-08:002006-01-19T20:29:00.000-08:00>You seem to be excusing the conduct of management...<I> >You seem to be excusing the conduct of management and then suggest that employees are supposed to do nothing about it.</I><BR/><BR/>Quite the contrary. I think that the leadership at this company is floundering badly. However, that fails to excuse any misconduct by individuals. Dissatisfied people should do the <A HREF="http://m-w.com/dictionary/honorable" REL="nofollow">honorable</A> thing and end their employment.<BR/><BR/>(I include the link for the benefit of those who may not be familar with the word.)<BR/><BR/><I> >I suggest you review employment law.</I><BR/><BR/>Well then, lad, where's your lawsuit?<BR/><BR/>If there were any valid legal claims, they would already have been made.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-7555958.post-1137711374854575882006-01-19T14:56:00.000-08:002006-01-19T14:56:00.000-08:00Bravo. Rarely does one see a person so proud of th...<I>Bravo. Rarely does one see a person so proud of their lack of integrity as to openly argue for it.</I><BR/><BR/>Well, aren't you the model employee, always operating at 100% peak efficiency, regardless of your morale or your enthusiasm or your job satisfaction. Never taking a minute from your work day to chat with a coworker or check a personal web site. Always rigorously testing every line of code you check in. Well, I'll call your manager and tell him to stop wasting morale budget on you. "Professional," whatever.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-7555958.post-1137705034016987972006-01-19T13:10:00.000-08:002006-01-19T13:10:00.000-08:00I'm not sure what the point of your post is. If it...<I>I'm not sure what the point of your post is. If it's that testers have some kind of specialized knowledge that devs can not acquire, then you are mistaken. I'm a dev and I've had to learn about all of these things.</I><BR/><BR/>I believe that the point is a work day only has so many hours and both jobs require a certain amount of knowledge and experience to be done properly.<BR/><BR/>A DEV can test but then they aren't writing the code needed to complete the product.<BR/><BR/>If you're going to do both jobs, you're either going to spend twice as much time at the office per day or something is going to suffer. <BR/><BR/>Since you took a DEV position, chances are you are going to spend more time writing code than testing it.<BR/><BR/>Testing your own code also sets up a conflict of interest. Are you going to file a bug report for every defect that you find in your code? We had a DEV lead that resolved all of his "defects" as "issues".<BR/><BR/>You've also only got a certain amount of time to keep your skills up to date.<BR/><BR/>If you think those who test the code you write are slack, take a test position and show everyone how it is done.<BR/><BR/>If that is too big of a step for you, tell your test manager that you believe you can do both jobs and have him assign you the test work for a set of features (not yours) in addition to your regular responsibilities for a few weeks.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-7555958.post-1137703347189005512006-01-19T12:42:00.000-08:002006-01-19T12:42:00.000-08:00May I remind you that one of the important aspects...<I>May I remind you that one of the important aspects of professionalism lies in your treatment of others, not in their treatment of you. I would almost suggest reviewing the ACM Code of Conduct, but given what occurs when vampires are exposed to sunlight, that may not be the wisest course</I><BR/><BR/>You seem to be excusing the conduct of management and then suggest that employees are supposed to do nothing about it.<BR/><BR/>I suggest you review employment law.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-7555958.post-1137659135692470572006-01-19T00:25:00.000-08:002006-01-19T00:25:00.000-08:00>Maybe employees would be more inclined to be "pro...<I> >Maybe employees would be more inclined to be "professionals" if HR didn't treat us like high school students with this review process.</I><BR/><BR/>Bravo. Rarely does one see a person so proud of their lack of integrity as to openly argue for it.<BR/><BR/>May I remind you that one of the important aspects of professionalism lies in your treatment of others, not in their treatment of you. I would almost suggest reviewing the ACM <A HREF="http://www.acm.org/constitution/code.html" REL="nofollow">Code of Conduct</A>, but given what occurs when vampires are exposed to sunlight, that may not be the wisest course.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-7555958.post-1137615207866130542006-01-18T12:13:00.000-08:002006-01-18T12:13:00.000-08:00I am a professional. I always do the job I agreed ...<I>I am a professional. I always do the job I agreed upon to the best of my abilities, meager though they may be. If I do not like the terms of employment, I leave the job.</I><BR/><BR/>The message from HR is that people need reviews, raises, bonuses, and awards in order to be movtivated to do their jobs.<BR/><BR/>So when they cut raises, bonuses, and awards, the message must be that we don't have to work as hard.<BR/><BR/>Maybe employees would be more inclined to be "professionals" if HR didn't treat us like high school students with this review process.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-7555958.post-1137584281254659742006-01-18T03:38:00.000-08:002006-01-18T03:38:00.000-08:00God, half past three in the morning and I'm only j...God, half past three in the morning and I'm only just home!<BR/><BR/>In the canteen this evening there were a bunch of young devs banging on, loud enough so that everyone could hear them, about their home-built systems they were running ripped off copies of OS X on.<BR/><BR/>Now, I'm not anal enough to worry about ripped off code: it's hacker culture, after all. the only way good software gets great is by people doing uforseen things with it, IMO. However, as a dev I worry about the kind of gungho, loose-canon attitude, that is typical of what these kids were displaying, and which I <B>know</B> their manager encourages (I've even heard it said they have a ripped off copy of OS X <I>in the building</I> to play with).<BR/><BR/>Are these guys more valable to Microsoft because of what they might do to us if we ever sacked them? I don't know, but because of the team they're on, I can tell you that they're probably at their most productive when they're dicking around with stolen code - and they have a manager that encourages them to take a "you can't touch us" attitude about that... as <I>that</I> was the same as getting anything useful done!<BR/><BR/>And it's f**ing nearly four AM and I'm still awake! Damn!Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-7555958.post-1137563677804800032006-01-17T21:54:00.000-08:002006-01-17T21:54:00.000-08:00"#3 Jawad Khaki. I was so glad to escape the netwo..."#3 Jawad Khaki. I was so glad to escape the networking team. It is super to see that they still go off and do whatever they want. Way to hit Brian's december 31st date for being IN winmain - not on a slow boat towards it. And where is NAP? Take mr. ashida with you on the way out. FJ."<BR/><BR/>-<BR/><BR/>THey missed winmain and people have been screaming about broken networking in vista since b1 (and screaming about networking in windows since WFW). <BR/><BR/>How many DCRs were acccepted and how far did they push out "feature complete" to compensate for the overlapped services of networking? Mind you most of this stuff was around during LH Alpha<BR/><BR/>Good jobAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-7555958.post-1137531206665637582006-01-17T12:53:00.000-08:002006-01-17T12:53:00.000-08:00>Devs can write solid code and test it themselves ...<I> >Devs can write solid code and test it themselves no problem.</I><BR/><BR/>I didn't ask whether they had the ability, I asked why they weren't. Re-read what I wrote.<BR/><BR/><I> >Devs are rewarded for working on a lot of different features and finishing them ahead of schedule. There's a big incentive to write something that seems to work, throw it over the wall, and move on.</I><BR/><BR/>I am reminded of a Muhammad Ali quote when he was asked about golfing: "I'm the best. I just haven't played yet". <BR/><BR/>While belittling those lesser than themselves already reflects poorly on the developers that do it, I suggest that such claims would be more credible had they learned the skills necessary and actually applied them in practice before presuming to tell others that their job is not as difficult.<BR/><BR/>Even better, devs could even stoop to help educate these benighted lesser beings so that they can help test code more effectively. Goodness, imagine that!<BR/><BR/><I> >Second, with 2% raises and dwindling benefits, why should _anybody_ do a good job at Microsoft? If somebody's doing a bad job, it doesn't mean he can't do a good job... </I><BR/><BR/>This attitude is utterly beyond contempt. <BR/><BR/>I am a professional. I always do the job I agreed upon to the best of my abilities, meager though they may be. If I do not like the terms of employment, I leave the job.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-7555958.post-1137473118391966572006-01-16T20:45:00.000-08:002006-01-16T20:45:00.000-08:001) STEs and SDETs cost between 50% and 80% of SDEs...<I>1) STEs and SDETs cost between 50% and 80% of SDEs.</I><BR/><BR/>Really? I could see that for STEs, but SDETs? I thought SDETs and SDEs were on the same pay scale, although I would expect most SDETs to not increase levels past 61.<BR/><BR/><I>I'm not sure how much we make in licensing for each game, but nearly doubling our attach rate is surely a good thing. Isn't the majority of our money made on licensing anyways?</I><BR/><BR/>Licensing and peripherals.<BR/><BR/>For competitors, gamepads and memory cards have great margins (make for < $8, sell for ~$40).<BR/><BR/>In the 18-month rush to get the first Xbox out the door, MS actually ended up designing a money-losing peripheral program.<BR/><BR/>On the bright side, Xbox 360's peripheral program is on par with competitors and profits are looking good. Especially considering greater than expected wireless gamepad attach rates.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-7555958.post-1137448991509237632006-01-16T14:03:00.000-08:002006-01-16T14:03:00.000-08:00Answer me this: For skills that are so "trivial", ...<I>Answer me this: For skills that are so "trivial", the average dev here clearly lacks them and has no interest in getting them. Why? Not a week goes by without another embarrassing MS bug making tech headlines ...</I><BR/><BR/>Devs can write solid code and test it themselves no problem. You're witnessing something else. Devs are rewarded for working on a lot of different features and finishing them ahead of schedule. There's a big incentive to write something that seems to work, throw it over the wall, and move on. Second, with 2% raises and dwindling benefits, why should _anybody_ do a good job at Microsoft? If somebody's doing a bad job, it doesn't mean he can't do a good job...Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-7555958.post-1137430466337046612006-01-16T08:54:00.000-08:002006-01-16T08:54:00.000-08:00I know this threadis trying to die bu I had to com...I know this threadis trying to die bu I had to comment on one of the last posts:<BR/><BR/><I>have a simple solution to the whole mess:<BR/><BR/>Once code complete is declared, if more than 5 bugs are found in their entire codebase or in the spec, the dev will be fired on the spot.<BR/><BR/>Once RTM is declared, if more than 5 bugs are found by a customer, the entire team (devs, test, pm, leads, and managers) will be fired.<BR/><BR/>That way, the whole team will view test as covering their butts and everyone will stop playing schedule-chicken.</I><BR/><BR/><BR/><BR/><BR/><BR/><BR/>Before you say this you have to determine what a bug is. Is a bug a typo? Is it a data loss problem? Is it an off-by-one? Is it easily seen? You can't just fire people if they have bugs in 10,000 lines of code. According to the normal curve for bugs, 10,000 will have as many as 10 bugs.Christian H.https://www.blogger.com/profile/16847810167041864292noreply@blogger.comtag:blogger.com,1999:blog-7555958.post-1137399814167126052006-01-16T00:23:00.000-08:002006-01-16T00:23:00.000-08:00So why don't we start coming up with a list of 68-...So why don't we start coming up with a list of 68-80+ level folks who should go "spend more time with family"?<BR/><BR/>My quick list:<BR/><BR/>#1: Robert Wahabe. What has this guy ever shipped? Has more architects and DEs than anywhere else in the company, but absolutely nothing to show for it. But he was creative enough to convert his teams admins into PMs to up his diversity numbers!<BR/><BR/>#2 Pieter Knook. Make me a smartphone that actually is smart about making and receiving calls above anything else, then have it run whatever other apps.<BR/><BR/>#3 Jawad Khaki. I was so glad to escape the networking team. It is super to see that they still go off and do whatever they want. Way to hit Brian's december 31st date for being IN winmain - not on a slow boat towards it. And where is NAP? Take mr. ashida with you on the way out. FJ.<BR/><BR/>#4 Ya-Qin Zhang. Oh wait, too late for that one...<BR/><BR/>#5 Lynn Hill. I got this one from a friend, with the comment "pure overhead" and "always looking out for Lynn". We need more folks like this.<BR/><BR/>#6 Brian && Jim. Sorry, but someone has to be holding the bag for Longesthorn. Probably should add ole Steveo to the group as well, he is responsible for product development. oh wait, our board has no real say in anything.<BR/><BR/><BR/>I do have to say I'm more excited about working at MS now than I have been in the past 4-5 years. I used to make fun of redvest from the comforts of bldg 40 but MSN actually feels like Windows used to in the mid 90s - shipping shipping shipping. If we only had more parking...<BR/><BR/>Keep it real, mini!Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-7555958.post-1137398869529625192006-01-16T00:07:00.000-08:002006-01-16T00:07:00.000-08:00>Testing is mostly process mixed with technical sk...<I>>Testing is mostly process mixed with technical skills - there are exactly 3 chapters in my '92 Software Engineering textbook about QA and they cover all of what is done including the things mentioned here like model based, coverage / complexity measurement, formal reviews and what not.</I><BR/><BR/>Answer me this: For skills that are so "trivial", the average dev here clearly lacks them and has no interest in getting them. Why? Not a week goes by without another embarrassing MS bug making tech headlines around the world, and here we have devs trumpeting their superiority to test instead of asking to learn how to catch their own mistakes. Why? Testing is so "easy", right?<BR/><BR/>I'm waiting.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-7555958.post-1137386324525717142006-01-15T20:38:00.000-08:002006-01-15T20:38:00.000-08:00My point is that any broad generalization about th...<I>My point is that any broad generalization about the differences between STEs and SDETs isn't going to hold up to scrutiny.</I><BR/><BR/>What about black-box vs. white box? Many testers I've met, regardless of ability to code, do not have the CS concepts to be able to narrow down issues beyond a basic level.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-7555958.post-1137386177494371682006-01-15T20:36:00.000-08:002006-01-15T20:36:00.000-08:00In 1999, the extent of education in how to test so...<I>In 1999, the extent of education in how to test software in my Computer Science program was a 1 page handout and 30 minute lecture.<BR/><BR/>In 2000, I spent 9 months performing and learning the ins and outs of globalization, localization, ...</I><BR/><BR/>I'm not sure what the point of your post is. If it's that testers have some kind of specialized knowledge that devs can not acquire, then you are mistaken. I'm a dev and I've had to learn about all of these things. If it's that computer science curriculums should change to teach more about, e.g., localization, then I think you're mistaken about that too. The point of a college education is to give you a broad foundation of knowledge. Surely you're not trying to say that college students should have to learn which Microsoft tool to run on which kinds of Microsoft files to produce a localized build of a Microsoft program.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-7555958.post-1137373123532608432006-01-15T16:58:00.000-08:002006-01-15T16:58:00.000-08:00In 1999, the extent of education in how to test so...In 1999, the extent of education in how to test software in my Computer Science program was a 1 page handout and 30 minute lecture.<BR/><BR/>In 2000, I spent 9 months performing and learning the ins and outs of globalization, localization, accessibility, scalability, reliability, performance, security, code coverage, deployment, uplevel/downlevel, interoperability, media verification, and a few more "quality areas".<BR/><BR/>Later, we all learned more about security testing. Later yet, we inherited even more quality gates.<BR/><BR/>Somehow, standard textbooks don't talk about needing to run polycheck against your resource files so that you can rip out geo-politically sensitive text so that our sales reps in China don't get thrown in prison.<BR/><BR/>Somehow, standard engineering textbooks don't talk about the US Government accessibility requirements for purchasing.<BR/><BR/>Somehow, standard engineering textbooks don't talk about techniques to use when trying to reproduce that elusive bug that you saw once and your dev can't fix unless you can repro it on their machine.<BR/><BR/>Or checking that your app works correctly with a right to left language and that the UI is mirrored correctly. Or checking the various color schemes, high contrast colors, and various font sizes.<BR/><BR/>I suspect that a lot of devs have little idea what testers do and vice versa. When dev and test and pm orgs go up several levels of management before they meet, there are a lot of ways each can screw the other and result in highly disfunctional groups.<BR/><BR/>For example, a dev and pm are taking in the hallway about a new feature.<BR/>PM: How long will it take to add X?<BR/>Dev: Only half a day to code, but I would guess about 3 days to test.<BR/>PM: Hmm, we hit code complete tomorrow and this will derail the test schedule. Let's do it anyway.<BR/><BR/>Equally, test can screw a product release by holding off on submitting critical bugs, or by playing "flip-flop the spec" alternating between conflicting bugs to give devs some busy work. <BR/><BR/>Or worse, test gets screwed on the schedule and doesn't have time to adequately test, takes shortcuts, and critical bugs go out the door and our reputation goes down even further in the eyes of our customers.<BR/><BR/>Now, let's talk about the test matrix for one of our previous release:<BR/><BR/>(free builds + release builds) *<BR/>(x86 + x64 + ia64) *<BR/>(home + pro + server + advanced server + blade server + datacenter server) *<BR/>(joined to a domain + workgroup) *<BR/>(long computername + short computername + german codepage chars + japanese UTF8 chars in the computername) *<BR/>(guest user + local user + domain user + local admin + special group membership) ... etc.<BR/><BR/><BR/>Already, we are at over a thousand configurations and we haven't even gotten into the features of the network management application. Clearly, there is a need for some automation, but who is going to write the automation when your SDE is busy trying to manually check a reasonable subset of tests so that you can ship? <BR/><BR/>And sure, you can focus on unit testing, but at some point we need to make a serious investment in adding complete test automation for all of those components that are sitting in maintainance mode. <BR/><BR/>You can't just automate the new stuff and assume that it will save you money when you have 10 layers of poorly tested dependencies below your new code.<BR/><BR/><BR/>I have a simple solution to the whole mess:<BR/><BR/>Once code complete is declared, if more than 5 bugs are found in their entire codebase or in the spec, the dev will be fired on the spot.<BR/><BR/>Once RTM is declared, if more than 5 bugs are found by a customer, the entire team (devs, test, pm, leads, and managers) will be fired.<BR/><BR/>That way, the whole team will view test as covering their butts and everyone will stop playing schedule-chicken.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-7555958.post-1137369792630042532006-01-15T16:03:00.000-08:002006-01-15T16:03:00.000-08:00Sure, they were allowed to interview and look for ...<I><B>Sure, they were allowed to interview and look for internal jobs for a few months. According to a dev that was in one of those loops, the interviews required technical programming skills so high that 20% of the current DEVS wouldn't have survived the loop.</B><BR/><BR/>20% of the current devs at Microsoft are crap, and could be let go without too much impact on the bottom line, aside from the fact that we'd probably end up shipping less buggy software. Hard dev interviews are a GOOD thing, not a bad thing.</I><BR/><BR/>What bothers people is applying standards unevenly.<BR/><BR/>If these same people left Microsoft and applied as DEVs, the original author is saying that they would pass (using your 20% number as a place holder for the real percentage which is unknown since there is no data to back it up).<BR/><BR/>As long as all of the current DEVs have to pass the same new standard, there would not be a problem except for people increasing the difficulty of the questions with the purpose of just getting rid of people they don't like or have a personal bias against.<BR/><BR/>As it stands now, the sands can shift in a series of interviews depending on whether or not the people interviewing you want you or don't want you around for whatever reason (not necessarily technical).<BR/><BR/>The process would be fair if the questions were set in advance.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-7555958.post-1137369175493693512006-01-15T15:52:00.000-08:002006-01-15T15:52:00.000-08:00Testing is mostly process mixed with technical ski...<I>Testing is mostly process mixed with technical skills - there are exactly 3 chapters in my '92 Software Engineering textbook about QA and they cover all of what is done including the things mentioned here like model based, coverage / complexity measurement, formal reviews and what not.</I><BR/><BR/>That's not very surprising, considering what the state of QA was in 1992 ("you peons, get back to steerage class with you").<BR/><BR/>I would think that seeing the horrible problems with security and so forth of the last 14 years might have changed some minds on the importance of QA since then.<BR/><BR/><I>We would be a lot more agile if we only had SDEs who either code or test as the project called for at that time. Sure, you would need separate orgs starting at the project lead(?) level to avoid any conflict of interest, but the technical resources themselves would have uniform skills and be easily replacable.</I><BR/><BR/>Again, this assumes dev skills are synonymous with test skills. They aren't. Creatively black-hatting code or having empathy with users isn't the same as writing code.<BR/><BR/>Are technical skills good things to have for a tester? Duh- that should be obvious (a tester who understands code has more ways to approach the task of testing). But I regularly casme up with "Hey, did you think about X" questions to my devs that they had never thought of- because they focused in on small domains in their expertise, where I had to range all over the goddamned OS and userland in test. Some people are better at this than others are.Anonymousnoreply@blogger.com