It is the employer's problem, there is also the matter of the competency of the line manager.
Have you ever been asked to implement a feature with the first question being 'how long will it take?' for you to pluck a figure out of the air?
In these scenarios a voice inside my head wants to ask 'well, you are the manager, aren't managers supposed to know these things?'
There is an aspect of this going on here. The manager should have some idea of what is involved in the task and have an idea as to how best to solve the task.
Once upon a time I learned a lesson about lying from The Simpsons:
Homer: Marge, it takes two to lie: one to lie and one to listen.
There is an aspect of that to this situation. I also am not too sure that the deliberate errors are the wrong thing to do. With my coding errors I often jest that these are 'deliberate mistakes' there to just see if anyone is paying attention. I have also joked before now that there is 'one deliberate mistake' in there to check that people are doing the testing properly.
In a fake-news world where people can be economical with the truth the OP has the option to weasel out of the deception that way.
So how to rescue the situation in such a way that everyone wins?
Maybe the OP can taper down the deliberate errors to make the work perfect. If there is also a claimed drop in 'time taken' to do this and some vague talk of 'macros' used to 'double check the work' then a slightly more honest bargain can be struck where it is acknowledged that some initiative has been taken to do things better is rewarded and not punished.
For the line manager this can be a definite win with nobody apparently played as a fool.
> With my coding errors I often jest that these are 'deliberate mistakes' there to just see if anyone is paying attention. I have also joked before now that there is 'one deliberate mistake' in there to check that people are doing the testing properly.
If I was your manager, I'd have an issue with this. Testers are there to methodically work through the code, acceptance test, and so on.
Not to play "find the possibly invisible needle in the haystack that the dev claims exists as his way of showing they're doing their job right". That's called a wild goose chase.
This is definitely in jest and is most likely to be when I am providing a tutorial or at an early requirements gathering stage of a task, i.e. definitely development code or numbers scribbled on a napkin. I know humour is verboten at times on HN, but in some situations, e.g. say you have forgotten to close a tag in some plain HTML and the whole page goes table shaped, then you can lighten the mood and engage with people that bit more by feigning 'deliberate mistakes'.
With people that are not versed in how to test in a proper disciplined manner with some methodology to it there are occasions when you need them to focus more than they otherwise might. This could be important documentation rather than code. In these circumstances you can include a 'deliberate mistake' and set them the task to spot it. So long as you point out the answer if they don't spot it then all is good. This is harmless and is a good way of achieving the primary objective of getting your work double-checked outside of a formal testing environment.
This is a bit like the legendary M+M's in the rider that bands have. If the venue gets the M+Ms right then there is a good chance they will have got the other requirements of safety, etc. correct.
> In these scenarios a voice inside my head wants to ask 'well, you are the manager, aren't managers supposed to know these things?'
That's a double edged sword. What would you think of a manager saying: you're on this task, it's going to take you 2 days? It's not better in my experience.
Well no it's not better but I once had a manager that would reply with "It doesn't take that long" to every estimate I made. Even though he had no idea how to do it himself or could even list the risks involved in such a request. Clearly that manager was not a good one.
Wouldn't it be easier if estimates are treated as such and everybody gets treated like a professional? Needless to say, I could only stomach 6 months in that work place.
Have you ever been asked to implement a feature with the first question being 'how long will it take?' for you to pluck a figure out of the air?
In these scenarios a voice inside my head wants to ask 'well, you are the manager, aren't managers supposed to know these things?'
There is an aspect of this going on here. The manager should have some idea of what is involved in the task and have an idea as to how best to solve the task.
Once upon a time I learned a lesson about lying from The Simpsons:
Homer: Marge, it takes two to lie: one to lie and one to listen.
There is an aspect of that to this situation. I also am not too sure that the deliberate errors are the wrong thing to do. With my coding errors I often jest that these are 'deliberate mistakes' there to just see if anyone is paying attention. I have also joked before now that there is 'one deliberate mistake' in there to check that people are doing the testing properly.
In a fake-news world where people can be economical with the truth the OP has the option to weasel out of the deception that way.
So how to rescue the situation in such a way that everyone wins?
Maybe the OP can taper down the deliberate errors to make the work perfect. If there is also a claimed drop in 'time taken' to do this and some vague talk of 'macros' used to 'double check the work' then a slightly more honest bargain can be struck where it is acknowledged that some initiative has been taken to do things better is rewarded and not punished.
For the line manager this can be a definite win with nobody apparently played as a fool.