Do you make mistakes at work?

Detroit

ThemeOne wrote: »

I wouldn't worry about it. Most managers like people who make mistakes anyway as it validates their superiority.

I don't know about superiority, but I would have thought most managers were sufficiently validated by their higher status, authority, autonomy and salary.

ThemeOne

Detroit wrote: »

I don't know about superiority, but I would have thought most managers were sufficiently validated by their higher status, authority, autonomy and salary.

Some are, but I've encountered many who are not very good and feel threatened by subordinates who show much aptitude or efficiency.

WobblyDog

In software development I make mistakes nearly every day. It sometimes only becomes apparent after several days work that a particular way of solving a new problem is going to be messy or impractical, and I need to re-work my solution based on what I've learned. We even have "code reviews" in which a same-level colleague looks in detail at what I've done. In software development, there's a move towards "Agile", which could be loosely described as "do things quickly, then go back and fix the mistakes which become apparent with the benefit of hindsight".

It all works OK, except in the cases where people try to use other people's mistakes against them, which happens occasionally.

getmore4less

WobblyDog wrote: »

In software development I make mistakes nearly every day. It sometimes only becomes apparent after several days work that a particular way of solving a new problem is going to be messy or impractical, and I need to re-work my solution based on what I've learned. We even have "code reviews" in which a same-level colleague looks in detail at what I've done. In software development, there's a move towards "Agile", which could be loosely described as "do things quickly, then go back and fix the mistakes which become apparent with the benefit of hindsight".

It all works OK, except in the cases where people try to use other people's mistakes against them, which happens occasionally.

Great if you don't know what you are doing but can be a disaster on projects where you know what you want.

These days with software development, tools have been developed over the years that make mistake rectification very common and taken for granted.

Dynamic syntax checking and compiling was not available in the early days, then you wrote your code by hand, manually checked it very carefully as you sent it off on punched cards to get compiled, turnaround could be measured in days in some places.

Hardware was costly and machine time precious so your testing could only be done in down time, no spare sandbox test bed(either real or emulations) to try stuff out, sometimes it would be shutdown&backup, run tests, restore the live data before bring it back up.

As you move to multi people projects, code reviews, SCC, build and test farms, make the process of development a lot more fault tolerant

One of the most common point of failures now is just building the wrong thing. Works perfectly but is not what is needed or wanted.

Very costly over ambitious projects with long timescales and no interim working usable deliverables that start to give return on investment and validation of the whole concept fail a lot more often that they should.


These are the sorts of mistakes that cost £millions and put a few missing copies of some notes for a meeting into context.

robatwork