|
|
|
|
|
|
by thaumaturgy
3043 days ago
|
|
|
Leave your bubble. There is almost certainly some volunteer group in your area that could use an extra pair of hands. You might be tempted early on to offer suggestions to improve their efforts through better software; don't. Instead, just watch, ask, listen, and learn. Once you've got enough experience to be confident that you understand end-to-end how everything works in whatever group you volunteer for, you'll probably know the right place to apply your skills as a developer (which very well may just consist of, "um, you need automated backups"). Keep in mind that their priorities are different from yours. Things that you would probably consider essential or best practices are, for them, distractions and nuisances and costs to which they're super sensitive: updates, security, anything that's new and requires effort to learn. Software developers tend to see themselves as "systems thinkers", and think they can always improve any given thing by swooping in and applying some new software to it. That is often not actually the case, but they don't get their hands dirty enough and stick around long enough to realize it. |
|
|
I had my fair share of coordinating events during school for science competitions. One event we had was spread across campus and in areas with low wi-fi coverage. Our coordinator wanted all the results managed by google spreadsheets in real time. At the end of the day, it was completely unnecessary for logging results (PC problems, typing in broad daylight sucks, no power outlet for laptop, no wifi coverage, etc) and resorting to a piece of paper to write down competition results got the job done much smoother.
I've had to do IT for alot of my friends and families. The last thing I ever want to do is introduce them to a new piece of software, because its just going to be more work for me tweaking it to their liking and them learning a new software package. Not only that, they are just going to eventually install a virus anyhow. Then I'm going to have to reset their PC a year later, regardless of how well I teach them about safe practices on being online.
There's a japanese philosophy that revolves around these points made above, called LEAN (also, this is what agile development is based on). One rule is you adapt well proven methodologies and workflows first, unless the benefits of using a shiny piece of tech far outweighs its cons and risks. Another rule is to listen and understand, before you jump to conclusions. A 3rd rule is to eliminate waste, in development this is generally your buildprocesses / shiny tech / reliance on too many libraries.
TL-DR . Go low tech as much as possible if its an option. If not, the benefits of shiny tech need to outweigh its cons / risks. If you do pick a software package, pick one that's well adopted, easy to learn, and fits your use case.