For certain tasks I’m able to identify tools or practices, usually used by engineers within the organization that can either get them done really fast or prevent problems from occurring in the future.
However sometimes I’m asked not to use them because everyone else isn’t familiar with them and that creates a kind of key person risk in my position. It’s not an IT issue since everyone has access to this stuff and can install it, it’s just foreign to the actuaries.
Usually it’s an easy sell if the tool gets the job done fast. Managers like that. But the latter benefit - preventing problems from occurring later on is much tougher. Sometimes they just want the project done without thinking about how neglecting certain practices will make things much tougher later on.
I guess an easy example to point out is version control. Countless files get named v1, v2, vFINAL, vFINAL2 and so on or whatever. I sometimes point out that we haven’t needed to do things that way for the last 20 years or so and there’s version control that just lets you have 1 file and you can go forwards and backwards in time as you please if you need to undo a change or see what you did a long time ago and see exactly when you did it, and in short, makes life way easier, at least for me. But many times I’m asked to just “make a v3 on the shared drive” and that my way is just too hard to comprehend or wastes too much time (it doesn’t).
What grinds my gears is that I know I will be asked in 6 months to clean up the mess of all these inconsistent copies and I don’t want to get into some argument about how it didn’t have to wind up that way in the first place.
The more experience i get, the more keenly aware i am of the risks of using software that isn’t widely accessible in a group. It really increases the risk that something will break in a critical way in the future. If there’s a strong case for changing the software in one tool that one person maintains, i try to find some other tool that other people work with that would also benefit from that software. And if i can’t make a case for that, i generally don’t push for the new software for anything.
Subfolder for Prior, move the old versions there and date them. It’s a clunky workaround, but it keeps the working folder clean, and you can keep your version control tracking on the main file, and it resolves the issue for others who want multiple versions.
I’m not really interested in looking for a workaround. Since the tools are approved by IT, the worst case for me is I just use them no matter what and deal with the friction from the rest of the team. But I would like advice on popularizing them.
Start doing demos/trainings for others. Showing someone -how- something can improve their lives will work a lot better than telling them it will and expecting them to take your word for it and then go out and learn whatever the thing is to put your word to the test.
Sometimes it’s better to get change by evangelizing to individual people.
But other times it works better to, at the same time, get with a manager and formalize change using new policy. The policy comes first, and the culture change second. However, this works best when the policy change serves as a kind of agreement between everybody that they will try using this new tool together. The policy is as much of an agreement as an authority.
It may be that you want to try making policy changes in your department, for example for everyone to use version control.
Have you trained anyone on the non technical end of the spectrum, in git? How long did it take? How confident were you after that they could train someone else? Has something ever gone wrong where you lost version s in git?
Ask forgiveness, not permission. Do what’s better, document the decision and new process, and if someone has a problem with that, tell them to pound sand.
I second SpaceLobster. Think about the KISS principle. Keep it simple Simon (or smoothie in this case). Loading or committing something to Git is so much more effort than clicking the save button in Excel and saving to a network drive. Until Git is as easy to use as File Explorer, nobody outside of IT wants to use Git. Git is an IT tool, created by IT people, for use in IT projects, and to prevent IT problems. If you are not on an IT team, it will be difficult to convince your peers it is the right tool to use.
I disagree that git is only an IT tool. It helps manage complexity. It is one of several tools that may have been incubated in the IT department, but is extremely useful for analysis.
It does take an initial investment of time to learn. After that, using it becomes easier than not using it.
However, it is very reasonable for people, like you, to be skeptical about it. This is why I suggested to CS that he needs to take a more structured approach if he wants people to start using it.
If the project is complex, has multiple people working on it, and must be used/maintained for the foreseeable future, then I think Git is appropriate. It doesn’t matter if it’s an IT project or not; it doesn’t matter if it’s in Excel or Python.
However, there are simple projects and reports that would probably be made more complicated using Git vs. just saving to a network drive. It doesn’t need to be used for everything.
The problem I have with version control to avoid v1, v2, v15 [feel free to educate me] is that if there’s a change somewhere along the way, I have no way of knowing what was changed when. At least with vWhatever, I’ll know “I was working on ____.” Yes, I could also have a Notes tab that says how I evolved changes, but not everyone does this. [I frequently document changes in the “final” working file that I’m in.]
Not to mention, if version control isn’t always available or only goes so far back, I really can’t just “go back to this version.” Asking non-technical people to do Git is like asking the average person on the street to explain quantum physics. They never will, and trying to teach them has a high risk of being a giant waste of time.
I thought about the title in a broader sense, though. It’s not just file names and versioning. It’s anything where you’re trying to streamline processes, do things faster and/or in a more orderly, more logical fashion. If you have someone in a position that objects to change, it doesn’t matter how many people are in favor of changing a process and how clearly they explain the reasons to make the change: it’s not going to happen, which means everyone else now has to do things in a more inefficient way.
You are right, with a binary file like excel there is no way of knowing. (For text files, it can show you the exact lines that changed.) But at least you know exactly what the file looked like on a given day. So if you want to know what was in there when you used that result for XX, you can check. You also know who changed the file, which is useful for team work, but not for solo work of course.
I would still argue that using version control is easier than saving copies of the file, trying to figure out what each file version name means, etc.
I claim version control is really not complicated. It’s just different. More like trying to explain to people why they need a camera on their phones circa 2005 than trying to explain quantum physics.