Jonathan's Blog
name

Jonathan's Blog

Mindful Leadership and Technology

TagTechnology
Featured

Technology Top Level Domain TLD

Why does that .blog domain cost $7000?

Posted by Jonathan FriesJonathan Fries on .

I was shopping for some domain names and I decided to look at a .blog address for something.

First of all, I noticed it was availble some places (GoDaddy, Network Solutions) and not others (Google Domains). Also, the .blog address cost $7000 - that's high compared with what I usually pay for a new domain.

So, I did some research.

The world is a different place than it used to be. Today there are new Top-Level Domains (TLDs) (.blog, .pizza, .business) with much more variety than there was a few years ago.

So, what's up with the pricing? Older TLDs (.com, .net, .org) have fixed wholesale prices negotiated by ICANN (The Internet Commission on Names and Numbers), which is a kind of regulatory agency for these things.

For newer domains - .blog, .rich, etc. They are controlled by different registries who set the prices. These agencies are free to set the prices as they please and the names are therefore subject to "supply and demand", as the old ones were not. I will get to the reason for the quotes in a minute.

In the case of the .blog domains, they are controlled by a company called Automattic from San Francisco.

Of course .com domains have supply and demand economics, just not for new names.

In theory Jeff Bezos could sell you the domain amazon.com - and it would certainly cost you a pretty penny. It would get you a lot of traffic to your site for a while until people realized that the company had simply moved it's amazing e-commerce platform somehere else and whatever you had was not as good.

Of course Mr. Bezos would never do that, but he could. And the market for the name would be driven by demand created by people who wanted to do something with the name amazon.com or wanted to use it to drive traffic to other existing websites.

It's clear that a good portion of the value of a domain in this type of after-market situation is in the content that that exists at a domain and the value created under that name previously. Also, there may be value in a shorter name or a more recognizable or memorable name. Paying for a premium domain might be worth while for some, because it can make you look better.

The best example I can think of this (for new .blog domains) is Seth's blog. Seth smartly snapped the domain Seths.blog. I would imagine it was expensive as domains go, but it makes sense because it matches his brand and it is much shorter than his old domain. And because he has a boatload of content already branded under the title seth's blog, so the short memorable title was valuable and he had the money to buy it.

So, why "supply and demand" and not supply and demand? Two reasons:

  1. The registries still have a quasi monoply on the name, if my name is Jeffrey and I am starting a blog, I can't buy jeffrey.blog from just anyone - it ultimately is controlled by Autommattic and they set the price.
  2. What's the value of a name, prior to having content attached to it? If amazon.com was owned by a Brazilian travel agency instead of the world's largest online store, it's value would be totally different. Every entrepeneur who looks at a name thinks of what they can change it in to, meaning that a crappy name could become a great name, with the right content or development. Surveymonkey.com, anyone? This scrambles this market a little bit.

So these registries have smartly designed an algorithm that prices shorter names higher, and must have some correlation with other names that get sold in other places. That's my guess, based on the following limited sample (as of May 3rd, 2019 from GoDaddy):

jonathan.blog costs $7000
jonathanfries.blog costs $9.99.
jeffrey.blog costs only $700.

I guess people named Jeffrey don't pay as much for domains.

Featured

Leadership Technology

Understanding the Thing that Didn't Happen

Posted by Jonathan FriesJonathan Fries on .

I was using a social media tool the other day and it recommended about 25 articles in a row about some electoral politics in a different country.

This was essentially the same story, 25 different times.

I didn't click on any of them because I post very few articles on politics.

So, my lack of engagement with a topic that they thought (for unknown reasons) that I would be interested in should have been considered a significant 'No' vote. I voted 'no' on the same thing, 25 times. This is the way it happened in my head.

Will they be smart enough to pick up on this? Are they aware of the things that I don't do?

We're all aware of the old adage - 'The squeaky wheel gets the grease.'

My squeak, as it were, was pretty significnat. But it was a no action squeak, which would not be measured unless someone was looking for it. And had analytics or code written to look for it.

Of course you'll always see the end result of this - when someone votes with their feet or dollars or clicks to go somewhere else. But will you know why? Or will you only feel their departure?

Featured

AI Technology Leadership

AI Resources - TensorFlow

Posted by Jonathan FriesJonathan Fries on .

I mentioned in an earlier post some free Amazon resources that are available for managing AI projects - I think those are really valuable and they are still available here:

ML for Business

These are really good for getting an overview of what a typical machine learning project looks like.

If you are interested in going a little more in depth and seeing the guts of what machine learning looks like it is worth taking a look at the TensorFlow tutorials:

TensorFlow Tutorials

There are five links on the bottom of the page that will take you to 5 different tutorials, I'm currently on the third, but it is very educational.

In one sense, these aren't for the faint of heart. They are really doing real machine learning, and if you're like me, you won't understand some of it. That's OK.

You need to look past a few things you don't know and just plow ahead they really do give you a great idea of how machine learning actually works.

Unlike the Amazon courses, which don't really require any prerequisites, you probably need some experience with development tools to get through the TensorFlow tutorials. They require that you are comfortable clicking a Play button like you run across in development environments, and sometimes you are kicked back warning messages that you have to look at, stomach, and promptly ignore.

While I've tweaked a couple of print statements to get the notebooks to show me different stuff, I'm really not messing with the core of what the notebooks do. I can generally make sense of it, but I don't have the skill to change the core logic of what these are doing.

I actually very much appreciate the concept of the notebook - it forces documentation into your work in a much more direct kind of way than traditional programming where comments and documentation are often an afterthought. Every example I've come across has had lots of helpful information (they are tutorials) and the text that is presented alongside the code is indispensable.

If you want to know more about machine learning, and you aren't afraid to see how the sausage gets made, it is worth checking it out. Highly educational.

Featured

Software Development Technical Debt Technology

Technical Debt as Metaphor, Where it Works and Where it Doesn't

Posted by Jonathan FriesJonathan Fries on .

I am across this article doing research for another post, I really enjoyed and think it is extremely valuable way to think about technical debt.

https://martinfowler.com/bliki/TechnicalDebtQuadrant.html

I'd go so far as to say, I'm going to expect developers I work with to read it and tell me which kind of technical debt they're talking about.

You should take the time to read the whole article. It's great. I'm not going to summarize it, only talk about a couple of things that I think are valuable and interesting.

Here's the quadrants for technical debt as Fowler defines them:

Technical Debt Quadrants

The first part of the article discusses the concept of technical debt and how it works as a metaphor to financial debt. Largely this distinguishes the concept of prudent from reckless debt, which is a useful distinction to have on hand for discussing projects with developers and clients.

In the financial realm you have prudent debts that you take on carefully, after doing your research, in order to further your goals. Buying a home, buying a car, purchasing rental property.

And then you have reckless debt that is taken on without proper research or out of alignment with your goals like buying a luxury items you can't afford.

There are two parts of this that I want to talk about in a bit more depth.

The first piece has to do with the concept of prudent, deliberate debt and where we begin taking it on in a project. I've had many conversations with developers over the years who may struggle to shift their mindset as you reach the end stages of a project.

Developers like to do things the right way - the scalable way, the smart way, the most effective way. I certainly did when I was a developer, and all the good developers I've known share this characteristic.

But there are times when you just need to finish off a feature or two and launch a product. Delays are dangerous in this situation. This is the moment to switch from avoiding all debt to taking on prudent, deliberate debt. It's time to say, "Yes, we could design it that way, but we need these features and we need to go to QA next week so please get it done."

Business realities drive us to these decisions, and most importantly, it is not wrong to do this. If you were a very savvy PM or product owner you might even put a date on the calendar when you think the decision making may change.

This doesn't negate the value of the all the design and hard work that went before it, nor does it mean you can't go back and revisit these items in the future. It just means, right now, in this phase of the project, we are making pragmatic decisions to ship and that is 100% OK and in line with best practices.

The second is the concept of prudent, inadvertent debt. Every project has it. No good developers are ever really satisfied as a result of it. But we can't ever truly get rid of it.

Why is that?

Just for clarification: prudent, inadvertent technical debt is the idea that some parts of system design will only really be apparent after the project is complete or once a particular phase is too far along to alter them.

This concept has no analog in the financial debt metaphor. There isn't a financial debt you can take on inadvertently and still be prudent. Being prudent implies that you don't have inadvertent financial debts.

But software is not finance - every software project has things that the development team would like to refactor toward the end.

If every project has this type of technical debt, why can't we eliminate it?

We can't eliminate it for two reasons:

  1. Technology changes too quickly. New tools come along and those tools have real business value so they can't be ignored. We bring them in to projects knowing we don't have every design ready for them. We do this because we push for ever greater scale, effectiveness, and feature delivery. We do it knowing it results in imperfect designs.
  2. Business Spaces are too diverse and changing too rapidly. Just when we think we understand an audience or a business, it changes. You can't be complacent, you can't rest thinking you know everything, you don't. Neither can you be paralyzed by such knowledge.

So, when you mix 1 and 2 together you get a situation where you can't design everything in advance. You look at the past, look at what you've done wrong and right, look at what you know about the tools you're using. And then you take the leap. You know you will taken on prudent, inadvertent debt by doing so.

The best bosses and clients understand this. It's why we like working for them and why work hard to eliminate everything else and build the great products we're capable of building.

Featured

Mindfulness Biometrics Technology

Spire Stone - A Wearable Device with Instant Feedback on Stress and Breathing

Posted by Jonathan FriesJonathan Fries on .

In my continued quest for biometric insights and stress management, I recently picked up a Spire Stone. It monitors respiration and it can give you real-time feedback on your breathing patterns. Very handy for identifying and managing stressful moments throughout the day.

Breathe less than 14 times in a minute? You are calm. Your breath is full and consistent. Feels pretty good, doesn't it?

Breathe more than 22 times in a minute? You are stressed. Your breathing has become quick and shallow.

If this happens, the Spire device gives you a small nudge in the form of vibration to let you know.

The great news? You can do something about it. Take deeper, more normal breaths and help your body relax and feel less stressed-out.

I like it because, like FitBit, it gives me a way to impact my health that I can make conscious choices about. Breathing? There's always time for that. And improved awareness leads to small changes that can have a big impact.

With the HRV, brain wave, and sleep devices I've tried, you just don't control those things as directly as breathing or steps.

Spire gives you control over your stress level. Changing your breathing helps you feel less anxious and it can help you BE less anxious by sending a calming signal to all the other systems in the body.

It is a really good device. I've noticed that I don't always agree 100% with its breath count. During meditation I think it over counts, slightly, depending on the position of the device.

I also have had a few false positives on the 'stress vibration'. But not more than 1 a day.

These are very minor flaws in my opinion, and the value it provides more than outweigh these (small) negatives.

The additional awareness it provides to your current breathing pattern is very helpful.

They also have an app with some nice features. They have helpful guided breathing exercises and stats on how much time you were calm, anxious, active, and focused.

Spire has a new product coming out called the Health Tag which is designed to be attached to clothes, more or less permanently (it can be washed). In addition to respiration it also monitors HRV.

Featured

Technology Education Kids

How Much Do You Teach Your Child About the Technology of Today?

Posted by Jonathan FriesJonathan Fries on .

I'm asking this question because I realize that if I teach my child about the technology of today - how it works, how to use it, how to build stuff with it - that a great deal of that information will be out of date when my child enters the workforce in 12 - 15 years.

This is going to happen for a bunch of reasons:

  1. I certainly hope that writing basic, redundant code will be done automatically. This might happen because tooling improves dramatically or because the languages that are used improve dramatically and remove the need for this kind of stuff.
  2. AI is going to replace a lot of jobs, even in technology.
  3. The jobs that will exist in the future don't exist and (mostly) haven't been dreamt up yet.

In such an environment, who can teach technology skills that matter? Not me certainly.

So, if we know that technology will continue to be important (it will) and we know that the details of that will change constantly and dramatically such that what you will need to do detail-wise at a job 15 years from now is hard to know, where do you go from there?

There are still skills that matter, you just have to emphasize them, even if you also do some detail-y technical work. Here's what I choose to emphasize:

  1. Think creatively.
  2. Do things with your creative thoughts - make stuff.
  3. Use technology and don't be afraid to get your hands dirty.

In the world of software, this last point is largely figurative. Your hands don't literally get dirty unless you've spilled a lot of coffee or toast crumbs into your keyboard over the years.

So, you have to teach them stuff. Teach them the big with the small.

The small stuff (details, technology) will expire. It always does. Sometimes faster, sometimes slower.

But while you're doing that you can learn to learn and not be afraid of it.

What 'it' will be in 15 years is anyone's guess.

Cover photo by @clever_visuals on Unsplash.