Follow Mark on LinkedIn Follow @marknca on Twitter Follow marknca on YouTube
marknca

Mornings With Mark
no. // 0 0 0 9

On The Importance Of Names

Subscribe to the podcast.

Watch the episode here

Join the discussion on LinkedIn

Tweet about this episode

Full machine generated transcript follows

Morning everybody. How you doing today? I wanted to talk to you about the importance of names. And the reason why this is top-of-mind is because in all my years of watching on the NBA the National Basketball Association, I've never seen anything like what happened on Friday and what happened was there was a three-team trade that fell apart because of a name.

So the three teams were trying to organize a trade where you know, they extend an asset the long and I guess to the teams never spoke directly. They spoke to the intermediary and the difference was that there was a miscommunication in the players named there's two players have the same last name Brooks on the team and one team thought they were getting MarShon Brooks where the other team thought.

They were trading Dillon Brooks and the whole thing fell apart because of a name and while that's amazing and hilarious and kind of sad all the same time. It does bring up an issue that we Face commonly within technology, especially with insecure. 3M privacy in the importance of a name now we use acronyms all the time way way way too often and we love throwing acronyms in front of things because it's hard on horde time consuming to stay the full name for things and that's fine.

Generally that we do have a lot of acronym names face conflict. Where were referring to one thing and people referring to another time or just the assumption that if I spent an acronym you'll actually understand that's a problem. So there's a depth of communication problem there as well. But one of the things where it hits me nonstop or two of the areas that I'll call out here that I will have our pieces that I'm writing right now is around serverless and around and devops.

So serverless. Yes. We were long past the whole service has service thing. We know that that's fine. What we're having a challenge now is people referring to serverless. So let me back up the original connotation around serverless was an architecture pattern. That used managed Services Social Services where you basically just put something in got something that you have to manage the weeds below.

So no containers. No operating systems just a database access just compute function running and things like that. So this is an architectural concept of building a serverless application, but people now that are coming into Community more and more using serverless within the context of functions as a service AWS Lambda Azure functions Google functions, they call that serve entirety of the concept and that's the problem is people referring to this specially with security to talk about serverless security, but they're only talking about functions as a service in the security around that they're not talking about the architectural pattern.

That's a problem not to challenge. There's no easy answer to that one. But that's that's a difficulty in name. Is that the name means one thing a good one for me to eat needs another to a community that's coming out. That's also trying to push that definition on everybody else.

That's mainly Turn by Marketing in startups in the space. I'm in people who are late to the game and not taking the time to research to Ashland Community challenge their I can't argue enough against the same even though it's a descriptive name. It runs counter to the principles of devops in the first place that runs counter to the whole point the idea of devops again as a cultural thing.

It's not a position. It's not a tool. It's a cultural change and that looks at breaking down barriers between First Development and operations, but in general breaking down barriers and delivering it services in another way and saying that we need a whole new acronym shoved in there. It's kind of ridiculous and it actually repeat a lot of what security is done wrong in the past.

So important and names of A continuing theme we see often is that a name will have one meeting within the community to start with their overtime. It will expand and that's great it just that it loses clarity as it expands because the original Community thinks of one thing. Add a new committee thinks of another noun the case of surrealist actually narrowing the definition of which is bad.

It's it's losing scope. Where's before? It referred to an entire area, which was exciting a lot of things going on in that area. Now. It's being referred to only a part of that area, which is is a challenge and I'm I'm not sure how the community to sort that out and when it comes to devops they're trying to expand the definition when really it needs to stay where is nowhere near the epic level of hell of an NBA trade falling through because you didn't bother to reference the first name of a player but none the less names are important and critical but they should also change over time.

It's a really interesting Challenge on within a community in those communities aren't even Define. What's your latest naming problem naming Challenge? And how do you handle it? When you think of a service we think about devops average steps a cop's what you think about that crazy. I make a trade that never happened.

Let me know online at Mark and ca for the zoo in the Vlogs the comments Down Below on the podcast to meet at Mark end. CA is always Quickly reaching episode 159 watch the hit that later this weekend when we do I'm going to shut things down for the year going to take a bit of a Christmas holiday and then we'll be back in the new year with a refreshed visual with refresh approach to the show.

I'm so I'm looking for feedback there. So again online Mark and see a Blog comments down below and is always email me. What do you think about what would you like to see from the show in 2019? I hope your setup for a wonderful. Fantastic day. Look forward to speaking to you online.

It's even on the show tomorrow. Morning everybody. How you doing today? I wanted to talk to you about the importance of names. And the reason why this is top-of-mind is because in all my years of watching on the NBA the National Basketball Association, I've never seen anything like what happened on Friday and what happened was there was a three-team trade that fell apart because of a name.

So the three teams were trying to organize a trade where you know, they extend an asset the long and I guess to the teams never spoke directly. They spoke to the intermediary and the difference was that there was a miscommunication in the players named there's two players have the same last name Brooks on the team and one team thought they were getting MarShon Brooks where the other team thought.

They were trading Dillon Brooks and the whole thing fell apart because of a name and while that's amazing and hilarious and kind of sad all the same time. It does bring up an issue that we Face commonly within technology, especially with insecure. 3M privacy in the importance of a name now we use acronyms all the time way way way too often and we love throwing acronyms in front of things because it's hard on horde time consuming to stay the full name for things and that's fine.

Generally that we do have a lot of acronym names face conflict. Where were referring to one thing and people referring to another time or just the assumption that if I spent an acronym you'll actually understand that's a problem. So there's a depth of communication problem there as well. But one of the things where it hits me nonstop or two of the areas that I'll call out here that I will have our pieces that I'm writing right now is around serverless and around and devops.

So serverless. Yes. We were long past the whole service has service thing. We know that that's fine. What we're having a challenge now is people referring to serverless. So let me back up the original connotation around serverless was an architecture pattern. That used managed Services Social Services where you basically just put something in got something that you have to manage the weeds below.

So no containers. No operating systems just a database access just compute function running and things like that. So this is an architectural concept of building a serverless application, but people now that are coming into Community more and more using serverless within the context of functions as a service AWS Lambda Azure functions Google functions, they call that serve entirety of the concept and that's the problem is people referring to this specially with security to talk about serverless security, but they're only talking about functions as a service in the security around that they're not talking about the architectural pattern.

That's a problem not to challenge. There's no easy answer to that one. But that's that's a difficulty in name. Is that the name means one thing a good one for me to eat needs another to a community that's coming out. That's also trying to push that definition on everybody else.

That's mainly Turn by Marketing in startups in the space. I'm in people who are late to the game and not taking the time to research to Ashland Community challenge their I can't argue enough against the same even though it's a descriptive name. It runs counter to the principles of devops in the first place that runs counter to the whole point the idea of devops again as a cultural thing.

It's not a position. It's not a tool. It's a cultural change and that looks at breaking down barriers between First Development and operations, but in general breaking down barriers and delivering it services in another way and saying that we need a whole new acronym shoved in there. It's kind of ridiculous and it actually repeat a lot of what security is done wrong in the past.

So important and names of A continuing theme we see often is that a name will have one meeting within the community to start with their overtime. It will expand and that's great it just that it loses clarity as it expands because the original Community thinks of one thing. Add a new committee thinks of another noun the case of surrealist actually narrowing the definition of which is bad.

It's it's losing scope. Where's before? It referred to an entire area, which was exciting a lot of things going on in that area. Now. It's being referred to only a part of that area, which is is a challenge and I'm I'm not sure how the community to sort that out and when it comes to devops they're trying to expand the definition when really it needs to stay where is nowhere near the epic level of hell of an NBA trade falling through because you didn't bother to reference the first name of a player but none the less names are important and critical but they should also change over time.

It's a really interesting Challenge on within a community in those communities aren't even Define. What's your latest naming problem naming Challenge? And how do you handle it? When you think of a service we think about devops average steps a cop's what you think about that crazy. I make a trade that never happened.

Let me know online at Mark and ca for the zoo in the Vlogs the comments Down Below on the podcast to meet at Mark end. CA is always Quickly reaching episode 159 watch the hit that later this weekend when we do I'm going to shut things down for the year going to take a bit of a Christmas holiday and then we'll be back in the new year with a refreshed visual with refresh approach to the show.

I'm so I'm looking for feedback there. So again online Mark and see a Blog comments down below and is always email me. What do you think about what would you like to see from the show in 2019? I hope your setup for a wonderful. Fantastic day. Look forward to speaking to you online.

It's even on the show tomorrow.