Discussing conflicts between programmers and customers. A discussion of ambiguous situations between the programmer and the client, and a rating of the most conflicted programmer performers. - page 7
You are missing trading opportunities:
- Free trading apps
- Over 8,000 signals for copying
- Economic news for exploring financial markets
Registration
Log in
You agree to website policy and terms of use
If you do not have an account, please register
" Discussion on conflicts between programmers and customers. A discussion of ambiguous situations between a programmer and a customer, and a rating of the most conflicted programmer performers.
You can't come up with something universal that removes all conflicts. At the core of conflicts is the stupidity of customers. Why precisely the customers, because programmers have been in the field for a long time.
Of course, after the tenth or twentieth task the stupidity disappears. Of course, everyone is different, for someone it goes away during the first task, for someone it never goes away.
Get the customer to first dive into the subject, read the article HOW TO WRITE TK, learn the terminology is not possible. The biggest lie of the 21st century - "The license agreement read. I agree".
Educate the customer instead of a specific job on its TK, should sit in the price, it already sits there. To put it in the price again will not work. It is ridiculous to complain about low prices to job programmers, they are the ones who set them.
By and large there is no global conflict. There is a routine work. There will always be one-off cheats on one side and the other.
Are you talking about all your TOR or are you describing the contractor's working day as you envisage it?
" Discussing conflicts between programmers and customers. A discussion of ambiguous situations between a programmer and a customer, and a rating of the most conflicted programmer performers.
You can't come up with something universal that removes all conflicts. At the core of conflicts is the stupidity of customers. Why exactly the customers, because programmers have been in the field for a long time.
Of course, after the tenth or twentieth task the stupidity disappears. Of course, everyone is different, for someone it goes away during the first task, for someone it never goes away.
Get the customer to first dive into the subject, read the article HOW TO WRITE TK, learn the terminology is not possible. The biggest lie of the 21st century - "The license agreement read. I agree".
Educate the customer instead of a specific job on its TK, should sit in the price, it already sits there. To put it in the price again will not work. It is ridiculous to complain about low prices to job programmers, they are the ones who set them.
By and large there is no global conflict. There is a routine work. There will always be one-off cheats on one side and the other.
But all this does not mean that someone who sees circles cannot succeed in the market, look at the price of Impressionist paintings.
Genius
The "Scream" painting alone
The Russian language itself is very difficult to grasp logically,
This is a hypothetical representation of the executor's working day.
Well, everything is not so sad. Yes, the work takes not one order per day, sometimes up to 3, every day for several weeks. But the constant bugs and glitches I think it is too much.
I don't argue that there are orders and customers with which programmers have trouble understanding. This is karma of such orders or something else, but it exists.
The practitioners confirm that some orders are problematic and sometimes even on an easy surface. Sometimes I want to turn down the money and refuse the order that just blows up your mind and takes time.
But if we take a purely technical execution, then the quality programming upon agreed ToR (let's not take time to approve ToR) can take maximum 4 hours. This I take a contrived TOR for a couple of sheets of fine text.
Then there will be very small changes in 1-2 days, but it's already dust. To fix them in the end takes a maximum of 30 minutes.
If you are working with a programmer in the style - today I want one thing, and tomorrow add a new to the unfinished code, or add a feature that proger hangs and thinking about how to stick it into the TOR algorithm, of course - problems in this version will be.
And your TOR will stretch for a month or even six months. As a result you will get a false opinion about coding as such.
PS.
Always, remember, you should always before you start work completely discuss all the details of the algorithm and all possible combinations of cases of his work. Worthless to the performer, who in your TOR will not find a single particular case of algorithm failure.
There are always new things! The customer doesn't see them. But they must be seen by the contractor. And before the start of the work inform you about them and discuss them with you. But it is obligatory before the start of coding.
It is better to spend a week on the ToR and then write the perfect code in a couple of hours, than spend months looking for bugs in the volatile ToR. Neither you, nor the coder will enjoy such a process.
Even a sentence pronounced with a different intonation can have a different meaning and context.
That's where you're going with this. :)
Well, then you can safely take full responsibility for the result of the performer and what he will give you after speaking with different intonations on Skype :)
You yourself are to blame if of all kinds of communication you choose an airborne transfer of information. Thank God there is no video, or you could complain that the same phrase, pronounced with a different position of the right foot and a protruding ear can mean different things :)
For you, recommendation no 2.
Communicate with the performer with the keyboard only. If you can't form an idea in your head properly that you can't put it on paper, then what kind of understanding are we talking about? This is nonsense.
It is a very big misconception if you think that you can convey the deep meaning of a word with intonation in your voice.
The meaning of the word is already in the word and it doesn't matter if it's the uncle with the smoked voice or the grinning granny in the bread queue who will tell me to fuck off.
Always, remember, you must always before the start of work completely discuss all the details of the algorithm and all possible combinations of cases of its work. Worthless to the performer, who will not find in your TOR a single special case of algorithm failure.
There are always new things! The customer doesn't see them. But they have to be seen by the contractor. And before the start of the work, inform you about them and discuss them with you. But it is obligatory before the start of coding.
It is better to spend a week on the ToR and then write the perfect code in a couple of hours, than spend months looking for bugs in the volatile ToR. Neither you, nor the coder will enjoy such a process.