062 - Highlights from our most popular episodes

With the arrival of a new year, we wanted to take the opportunity to look back. This episode brings together a collection of clips from five of our most popular guests: Scott Allen, Kelsey Hightower, Deborah Kurata, Troy Hunt and Filip Ekberg.

If you enjoy this episode, please consider leaving a review on Apple Podcasts or wherever you listen.

Please send any questions or comments to podcast@pluralsight.com.

[00:00:00.000]

Hello, and welcome to All Hands on Tech. I'm Daniel Blaser. As we look forward to a new year, we thought it actually might be a good opportunity to look back. This episode is a collection of clips from five of our most popular guests. This includes Scott Allen, Kelsey Hightower, Deborah Kurata, Troy Hunt, and Filip Ekberg. First up, is Scott Allen. Scott appeared on our very first episode in October of 2019, and little did we know that he would tragically pass away just a couple of months later. Judging by the messages that we still frequently come across, however, his unique perspective and teaching style is still impacting lives around the world. In this clip, he and Jeremy Morgan talk about the timeless skills that developers should look to prioritize. 

 

[00:00:51.013]

A lot of developers I think focus on skills that don't have a lot of staying power, and I think unfortunately that's just because our industry becomes very obsessed with these types of skills. It's how we recruit; it's how we express our capabilities to other organizations and individuals. When someone asks us, for example, for our resume, what do we say? We say, oh, I've been doing C# development for X amount of time, and I know Angular 1, and I know Angular 2, and I've worked with Microsoft SQL Server databases for this length of time. And I think all those skills are good, and obviously you have to know something about SQL Server and C# if you're going to work in a Microsoft shop where software is written using C# and the SQL database. But at the same time, I think developers then---because there's so much emphasis on building your resume and acquiring these types of skills, I think unfortunately some of the more timeless skills are undervalued in our industry. I think some of that's been changing recently, but some of the undervalued skills would be---some of them are very simple and obvious I think these days, like communication, so the ability to work with other individuals on a team. Timeless skills to me also would include something like empathy, so having empathy for other team members, having empathy, for example, if I'm a developer, having empathy for the ops team that has to put my software into production. Are there features that my software is missing or that I could add to my software that makes it easier for the ops team to operate the software and debug it and figure out what's wrong and deploy it? Also, skills like leadership and just good software design principles, UI design principles are kind of timeless. All of those skills are skills I think people should look for when they're learning a new technology or a new language. Because even though that language or technology's important in the short term to learn, if you're building a career over 5 or 10 or 15 or 20 or 25 or 30 years, it's those timeless skills that will pay off in the long run and transfer across these technologies that are going to be short lived, and even across career paths. So if you spend 15 years as a developer and after 15 decide you want to go into banking or real estate or just do something different with your life, skills like communication, the ability to write, the ability to empathize with other individuals, those things will carry you over into any profession. 

 

[00:03:40.397]

That's one of the things, when I was in college we took writing class after writing class, and I thought to myself, I'm going to be an engineer, I'm not going to need this stuff. And then of course in hindsight years later, I'm like, writing is probably the most important skill that I have and can work on and build. It's one of those hindsight things. And the people skills, I agree, like soft skills. One of things that I had kind of learned the hard way in management, being a lead software developer and a manager was trying to find the candidates with the most skills and the most bullet points like we talked about. Who's got all the bullet points? Let's bring that person in. And over time I learned that it was a little bit better to find the people who have the soft skills, the communication skills, empathy, are they nice, can we work with them? Those kind of things make all the difference to where, I had reached a point in my career where I would pick somebody with a lower set of skills as far as the technical side and then a higher set of skills as far as the soft skills side. Because I figure I can teach them technical skills and ramp that up a lot quicker than I can teach them not to offend everybody on the team when they speak. That's definitely a changing way of looking at things I think for beginning developers.

 

[00:05:03.572]

Right, I really wish there was a way in this industry to be able to evaluate people without looking at some of these very specific technical skills that we talk about. I mean, every time I see a job ad put out that says, required: 5 years of C# experience, I just sort of cringe. I say I wish there was a better way to express that somehow. I don't necessarily only want candidates that have worked in C#. If there's someone really bright that has been doing Python for 5 years, that actually might be the right candidate because they can pick up C# in a couple months and be just as productive as someone else I might hire.

 

[00:05:48.028]

What are some things that you wish you knew when you started out that you would've focused on, knowing what you know now?

 

[00:05:56.396]

Definitely I wish I would've known just how important communication was right from the start. So like you said, the ability to write and express your thoughts and organize thoughts is just so valuable in this day and age, the ability to communicate with other people in a written format or speaking to them and presenting to them. I wish I'd known that. And I also just wish I had realized at the start that this is a marathon and not necessarily a sprint, where you're trying to get as much done in a short amount of time as possible. Really you just want to keep moving forward and making small improvements in your career and in your life. You're going to be at this for years and years and years, and as long as you keep improving steadily over those years, you'll be somewhere.

 

[00:06:49.786]

Next up is Kelsey Hightower, who is a developer advocate at Google. In this conversation with Jeremy, Kelsey offers what we think is one of the best overviews of Kubernetes we've heard. He explains why an organization should consider using Kubernetes, why they shouldn't, and how it compares to other technologies.

 

[00:07:07.643]

It's a really long name to describe what we consider today a container management platform. So at the very highest level, if you come across the name Kubernetes---it's Greek for helmsmen, as someone who drives the ship. And the idea here is that when you have lots of applications, you can decide to package them into containers. So this is kind of an up level from the world of Docker. So ideally, as an application developer, you can now package your app in this universal format we call containers, or container images. And once you pair that up with thousands of machines, you need some way to orchestrate that. So how do you decide what applications run on which machines? And at a very high level, that's the problem that Kubernetes is trying to solve. 

 

[00:07:55.114]

Why would an organization want to use Kubernetes?

 

[00:07:58.032]

That is the million-dollar question that gets asked over and over again. So, if you're an organization, it depends on your size. If you're startup, you may decide that maybe you don't need Kubernetes on day one, and you can just use like a platform as a service. Think something like Heroku, where you just take your source code and let them run it for you. Maybe as your team kind of grows a bit more, or maybe your application stack gets a little bit more complex, meaning lots of microservices, 10 to 20 of different services, hundreds of machines, maybe even tens of machines, then at that point you kind of want a common language or a common tool to describe your deployment. So the ability to say, I need three copies of this application in this particular part of the world backed by a load balancer. So Kubernetes kind of gives you that ability to articulate what your deployment needs and then keep that running. Now, as you get a little bit bigger, let's say you're at a typical enterprise with thousands of employees, thousands of applications, and you've been around for a while. When you really peel back the covers to Kubernetes, it looks like all of those things you've been trying to build over time. If you have more than a handful of machines, then you've already dealt with the idea of autoscaling, a load balancing, failover. All of these things are the things you would build if you had enough time and the experience. Kubernetes kind of comes with a lot of that stuff baked in and a big contribution from the community of people with the same problems as you do.

 

[00:09:26.668]

What are some of the big obstacles for an organization in the beginning, when they're first adopting Kubernetes?

 

[00:09:32.369]

I think all new technology has a learning curve. If you were to start with Linux for the very first time, your biggest learning curve will probably be things like how do you even get it installed, which Linux distro to choose. And then once you've got it installed, how do you lock it down and secure it? How do you patch it? How do you update it? And then once you figure all of that out, how do you deploy your applications to it? If you just take that from the standard operating system world, those same problems apply to Kubernetes, and I think where it gets a little bit more complex. It's much newer than a single operating system running on a single machine. People know how to do that. There's lots of talent out there that can do that. But once you fast forward to distributed systems, now you have a whole new set of concepts to master, understand, and it may take you a little while longer. But to me it resembles the complexity that you find in any system. I can think back to my first days trying to edit a file with Vim. I couldn't exit for a long time, so I just shut down the computer. So I think most systems have an initial learning curve, and Kubernetes is no different.

 

[00:10:45.129]

Is there any time an organization wouldn't want to use Kubernetes?

 

[00:10:48.533]

Yeah, I think a lot of people run to Kubernetes to solve maybe problems that maybe Kubernetes is a good fit to _____, like all the things we mentioned earlier, this idea of having this tool that can manage multiple machines and keep things running and do basic failover. But if you think that you can ignore the basics, like the way you write your applications, they need to have things like health checks, metrics will be great, the ability to go down at any moment and then recover their own state. Kubernetes just can't do that for you automatically. It can meet you halfway and do some of the infrastructure basics, but when it comes to application design, you can't just rub Kubernetes on your applications and make their problems go away. It isn't that. There's another area where you have to be a bit careful. If you don't have a lot of experience with databases, most people don't. Most people create a database on a static set of servers and never touch it until there's a problem. If you try to move that into Kubernetes, you may not have the operational expertise to manage a database in such a dynamic environment.

 

[00:12:00.522]

And so are there some other challenges with the tenancy model of it? Because I know that when you're developing applications, some applications can run with the soft tenancy model, where it can just run in a container and it can run with other ones next to it, no big deal. But some of them do need to be isolated and do need a little more OS level-type architecture. And is that something that's a big challenge in Kubernetes right now?

 

[00:12:24.447]

Well, I would say Kubernetes lets you make the decision that you think is best for you. So if your applications really need to be one application per virtual machine or per physical machine, then Kubernetes will definitely let you do that. You can definitely say anti-affinity, or you can say only one app per machine, if that's really what you want to do. The drawback there is of course you're going to lose some benefits around density. It's a little easier in the cloud because you can create virtual machines a little closer to the memory and CPU requirements of your workloads. So you don't have to use Kubernetes in what most people think of in its default configuration, which is this idea of packing as many containers as possible in order to leverage as many resources as possible. And that bin packing does have the tradeoff of dealing with maybe less security, if you're just running with maybe something like Docker or container runtime. So it's kind of a tradeoff, but depending on which one you make, Kubernetes can help you enforce it.

 

[00:13:26.711]

It seems like there's two camps out there right now, as far as people opining on it. And they say that VMs are going to replace containers completely. And then of course there's others that are saying, no containers are going to replace them. And then there's the middle ground, which probably makes more sense, that they're both going to exist in this world, and since Kubernetes can manage both of them, it's well positioned for that. But which camp would you say that you're in, as far as the future goes?

 

[00:13:52.472]

Yeah, I mean, that argument is like saying nails will replace hammers. They're complimentary technologies. So if you have a bare metal machine, so that's a physical machine, and you have a kernel on there, one way to partition up that machine or to leverage all of its capabilities, you can use containers just like you use processes today. I can put 25 different processes on a machine, and they will all take the amount of CPU and RAM that they need. That's been a thing we've been able to do forever. So in this case, we're just going to leverage container images as a packaging technology. This is not a virtualization technology at all. This is just processes on steroids. So that's what containers are. Now, the decision to virtualize is independent of the decision to containerize. If you have a bare metal machine that you want to carve up into maybe smaller resource chunks or different security boundaries, you pick virtualization for that. I mean, I guess at some point you could back container technology packaging format and couple it with these lightweight virtual machines, you hear things like firecracker and so forth. But again, that's virtualization just being used to run a process. These are just two separate things.

 

[00:15:20.331]

How is Kubernetes different from something like Docker Swarm?

 

[00:15:24.357]

Yeah, so Kubernetes and Docker Swarm aim for the same things in many ways. You take a group of machines, and you expose an API that allows people to deploy containers to them. So at a very high level, they look very similar. When you start diving down into the API, that's where things start to differ pretty quickly. In a Docker Swarm world, you have this concept of a container and volumes and secrets, load balancers, and service discovery. But in the Kubernetes world, you have a concept of a Pod, and this would probably be the biggest difference most people would see on the surface. So a Pod is one or more containers deployed as a set. So the way to think about this is, let's say you have an app written in the Go programming language. So it's a little web server; it takes web requests. But let's say you don't want to add any authentication to it or anything fancy. You just want to take web requests. Well, with a Pod what you can do is, you can have a dedicated instance of let's say Nginx, Apache, any web server you like Envoy, if you will, and you can deploy those things together as a logical unit. And then the Pod becomes a place where you can actually attach a bunch of sidecars that do additional functionality. So think about logging. You may want to use a logging agent such as Splunk. So the combination of Apache, my application, and Splunk, those three things equal one logical app. And I can manage those Pods using something like a deployment and maybe stamp out five of those.

 

[00:17:02.138]

For our second annual Tech Skills Day, we worked with content creator Hank Green to host a multihour-long livestream with a handful of exciting guests. One of these was Pluralsight author Deborah Kurata, who spoke with Hank about all things Angular.

 

[00:17:17.786]

So you are known for your Angular expertise. Tell me what you like most about that framework.

 

[00:17:22.707]

Well, as I mentioned at the beginning, one of the things that I learned very early on was structured programming and good patterns. And it was really great to be able to pick up any piece of code and recognize that it had a similar way to look. The patterns that Angular has are also very consistent. So you pick up a piece of Angular code, and you know immediately where to start looking. So if somebody sends me their code or posts it on GitHub or whatever, any Angular developer can go up to that code and know where it starts, what is the first file you should go look at, what are the next files? because it has a very consistent pattern that it uses. I also really like the MVVM, model-view-viewmodel architecture that it follows for getting the templates, the visual part of the UI and the code part of the UI to work together. So you've got the template as the view, and then your codebehind is responsible for making that view work. It gives it the data, it handles its events, and I really like that architecture. It's clean and it can be very powerful. I also, lately, the last several years, been really into RxJS, which is Reactive extension. It's built into Angular, and you can use it just a little bit, or you can really dive into it. And recently I've been really diving into it and talking a lot about the power that it gives you. Because the web is so reactive, using Reactive extensions lets you be more reactive in the code as well, to react to what's going on in the UI, to reactively process data in multiple ways, to easily get data from multiple sources and merge them in a logical way for displaying in the view. And lastly, one of my favorite things is the Angular community. The Angular community is just an amazing bunch of people. They're kind, and they're welcoming, and they're easy to talk to. I really miss seeing them at the many Angular meetups and conferences that they have. They have zillions of conferences all over the globe. Last year I was in one in Malaysia and one and Copenhagen. And I mean, they literally are all over, of course, not this year. But hopefully sometime, maybe next year, we'll be able to get the community physically together again. But I really like Angular for all of those things. 

 

[00:20:32.171]

So React and Vue have come out fairly recently as kind of competitors to Angular. Do you think that Angular has an edge over them, and what do you think that is? And I'm not going to let you get away with saying the community, because we all know you love the community. 

 

[00:20:49.101]

Community. Community, community, community! I'm frequently asked this question, and one of the things I like to kind of compare it to is maybe like a restaurant. There are some people that like to go sit down and have a meal where it gives you everything, so it's got the right potato that goes, or rice or whatever, that goes with whatever your main protein is, and the vegetable, that complements it, and it all comes is one kind of unit. And there are other people that much prefer the buffet, where you go and you pick your own bits of salad that you want, and your own protein, and your own starch or whatever. It's kind of the same way with Angular and React. With Angular, when you use Angular, you are getting everything. You get the router, you get the forms package, you get the HTTP package. There is kind of a prescribed way to code with Angular. Products like React are much more pick and choose. So you can pick which router you want. You can pick which HTTP package you want to use, and so on. So it depends on your preference of whether you would like the kind of pick-and-choose kind of thing, or if you'd rather have, when you hire an Angular person, you know that they probably know the forms package, the HTTP package. When you hire a React developer, it's like, okay, well, we're using this HTTP technique. If you don't know the---so there's a lot more variables, I guess, in that equation. But in the end, they all meet the same goal. They all satisfy your hunger, or satisfy the ability to develop your client-side web application. So in terms of results, they'll all get you there. It's the same reason why some of us drive a Tesla, and others prefer an F-150. So it's just kind of a personal preference. 

 

[00:23:03.338]

Next up is a clip from my conversation with security legend Troy Hunt. Troy starts off by talking about the growth of his Have I Been Pwned project. We then discuss the importance of good security hygiene, how to do your own personal threat modeling, and more.

 

[00:23:20.080]

Well, it started out in 2013 as a bit of a curiosity. I thought, oh, this will be a bit of fun. A few of my friends will use this. It'll be a good way of finding if you're in predominantly the Adobe data breach, because I heard 150 million-something records. And then I grabbed a few other data breaches that were circulating around, I added them, and I went, that's it, job done. This will last for a little while. And now like 6 and a bit years on I'm going to break through 10 billion records pretty soon, which is kind of crazy. And I did not see any of this coming. This was not some grand master plan of mine. It was just literally doing stuff that seemed like a good idea at the time.

 

[00:23:57.794]

And I've noticed there's now kind of an integration with 1Password, correct?

 

Troy Hunt:

Well, there's a heap of integrations. So 1Password is one of them, which is great. because that's my favorite password manager. I was using them for years before I even started Have I Been Pwned. So, that's super cool. I can now go into my 1Password application, and I can see if any of my passwords have appeared in data breaches before, and I can also see if any of the accounts that I presently have, have had data breaches themselves, which is a really neat way of doing it, I reckon, because your password manager is sort of the place where you want to understand all this stuff.

 

[00:24:30.582]

It's cool. Whenever I see a data breach or anything that happens, people are talking about it on Reddit. I usually see people say, oh, well, just go to this website haveibeenpwned.com, enter it in. It's kind of become, I feel, like this thing that just exists. It's like the step one.

 

[00:24:50.997]

Yeah, it really is sort of the de facto standard now, which is kind of amazing because there are certainly other data breach services out there. But frankly, there's a bunch of pretty dodgy ones. There's a bunch that have been taken offline because they've been doing stuff like literally trading in identity data. Like, buy someone else's personal information. What could go wrong? But, yeah, Have I been Pwned has just stood the test of time and just keeps getting bigger and bigger.

 

[00:25:15.482]

Very cool. Do you think, on the topic of password managers and checking your email to see if it's part of a breach, do you think that the average person is more security minded than they were a few years ago? And why or why not?

 

[00:25:31.616]

I think they're more conscious of security simply because it is so pervasive in the mainstream media. So we see mainstream press probably every week talk about some sort of a data breach somewhere or other, some security incident. I reckon 2016 was actually a big watershed moment there because we had the elections, and the DNC hacking, and all this sort of thing, and it had just started to get into everyone's psyche. And then of course, just the nature of online life now. You get so many security notices, security advice, change your password, turn on your 2FA. You just can't live in any sort of connected world these days without security constantly jumping up into your face one way or another, in both good and bad ways.

 

[00:26:12.496]

People that are looking at this, let's say the average person, they see this Jeff Bezos phone hacking story and maybe they think, oh my gosh, if it can happen to him, it can happen to anyone. What should be our top security takeaway after we hear about that story?

 

[00:26:27.774]

I am surprised that such a smart guy in the tech industry, frankly, did something so stupid. And what I mean, I'm not even talking about any sort of questions about the infidelity and all that sort of thing, but I'm talking about digitizing and redistributing something that would obviously cause a huge amount of embarrassment and discomfort. Now I'm really cautious here as well because I've often said this before and because it's the internet, people get upset. And they say, oh, you can't say that he shouldn't take those photos because that's victim blaming. And like, whoa, whoa, hang on, hang on. Let's take a step back. All of us have control over our own security posture and the risks that we choose to take. And you almost need to do a bit of a threat modeling, a little bit of threat modeling around each of our online activities. Now my threat model in a case like that would be, if I was to digitize something such as the photos that he did, I would then be at a greater risk of them being redistributed than if I didn't have them. Now, I might say that that's an acceptable risk. And this is just like with the way we do threat modeling in application. I go, okay, so it's an acceptable risk, I'm going to have some mitigating controls, which are, I'm only going to send it off to my partner, and that's going to be it and then I might delete it off the phone, whatever it may be. So I would have a very conscious process of considering that. But maybe he did that because if the press is right, and it was actually the Saudis hacking into his phone, this is like state-sponsored actors now, who have a lot of resources at their disposal. But look, I would just fall back personally to the principle of you can't lose what you don't have. So I would avoid having something like that because for me personally, that's too great a risk.

 

[00:28:11.521]

Last, we have a portion of Jeremy Morgan's conversation with Microsoft MVP Filip Ekberg. They discuss the latest news in the worlds of C# and .NET.

 

[00:28:23.353]

There's been bunch of big changes, and there's a bunch of big changes coming along, as well. If we look at C# over the past, let's say 5 years, they announced that they were doing the compilers as an open source project. That means that rewrote all the C# and VB compilers in C# instead, which also means they compiled the new C# compiler with the old one, so that's a little mindboggling, but that's pretty cool. So that also meant that they have the capability of more easily adding more functionality or language features in the language. So what they've actually done is that they've added a few things that are really interesting. They've added a language first, what is called first-class citizen of tuples in the language. You've always been able to use tuples in the language, but now they're a first-class citizen and look really nice. The syntax is really good. And together with that, they've introduced pattern matching, which is something that's been available in F# and Kotlin, Swift, Pascal, and a lot of other functional programming languages. And it's one of those ways where you can write really beautiful code to match on particular traits of an object. So you can say that I have this object, but now I want to make sure that it matches these different criteria. And based on those different criteria, we can do different things. And that's something that they're gradually improving. So with C# 7, one of the 7 releases, they released a first version of the pattern matching, and then they improved that in C# 8, and then they're going to improve it a little bit more in C# 9, 10, 11, 12, and so forth. Yeah, so what's interesting with the language now is that it's, the cadence of the release cycles, they're releasing the new language features a lot quicker than they've previously done, mainly because it's not really coupled to Visual Studio. It is, but it's not really. They're doing the development open source on GitHub so they can just send you out a new compiler and you can just play around with the new features. But that also means that they kind of rely on the community and they rely on the Visual Studio teams to do the integration with the new compiler features and so forth. But what's interesting with C# 8 is that it requires .NET Core 3.0, so you have to jump onto the new runtime to be able to leverage some of the new features. And one of the things they've really not done in the past, or it's been a very long time since they required you to jump on a new version of the runtime to get new language features. But I think we're going to see more of that as well, and I think it's good. It makes sense because now you can have the .NET Core runtime side by side and you can have multiple different runtimes on the same machine, no problem. But that was a little bit trickier in the past.

 

[00:31:04.931]

Yeah, I think it's a weird transition period because if I understand it correctly, there isn't going to be a .NET Core or a .NET Standard anymore. They're kind of going to merge together and it'll just be .NET. So I think right now there's that struggle time, kind of like the Python 2 and 3 struggle that's been going on for years. 

 

[00:31:22.690]

Yeah.

 

[00:31:23.352]

People should just expect the struggle.

 

[00:31:27.171]

I have to be very careful how I phrase that, but I would say that they're no longer doing anything on .NET Framework, and .NET Core is now becoming .NET 5. They're just scrapping the Core out of it and just making it I guess feature compatible with Framework. I don't know how you would explain it, but you can't just upgrade the Framework version 2 to the .NET 5 version, from what I understand. But from now on, what you want to install on any machine when you do new development, you want to install .NET 5.

 

[00:31:58.453]

And that's kind of how I've understood it too. And I think pattern matching is probably one of my favorite new features. As you said earlier, stealing from F#, it wasn't very long ago that that's what F# was doing in applications that I was working with. I remember working on a very big project, and there was a lot of pattern matching, and it was moved off to an F# team of a few people who were doing that, and the rationale was basically F# for pattern matching, we don't want to deal with it, we don't want to try to replicate what they're doing in C#. So hearing that it's come in and being implemented is pretty cool, and I imagine they stole a lot of patterns from F# for that.

 

[00:32:42.591]

They certainly did. And there's still things that they want to improve and can improve upon, but it's still one of those things that people have really been missing out from F#, and I think it makes the code a lot more beautiful. It certainly makes it less chatty, and that's what most of us want. We want to write less code, but as well as expressing ourselves the same way we did before. And I think that's one of the reasons DB developers might be moving onto C# instead, because they want to be less verbose in their code.

 

[00:33:18.217]

Thank you for listening to All Hands on Tech. In the show notes, we've included links to the five episodes that we sampled in today's podcast. Thanks again, and have a great week.