We're sunsetting PodQuest on 2025-07-28. Thank you for your support!
Export Podcast Subscriptions
cover of episode 215: Staying Technical as a Manager

215: Staying Technical as a Manager

2024/2/25
logo of podcast Test & Code

Test & Code

AI Deep Dive AI Insights AI Chapters Transcript
People
M
Matt McKay
Topics
Matt McKay: 我从一名软件工程师转型为开发关系副总裁,我的职业生涯始于Java开发,后来转向Python,并积累了丰富的管理经验。在管理团队的同时,我仍然保持着编码的习惯,并通过参与开源项目、公开演讲和写作等活动来提升我的技术能力和沟通能力。我认为在裁员时期,拥有多种技能(不仅仅是编码)并对公司有巨大价值比单纯的编码技能更重要,这能提高工作保障。保持技术更新的关键在于业余时间进行编码练习,专注于解决通用问题而非公司特定问题。我利用业余时间进行个人项目开发,例如Full Stack Python和PlushCap,来保持技术技能并学习新技术。个人项目不应仅仅是工作内容的延伸,而应该专注于解决抽象问题。通过在公共平台上解决问题并撰写博文,可以获得他人的反馈,并与其他开发者建立联系。在公开分享项目时保持谦逊,并欢迎反馈,能获得更有价值的反馈。参与开源项目、公开演讲和写作等活动,提升了我的沟通能力和公众演讲能力,并促进了我在开发关系方面的职业发展。成为一名优秀的管理者需要持续的学习和努力,并根据自身情况和团队特点调整管理风格。优秀的管理者会认可团队成员的成就,并以此激励团队成员,从而营造积极的工作氛围。我的个人项目通常使用与日常工作相同的工具和技术,以便保持技能的熟练度。对于小型公司或个人开发者而言,专注于一种开发者关系策略(例如博客、视频等)比分散精力更有效。目前我将更多时间投入到学习和实践大型语言模型,未来可能会更多地分享关于开发者体验方面的经验。要保持技术能力,管理者可以尝试以下方法:进行个人项目开发(解决通用问题)、撰写技术博客、提升沟通能力和管理能力。保持技术能力的关键在于每天都完成一些小的技术任务,并建立高效的部署流程,减少障碍。

Deep Dive

Key Insights

What is Matt Makai's current role and background?

Matt Makai is the VP of Developer Relations and Developer Experience at Assembly AI. He previously spent over nine years at Twilio in developer relations and has a background as a software developer, starting with Java and later transitioning to Python.

Why did Matt Makai transition from Java to Python?

Matt transitioned from Java to Python because he found Python more productive and explicit compared to Java, which he felt was slow-moving at the time. He also tried Ruby but found Python's explicitness more aligned with his thinking.

What challenges do technical managers face in staying technical?

Technical managers face the challenge of balancing leadership responsibilities with maintaining and updating their technical skills. There is a fear of being outpaced technically by newer developers, which could make them less valuable during layoffs or when seeking new roles.

How does Matt Makai stay technical as a manager?

Matt stays technical by working on side projects that solve generic versions of problems he faces at work. He uses these projects to keep up with new technologies and tools, ensuring he remains fluent in coding and technical trends.

What is Plush Cap, and how does it help Matt stay technical?

Plush Cap is Matt's side project that tracks how developer-focused companies invest in their documentation, blog posts, and YouTube channels. It allows him to analyze trends and experiment with new tactics, keeping him engaged with both coding and industry developments.

What advice does Matt give for staying relevant in the tech industry?

Matt advises combining multiple skill sets, such as coding, writing, public speaking, and teaching, to become more valuable to a business. He emphasizes that being irreplaceable comes from having a unique combination of skills that are hard to replace.

What is the importance of having a quick deployment pipeline for side projects?

A quick deployment pipeline allows for immediate feedback and iteration on side projects. Matt uses this approach with Plush Cap, enabling him to deploy changes daily and stay engaged with coding and problem-solving.

How does Matt use large language models (LLMs) in his work?

Matt uses LLMs, such as the Dolphin version of a 7 billion parameter model, to summarize blog posts for Plush Cap. This allows him to process large amounts of content efficiently and stay informed about industry trends.

What is Matt's opinion on using LLMs for creating technical content?

Matt believes LLMs are good for brainstorming and summarization but are not yet capable of producing highly accurate or creative technical content. He emphasizes the importance of human-driven quality in developer-focused content.

What is the key to building a strong developer relations strategy?

Matt suggests focusing on one standout area, such as exceptional documentation, YouTube content, or developer events, to differentiate a company. He highlights examples like Twilio's developer events and Assembly AI's YouTube channel as successful strategies.

Chapters
The conversation begins with Matt Makai's introduction and background, transitioning to the central theme: maintaining technical skills while in a management role. He emphasizes the importance of staying relevant in the face of industry layoffs and how side projects contribute to this.
  • Maintaining technical skills as a manager is crucial for job security.
  • Side projects focused on generic problem-solving are beneficial.
  • Combining multiple skill sets increases value to the business.

Shownotes Transcript

Translations:
中文

Well, welcome to Python Test. Matt McKay is here. I met Matt many years ago. But you're up to new things now. So Matt, can you introduce yourself and let us know what you're up to?

Yeah, sure. My name is Matt McKay. I am the VP of developer relations and developer experience at Assembly AI. Before that, I was nine plus years at Twilio, where I was also in developer relations. And then my entire career before either Assembly AI or Twilio was as a heads down software developer. So I started out in Java, Java world, J2E, a lot of

big iron software projects that were closely associated with usually mainframe transition type stuff. And then I got into Python and I was like, oh my gosh, I can hack on stuff in Python for an hour at night and I feel more productive than nine hours a day in Java, at least at the time the Java ecosystem was kind of slow moving. So yeah, so that's my background. Also run full stack Python and a new side project that I can talk about as well.

Well, I'm glad that you tried Python because it really could have been any language that you tried after Java. Yeah.

Yeah. And I did try Ruby. Ruby on Rails was super hot back then. This was before the days of Node.js. It just didn't quite click with me. I thought Ruby is more implicit, Python is more explicit, and that kind of clicked with me for some reason. So you've got to kind of pick the programming language that matches your brain. Yeah. Yeah. Early on, Perl matched my brain. I'm glad that Perl doesn't match my brain anymore. Wow.

That's incredible. That one also did not stick for me. So I'm impressed. I do want to talk about your new side project, and maybe this will shoo in. But staying technical as a manager, and this is actually, this is very close to me because I'm a technical manager. But Matt, are you in a management or leadership role now?

Yeah, absolutely. So currently I have a team of seven, which actually I just handed off a few folks. So while I was at, when I joined Assembly AI about a year ago, I was running marketing, but we really were going for a very developer focused DevRel bent and then specifically

sprinkled in a little like demand gen and content marketing. So I was recently managing a team of 11, but before that at Twilio, I had a team of 35. So I had managers that I was managing for the individual teams. So I've been managing either in, you know, sort of the player coach model, which I typically think of as, you know, if you're managing teams,

At most, like three to four people versus a sort of a pure manager where you spend the majority of your time managing, which is like often eight to 12.

people. So I've been manager since, I don't know, probably 10, 11, maybe 12 years now. Yeah. And it's similar situation to you. Many of those times where, you know, I'm both coding and doing a lot of code reviews and things like that, as well as managing as well, which is a

a tough balance. I've been in management for probably about the same time you have, really. It is always a fear. And one of the reasons why I'm interested in this topic is to, even if I were to leave a lot of the technical stuff to other people, that at some point there's going to be a shrinkage and they don't need as many managers. And now I'm not one of the top coders anymore. So

Yeah, that's one of the fears of being, especially a lower level manager, is that you're going to let everybody else pass you technically. And then you're not one of the obvious people to keep around when layoffs come. So that's that's and then also trying to find another job. So it's difficult finding a job because people.

There's a lot of times where people are like, oh, well, you're a manager. We don't have any manager roles. I'm okay with being an engineer too. Well, yeah, but you're not right now. So things like that. So how do you stay technical as a manager, Matt? Sure. Well, let's just take a little bit of a step back, which is just like, obviously, this is an incredibly pertinent topic as we've had just this high

hundreds of thousands of layoffs across the software ecosystem over the past 18 to 24 months. And there probably will be more the first half of this year. I would say that most people I've talked to have said that this is much more like a 2001 kind of dot-com crash situation for layoffs as opposed to even great financial crisis wasn't necessarily even as bad as it is right now. So that's kind of saying, I think in a lot of cases, you really can't

prevent getting laid off. A lot of times it's really just like a numbers game. And so I think a lot of times people take it really personally. I do think there's things that you can try to do to stack things in your favor a little bit. And so this goes to like your point of like, you know, you, you,

If you think that you're going to lose out in coding to someone who's newer, I actually think what matters a lot more, and I say this as someone who's gone through layoffs myself, is somebody just wildly valuable to the business. And obviously, coding is one of many skill sets. And typically, if you combine multiple skill sets...

This is what developer relations is a lot about. It's like you are not only coding applications, but you're also writing technical tutorials or you're creating YouTube videos or you're giving a talk at PyCon. It's the combination of those skills that are rare. And so if a company really needs that for its business and knows that it's going to be extremely difficult to replace you, that gives you a little bit more job security. But again, sometimes they just decide to cut teams arbitrarily. So

Um, I do think that like coding, I would look at coding as like one of many skills that you can, uh, you know, kind of try to stack the deck in your favor, but, uh, you know, it's been a tough time in the industry. Like, I don't think anybody should ever take it personally that they got like laid off. Like I got laid off from Twilio, uh, actually turned out to be awesome for me, but I'm very fortunate that I just happened to be in, you know, a little bit of the right place at the right time. Um, when it happened, um, and I was, I was ready for it, but it's, you know, um,

Anyway, so I think coding is one of these things. So like going back to your original question of like, you know, how do I stay up to date with coding?

The big thing for me is I work on in my spare time, and I have a family and everything. I don't have a ton of spare time. I tend to do a little bit of this in the mornings before my son wakes up. But I work on generic versions of a problem that I face. And so what that allows me to do is think about things in a way that are separate from the particular details that I face at the company. So let me give you two examples because both of my...

side projects have essentially been in this model. So I worked on full stack Python for about 10 years, taking a bit of a break from it. I will go back to it eventually, but it was like, I wanted to make sure that I really understood the full scope of the Python ecosystem as a developer, when I was a developer evangelist at Twilio and still a software developer. And so I would just write, you know, pages and find the best articles on a new web platform.

framework that was coming out or a new database that had come out. The time between 2007 and 2000, even up until recently, the explosion in the number of technologies around web development in the Python ecosystem was like, it was really hard to keep up. And so I just used my side project as a forcing function that I would keep up with all of that stuff.

And the coding part of it was like, you know, Jinja templates and I was using Pelican to create a static site. And I would like, you know, it wasn't super coding heavy, but it was enough to like keep me, you know, really familiar with my tools. And I think that's one component to it is like, if you want to still be able to code, even as you go into management, like, yeah, you're going to have to spend some time on the side, just like most software developers do.

in order to like make that possible. If you work on something that is going to make you better at your job, but is like separate from your job so you can think about things in a little bit different way and doesn't,

You don't want to just be working on work as your side project. You want to be working on, I think, like an abstract problem. That's kind of how I tend to approach it. And there's a bunch of like tactical stuff we can talk about as well. But that's like my conceptual framework. And I have a new side project called Plush Cap. It's plushcap.com. It allows me to see the landscape of every developer-focused company that's out there.

and how they're investing in their docs, how they're writing blog posts, how their YouTube channel is doing. So I can see every single company and how they're doing from publicly traded company all the way down to a pre-seed company. And then I can say, oh, that tactic is working really well. Maybe we should experiment with that on my team. So you can kind of, you can self sort of learn from others. And I do that through the tool that I created.

We may need to have you back on and just talk about plush cap at some point. Cause that sounds fascinating. And I don't,

I think I've got like 20 questions around it. So one of the ways places where I looked at, uh, trying to stay technical and I, and I've heard this before is to have it be something completely different than your, your normal day job. Uh, like, uh, trying to, I don't know, um, do a forum for one of your hobbies or something like that. Um,

But I love this idea of generic versions of a problem that you're working on your company. It's a, it's something that when I was, when I started writing about testing, the, the,

I was definitely thinking of problems I had at work and trying to solve them, but I wanted to do it in the open, and I couldn't do that. I can't write the problem down that I'm facing at work because it's an intellectual property. I can't share that. But also, it would be boring for everybody. It's usually super deep detail into something that only we care about.

or a few other people do, but that's not the part. That's not the point of the problem. The problem is some sort of a software architecture problem that has nothing to do with the domain. It's like, like for instance, the on with the, with testing the, the early on, I had a need to have multiple checks. So I wrote a plugin called PyTest check that I still maintain. That is a,

Normally in all tests, you can only assert once. If it fails, it stops. And it needed to have more. We needed that in work for waveforms because we've got both a bandwidth and frequency and other things you need to check. And I don't want to stop checking if one of them fails. I want to see the whole picture.

But I knew that that was going to be generic enough for other people. So trying to solve that in public. Also, I didn't know how to solve it. So solving it in public and writing blog posts and everything helped have other people come on to correct me and say, oh, have you thought about doing this? And that's how I started getting in touch with some of the core contributors that I test.

because they were some of the best people to say, oh, yeah, this doesn't work because of this. And you should look at this internal variable and that'll help. So when you're writing full stack, did you have a lot of feedback from people? Would people contact you and say, and you're in left field, man, you're wrong about this. Or did you get very many corrections?

Yeah, I mean, quite a bit. I mean, I think the thing that helps there is like, and I think basically this is, it seems like matches your experience as well, is like, if you just sort of approach things in a way that like, hey, I'm doing this and I'm also learning at the same time, like I'm not the definitive, you

I have enough experience to be able to write in a neutral, but still entertaining way about the topic, informed enough, but also with the humility that, hey, I actually don't know everything and I very much welcome feedback. I think that is often what helps to differentiate projects where people will give you valuable feedback versus just being kind of a jerk.

Um, you know, cause if you say, if you're kind of putting yourself out there as like, I know everything already, like then I think you just open yourself up a little bit more to like people that are like, you know, disagree with you. Um, so yeah, I don't know. I think on, on full stack, I definitely, um, you know, got a lot of feedback along the way. Um, you know, a lot of what was really helpful was actually like, I, I, you know, I work on it every single day. Um, and then, you know, sometimes you get some interesting feedback through social media, but like a lot of times it's like going to PyCon.

just talking to people and being like, "Oh, I built this thing. What do you think about this?" And then they would take a look and email me back a couple of weeks later and be like, "Hey, I read through your stuff and give me feedback." So I think it's a combination of... I personally really liked the fact that you get some feedback online, but also if you bring that into conversations in the appropriate conversations, people also give you really good feedback through that as well.

Yeah, I'm would you have so you you started full stack when you as you were a full time engineer, right?

Yeah, I did. Yeah. Back in 2012. Yeah. In fact, like the reason, the reason why I did was because like I was home for the holidays and this was when I was like still pretty young and young and single and no like family or anything. And I just like went on a coding like bender because I had just like done all of this like Python stuff, like deployment related stuff. And the full stack Python started out as like a,

almost completely deployment related information. And I really just wanted to get it out of my brain. It was like a way of like me relaxing during like the holidays was just like, I have all this stuff that's rattling in my brain. I'm just going to put it down on, on paper and publish it online. And then it just kind of like snowballed from there. So yeah, I was a, I was a full-time developer when I actually started it. Well, you, you brought up one of the things of keeping,

Keeping up, trying to make yourself less easy to lay off is having more than one skill. Having skills in not just coding, but also communication and public speaking and teaching, writing, etc.

do you think that your involvement with, uh, with full stack Python and with speaking at conferences and things like that led you to be somebody that would make a good developer relations person? Um, yeah, definitely. So I, and, and, um,

That was one of the reasons why Twilio originally hired me. I was a developer evangelist for them. Twilio was still pretty small. They had a few developer evangelists, but that was kind of their primary marketing effort in order to market to developers to use the API. So yeah, I was doing a lot of writing and speaking, but 90% of my time was spent coding. It's kind of the perfect match for what you want in someone who is a

a potential like developer evangelist, developer educator. Those skills. I, I didn't think that I would value at work as much. But it, but I do the, I knew I wanted to be able to do public speaking more and to write better. So blogging and podcasting, speaking at conferences, something I wanted to do on my side projects,

And just to get involved with Python. But it turned out that it has helped me at work. I'm a better speaker at work. I'm not afraid to talk at a meeting or anything like that. It doesn't even matter who's there. Some of the large managers can be there and I can stand up and talk without sweating too much.

I think that that's comes from a lot of my involvement with the open source community. Yeah. And I don't know, were you, before you were a manager of like up to tons of people, were you somebody that was comfortable with, with leadership or with public speaking or was that something you've learned? Certainly the public speaking, but I think,

To be a really good manager, you have to be just constantly intentional about wanting to be a really great manager. And to be fair, I actually didn't particularly want to be a manager. I thought I would just be an individual contributor. I just mostly... Once I had the opportunities, I was...

Like you either have to grab a hold of them or not. Right. And I think for better or worse, like a lot of managers kind of go into management because that's kind of where they're pushed, but they don't really want to,

take that opportunity and be amazing at it. I still have a ton to learn. But like, I am extremely intentional about the way that I manage. And, you know, I want to be a really good manager in addition to still having all my technical skill set. I'm not sure I necessarily see that same desire from every manager. I think some of the, you know, unfortunately, some of the weaker managers that I've

I have personally had in my career are the ones that think that because they got the title, now they make all the decisions. When in fact, like that's typically like not how things work. Right. Which is why, like I've, I've been very intentional about, you know, studying servant leadership and what are the right ways to manage folks that are particularly technically talented and, and creative, you know, there's different management styles, but you also have to like kind of know your own personal,

preferences and things like that and kind of come up with something that works for you and the people that report to you and the team that you have at that time. So all there's like so many variables in management. And I think that is a one big thing that people have to recognize is like there's

um you know there's different ways that you need to approach this problem just like you need to approach different architectures you know technical architectures or whatever and these are not like i am a manager i know how to manage like you don't you may know how to manage in like one slice of a situation of a team and completely not know how to manage in other situations so there's like definitely a self-awareness component to it as well well i want to bring up the the

A management style that grates on me is maybe it's not a style, but the managers that actively try to make sure they look like the smartest person in the room either just take credit or just dismiss some of the accomplishments of the people that are working for them because they want to be looked at, seen as the superstar.

Well, and I think that's actually how you become a better manager. If you want to be a better manager is you just think about those traits and why they were so grating and why they actually caused you as an individual contributor to do worse work. It has the opposite effect, right? I know that when I highlight the accomplishments of folks that report to me or different teams or things like that, that makes them want to do

like more of that. It makes them want to be better, right? Because they get recognized for their accomplishments as opposed to feeling like somehow someone else is going to take the credit for that. But you also have to have the right culture. I mean, some companies have such toxic cultures where even that type of thing is not possible. But I don't know. I think that also feeds into like,

I want to work at places where I can recognize other people and they get recognized for the things that they do. And everyone feels good about that situation. I can deflect any sort of credit onto the people that truly did the work. And that is how I think you create a much better company culture overall where people are actually happy and productive.

Yeah. So does Plush Cap, the technologies behind that line up in any way with what you do on a day-to-day basis or?

Sure. So I would say yes. So PlushCap is built in Python Django. I deploy it to just a virtual private server. I use Ansible, a lot of tried and true tools. So my opinion when I... And again, everyone has to develop their own style. But when I use side projects,

I actually tend to use like the same tools that I know. So I'm using, you know, my code editors, Vim and Tmux, which I've been using for 15 plus years. You know, Django, which amazingly I've been using for 15 plus years, still a

unbelievable framework. Obviously Python, I continue to increment on the versions. I've gone from Python two to Python three, you know, all that. And now I'm taking advantage of like Python, you know, 3.10, 3.11. So, so incrementally I'm learning through Python,

some of these tools as they, you know, like Django just went, what, 5.0 or whatever it is. So I'm still keeping up with the tools, but they tend to be the same tools that I use consistently. So I think that in some ecosystems, this might actually be a really difficult thing to do. So for example, like in iOS, like I actually think you need to spend a lot more time learning Swift and iOS and keeping up with it that may make it actually really hard to do on the side.

But for me, for PlushCap, it's a Python stack. And then I add tools in that I think are going to be uniquely relevant and often do correspond to my job. So for example, there's a tool called Ollama. It's a way to run large language models on your local system. And I run like the...

the dolphin version of like mixed role, uh, seven, eight times 7 billion parameter model, uh, locally. And I actually use that to create, um, uh, summaries, uh, for, um, blog posts. So plush cap basically takes in all of the public data and information, blog posts, site structure, YouTube videos, all sorts of things, and basically creates a profile for various companies. Um, and so, and part of that, I take all the blog posts. So I have a data

database of tens of thousands of blog posts that companies have written. And I'll create summaries for each one. So I actually run those through a local large language model and I'll create a summary out the other side. So you can take a 5,000 word blog post and just distill it into a single paragraph that will give you the gist of that whole thing. So that way you're actually able to consume... I can actually consume the fire hose from hundreds of companies and actually understand what they're

working on and what they're doing. So that's how I like mix in tools that are relevant, that are new, that actually give me like an understanding of like, kind of like, you know, they actually help do help me at work to be better, because I understand how, you know, this, this particular LM is valuable for certain things and not for others. That's pretty cool.

Is plush cap just a private thing or is it available? It's available. It's plushcap.com. And it's, you'll just see, it's like a database of all these different companies, you know, and you can sort of sort them by different categories and click into them and see their blog content and things like that. So for me, I use it actually mostly to, I use it in part because that's actually how I operate my teams. I can say like,

you know, Hey, we want to publish like X number of blog posts. And, um, you know, like it basically gives me enough metrics of what I call input metrics, like input into like how much our team should be producing. Um, that then I can combine that with our, you know, proprietary metrics and really make sure that the team is like operating, um, according to like, uh, the way that we, we need to run the business and actually drive the business results. So, yeah. Any, uh,

Any sneak peek at some of the answers? If I've got a limited amount of time, should I write blog posts? Should I go on YouTube? Oh, for actually doing developer relations stuff? Yeah. What's the biggest bang for the buck right now?

Okay. So this is my personal opinion and, you know, but I think each company really only gets to be known for like one thing. And so you got to figure out what your thing is as a company, if you want to be an exceptional company. So for Twilio, it was developer events. I went to 86 developer events in 2014, my first year, we did 500 events that year.

So Twilio just became known for you meet a Twilio developer evangelist at PyCon or at a meetup or wherever, right? You know somebody personally from the company.

Stripe became known for their exceptional developer docs. Eventually, Twilio actually became even better known for a lot of the developer content, particularly as we enter the pandemic. Assembly AI is known really well for our YouTube channel. So there's actually a list of all the top YouTube channels by subscriber count and view count on Plush Cap. And Assembly AI is basically like

The only companies that have more are like JetBrains has a little bit more of subscribers, the big three clouds, open AI. And that's basically it. Like all the publicly traded developer focused companies don't particularly have a great YouTube presences. And so like, you just have to pick the thing.

that you want to be really great at and orient the team to make sure that they're driving the results that you want out the other side with, with that tactic. And then you can layer in other tactics. Like we do a lot of work on our docs. We do a lot of written content, but we're really, really well known for the YouTube content. That's what like,

I'm constantly talking to other companies about like, they're like, how are you doing like this YouTube content? It's like, well, you know, there's a whole bunch of stuff, but that's what we want to be the best at. Well, like for a while, I don't know if they're still like this, but DigitalOcean was into like user documentation for a long time.

That was, yeah, that was actually the example that I meant to bring up as well. So they actually mentioned their tutorials in their S1 filing when they IPO'd. They said, you know, we have 3000 plus tutorials, they drive X amount of traffic. And this is actually something that powers our business, which is kind of interesting, considering they like, I believe, laid off that whole team fairly recently. I wasn't gonna bring it up. But I was like, Oh, my God, that's, that's, that's why you're known right now.

Yeah, exactly. Exactly. So, yeah, I don't know. They're struggling a little bit. Yeah. Still...

I don't want to diss him too much. I don't know what the internal decision on that was for, but yuck. Anyway. Okay. So very interesting. So trying to be known for one thing. So, well, I actually, for individual, like a small company, just one person or a handful, actually usually just one or two or two friends or something doing something. Yeah.

You can't spread yourself too thin. So I like that idea of like, just pick what you're going to do. Is it going to be, you know, focused on videos? Like a good example is fast AI or fast, fast API. Sorry. He was just really great at awesome things.

documentation there you shouldn't have a question because it's Sebastian's gonna have the answer right there he I don't know if he was doing YouTube videos if he was I wasn't paying attention and he does show up at like conferences and stuff but having the just the nailed documentation right it was part of this growth I think so

Yeah, especially as an open source project, like the docs are exceptional, people are going to notice that, right? Because a lot of a lot of projects, unfortunately, don't always get that right. Yeah. Anyway, writing, you did your did you still writing some, I imagine it's hard to stop writing once you start writing.

Are you still like posting or blogging or anything lately or not as much lately? I will get back to it. Frankly, I've just been spending so much time coding and really enjoying that. And it basically absorbs all of my, my, my own time. I think the other thing too, is like, we are, you know, undergoing this dramatic shift in what is possible with software right now by using software

large language models, even things like assembly AIs, like automated speech recognition, ASR, like just the, what is possible now is like so different than it was five years ago. Like the only thing that I can even compare this time, this, the excitement of this time too, is like when like Ruby on Rails and Django,

It kind of came out and I was like, oh my gosh, I can build web apps so much easier. This is amazing, right? Or maybe when iOS, you could start building mobile apps and things like that. That was amazing. But now, large language models truly are creating a very different computing model. And so I just spent a lot of my time evaluating LLMs, learning about prompting, frankly, watching others.

Sometimes you have something to share when you feel like you have enough that's known and other people aren't talking about it. And that's why I wrote Full Stack Python originally. But right now, I'm still spending so much time learning and actually doing this stuff myself.

uh, until I eventually get to the point where like, I have more to share on the topic. So I think, um, you know, like kind of like what you talked about earlier, like, you know, you kind of have to do the work for a while before you feel confident in that. You're what you're sharing is like the right, the right thing that you have something of value, um, to provide to other people. So, um, yeah, so,

short answer is like right now spending a ton of time on with llms working on plush cap tons of time coding uh coding plus llms and uh eventually i'll shift back into a mode where i'm writing a little bit more i think that'll actually be a little bit more on the developer experience angle because that's actually where i have much stronger opinions right now versus like pure programming which was like sort of like full full stack python side i think it's fascinating to just like sign up for developer services particularly like these um

There's a lot of these machine learning platforms, like just like going through and just like studying, like how do they do developer experience? The good, the bad, you know, there's a lot of lessons take away and learn. That's actually probably where I'm starting to get a little bit of the itch to share a little bit more. And you know, it's obviously something I think about a lot at leading developer experience for assembly AI. So that's hopefully where, and maybe it'll be written, but it might also be YouTube stuff because yeah,

I have this incredible team doing YouTube content and I don't do anything myself. So I feel like for credibility with the team, I got to do a little bit more YouTube content. How, I hope you don't mind me asking, but how, how much like a large language model stuff goes into creating content? Are you using it for like generating first drafts for blog posts or anything like that?

I don't think anybody on the team does. You know, a lot of it just comes down to the fact like large language models are good, can be good at creating outlines or like brainstorming and they're good at summarization, but they're not particularly good at, or at least like it takes a lot of effort to get them to be good at like the more

to be technically accurate and creative. And I still think that eventually they'll probably get there, but the type of content that we're doing on Developer Relations is very step-by-step developer tutorials, or it's extremely deep dives into theoretical concepts. I have a PhD in theoretical mathematics on my team.

right? Like he goes into machine learning topics in like 6,000 word blog posts, theoretical, theoretical explanation that is distilled from academic papers into something that a developer can read and start to understand. Right. That type of stuff is like, I would say beyond the capabilities of LLMs being able to do in a way that is like, you could probably get something out the other side, but it's not going to be like, it's not going to be amazing. And like, I think right now there's like a flight to quality. Like you can tell when you're reading,

Yeah. Well, you can tell when you're reading like boring stuff, it doesn't matter what's created by written by human or created by an LLM. Right now, I've not found that LLMs other than like creative, creative writing, like fiction stuff. I haven't found LLM output to be exceptionally engaging when it comes to like nonfiction topics or technical topics. Now, maybe I'm wrong. Maybe I have read it and I just haven't, you know, been like, wow, I didn't know that I was being wowed by something, but that that's kind of,

Still, I think ahead of us. Well, also just, I think good writing is rare still. So if you're reading the odds are it's bad writing. Yeah. Decent. Yeah. But yeah, I think so. And like, if you want your company to be differentiated and exceptional for particularly for developers who are an extremely discerning audience, um,

You have to not think about how do we publish 100 blog posts per month, but think about how do we make sure that every single blog post that goes out has tremendous amounts of value to someone who is going to read that. And there's obviously different types of content that you need to produce and not everything is going to be a 6,000 word blog post.

Um, but, uh, that I think is actually what is going to differentiate companies now because it's just so easy to use an LLM to produce like garbage. Um, and the differentiation on top is really what sets, sets really great companies apart. Yeah.

Well, so I, we kind of talked about a lot of stuff, but I want to maybe try to summarize a few things for people to look at if they're, if they're in management, they want to stay technical. One of the things you said was on the side doing generic versions of problems that you use at your company anyway. I think still like writing technical blog posts is a good thing. And if, if,

if you haven't done it before then i mean anybody that hasn't written openly before should try it i think um i think it's a good way to stay technical and i think even myself i probably i write way less open blog posts than i used to but the experience of doing it at least in the past has made it so that that's how i think now i i think in terms of do i know it enough to explain to somebody else

whether it's YouTube or blog post or something. And then side projects of actually, do I know this enough to actually have a completed thing that other people can use also? Or even if it's just that I can use, there's nothing wrong with side projects that you're the solo user for. Yeah.

I think the other thing was, was making sure that you're not just thinking about coding skills, but also thinking about things like, like writing and speaking and just communication skills and people skills and management. You can always be improve your style as a manager.

Anything else that we should throw out there? I had just a few quick tactical tips, which is like, I think you also have to know yourself. So if you're constantly bashing your head against the wall and you're frustrated because you're like, I want to be a better writer, but you just don't want to do it.

Like maybe don't put the pressure on yourself to do that. Maybe there's something else that you want to improve. So I think improve like, so for me, I think the big thing that whether you want to work on some side projects or you want to be, you know, coding in addition to managing is like just having something every day that you can accomplish. So for me, like I really enjoy getting up in the morning. I tend to wake up pretty early and I just write a little bit of code.

the first thing I do because I'm not distracted. And sometimes I write code for two minutes and sometimes I write code for an hour before my son wakes up and I'm done for the day. So I think just having something every day that you can accomplish. I think I've actually also, just to get back to the real technical angle, there is a tremendous advantage in having a really quick deployment pipeline. So I deploy PlushCap changes to it every single day.

Um, and it's because it's like one command. It's like deploy, deploy, deploy. Right. So if I have an idea and I have enough time to code something in the morning, I can immediately deploy it and go send it to a bunch of people. Cause there's people that I have as friends or, or colleagues that use the tool. Um, and so for me, like, that's like a, almost like a little bit of like an adrenaline rush is like, can I finish this little feature and like send it to people before like the start of the day, my like actual day starts. So that only comes with having a really easy deployment pipeline. Um,

And then the one other tip I have for people, particularly if you're like a manager and you want to keep up with your coding skills is like, I actually take all of my notes in Vim. And that allows me to just have the muscle memory. So I like all my notes for like my one-on-ones, to-do lists, like anything is like in Markdown in, and I just use Vim for everything. Right. So when I'm like going and coding, like I don't have to like, like there's no context switching. Like,

Like I'm encoding and writing to me are like almost to some extent interchangeable. So that way, like I'm just, I'm always fluent in my tools. So I think that actually is like, you just want to make sure there's like no impediments to you just being able to do this stuff on your own. Right. Like if you have to overcome five hurdles in order to work on a side project at night, you're probably going to most of the time fail at the third hurdle. So just don't have any hurdles. Just do it.

I don't know how I overcame this, but it used to be that like outlook would close a window if you hit escape. And I think that maybe I've overridden that or something, but being a V Vim user or VI, I, so I haven't actually used VI directly for, I,

I use it like if I'm SSH into something. Yeah. But normally it's either VS code or pie charm in Vim mode. But, but yeah, I, I, all of my writings in Markdown and,

and VI too. So you're, you're already doing it. Yeah. Yeah, definitely. So we could talk on this subject for a long time, but I want to wrap things up. Thanks a lot, Matt, for, for coming on the show and we'll talk to you later. Sounds good.

Thank you for listening and thank you to everyone who has supported the show through purchases of the courses, both Hello PyTest, the new fastest way to learn PyTest, and the complete PyTest course, if you'd like to really become an expert at PyTest. Both are available at courses.pythontest.com and there you can also join the Python test community. That's all for now. Now go out and test something.