>try stuff out and don't be afraid to break things. It's just software.
When I was taking 3dsMax in college, my professor said something very similar. If you want to try something, save a copy and try it. Nothing lost. I've learned quite a bit in both 3d modeling and programming by not being afraid to break things.
Unfortunately that's not really an option for most business software, and it's also not always very apparent what various functions in business software actually does (in terms of secondary implications). My first programming job was developing tools to ingest reports from various front of the house systems into back office accounting systems. I would have users sit down with me and go through what reports they used, what data they wanted, and pull the sources for that data from the system.
It's amazing how many users would not know how to do much of anything beyond clicking exactly where they expected to in order to do the half a dozen or so day to day functions they needed to perform, to the point of not knowing where individual reports where because they were all run at the end of the day as a report package rather than on demand. Even clicking on menu items to see what the options were would get people on edge. Running reports should be something that's an idempotent operation, but there would still be reluctance. That being said, there also were reports that would have implications when run as they would either close things for the day, or various counters would be reset.
That's a long way of saying "just break things" isn't really good advice for users. Fixing things takes time and skill, neither of which the user might have. "Breaking things" might have far more significant implications that just going back to your last saved file. It also implies that the user knows when things are "broken". The longer it goes that they don't realize things are "broken", the more likely there will be problems and the more work was likely lost. That's also assuming they realize things are "broken", which is a point some users may never get to.
When I was taking 3dsMax in college, my professor said something very similar. If you want to try something, save a copy and try it. Nothing lost. I've learned quite a bit in both 3d modeling and programming by not being afraid to break things.
Unfortunately that's not really an option for most business software, and it's also not always very apparent what various functions in business software actually does (in terms of secondary implications). My first programming job was developing tools to ingest reports from various front of the house systems into back office accounting systems. I would have users sit down with me and go through what reports they used, what data they wanted, and pull the sources for that data from the system.
It's amazing how many users would not know how to do much of anything beyond clicking exactly where they expected to in order to do the half a dozen or so day to day functions they needed to perform, to the point of not knowing where individual reports where because they were all run at the end of the day as a report package rather than on demand. Even clicking on menu items to see what the options were would get people on edge. Running reports should be something that's an idempotent operation, but there would still be reluctance. That being said, there also were reports that would have implications when run as they would either close things for the day, or various counters would be reset.
That's a long way of saying "just break things" isn't really good advice for users. Fixing things takes time and skill, neither of which the user might have. "Breaking things" might have far more significant implications that just going back to your last saved file. It also implies that the user knows when things are "broken". The longer it goes that they don't realize things are "broken", the more likely there will be problems and the more work was likely lost. That's also assuming they realize things are "broken", which is a point some users may never get to.