Jonathan's Blog

Jonathan's Blog

Mindful Leadership and Technology


Technology Top Level Domain TLD

Why does that .blog domain cost $7000?

Posted 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 - 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 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 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 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 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., 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): costs $7000 costs $9.99. costs only $700.

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


What to Do When the Code Sucks

Posted on .

I've written a few times about people saying 'this code sucks'. Most of the time the sucky code in question was written by somebody else - another employee or a different vendor.

On occasion it was written by the very person who is talking to me about it, usually 6 months or more in the past. That is always a fascinating conversation, but that is not what this blog is about. This blog is about the other situation - This Bad Code Was Written By Somebody Else And It Is Bad, Bad Code.

As a manager, I just believe now that every developer (yes, I'm talking about you team leads and architects) is always going to say that. Even people I trust.

Is that fair? Probably not.

Is it prejudicial? Yes.

Has anyone ever proven me wrong? Sometimes, but rarely.

Does it mean that the code is good? No, it doesn't.

But here's the thing. I've worked with tons of developers, some great, some good, some mediocre, but they're all pretty clever at some level. The cleverness manifests itself in all sorts of ways. Many of even the mediocre ones work hard and deliver working solutions to clients and bosses.

And of course clients and bosses appreciate things that work.

So if you think most code is junk you're probably seeing artifacts of something besides talent. What do you think it may be an artifcat of? Here's a great question: If we work with this client with this sloppy code base, what do we need to look out for?

Code can be a great artifact for thinking about that question.

Chances are, in the middle of the sloppy mess, as you call it, are some bits of brilliance or cleverness. Finding them will give you some indication of both the motivations of the original developer and of the business realities this code faces in the real world.

Telling me one good or interesting thing about the code would prove that you had read the code. Telling me two good or interesting things about the code would tell me that you probably have a good grasp on it.

Providing me, as a development manager, solid context for understanding that you have read and understand the code allows you to judge the code, and allows me as a manager more leeway to listen to you and understand your criticisms.

Here are my list of phrases and statments that cause me to judge people when I hear them without any further explanation:

*The code is fragile.
*This is spaghetti code.
*This was not designed properly.
*The code sucks.
*The code is over-engineered.
*The code is under-engineered.
*I make a change and it has unintended side effects.

The last one especially is a huge doozy to me. Unintended side effects? You're really just saying "I didn't read the code. And I don't understand it." In the worst case you're saying, "I don't know how to do my job very well."

When unjustified, all of those statements are smokescreens, avoidance, and hand waving. Even if you have a point, you aren't proving it.

How do you prove that you read the code? Well, pointing out a thing or two that is good can be helpful, but there are other ways, too.

Here are two that can be helpful if you're specific about it - Technical Debt and Code Smell.

If they're used generically they have the same problem (they're handing waving or avoidance or griping for the sake of griping), if they're used specifically they can be meaningful.

Before you start to talk about the 'bad code' you can use these types of statements to be much more specific.

Here are some things to read: - what in particular is the problem? - what's your proposal to make it better? - what type of debt do you think this software has? Why?


Ghost v2 Switch Over

Posted on .

I'm really enjoying using Ghost v2, which I switched over a while ago, in October 2018.

While I still spend a lot of time using markup and most of the blog posts are written in markup, I'm making some use of the other content types and editors, especially images and dividers.

The upgarde path to v2 was actually easier than v1 or some of the v0 upgrades that I did along the way.


Technology Management Management Conflict

Managing Professional Conflict in the Workplace

Posted on .

I was recently answering a couple questions about this for someone and I found I had a lot to say about it, so I'm going to try to encapsulate those thoughts in a blog post.

I've realized it's much more important to encourage people to solve their own problems. It's what most people want, anyway. Your job is to listen to them and to give them tools and encouragement they need. My first answer to 'Professional Conflict in the Workplace' - is that youneed to help people help themselves. It took me a long time to figure that out, but with help from a good mentor and from this book I've really tried to shift away from getting involved directly, as hard as that is sometimes.

To begin with, you need to understand what help you're being asked for. For any professional disagreements what's really being said is, "Please help me get better at working with this person." This can be true, even if they don't phrase it this way.

If someone is venting, you need to listen and ask why they're venting. Questions like - "What's really bothering you?" or "How do you think the situation could be resolved?" Can help them move away from their vent and focus on what they can actually do about it.

Once they begin to focus on problem solving for themselves, you can coach them through that - again questions are useful. "What else?" or "Do you want to rehearse what you will say?" are valuable here.

If they plan to talk to the person they're having a disagreement with, you should state your expectations for the interaction, “You’re going to speak to Ted this week? Let me know on Monday how it went.”, “Please listen to the other side of the argument and seek out a win/win.” Only get involved further if the sides seem unwilling or unable to reach a decision.

One other possible resolution strategy that I have used is to simply invite the other party to the meeting where the venting or other discussion is occurring. If someone is complaining or struggling with a workplace conflict, simply ask to bring the other party in. Then pick up the phone and say to the other party, "Can you come down here? I need your help resolving something."

Once both people are together I usually speak first and try to characterize the issue as I see it. Then the parties need to work together resolving a solution. This has the advantage of bringing both sides to the table and drawing forth quick resolutions.

You should be careful about when and how you employ this strategy and the different profession and emotional levels of the parties involved. It's effective if you feel the parties need supervision or if you simply want to make it clear that you want an answer now. It avoids all he said she said aspects. For manager-to-manager disputes or director-to-director level professional disagreements it can be an effective tool.

Most of the time, the two sides, when brought to the table in this fashion will see the expedience in working together to find the right solution.

There may be situations where you need to make the final decision. In that case, you make the decision.

In general I would still characterize this as a win/win to both sides if you can reasonably do so. But the 'loser' may not feel that way. Avoid overselling it. You can come across as dishonest if you don't realize that one of your employees just lost an argument.

Above all, you should make sure they know that you listened and that you appreciate their cooperation, you know they're a professional and will abide by the decision. Do your best to explain the business rationale of why you chose the way that you did. Avoid the urge to let them feel like they are owed one. In the future you need the latitude to continue to make the right business decision, based on who has made the best case.


Leadership Technology

Understanding the Thing that Didn't Happen

Posted 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?


AI Technology Leadership

AI Resources - TensorFlow

Posted 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.