Jonathan's Blog

Jonathan's Blog

Mindful Leadership and Technology


Anxiously Awaiting My AWS Deep Racer

Posted on .

I ordered my AWS Deep Racer about 6 months ago, when it was supposed to be ready in March. At long last, I'm expecting to get it this week.

If you aren't familiar, Deepracer is Amazon's 1/18th scale robotic self-driving (toy) car. It uses reinforcement learning (a variation of machine learning) to teach the car about driving and help it to complete various courses.

Here is what the car hardware looks like:

The hardware was originally supposed to be out earlier this year, but has been somewhat delayed.

In the meantime I've been working with the simulation tool on AWS - AWS Deepracer. So far, I've managed to train a model to complete one of the easier tracks every time.

I'm pretty excited and looking forward to having the actual hardware. I'm probably not ready for the Deepracer League yet but I am having fun with it.

So far, the cost of running the AWS Robomaker simulation jobs (used for training and evaluating models) is not too expensive. I'll have to see what I spend over the coming weeks, it appears to be $10-$15/day for a few training and simulation runs a day, but that is based on a pretty small sample size.


Agile Agile Software Development

Forrester Wave Success

Posted on .

I was very pleased with Exadel's performance in a recent Forrester Wave™.

We participated in the Midsize Agile Software Development Service Providers, Q2 2019 Wave from Forrester. We were named a Leader in the report and given the highest score in the Current Offering category.

It was really great to work with all of our Agile experts here at Exadel. We worked hard to put together our response and talk about the exciting Agile software development work that we do for our clients and ourselves.

Exadel has been doing Agile development for a number of years and it was great to get to talk about our Agile capabilities. Our Scrum Masters really know their stuff, and it was cool to get recognition for this.

Here is a link to our Press Release, the Forrester Public Page, and our Exadel Site Page.


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.