|
That's what I have as well. I have yet to figure out what the "Noise" setting does  .
Soren Madsen
"When you don't know what you're doing it's best to do it quickly" - Jase #DuckDynasty
|
|
|
|
|
Redundant for the lounge - it removes low voted messages, in theory.
Insufficient caffeine error: Brain function compromised.
It sets the "Grey point for messages": Medium means that posts with a "three" or below are Grey, Low is "two" or below, and so forth. It doesn't hide rubbish (mind you, you'd need some serious filters to hide rubbish in the lounge anyway!  )
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
  Thank you. Now it makes sense.
"When you don't know what you're doing it's best to do it quickly" - Jase #DuckDynasty
|
|
|
|
|
OriginalGriff wrote: you'd need some serious filters to hide rubbish in the lounge
Do not be so sure, the one they have activated to block DD's posts is working like a charm ! 
~RaGE();
I think words like 'destiny' are a way of trying to find order where none exists. - Christian Graus
Entropy isn't what it used to.
|
|
|
|
|
A businessman waiting at the airport finds sitting next to him, an elegant woman wearing the largest, most stunning diamond ring he had ever seen. He asks her about it.
"This is the Klopman diamond," she said. "It is beautiful, but there is a terrible curse that goes with it."
"What's the curse?" the man asked.
"Mr. Klopman."
|
|
|
|
|
Abhinav S wrote: He asks her about it.
You can imagine this in real life..
Man: Can I take a closer look at your jewel?
Woman: Security!!
How do you know so much about swallows? Well, you have to know these things when you're a king, you know.
modified 31-Aug-21 21:01pm.
|
|
|
|
|
Developers think QA team should be in charge of this. QA team says developers should write it by themselves. Test case has now become a political issue in my friend's company.
|
|
|
|
|
Shouldn't developers write unit test cases and rest to be done by QA, business analyst or whatever?
|
|
|
|
|
Unit tests are NOT "test cases". Writing those is the domain of QA, and they are developed based on requirements.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
Assuming that you mean something like a UAT test case, it is really easy to argue development shouldn't write them: The original spec always contains ambiguity or needs a interpretation - if this wasn't the case we wouldn't need developers. The developers need to interpret the specs and no matter how good will get the interpretation wrong or make an incorrect assumption. Getting the dev to write the test case has the effect of transferring the errors into the test case rather tha n picking them up, which is the point of the test. Also a dev has worked on the UI and thinks it is usable, he will write tests with ease, which will be followed as scripts. It is better for someone else to write them as they'll report stuff they find difficult to use.
Alberto Brandolini: The amount of energy necessary to refute bullshit is an order of magnitude bigger than to produce it.
|
|
|
|
|
Keith Barrow wrote: The developers need to interpret the specs and no matter how good will get the interpretation wrong or make an incorrect assumption.
Call me maybe thick but... wouldn't it be better if the developers clarified any ambiguity with their clients before basing their work on an interpretation?
I know I may live in cloud cuckoo land, but it's the way I tend to go about things - I do also meet people who do have a tendency to jump into coding when the spec is full of ambiguous requirements.
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
|
|
|
|
|
Test cases should should come from both BA & Developers as business Analyst know what is the change require for and developers know the implication of their changes.
Mark the answer as accepted if that worked for you .
And for down-voters please specify the reason to improve the solution .
|
|
|
|
|
In my case - I'm a business analyst, project manager, developer and mentor all rolled into one - with a client base of around 130 people - it's the way I like to work, not having to interpret an interpretation of a user request.
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
|
|
|
|
|
GuyThiebaut wrote: wouldn't it be better if the developers clarified any ambiguity with their clients before basing their work on an interpretation?
Where you realise there is ambiguity obviously, yes. Really the problem is that natural language is imprecise to which everyone brings their own set of assumptions about the ambiguity. I suppose "misunderstanding" is better than "assumption". I think this problem is intractable, otherwise natural language would rapidly become source-code directly.
There are other reasons devs should not formally (obviously only a total fool would not test their own UI as they are developing it) test their own stuff in the end-user capacity (as oppposed to unit/integration etc) but those reasons are less concrete and harder to sell to managerial staff.e.g. a [decent] developer is attached to their work and therefore biased, also developers tends to start from the standpoint "is it working" rather than a better foe testing standpoint of "how do I break it?"
Alberto Brandolini: The amount of energy necessary to refute bullshit is an order of magnitude bigger than to produce it.
|
|
|
|
|
Here's a nasty take on it, whoever specifies the requirement should also specify the acceptance criteria. The developer should prove the criteria is met and then QA confirm the proof.
Pipe. Inserted. Smoke.
|
|
|
|
|
Every requirement in the specification should have a section "How will we know this is done".
That becomes your UAT test case(s) independent of coding.
|
|
|
|
|
Writing test cases is boring. No one, including myself, wants to write them...but they must be done.
There is great responsibility in writing good, effective test cases, and none of which is fun.
|
|
|
|
|
Hi,
many of my friends have different opinion on switching the company. some of them changes job frequently even for minor money increment. i understand that if you are not getting a good growth(in terms of money and learning)/some bad office politics you should change your company but is it okay to switch company to get more pay/may be better opportunity (which we don't know if that is better, until joining the new company) even if you are happy with your current employer. what should be the right time for a developer to look for a change which will give him proper boost in his carrier?
Ravi Khoda
|
|
|
|
|
For me personally, the right job is not just about the money or opportunity. I want to work for a company that treats its employees fairly and with respect, where I feel that my opinions are valued, that I feel that I can make a positive contribution and that I am fairly rewarded for making those contributions.
I am not career minded and do not switch from job to job just for minor pay increases. This looks bad on your resume and many employers avoid such people.
There is no right or wrong answer to this. If you constantly want to explore new opportunities then maybe contracting is a better option.
"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare
Home | LinkedIn | Google+ | Twitter
|
|
|
|
|
Isn't there an app for that?
Peter Wasser
"The whole problem with the world is that fools and fanatics are always so certain of themselves, and wiser people so full of doubts." - Bertrand Russell
|
|
|
|
|
There is no "one rule" which covers when to switch. But...do note that switching too often can be a kiss of death for good companies. Recruiting costs money - lots of it - directly in terms of Agency fees (which are a percentage of the annual salary of each placed employee) or advertising, and indirectly in terms of the sheer time it takes to interview and decide. If you have a history of changing often then the implication is that you won't stay long, so you can get passed over in favour of a lesser candidate with a more "stable" employment history. It can also look like you are good at interviewing, and very bad at the job...
Don't change jobs just for money - unless the increment is substantial. Change because the old job is too easy and you need a challenge. Or because the conditions in the old company are intolerable for what ever reason. If you are happy with the employer, the work is good, the commute doesn't eat your life and soul, and your colleagues are good to work with then stay - if you can.
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
there are the people whom i know, they have change there job only once in 30 years of their career. So its totally depended on where you would like to work,are you happy with the work you are doing.
Is you work life is balanced(most important  ).
Mark the answer as accepted if that worked for you  .
And for down-voters please specify the reason to improve the solution .
|
|
|
|
|
Maybe its time to change the job when each Monday you wake up, realize you have to go to work and wish for a world apocalypse, so you can stay in bed a little longer and skip work.
Microsoft ... the only place where VARIANT_TRUE != true
|
|
|
|
|
Most people switch the company off at night, and on weekends, but I'd say it will vary with the the job.
«OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things. » Alan Kay's clarification on what he meant by the term "Object" in "Object-Oriented Programming."
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
