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

:: Trust and the System

One of the most interesting aspects of the whole Blockchain thing is how it fails at one of it’s core concepts.

Consider, Blockchain requires that all transactions are made public using zero knowledge encryption to assure that both parties are valid and that no party can double spend. It is built off of the core principle that You Can Not Trust. Heck, advocates practically scream that Blockchain is superior to “fiat” currencies because they don’t trust the banks or government to manage them.

And yet, almost every sad case you read about on Web3IsGoingJustGreat is fundamentally due to someone’s misplaced trust.

Folks are trusting that various NFTs are legit, or not stolen, or will be valuable.
Folks trust that storage and management systems are secure and reliable.
Folks trust that the code for their smart contract is bug free and that the developers tested against all possible cases.
Folks trust that the exchanges are secure against attack and that their funds or holdings will not be stolen.
Folks trust that their fellow coin holders will not cash out and that their investment will continue to grow.

For a system built off of the concept of “Trust No One”, there’s an awful lot of trust at play.

It’s almost as if having a trust free system is infeasible. Unless you have unlimited time and resources, you can’t verify and validate every aspect of the system you’re partaking in. You can’t presume that the various exchanges aren’t favoring other exchanges over your transactions. You’re not always going to audit the code in whatever smart contract that’s tied to your Ether transaction, nor will you validate that the language implementation that runs your code is error free. You not going to independently audit and validate every system and interaction point that is required for your transaction to be recorded, validated, and authorized. Ultimately, you have to trust that someone, at some level is acting in your benefit for some reason.

And that’s where the Trust No-One thing kinda/sorta breaks down.

The problem is that once you trust someone, you immediately have to accept all the parties that they trust, regardless of whether or not they disclose those trusts. You can safeguard against those relationships to a degree, but it’s not going to be perfect because no trust relationship is. In that case, you have to start asking “so, what really differentiates this system with any other one?”

Well, for one, traditional “fiat” based systems have various regulations, monitoring and established law based on the fact that they’ve been “a thing” since the dawn of civilization, where as CryptoCurrencies have been around for less than 20 years and very proudly don’t have any of those. So, basically, you have a system of finance that is based off of centuries of preventing damage from bad actors trying literally everything possible to a group of dudes pushing a “Zero Trust” system by saying “Trust me.”

i guess, maybe, the big reason i’m cynical about blockchain and web3 and all the other crap is that i’ve been in tech long enough to know that you don’t trust tech.

:: 19 years

According to my own records, i’ve been running this blog for 19 years now.

Well, 20 if you think that the new millennium started on January 1st 2000.

According to the same indicator, i’ve published over 5500 posts.

i *could* make a comment here about this blog predating “web 2” and facing all the same challenges that face whoever wants to do any “web 3” thing (and probably as successful about it), but that would probably be snarky of me. Suffice to say, that you’ll see that not much has changed here, nor am i really planning on changing things in the future.

Japanese phone-booth green color scheme and all.

:: A Few Degrees out of 360

Every year (or twice a year) i’m reminded that most of the employee review process was created by folks that are not introverts.

This is highlighted by things like 360 Reviews, where you’re asked to provide feedback on lots of folk, like peers, and managers, and co-workers, and strangers. For introverts, this is kind of the worst case thing they can be asked to do. It’s not only forced social interaction, it’s forced social interaction that will impact your livelihood and whatever tenuous co-working relationships you may have managed to foster. Pile on to that the fact that folks have MASSIVE imposter syndrome and it’s just the worst time.

This is not to say that i don’t understand the value of this process. Managers are busy people who have enough on their plate that they often can’t assess a subordinate’s skills correctly. Likewise, relying on the viewpoint of a single individual means that there can be things missed. Well rounded feedback is invaluable in that it’s the outside perspective that we may be missing. i don’t know when i am screwing up for reals partly because i’m convinced i’m constantly screwing up, so having someone else give good critique about it is, well, critical.

Of course, my paranoid brain also notes that giving negative feedback, particularly around review time, and in a channel that is used by management, means that management has lots of ammo available to shoot down reasons that you might get a raise / promotion / recognition / whatever. “Well, Bob, i see here that you resolved seven critical security issues and single handedly kept this pillar system operational, but Dave thinks you need to write better comments, so here’s a ${CURRENT_BASE_INFLATION_RATE – 1}%1 bump in salary. We’ll see what we can do about that comment issue next quarter, right?”

Added into the fun, folks are often asked to list all the people they worked with over the prior period. For introverts, this is going to be a small number. Maybe three or four if they’re feeling super social one week. It may be the folk that review their code, or folk that they might have talked about a project with, or just folk that they have a reasonable level of trust in. Which the other person may not realize. Thus the whole “from strangers” thing above.

Getting back to the top point, i get the feeling that whoever tends to design these things presumes that everyone has a rich network of connections and believes that all interactions are done in good faith. i understand that it’s impossible to address each and every persons broken psyche, but i do wonder if there might be a better way to approach this for folks that are not, let’s say, outgoing in the workplace.

Maybe ask them to put together a list of the folks they felt were meaningful (either good or bad) to them over the past few months. Maybe get in an introvert whisperer who will chat with folks to ask what about that person was meaningful and help craft a statement that the introvert can agree with. Point out that there might be things that the other person could do differently that might make working with them easier or things they do now that shouldn’t change.

People often say that introverts are socially awkward, but i’d argue that it’s because they’re hyper aware of social interaction. They are well, well aware of the weight that actions can take and they don’t want to cause undo damage. These sorts of requests are difficult to deal with because introverts are keenly aware of the sorts of outcomes they carry. For them, there’s no way to do this in a “light, casual” manner. They’re dealing with someone’s life and don’t want their misjudgement to be what ruins it.

Of course, i’m not a behavioral scientist, psychologist, or extrovert (regardless of how i may act), so Far Smarter People than i should probably work on this. i also wonder if it might be good if companies at least recognize this as a source of potential stress and at least give employees ways to either address, or help address it in their own ranks.

If not, folks are welcome to join me twice a year as i stare out into the endless sea surrounded by a dark cloud of anxiety and dread.


1 This is a pay cut.

:: Web 3. No

Recently i heard about Web 3.0.

Ok, not that recently, but like all such things, it bubbled up enough that i finally decided to pay some attention to it. Mostly based on this thread touting the glory that would be Web 3.0

Web 3.0 is a bit… i’m going to say nebulously… defined. The shortest answer is some hand waving about using blockchain to ensure that content remains distributed and not centralized like it is with Web 2.0. (Yeah, i know. Granted, i had thought that Web 2.0 was where every site had an API and you could use data however you wanted, and THAT got replaced by Web 3.0, but apparently i was jumping the gun a bit.) To be honest, i still haven’t found a good tutorial about how one goes about setting up a truly distributed node that is Web 3.0 compliant, but i found a bunch of articles that point to subscription sites where you can easily get going building your unique “Hello World” site, for reasons? Even those are mostly focused on instantiating identity (although those might be semi-disposable, and since there’s payment, i’m not going to use ‘anonymous’ because, yeah, they’re not at that point.)

i have questions and concerns about this proposed system. i mean, aside from the not insignificant concerns about block chains in general, i’m just going to focus on that whole “content” part.

Let’s say you’ve created some bit of media. It could be a book, song, video, picture, or just a short, pithy message, but by God, it’s yours. You initialize a chain tied to yourself and the media and set it loose on the internet, and… well, then what? i’m going to presume that there’s some media amplification site. Some site where folks tend to already congregate and share quality content among themselves. A place where content may be suggested (or blocked) by some controlling entity based on either some set of rules or a set of, say automated processes that automatically highlight content of interest. Maybe you’ll use one or more of those. i’ll note that one of the BIG reasons that sites got away from having APIs is the general headaches they introduce for very little return value.

Ok, so now your precious media is gathering a bit of a following. Yay! So much so that you’re seeing your content duplicated, because the blockchain only protects the concept of ownership, not the content, and the media can be easily extracted using any number of methods, like screenshotting, or setting up an external recording device. Oopsy!

Right, so let’s now say that you’re a very large media company, one which has a VERY strong investment in media generation, management and control. Where Intellectual Property (IP) drives every decision. Obviously, you don’t want to just hand out your money source, so instead what you hand out are licenses that allow customers to consume your IP within the constraints they’ve paid for. For them Web 3.0 is awesome, because now there’s a hard declaration of who crafted the IP, who consumed it, and where it might go beyond that. Now you’ve got a super clear cut case if a content owner duplicates the data out of license, or shares it, or passes it along to unlicensed parties, or anything else you may not like, and you’ve got the legal trail to prove it.

Of course, users might try to bypass your protections in fun ways, so you implement fingerprinting systems to look for partial content and thankfully similar existing systems are flawless works of science that are never ever abused. Nor do studios ever bring charges against customers that are not grounded in hard evidence. i mean, the internet is a copy machine, and this adds a fun machine id code to everything.

So, yeah, that’s just one aspect of Web 3.0 that i started mulling over.

There’s a term i’ve heard recently that i like. Technologists tend to be blinded by Utopia. It fits in well with my theory of the Magnificent Hammer. (You’ve heard “When all you have is a hammer, everything looks like a nail”? Well, if you work in building, designing and selling hammers, suddenly hammers are the perfect tool for EVERYTHING. That’s a Magnificent Hammer.) Being blinded by Utopia means that folks become so enamored with their end goal and the wonders that it will bring that they completely miss the horrors that may accompany it.

Web 3.0 (as it’s defined here) is full of raging horrors and you really don’t have to look super hard to see them. i just picked one at random. i didn’t even get into the whole mess about how this destroys privacy, potentially limits access to just the rich, and all the other woes i can spot.

Just gonna pass on this one.

Hard pass.

:: Asteroids and Papercuts

i work on long lived projects. These are projects that tend to run for years, and might even be considered to be tech debt magnets. That’s pretty natural, but it’s interesting considering that the rest of the company tends not to really think that way. They are instead focused on “the next version” of a product.

Since i’ve got services that need to last for years, i’ve got to manage levels of tech debt that happen. Some of it for internal reasons, a lot of it for external ones. This is because i need to balance working on those services with new services we’re rolling out because we’re generally understaffed and have lots of priorities.

To that end, i’ve started classifying concerns into “Asteroids and Papercuts”, and i’m wondering if others might find the framework useful.

Asteroids

An Asteroid is a big, potentially civilization ending event that will arrive at a known time. It’s something you need to pay attention to now, but the date is still (hopefully) a way off. This can include things like:

  • The language your service is built on is no longer actively supported or receiving security updates.
  • You need to move your data from one, cloud based, proprietary data store to another cloud based, proprietary store for reasons.
  • A key individual who has deep domain expertise is leaving the company.

(All of those things happened at least once with projects i worked on, so yay!)

When dealing with an incoming asteroid, your priorities are:

  1. Knowing the date
  2. Knowing the damage
  3. Knowing the mitigations: Short term and long term
  4. Putting together the work load estimate that is based on worst case scenarios

That last one is the trickiest, and kinda requires your most pessimistic attitude. Basically, try to factor in the other things that can and will go wrong. It’s important to avoid jargon, undefined TLA (Three Letter Acronyms), and presumed understanding when writing each of those up.

For instance you’d want to write up a summary that clearly specifies the problem, includes dates and provides a reasonably terrifying summary of why this is really important. So for something like a language going EOL:

This is something that will probably require at least a day or two of focused effort.

If you can’t get the time to do that from your management, be sure to get that in an email or document so that when the service fails, you have proof that you were told what you work on isn’t critical. (You don’t have to be snippy, just a quick email saying

If the manager insists on doing an in person meeting, take notes and feel free to send a follow-up email that includes the points of discussion and resolution, and ask that they confirm that this is correct.

Also start looking around for a different team/org/company because this is bullshit politics and your manager is setting you up to be the sacrificial offering when it all goes to hell.

Once you have a plan, treat it as a high priority task and get your various product people aware of it and working toward it. Make it a banner line on your weekly reports. Time is your asset and enemy because it will go faster than you expect, particularly if you have other priorities, and you will have other priorities.

Papercuts

Papercuts are smaller annoyances. Things like blocked library updates or significant bits of notable tech debt. The thing about papercuts is that while they’re small, if you get enough of them, they will kill you. (e.g. Death by 1,000 Papercuts)

While these tend to sit in the backlog forever, it’s important to track them because they can also fester and turn into significant events. Each papercut can be a unique thing, so it can be hard to come up with as clear strategy as for an asteroid, but you should have one in any case. Fill out the bug/issue/ticket with details for future you. Note the relationship a given papercut has internally in the project or across the org. Show not only that it’s important, but how a delay on fixing it impacts the bottom line. Basically, present it so that someone who has no understanding of the tech or why this is important can understand why this is important.

Of course, there are lots of other issues that you can address, and lots of ways to categorize things. Not everything is or should be an Asteroid or Papercut. There will be some things in your backlog that are there to die, neglected and alone, but there will always be things that are more critical that you need to pay attention to. Your team and mileage will vary, but hopefully you now have a framework to help present critical issues up the chain if you didn’t already.

Blogs of note
personal Christopher Conlin USMC Henriette's Herbal Blog My Mastodon musings Where have all the good blogs gone?
geek ultramookie

Powered by WordPress
Hosted on Dreamhost.