Oops! Something went sideways.

Looks like the styling got goofed up. Sorry about that, unless it's what you wanted. If this isn't what you were looking for, try force refreshing your page. You can do that by pressing Shift + F5, or holding Shift and clicking on the "reload" icon. (It's the weird circle arrow thing "⟳" just above this page, usually next to where it says https://blog.unitedheroes.net...)

isn't quite ashamed enough to present

jr conlin's ink stained banana

:: Get Off My LAN

i’ll admit it, i’ve been having an increasing number of “Get Off MY LAN” moments.

i suppose you could also declare these as “Old Man Shouts at iCloud” stories as well.

As i get older (and one supposes, progressively more jaded), i’ve been increasingly frustrated by just how often folks build things that they haven’t really thought out. Mind you, twenty years ago, when we were first building this crap, you’d be excused for not knowing that there’s little difference between “Success” and “DDoS Attack” or that cracking SHA1 would be a simple matter of harnessing the power of an internal graphics processing unit, but you can’t really say that anymore.

Technology, at least in theory, is supposed to build off of itself. We’re supposed to be at that stage of the game where we’ve determined reasonable, objective facts about how to create and provide services. There will always be new tools introduced, but fundamentally the principles of data exchange and processing should really be kind of A Thing™ by now.

There are supposed to be a few Golden Rules that all engineers follow (or at least know of):

  1. Be lenient about what you accept, strict about what you create.
    Other people will screw up, try to work with what you’ve got so that things continue to work reasonably well. File bugs against the crappy providers, but don’t reject them unless it’s total jibberish. That said, only output stuff in strict, predictable form that adheres to published standards so that everyone else isn’t trying to accommodate you.
  2. Play with the new, work with the old.
    Play and explore new technology. Revel in discovery and insight, but when it comes time to provide a service for more than a few hundred people, build it using boring, well tested, reliable tools and technologies. If the new stuff is good, eventually it too will become boring, well tested and reliable. Every project should dream of becoming “useful, but not hip” because that means you’re now key to infrastructure.
  3. Bad guys have infinite time and infinite resources
    If there’s a flaw in your code, bad guys will find and exploit it. Protect your systems from yourself. If you can break it, even with some attack that is so remote that “nobody will ever do that”, someone else will do that attack.
  4. Don’t fall in love with your code
    You may have come up with a good solution. Someone else may have come up with a better one. Always be willing to admit that someone else’s answer may be better than yours (again, metrics beat statements), and be ready to move to it.
    Yes, i added this one after i wrote the original.
  5. There is no One True Tech
    No technology is perfect and all applicable. Everything sucks for some reason. Only a fool uses one tool to solve all problems. The first question any maker of hammers should ask is, “Do i need a screwdriver?”
  6. Open is better than closed
    Being open is like growing dozens or millions of extra brains. Suddenly, it’s not just you or a few folks working on a problem, it’s lots and lots of folks, constantly working on a problem. Of course, the Achilles Heel of any open project is getting someone else to care about it, but that’s where the rest of the rules come into play.
  7. Write your documentation for five year olds
    There are people smarter than you. They have different areas of expertise and interest than you do. Not everyone has spent the past decade focused on AES encryption wrapper math, phoneme pattern analysis, or efficient regular expression syntax. By all means, encourage folks to explore the wonders of elliptical compression algorithms, but understand that the reason they are looking at your library/code/application is because it’s a small part of the larger problem they’re trying to solve. Spending hours to learn interesting tricks in 64bit binomial storage so that they know to call your function with a proper set of prime Fibonacci numbers isn’t going to make them love you.
  8. Teaching makes you smarter
    You only really understand something when you can explain it to someone else. This ensures that you understand not only one aspect, but the various effects and inputs so that you can answer their questions. Teaching someone else will make you say “i don’t know” a surprising number of times.
  9. You are not alone
    This is a big one. If you’re pounding on a problem, chance are, so is someone else. Or they’ve worked a problem similar to yours in some fashion. Ask and answer questions. Share knowledge and findings. Humans are capable of sharing information and that’s what made us more successful than Bonobos. Use and contribute to that advantage every chance you can.

And, yet, every goddamn day, i see folks gleefully ignore those rules. So i wind up posting cranky notes, laughing at other people’s completely avoidable failures, and otherwise turning into an angry old coot standing on his digital porch yelling at the kids these days.

Honestly, this is why the jocks and douchebags became Brogrammers who write crappy code. There’s nothing preventing them from doing it and no tools for pointing out the obvious flaws.

Blogs of note
personal Christopher Conlin USMC memoirs of hydrogen guy rhapsodic.org Henriette's Herbal Blog
geek ultramookie

Powered by WordPress
Hosted on Dreamhost.