In discussing blockchain opportunities with clients who are curious about how it might serve them, I've realized a couple of things, I've realized a couple of things.
Not all problems have some type of blockchain answer. The question you should ask yourself is, "Does another type of data storage solve this problem equally well?" Or "Am I just doing this so I can say blockchain?"
You should also ask, "How am I going to generate new revenue or save costs?" Or "What business outcome am I after?"
If the answer to number 2 is "Reinventing My Industry", that will come with some friction.
In looking at this challenge, some of the problem comes from ourselves. We haven't seen enough, done enough, or tried enough things to always understand what it does or how it will change things.
I'm speaking for myself here. If the answers aren't in my head, it isn't the technology's fault, it just means that I don't quite see how to fit it in. Or it's possible that what it will do is so radical that it may require some (additional) visionary ideas to help light the way.
Visionaries, apply here.
So, blockchaininess is a term for an idea that matches what blockchain technology does best. So far these seem to share that they are broad and sweeping in their implications, if they're going to be successful. This doesn't mean it will always be that way, but it isn't an incremental technology, which is why it can be so hard to look at. It isn't like stuff you've done before.
It could also be a term for a way of thinking about problems that inherently sees problems that can be solved well by blockchain.
Some of this will take time. But don't wait. My recommendation is to do some reading and start thinking about it. Start trying things. It is a powerful tool - look no further than Bitcoin for evidence of that.
What it will do for us, in technology and beyond, is still something we can decide and influence.
At least one other person is using the term blockchaininess. There was one other but it appears to have been edited out of their twitter profile. I'll list them for completeness:
I switched back to the Mots theme so that I could put full posts on the home page.
I did this so that someone arriving here can see content directly and no clicks are required to get there. Although you do need scrolling, since some of my posts are long. I may shrink the font at some point to get more on the screen.
It took only some minor mods to Handlebars files to make this happen. Great design from Ghost that you can make this type of change with only simple modifications.
As I mentioned in an earlier post, I'm a big fan of Seth's Blog and I'm going to take a closer look at what he does. Partly for my own edification and partly because I think it is worth studying a master's style.
Here is the first post I want to consider (it's very short, click the link and then come back):
Why this post in particular? Well, because this is something that I try to talk about regularly in check-ins and mentoring with colleagues and employees. So, it speaks to me. And it does it in an interesting way.
For the record, I've never conveyed it as eloquently as this. See the quotes below to get a better sense of how this has gone for me.
Seth, in a very concise and inviting way offers his vision. That fence is in your head. What makes it easy to hear when he says it?
This is the narrative structure of these three sentences:
It starts with the concrete. A fence starts out just being a fence. Which leads to 2:
Where's he going with this exactly? There's a small amount of suspense about the fence and where this particular post is going.
Next, he turns this somewhat obvious statement about a fence as a deterrent (can't really stop you) into what it implies metaphorically inside the reader - we are conditioned by fences to obey fences.
Oh, this is about me you say? That's surprising.
Which leads to the last part - you (the smart one reading this) can see the fence for what it is. What are you gong to do about it?
It works a lot better this way than simply saying: "Those things that your boss does are not really impeding you, you are impeding yourself."
Because, with that approach the person you're talking to is inclined to say, "No, it's not. My boss really does those things and it's hard."
By doing it this way it starts out not being about you the reader at all, and only becomes that way once you identify with it.
What makes this all work:
It is about you the person reading it, but it doesn't come out and hit you over the head with it in the first sentence.
Slowly it reveals itself as being about the reader. It does this in the gradual progression from sentence to sentence. Sentence 1 no obvious pronoun, general statement. Sentence 2 uses we - so we are all in this together at this point. Sentence 3 now it comes out and hits you with you - you ignore that fence. OK?
An excellent piece of writing, packed into a small space.
I'm a reader. As a reader, it's just flat out great. You should read it. It's interesting and informative. That's a no-brainer.
As a writer, what interests me is the breadth of the work. I feel like he's able to write about a lot of different things and they always tie back thematically to his main focus which I will sum up like this: creativity in the workplace.
He might not sum it up that way, but I will. Because that's what I think ties it all together.
He's not writing for artists living off the grid. He's not writing for people who have no interest in creativity or change. It's pretty clear and gives him breadth on topics ranging from the psychological, to the cultural, to the career-related.
Still, how does he do it?
I'm going to write some some of my own blog posts dissecting a couple of his recent posts to figure it out. I'm interested and I think I can figure it out.
More reasons why code is harder to read than write:
Code is meant to be executed by machines, not to be read by people. In other words, you, as a human, are not the intended audience. Everything about the program you're trying to read, including the intent of the language designers, was focused on machines and not on you.
Developers don't get paid to write, they get paid to build.
Developers prefer to build things over writing about it or adding comments to code.
There is always a deadline. The deadline is never about writing comments or documentation.
I've posted this article recently, but it got me thinking about why code is harder to read than to write. So, I will post it again, to make your life easier and explain why I think that code is still harder to read than write, even all these years later. Here's the article:
The title of this post seems counter-intuitive because we think of reading and writing in relationship to human language, but programming languages are not like human language.
What are the important differences? Here is the main one:
Programming languages can't be read aloud.
So when we talk about 'reading code' we're using 'reading' in a purely metaphorical sense. When you 'read' code you don't actually read it - you're looking at it and trying to make sense of what it does.
This is nothing like reading a book, paragraph, or sentence written in human language.
When you review code you study, you re-read, you look things up. You jump around from file to file. You may consult web pages. Even in programming languages you are familiar with and with a business domain you know, these tasks can be time consuming.
You're trying to 'read' something that can't be read, across many files, and trying to ascertain the author's intent not just comprehend a sentence.
An equivalent would be trying to read in a language where you had to look up every third word, every time you read something because:
Every author used the language in a novel way. AND
Every page of a book was put in a different file and they were constantly referencing each other and not in order.
It would be hard. And it would not really be reading. That's what 'reading' code is.
Jonathan Fries on .