In this show, I open you the doors to companies and thought leaders around the world. With my guests, I discuss software engineering best practices and pitfalls, and how they strive to build software people love.
Similar Podcasts
The Rabbit Hole: The Definitive Developer's Podcast
Welcome to The Rabbit Hole, the definitive developers podcast. If you are a software developer or technology leader looking to stay on top of the latest news in the software development world, or just want to learn actionable tactics to improve your day-to-day job performance, this podcast is for you.
Flutter 101 Podcast
Weekly podcast focusing on software development with Flutter and Dart. Hosted by Vince Varga.
Views on Vue
Vue is a growing front-end framework for web developments. Hear experts cover technologies and movements within the Vue community by talking to members of the open source and development community.
Relationships Ruin Your Code Reviews
Key Insights:Importance of Code Reviews: Code reviews are essential for error detection, understanding new features, adhering to coding standards, and ensuring only reviewed code is deployed.Emotional Impact: Emotional dynamics play a significant role, with 30% of developers reviewing code from less favored colleagues, which can lead to biased judgments and negative feelings.Striving for Objectivity: Despite personal feelings, approximately 76% of developers strive for objectivity to maintain professionalism.Impact of Developer Experience: The experience level of a developer also influences the depth of code reviews and the manner in which feedback is provided.Perceptions Formed: Reviewers' perceptions of code quality can affect their views on the author's skills or character.Strategies to Mitigate Bias: The episode outlines multiple strategies to reduce bias in code reviews, such as involving multiple reviewers, standardizing review criteria, and implementing anonymous reviews.Additional Resources: Read the full paper called "How social interactions can affect Modern Code Review"Visit awesomecodereviews.com to discover Dr. McKayla’s latest article on the top 10 code review techniques and methodologies, including systematic approaches like using checklists and change-impact analysis.Conclusion: The podcast sheds light on both the positive and negative impacts of human factors in code reviews and emphasizes the need for strategies to minimize bias, enhancing both code quality and team dynamics.
Measuring and improving developer experience
Make code reviews your superpower at awesomecodereviews.com!Episode Resources:Paper on improving developer experienceAbi's thoughts on the DX paperAbi Noda's LinkedInAbi's podcast for Engineering Enablement leadersAbout Abi NodaAbi Noda is the CEO and founder of DX, a company that helps measure and improve developer experience.
From DevOps to Platform Engineering
Earn additional income by sharing your opinion on userinterviews.com!Episode Resources:What is platform engineering?What is an internal developer platform?What is Dynamic Configuration Management?Salesman tricks for the Platform EngineerPlatform Engineering communityPlatformCon 2023Luca’s LinkedIn and TwitterAbout Luca GalanteLuca is leading product at Humanitec, saw hundreds of DevOps and platform setups, and shares his learnings in his weekly newsletter PlatformWeekly (with 10k subscribers). He is also the core contributor to the Platform Engineering community, with 10k+ meetup members, and 8k+ Slack members.Make code reviews your superpower at awesomecodereviews.com!Other episodes you'll enjoyCan Engineering metrics be ethical?Measure developer productivity using the SPACE frameworkHigh-performing engineering teams through DX
From English teacher to dev in 9 month: A self-taught developer journey
Earn additional income by sharing your opinion on userinterviews.com!Episode Resources:Nadia's BookNadia's websiteNadia's TwitterAbout Nadia ZhukNadia is a software engineer at Intercom, and was previously working at Zendesk. Before, Nadia was an English teacher, and journalist, until she decided to learn programming and enter the tech world.Make code reviews your superpower at awesomecodereviews.com! Other episodes you'll enjoyDo code reviews frustrate developers?The Secret To High-Quality CodeVulnerability disclosure with Katie Moussouris
Do code reviews frustrate developers?
Earn additional income by sharing your opinion on userinterviews.com!Episode Resources:Alexander's TwitterAlexander's ResearchAwesome Code ReviewsPapers:An exploratory study on confusion in code reviewsEmotions and Perceived Productivity of Software Developers at the WorkplaceRecognizing developers' emotions while programmingGendered Experiences of Software Engineers During the COVID-19 CrisisDeveloper experience research paper About Alexander SerebrenikAlexander is a Full Professor of Social Software Engineering at the Software Engineering and Technology cluster of Eindhoven University of Technology (TU/e). Alexander’s research goal is to facilitate evolution of software by taking into account social aspects of software development.
Fighting software vulnerabilities with software bill of materials
Earn additional income by sharing your opinion on userinterviews.com!Episode Resources:Executive Order on Improving the Nation’s CybersecurityAlpha-Omega ProjectsCybersecurity & Infrastructure Security Agency (Cisa)Tools to create SBOM About Barak BrudoBarak Brudo helps organizations secure their software supply chain. He works as a Developer Relations Advocate at Scribe Security.Other episodes you'll enjoyWhat developers should know about securityThe Secret To High-Quality CodeVulnerability disclosure with Katie Moussouris
Mastering a difficult job search
Earn additional income by sharing your opinion on userinterviews.com!Episode Resources:Heather's TwitterHeather's job search blog postHeather's BlogAbout Heather ReidHeather Reid is a Test Engineer at Glofox. Before that she was the community boss for Ministry of Testing, making sure that the testing community had everything to be successful. Before that, she was a software tester at Exploristics and at Moola.Episode Chapters:00:00 Introduction02:00 What does a test community boss do?06:28 Can we forget our skills?08:00 Attending workshops09:00 4-hour interview experience10:00 Hurtful rejections pile up12:10 Can't ask questions in an interview14:00 A good interview experience19:00 A technical test23:00 Different backgrounds and perspectives26:10 Arguing during an interview30:50 Improving the state of testing 33:50 Adding accessibility 40:00 Career advice for job seekers
Entrepreneurship, Career Growth and Testing: Top 5 Episodes of 2022
This episode samples:Alvaro Trigo, who once was a web developer but could quit his day job to work on his open source software Fullpage.js.Daniel Vassallo tells us why he left his cushy job at Amazon to start many small businesses.Dagna Bieda explains how you can fast-track your engineering career and what mindset has to do with professional growth.Mauricio Aniche explains how to write tests that find bugs and what domain-driven testing is.Nuchals Dular shares why the engineering manager position he worked hard toward to wasn’t meant for him.YouTube Video: https://youtu.be/XKKFCmvK7_M
Coding practices at MAANG companies versus startups
Make code reviews your superpower at awesomecodereviews.com!About Michael LynchMichael is a software engineer and entrepreneur. He has launched several businesses after leaving Google in 2018. His hardware/software business, called TinyPilot, lets you control any computer remotely and has brought him the most success so far.Episode Resources:Michael's TwitterHow to Do Code Reviews Like a HumanTiny Pilot
Can Engineering metrics be ethical?
Book your awesomecodereviews.com workshop!Episode Resources:MultitudesLauren's TwitterDeveloper experience research paperDORA metricsSPACE developer productivity frameworkAbout Lauren PeateLauren is the CEO and founder of Multitudes. Her goal is to empower engineering teams to be high-performing through a people-first way to software performance metrics. Lauren’s worked with tech teams around the world, from Silicon Valley to the Middle East and now New Zealand.
Collaborative debugging with Fiberplane
This episode is sponsored by Fiberplane. Your platform for collaborative debugging notebooks!Episode Resources:Try Fiberplane hereFiberplane websiteFiberplane DocsNP-hard Ventures About Micha Hernandez van LeuffenMicha Hernandez van Leuffen is the founder and CEO of Fiberplane. He previously founded Wercker, a container-native CI/CD platform that was acquired by Oracle. Micha has dedicated his career to improving the workflows of developers. Read the whole episode (Transcript)[If you want, you can help make the transcript better, and improve the podcast’s accessibility via Github. I’m happy to lend a hand to help you get started with pull requests, and open source work.][00:00:00] Michaela: Hello and welcome to the Software Engineering Unlocked Podcast. I'm host, Dr. McKayla, and today I have the pleasure to talk to Micha Hernandez van Leuffen. He is the founder and CEO of Fiberplane. He previously was the founder of Wercker, a container native CI/CD platform that was acquired by Oracle. Micha has dedicated his career to improving the workflow of developers, so he and I have a lot to talk about today.I'm really, really happy that he's here today and he's also sponsoring today's episode. Welcome to the show. I'm happy that you're here, Micha.[00:00:36] Micha: Thank you for having me. Excited to be on the show.[00:00:38] Michaela: Yeah, I'm really, really excited. So, Micha, I wanted to start really from the beginning. So you are the CEO of Fiberplane and you are the founder of Wercker, which you already sold.So, can you tell me a little bit about how you actually started to this entrepreneur journey of yours and what brought you to the developer experience area.[00:01:03] Micha: Yeah, sure thing. So I have a background in computer science and I did my so, I'm originally from Amsterdam, but I did my thesis at USF.And the topic was autonomous resource provision using software containers. This was all before Docker was a thing, you know, the container format that we now know and love. And I sort of got excited by that field of, of so containers and decided to start a company around it. That company was Worker, so container native CI/CD platform.So we helped developers build tests and deploy their applications to the cloud. We went, I would say, so we went through various iterations of the platform. You know, eventually, you know, we started off with Lxc as a container format and then eventually ended up, you know, having to, to platform on Docker.And Kubernetes. But, you know, it was quite a, quite a journey. So that company eventually got acquired by Oracle to bolster their cloud native strategy. And then, you know, spent a couple years in a Bay area as a VP of software development focusing on their cloud native efforts.Tried to do a little bit of open source there as well, and then, you know, move back to Europe. And so sort of started thinking about what's. Did some angel investing. We're still doing some angel investing as well actually in the sort of same arena. So developer tools, infrastructure building blocks for tomorrow.So I run a, a small precede seat fund with to other friends of mine. But then also started, you know, thinking about what to build next. And you know, we can get into that, but sort of from our experience at running work or this sort of large distributed. Sort of fiber plane was, was born.[00:02:26] Michaela: Cool. Yeah. And so how, how was the acquisition for you? I, from the time I'm, you said you were studying at the university, but then did you write out of university, you know, start worker or maybe already while[00:02:40] Micha: you were Yeah. More or less studying? Yeah. Yeah, more or less just out of university. So it was around 20, 20 12, 20 13.And then, you know, expanded the team. Of course we got an office in San Francisco and, and London. And then 2017 we got acquired by Whirlpool. Oh,[00:02:56] Michaela: very cool. Wow. Cool. So, and you were the, you were the founder of that and also probably cto, CEO. At, at the beginning you were one person shop, or was this, or have this idea and I get some funding and I already, you know, have a team when I'm starting out, or was it more bootstrapped way?How, how was that?[00:03:16] Micha: Yeah, yeah. We both gates, both fiber plane and, and, and worker. We got some funding early on. Then eventually got a CTO. For worker was one of the co-founders of, of OpenStack. So also, you know, very early in the, in that sort of, mm-hmm. container and, and cloud infrastructure journey.And then if for fiber plane, Yeah. There, there's no cto. I'm. I'm both CEO and cto, I guess[00:03:38] Michaela: at the same time. Yeah. Cool, cool. Can you tell me a little bit about fiber plane? What is fiber plane? You know, what does, what does it has to do with containers and with developer experience? What, what kind of of a product is it?[00:03:51] Micha: Yeah, sure thing. So, so guess coming back to the worker days, right? So we, we, you know, we're running this distributed system cic cd, so we were also running users arbitrary code. You know, any, any sort of job could happen on the platform on top of Kubernetes, inside of containers. So one of the things that, you know, stuck with me was it was very hard to always sort of debug the system, like figure out what's really going on when we had some kind of issue.You know, we've going back and forth between metrics, logs, traces, trying to figure out what is the root cause of an issue. So sort of that, that was sort of one thing. So we're thinking a lot about, you know, surely there must be a better way to, to, to help you on this, on this journey. . The other thing that I started thinking about a lot was sort of just challenge the assumption of the dashboard, mm-hmm.So if you think about it, like a lot of the monitoring observability tools are modeled after the dashboard, like sort of cockpit like view of your infrastructure. But I'd say that those are great for the known knowns. So dashboard is great. You set it up in advance, you know exactly what's gonna go wrong.These are the things to monitor. These are the things, you know, to keep tabs on. But then reality hits and you know, the thing that you're looking at, at the dashboard is not necessarily a thing that's. Going wrong. Right? So started thinking a lot about you know, what, what is a better form factor to support that sort of more investigative explorative debugging of your infrastructure.And not to say that dashboards don't have their place, right? It's like still that sort of cockpit view of your infrastructure. I think that's a, a good thing to have. But for debugging, you might wanna sort of more explorative a form factor that also gives you actionable intelligence. I think the other thing that you see a lot with dashboards, like everybody's monitoring everything and now you get a lot of signal and a lot of inputs, but not necessarily the actionable intelligence to figure out what's going on.So that's sort of the other piece where it, then the other, like, the third like I would say is collaboration sort of thing that stuck with. Was also like we've come to enjoy tools like Notion, you know, Google Docs obviously. You know, in the design space we got Figma where collaboration is built in from the get go and it is found that it was kind of odd how in the developer tools and then sort of specifically DevOps.We don't really have sort of these collab collaboration not really built in. Right. If you think about it you know, the status quo of, of you and I debugging an issue is we get on, you know, we get on a. You share your screen you open some dashboard and we started talking over it or something.Right. And so it's, and it's, you know, I guess sort of covid accelerated his thinking a bit, but you know, of everybody going remote you know, how can you make that experience more collaborative?[00:06:22] Michaela: Mm-hmm. . So it's in the incident space, it's in the monitoring space, and you want to bring more collaboration.So how does it work? Yeah,[00:06:32] Micha: yeah, yeah, exactly. So what's your solution now? Yeah. Now I've explained sort of the in inception. Yeah. But yeah, but what is it? What is it? Right. So it's, it's it's a notebook form factor. So very much inspired by data science, right? Like rc, like Jupiter. Yeah, we can Jupyter Notebooks.Yeah. Think of, think of that form factor. Mm-hmm. . We don't use Jupyter or anything like that. We've written everything from scratch. But it's a sort of, yeah, a notebook form factor and you know, built in with collaboration. So you can add, mention people like you would on Slack. You can leave, you know, comments or discussions and all and all that.But where it gets interesting, we've got these things called providers, which are effectively plugins. So they're web assembly bundles, which we can sort of dive into into that as well. But they're providers that connect to your infrastructure, right? So we have, for instance, a provider for Elastic Search for your logs.We have a provider for Prometheus for your. And it allows you to connect to these observability systems and kind of pull 'em together into one form, factor the notebook, and then, you know, start collaborating around that. Mm-hmm. . So, you know, imagine if Notion and Datadog would have a baby . Yeah.That's kind what you get. Yeah.[00:07:41] Michaela: That's cool. So I can imagine that. Let's. I'm on call and hopefully I'm not alone. A call. You are also on call, right? Yeah, and so we would open a fiber plane notebook.[00:07:52] Micha: Hopefully we're in the same time zone and we don't need to like wake up in the middle of that. Yeah.[00:07:57] Michaela: Hopefully. Yes. And then we want to understand. How the system is behaving. And so we are pulling in observers. These are data sources. Yeah. More or less. Right. And then we can do some transformation with those data. Data sources or[00:08:12] Micha: Yeah, yeah. That, yeah, exactly. That, that might be the case. The other thing that we integrate with is, for instance, PagerDuty.So an alert goes off indeed we are on call, but an alert goes off and we have this PagerDuty integration. And subsequently a notebook is created for us already. Mm-hmm. . Okay. Maybe, maybe even with, you know, some, some charts and logs that are already related to the service that might be down.Okay. So depend, So depending on the alert, obviously you're, as you know, you're as good as how you've instrumented your alerts. But say we've written some good alerts, we now have a notebook ready to go. Based off a template. So that's another thing that we, that we have as well, which is this template mechanism.And now, you know, we're ready to, to, to go in, get in into things and start debugging. So we might have a checklist, you know you look at the metrics, I'll look at the logs, sort of this action plan. We pull in that data we start a discussion around it. Mm-hmm. , hopefully we come, we come to the, to the, you know, the root cause of, of our issue.[00:09:11] Michaela: Okay. And so this discussion and this pulling in data, this happens all in the notebook. Can you explain me a little bit more, and also our listeners Exactly. When we are on this, you know, on this call now, having a fiber plane notebook in front of our, what do we see, right? How does that, how does the tool look?[00:09:28] Micha: It's, it's very similar to, I would say, like a Notion Page or a Google Doc page. Mm-hmm. . So we've got like different, different headings. The other thing that we have is, so you might have a title for a notebook, right? You know, the billing, the billing API is now. The other thing that we have is sort of this, this time range.So maybe usually when there's an issue, you know, we've seen this behavior over the last three hours, so we can sort of have that time range locked into place. So we only want to see our. For the last three hours. And that means that any chart that we plot or any log that we pull in will adhere to that global timeframe.So that's what we see. Mm-hmm. . We have support for labels, so, you know, obviously big fans of Kubernetes and, and Promeus. So we, you know, labels are. A first class primitive on the platform. So you're able to sort of populate the notebook with the labels that might maybe be related to our service.Right? So it's a US East one, which is our region. It might, you know, say service is the billing. It might be, you know, environment is production. And the status of our incident is, mm-hmm. ongoing, stuff like that. So we have, we've got, go ahead.[00:10:34] Michaela: Cool. Yeah. And, and so is it then from top to bottom we are writing and we are investigating and we are writing out down the questions that we have and the investigation.Yeah, exactly. We do.[00:10:44] Micha: Yeah. Yeah. And so, so[00:10:45] Michaela: we might have, Is it an Yeah. Is it Yes,[00:10:48] Micha: we our work? Yeah. Yeah. It's sort of Exactly. And I think in the most ideal use case, right. And I do it most ideal scenario, you're kind of like writing your postmortem as you go along. That's what[00:10:59] Michaela: I, I was thinking exactly that.Right. And then maybe next time I'm on call again and I get PagerDuty and something is down, it's again, billing. Can I search in the fiber plane notebooks to find, you know, what we did last time and then[00:11:13] Micha: Exactly. So you'll, you'll search, jump to the conclusion . Yeah. Yeah, exactly. Hopefully, hopefully if you, if you experience, you know, the same issue multiple times at some point, we'll, we'll, you know, do a little commit on GitHub and we, we fix our, fix our, Yeah.Do. But yeah, indeed, so you can search Yeah. Cool. On the notebooks and see if you've, you know, ran into similar issues. So that's, you know, it's great for building up this, this system of record, right. This knowledge base of mm-hmm. . Mm-hmm. . Of infrastructure issues and, and incidents. And it's also great for onboarding, right?If a new person joins, like, this is our process. These are some of examples that we've run into you know, have a look. And now you've got a sense for you know, how we, how we handle things and some of the issues that we've investigated. Yeah. Cool. One more thing on the, on the product. So the other, so, you know, sort of explained the, the notebook form factor.We've got these providers, right, that pull in data. From different, different data sources like Elastic Search or, or Prometheus. The other thing that we have is a command line interface which is called fp. Mm-hmm . And apart from, you know, being able to create notebooks from your terminal and you know, even invite people from the terminal, all this sort of usual stuff that you would, you know, expect from interacting with an API, with, with a product like this, there's two other things that we do.So one is a command called FP Run. And it allows you to, if you are typing a command like cube, ctl logs for a specific pod, you can pipe that the output of that command to a notebook. And why that is useful is of course, you know, when we're de debugging this issue, you and I, and you're start typing things in your terminal.I have no idea what you just did. And this is a way sort of to capture that. So you're piping these these, these outputs from your, the stuff that you're typing into your into your. into the notebook. And the cool thing is, you know, in, on your laptop you just, you know, sort of see text, right?Monospace output. But for certain outputs such as the cube CTL logs command, we actually know the structure of the data and we're actually capable of formatting that in the notebook in the structured manner that you can start filtering on, on the logs and you know, select certain columns and sort of highlight even certain loglines for prosperity that you say, Hey, these are the culprits, these are the things that you need to take into, into consideration next.So we have this sort of command line interface companion, and the other thing that it does, you're actually capable of running a long, like, sort of same use case as it just, I mentioned, but like a long running recording, like you actually record your entire shell session session as you're debugging this thing and all the output gets piped into the notebook.Cool. Cool. And[00:13:46] Michaela: so I have two questions for fiber plane. One. Is the software engineer the right person to interact with you know, fiber plane or is it the site reliability engineer that's really designed, you know, or the tool is designed[00:14:03] Micha: for? Yeah, it's, it's, that's an excellent question. So I think one, one site reliability engineers, you kind of see in more larger organizations, right, where you start splitting up your teams.I will say, I think at the end of the day, right, is if you're an engineer, you've built the service, now you need to maintain it now you need to operate it like it's, it's your baby, right? You need to, you probably know best how that system behaves than anybody else. So indeed I would say that, yeah, the target group is, you know, developers.Mm-hmm. .[00:14:40] Michaela: And so the other question that I had around fiber plane is also. When we are on this call and we are writing in this notebook, how does the whole scenario look like? Are we still on a call, like, do we have Zoom or, you know, Google meet open, or are we really in the, in the fiber plane document just writing, Or are we sitting next to each other?You know, what, what's the traditional, Is there a traditional scenario or is this all possible with fiber plane? How would you recommend using[00:15:09] Micha: it? Yeah, Yeah. Yeah. Not a, not a great question. Right. I think back in the day, it would be that, you know, we maybe sit in the same office and I scoot over and we start looking at a, at a screen, right?And start typing together. Mm-hmm. . The reality is, of course, we're all doing remote work now, and we might not be in the same room. So I do think people will still use a Zoom call or a Google meet you know, as a companion to talk over stuff. I think, you know, people will still communicate in Slack and sort of start chatting back and forth.But I think what we hope to achieve with fiber plane is like the pasting of screenshots, right? Well, if you take a screenshot of some kind of chart in your dashboard and you put it in Slack and you know, somebody yells, Oh, that's not the, that's not the thing that you should be looking at. You should, you know, like all that sort of slack glue That, you know, it's our, our goal to do away with that.[00:15:59] Michaela: Yeah. And, and the slack blue is also very problematic for the search. At least I'm never able to find it again. Right. It's like is in the dark, super in[00:16:07] Micha: the dark area. Yeah. Super ephemeral. Yeah. Yeah. You can't, can't go back in time easily. And, and you know, how did we solve this last time? So again, like building up that system of record, I think.[00:16:17] Michaela: Yeah. Very cool. And so how long are you now working on fiber plane already?[00:16:23] Micha: So we've been working on it for about two years now. Which is a, is a, is a long time. I think as a sort of, you know, one of the things that we've, I guess, sort of discovered along the way that we're kind of like building two startups at the same time, Right?We're doing a notion or like a, a rich text, collaborative rich text editing experience, which is kind of like a startup on its own. Mm-hmm. . And we're building sort of this infrastructure product. So it's, you know, it's taken quite some time and, and energy to, to get the product to where it is now.[00:16:54] Michaela: Yeah. And do you have already users? Is it like can people that listen today, can they hop on fiber plane already or.[00:17:02] Micha: It's, it's in it's been in private beta, mm-hmm. , but I think by the time this gets aired it's will be in public beta and people can sign up and take it for a spin. And, you know, we would love to get feedback on, on our roadmap, right?And Okay. People can suggest what other types of providers we need to support, what are types of integrations we, you know, would love to, to have that convers.[00:17:23] Michaela: Cool. Yeah. So is there, There is the provider side. Is there something else that you want feedback on that you are exploring[00:17:30] Micha: maybe. . Yeah. Yeah. So we've got the providers that's one thing.We've got sort of our templating stack. Mm-hmm. So curious to sort of see how people sort of start codifying their knowledge, right? What's, what, what kind of processes people have to debug their infrastructure and sort of run their incidents or write their postmortems. So curious to see what people come up with there.Other types of integrations. Right? So we have as I said, sort of PagerDuty what other type of, sort of alert, alert to notebook or other types of external systems that we need to plug in with. I would love to get some feedback on that as well. Yeah,[00:18:04] Michaela: I think I had page Bailey over on the podcast.She's from GitHub and she was she was also, they were releasing something with copilot and you know, For data scientists, some, some spaces here. And she also said like, well, we really need input from the users, right? So try it out, you know, tell us how it's working. I think it's so valuable, right, to see not only like you have your vision and obviously.It's going one way, but then if you have your users, sometimes they take your product and they use it in a very different, you know, way than you anticipate it, which can be very informative. Right. I dunno. You have done two startups already. Have you seen that? And how do you react to it? Do you instrument the data a little bit?How do you realize that people are using your product in a different. . Yeah.[00:18:50] Micha: So, so obviously we have metrics and analytics on sort of usage patterns of the, of the product. But I think, I think that data is excellent, right? But also qualitative data is, mm-hmm. , especially at this stage is probably even better, right?Where you can get somebody on a call and, you know, tell us about your use case. Tell, tell us about the problem that you're trying to solve here and how can we be, be helpful in like what types of integrations should we support? I think sort of the difference between. Worker, I would say, and, and fiber plane is that, you know, worker was a pretty confined piece of surface area, right?Cic, c d the whole goal is so you either have a, you know, a green check mark next to your build or a red check mark next to your build. Like it either, you know, failed or passed. And we need to sort of do that fast for you, get, get that result quick. Mm-hmm. . And with fiber plane, it's a more. I think that the interesting thing here is like, it's a, it's a more explorative and a sort of rich design space, right?It's this notebook, which already you, you know, you can start typing and text and images and headings and check checklists and whatnot, right? It's a very open form factor and design space. And then of course, with the integrations, it can even, you know, be richer. So I'm very curious into your point, right what direction people will pull the product into.Cause you can take it into all sorts. Use cases and scenarios. Yeah,[00:20:05] Michaela: exactly. And I think as a founder also, or as the design team, product team, it's it's also a little bit of a balancing act, right? So how far, you know, let me, are we going with what the user are doing with our product and where are we setting some boundaries that they can't do everything right?So there's also often the talk about opinionated products, right? That you can actually do one thing and on one thing only, and we have an opinion on, you know, how. Supposed to use our product. And you know, we try to, if we see people deviate from that, we try to put an end to it. And then there's the other way where you say, Well, you know, if you take fiber plane and you do X with it and we haven't thought about this maybe, you know, we are okay with it.Or maybe we even support that path, right.[00:20:48] Micha: Yeah, I think, I think we're more on indeed on the, on the ladder, right? I think what we've sort of, we talk about this a lot internally, sort of everything is a building block. You know, you've, we've got the notebook, you've got these different cell types, you've got providers, you've got templates.Mm-hmm. You've got the command line interface. So like for us, like everything is a building block and we, we actually want to retain that flexibility. Not be too prescriptive. Cause maybe you have a, a if you think about sort of the, the incident debugging or, or investigating your infrastructure, like you might have a certain process, I might have a completely different process and we need to be able to facilitate, you know, these different workflows.So, you know, thus far sort of our, our thinking around the product has been everything is a building block. And it should be this sort of flexible form factor that people can pull into into different scenarios and use. I mean,[00:21:36] Michaela: we have infrastructure as code, right? And we have like security as code.Maybe we have debugging as code. Maybe, you know, this is what's coming next. Can, can you envision that, that it's going in this direction? Because while we have building blocks, maybe right now it's not you know, programming language for debugging, but it could go a little bit into the distraction, right?No code coding for debugging.[00:22:02] Micha: Yeah, we've actually, we've, we've had some of, of that sort of discussion internally as well. If you think about the templates right. To, to some extent that is a, you know, we use J Sonet as a, as a sort of language, but we sort of codified them in a certain way and you can, you could argue that the templates is, you know, sort of a programming language for at least, you know, that debugging process, right?Yeah, exactly. Right. Yeah. And. And, and we, you can take that even further and make it kind of like statically typed and make it adhere to, you know, certain rules and maybe even have control flow. So I think that, that there's, there's a piece there. And then maybe, you know, obviously we have you know, some YAML configuration on how you set up your providers, right?Like how to connect to your infrastructure. So there's some, you know, observability as code in mm-hmm. in that realm. Yeah. Yeah. I think that'll be an interesting part of the journey, right? Like to figure out can we, and some even.[00:22:55] Michaela: Yeah, in some parts should be well, don't repeat yourself, right?Like, for example, pulling in these providers, configuring that, you know, I get the right data. This would actually be something that I'm, you know, pulling in again. And probably that's what your templates do, right? So you say billing, oh, and then check, check, check, check, check. I have, you know, all my signals here and they're configured in a way that it's useful.And then for this investigation, hopefully, One at a type thing, right? So I'm investigating, and as we, as we talked before once I realized what's going on, hopefully in my postmortem I'm going to, you know, make sure that this is not happening again. So this code probably is not going to be reused that often.Maybe some, you know, some ideas from it, but hopefully we won't reproduce the same sect completely exact thing again.[00:23:44] Micha: Yeah. Cool. Yeah, that's, that's a super great point. And I think coming back, sort of the early part of the conversation around dashboards, right? I think thus far what we've sort of experienced as, you know, engineers ourselves, like, I think, I think we probably had sort of a phase around information gathering.Like all these dashboards are great for information gathering, but now with Kubernetes and containers and microservices like the, the, the number. Services that we're running and the complexity has increased. So I think, I think there's sort of an opportunity for more exactly what you're describing. So it's more about action, right?Mm-hmm. , what? What are we doing? We want to have the information, we want actionable intelligence that informs us what to do.[00:24:20] Michaela: Yeah, yeah, exactly. Because now I'm looking at this dashboard and I'm seeing the signals. But then everything else is outside of, you know, this realm, right? So what actions do I take?Do I go, go to the console? Do I restart that service? You know, or, you know, whatever I'm doing. And, and it's also vanishing, right? So I'm doing it, but then. Who can see it, What I did. Right? Yeah, exactly. And so now we are capturing this, which is very nice, and then we can learn from it Right. Postmortems as well.Yeah. So I looked a little bit through your blog and and, and your Twitter, and you were also talking about blameless postmortems. So how do you think about psychological safety? How should people. In an organization look at on call and incident management to really make it sure that we are ending the blame game.Right. You probably have some thoughts about that as well, because you're working in this area.[00:25:19] Micha: Yeah. I, I think it's important to, and you like not have put any blame on any person. Right. It, it is a, and I guess sort of, you know, that's also why we're building this product. It is a collaborative process to debug an issue or resolve an incident.Like, and what you want to achieve is to put the entire team in the best possible position to solve the issue at hand and and, you know, a support structure around it. So, you know, coming back to the product, like being able to, to open discussions. Point people in the, in the, in the right direction.[00:25:52] Michaela: So maybe also if it's easier to find a problem to root cause it, and, you know, incidents become no issue or at least a lesser issue. So maybe the blame game is not that important. Can, can we say it that way?[00:26:08] Micha: I think so. Yeah. Yeah, yeah. If, if, you know, if the process becomes repeatable and we codify that and we collaborate on it and we build up that, again, that system of record and knowledge base I think that, you know, puts us in a safer position to, to solve the next one.That's[00:26:25] Michaela: true. Yeah. Another thing that I was thinking of when I looked through, you know, fiber plane and what it does is KS engineering and I thought like what KS engineering is where you try to prevent not only the knowns, but also the unknowns, right? So really think about, you know, what, what could go wrong and then, you know, make a fallback so that your system is reliable.Or, you know, if this database goes down that not the whole system goes down, but only a part of it and so on. Do you think that KS engineers can act. Source or, you know, use those notebooks that you're creating as input for knowing, you know, what we should actually look at and, Yeah.[00:27:02] Micha: Well, I think it, well, one thing I think it'd be a great provider yeah.integrating with, with, with, you know, one or many of the, the chaos engineering services out there. I think it's a great way to train your team, right? You, we plug in some K engineering provider. The, the provider communicates with your infrastructure and such, pulling out wires from from, you know, your, your system.And then now go ahead and start, you know, debugging this issue and mm-hmm. and you know, use different templates and you can, you know, sort of trial all sorts of different issues. I think it'd be super fun. Yeah.[00:27:37] Michaela: Yeah. So Micha, one thing that I also saw is that some of your of fiber plane is open source.So what's your vision for open sourcing that are, you know, are some parts being open source? Can people help with the building fiber plane?[00:27:51] Micha: Yeah, great question. So right now what we've open sourced is a project called fp bind Gen. So this is actually of SDK bindings, generat. For how you would create full stack web assembly plugins.So this is what we use to build our own elastic search and our Prometheus plugins. So we've, we've open sourced that. It's on GitHub we've already got some, quite some feedback on it. So, but would love some more. And then going forward we'll be open sourcing sort of our templating stack the proxy.Which sort of sets which you install inside your cluster and sort of sets up the secure connections between the providers and your infrastructure and then the fabric plane managed service. And then the command line interface that I mentioned will also be open source. So expect more to hear from us on the open source front.[00:28:36] Michaela: Yeah, Cool. I think that's so important, especially for developer tooling, that people can also really get it into their hands and then help, you know, shape the, or make the best product for their, for their environments that they have. I think this is such a success strategy.[00:28:50] Micha: Yeah, exactly. And you know, we, as I said, we would love to get feedback on the, on the providers and the, the plugin model, but maybe even, you know, once we open source the the, the provider stack would be great if people maybe come up with crazy ideas.Right? You can think of any type of provider that you could surface data inside of, inside of the notebook. Yeah. Doesn't need to be observability or like monitoring data. Like could be. Yeah.[00:29:14] Michaela: Cool. Yeah, I'm super excited. What, you know, what will come out of that. Yeah. So I want to come back a little bit to your founding story because I know a lot of people are interested in developer tools and, you know, and, and Startup founding as well.And you did it twice already, right? And maybe several more times in your life, I dunno. But right now we know of two instances. Yeah. There, there. So, and and also for fiber plane, you already got funding, right? Several million dollars. And so how do you do. How do you do it out of Europe is also some of my questions that I have because I think it's a little bit a different game here in Europe than it's in Silicon Valley.Yeah. It doesn't look like, you know, opportunities around the corner everywhere. I, I have been studying in the Netherlands, so I know that actually Netherlands is really a good place, I think for, for tech startups and, you know, also a little bit out of the universities I saw there like You know, you get a little bit of help and, and, and funding and things like this, but still, I would assume it's harder than in Silicon Valley.So how did you make it work? How did you get funding? You also said that worker had some funding at the beginning. Yeah.[00:30:26] Micha: Yeah. It's a good question. Well, how did we do the second time around, to be honest, Because it's the second time. Yeah. It was a bit easier. I mean, it's never, It's, Yeah. Yeah. It's obviously, you know, never as easy.But it was definitely easier. I do think in Europe, if I also compare it to the worker days to where we are now, Like I do think the funding climate and sort of the, the, the, the thinking around startups has improved a lot, right? There's there's more funding out there, there's more feess. I think more importantly though, what we've seen is that now.Sort of the European unicorns have exited or gone ipo. And we have actually more operators inside of Europe that have experience in either founding a startup are able to sort of start doing angel investing or have worked at multiple startups and we have just more operating experience you know, versus honestly like bankers, right?That That, you know, help you out or are, are investing in you? So actually the, the, the funds that funder does were Crane Venture Partners which is actually a seed fund out of London that's actually focused on developer tools and infrastructure. So I would highly recommend, you know, talking to them.If you're thinking about, you know, building a developer tool company and you need some funding, of course my own fund is also focused on developer tool. So shameless plug there on MP Hard Ventures. You can just Google that and find me. And then we have North Zone, which is a, you know, very like multi-stage fund.Also out of, well actually quite different geographies and Notion Capital out of out of London as well. Okay. We've got some have several micro VCs, several things. Yeah. We have somebody funded West Coast Alana Anderson was doing with base case capitals investing in a lot of infrastructure and enterprise startups and Max Cloud from System one in Berlin.Is another one. So yeah, we have a good crew of, you know, a diff different experience and sort of different stage type of funding as well.[00:32:19] Michaela: Yeah. This was my next question that I had for you. It's probably not only about the money, you said experience, right? It's also about the knowledge that people have, right.How to do things. Probably, yeah. The people that they know, right? So that they can Yeah. To be Yeah, exactly. Can consider the right people have the right network and so.[00:32:36] Micha: Yeah, I think, I think the most, yeah, it's is, is introductions, but it's also. You know, if you, if you think about the, the funds that actually do developer tools, right?So they, in their portfolio, they, they've seen, you know, startups trying over and over to tackle some kind of go to market issue or trying to build an open source, mm-hmm. company, right? So they have some, some pattern matching and some, some knowledge about, you know, what to do and what, what not to do.Of course, it's all advice, but it's good to sort of have some people in your corner that have at least seen this, these types of companies being built. Over and over again. Right. That's, and then, and then other VCs have more experience in, you know, more, more like how to build up or scale up a sales organization and thinking about how to run a SaaS company.So yeah. Different experience from different, different funds.[00:33:20] Michaela: And so now you listed quite a lot of different investors. Do you reach out to each one of them or do you have like a whole group meeting and they're all in there and you ask them for advice? , how does it[00:33:33] Micha: Yeah. No, it's, it's sort of one on one chats, right?Either over, over chat or, you know, we meet up for coffee or, or or breakfast, mm-hmm. . But yeah, we try to do that on a, on a regular cadence. And then of course, when, you know, something exciting happens, such as our launch know, we try to group them together and get them all on the same page around the same time.Or of course if an issue arises, Right, which could also be the case. Yeah. And then sort of all hands on deck and everybody in the same room or zoom.[00:34:01] Michaela: And what about your biggest struggle on your, on your entrepreneurial journey, maybe now with fiber plane or maybe with Worker? Did you ever think that, you know, worker, when you started it, did you think that somebody is going to buy this and.This is going to be huge.[00:34:16] Micha: Yeah. Yeah. I think, I think the ambition was always there. Mm-hmm. . And, but, and, and sort of that drive to just make better developer tools. I think that sort of, that, you know, that's been true for all the companies or all too. Yeah, that's,[00:34:30] Michaela: Yeah. And what[00:34:32] Micha: I struggle. Yeah. Yeah. So I think, I think as I think for fiber plane now, it's not necessarily a struggle, it's just the real, which this mission of this flexible form factor, just the fact that we're doing sort of two startups at the same time has been sort of mm-hmm. An interesting thing to to build now, right? You're doing this rich, collaborative, rich tech editor and trying to build this infrastructure oriented company, and I think that's been yeah, just an interesting experience with building out a team.You know, the technology and the product that we.[00:35:01] Michaela: Yeah. Yeah. So maybe can you tell me a little bit more about again, if people want to hop over to Fiber plane now and try it out how does that work? Do you have to, you know is there a sign up? Is there a waiting list? I mean, you said probably when this airs there is a public beat, but still do you have to, you know, what do you have to reach out to you, you give me a demo or I just fill in my credentials and I'm off togo.[00:35:25] Micha: you can just sign, sign up with Google and then you're off to the races. And then of course, if you want a demo and sort of get some more, more more help or onboarding we're happy to help you and get on a call and walk you through it. But yeah. Okay, cool. Try playing com. Is there[00:35:40] Michaela: also a, Yeah, is there a video or something that we can look[00:35:44] Micha: at?Yes. The, the website and there's a video.[00:35:50] Michaela: Okay. I will link that so that people can go Yeah. And it will explain everything to them. Right. What about pricing? Whatever pricing? Yeah. You have already some idea around pricing. Yeah.[00:36:01] Micha: We've got some ideas on how to charge, but I think right now for us, it's important to get the product market fit, mm-hmm.and as such, you know, get, get the feedback. From these companies and these teams using the product. So we'll introduce pricing at a later stage. So for now it's, it's free to use, mm-hmm. . And you just give us your time and your feedback, and then Yeah, we're grateful.[00:36:20] Michaela: Yeah. And what about my data?Is it safe with you? Like, do you have some visibility into my data or do I send it over to[00:36:29] Micha: you? Yeah, so we actually so the way the, the providers work the plugins, so they actually get activated through a proxy. So we install a proxy inside of your cluster. The proxy sets up a secure bidirectional tunnel from your infrastructure to the fiber plane managed service.And then we do, for that specific query, we do store the data that's related to that query. So of a result, we do store that in the notebook. And yeah, we probably will come up with sort of more enterprisey ideas around how to self host[00:36:59] Michaela: it, Right? Or something[00:37:01] Micha: as an example. Yeah, yeah, yeah. But again, we'd love to get some feedback on that.[00:37:07] Michaela: How that works. Right? Yeah. Okay, cool. So yeah, that sounds really good. I think you, at least my questions, , you could answer them all, but maybe my listeners have questions and then they can send them to you. I think you will be, Yeah. Quite happy, right?[00:37:22] Micha: A hundred percent. At mes on Twitter, m i e s and at fiber, playing on Twitter, fiber playing.com.Sign up, take it for spin, shoot us a message. Yeah, sounds.[00:37:33] Michaela: Yeah. Yeah, it sounds super interesting. I hope that a lot of my listeners will do that, and I will link everything in my show notes that we, you know, talked about your, your Twitter handle and everything so that people can reach you. And I hope you get a lot of questions and people give it a spin and give it a try and send you their use cases,And yeah. I hope you all the best with your product. Thank you so much for being on my show today Micha. And yeah. Thank you. Bye.[00:37:59] Micha: Thank. Thank you for having me.[00:38:01] Michaela: Yeah, it was really great. Bye bye[00:38:04] Micha: bye.[00:38:06] Michaela: This was another episode of the Software Engineering Unlocked Podcast. If you enjoyed the episode, please help me spread the word about the podcast.Send episode to a friend via email, Twitter, LinkedIn. Well, whatever messaging system you use, or give it a positive review on your favorite podcasting platform such as Spotify or iTune. This would mean really a lot to me. So thank you for listening. Don't forget to subscribe and I will talk to you in two weeks.
Deeply caring for developer experience
[00:00:00] Michaela: Hello, and welcome to the Software Engineering Unlocked Podcast. I'm your host, Dr. McKayla, and today I have the pleasure to talk to Ashley Hansberger. Ashley is Director of Developer experience at Tackle io. But before I start, let me tell you about my latest project. Awesome cos.com. Yeah. All my work on Culture Views has now its own dedicated home at awesomecodereviews.com.You find articles about code review best practices code review checklists, news about the latest research on code reviews and of course workshops and courses I offer around this topic. So please hover over to awesomecodereviews.com and check out my latest work. But now back to Ashley.Ashley is a vivid speaker and proponent of testing, and she loves to share her experience in conferences during blogging, all about testing and engineering productivity.Before she was working at Tackle.io, she was the director of DevOps engineering at Black. So I'm super, super thrilled to pick her brain today and, you know, learn all about her experience. Welcome to the show Ashley.[00:01:08] Ashley: Thank you so much for having me. I'm, I'm so happy to be here. .[00:01:14] Michaela: Yeah. Yeah. I'm really, really happy.So I want to start really at the beginning. I know that you have been a tester at the start of your career. Yes. So how, how come that you're now, you know, the director of developer experience, how did you come into developer advocacy and so on, but what's, what's that[00:01:30] Ashley: path? , I'll try to give the short story, but it might become a long and winding journey, but that's okay.Yeah, I did start as a tester and, you know, went from manual testing and I'm not even gonna say how many years ago, because it feels like ages ago and it was, but that's okay. . So I started as a manual tester and as many companies go, you know, started to learn automation and really found a passion for leading that effort.So I went from tester test lead. Test architect into really becoming a technical product owner. How do I start advocating the voice of what is needed technically to balance against the features needed so that we can think about how do we design and create the frameworks and develop the automation that we need to get the feedback loops in place for our code?That kind of led me down to a path of really thinking about testing and continuous delivery and adopting DevOps principles of like flow and feedback and continuous learning and thinking about DevOps from a culture perspective. And once we had a reorg, I was asked to lead release engineering. Now that became a really interesting experience for me, not knowing a whole lot about release engineering, but being able to lead people and thinking about our infrastructure as code and how do we even test our infrastructure.And guiding a team of DevOps engineers to be able to do just that. As we develop a microservice oriented architecture, how do we create the, the easiest path forward for a team to spin up a service, develop what they need to, and not have to worry about the underlying architecture behind, behind the microservices that they need to create.So my team creates the Pav road at that point. But what I really found I was most passionate about was bringing people together, learning how to work together and really focusing on people and their experiences at work. I was also asked you, as you mentioned, I've been speaking in the industry a lot about testing.But what I really found it was about, at the heart of it, was how do we advocate for these ideas and the ways in which we should deliver software? So I was also asked to start thinking about how do we influence an organization through change for an idea that we wanna implement at, at that point, it was agile and how do we scale that across an organiz?So I got to start thinking about, well, how do we approach change as humans? And, you know, thinking about the, how our bodies and our minds react to change. How do we move through that change, whether it's positive or negative, we, we need to be able to move through it. And I started really getting interested in the psychology of change and how we do that and influence it through other people.But at the end of the day, we also have to be effective. And what makes effective. Psychological safety. And so I really started developing not just the, well, what are the things that we're trying to do as a team, but, but how do we do that? And what are the things that we need? And so I really got into a deep dive of looking at Amy Edmondson's work and psychological safety.How do we apply it and learn about our own teams through those mechanisms and start building the, the underpinnings of having an effective. At the end of the day, what I've decided after a lot of reflection was I'm most interested in our experiences as people in tech, because if we are not having a good experience, how can we truly be our best selves?And if we can't be our best selves, how can we produce something that is really meaningful in providing positive impact to others? At the end of. We might be able to, but it's not gonna be sustainable. So I've been studying on the side organizational psychology pursuing my master's in network.And I started developing a program around developer advocacy and thinking about our experiences at Blackboard. But through just luck and circumstance was asked to come implement what I've been building over at Tackle io. So I get the chance to start ground up with a fairly new company compared to my 17 years at at Blackboard.And just start from scratch. And it is so amazing to have the opportunity to build from the ground up with a team that is excited about this change, excited about how we can think about our experiences in a positive culture and sustain what we need through the growth of the company.[00:05:40] Michaela: Yeah, that's, I mean, it sounds amazing and I think that what strikes me the most when you describe everything is.At the heart, you're describing some internal. Focus, Right. Which, yes. Which I often see developer experience and advocacy and so on. And it's always outside focused. It's like we want our, you know, tool to be used by others. So and then, and then you have all these developer experience professionals and people and, and this focus.But again, it's a customer focus actually, right. and what you are talking about is exactly that. What I'm so interested in is the internal focus. So not how can we, you know, make a good experience for our customers, the developer , but how can we have a great experience for our internal developers? Yeah. You know, that are, that are making whatever, you know, it, it doesn't have to be the developer products.Again, it can be something, you know, completely, you know, let's say it's healthcare or yeah, it's, you know, whatever software you're actually producing. But how can we look internally that we have great experience and, and, and, and I think from that perspective, it's so natural that you're coming from the testing and DevOps side, right?Yeah. Because. There is always enough time to program. Well, because you have to. Right. So , you know this, they can't take it away. We have to somehow program, we have to code. Mm-hmm. . But there is not enough time for testing for DevOps, for pipelines, for ci, you know, for, for making sure that we have a good code base.We don't have technical debt. We have maybe, Good meetings. We have a good culture. We, you know, we understand each other. These are all the things that we can scrape away, you know, and just bare a minimum. Let's code . Yeah. And, and so I think, yeah. So when you describe it like this, it makes sense that you're, as a tester, arrive at a developer[00:07:39] Ashley: advocacy Yeah.Role. And think about it as, as a tester early and you know, at the heart of testing, we care about what is the user going to experience, Right? Mm. I got into testing because I cared so much about that user experience. Well, now my users are my, my engineers in the, in the whole program, internal, they are my clients.And it's not just about the code that's delivered or application that's created. You know, we think about these core experiences that make us effective and productive. And it's not just, did I deliver a. . It's the meaning behind that. Do we understand significance and meaningfulness in our work? Do we understand the positive impact we had?Do we have variety in the things that we do? That helps us, one, learn and grow first and foremost, but also keep us interested in what we wanna achieve. Yeah, do we have the ability to see it through start to finish? I can't tell you how many projects I started that I've just just ripped off of for somebody else to finish and not be able to see what happened with that.All of these things that affect like our, our wellbeing and our mental state as workers, you know, really helps drive that experience. And when we can have a good positive experience, we're more committed to our teams and our work and our companies. We become very much tied to the mission of what we want to do.And we're more likely to stay. So we see higher attrition, we see higher job satisfaction. These are all interconnected things that I'm so deeply fascinated by and want to help just make the best experience possible for anybody. Yeah,[00:09:16] Michaela: yeah, yeah. I did this study that you, read the paper about it, right?Last year. About developer experience and what, you know, what makes a good or a bad developer experience, what changes and so on. And we had these factors, right? Mm-hmm. . And I really like to do this, this study because exactly of the reasons you said, right? It's not only productivity, but it's wellbeing, it's, you know, retention.So there are so many good things that are coming out of a good developer experience. And what I also like, you know, from this experience is, Sometimes if you are in this tech bubble, right? Everybody's like, Oh, engineering is so great. But then we have to think, is it true? Right? Is it true that it's so great or is it just a lot of people are in it for the money, which I think is a.It's a fair reason to be in it for it. Right. But if you have a good experience, then suddenly it's not only the money why you are in tech, Right. It's also Oh yeah. Because you're having a good experience. And I think a person that's not only because you know of the paycheck and thinks, you know, apart from the paycheck, it's actually miserable here.they write different software than, you know, the person that says, Well, you. I'm in a, in a high paying industry, but what I'm doing, I'm really excited about. Right. I, I feel committed. I feel yeah, I'm proactive, you know, doing something. I can, you know share my ideas. I have colleagues that help me.This is very different things, and I, and I think those people that have a good experience in their work, they deliver a complete. It's game changing, you know, the, the kind of software Yeah. And product that they are delivering. I mean, that's, that's my experience. How do you see that?[00:10:52] Ashley: Mine too. You know, I've been on the, the teams that were, became feature factories ultimately, and that was that, don't worry about the experience of the people, just get these things out.I've been on teams that have really focused on the human aspect. Right. And it's just night and day experience. The, the difference is so vast in what drives somebody to want to, to deliver the best software. At the end of the day, I mean, I don't think nobody shows up and goes to work. I'm gonna deliver crap software, Right?No, but. It makes it so much easier when you know you have a team you can come in and talk with and ask for help and learn from each other and have clarity in what you're trying to achieve and the processes that help make this as easy as possible. I don't know if, if you've had this experience before, but one time I was learning to, to get my local build set up so I could write some, So write some automat.And to run it, it took me five days to get that first build going on, on my local machine because it was so convoluted and hard and at the end I just felt like I have created fire. But why should that be the experience that we have? Like it should be so easy. And what if we had a world in which your first line of code is delivered that first day that you join a company or join a team because we've made it so simple for you.To just get that build up, deliver your first line, and, and, and push it to pride. Like how, how delightful of an experience would that be if you can see that you're adding value from day one instead of six or eight or 12 or even longer weeks later, you know, from that first time that you joined that team.And I think when we can have those experiences, like from the ease of being able to do something to understanding to how we work and, and, and operate with a team. That just makes it so much happier, which matters on our wellbeing because we need that balance in life too. I mean, I've seen and I've experienced where I've brought a bad workday home and my kids notice, and I don't want that for them.Right? I want it to be, even if we've had hard problems, we can do hard things. It's not saying that this is gonna be easy, but I am gonna make it an enjoyable environment in which to. And have that safety to fail and celebrate those failures versus feeling like I got yelled at because I miss something as a tester and it made it into production rate.I've been yelled at. It, it hurts and you take that and you internalize it, and it might affect how you approach something again in the future or what to raise a risk in the future. And we need that for our own psychological wellbeing to be able to, to have that effective experience and become more productive over time.Yeah. Yeah,[00:13:44] Michaela: definitely. I think there are a couple of things that really resonate with me. So there are two things that you know, are quite different than I want to discuss. One is, Yeah. That you were talking about factors, Right. And I also describe factors in the paper. Mm-hmm. And some of those are technical, right?So for example, the CI pipeline or maybe also having this build go through, having you, this image set up. You can run actually the software, this is more a technical problem, but on the other hand, we also have the culture problem, which, you know, they're always fading into each other because if, you know, if the build doesn't really work, maybe can you reach out to another person?Will, you know somebody sit at your desk and help you? You know? Or will you get, you know, strange looks and maybe somebody comes over and say, Yeah, do this event is gone. And then you feel bad asking them again. Right. . So . Yeah, exactly right. So there. Technical and the social aspect of it. And I think, oh yeah, those are really important.What's your, what's your experience with that?[00:14:45] Ashley: Yes, so, so critical. I think if we don't have learning behaviors, and by that I mean am I on a team that is willing to learn from each other? Be able to have the practices in place to know when we need to go learn something and help each other learn.You probably have a variety of skill levels a variety of skill sets, you know, on your team, and so how can we leverage those from each other to build a cohesive unit as a working group and learn from each other? You have to have some social elements that you're taking account for. If I can't ask for help, I'm going to flounder and fail in in my, in my world.I remember my first time learning automation and I was getting stuck on writing some code for it. And you know, I think some of us have different drivers on do we feel comfortable asking for help? Do we need to be perfect? Do we just wanna please other people, right? Or do we just wanna get something done?But. If we listen to those drivers in a world, let's say, I'm afraid to ask for help. I don't wanna ask for help cause I don't wanna appear weak. What am I going to learn? How am I going to become a part of that team? And when I can ask for, for help from somebody that helps create a social bond with that person that makes us want to be able to continue to work for and with each other.And I think it's so critical that we create those, those relationships as well to help improve that experience. Yeah,[00:16:21] Michaela: so my question is also, Blackboard was a large organization, right? Or Yeah. Yeah. And now Tech Li o is smaller. You said what? What's[00:16:32] Ashley: smaller? Yes. What's smaller? So the company itself is 300.So Blackboard by the time I left, I was around 3000 people. Yeah. Okay. I go to tackle io 300 people total. So I went from an engineering department that was around 1200 to an engineering department that is right around 90 people right now. Okay. And that's what I actually, I love it. I didn't know what to expect.But what I'm finding is I have the time and the bandwidth to build a relationship with each person in engineering right now. Mm-hmm. . So my goal is to actually have a one-on-one with every single person in our department, which was not feasible at my last company, . Yeah. You will at least have met me, by the time we hit the end of October.So I finished my first quarter. My goal was to meet every single person engineering. But I love that because what it lets me do is create that, that touchpoint, that human connection with somebody, because not many people wanna just open up immediately and say, Here's all the things that would help my experience, Right?I don't jump in and say, Tell me all the things that are wrong so that we can go after and fix. I will eventually, but how do I create that trust? To me, it's more important to build that relationship, build the trust, so that when I do ask you, you know, I'm coming from a place of honesty and good intent.And really it's not about complaining. It's about what can I do to make your experience better, and how do you know that I'm the person that cares so deeply about. That you will trust me to help make this happen. And so that's really what I'm after. It's, it's kind of amazing in a way. So yeah,[00:18:12] Michaela: so we have this 300 and the 3000, and then there are companies in the size of three, right?Yeah. And I actually worked with, you know, a big range from them. Yep. Even at larger corporations. Right. With hundred thousand people, but. . I wonder sometimes, right, with, let's say Microsoft, for example, is really large organization and, and they have like their own department for developer experience, I mean mm-hmm.wasn't called developer experience, but it was, I was in this team, it was called Tools for software engineer team, or one ES one engineering systems team. So, but the focus is making engineering better for the internal developers, right? Mm-hmm. , it's a large endeavor because there are like 100,000 people and a large portion of that, let's say 40 or 50,000 R engineers, right?So mm-hmm. , but then you have like, as you. 3,303. And lately have a lot of experience with smaller companies, right? Let's say 20, let's say three, maybe 5, 10, 100. And what I also see is that especially the startups, They also don't value developer experience, , , you know, like then, then we are so small and everything is just a hustle and the grind.That there is no place for developer experience. I don't know if there is place for heart. Yeah. Later on, you know? And, and, and I always feel like if you can't, you know, if you can't focus on developer experience, if you're a three person team, or not only developer, even employee, you know? Mm-hmm.experience. If you are a three person startup or a five person startup, and you know, all those are after thoughts because now we have, you know Yeah. To get to the market and make money and, and, and, and, and later on we will think about, you know, how people. Mm-hmm. ,[00:20:01] Ashley: I think what I like, this will not work.It's interesting because, so tackle's my first startup and I was really, really intentional when I started you know, thinking about what is next on my journey. Mm-hmm. on a company that has, has proven that they value the employee experience. Mm-hmm. , and I'm not taking, you know, just engineering, but what impressed me about tackle is.From the start, they cared about wellbeing. It is in their values that they established as a beginning, at the beginning stages of their company. That, you know, we care about each other. That we worry about our wellbeing and our leadership reflects these values. And you know, if they see it not happening and they still do, tap me on the shoulder, say, Ashley, I saw you are on Slack sending a message at midnight.Why? Please don't do that. Or I thought you said you were on vacation. Why are you responding to a message? Things that I don't know that I ex I expected when I joined, but deeply appreciate that it is so ingrained in their culture to care about the experience and our wellbeing. So I was, I feel really fortunate to land where I did.But what I love is that, you know, they're about, we were on, on series Cs, so, you know, not, not super early for tackle. Not quite late stage yet, and. They saw the need as they scale and grow their department to worry about the developer experience and care deeply about it enough to create a new program.Mm-hmm. . So I was super excited, that, you know, I was selected to come in and help establish this program where, yeah, you don't hear about it too often in the small startup space. Because yeah, you gotta get, you gotta prove out your. Your value, right? You wanna make sure that you're hitting the market need as a early startup, you know?But how do we do that in a way that gives, it focuses on the care and feeding of our engineers who are going, who are, It's very easy to dive into just. Go work all day only and deliver this thing because we need to do this. Right? Yeah. But I love that, that that is not necessarily the case here.[00:22:16] Michaela: Yeah.Thankfully have forgotten a name of the company because otherwise, you know, I name in Shame, which I'm not the person for. I don't like naming. No, I don't. But anyway, No, I don't like that. So I have forgotten the name, , but there was a Twitter thread and, And this guy was, You know, come it work for me. We are like really hard problems.Really low pay . Yeah. You work all day? No, actually he didn't say low pay. I think he said. Competitive. So competitive vape, but you work, you know, day at night and evenings and whatnot. Right. Yeah. And, and if you like, free time, don't work for me and so on. Right. It was longest read and, and I, I read through it and I think it was meant a little bit sarcastic or fun, nor, I don't know exactly.But yeah, it was this, this hustle culture thing, Right. And I thought like, wow, I don't know.[00:23:05] Ashley: Yeah. It's how that like puts us off too, right? Yeah. Like if I read like incredibly passionate about delivering everything, it's like, of course I'm passionate. I wouldn't be applying if I weren't passionate about my role.However, Yeah. I internalize that. as, I need you to work all day and all night on this problem until it's out the door. Like, yeah, it's a, I'm just not, I'm too one. I'm too old for that. Two, I like to spend time with my family and my kids like, yeah, if I see something like that on a job posting or hear it described like that, it kind of turns me off in a little bit.Like, yeah, why am I not expected to have balance? Yeah. It was[00:23:43] Michaela: really like, if. Work life balance for you means to have a lot of free time. This is not for you, right, . I'm like, well, what else[00:23:53] Ashley: should it mean? This is about the biggest red flag I ever heard. Yeah, Yeah.[00:23:57] Michaela: But but, but, but I wasn, but I'm wondering.Right. And it was all under this umbrella of all we startup, right? And, and so you have to be super passionate about, and so but I wonder if you can get rid this DNA or if you can strive it off at one point, Right? If could say, Oh, now we are this 10 person and we don't make it enough revenue. And so we hired all these people that have this mindset of, you know, Working day at night and, and whatnot.Mm-hmm. and so on. And then at one point we transform into this developer friendly, employee friendly entity. I, I, I can't imagine, Right?[00:24:32] Ashley: I, I, yeah. I think it's possible. I think you have to assess, you know, there's, there's things that you can look at. If I put on my organizational psychology hat, right, , you can look at the current culture mm-hmm.And what it is, and you can look at desired culture. Mm-hmm. and it, it could take a very heavy lift and a lot of time to get to that desired culture. But I think it's feasible if you understand where you're starting from, where the desired end state is, and then start putting an action plan in place to get there.So let's say you are in a sales driven culture, right? Yeah. Sale, sell, sell. And it basically informs what your engineering backlog is. It's kind of a dangerous and scary spot to be as well, because what if they, they sell something that you haven't yet built and they promise it to somebody. That's a really high stress environment, right?But what if you want to move to a more collaborative and generative environment or culture? Okay, cool. How do we now set the the things in place with sales, communicate to them, This is how we wanna start doing things. and then start working with them. Well, what, how, how can we do this? Right? How can we meet in the middle so that you're still able to sell something?Because of course they have targets at the end of the day. But how can we get to a place that is healthy for everybody? Maybe let's sell what's there, not what is in the future. Something can always go wrong, right? And what are the steps we need to take as an organization to support that and start transitioning to a more collaborative and communicative culture.From that, or maybe you have a very hierarchical driven culture. Everything is top down. It's very bureaucratic. I think that you can also set in place the ways to move along this dimension of, of what is more collaborative in nature, more organic feeling than a very, I like to call it the, like 1990s, early two thousands management style.But I've seen us transform. It took years, but we've done it right. Like I had no problem at Blackboard at the time talking to the CEO if I just wanted to talk about something with him. Whereas earlier in my career, it was very, very difficult to get that call with the CEO to just have a chat or something.You know? It just depends on what that. Yeah,[00:26:50] Michaela: maybe there's a, a German saying, I don't think maybe you can tell me if there's a English version of it. I just translated literally so it, it doesn't sound very nice, but , the fish starts to think at the head. , Do you have something like this? ? I don't think[00:27:10] Ashley: we[00:27:10] Michaela: do , but what it means is that leadership somehow sets the stage, right?Oh yeah. For the company and for the culture. And, and so what you describe is, Yeah. Is so I, I've seen two. Right? When I joined Microsoft, it was still Bama. Yeah. And it was an extreme different culture and organization you know, than you know, when it changed and, and it was transformative, right?[00:27:38] Ashley: Yeah. I was, It takes adaptive leadership to be able to drive that type of change. It takes transformative leadership. Yeah. I would say the closest that, that I think I've heard, Well, it was funny, I was just watching, remember The Titans with my children last night? Yeah. I don't know if you've seen that.But it's about a team that comes together you know, at, in a point of United States history where we're, we're integrating schools and a football team forms. And one of the saying that always sticks out to me is attitude reflects leadership. Mm-hmm. , And I always take that with me because as a leader, my, my own attitude is going to be mirrored back to me from the people that work with me or for.And I always try to make sure that I am leading in a way that I can stand by and that I want my team to, to. You know that they have the best attitude and ability to move forward. But yeah, you, you have to have to make that change. It, it's leadership style, right? Yeah. You, you have to be able to work with others and collaborate.Rarely is it gonna be a top down decision making driven thing that's gonna drive change. It's gotta come bottom up. It's gotta come top down and sideways to be able to communicate all the things and work together. , you have to have a clear vision. You have to be able to, to guide. You might not have all the answers as that leader, but you sure can ask questions to get there,Yeah. And help the team through that and navigate through that change cuz ch change, like I said, it can be a change for the better. But it is hard, , whatever we deal. Yeah. It's[00:29:07] Michaela: extremely hard. Yeah, that's true. I mean, I'm working with people on culture views, right? So very focused. At Microsoft I worked at many different aspects of developer experience, like the, the, the cycle testing and so on.For my workshops right now, I'm really focusing on culture views. Mm-hmm. And so it's, it's one area. And in my workshop we are going to. Code reviews, right? And the code review processes that people have and thinking about, you know, how can we make the experience better and. and it's hard, right? Yeah.Even though it's a small thing, you know? Yeah. You would say, well, you know, it, it's even at the fingertips of developers. But still, it's really hard because it's a team practice, right? It is. So you have to have more people on the team really be willing and committed to make the change. But then if they do it, if they are committed, I mean, it, it takes wonders, right?It, it, it's really different experience. It's, yeah, it's[00:30:00] Ashley: huge. It's, it's not, and it's not just the, the timing of the code review. Cause I've also, you know, part of the experience is how fast am I getting my feedback? Yeah. So that I can make the changes I need to, and, you know, get it through, it's what is said in these code reviews.Yeah. I remember I like, I was so blocked when I was first learning, I got one of the meanest comments ever , like on a code review. Somebody I guess didn't realize it. It was like one of my first prs and just like, Why would you do it this way? And I can't believe what I was like, Okay, I think I'm just gonna not automate anything ever again or write code ever again.It's fine. . Yeah. So you have to think about the experience there, right? Like. What is that, that holistic view, not just the timing and how many people are able to do a code review, but what is the content? What is the meaning behind it? Are you actually teaching and coming from a place of learning and growth versus maybe we had a bad day kind of getting snippy with people, or I just wanna get through this code review because I have a lot on my.It just depends. Right? But I think you need to take that whole view. Yeah. Of what is that, that whole experience. And[00:31:09] Michaela: I actually like culture views so much because very similar to, you know, developer experience. I would say the developer experience is like the big umbrella, right? Mm-hmm. . And then culture views is one aspect of it, but it's an interesting aspect because it has.It's a technical sociotechnical engineering practice, right? So you have the social aspects, you have the technical aspects, so you have to be technical words as well. And then you all have as the third organizational aspect. So in this little practice, you actually have all three. Most important skill sets in there.Oh yeah. Right. And I think this is what makes it so fascinating. Yeah. So I want to come back a little bit to the paper that I wrote with Avi Notre and Margaret and story. Right. It's called, How is it called? Let me see. To level an actually framework for developer for improving and understanding developer experience, Right?I think this was the title that we settled on. And so the paper is really, so we made an in depth study really on what's important for developers, what's impacting their experience, right? For the good and for the bad. And so we made the list of several factors. So this was a qualitative study. So a couple of themes.We did interviews, a couple of themes emerged, right? And some of them were really the factors. But then it was also what's hindering developer experience. How do people compensate, you know, their negative experience and so on. And you, you read the paper, what, you know, what was interesting for you and was there something in it that you could actually take And You know, and apply maybe in your job.Yeah. As developer experience director.[00:32:47] Ashley: Yeah. It's, it's, it's when I came across the paper so how I was approached my job was can you take the things that you were learning from organizational psychology and apply them to engineering? That's, Yes I can. Let's talk . And so I do, you know, I try to do a little bit of research each morning, what's going on in the field, what are people other people finding?Cuz it's still fairly new-ish compared to other topics in our field. Right. And when I came across the research paper, I was so excited on a few fronts. One. That okay for you? Yes, I am new to like doing research and graduate level work, but I was really happy that my methods are very similarly aligned with your research methods.Granted it's within my company, but very, But you know, let's have the qualitative interviews. Let's understand. Let's find the themes. I had started theming my things out. Mm-hmm. then I was really happy that my themes were aligning with the themes that you also had been outlining. That's. You know, different words, but ultimately very similar structure.Things that we're, we're looking at and hearing from people. But what really fascinated me and what I loved is that holistically looking at the paper, , all of these aligned to things in, in organizational psychology. From where do we find fulfillment and job satisfaction? You know, the importance of having clarity in our goals how we work with product.Sure. We're not gonna be talking about how do we work with product managers and organizational psychology, but we are gonna talk about how do we understand our significance? Where do we fit in this universe? Do we understand how we provide value? Do we understand the positive impact we have? Are we able to work iteratively?Are we able to do feedback loops? Everything in software development in the world of psychology is an I P O model or input process. Output model that is just super cyclical. That's all we, I look at these diagrams all day long. That's DevOps, That's testing, that's like software development life cycle, right?Thinking about our tooling when we look at your development and release theme, right? All of those questions we look at the environment, the health of my code, how confident am I all of those things come down to our experiences that we can generalize into. Or if I like to think I like how can I apply it into organizational psychology terms?Cause I like to write about it in, in my classes. But I was so excited to think, okay, I think I feel like I am home. I'm studying the thing I'm passionate about. I feel like I'm a scientist, practitioner can go forth and do these things. I even like, how do we notice when people aren't feeling these things?How do we notice when people are having a bad experience? I thought that was such a critical part of the paper that's not often talked about. I think, you know, we, we all say, Oh yeah, we should do this based on my experience. But what I really enjoyed was reading, you know, What are the, what are those implications?What should we look for as leaders? How might people be coping if in the absence of these factors? And those should start to give us some, some red flags there if we're not careful, what we might lose people or worse, not be able to revalue at the end of the day. Yeah. I mean, worse to me is losing people and having somebody have a horrible experience and, and be turned off from tech because I almost quit tech.Right. I don't wanna lose that, but are we going to be able to meet organizational goals without looking at developer experience? I'm not convinced we can. Because we're building the thing the organization exists to deliver. And if we don't focus on that experience, you know, what are the implications not just for our teams and the people, but for the company as a whole?And, and your paper is just so, so good, and I can't wait to dive in more for further research on my own, even if it's within my teams. But I, I. I just think it's such an opportunity for growth for us to discuss as a community, for us to think about not just what are our personal experiences, but what does science and psych and psychology and organizational psychological research tell us?That can be applied here too, for even deeper interventions. And in looking at that,[00:36:47] Michaela: yeah, this sounds really inspirational. So one of the, the last questions that I have for you is for my listeners, if they want to improve developer experience and. Companies, what would you suggest them? What's, you know, what are some of the things that we should tackle first?Is there some factors that are more important than others? Is there something that you can say in general, you know, this is a good, you know, this is a good investment Yeah. Of your time and money.[00:37:16] Ashley: Yes. So I don't necessarily think you have to go have a separate developer experience program to be effective.But I do think there are a few aspects. If you want to show quick wins, you know, what are the things that might be high pain points, low effort, and just start doing You know, I somebody once said, Be the change. You want to see , so how can I do that? , maybe it is, Oh, I need to talk to my team about psychological safety and, and run this workshop with them.Maybe I want to make sure that we are clear on how we write stories so that my team has a clear understanding of what work they need to do and why, but also how do we go in and break that work? What are some short term wins that we can find to build trust that people see that we are effective to then get more and more complex over time.And so I think, you know, some things are really hard and gnarly and take very spec specific skill sets to do and implement. Those are great, Put them on a roadmap, but think about what are the short, fastest things I can do that will be even a quick, easy win for my team, Make their lives easier, provide value at the end of the day and maybe not such a heavy lift on maybe one person.And then maybe start to show more and more of those as you grow, and then be able to get the buy-in to build the team that can solely focus. .[00:38:40] Michaela: Yeah. Yeah. Sometimes it's really hard to get the buy in. Right? So, so hard. . Yeah. . Is there something that you can recommend? Like how do we, how, how do we, you know, translate or make sure that other people not in engineering understand the value of developer experience?What's your pitch? I mean, there's the, the metaphor for a technical depth, right? Where Yeah. Are we talking about that? To, you know how you, Nobody cares about that on Yeah, exactly. , but how. How can we, I think developer experience is even more complex, right? Because people at least care about the software.So technically that even though it's hard, it's a hard sell, I think or hard sell. At least it's about the software developer experience is even about the people, right? It's even more. Fussy and so on. How? How can we make sure people understand the value of it? How would you explain it to management or to C level[00:39:36] Ashley: that happy.Happy engineers. Happy clients. Right. If you look, focus on the happiness and experience of your teams, at the end of the day, you should have happy clients because we are able to, The things that we think our clients value and see value in just ev all the more effectively. So I think if you can sum it down without having to talk about all the technical aspects.Right. What would your slogan be? Mine is always, usually people first off or second. However, when I think about in terms of providing the value to sea level, happy engineers, happy developers, happy clients. Yeah. You know, it, it shows, right, the, there's this, there's a saying or analogy here in the us. A happy cow makes better milkOh yeah. Really? . If they're grazing, they're eating. You know, good food, they're ate, getting access to grass, the milk quality goes up. They're not stressed. It's funny how even or if you're a human, like think about the stress and the effect of stress on our bodies biologically. And physiologically, you can still maybe perform the actions you need to do, but at the end of the day, your, your blood pressure might be up.If we don't have that, that stressors on our engineering teams think about the quality that they might be able to deliver in a sustainable way, in a way that makes them excited to stay at the company and want us to be there day in, day out, and excited to get up and go to work and work with their team.I[00:41:06] Michaela: don't think that there is a specific developer research exactly on this topic, but I know that there is quite a lot of employee research, right? Mm-hmm. So employee experience, which is a. , it's a topic on its own, and it's a little bit older than developer experience, right? Mm-hmm.So we borrowed a lot ideas and concepts from, from that field actually. Mm-hmm. , and they show exactly that, right? They, they show with case studies and with different studies that companies that are valuing, right? The experience of their employees in general. Yeah, those can also value the customers and that they're much more successful doing that.Yeah, so I will probably put some some of that in the show notes as well. So if people want to deep dive, they can.[00:41:55] Ashley: Yeah. Yeah, yeah, yeah. It all, it all comes down to like, you know, science and research that's been done, you know, many years over. We're just looking at a specific application of it Exactly. In tech, and it's fascinating to see how you can, how it's been generalized for more fields than just our industry.Right. But when we can take a look back, And see, Oh yeah, Oldham's job characteristics theory is actually super applicable to us. For example, like thinking about five dimensions of, of our jobs and what are the critical psychological states that emerge from being able to have positive experiences in those, those five characteristics.And then what are the outputs that we see, right? Retention, higher value, happy client, all of these things, higher productivity. All the things we care about in, in engineering that you know, it's just amusing to me to reflect back and like, Oh my gosh, this, this research was done in the 80, 1980s, like yeah, so many years ago and still applies to what we do.That's true and I love it. Yeah.[00:42:57] Michaela: Yeah. Yeah. So, cool. Well, thank you so much Ashley, for, for sharing everything today with me and I will put everything that we talked about in the show notes and obviously thank you. We'll also link your, your profile. Is there something as a last message that you want to give to my listeners?[00:43:17] Ashley: Oh, . Sure. Let's see. You know, it.always put the people first. I think when in doubt, I've never seen it fail me as a leader. Yeah. Think about, you know, your wellbeing, your team's wellbeing. If you can put that first, I really feel like the rest will fall into place. And even though those other aspects might be really challenging, Because you come from a people first mindset, it makes it so much easier to tackle those challenges together.Yeah.[00:43:54] Michaela: That's a really good closing note, and I totally agree. So thank you, Ashley, for being on my show. It was really a pleasure talking to you.[00:44:02] Ashley: Thanks for having me. Yeah, thank you so[00:44:04] Michaela: much. Yeah, bye bye. Bye. Hi, this was another episode of the Software Engineering Unlocked Podcast. If you enjoyed the episode, please help me spread the word about the podcast.Send episode to a friend via email, Twitter, LinkedIn. Well, whatever messaging system you use, or give it a positive review on your favorite podcasting platform such as Spotify or iTunes, this would mean really a lot to me. So thank you for listening. Don't forget to subscribe and I will talk to you in two weeks.Bye.
Making security easier for developers
Book your awesomecodereview.com workshop!Links:Harshit’s LinkedinThe voice of the modern developerTromozoSubscribe on iTunes, Spotify, Google, Deezer, or via RSS.
Being an engineering manager wasn't for me
Book your awesomecodereview.com workshop!Links:Nicolas TwitterNicolas’ blog post: about stepping back as an engineering manager to be an individual contributor againThe engineering manager pendulumSubscribe on iTunes, Spotify, Google, Deezer, or via RSS.
Mentoring as an engineering manager
Today’s episode is sponsored by Mergify, the faster and safer way to merge your code.[00:01 - 06:24] Opening Segment Start saving time by automatizing your pull requests and securing the code merge using Mergify!Sign up for a demo at https://mergify.com/Get to know Jess Roseher reasons for her helping strangers on the Internet[06:25 - 11:59] Bottom-Up Communication Vs. Top-Down ManagementThe challenges of upward communicationHow to balance personal values at workIt’s unique for individual circumstanceManaging the conflict of interest as a manager to upper management[21:00 - 33:33] Level Up Your LearningWhy Jess’ started an online learning programIn search of the best tool for virtual and distance learningThe impact of tools on the quality of learningMentorship and organizational rankEstablishing healthy boundariesResilience in an educational setting[33:34 - 44:46] Let’s Start Speaking The Same LanguageAcing the basics: Why learning the fundamentals is everythingLet’s talk about programming languageHow to improve team communication and having a shared language[44:46 - 49:55] Closing SegmentDr. McKayla talks about her book in progress and her advice to those who would like to write a bookFinal wordsTweetable Quotes“Sometimes changing jobs is easier than making peace with uneasy ethical decisions.” - Jess Rose“Nobody tells you, but you're not going to start managing people and get it right right away.” - Jess Rose“We learn better when we're chill.” - Jess Rose“I think it's really valuable to talk about the culture of the language we use around programming and really the culture of the structures we build because it's not transparent to people.” - Jess RoseConnect with Jess Rose on LinkedIn, Twitter, and her website. Go to Github.com/JessicaRose to check out her 1-1s.Resources MentionedMergify - Sign up for a demo now!freeCodeCampClass CentralWeaving the Web by Tim Berners-LeeThe Intuitive Programmer: Learning How to Learn for Programmers (Barbara Oakley & Zach Caceres)Software Engineering Unlocked Episode with Dr. Cat HicksFelienne HermansDan AbramovLet’s Connect! You can connect with me, Dr. McKayla on Instagram, Twitter and Youtube to look into engineering software, and learn from experienced developers and thought leaders from around the world about how they develop software!LEAVE A REVIEW + help someone who wants to know more about the engineering software world. Your ratings and reviews help get the podcast in front of new listeners. _______Transcription[00:00:00] Dr. McKayla Hello, and welcome to the Software Engineering Unlocked podcast. I'm your host, Dr. Mckayla and today I have the pleasure to talk to Jess Rose. Jess is a technology professional and keynote speaker specializing in community building outreach and developing better processes for talented technology. She is passionate about fostering more equal access to technical education, and digital spaces. But before I start, let me tell you about an amazing startup that is sponsoring today's episode Mergify. You know, I'm all about code reviews and pull requests. Having your teammates review your code can be super beneficial, but it also can create a bottleneck and slow down your software development. With Mergify, your team can be way more productive with GitHub. Mergify automates all about merging pull requests, you can specify the merge conditions, and Mergify will take care of the rest. Do you want a specific order for merging the pull requests? Should one PR be prioritized? Or do you need a copy of the PR and another branch for bug fixing? No problem. Mergify can take care of all those situations. By saving time, you and your team can focus on projects that matter. Mergify integrates completely with GitHub and your CI pipeline. They have a startup program that could give your company a 12-month credit up to $21,000 of value. Start saving time, visit Mergify.com to sign up for a demo and get started or just click the link in the show notes. I'm super, super thrilled to have Jess here with me. Jess, welcome to the show.[00:01:38] Jess Rose Oh, gosh. And I'm absolutely delighted to be here when you said hey, do you want to come and talk about teaching and learning? Oh, I'm just going to be insufferable. Thank you so much. [00:01:48] Dr. McKayla I'm really excited because I'm following you on Twitter. And I see that you're creating spaces for people to learn to get better to grow. Right. So there are a couple of things that I want to touch base on today with you. One is the 1-1s that you're offering. So maybe, maybe let's get started with that. Because I see you from time to time you say, you know, I have some time available, why not hop over on a call, and I can help you with some career advice? How's it going? What do you do with people? What kind of people are picking up on that?[00:02:27] Jess Rose So I've been doing this for about, I looked the other day because I do, I do keep records and privacy-preserving records just like, oh, what kinds of things am I talking to people about? And I've been doing this for about eight years now. So just broke 1700 folks I've talked to over the years.[00:02:40] Dr. McKayla Wow. [00:02:40] Jess Rose And you would think oh, it's going to be mostly juniors or mostly people trying to break into tech. But just the absolute vastness of experience is so dazzling and exciting and strange to me. I don't see myself as especially well suited to give great advice. But on these calls, people are almost never asking for actual advice. So a lot, most of it's just, I'd like to be heard and I'd like someone to confirm that my experience is unusual or isn't unusual. Or getting sort of a level check for a different area saying, Hey, I'm based in this region, and I'm looking for work in your region. What's that like? What's the experience like? What's the process like? I actually documented the whole process out because I want, I definitely want other people to be doing this if you feel like it. No pressure. And it's on my GitHub. So GitHub.com/JessicaRose. And it should be right on there as 1-1s.[00:03:37] Dr. McKayla Yeah, I saw that. I saw that on your Twitter feed. So it tells us how to do those 1-1s and how to, what questions to ask, and so on?[00:03:46] Jess Rose Yeah. And mostly just about the tooling. So how to get it scheduled, how to get that sorted? And then because I'm a weirdo, how to get the records of who chatted to you deleted if you want to, like, yeah, I wouldn't keep notes on somebody who doesn't want me to keep notes. [00:04:00] Dr. McKayla Yeah. And I think it's good for privacy as well, right?. If people I don't know which topics, they are coming to you, but I mean, some of them might be private, and you know, especially if you're having maybe, like, I think if you need advice, you're very often not such a good place, right? Probably more than being in a great place where you think, well, everything figured out, you know, things are going smooth than you're seldomly reaching out to other people. It would be like I'm bragging now to you. You're more probably reaching out if you have some problems with your team maybe or getting a job or something like this. Is that what people talk to you about in the sessions?[00:04:41] Jess Rose So anything from, Hey, am I getting paid right? To, Oh, I'm getting screamed at a lot at work. Is this normal? So a lot of them are sort of, oh, gosh, but a lot of times folks just want to explore what's going on next. I've managed people a lot in my career. And one of the things that I always, I always have a difficult time with, and I hope other managers do, too, is how do you deal with the conflict? And there's always going to be conflict between what's best to the individual person you're managing, and what's best for the company because those are those, And one of the big things I push when I do manage people is, hey, do you have someone external to the company to give you good advice when I can't? Or I shouldn't give you the advice that's best for you?[00:05:31] Dr. McKayla Yeah, yeah, it's a conflict, right? Because obviously, you don't want to lose that person. But you see that they're outgrowing, you know, maybe the position?[00:05:42] Jess Rose Oh, I really just want to chase this up a minute. I'm always like, you don't want to lose somebody, like, you don't want somebody to move on for your team because they were unhappy or mistreated. This is definitely from me being a teacher for too long. I'm always pretty excited when somebody graduates up out of a team I run. Like, of course, you want to make sure that people have space to grow, of course, you want to be actively making sure there's career progression and more things to learn. But and especially in a job market, like right now, sometimes people like oh, cool, I could make a bigger salary jump bracket, they could make your title jump by leaving. And I'm always pretty chill with that.[00:06:24] Dr. McKayla Yeah, yeah. Me too. And my husband is also managing a bunch of people. And but I see tension there, right? So I think he's always really behind the people. But then upper management would be, yeah, but you know.[00:06:38] Jess Rose The business case for retention.[00:06:40] Dr. McKayla Exactly. Right. And the same for, for example, giving your raise, right. And I think, especially maybe the managers, you know, that are really like first line, they are more for the people because they have like some personal relationship, and then one level up, it's already like, yeah, but you know, we don't have the budget or we don't want or we believe we can still keep that person, you know, for this for this cheaper?[00:06:38] Jess Rose Oh, well, you know, let's give it another quarter or two and wait and see.[00:07:08] Dr. McKayla Yeah, exactly, right?[00:07:10] Jess Rose Baffling.[00:07:11] Dr. McKayla how do you do that as a manager? How do you speak up for your, for your people, or for your team? And h ow do you deal with that conflict as well?[00:07:22] Jess Rose So I think that's a really challenging one because I think that the conflict there is still the same. What do you do as an individual manager when the y eah, when your contractual, your fiduciary duties to your company, run counter to your individual ethical responsibilities to the people you manage? And or what happens when there's a conflict between the needs of an individual and the needs of a team? And it's not a good answer. And it's not a reassuring answer. But it depends. If somebody is facing treatment that feels unfair, or targeted, or they're in a position that I, generally, if somebody is in a position, I'm not okay, with being much more lovingly strident around, hey, this is a topic I would really bring to your external mentor A well, and then setting really clear limits internally about what, even as a manager, you are and aren't willing to do. So somebody saying, Oh, you get the idea that, Oh, maybe we want to manage so and so out, go ahead and write them up for stuff that the rest of the team routinely does. You still have consent as a manager. So you could say, like, yeah, no, I won't work in a space that involves maybe this kind of behavior.[00:08:45] Dr. McKayla Yeah, yeah, I think this is really important that we are standing up for our own ethics and for our own beliefs and value and, you know, also behind our, you know, our people that we, you know, I think we have a responsibility as well for and yeah, so I yeah, I can totally see that. [00:09:05] Jess Rose It's easy to say in this kind of job market in the West as well. I think, a re you based perhaps in Europe as well? [00:09:12] Dr. McKaylaYes. Yeah. [00:09:13] Jess Rose Because, like, these days for many European job markets in tech, finding a new job feels to many people who are established for juniors or people getting your first job, It is hard. But for folks who've been in for a little while, and folks in different in high demand areas, getting a new job as a junior as a middleweight, or a senior, is not as difficult as it could be these days. Whereas if you're having to engage in management behavior that you're just not comfortable with, yeah, sometimes changing jobs is easier than making peace with uneasy ethical decisions. Yeah, sometimes that's not true for everybody. And it's a very, very privileged take for those of us who have a little bit of wiggle room.[00:09:58] Dr. McKayla Yeah, I think so. And it really depends on where are you located? And what is your personal situation, right? Do you have dependents? Do you have like family or people that you have to take care of? And so on, which I think makes it much harder to say, you know, I'm going to not do that. But I think there, you know, there are boundaries, it's, it's one thing is playing along, and just, you know, or letting the other person also, you know, know, in the space that you have, right? You’re also like, as a manager, you also, you can't just go and, you know, give advice directly conflicting with the interests of your upper management because that, you know, is a problem, but you can, you know, talk a little bit about, as you said, maybe asking you an external person, or also I think very well, you can say I'm disagreeing with this decision, right? And I advocated for you, unfortunately, you know, these were my boundaries here, for example, and let them know, I think that's, that's perfectly fine. Yeah. And I think that the problem is that if more of those things come together, people start thinking about leaving, right?[00:11:06] Jess Rose And that’s not always a bad thing. As a manager, if you're not able to offer someone, a place that is safe, and productive, and non-traumatic to work, yeah, it's okay, that your people move on, and actually kind of preferable?[00:11:22] Dr. McKayla Yeah, yeah, I think so, too. So another topic that I wanted to talk with you about, and it's a little bit related to management, but it's more related to teaching. So I don't think you have to be a manager to teach, right? You can be, you can be, you know, Junior Dev, Mid Dev, senior Dev, right, so we can all learn from each other. But I really see you as a teaching, you know, expert here. Yeah. Because you're, you're bringing topics around programming, but also, you know, advice for hiring or you know, how to get hired. And to so many people, right, you're, you're also making these really mass, mass online learning events, right, occur online boot camps. So how is that going? Why did you start that and is that only for really junior people?[00:12:12] Jess Rose So the first thing I want to do is like, I would absolutely love if there was an excuse for me, Oh, yes, I'll just take all the credit. But the free online boot camps that I've started are absolutely not just me. So they started as 12-week boot camps, and they've been collapsed into a reasonably intense but still part-time, six-week boot camp. And this is built off of the freeCodeCamp curriculum. So they're a registered nonprofit. They're amazing. We could not do this without them and without their permission. But also the good people, I’m pointing behind me like they're back there. The good people Class Central built a whole platform that lets us teach on so like, just really, and Ramon is my, my co-teacher. And he's he's just, it’s almost disgusting how lovely he is. Like, the learners love him and deservedly so.[00:13:03] Dr. McKayla Cool. Yeah. So what do you teach there? Is it like really the 101 of programming? Or is it more advanced concepts? Who is your target audience here?[00:13:14] Jess Rose So this last cohort, which just ended about two weeks ago, I should get back to work on those. We had 15,000 unique learners across two tracks learning either web development, which is HTML, CSS, accessibility, really, really intro level of like first steps of programming, or across JavaScript. And again, that sort of first steps with JavaScript, getting started. So really sort of introductory level. But we added some additional forums for peer support. We've got a very noisy Discord. And then some live stream lessons and question-answer to get people unstuck. We've had such a, so I would have expected oh, these will be beginners. We have back-end devs who wanted to try out web development. We've got folks who don't want to go into tech, but they do want to build a website for their business. And the thing I was, I used to be a teacher and I used to be a linguist. And very selfishly, the thing I was, one of the things I was most excited about was the absolute range of the learners. We've got folks across every regularly inhabited continent. And folks joining us in this massive exciting range of first languages. I was just so, so people who are learning from their phones, people who are learning from the library computers, and I just really really loved this loud, chaotic, and so lovely and so supportive group of learners all helping each other out.[00:14:49] Dr. McKayla Yeah, that's, that's really exciting. So I actually was thinking a little bit about learning on devices that are not high-end, right. And when I, when I started university, I couldn't afford a really high-end computer not even a normal computer, right? So I was on this, I got, I got one of those really cheap computers from somebody that you know, gave it to me for free. And it was a nightmare. It was a nightmare to work on that. And nowadays, it's obviously not the case anymore. And I'm really happy about that. But I was wondering what about, you know, people that don't want to work on the phone or work to, you know, on a tablet, and I'm pregnant right now. [00:15:32] Jess Rose Oh, congratulations. How exciting, how scary. [00:15:36] Dr. McKayla Yeah. But it's also a really cool experience because I'm thinking, like, this is my third child. So I know a little bit.[00:15:45] Jess Rose Oh, you're just fine. You're like, duh, this happens.[00:15:46] Dr. McKayla I know what's going to happen, that I can sit here and you know, work on my comfortable devices. And so I tried a little bit to work on my phone and work on the tablet and so on, I still think it's really difficult. What tools do your learners have?[00:16:03] Jess Rose Did somebody, somebody did one of my friends talk to you about this? I'm deeply suspicious. So I'm going to try really carefully not to say too much. I’m working on a little side project around this problem. Because this is a problem I've been thinking about a lot. So right now, and if our dear listeners aren't your viewers are, oh, gosh, what's the noun? Our beloved audience, your beloved audience has a tool or has something in the space that I haven't seen yet, please come and yell at me. But right now, I'm not seeing really good tooling. I'm not seeing a good way to write to the web from mobile devices. [00:16:46] Dr. McKayla Yeah, it's not there. [00:16:47] Jess Rose And this is an ethical problem for me. Because right now we hear people talking about the next billion users, I love this. But in a lot of cases, we're seeing people who are accessing the web for the first time, and I love it, and I live for it. But they're accessing the web on a lot of constraints. So they're usually on phones, they're usually mobile-only is what we'll call those kinds of learners. They may be accessing it in their third or fourth language, because you're going to see global web primarily in English and French and Spanish. And they're often constrained to really, really challenging limits on their, like their actual access to broadband or to mobile signal. And that's something I've been thinking about a lot on the device level for this problem. If I went, I'm going to date myself terribly. But I got access to the internet, when I was maybe 13, or 14. And the device I use to access the web to read the web, I could also write to the web. And we're effectively giving people this right only access to the web through smartphones. And that just, that doesn't seem like enough to me. So there's nothing great yet. And I don't think I've necessarily cracked it myself. But in the next couple of months, I would like to, I've got a little thing I'd like to launch to see whether or not that might be a good tool.[00:18:10] Dr. McKayla Yeah. Cool. I would be super interested in that. And I also think like, nowadays, I'm actually, I should actually be the whole day on bed rest. But two weeks ago…[00:18:20] Jess Rose What are you doing? You should be doing this lounging.[00:18:23] Dr. McKayla Yeah, I should. Right, yeah. But so now I'm allowed to be up a couple of hours per day, which is, which is great, but because I'm on this bed rest, right, and I only can lie down, I'm not allowed to sit actually, I experienced all these accessibility problems that, you know, couple of, you know, disabled folks also are experiencing and I'm like, right now, I really understand how difficult it is if you can't, you know, type, write, if you have like these mobile devices. And I think there is really there isn't a lot of you know, there's so much space in there. And we should really be much more welcoming to people that can't, you know, sit on this nice computer have their three monitors, right, the keyboard and the mouse. And it's really I mean, it's really frustrating for me to write a blog post to make an update on Git, right, to make a PR.[00:19:12] Jess RoseI'm not ignoring you. I'm just grabbing a book to see, so rude, isn't it? Turning away? Oh, heck, I must have hidden it somewhere. But there's a really fantastic book from the late 90s that Tim Berners Lee wrote about the process of inventing the web. But I've got sort of a tab in the book because he said, Oh, okay, we had to sit down we had to define the bare minimum. What is the minimum viable setup you need to access the web? He said, Oh, you need to, you need some kind of CPU, we need some kind of monitor some kind of display. And one of the things that they specified as necessary for the web was, you're going to need a keyboard. I think that's the point that sticks me again and again, where I think, but we've gotten past the need for keyboard in so many other spaces. Yeah, it seems a bit lazy to have not gotten past it in sort of the ability to do simple web development.[00:20:12] Dr. McKayla Yeah, yeah, it would be so great. Like, I would benefit so much from it. [00:20:17] Jess Rose Oh, just the guilt I've got right now. I'm just like, yes, yes, I'll get back to work. But we do currently have learned, well, in the last cohort, we had a number of learners who were accessing the course, all via smartphones. So they would post and we'd love to see them post, screenshots of their code to see, hey, where's this gone wrong, but it's going to be folks screenshotting their phone screen, and just the implication of how challenging it would be to write, I've tried it to write a bunch of CSS on your phone, oh, the absolute, like the strength these people have in their hearts not to throw it across the room.[00:21:01] Dr. McKayla Yeah, definitely. Definitely. So another question that came to my mind is now you have this experience of, you know, teaching really beginners, and also in a different space, it's a space of you are, you know, like this, this teacher now, and they're doing an online course. But I'm also very interested in how can we actually bring back or coming back to the managing position, right, how can we teach and mentor within a team, right? How can we do that for juniors? How can we do that for mid engineers? Who mentors and teachers, senior engineers? How is that all, you know, the dynamic in a team? And I was wondering if you have like some experience around that and some thoughts around that topic as well.[00:21:47] Jess Rose So I was really lucky. I was on a team several years ago now out at FutureLearn. With oh, gosh, Nikki, What's your surname? I'm so sorry. I swear I know it. I've just forgotten it, because I'm a bad person. And Belinda Sockington, who are both unreasonably brilliant and fantastic managers. And a lot of that work on that team was around, because I have FutureLearn was that it was a MOOC platform. How do we, how do we encourage learning? How do we incentivize it? How do we balance it? And really, what kind of landed for me is it's an ongoing conversation between the folks running these teams, the individual people, I think it may be one of those issues where there's just no one size fits all. It's a combination of saying, Hey, we have these options. Here are some off-the-shelf learning experiences, with starting a conversation and keeping up a conversation of what do you want to learn, what works for you? What's best for you? One thing that I've encountered a couple of times in my career, which I've had a really, really hard time with and my opinion on it has really radically changed, is every now and again, I'd meet somebody who's sort of mid-level or senior, so they've they've gotten themselves into a secure role. They're feeling okay with it. And they wouldn't be that excited about learning where they said, Yeah, I just want to do my job. But I want to go home. And I think the first couple of times, because nobody tells you, but you're not going to start managing people and get it right right away. I'm going to stay awake late tonight absolutely obsessing over the ways I'm still not doing it right. But back then I was thinking, Oh, how can I, how can I make this person care about their learning? And these days, I think with the, with the world having gotten much more stressful, and me having enough experience to see that I think now that I was wrong. These days, when I meet somebody who's like, well, I'd like to do my job. I'd like to do a good job at my job. And I'd like to go home, I don't really need to move up. I don't really want to stretch and learn more. I've gotten, yeah, like, that seems increasingly chill. I think it might be cultural as well, I think. I'm from the States originally. And I think there's quite a bit more fear around employment in the States. Almost everybody can be fired at any time and that makes everything very exciting. And generally your health care is associated with your employment. So I think I see when I was younger and based in the States, there was a lot more. Of course, you have to keep learning, of course, you have to keep running, you have to progress. Otherwise, something bad could happen. And yeah, I think I've just gotten increasingly excited to see people set boundaries around where they put their learning and where they put their interests. Yeah. Yeah, that's a very strange take for a teacher.[00:24:47] Dr. McKayla Yeah. So actually, I was talking to Cat Hicks, just a couple of weeks ago. Yeah. And so we were talking about learning debt. And this whole topic brought us to something where I think, you know, learning is often something very externalized, right, where you say, Oh, I'm learning, let's say I'm learning React, or now I'm learning Remix, right? So maybe the newest framework or, you know, a new a new approach for DevOps or whatnot, right? So it's something that's out of what you're doing right now. And it's a new technology, very technology-oriented as well, whereby I think at the company, there are so many, a little bit more how to call it but informal, or, you know, a little bit more tactic, learning experience that you actually have every day, right, which is, how do I communicate with this new person on the team, right? How do I, how do I understand parts of this codebase? Can we change the architecture for that without breaking something? And all of these are also learning experiences, which we are often not declaring as that right, so we are not saying, oh, you know, McKayla, today learned about new ways to do this architecture for us or to refactor that code, or, you know, she did, she learned about how this API works over there that she hasn't worked about, right? This is very often not, I don't think it's so visible in the learning experience than if I would say, Oh, me, hey, let's sit down and learned React. Yeah, you know.[00:26:25] Jess Rose And I think that's really valuable. Because even when you say something, somebody say, I think, oh, you know, I'm just going to chill and do a good job. And it's so easy to generalize about brains and learning to, say, Oh, we know what we know about learning. In so much as we've learned anything about learning like self-assessment’s messy, the study of, I'm not nearly clever enough to have a good handle on neuroscience and learning. But there's actually a fantastic researcher and author, Dr. Barbara Oakley, who does a lot of work on learning how to learn. And she's been doing some work with Zack Caceres who's a programmer, and I’m not going to tell, talk out of turn. But I believe they may be launching a project around how we learn programming skills relatively soon.[00:27:11] Dr. McKaylaYeah, nice. Yeah. [00:27:11]Jess Rose But we're primates in changing environments. Even if we don't think about it as learning, we are getting new situations and new stimuli, just like you said, I've got a new teammate, I'm going to learn to work with them. Oh, I've got this API. Oh, I finally understood what's going on under the hood. Regardless of whether or not we've set ourselves a mountain path to hike a declared learning journey, there's still learning happening. Yeah.[00:27:37] Dr. McKayla Yeah. And I think that those chill folks, how you call them, right? Maybe they have also more capacity to actually see things that are, you know, people that are very on their journey of, oh, I want to learn React and the latest, you know, whatever, technology comes out right now, maybe don't have the capacity to see, for example, oh, you know, now that the market changed a little bit, budget shifted, we have to work a little bit different with this team, or, you know, how can we make sure that our deadlines are, you know, approachable, and so on? So, yeah, I think learning really happens in so many forms. And, yeah.[00:28:14] Jess Rose And I, yeah, I've always been really excited about that as well. I think resilience is undervalued in teams often. Sorry, this isn't very confident or it is not very definitive, but I'm going to waffle about my biases as part of this. I really like thinking about resilience in individuals and in teams as a resource available. And I like thinking of people as resources, but like, someone being rested, somebody having the capacity, somebody being ready for a little tiny crisis, or a little weird thing. That feels like a resource right there. But I think often we really lean on productivity so hard. How can we get. what kind of developer experience tooling can we use to get 20% more? How can we make sure people are focused? How can we cycle our meeting? And we're so focused on developer productivity and the productivity of technologists, I think we often sacrifice that flexibility and that resilience of having somebody who's not under these productivity pressures to such a high degree. Like, we learn better when we're chill.[00:29:25] Dr. McKayla Yeah, yeah. And I think it brings us back also to, there was this blue code, right? People that are taking on responsibilities, right, blue work, sorry, blue work, that was what it was called, right? But people that are taking on some invisible work that are, you know, good for the team. And, and so yeah, I think this also for teaching, mentoring, learning, I think this can be one thing, and obviously, we shouldn't get outdated too much. And, but I also think that it's not changing every minute, you know, like, sometimes we believe, or we were made to believe, or this story lines around time, Oh, my God, you know, if you're not doing every day something and..[00:30:11] Jess Rose What do you mean you're not using blank? I’m like, look, I’m very old, and I'm very tired. Like, I'm good.[00:30:18] Dr. McKaylaI think it's totally fine, right. And there are a lot of technologies, that I mean, if you're working on PHP, you know, a lot of the web runs on PHP, and it's still, you know, a good technology, and it's okay. [00:30:33] Jess Rose Like, if you want to stretch a little bit, getting into some Laravel is really, really exciting. But if you write PHP, you can hang out and get better at the core stuff of what you do. And do a good job. Like, you don't have to run as hard as you can, as fast as you can forever.[00:30:51] Dr. McKayla Yeah, I think they're, they're, you know, good choices to make. And I'm definitely for growth and for learning. But sometimes people are just burning, you know, mental calories. I learned so much. I mean, I'm actually a learner, right? I love to learn. But most of the stuff that I learn, I never used. It's not very productive, right? [00:31:16] Jess Rose Yeah, but not sorry, you've invited me on here. And I'm just up here ready to blow you. But yeah, this sort of cult of productivity, not that you're espousing it makes me very, very, and when I talk to new learners, and they say, oh, okay, I need to learn this, and this, and this, and this, and this, and this. And I've heard these words, and I need to learn this. I'm like, Babe, you can, you can show we can all chill. Like, we don't have to learn any frameworks yet. We don't have to learn any ops yet, we can just chill and learn the core stuff. And as these are like, one thing I really like to encourage, especially with new learners, or learners new to a specific space, is to go ahead and get some kind of digital or some kind of physical space where you can dump stuff. Some people like Notion, I hate Notion a lot. I quite like Obsidian. I don't care what you use, as long as you're happy about it. As you're seeing all these terms, just chuck them in a big doc. Okay, well, I keep seeing Angular, I know Angular is a thing, should I learn it? Don't worry about whether or not you have to learn it next, just go ahead. And when you see an article about it, throw it in the slush pile. I call it my link dump for early learning. And that means once you've got through the foundational stuff, you say, Okay, I've learned enough JavaScript where I can write. And I like setting these little tiny interim goals to say, Well, I've learned enough JavaScript where I'm able to make simple bug fixes in this open source project I was interested in. I've learned enough. And one thing I'm excited about is the The Art of Learning code, or the art of reading code, which is something Felienne... is an academic who’s done a lot of work in the space.[00:32:59] Dr. McKayla She's from Leiden University.[00:33:01] Jess Rose Yes. You've talked to her already. I bet.[00:33:02] Dr. McKayla I did my PhD with her in the same room. Roommates. Yeah.[00:33:06] Jess Rose Did you? Did you?[00:33:06] Dr. McKayla Yeah, we were roommates. Yeah.[00:33:07] Jess Rose Oh, is she just as delightful to study with?[00:33:10] Dr. McKayla Yeah, she is wonderful. [00:33:13] Jess Rose But yeah, so really getting through the basics of well, I set out to do X, I'm doing X. Now it's time for me to go look through my link dump file, and see, wow, it looks like I've got like 40 different articles about Angular. Maybe that was important that that's enough for what I want to learn next. Yeah.[00:33:34] Dr. McKayla Maybe something else that comes to my mind here is also that I think fundamentals are really important, right? So I like for example, the approach of Dan Abramoff, right? He has like this course of chess JavaScript, which it means that you're not starting with React, right? You're starting with JavaScript and with the fundamentals around it, and I wouldn't say it's really a course for really real beginners. But it's like if you got a little bit of your hands dirty around JavaScript, it's really nice to go in and then check. Did I actually really understand what's you know, what's happening here? And then if you have these fundamentals, I think it's so much easier to build upon that dump. And dive into React or whatnot, right? Whatever technology you want to add here.[00:34:21] Jess Rose I think this comes back to something I've been thinking about a lot in how we learn and teach. But like, where we abstract things out. Soin the boot camp, we're using Free Code Camp to teach, which is a, it's an in-browser sandbox, you don't have, and they've just come out with a new beta curriculum for web development I'm in love with. And it previews that these are files and that you have to link to these files. It is very, very good. But it's still a sandbox, it's still an abstraction. And the places we tend to send learners next are things like, Okay, we're going to head over to CodeSandbox, we're going to head over to Glitch which are still abstracting away a lot of really, and then even when you look in to professional tooling and frameworks, they say, Okay, let's get into React. A lot of the power behind these frameworks are that they abstract away or that they compress, or they obscure or or smooth over some of the fundamentals of how we work with the core technology, maybe JavaScript or the way, Tailwind is a weird abstraction of the things you'd like to do with CSS. And I don't have a problem with, I think it's a teacher, I'd have a hard time having a problem with abstraction. But I think that thinking really carefully about how we do this, when we abstract things , and how we signpost what's been taking, or what's been added gets to be really valuable.[00:34:47] Dr. McKayla Yeah, I think so too. Yeah. When I was starting to learn programming, I struggled a lot with abstractions because I just wanted to know, or not only with abstractions, but also like, there wasn't a lot of abstractions. It was actually very, very raw, right? It was like, Oh, you have an Eclipse IDE open and you're writing Java code. Bbut then you have like, oh, let's say, you know, public wide string, main, whatever, right? And it's just like, you just do it, right. And I'm like, why? What does it mean, don't worry about it. [00:36:22] Jess Rose And then we'll cover this later. And so by the time, we will have covered it, yeah… Having been a linguist, I fear that I mentally map language learning to programming language learning, even when it might not be entirely suitable. But I see this happening in human language education as well, where we say, okay, cool. Here's how, we keep we start people in the present perfect tens for a lot of languages, I see the cat, I drink the water, I walked to the store. And we don't send them into a present perfect world. And I think that's true with programming as well to say, Okay, well, we're going to give you this sandbox, or we're going to give you this framework, which abstracts away a lot of the complexities of the grammar or the the nuance of, and I think it's really valuable to talk about the culture of the language we use around programming and really the culture of, of the structures we build, because it's not transparent to people. I met with a learner in person, what a delight, in person last week. And without thinking about it, I said, yada yada yada bikeshedding. And thank goodness, this learner was confident enough to be like, cool, what the heck are you talking about? I was like, oh, gosh, that's just something we say. We say it as though everyone's going to understand it. And it means to get sidelined to get distracted with little unnecessary details. Just like okay, cool. You should just say that, it's less complicated. [00:37:55] Dr. McKayla Yeah. I think it's not always that easy to be always aware of how you do it. But I recall the time that I started at Microsoft, and, you know, when you start there, it's full of acronyms. And they mean, they mean something completely else inside Microsoft and what it would mean outside, and it really takes quite some time. And then a lot of people get very blind to it, and you know, just start using it as well. And you know, you start talking this gibberish. Nobody else can understand. Yeah.[00:38:32] Jess Rose But like, from a linguistic perspective, that's because that's identifies you as a member of the in-group, doesn't it? How fascinating. Yeah, incredibly interesting. Oh, no, no, I absolutely refuse to spend the next three days hyperfocused learning about weird Microsoft acronyms. It's so tempting.[00:38:49] Dr. McKayla Yeah, there are a lot. But I think it's the same with code reviews, right? And with sometimes how people say, oh, you know, we have this style of giving feedback to each other. And in my code review workshops, I always talk You know, I always try to have people come to an agreement that we need to use language and also, you know, phrase that in a respectful way, that's not only for the internal, you know, internal team to understand. Because there are newcomers, you know, in the team, maybe somebody will look at that, what you wrote two years from now, right, and still should be able to understand it. And so I think it's really good if we be clear about those bridges that we built that, you know, are this internal behavior and language that we are using that it's only, you know, it's an insider joke, and so on.[00:39:47] Jess Rose Yeah. Yeah. And I think we're often really chill about that in tech. Yeah, oh, here's a glossary of technical terms you need to know to do the thing. We're, we're cool about that. There seems to be a bit more resistance around when shared language or shared norms, or shared language structures around things like code reviews are proposed because we don't need that we know how to talk to each other. I hope I'm not putting you on the spot. Are you one of those lucky people who speak like nine languages?[00:40:15] Dr. McKayla No, not nine.[00:40:15] Jess Rose Oh, only five?[00:40:17] Dr. McKayla Maybe, yeah. German is my mother tongue, right? English, Dutch, Italian, and a little bit of Spanish.[00:40:28] Jess Rose A little bit of Spanish. Look at that. The fantastic thing about chatting to many folks from Europe is, is y'all always have this very, very beautiful, very casual, like humble brag at the end, you like, you know, just a little tiny bit of Croatian. I'm terribly jealous. Yeah, like recognizing that folks aren't going to be coming to, coming to these code reviews. And I really liked that you highlight that they're going to be coming to the uncoupled in time. I love this idea that when you leave a code review, when you leave feedback, when you leave a pull request, when you leave code, you're leaving a little artifact of understanding behind. So to say, Cool, we've standardized how we talk about these, we've created a shared language for them. Because when we go into the far scary future, we want these to still make sense.[00:41:23] Dr. McKayla Yeah, I think this is really important.[00:41:26] Jess Rose But also making them like giving a shared language around, hey, maybe English, or if we're doing the, if we're doing the code review, in Dutch, I'm in a bit of trouble. But maybe the language this code review is in is your second or third or fifth? Let's go ahead and have some shared language have some shared structures around feedback to lower the cognitive load? Yeah, well, can we talk about cognitive load? I imagine you've done it tons of times on the podcast. I imagine many programmers are familiar with it.[00:42:00] Dr. McKayla Yeah, we also have to be a little bit careful of the time now. But maybe the last thing that I want to add here is I'm writing a book on code reviews, right? [00:42:10] Jess Rose Are you?[00:42:10] Dr. McKayla Yeah, I'm right now in the middle of the feedback section, right? So how to give feedback, how to give respectful feedback, and how to communicate with each other and also cultural right? So how do we deal with, it gets really hairy there, right? So yeah, what are different cultures are expecting, what's respectful there, you know, how much you know, how harsh should a feedback be? Or can it be or, you know, what is seen as polite and so on? And this is not only, it's not only, it's not one standard thing, right? It depends on who's on the team, what's the background? What's the culture? But I think the expectation, setting the right expectations, and, you know, explicitly stating that, and talking about that, reflecting on that, and, you know, learning how others see those things and learning how, you know, like, if I would talk to you I'm originally from Austria lived in a couple of countries, right? You're from the States you're, you're in the UK now, right?[00:43:12] Jess Rose I am, yeah, everything's just fine here. Very chill. Not weird.[00:43:10] Dr. McKayla Yeah. And then maybe we have another person from Croatia and then somebody from India, right. And so I think it would be really important for us to talk about how we understand different terminologies, how we understand different you know, expressions in my career workshops, sometimes I have discussions about looks good to me. And I love those discussions because, you know, it's just a simple term looks good to me. Most of the time, people just, you know, have the acronym for it, right?[00:43:47] Jess Rose Like it's the thumbs up emoji in my head.[00:43:50] Dr. McKayla Exactly or you know, LGTM, right? And then some people are like, oh, yeah, this means you know, that I looked through it and you did a good job. And then the other person has no, you know, looks good to me means that you haven't looked at my code.[00:44:07] Jess Rose You just glanced at it. [00:44:07] Dr. McKayla Yeah, you just want it out of your way. Yeah. And the other person says, Oh, this means, I don't care. [00:44:07] Jess Rose Sometimes, sometimes.[00:44:16] Dr. McKayla And having those discussions in the team, you know, and understanding where everybody is coming from, and that they actually use, you know, one simple terminology. And everybody on the same team understood something else about it, I think it's so valuable, right? And only by these discussions, you know, we can really understand what's behind those terms and the way that we are communicating. But I'm also getting a little bit carried away.[00:44:45] Jess Rose No, no. So I'm going to ask you about your book. And yeah, I've just had a friend tell me that there are some questions you're not supposed to ask about someone's book. So I won't ask any of those. Instead, I've been told you're supposed to say, I hope it's going well. I'd like and I think it might be useful for hopefully some of the audience as well. I had an idea for a book that sounded really fun in my head. And I've sort of broken it down into chapters into essays and trying to write a couple of chapters. And my goal in writing a couple of essays is I'm trying to talk myself out of writing a book. [00:45:22] Dr. McKayla Yeah, I've heard that. Yeah. [00:45:23] Jess Rose Do you have any advice for not, like, it's the worst. It's the worst idea ever. No one wants to write a book like, please, please, please. [00:45:32] Dr. McKayla No, I don't have.[00:45:32] Jess Rose No, I want to know what you’re doing.[00:45:34] Dr. McKayla But I saw on Twitter that you said that and I thought, like, yeah, you won't be able to not write a book with this approach, right?[00:45:42] Jess Rose I love that it sounds like a th reat, where you’re like, you’re going to write that book.[00:45:45] Dr. McKayla Yeah, it looks like. I think if you're breaking it up in essays, that become more manageable. I think you will write this book. Yeah.[00:45:55] Jess Rose But for our beloved audience, for your beloved audience, they shouldn't write a book, they should, they should definitely do things that are not writing a book. Like, it's a terrible idea, isn't it?[00:46:04] Dr. McKayla I can't, I can't say it's a terrible idea. [00:46:06] Jess Rose Are you enjoying it?[00:46:08] Dr. McKayla I don't think it's a good idea. But I think a lot of people would like to write a book and I would be the last person that would discourage them. Because I was always discouraged to write a book, right? But I think I know what mess I got myself into. [00:46:25] Jess Rose That’s what I'm looking for, there we go.[00:46:26] Dr. McKayla I would just tell the people that you're getting yourself into a big mess. But it's okay. You know, it's okay. I think people can write books, and people should write books.[00:46:36] Jess Rose The world is messy. It'll be fun. Oh, no, this is the opposite of what I was looking for. But it's so delightful.[00:46:42] Dr. McKayla Yeah, well, Jess actually, this brings us to the end of our show, I really enjoyed talking with you about all of that. And I think we should talk about cognition and cognitive load, and you know, all of that. So maybe I will invite you again, to another session[00:46:58] Jess Rose I'd love to come back any time. But I'll also pass you some contacts for folks who are much better at this than I am, I would just go back and be like, so books. And really, your audience deserves better.[00:47:13] Dr. McKayla Okay. And we will both all the things that we talked about down there also, maybe the Twitter handle or LinkedIn profile or whatnot, from the person that you mentioned in the middle, where you forgot the last name, I put it there. So she will be there as well. And then, yeah, so is there something that you want to wrap this episode up? Or?[00:47:36] Jess Rose Oh, gosh, can I bully your audience? Is that doable? Is it permitted? I've been doing advice calls all this week. And the big thing that I keep coming back to when I chat to people, I do do them just to be mean to people who are smarter than me is right now everything, everything is just so big and so loud and so stressful. One thing I've really enjoyed exploring with people is looking at ways that what they have to do, what they think they have to do can be smaller and softer and quieter. And I think that yeah, I'd love to gently bully folks to consider how what they need to do could be a little less. Maybe you don't have to write that book. It can just be an essay.[00:48:24] Dr. McKayla Yeah. Yeah. I like that. I actually did that this week with myself and just gave myself permission to let go of a couple of balls that I was juggling. And I think it's delightful. We should really do that. And I think it's it's the time that we are many people needed. Not everybody, right. I think a lot of people needed.[00:48:41] Jess Rose There's going to be one person out there who's having a real good week. I just haven't met him.[00:48:46] Dr. McKayla Or yeah, or that cat very nicely distracted by all of the work and don't have to think about the stuff that's going on. Yeah. Okay, so Jess, thank you so much. Thank you. It was really a pleasure talking to you.[00:49:01] Jess Rose Thanks so much. I'll let you go and thank you again. I won't get into a thank you loop with you.[00:49:06] Dr. McKayla Okay, bye-bye. [00:49:06] Dr. McKayla This was another episode of the Software Engineering Unlocked podcast. If you enjoyed the episode, please help me spread the word about the podcast, send episode to a friend via email, Twitter, LinkedIn. Well, whatever messaging system you use, or give it a positive review on your favorite podcasting platforms such as Spotify or iTunes. This would mean really a lot to me. So thank you for listening. Don't forget to subscribe and I will talk to you in two weeks. Bye