Podcasts Technology Screaming in the Cloud Building a Strong Company Culture at Honeycomb with Mike Goldsmith

Building a Strong Company Culture at Honeycomb with Mike Goldsmith

Published: Nov. 9, 2023, 11 a.m.

b'

Mike Goldsmith, Staff Software Engineer at Honeycomb, joins Corey on Screaming in the Cloud to talk about Open Telemetry, company culture, and the pros and cons of Go vs. .NET. Corey and Mike discuss why OTel is such an important tool, while pointing out its double-edged sword of being fully open-source and community-driven. Opening up about Honeycomb\\u2019s company culture and how to find a work-life balance as a fully-remote employee, Mike points out how core-values and social interaction breathe life into a company like Honeycomb.

About Mike

Mike is an OpenSource focused software engineer that builds tools to help users create, shape and deliver system & application telemetry. Mike contributes to a number of OpenTelemetry initiatives including being a maintainer for Go Auto instrumentation agent, Go proto packages and an emeritus .NET SDK maintainer..

Links Referenced:


Transcript


Announcer: Hello, and welcome to Screaming in the Cloud with your host, Chief Cloud Economist at The Duckbill Group, Corey Quinn. This weekly show features conversations with people doing interesting work in the world of cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud.



Corey: Welcome to Screaming in the Cloud. I\\u2019m Corey Quinn. This promoted guest episode is brought to us by our friends at Honeycomb who I just love talking to. And we\\u2019ve gotten to talk to these folks a bunch of different times in a bunch of different ways. They\\u2019ve been a recurring sponsor of this show and my other media nonsense, they\\u2019ve been a reference customer for our consulting work at The Duckbill Group a couple of times now, and we just love working with them just because every time we do we learn something from it. I imagine today is going to be no exception. My guest is Mike Goldsmith, who\\u2019s a staff software engineer over at Honeycomb. Mike, welcome to the show.



Mike: Hello. Thank you for having me on the show today.



Corey: So, I have been familiar with Honeycomb for a long time. And I\\u2019m still trying to break myself out of the misapprehension that, oh, they\\u2019re a small, scrappy, 12-person company. You are very much not that anymore. So, we\\u2019ve gotten to a point now where I definitely have to ask the question: what part of the observability universe that Honeycomb encompasses do you focus on?



Mike: For myself, I\\u2019m very focused on the telemetry side, so the place where I work on the tools that customers deploy in their own infrastructure to collect all of that useful data and make\\u2014that we can then send on to Honeycomb to make use of and help identify where the problems are, where things are changing, how we can best serve that data.



Corey: You\\u2019ve been, I guess on some level, there\\u2019s\\u2014I\\u2019m trying to make this not sound like an accusation, but I don\\u2019t know if we can necessarily avoid that\\u2014you have been heavily involved in OpenTelemetry for a while, both professionally, as well as an open-source contributor in your free time because apparently you also don\\u2019t know how to walk away from work when the workday is done. So, let\\u2019s talk about that a little bit because I have a number of questions. Starting at the very beginning, for those who have not gone trekking through that particular part of the wilderness-slash-swamp, what is OpenTelemetry?



Mike: So, OpenTelemetry is a vendor-agnostic set of tools that allow anybody to collect data about their system and then send it to a target back-end to make use of that data. The data, the visualization tools, and the tools that make use of that data are a variety of different things, so whether it\\u2019s tracing data or metrics or logs, and then it\\u2019s trying to take value from that. The big thing what OpenTelemetry is aimed at doing is making the collection of the data and the transit of the data to wherever you want to send it a community-owned resource, so it\\u2019s not like you get vendor lock-in by going to using one competitor and then go to a different\\u2014you want to go and try a different tool and you\\u2019ve got to re-instrument or change your application heavily to make use of that. OpenTelemetry abstracts all that away, so all you need to know about is what you\\u2019re instrumented with, what [unintelligible 00:03:22] can make of that data, and then you can send it to one or multiple different tools to make use of that data. So, you can even compare some tools side-by-side if you wanted to.



Corey: So, given that it\\u2019s an open format, from the customer side of the world, this sounds awesome. Is it envisioned that this is something\\u2014an instrument that gets instrumented at the application itself or once I send it to another observability vendor, is it envisioned that okay, if I send this data to Honeycomb, I can then instrument what Honeycomb sees about that and then send that onward somewhere else, maybe my ancient rsyslog server, maybe a different observability vendor that has a different emphasis. Like, how is it envisioned unfolding within the ecosystem? Like, in other words, can I build a giant ring of these things that just keep building an infinitely expensive loop?



Mike: Yeah. So ideally, you would try and try to pick one or a few tools that will provide the most value that you can send to, and then it could answer all of the questions for you. So, at Honeycomb, we try to\\u2014we are primarily focused on tracing because we want to do application-level information to say, this user had this interaction, this is the context of what happened, these are the things that they clicked on, this is the information that flowed through your back-end system, this is the line-item order that was generated, the email content, all of those things all linked together so we know that person did this thing, it took this amount of time, and then over a longer period of time, from the analytics point of view, you can then say, \\u201cThese are the most popular things that people are doing. This is typically how long it takes.\\u201d And then we can highlight outliers to say, \\u201cOkay, this person is having an issue.\\u201d This individual person, we can identify them and say, \\u201cThis is an issue. This is what\\u2019s different about what they\\u2019re doing.\\u201d



So, that\\u2019s quite a unique tracing tool or opportunity there. So, that lets you really drive what\\u2019s happening rather than what has happened. So, logs and metrics are very backward-looking to say, \\u201cThis is the thing that this thing happened,\\u201d and tries to give you the context about it. Tracing tries to give you that extra layer of context to say that this thing happened and it had all of these things related to it, and why is it interesting?



Corey: It\\u2019s odd to me that vendors would be putting as much energy into OpenTelemetry\\u2014or OTel, as it seems to always be abbreviated as when I encounter it, so I\\u2019m using the term just so people, \\u201cOh, wait, that\\u2019s that thing I keep seeing. What is that?\\u201d Great\\u2014but it seems odd to me that vendors would be as embracing of that technology as they have been, just because historically, I remember whenever I had an application when I was using production in anger\\u2014which honestly, \\u2018anger\\u2019 is a great name for the production environment\\u2014whenever I was trying to instrument things, it was okay, you\\u2019d have to grab this APM tools library and instrument there, and then something else as well, and you wound up with an order of operations where which one wrapped the other. And sometimes that caused problems. And of course, changing vendors meant you had to go and redeploy your entire application with different instrumentation and hope nothing broke. There was a lock-in story that was great for the incumbents back when that was state of the art. But even some of those incumbents are now embracing OTel. Why?



Mike: I think it\\u2019s because it\\u2019s showing that there\\u2019s such a diverse group of tools there, and [unintelligible 00:06:32] being the one that you\\u2019ve selected a number of years ago and then they could hold on to that. The momentum slowed because they were able to move at a slower pace because they were the organizations that allowed us\\u2014they were the de facto tooling. And then once new companies and competitors came around and we\\u2019re open to trying to get a part of that market share, it\\u2019s given the opportunity to then really pick the tool that is right for the job, rather than just the best than what is perceived to be the best tool because they\\u2019re the largest one or the ones that most people are using. OpenTelemetry allows you to make an organization and a tool that\\u2019s providing those tools focus on being the best at it, rather than just the biggest one.



Corey: That is, I think, a more enlightened perspective than frankly, I expect a number of companies out there to have taken, just because it seems like lock-in seems to be the order of the day for an awful lot of companies. Like, \\u201cOkay, why are customers going to stay with us?\\u201d \\u201cBecause we make it hard to leave,\\u201d is\\u2026 I can understand the incentive, but that only works for so long if you\\u2019re not actively solving a problem that customers have. One of the challenges that I ran into, even with OTel, was back when I was last trying to instrument a distributed application\\u2014which was built entirely on Lambda\\u2014is the fact that I was doing this for an application that was built entirely on Lambda. And it felt like the right answer was to, oh, just use an OTel layer\\u2014a Lambda layer that wound up providing the functionality you cared about.



But every vendor seemed to have their own. Honeycomb had one, Lightstep had one, AWS had one, and now it\\u2019s oh, dear, this is just the next evolution of that specific agent problem. How did that play out? Is that still the way it works? Is there other good reasons for this? Or is this just people trying to slap a logo on things?



Mike: Yeah, so being a fully open-source project and a community-driven project is a double-edged sword in some ways. One it gives the opportunity for everybody to participate, everybody can move between tools a lot easier and you can try and find the best fit for you. The unfortunate part around open-source-driven projects like that means that it\\u2019s extremely configuration-heavy because it can do anything; it\\u2019s not opinionated, which means that if you want to have the opportunity to do everything, every possible use case is available to everyone all of the time. So, if you might have a very narrow use case, say, \\u201cI want to learn about this bit of information,\\u201d like, \\u201cI\\u2019m working with the [unintelligible 00:09:00] SDK. I want to talk about\\u2014I\\u2019ve got an [unintelligible 00:09:03] application and I want to collect data that\\u2019s running in a Lambda layer.\\u201d The OpenTelemetry SDK that has to serve all of the [other 00:09:10] JavaScript projects across all the different instrumentations, possibly talking about auto-instrumentation, possibly talking about lots of other tools that can be built into that project, it just leads to a very highly configurable but very complicated tool.



So, what the vendor specifics, what you\\u2019ve suggested there around like Honeycomb, or other organizations providing the layers, they\\u2019re trying to simplify the usage of the SDK to make some of those assumptions for you that you are going to be sending telemetry to Honeycomb, you are going to be talking about an API key that is going to be in a particular format, it is easier to pass that information into the SDK so it knows how to communicate rather than\\u2014as well as where it\\u2019s going to communicate that data to.



Corey: There\\u2019s a common story that I tend to find myself smacking into almost against my will, where I have found myself at the perfect intersection of a variety of different challenges, and for some reason, I have stumbled blindly and through no ill intent into \\u2018this is terrible\\u2019 territory. I wound to finally getting blocked and getting distracted by something else shiny on this project about two years ago because the problem I was getting into was, okay, I got to start sending traces to various places and that was awesome, but now I wanted to annotate each span with a user identity that could be derived from code, and the way that it interfaced with the various Lambda layers at that point in time was, ooh, that\\u2019s not going to be great. And I think there were a couple of GitHub issues opened on it as feature enhancements for a couple of layers. And then I, again, was still distracted by shiny things and never went back around to it. But I was left with the distinct impression that building something purely out of Lambda functions\\u2014and also probably popsicle sticks\\u2014is something of an edge case. Is there a particular software architecture or infrastructure architecture that OTel favors?



Mike: I don\\u2019t think it favors any in particular, but it definitely suffers because it\\u2019s, as I said earlier, it\\u2019s trying to do that avail\\u2014the single SDK is available to many different use cases, which has its own challenges because then it has to deal with so many different options. But I don\\u2019t think OpenTelemetry has a specific, like, use case in mind. It\\u2019s definitely focused on, like\\u2014sorry, telemetry tracing\\u2014tracing is focused on application telemetry. So, it\\u2019s focused on about your code that you build yourself and then deploy. There are other tools that can collect operational data, things like the OpenTelemetry Collector is then available to sit outside of that process and say, what\\u2019s going on in my system?



But yeah, I wouldn\\u2019t say that there\\u2019s a specific infrastructure that it\\u2019s aimed at doing. A lot of the cloud operators and tools are trying to make sure that that information is available and OpenTelemetry SDKs are available. But yeah, at the moment, it does require some knowledge around what\\u2019s best for your application if you\\u2019re not in complete control of all of the infrastructure that it\\u2019s running in.



Corey: It feels that with most things that are sort of pulled into the orbit of the CNCF\\u2014and OTel is no exception to this\\u2014that there\\u2019s an idea that oh, well, everything is going to therefore be running in containers, on top of Kubernetes. And that might be unfair, but it also, frankly, winds up following pretty accurately what a lot of applications I\\u2019m seeing in client environments have been doing. Don\\u2019t take it as a criticism. But it does seem like it is designed with an eye toward everything being microservices running on containers, scheduled which, from a infrastructure perspective, what appears to be willy-nilly abandoned, and how do you wind up gathering useful information out of that without drowning in data? That seems to be, from at least my brief experience with OTel, the direction it heads in. Is that directionally correct?



Mike: Yeah, I think so. I think OpenTelemetry has a quite strong relationship with CNCF and therefore Kubernetes. That is a use case that we see as a very common with customers that we engage with, both at the prospect level and then just initial conversations, people using something like Kubernetes to do the application orchestration is very, very common. It\\u2019s something that OpenTelemetry and Honeycomb are wanting to improve on as well. We want to get by a very good experience because it is so common when we come up to it that we want to have a very good, strong opinion around, well, if you\\u2019re running in Kubernetes, these are the tools and these are the right ways to use OpenTelemetry to get the best out of it.



Corey: I want to change gears a little bit. Something that\\u2019s interested me about Honeycomb for a while has been its culture. Your founders have been very public about their views on a variety of different things that are not just engineering-centric, but tangential to it, like, engineering management: how not to be terrible at it. And based on a huge number of conversations I\\u2019ve had with folks over there, I\\u2019m inclined to agree that the stories they tell in public do align with how things go internally. Or at least if they\\u2019re not, I would not expect you to admit it on the record, so either way, we\\u2019ll just take that as a given.



What I\\u2019m curious about is that you are many timezones away from their very nice office here in San Francisco. What\\u2019s it like working remote in a company that is not fully distributed? Which is funny, we talk about distributed applications as if they\\u2019re a given but distributed teams are still something we\\u2019re wrangling with.



Mike: Yeah, it\\u2019s something that I\\u2019ve dealt with for quite a while, for maybe seven or eight years is worked with a few different organizations that are not based in my timezone. There\\u2019s been a couple, primarily based in San Francisco area, so Pacific Time. An eight-hour time difference for the UK is challenging, it has its own challenges, but it also has a lot of benefits, too. So typically, I get to really have a lot of focus time on a morning. That means that I can start my day, look through whatever I think is appropriate for that morning, and not get interrupted very easily.



I get a lot of time to think and plan and I think that\\u2019s helped me at, like, the tech lead level because I can really focus on something and think it through without that level of interruption that I think some people do if you\\u2019re working in the same timezone or even in the same office as someone. That approachability is just not naturally there. But the other side of that is that I have a very limited amount of natural overlap with people I work with on a day-to-day basis, so it\\u2019s typically meetings from 2 till 5 p.m. most days to try and make sure that I build those social relationships, I\\u2019m talking to the right people, giving status updates, planning and that sort of thing. But it works for me. I really enjoy that balance of some ty\\u2014like, having a lot of focus time and having, like, then dedicated time to spend with people.



And I think that\\u2019s really important, as well is that a distributed team naturally means that you don\\u2019t get to spend a lot of time with people and a lot of, like, one-on-one time with people, so that\\u2019s something that I definitely focus on is doing a lot of social interaction as well. So, it\\u2019s not just I have a meeting, we\\u2019ve got to stand up, we\\u2019ve got 15 minutes, and then everyone goes and does their own thing. I like to make sure that we have time so we can talk, we can connect to each other, we know each other, things that would\\u2014[unintelligible 00:16:35] that allow a space for conversations to happen that would naturally happen if you were sat next to somebody at a desk, or like, the more traditional, like, water cooler conversations. You hear somebody having a conversation, you go talk to them, that naturally evolves.



Corey: That was where I ran into a lot of trouble with it myself. My first outing as a manager, I had\\u2014most of the people on my team were in the same room as I was, and then we had someone who was in Europe. And as much as we tried to include this person in all of our meetings, there was an intrinsic, \\u201cLet\\u2019s go get a cup of coffee,\\u201d or, \\u201cLet\\u2019s have a discussion and figure things out.\\u201d And sometimes it\'s four in the afternoon, we\\u2019re going to figure something out, and they have long since gone to bed or have a life, hopefully. And it was one of those areas where despite a conscious effort to avoid this problem, it was very clear that they did not have an equal voice in the team dynamic, in the team functioning, in the team culture, and in many cases, some of the decisions we ultimately reached as an outgrowth of those sidebar conversations. This led to something of an almost religious belief for me, for at least a while, was that either everyone\\u2019s distributed or no one is because otherwise you wind up with the unequal access problem. But it\\u2019s clearly worked for you folks. How have you gotten around that?



Mike: For Honeycomb, it was a conscious decision not long before the Covid pandemic that the team would be distributed first; the whole organization will be distributed first. So, a number of months before that happened, the intention was that anybody across the organization\\u2014which at the time, was only North America-based staff\\u2014would be able to do their job outside of the office. Because I think around the end of 2019 to the beginning of 2020, a lot of the staff were based in the San Francisco area and that was starting to grow, and want more staff to come into the business. And there were more opportunities for people outside of that area to join the business, so the business decided that if we\\u2019re going to do this, if we\\u2019re going to hire people outside of the local area, then we do want to make sure that, as you said, that everybody has an equal access, everyone has equal opportunity, they can participate, and everybody has the same opportunity to do those things. And that has definitely fed through pandemic, and then even when the office reopened and people can go back into the office. More than\\u2014I think there\\u2019s only\\u2026 maybe 25% of the company now is even in Pacific Time Zone. And then the office space itself is not very large considering the size of the company, so we couldn\\u2019t fit everybody into our office space if we wanted to.




Corey: Yeah, that\\u2019s one of the constant growing challenges, too, that I understand that a lot of companies do see value in the idea of getting everyone together in a room. I know that I, for example, I\\u2019m a lot more effective and productive when I\\u2019m around other people. But I\\u2019m really expensive to their productivity because I am Captain Interrupter, which, you know, we have to recognize our limitations as we encounter them. But that also means that the office expense exceeds the AWS bill past a certain point of scale, and that is not a small thing. Like, I try not to take too much of a public opinion on should we be migrating everyone back to return-to-office as a mandate, yes, no, et cetera.



I can see a bunch of different perspectives on this that are nuanced and I don\\u2019t think it lends itself to my usual reactionary take on the Twitters, as it were, but it\\u2019s a hard problem with no easy answer to it. Frankly, I also think it\\u2019s a big mistake to do full-remote only for junior employees, just because so much of learning how the workforce works is through observation. You don\\u2019t learn a lot about those unspoken dynamics in any other way than observing it directly.



Mike: Yes, I fully agree. I think the stage that Honeycomb was at when I joined and has continued to be is that I think a very junior person joining an organization that is fully distributed is more challenging. It has different challenges, but it has more challenges because it doesn\\u2019t have those\\u2026 you can\\u2019t just see something happening and know that that\\u2019s the norm or that that\\u2019s the expectation. You\\u2019ve got to push yourself into those in those different arenas, those different conversations, and it can be quite daunting when you\\u2019re new to an organization, especially if you are not experienced in that organization or experienced in the role that you\\u2019re currently occupying. Yeah, I think the distributed organizations is\\u2014fully distributed has its challenges and I think that\\u2019s something that we do at Honeycomb is that we intentionally do that twice a year, maybe three times a year, bring in the people that do work very closely, bringing them together so they have that opportunity to work together, build those social interactions like I mentioned earlier, and then do some work together as well.



And it builds a stronger trust relationship because of that, as well because you\\u2019re reinforcing the social side with the work side in a face-to-face context. And there\\u2019s just, there\\u2019s no direct replacement for face-to-face. If you worked for somebody and never met them for over a year, it\\u2019d be very difficult to then just be in a room together and have a normal conversation.



Corey: It takes a lot of effort because there\\u2019s so much to a company culture that is not meetings or agenda-driven or talking about the work. I mean, companies get this wrong with community all the time where they think that a community is either a terrible option of people we can sell things to or more correctly, a place where users of our product or service or offering or platform can gather together to solve common challenges and share knowledge with each other. But where they fall flat often is it also has to have a social element. Like ohh, having a conversation about your lives is not on topic for this community Slack team is, great, that strangles community before it can even form, in many cases. And work is no different.



Mike: Yeah, I fully agree. We see that with the Honeycomb Pollinators Slack channel. So, we use that as a primary way of community members to participate, talk to each other, share their experiences, and we can definitely see that there is a high level of social interaction alongside of that. They connect because they\\u2019ve got a shared interest or a shared tool or a shared problem that they\\u2019re trying to solve, but we do see, like, people, the same people, reconnecting or re-communicating with each other because they have built that social connection there as well.



And I think that\\u2019s something that as organizations\\u2014like, OpenTelemetry is a community is more welcoming to that. And then you can participate with something that then transcends different organizations that you may work for as well because you\\u2019re already part of this community. So, if that community then reaches to another organization, there\\u2019s an opportunity to go, to move between organizations and then maintain a level of connection.



Corey: That seems like one of the better approaches that people can have to this stuff. It\\u2019s just a\\u2014the hard part, of course, is how do you change culture? I think the easy way to do it\\u2014the only easy way to do it\\u2014is you have to build the culture from the beginning. Every time I see companies bringing in outsiders to change the corporate culture, I can\\u2019t help but feel that they\\u2019re setting giant piles of money on fire. Culture is one of those things that\\u2019s organic and just changing it by fiat doesn\\u2019t work. If I knew how to actually change culture, I would have a much more lucrative target for my consultancy than I do today. You think AWS bills are a big problem? Everyone has a problem with company cultures.



Mike: Yeah, I fully agree. I think that culture is something that you\\u2019re right is very organic, it naturally happens. I think the value when organizations go through, like, a retrospective, like, what is our culture? How would we define it? What are the core values of that and how do we articulate that to people that might be coming into the organization, that\\u2019s very valuable, too, because those core values are very useful to communicate to people.



So, one of the bigger core values that we\\u2019ve got at Honeycomb is that\\u2014we refer to as, \\u201cWe hire adults,\\u201d meaning that when somebody needs to do something, they just can go and do it. You don\\u2019t have to report to somebody, you don\\u2019t have to go and tell somebody, \\u201cI need a doctor appointment,\\u201d or, \\u201cI\\u2019ve got to go and pick up the kids from school,\\u201d or something like that. You\\u2019re trusted to do your job to the highest level, and if you need additional help, you can ask for it. If somebody requires something of you they ask for it. They do it in a humane way and they expect to be treated like a human and an adult all of the time.



Corey: On some level, I\\u2019ve always found, for better or worse, that people will largely respond to how you treat them and live up or down to the expectation placed upon them. You want a bunch of cogs who are going to have to raise their hand to go to the bathroom? Okay, you can staff that way if you want, but don\\u2019t be surprised when those teams don\\u2019t volunteer to come up with creative solutions to things either. You can micromanage people to death.



Mike: Yeah. Yeah, definitely. I\\u2019ve been in organizations, like, fresh out of college and had to go to work at a particular place and it was very time-managed. And I had inbound sales calls and things like that and it was very, like, you\\u2019ve spent more than three minutes on a wrap-up call from having a previous call, and if you don\\u2019t finish that call within three minutes, your manager will call your phone to say, \\u201cYou need to go on to the next call.\\u201d And it\\u2019s\\u2026 you could have had a really important call or you could have had a very long call. They didn\\u2019t care. They just wanted\\u2014you\\u2019ve had your time now move on to the next one and they didn\\u2019t care.



Corey: One last question I want to ask you about before we wind up calling this an episode, and it distills down to I guess, effectively, your history, for lack of a better term. You have done an awful lot of Go maintenance work\\u2014Go meaning the language, not the imperative command, to be clear\\u2014but you also historically were the .NET SDK maintainer for something or other. Do you find those languages to be similar or\\u2026 how did that come to be? I mean, to be clear, my programming languages of choice are twofold: both brute force and enthusiasm. Most people take a slightly different path.



Mike: Yeah, I worked with .NET for a very long time, so that was, like, the place\\u2014the first place that I joined as a real organization after finishing college was .NET and it just sort of stuck. I enjoyed the language. At the time, sort of, what 15 year\\u201412, 15 years ago, the language itself was moving pretty well, there was things being added to it, it was enjoyable to use.



Over the last maybe four or five years, I\\u2019ve had the opportunity to work a lot more in Go. And they are very different. So, Go is much more focused on simplicity and not hiding anything from anybody and just being very efficient at what you can see it does. .NET and many other languages such as Java, Ruby, JavaScript, Python, all have a level of magic to them, so if you\\u2019re not part of the ecosystem or if you don\\u2019t know particular really common packages that can do things for you, not knowing something about the ecosystem causes pain.



I think Go takes away some of that because if you don\\u2019t know those ecosystems or if you don\\u2019t know those tools, you can still solve the problem fairly quickly and fairly simply. Tools will help but they\\u2019re not required. .NET is probably on the boundary for me. It\\u2019s still very easy to use, I enjoy using it, but it just\\u2026 I found that it\\u2019s not that long ago, I would say that I\\u2019ve switched from thinking like a .NET developer, so whenever I\\u2019m forming code in my head, like, how I would solve a problem, for a very long time, it was in .NET and C#.



I\\u2019d probably say in the last 12 months or so, it\\u2019s definitely moved more to Go just because of the simplicity. And it\\u2019s also the tool that is most used within Honeycomb, especially, so if you\\u2019re talking about Go code, you\\u2019ve got a wider audience to bounce ideas off, to talk to, communicate, get ideas from. .NET is not a very well used language within Honeycomb and probably even, like\\u2026 even maybe West Coast-based organizations, it seems to be very high-level organizations that are willing to pay their money up for, like, Microsoft support. Like, Go is something that a lot of developers use because it\\u2019s very simple, very quick, can move quick.



Corey: I found that it was very easy for me to pick up Go to build out something ridiculous a few years back when I need to control my video camera through its \\u2018API\\u2019 to use the term charitably. And it just works in a way that made an awful lot of sense. But I still find myself reaching for Python or for\\u2014God help me\\u2014TypeScript if I\\u2019m doing some CDK work these days. And honestly, they all tend to achieve more or less the same outcome. It\\u2019s just different approaches to\\u2014well, to be unkind\\u2014dependency management in some cases, and also the ecosystem around it and what is done for you.



I don\\u2019t think there\\u2019s a bad language to learn. I don\\u2019t want this to be interpreted as language snobbery, but I haven\\u2019t touched anything in the Microsoft ecosystem for a long time in production, so .NET was just never on my radar. But it\\u2019s clear they have an absolutely massive community ecosystem built around it and that is no small thing. I\\u2019d say it rivals Java.



Mike: Yeah definitely. I think over the last ten years or so, the popularity of .NET as a language to be built from enterprise, especially at larger-scale organizations have taken it on, and then, like, six, seven years ago, they introduced the .NET Core Framework, which allowed it to run on non-Windows platforms, and that accelerated the language dramatically, so they have a consistent API that can be used on Windows, on Linux, Mac, and that makes a huge difference for creating a larger audience for people to interact with it. And then also, with Azure becoming much more popular, they can have all of these\\u2014this language that people are typically used to using Linux as an operating system that runs infrastructure, but not being forced to use Windows is probably quite a big thing for Azure as well.



Corey: I really want to thank you for taking the time to talk about what you\\u2019re up to over there. If people want to learn more, where\\u2019s the best place for them to go find you?



Mike: Typically, I use Twitter, so it\\u2019s Mike_Goldsmith. I create blogs on the Honeycomb blog website, which I\\u2019ve done a few different things; I\\u2019ve got a new one coming up soon to talk about different ways of collecting data. So yeah, those are the two main places. LinkedIn is usual as ever, but that\\u2019s a little bit more work-focused.



Corey: It does seem to be. And we\\u2019ll put links to all of that in the [show notes 00:31:11]. Thank you so much for being so generous with your time, and of course, thank you Honeycomb for sponsoring this episode of my ridiculous podcast.



Mike: Yeah, thank you very much for having me on.



Corey: Mike Goldsmith, staff software engineer at Honeycomb. I\\u2019m Cloud Economist Corey Quinn, and this is Screaming in the Cloud. If you\\u2019ve enjoyed this podcast, please leave a five-star review on your podcast platform of choice, whereas if you\\u2019ve hated this podcast, please leave a five-star review on your podcast platform of choice along with an insulting comment that we will then have instrumented across the board with a unified observability platform to keep our days eventful.


Corey: If your AWS bill keeps rising and your blood pressure is doing the same, then you need The Duckbill Group. We help companies fix their AWS bill by making it smaller and less horrifying. The Duckbill Group works for you, not AWS. We tailor recommendations to your business and we get to the point. Visit duckbillgroup.com to get started.

'