Episodios
-
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.
-
Make code reviews your superpower at awesomecodereviews.com!
Episode Resources:
Paper on improving developer experience
Abi's thoughts on the DX paper
Abi Noda's LinkedIn
Abi's podcast for Engineering Enablement leadersAbout Abi Noda
Abi Noda is the CEO and founder of DX, a company that helps measure and improve developer experience. -
¿Faltan episodios?
-
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 Engineer
Platform Engineering community
PlatformCon 2023
Luca’s LinkedIn and TwitterAbout Luca Galante
Make code reviews your superpower at awesomecodereviews.com!Other episodes you'll enjoy
Luca 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.Can Engineering metrics be ethical?
Measure developer productivity using the SPACE framework
High-performing engineering teams through DX
-
Earn additional income by sharing your opinion on userinterviews.com!
Episode Resources:
Nadia's Book
Nadia's website
Nadia's TwitterAbout Nadia Zhuk
Make code reviews your superpower at awesomecodereviews.com!Other episodes you'll enjoy
Nadia 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.Do code reviews frustrate developers?
The Secret To High-Quality Code
Vulnerability disclosure with Katie Moussouris
-
Earn additional income by sharing your opinion on userinterviews.com!
Episode Resources:
Alexander's Twitter
Alexander's Research
Awesome Code Reviews
Papers:
An exploratory study on confusion in code reviews
Emotions and Perceived Productivity of Software Developers at the Workplace
Recognizing developers' emotions while programming
Gendered Experiences of Software Engineers During the COVID-19 Crisis
Developer experience research paperAbout Alexander Serebrenik
Alexander 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. -
Earn additional income by sharing your opinion on userinterviews.com!
Episode Resources:
Executive Order on Improving the Nation’s Cybersecurity
Alpha-Omega Projects
Cybersecurity & Infrastructure Security Agency (Cisa)
Tools to create SBOMAbout Barak Brudo
Other episodes you'll enjoyWhat developers should know about securityThe Secret To High-Quality CodeVulnerability disclosure with Katie Moussouris
Barak Brudo helps organizations secure their software supply chain. He works as a Developer Relations Advocate at Scribe Security.
-
Earn additional income by sharing your opinion on userinterviews.com!
Episode Resources:
Heather's Twitter
Heather's job search blog post
Heather's BlogAbout Heather Reid
Heather 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 Introduction
02:00 What does a test community boss do?
06:28 Can we forget our skills?
08:00 Attending workshops
09:00 4-hour interview experience
10:00 Hurtful rejections pile up
12:10 Can't ask questions in an interview
14:00 A good interview experience
19:00 A technical test
23:00 Different backgrounds and perspectives
26:10 Arguing during an interview
30:50 Improving the state of testing 33:50 Adding accessibility 40:00 Career advice for job seekers -
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 -
Make code reviews your superpower at awesomecodereviews.com!
About Michael Lynch
Michael 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 Twitter
How to Do Code Reviews Like a Human
Tiny Pilot -
Book your awesomecodereviews.com workshop!
Episode Resources:
Multitudes
Lauren's Twitter
Developer experience research paper
DORA metrics
SPACE developer productivity frameworkAbout Lauren Peate
Lauren 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. -
This episode is sponsored by Fiberplane. Your platform for collaborative debugging notebooks!
Episode Resources:
Try Fiberplane hereFiberplane websiteFiberplane DocsNP-hard VenturesAbout Micha Hernandez van Leuffen
Read the whole episode (Transcript)
Micha 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.[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 to
go.
[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.
-
[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 milk
Oh 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.
-
Book your awesomecodereview.com workshop!
Links:
Harshit’s LinkedinThe voice of the modern developerTromozoSubscribe on iTunes, Spotify, Google, Deezer, or via RSS.
-
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. -
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 Management
The 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 Learning
Why Jess’ started an online learning program
In search of the best tool for virtual and distance learning
The impact of tools on the quality of learningMentorship and organizational rank
Establishing healthy boundaries
Resilience in an educational setting
[33:34 - 44:46] Let’s Start Speaking The Same Language
Acing the basics: Why learning the fundamentals is everything
Let’s talk about programming language
How to improve team communication and having a shared language
[44:46 - 49:55] Closing Segment
Dr. McKayla talks about her book in progress and her advice to those who would like to write a book
Final words
Tweetable 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 Rose
Connect with Jess Rose on LinkedIn, Twitter, and her website. Go to Github.com/JessicaRose to check out her 1-1s.
Resources Mentioned
Mergify - 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
-
This episode is sponsored by Tonic.ai – where your data is modeled from your production data to help you tell an identical story in your testing environments.
[00:01 - 05:08] Opening Segment
Need to generate fake data that looks, acts, and behaves like production data for your test environments? Check out Tonic.ai!Head over to https://www.tonic.ai/ and sign up today for a free two weeks trial sandbox!Dagna talks about experiencing a plateau in her career as a software engineerRealizing the lack of support networksHow this led her to set up her own coaching business[05:09 - 11:26] How Cultural Upbringing Affects Work Performance
What Dagna is doing to help immigrants like her fit into their American workplaceUsing the Hofstede model to understand the cultureCultural differences in the US and other countriesIndividualism and collectivismLong-term orientation and short-term orientation[11:27 - 26:14] Engineering Mindset for Success
Coaching clients on career advancement and finding fulfillmentThe importance of mindsetCommon limiting beliefs engineers have and overcoming themBeing your own advocate, your work does not speak for itselfCreating a safe space for feedbackThe feedback Dagna received from her superior and how it changed how she was writing codeKnowing when to move onThe state of the US and European job market[26:15 - 29:54] Closing Segment
Dagna’s advice: Don’t take code reviews and feedback personallyKnow more about the process Dagna uses to take her clients’ careers to the next level at https://www.themindfuldev.com/podcastFinal wordsTweetable Quotes
“How you think is how you act.” - Dagna Bieda
“What you really have to do is market yourself. You have to talk about your achievements and accomplishments and not expect everybody in the company to just know what it is that you're doing.” - Dagna Bieda
“It's very important to understand how what you're doing fits into the business as a whole, the business that you're working for, and how to communicate about it.” - Dagna Bieda
Resources Mentioned
https://www.tonic.ai/ - Sign up now for a two-week free trial!The Culture Map by Erin Meyer - https://erinmeyer.com/books/the-culture-map/Dagna’s WebsiteConnect with Dagna by following her on LinkedIn. Go to theMindfuldev.com and theMindfulDev.com/podcast to learn more about her coaching business.
Let’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 Dagna Bieda. She's a software engineer turned career coach for software engineers. She's been coding for over 10 years and has been a coach or has been coaching for the past two-plus years.
[00:00:24] Dr. McKayla: And today I will learn everything around how to get a job, how to be successful as a software engineer, and how to advance your career. But before I start, let me introduce you to an amazing startup that's sponsoring today's episode, Tonic.ai, the fake data company. So what does Tonic.ai do? I'm sure you know how complex and cumbersome it is to create quality test data.
[00:00:51] Dr. McKayla: It's a never-ending chore that eats into valuable engineering resources. Random data doesn't do it and production data is neither safe nor legal for developers to use. What if you could mimic your entire production database to create a realistic dataset with zero sensitive data? That sounds amazing, right?
[00:01:10] Dr. McKayla: Tonic.ai does exactly that. With Tonic.ai, you can generate fake data that looks, acts, and behaves like production data because it's made from production. Yet, Tonic.ai guarantees privacy so your data sets are safe to share with developers, QA, data scientists, heck, even distributed teams around the world. Visit Tonic.ai to sign up today or click the link in the show notes to get a free two weeks trial sandbox.
[00:01:38] Dr. McKayla: Well, Dagna, I'm, I'm so excited to learn everything that, you know, you have been through. in your career as a software engineer and how you actually help software engineers get the most out of their career. So can you tell me a little bit, how did you go about to this shift from, you know, being a software engineer, yourself to being a full-time career coach for software engineers? Why did that happen and how?
[00:02:03] Dagna Bieda: Absolutely. And first of all, thanks so much for having me on your show, McKayla. Essentially, you know, in my own career, I have seen some incredible accelerated progression in my own career. When I started programming, I went from a junior engineer to a senior engineer fairly quickly.
[00:02:22] Dagna Bieda: It happened in less than three years, which, it takes a lot more for a lot of engineers in our industry. And it was all because of the people that were in my corner that supported me, that mentored me. And because I was very relentless about asking them for feedback to tell me how I can improve, how I can do better.
[00:02:44] Dagna Bieda: And as I kind of like, went up in my career in my senior engineering role, what happened is I experienced this plateau, you could say. And I recognized, later on, you know, in hindsight that I was just working really hard on the wrong things, but I didn't have that kind of support that I needed that would have showed me like, Hey, Dagna, what you're focusing on is not going to take you to that next level.
[00:03:11] Dagna Bieda: So after having that aha moment, I recognized like, okay, I was going super quickly, advancing in my career in the early, in the beginning, because of that support. Later on, I didn't have that support. I had to figure it out by myself. And so , it was so much slower of a process when I was trying to figure it out myself.
[00:03:32] Dagna Bieda: So I decided that, you know, this is a great idea for a business because not everybody, being a software engineer, has that support network that they could lean on. So I could step in and become that support network for my clients. And that's exactly what I do today. And it's just amazing. And I've helped so many clients, you know, I've had over the past three years that I've been coaching, I've helped over 50 engineers.
[00:03:59] Dagna Bieda: They had various backgrounds. Some of them work at fan companies. Some of them work for like small mom and pop shops, and they had experience ranging anywhere from 2 to 20 years of experience. Some were self-thought. Some had college degrees, some are boot camp graduates. And you know what I do right now as a coach and that lits me on fire and, you know, brings a lot of fulfillment to my life is to help my clients find that in their life and in their career.
[00:04:28] Dr. McKayla: Okay. And so, what does it take from a junior to become a senior? And why was there no support for you when you were a senior to get, you know, to the next level? Maybe what was your next level? Was it like a staff engineer that you wanted to become, or is it more in a managerial role that you wanted to develop yourself? So what's the next, the next step?
[00:04:52] Dagna Bieda: I wanted to become a team lead and team lead is like a mix of both, right? On one hand, like from an HR perspective, maybe you are not on the org chart on top of like a team, but you are leading your team with your technical expertise. So like it's a mix of the managerial and the engineering responsibilities.
[00:05:09] Dagna Bieda: The big reason why I had the plateaued is because I moved from Poland to the United States. And as an immigrant. I didn't realize that, you know, the way I was thinking and going about work, while it made perfect sense back in Poland, it didn't necessarily set me up for success in my American workplace.
[00:05:30] Dagna Bieda: And also like right now, a lot of my clients are immigrants moving from one country to another. And what I help them is to understand how their cultural upbringing affects their performance at their workplace. Because for me that was one of the blockers, right? I had to really kind of like understand my new situation, my new culture, how I was fitting in what was stopping me, and for example, there's this one situation that I can, that comes to mind is when, when I posted a joke in slack that I thought was super funny and, and being an Eastern European, we have this dark sense of humor.
[00:06:06] Dagna Bieda: And, you know, in this new American company, what happened was I was called to HR and I was told that that was inappropriate. And I was like, what? That was super funny. What are you talking about? So, that was like one of the things that I had to realize, like, okay, This is the type of sense of humor that just doesn't go with my workplace.
[00:06:27] Dagna Bieda: So I can, you know, keep doing that on my own and private, but this is not going to help me in terms of work advancement, right?
[00:06:34] Dr. McKayla: So can you, can you go a little bit more into this in this cultural aspect, right? Okay. There are the jokes that obviously, there are cultural differences. What's funny, what's not, what's inappropriate, right, and so on. But is there also like for leadership because you were talking about tech lead, right? So it's, how, how can you show the outside world that you're ready for it? Is there a difference in your experience?
[00:06:58] Dagna Bieda: Yes. So that's another like cultural aspect, you know, like, there's this specific tool that I use for analysis that helped me really map those differences. And it's called the Hofstede model. And essentially, it has, like, this database that compares different countries on, like, six different dimensions, right? And one of the things for the United States specifically is that individualism is super highly rated, right? And Poland is more rated closer to being like a collective culture, right, where we work together towards success. And I can tell you, for example, there was this initiative that I was leading in my American workplace.
[00:07:45] Dagna Bieda: And what happened was I was talking to different people, different types of stakeholders. They agreed with me. So I thought, okay, if I have a buy-in, something's going to happen now, right. Because that's how it would have worked back in Poland, right? In the American workplace, I was expected to, once I picked up the initiative to lead it from end to end. And, you know, I wasn't aware of that. So, you know, I got all the stakeholders on board. Everybody agreed to my idea and then nothing happened, and I got so frustrated. I'm like, why there's nothing happening? Like, didn't we all agree, should we all collaborate together? And because they didn't realize that my cultural upbringing was different, nobody could give me that kind of feedback, right?
[00:08:29] Dr. McKayla: Yeah.
[00:08:29] Dagna Bieda: They just didn't know how to support me there.
[00:08:32] Dr. McKayla: I think this topic is so interesting because right now I'm working on the book on code reviews and I'm working a lot about feedback and disagreements, agreements, and how to solve that, right, how to collaborate together.
[00:08:45] Dr. McKayla: And so one book that I'm actually deep diving into that I found really interesting was The Culture Map. I don't know if you are familiar with, from Erin Meyer, and there she...
[00:08:55] Dagna Bieda: Oh, that's interesting. Okay.
[00:08:56] Dr. McKayla: Yeah, you can have a look at it and she also looks at a different perspective. And one is, for example, agreements, how are people from different countries agreeing? And for example, Germany or Austria, right? It's a little bit more collaborative or, you know, collective, right? Collective agreement.
[00:09:11] Dagna Bieda: Exactly.
[00:09:12] Dr. McKayla: It's really, really important. So it takes a very long time until everybody agrees. And it's a little bit an upfront process, right? Whereby in America, it's more, well, one decision is made by the leader, but then this decision can also be questioned along the way, right? And so it's quicker, quicker to get started, right? And one person brings up and says, okay, this is how we are going to do it.
[00:09:34] Dr. McKayla: And then people are working on this vision. This is how she explains it, right? But yeah. And then over time, you can actually challenge that a little bit, right? You can say, but maybe, you know, we should change course because we have more information now and so on. And in Germany, it's exactly the other way around, right? So we are investing a lot in this process of collective agreement, on this is the right way to go. But because there's a lot of, you know, a lot of time and information that goes into this process, it's really hard to challenge that later on, right? So after three months of discussing that we are going to do that.
[00:10:09] Dr. McKayla: It's really hard to say a month later, oh, maybe you should change that again, which I think is perfectly fine in America. I don't know. Can you see that as well? Is that something that...
[00:10:20] Dagna Bieda: Oh, absolutely. Yeah, absolutely. And another interesting thing is like, for example, in terms of the short-term versus long-term orientation, in the United States, the culture as a whole is on the Hofstede model described as a more short-term oriented. So the company would be more like working towards your quarterly goals, right? And when I work, for example, with some of my clients that have Asian upbringing and working in the United States, that their cultures tend to have this long-term orientation.
[00:10:51] Dagna Bieda: What happens is, for example, in an interview, whenever they present themselves, they're talking about, you know, building a solid foundation for a long term. But what happens is. American companies don't necessarily value that, right? Because, and they even have this, this saying here to hit the ground running, right? So when I work with my clients, I tell them, look, if you're starting to work in a new workplace, American workplace, you want to present yourself as someone who's operating fast and can bring results really quickly because of valuing of that short term results rather than long term.
[00:11:27] Dr. McKayla: Yeah, yeah, yeah. I can totally see that. So you are working as I understood it, you're working with a very range of experiences, right? So you said people are coming from boot camp, but it's just coming from boot camp with no experience and want to go into the workplace or is it more, are they already, you said two years, something like this.
[00:11:48] Dagna Bieda: Yeah.
[00:11:49] Dr. McKayla: Is it really an even distribution here or do you see that it's cooling in one direction, right? More the junior engineers in the first, let's say, five years or more the senior engineers or midterm, maybe?
[00:12:02] Dagna Bieda: I would say that the majority of my clients are the mid-level professionals and the more senior professionals that are kind of like finding themselves a little stuck, maybe not sure about their next step.
[00:12:13] Dagna Bieda: And they're looking for, you know, figuring out first of all, how are they stopping themselves? Second of all, how to find fulfillment in their career rather than chasing money or promotions. And, you know, the truth is there's, to my knowledge, nobody else that offers the type of services that I offer, which is working on the engineering mindset for success, right?
[00:12:36] Dagna Bieda: And you know, what got you to that senior engineer position was very likely your technical foundation. And I do not work on that technical foundation while having been a software engineer myself, I can definitely send my clients some pointers, like what are the gaps that they have in their skill set that they should, like, fill up in terms of you know, career advancement, but what I really am passionate about and what I really love to focus on is that mindset piece, right? Like, what kind of blind spots do you have? What kind of limiting beliefs do you have? I actually like to say that I moved from programming computers to reprogramming human minds. And it really beautifully describes what it is that I do, because once you change your mindset, I put it this way.
[00:13:21] Dagna Bieda: How you think is how you act. And how you act is the results that you're getting then from, you know, the reality, the real world.
[00:13:31] Dr. McKayla: Yeah. Can you tell me some limiting beliefs? I also regularly reflect on mine and, right now, you know, I'm also in a, this state where I think, because of the pregnancy and the very new birth, I think this is such an inward-facing period in my life again, right, where I'm thinking, like, what are the beliefs that I have, and that are holding me back and so on. I would be really curious, can you give some examples of beliefs that engineers have, maybe that you have seen patterns?
[00:14:00] Dagna Bieda: Absolutely.
[00:14:01] Dr. McKayla: Yeah, that hold them back.
[00:14:02] Dagna Bieda: There are two that are super common and super popular. Number one is believing that your work speaks for itself, which it doesn't. It does not. Like, okay, if someone else works on the same code base with you and they can look at your code, they could see the value that you bring to the table if they put in the work and effort to actually go into the code, look up what it is that you committed and, you know, have some thoughts on that.
[00:14:28] Dagna Bieda: But, in order to be successful in an engineer's role, what you really have to do is market yourself. You have to talk about your achievements and accomplishments and not expect everybody in the company to just know what it is that you're doing, because people just don't know. They have their own work that they're prioritizing.
[00:14:44] Dagna Bieda: And it's very critical to figure out if you have that limiting belief of work speaks for itself because again, it doesn't. That keeps a lot of talented engineers stuck in their career. That's number one. The second one, which always cracks me up, but I used to think that way too. There was a moment, and I have to be honest with you, there was a moment I thought the same way. And the second limiting belief is essentially, that you are surrounded, as an engineer, with idiots that just don't want to listen to your amazing ideas. And here's the thing, whenever, as an engineer, you have an incredible idea and you want to pitch it. You want to get people on board.
[00:15:25] Dagna Bieda: It's super important for you to communicate about it in a certain way. You have to be able to negotiate. You have to be able to like really describe it, but describe it in terms of the priorities of your stakeholders, right? So if I'm going to, and I'm guilty of that as well. Like, there was this two projects that I worked on in my most recent engineering job, and I was responsible for taking care of a mobile app.
[00:15:48] Dagna Bieda: And it was a pain in the butt that the build of the app was taking a few minutes, you know, and I just felt it was so inefficient. So I went ahead and I refactored how this particular app was built. And I reduced the build time from few minutes to, like, 30 seconds. And I was so proud of myself, you know, I was so like, yes, this is amazing in reality, what happened is, that what I did that work that I did, impacted my life and one other engineer. Nobody else cared. It didn't matter. Then I had a second task or project that I worked on in the same company, which was creating a deliverable for a client, super boring, a lot of copy and pasting, a lot of like following steps. I did not enjoy doing that at all, but guess what?
[00:16:36] Dagna Bieda: Whenever it was deployed and the client could spread the mobile app to their own client base, I got praise from the sales representative from our BA, from the project manager. My tech lead was like, wow, Dagna, that was a super fast turnaround. You know, everybody across the organization was like, yay, success.
[00:16:57] Dagna Bieda: And I'm thinking to myself, Wow. I would have never in a hundred million years figured this out on my own. If, if you ask me as an engineer to like put a value on this project versus that project, I would've thought that the refactoring was better. So here's long story, but essentially what I'm trying to say is, it's very important to understand how what you are doing trickles, like, how what you're doing fits into the business as a whole, the business that you're working for and how to communicate about it. That's the, really the key of what I was trying to say here.
[00:17:35] Dr. McKayla: Yeah, I think that's really, really important, but I also found myself working at companies where. You are assigned things, right? So you're not really asked for your opinion. if this is now really helpful or not or, or something like this. And then maybe reassigned as well, right, which I think there are, there are several impacts to that. First of all, what would be your advice for people that are assigned projects where they also know maybe doesn't look like this has a big impact on the company, right? So it's also limiting my ability to advance my career here. What should you do? How do you communicate about that? What's your advice?
[00:18:18] Dagna Bieda: Yeah, we're kind of going back to, you know, to that communication piece, right? So, first of all, one thing that I want to share the assumption I'm coming here up with is that whoever assigns you that work is not a mind reader, so they would not necessarily have your priorities, your career priorities in mind.
[00:18:37] Dagna Bieda: So it's important to, whenever you are asking for work to kind of like be proactive and say, Hey, I am really working towards becoming, let's say a staff engineer, becoming a team lead, becoming an engineering manager, can you help me out and assign the kind of work to me that will help me achieve that goal, right?
[00:18:58] Dagna Bieda: Asking for that help and support because most of us are nice and friendly people, and we want to help. But we don't always know what's the best way to provide that help. So being kind of like your own advocate and talking about what it is that you want to do is really critical here. A second thing is, you know, whenever you're in those one-on-ones with your manager, is to really ask for feedback. How are you doing, how you could be doing better, and creating that safe space for feedback. You know, something that is my strength actually, and really helped me with accelerating in my career early on was that relentlessness in asking for feedback. Like, I had this team lead that worked with me that helped me become a senior engineer because he kind of vouched for me in the meetings that I wasn't part of.
[00:19:53] Dagna Bieda: And he really said like, Hey, she's ready. She can handle it. She can be a senior engineer. I think she's ready. And that's what got me the promotion. But when him and I worked together, I was telling him, look, I really want to know. Don't worry. You're not going to hurt, hurt my feelings. I want to advance, I want to be hitting the ground running, and I want to really work on the things that are holding me back.
[00:20:16] Dagna Bieda: And, you know, one of the critical pieces of feedback that he initially didn't want to give me, because it felt like maybe he would hurt my feelings or maybe was too much. I don't know. But after I was pushing and pushing for that feedback, he essentially told me, Dagna, fast is great. But reliable is better.
[00:20:35] Dagna Bieda: And that advice changed how I was thinking about writing code, because I was really prioritizing being fast, delivering as soon as possible, right? But sometimes my fast solutions were not fully thought out. And a senior engineer really has to have that understanding of how the engineering decisions impact business, the team and what it is that, that they're trying to accomplish as a team.
[00:21:03] Dr. McKayla: Yeah, I'm thinking back of a time, right, where I think it's totally true that we have to go and advocate for ourselves, but I also wonder how many people are a little bit stuck in that, well, this is what the business needs, right? I understand that you want to advance your career. You want to become, you know, a senior engineer or a tech lead or whatnot.
[00:21:27] Dr. McKayla: You know, saying that the project doesn't seem to have such big impact, right? And big impact, I think has to do with the stakeholder. Who is it visible to, right? Who is going to see and hear your name and, and so on. I thought, I think there's a little bit of political background towards that as well. Have you worked with people that are just really stuck in a situation where there is nobody that really advocates for them too much, or they are assigned a project that's, you know, low visibility and they're stuck there. Would you say the best is to move companies or?
[00:22:01] Dagna Bieda: The short and sweet answer is yes. And, you know, in the very first meeting that I have with my clients whenever we start our coaching sessions in the program, what we do is we figure out what are their specific life and career goals, and what are their values and, how their current workplace supports those values. And then we measure them in a specific way. And after that, specific exercise, we're able to confidently say whether it's worth staying in that place or if it's time to move on.
[00:22:38] Dr. McKayla: And so, whenever I see, like, in my Twitter bubble, right? I'm also very much in the American, you know, world somehow. And everybody is like, oh my God, the marketplace is, or the market is so hot now. And, you know, jobs are everywhere. I don't know in Europe, I don't feel that way.
[00:23:00] Dagna Bieda: Got it.
[00:23:00] Dr. McKayla: Is, is it like this? Do you feel like right now, it's so hot and everybody can, you know, change their career in a second and get better and you know, why would you even stay there? I feel like even if you have a good place, let's move because you can make more money and so on, which is a very different mindset.
[00:23:18] Dr. McKayla: I don't see that here in Europe so much. It doesn't feel that hard or it also feels like if I'm at the good company and, you know, I make a market okay salary, I don't feel that people are looking forward, changing every one and a half, two years, more.
[00:23:34] Dagna Bieda: Yeah. So two years is very common for people who are very ambitious.
[00:23:39] Dagna Bieda: I want to try to see how different companies do different things and gain those experiences across a variety of industries or companies of different sizes. So, two years is definitely something that's seen as fairly normal. And I feel like you touched on an important subject there, it's very important to realize that the European job market is much more fragmented, right?
[00:24:03] Dagna Bieda: Because we have different countries, different cultures, and it's not as easy to, you know, have access to all those opportunities. In the United States, it's way more streamlined because you know, it's one country and people mobility is also completely different. So like if you live in LA and then next year you get a job in New York, it's much more likely that you're just going to pick everything up and move for that job.
[00:24:30] Dagna Bieda: In Europe, we are not like that. so it's more like choosing a town you want to live in, and then you find a job within that town, say, for example, right? So in that sense, we have just different priorities in Europe, and there are different priorities here in the United States, and that impacts that job market, absolutely. With that being said, with the COVID, the pandemic, and the acceleration of the remote workplaces, there's more and more opportunities for the Europe software engineers, for example, or anyone else really to access those American jobs. I cannot think of, like, anything in particular, but there's more and more companies that are supportive of those remote jobs and help pair American companies with offshore workers.
[00:25:18] Dagna Bieda: And it's kind of like in that saying where Europeans work to live and Americans live to work. There's definitely something in that, some truth to it. I mean, I remember when I moved to United States and I was, you know, trying to get my very first engineering job and, on the phone interview, someone would tell me, like, we offer three weeks vacation, we're generous.
[00:25:42] Dr. McKayla: Yeah, it's different.
[00:25:43] Dagna Bieda: Yeah, right? It's different. It's different. There's so much more vacation time back in Europe, back at home. In the United States, even though they are coming up with, like, this unlimited time off policies it really depends on the company. Some companies are just trying to not pay you out the accrued time off.
[00:25:59] Dagna Bieda: So you have to like really be wary when you are verifying if it's really unlimited time off. But with that being said, I had a client and she took like 10 weeks off within a year. So you know, there are companies that, yeah, there are companies that really kind of like honor that.
[00:26:15] Dr. McKayla: Okay. Okay. Well, I have a last question for you, actually, and it's about code reviews because you were touching upon communication and also showing your work and what you are doing. How do you think can people use code reviews to do that, to accomplish that, to, you know, make their work a little bit more visible? Is it something that you thought about? How that fits together?
[00:26:39] Dagna Bieda: So in terms of code reviews, the advice that I really give to my more inexperienced clients who are earlier in their career journey is to not take them personal.
[00:26:51] Dagna Bieda: Just take it in as an information, as a guidance and, you know, earlier in their career, a lot of software engineers tend to take those comments, that feedback very personally, and they have their feelings hurt. But in reality, it's just feedback. It's just objective information that you can use to better yourself.
[00:27:11] Dagna Bieda: Now, in terms of my more senior client, their skills are at the level that, you know, I don't see code reviews being very critical there because they already, you know, have mastered that technical foundation. So what I focus on really is those skills that are missing: the people skills, the communication, how you market yourself and all the things that we talked about today.
[00:27:34] Dr. McKayla: Okay. Okay, cool. So, Dagna, thank you so much. Maybe you can also tell us a little bit how people can follow your work can find you, and maybe something that you want to. You know, give on the way for the engineers on how to find the career or the next step that makes them happy.
[00:27:56] Dagna Bieda: Yeah, absolutely. So the best way to really get in contact with me is through my LinkedIn profile. You just can go to LinkedIn and find me under Dagna Bieda, D A G N A B I E D A. And then you can also go ahead to my website, the mindfuldev.com/podcast, and you'll find there a case study. And that case study beautifully explains the process that I follow with my clients and how it helped them really level up in their career. For one client, it meant going from an underappreciated senior engineer to a startup CTO in three months. For another client, it meant moving from a senior engineer to a VP of engineering and innovation at his company. For another client, that meant doubling his salary as we work together. So, you know, if that case study is something that you're interested in, you can then reach out to me and we can see if we're a good fit to work together and how I can help you accelerate your career.
[00:28:57] Dr. McKayla: Okay. Cool. Thank you so much. Thank you, Dagna, for being on my show.
[00:29:01] Dagna Bieda: Absolutely. It was a blast. Thanks for having me, McKayla.
[00:29:04] Dr. McKayla: Yeah. Thank you. Bye.
[00:29: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 the 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.
-
This episode is sponsored by Tonic.ai – where your data is modeled from your production data to help you tell an identical story in your testing environments.
[00:01 - 07:22] Opening Segment
Need to generate fake data that looks, acts, and behaves like production data for your test environments? Check out Tonic.ai!Head over to https://www.tonic.ai/ and sign up today for a free two weeks trial sandbox!From full-time employment to consultancyOn why he calls his business the banana stand“There’s always money in the banana stand.”[07:23 - 21:54] Doing His Own Thing and Gaining Independence
Avdi on the difference between consultancy versus the banana stand modelWriting his e-book and getting into screencastsHow he managed a startup business, consultancy, and being a new father at onceThe reason behind the rebrand: From RubyTapas to Graceful.DevWhy Avdi is done subscribing to the corporate cultureThe unconscious bias in recruitment[21:55 - 31:42] Building on WordPress
Why Avdi chose WordPress as the platform for his businessWhat are the advantages over the other platforms?WordPress plugins: What you need to knowKeeping track of the changes and updates on the platform[31:43 - 41:46] Closing Segment
What’s next for AvdiHis advice on delegating and building your email listFinal wordsTweetable Quotes
“There's always the risk. There are no guarantees in this industry. There are no guaranteed retirement plans.” - Avdi Grimm
“I think a lot of people in software are completely focused on either financial scaling or on like user scaling. The kind of scaling you need to plan for is devolving stuff from yourself, removing yourself as a bottleneck” - Avdi Grimm
“Anything that I'm thinking of delegating or automating, always do it manually first, and do it manually for a while first and get a really good idea of what it is that I'm either delegating or automating.” - Avdi Grimm
Resources Mentioned
https://www.tonic.ai/ - Sign up now for a two-week free trial!Exceptional Ruby by Avdi Grimm - Get a copy of Avdi’s e-book at https://store.avdi.codes/l/NWtnkWordPressConvertKitLearnDashMemberPressWooCommerceConnect with Avdi on his site and on Graceful.Dev! Follow him on LinkedIn, too!
Let’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 after pleasure to talk to Avdi Grimm. But before I start, let me introduce you to an amazing startup that's sponsoring today's episode, Tonic.ai, the fake data company. So what does Tonic.ai do? I'm sure you know how complex and cumbersome it is to create quality test data.
[00:00:27] Dr. McKayla: It's a never-ending chore that eats into valuable engineering resources. Random data doesn't do it and production data is neither safe nor legal for developers to use. What if you could mimic your entire production database to create a realistic dataset with zero sensitive data? That sounds amazing, right? Tonic.ai does exactly that.
[00:00:50] Dr. McKayla: With Tonic.ai, you can generate fake data that looks, acts, and behaves like production data because it's made from production. Yet, Tonic.ai guarantees privacy so your data sets are safe to share with developers, QA, data scientists, heck, even distributed teams around the world. Visit Tonic.ai to sign up today or click the link in the show notes to get a free two weeks trial sandbox.
[00:01:14] Dr. McKayla: But now back to Avdi. Avdi has been a developer for over 20 years and runs, similar to me, a training and consulting business. The main difference is that he has been doing this already for over 10 years. So I'm super thrilled to pick his brain today around everything business-related. He's also a consulting pair-programmer and the author of several popular Ruby programming books and has several courses on this subject on his website, Graceful.Dev, formerly RubyTapas.com. So I'm super thrilled that he's here with me today. Avdi, welcome to my show. I'm very excited.
[00:01:51] Avdi Grimm: Thank you so much. I'm excited to be here.
[00:01:53] Dr. McKayla: Yeah, I'm super excited. So I've been following your journey on Twitter and so on for quite some time. Very inspirational as well. And I have a lot of questions around how you run your business and why you're running the business and what we can learn from you, right, a seasoned entrepreneur and self-employed person to also maybe get a little bit more independence in our life, right? So this is probably the main goal for myself, for everything that I do is flexibility and independence. So why are you running your own business and how does this come about? Why are you not a software developer in a company somewhere?
[00:02:32] Avdi Grimm: Right, yeah. I mean, to some degree, I feel like it's almost an inevitable career arc for somebody in software. You know, I know people who have avoided it, but a lot of the people that I kind of looked up to over the years went through, you know, they went through the full-time employment phase and then they gradually kind of moved out to becoming consultants and having various other side businesses.
[00:02:55] Avdi Grimm: And, you know, come to think of it, I never really thought about this much before. I had the example of my dad who worked in software and hardware design, and he was an independent consultant I was growing up. So that was kind of normalized to me to, like, have your own thing
[00:03:08] Dr. McKayla: Yeah, for me was quite different. Yeah.
[00:03:11] Avdi Grimm: I think that I, I saw that on the horizon maybe from earlier than some people do, just because it was, it was normalized for me, you know? And it just seemed like that's what a lot of my heroes did in the industry was eventually they became consultants.
[00:03:26] Dr. McKayla: Yeah. Yeah, it's good if you have like role models. For me, it was quite the difference. I always saw it that I will work at the company for a really long time and, you know, climb the career ladder somewhere. Actually, I started a family that I saw, oh, this is not working out as I expected. And as I would like it to work out, right? And so this was a little bit why I changed the thing. So you call it a banana stand. You don't call it like an enterprise or something. Why do you call it the banana stand? And what's your philosophy for your business? How do you run it?
[00:04:00] Avdi Grimm: So, yeah., I've started using the term banana stand recently, especially as I've been kind of reflecting back on, you know, over a decade of doing this and, like, my style of, of running the business and writing a little bit more about that. So the, the term banana stand, it comes from, the show Arrested Development in which one of the characters says to another, this character is trying to save the family business and his dad who is in prison keeps telling him there's always money in the banana stand, which he completely misinterprets the message and winds up, burning down a banana stand that's full of literal money in the walls. I apologize if I've spoiled the show for you, but it's been out for a while. But you know, like, that phrase stuck with me. There's always money in the banana stand and that's kind of the way that I look at it.
[00:04:48] Avdi Grimm: So there's kind of two sides to this, this independent business for me. There's the consulting side. And then there's the product side, product being kind of a broad term for selling books, selling courses, selling workshops. It's kind of a loose definition of product, but it's definitely distinct from the consulting side of my business, which is more like, you know, hourly consulting on people's projects.
[00:05:12] Avdi Grimm: And I definitely look at the product side as a banana stand as like something that I kind of run casually, even if I'm putting most of my time into it now. I still run it kind of like lazily and you know, and it's my own banana stand to putter around in. I'm not, like, beholden to any, like, schedules and I'm not on any kind of like track of, I have to, you know, make this much money.
[00:05:35] Avdi Grimm: I have to, like, make sure that my VCs get a payoff and stuff like that. It's just kind of like, you know, I get the putter around in the banana stand and work on whatever I feel like. And, you know, that phrase there's always money in the banana stand is kind of like that has informed the way I think about employment a lot, because, for me, if I'm in between jobs, I used to think of it as in between jobs, I don't think of it that way anymore, but if I'm in between jobs, quote, unquote, that's not like a time to panic and, you know, and, like, do all the interviews and freak out about how I'm unemployed. That's time to just focus on the banana stand.
[00:06:12] Avdi Grimm: And until something comes along, that makes sense. And I think that's been helpful to have that. And, yeah, that side of my business, really like, so we talked about consulting, but that side really came from early on, getting into e-book sales, which we can talk about how that story went if you want.
[00:06:28] Dr. McKayla: So if I understand that you would say there's the consulting, which is, you know, it's something that you have continuously to invest in and also make some contracts around that.
[00:06:37] Dr. McKayla: I'm also doing some consulting, which means like now I'm dedicating, let's say 30 hours for this project for three months, right? And so you are more or less sold out for that time?
[00:06:48] Avdi Grimm: It's kind of like a real job.
[00:06:49] Dr. McKayla: Yeah. It's like a real job, only that you have all the risks as well, which is even worse.
[00:06:58] Avdi Grimm: But there's a lot more, even there there's a lot more independence. And honestly, you know, one of the things that I value on the consulting side is that, I mean, yeah, you have the risk, but there's always the risk. There are no guarantees in this industry. There are no guaranteed retirement plans.
[00:07:13] Avdi Grimm: And what I don't have to do is I don't have to buy into a lot of corporate mission and values BS that I don't believe in.
[00:07:22] Dr. McKayla: Yeah. So you have your consultancy and then in between those consultancy gigs, right, when there are no consultancy gigs, you're not freaking out, you're working on your banana stand and you grow that, right? And the good thing it's about the products and, you know, this mindset, I think, is that even a little bit of work on them pays off, right? So it's a little bit like an investment. So you create another free course, maybe, and you have like a, you know, a good lead magnet, have people that are interested in your work.
[00:07:53] Dr. McKayla: Then you create a paid course when you have time and so on. And it stays, right? It's something that's there for longer, whereby the consulting, it comes, it brings normally quite good money, from my experience, right? In a very short amount of time, but then it goes away as well. While the banana stand, maybe it's a little bit, it's not this boom, now we have like all this money. But it's also not going away, right? Yeah, exactly. It's a snowball. It's a flywheel somehow, right? Yeah.
[00:08:20] Avdi Grimm: Yeah. I mean, you know, a consulting gig is one big blizzard that, you know, that melts the next week and a banana stand is a snowball that you just kind of gradually roll over the years.
[00:08:32] Dr. McKayla: And so how long did it take for you to have this banana stand where you could say, well, I have some predictable income that, you know, makes me sleep at night? .
[00:08:43] Avdi Grimm: So actually I think, you know, my trajectory there probably was a little different from a lot of people's. I kind of, you know, I put along having the book, the e-book business on the side for a few years, and that really just fell out of speaking.
[00:08:58] Avdi Grimm: It happened because I was giving talks at software conferences. And I was pouring a ton of time and energy into researching these talks. And I was like, you know, I wonder if there's a way to kind of recoup. You know, I have all this material that I put together. I can't fit it all into a talk.
[00:09:14] Avdi Grimm: And I wonder if there's a way to like recoup the energy that I've been putting into this. And that was really the origin of the first book, which was Exceptional Ruby, which is about error handling and failure management and I made a book out of like the, all the extra material that I put together for that.
[00:09:29] Avdi Grimm: And that was that kind of launched things. And so that was kind of a side business. It was a nice little side business for a couple of years. And then what changed was I decided to get into screencasting. I've been doing the books, I've been doing some podcasting and this was around, you know, this was like 20, maybe 2010, 2011, 2012.
[00:09:52] Avdi Grimm: A lot of programming screencasts started taking off. And I decided to get into that business. And I had a vision of like, what if we did that only much shorter and more focused? And, you know, just do like five minutes or less. You know, get one idea across at a time. And so, unlike most banana stand efforts, that was really like a do or die, not do or die.
[00:10:13] Avdi Grimm: I don't like that terminology that was a go big or go home. That's the phrase I'm looking for, go big or go home because I knew how much energy went into video production and it is a lot. And so it was like, okay, this is a project that I'm going to test the waters. If it does well, I'm going to try, you know, the only way this works is if I can make it into my full-time job, otherwise I'll just stop. And yeah, I got really lucky. I was coming in at a good time. People really liked the format. And so within, I think around a year or two, I was able to say, I don't actually need other jobs right now with the RubyTapas screencasts.
[00:10:49] Dr. McKayla: Oh, yeah. That's nice.
[00:10:51] Avdi Grimm: Yeah. So that was, that was kind of like line goes up. That was less, you know, slowly rolling snowball.
[00:10:56] Dr. McKayla: Yeah. And how much time did you spend in this line goes up phase? You know, because somehow when you're focusing on something, like doing the screencasts, you're not having an income, right? And then if you go to consulting, you don't have the time. So you have to switch between those boats of not having time or not having money. So how did you handle that at that time?
[00:11:17] Avdi Grimm: I didn't sleep. I had at least one new baby at the time, too. And, like, I was working consulting gigs. I don't know. It's kind of a blur at this point. I don't think that I could do that kind of thing again, unless it was a great need. 'Cause I was also, at that point at the beginning, I was producing three episodes a week.
[00:11:41] Dr. McKayla: Wow. Yeah, that's a lot.
[00:11:43] Avdi Grimm: Yeah. I was doing a lot at once and it was kind of nuts.
[00:11:46] Dr. McKayla: Yeah. And I actually really liked, with the whole style also, when I look through your blog posts and everything, right, you have your own style. You didn't call it like Professional Ruby screencast, you call it RubyTapas, right? And the tapas probably transport the message of it's small pieces of very digestible, tasty things, right?
[00:12:09] Avdi Grimm: And I feel like some of that probably also fell out of just like the Ruby, like, the community has always been super whimsical and kind of silly. And so, you know, I can't take full credit for that approach.
[00:12:22] Dr. McKayla: Yeah. But recently, I don't know exactly when, but you rebranded your whole RubyTapas into Graceful.Dev, why is that? For me, it seems like it's now broader and there can be more happening, but what's your strategic vision behind, you know, going from RubyTapas to...
[00:12:40] Avdi Grimm: I do not do strategic visions. I used to, but, man, I avoid strategy as much as possible now. I mean, that's okay. That's not true. I do a little, I do a little. But I try not...
[00:12:54] Dr. McKayla: You definitely have some reasoning behind it, right?
[00:12:56] Avdi Grimm: I try not to have five-year goals. Let's put it that way. I don't do goals. There's definitely some reasoning there. There's a direction there. I mean, the direction was one that I've honestly had in the back of my mind for a really long time. A lot of people don't know that, like, the same day in, like, 2011 or whenever it was that I registered RubyTapas.com and associated addresses. I also registered CodeTapas.com.
[00:13:20] Dr. McKayla: Okay.
[00:13:21] Avdi Grimm: So like, you know, I never wanted to completely limit myself to Ruby, strictly Ruby content. You know, I've worked in, God, like a dozen languages over the course of my career. And Ruby was just an area that I wound up focusing on a lot and wound up making a lot of money in. And enjoying, I really, really enjoy the language still and the community as well.
[00:13:42] Avdi Grimm: But I always had in the back of my mind, you know, that I would expand, but, you know, I didn't wound up not using as you'll notice. I wound up not using CodeTapas as the branding 'cause I was really, like, moving in a different direction, broadening not just in, like, in the technologies that I want to cover, but also I just spend a lot more of my time thinking about broader topics like, the sustainability of the development that we do and systems thinking, understanding the systems in which we work and the systems that cause the work that we have to exist. And yeah, so just, for a lot of reasons, it made more sense to me. And in some of my talks, I've been really focusing on the concept of grace.
[00:14:21] Avdi Grimm: So it just made more sense to me to move in that, that branding direction. And then recently I had the opportunity to finally, like, do a lot of the heavy lifting of moving content over. And so I took that.
[00:14:33] Dr. McKayla: Where did this opportunity come from?
[00:14:35] Avdi Grimm: Well, so I had a point a few years back where I was like, okay, you know what? I've been sort of off on my own, doing my own thing for a long time. I would like to get back into, like, the hustle and bustle of being part of a big team that's making something real in the world. And I spent, I don't know, a year or so interviewing pretty seriously at a bunch of different places. And that did not go as expected.
[00:15:00] Avdi Grimm: And I finally decided that I, wasn't going to focus on that anymore after all. And I was just going to get back to the banana stand 'cause there's always money in the banana stand. And that has been actually an immensely satisfying experience, kind of coming back to it with a fresh, fresh, like maybe this is my calling perspective.
[00:15:18] Dr. McKayla: Yeah, I actually followed this journey a little bit on your Twitter, you were sharing it with us and also the hassle of the whole, you know, getting naked in front of strangers, you know, and really selling yourself. And I mean, you have been in the industry for so long, you have shared your learning.
[00:15:38] Dr. McKayla: You know, you have some portfolio online. It's not like somebody comes and has no idea about you, but still, it felt like at least what I got out of the tweets, right. What I read into them was that every interview was a little bit, it wasn't really like keeping your dignity, right? So you had really to get naked in front of them to do all these silly things.
[00:16:03] Avdi Grimm: You know, I wouldn't, I actually, I would argue that it's not, it wasn't really about being naked. It wasn't really being, about being transparent. It was about people wanting you to do a very special dance for them that strokes their ego and me being at a point in my career and life where I'm just like, I'm not going to do that. Why would I do that? Looking back I got some actually really nice offers from some, you know, well, large companies anyway, but in the end I was not comfortable taking any of them. And in part, because of what I saw during the interview process.
[00:16:39] Dr. McKayla: Okay, what did you see?
[00:16:41] Avdi Grimm: Well, you know, so actually, let me tell you about something I just heard recently from a friend of mine, because I hear the same story over and over again. Like my story, what I've realized is my story is not at all unique. So just the other day I heard the story again of like, basically, you know, an extremely senior well-respected brilliant engineer gets asked by a friend that works at a FAANG, you know, works at one of these giant unicorn Silicon valley darlings, gets asked to come interview there. It's like, we'd love, you know, I'd love to work with you here, which is basically what happened to me, a number of different places. And, you know, so they kind of go into the interview silo and then they go through this process where in, you know, in this particular case, like they got interviewed by someone who was totally unrelated to the group that wanted to hire them because this is the way the process works. You know, we don't want bias in the system. There's a lot in these processes that are supposedly about eliminating bias, it's actually creating it.
[00:17:42] Avdi Grimm: We can talk about that more in a minute, but, you know, was interviewed by someone totally unrelated to that team. And basically, they were like, you know, show that, you know, by heart, my favorite algorithm,
[00:17:55] Avdi Grimm: I happen to have a favorite algorithm. You're going to show me that you can, you can identify that I'm thinking of this algorithm and then you can write it by heart. And like that wasn't an algorithm that this engineer had used before. And so it wasn't one they thought of, you know, I've got a lot of stuff in my background where it's like, I know of algorithms that probably most engineers haven't heard of because they happen to be useful for networking middlewares and I hear this all the time.
[00:18:18] Avdi Grimm: Anyway, they got flunked out because they couldn't, you know, reproduce somebody's favorite algorithm from, by heart. And this is somebody with, like, close to my level of experience. It's nuts. And I keep hearing this. It's actually, you know, I've heard this from a lot of people, with my, lot of friends of mine, with my level of experience in the industry, that these systems, they're really tuned to find people that are exactly like the people who designed the system in as many ways as possible.
[00:18:47] Dr. McKayla: Yeah.
[00:18:48] Avdi Grimm: Like, for me, I don't care. I am a white guy with plenty of opportunities and a banana stand. You know, I can fall out of a process like that and be fine. But what I'm seeing is that these processes are also, I mean, they're very gatekeep-y and they're very clicky. They're very in-crowd, they're very, very, like, we are expecting people that sort of show the secret insignia of a very select group of Silicon Valley insiders, basically.
[00:19:18] Dr. McKayla: I think one of the problems is also that they often require a tremendous amount of preparation, right? And if you think you are an experienced engineer, maybe at that point, you have a family, for example, around, right.
[00:19:33] Dr. McKayla: And some other commitments, it gets really hard to study some, you know, lead code examples, just to be as fast as, you know, somebody else, right? And I think this is also something that I criticize a lot when I'm thinking, and then you don't even need that, you know, you don't need that knowledge. You could really solve real-world problems.
[00:19:51] Dr. McKayla: You have some experience and background, right, that you have worked on. And it's probably also super challenging. So looking really at what that person has already achieved in the last, let's say 15 years would be, you know, and then really let them explain that in-depth, which shows that they probably can learn, you know, whatever problem or solve whatever problem you throw at them. It would be a much better way than, you know, getting back to bubble sort and, you know, and linked list or something, right?
[00:20:19] Avdi Grimm: And this, this is a big part of where the bias is in the system, and this is why I get sort of morally outraged by it, you know? I don't do well in these, you know, I might not do well in these because I'm at a point where I just can't be arsed to do that much homework of like learning somebody's arbitrary favorite algorithm.
[00:20:36] Avdi Grimm: But what they're implicitly biasing towards is the sort of stereotypical young white dude that has all the time in the world and doesn't have a family to support and doesn't have any disabilities. And, you know, I could list off a lot of, you know, a whole lot of privileges there that go into that sort of their really looking for that person who has nothing else going on in their life.
[00:20:59] Dr. McKayla: Exactly.
[00:21:00] Avdi Grimm: You know, so that they can then like induct them into the cult of your passion is your software career. And that bugs the heck out of me, you know, and I see this really like, you know, who is really hurting is people that come from backgrounds that aren't like mine and have other stuff. They have people that they're taking care of. They have kids, they have elderly parents, they have families that they're sending money to, and they can't afford a, you know, a break in their income while they spend six months, you know, doing nothing but the interview game. You know, there are so many things, and the people that are, you know, so many minorities in this country already have, in the world or, you know, minoritized people, I shouldn't say have so many other calls on their time because of the way society is already stacked against them. That it makes it impossible to jump through these.
[00:21:48] Dr. McKayla: Yeah, I totally agree. I totally agree. Yeah.
[00:21:51] Avdi Grimm: Sorry, I get worked up.
[00:21:53] Dr. McKayla: No, I want to come back a little bit to your banana stand again because this is the way out for, for you. And it's a little bit the way out for me as well, right? So with Graceful.Dev, I don't know if you had that before. You had RubyTapas and you had like the courses, but Graceful.Dev is now a full-fledged membership site, right? So you have different courses and you build it on top of WordPress. Why did you go this route? I mean, you could have like your courses on some third-party platform, right? From, I don't know, Teachable or whatnot, you know, many, many different PODR and so on. But you host it yourself and then you have the membership site as well. And you do that. Why does choice, like, I'm also thinking about right now, awesomecodereviews.Com for example, runs on, I switched from WordPress to Gatsby. So it's a static side and I'm thinking on how to give it a membership capabilities.
[00:22:49] Dr. McKayla: And I looked at SurplusCI and so on, but why did you go for WordPress? And are you happy with it? And what's the philosophy behind it? What do people get from this membership? What do you want to build? Probably there's a community behind, right? And some, some visions that you have for that.
[00:23:06] Avdi Grimm: This is an opinion I've kind of come to over years of using many different systems. And there's continuum here because you know, a lot of people running, particularly running education sites for developers have rolled their own system from scratch. They've built their own servers or their own applications.
[00:23:26] Avdi Grimm: And so, you know, there's that continuum all the way from roll your own to, you know, use a completely hosted service, like Podia, Thinkific, whatever, you know, and I've, I've tried a lot of these different things. I started Ruby topis out on somebody else's platform.
[00:23:39] Avdi Grimm: And it was super limiting. You know, there would be things that people were asking for for years and they just, that feature wasn't a priority for the platform because you're competing, you know, you're competing with all the other people who use the platform. And for, you know, whose feature is most important.
[00:23:54] Avdi Grimm: So it was very limiting to use a hosted platform, and I've periodically I try them again and they're always, there's always like something pretty early on, it's like, wow, I really need this feature. And I don't have it. But I've also toyed with building my own. I did that for a few years and you know, what I realized was, if I did that, my show was going to become about building an app to support the show, because that's what I was going to be spending all my time on, because it's a lot of work to build.
[00:24:23] Dr. McKayla: It's a lot of work, yeah.
[00:24:25] Avdi Grimm: People don't realize, you know, how many features are expected in an application that sells content and serves content and keeps track of people's progress in the content, et cetera, et cetera, et cetera.
[00:24:38] Avdi Grimm: And yeah, I just, that was not the show that I wanted to be doing was, you know, I didn't want to be like here's videos about how to build a place that hosts these videos. So WordPress has turned out to be a really happy medium kind of between those two extremes. WordPress is just incredibly mature software.
[00:24:56] Avdi Grimm: There's a lot of people in, particularly, the developer world that are kind of biased against WordPress and sadly against like the PHP ecosystem entirely, which I think is really undeserved. There's a lot of really, really good people working in this space. And the ecosystem is just amazing because you can kind of build anything you want and you can get as little or as much support as you want.
[00:25:20] Avdi Grimm: You know, it's easy enough to build your own plugins for WordPress to just do a little tweak here, a little tweak there. You know, the architecture of it really supports the idea of exposing everything it does as hooks. And then you can hook your own stuff into those hooks, which is why it has this great plugin ecosystem.
[00:25:36] Avdi Grimm: But one of the really cool things about the plugin ecosystem around WordPress is A, there is a plugin for everything, like, anything you might want to do. Somebody has got a plugin for it. And B, usually they have, like, a premium version, which comes with support. And I have had the best experience with premium plugins for WordPress.
[00:25:55] Avdi Grimm: Like, you know, people just like being very responsive to the people that are giving them money and coming back and, you know, with bug fixes or like going into the, you know, going into your site and making, figuring out why it's not working. And so it's like, it's one of the rare places I've seen that people are putting out a ton of open-source software, but also getting paid for their work.
[00:26:16] Avdi Grimm: Because all these plugins, like the base version at least, is always open source. And then basically you're paying them for maybe some premium features, but mainly for a support contract and, you know, and so people are making their living, creating open-source software. And I think that's pretty cool. And it's also, it also has done really well for my business.
[00:26:32] Dr. McKayla: Yeah, and it's true. And so when I'm thinking about your course software, did you get a plugin for that? Or did you have to write it yourself or do you have like a plugin and then extend that on your own? How does that work? You're hosting your videos, but then they're also like, you know, questionnaires, for example, some quizzes, you know, as you said, you see that people, you know, it somehow tracks the progress of the people. It has to know that you're a member that can access that course, the other course. All of that functionality, does it come out of the box with some plugins for WordPress? Or did you have to implement that yourself or was it a mixture that you're actually getting a plugin and then you can, you know, enhance that with your own code?
[00:27:15] Avdi Grimm: Great question. So, there are two to three categories of plugins that go into a site like this. I mean, my website has a lot more plugins than that, but there's sort of maybe three basic pieces. And one is learning management system LMS, otherwise known as courseware. So that's a category of plugins I could probably reel off maybe six of them off the top of my head, I'm personally using LearnDash, which is one of the older ones and one of the more, probably the most popular one in WordPress right now. And it's very mature. It's a little clunky for me sometimes because it's really targeting in many ways, it's targeting like serious learning institutions where they have like accreditation concerns and certificates.
[00:27:59] Avdi Grimm: And like, you can't take this course until you take this other course, lot of stuff that I don't care about. On the flip side, it's very mature. They handle all the things that I might want to put into it. They just also, also a lot of stuff that I don't care about. And then, so you've got, like, there's learning management, that's one. There's membership, which is like another whole category of plugins, which are generally focused around, given this account, what material does this person have access to? And that includes courses, like what courses does this person have access to.
[00:28:28] Dr. McKayla: So they work nice together, LearnDash and the membership thing.
[00:28:30] Avdi Grimm: Yeah, so generally what you see, so I'm using LearnDash on the LMS side, I'm currently using MemberPress, which is one of the more popular membership management plugins.
[00:28:39] Avdi Grimm: Generally these plugins, they work hard to work with each other, you know, different teams usually, but they work hard to work with each other because that's where a lot of the value comes from. And so they have explicit support for each other. And then the third piece often is like your e-commerce, how you sell the thing.
[00:28:56] Avdi Grimm: And that is often a separate plugin as well. Like in the WordPress ecosystem, it's usually WooCommerce. Sometimes it's EDD, Easy Digital Downloads. Now I've reeled these off like they are distinctly separate categories, but actually almost everyone in each of these spaces will happily give you like all of the above kind of in one.
[00:29:18] Avdi Grimm: Because they all kind of, they'd grow, all gradually expand out to include each other's features. So like LearnDash, you can do a pretty basic membership management using the groups that are built into LearnDash. You can sell courses directly. Like they have Stripe integration and stuff directly from LearnDash if you want to, it's kind of basic, but it's totally there.
[00:29:36] Avdi Grimm: MemberPress recently introduced their own courseware plugin for MemberPress. You can just like stick with that company if you want, as long as you're okay with like a more basic courseware offering. They also have the storefront part built in if you want to use it. So there's a lot of blur between these plugins as well.
[00:29:54] Avdi Grimm: Yeah.
[00:29:55] Dr. McKayla: Yeah. Okay, cool. And so are you then enhancing that, is that possible, especially if you have like the paid version, could you just write that? And then how do you keep track of your own changes and new updates that are coming from the team? How do you integrate those things?
[00:30:09] Avdi Grimm: So one of the marks of a good industrial strength WordPress plugin is that they have well-defined hooks. You know, I was talking about like, WordPress is built on the concept of hooks. They have well-defined hooks that are documented. And so, like the ones that I work with do, they have good documentation sites and they have all these hooks that you can like, here's how you change this, you know, here's how you hook your own thing into this particular part of the interface or this particular process.
[00:30:36] Avdi Grimm: And then, so what I have is what they call a site-specific plugin that I keep under version control, and I have a deployment system for that pushes it out to my way. And my site-specific plugin, basically just very selectively has a few, there's a few hooks where I want to customize something in one of those other plugins.
[00:30:54] Avdi Grimm: And it just like hooks its own handler into just the, like the very specific hook that is one tiny piece that I care about changing. It's very small. The site-specific plugin is very small. I try to keep it very small and very focused.
[00:31:07] Dr. McKayla: Okay. But so it has a valid defined API or hooks that you can really enhance. You're not going in and hacking in their, in their code base, right? So you're on the outside, whatever they allow you to change.
[00:31:18] Dr. McKayla: Yeah. And if you're going to really get into this ecosystem, that's one of the things you want to keep your eye out for is like, does it seem like these people are really supporting that kind of external hooks?
[00:31:28] Dr. McKayla: Yeah, it sounds very interesting. And I know quite a couple of people that are running WordPress websites and have a lot of, you know, like you said, WooCommerce, or like a membership sites and they're very, very happy with it. Maybe my last question for you is around, you said you are not going to plan for five years and so on, right? But I think everybody has some, some vision you know, some, some reasons why you'd be doing things like transitioning from RubyTapas to Graceful.Dev, right? What do you see yourself, do you want to do, is there a possibility that Graceful.Dev is really your full time thing and that you're not doing any consulting or do you want to keep doing consulting on the side? Or, you know, where are you heading towards, what's your ideal case?
[00:32:16] Avdi Grimm: I wish I had a good answer for you. You know, I want to keep being able to do what feels right at the time, which is kind of what I'm doing right now. You know, Graceful.Dev is supporting me pretty decently along, you know, that alongside of my other, you know, other products and things. You know, I take consulting gigs as they look interesting.
[00:32:35] Dr. McKayla: Yeah, and are you a solopreneur or do you have, like, a team that really helps you?
[00:32:39] Avdi Grimm: Oh yeah. Good question. I don't have any full-time employees for years and years. I've employed people very part-time here and there, only ever like a handful only ever like maybe three to five at most, at any given time. Actually five is probably more than I have, but like I have somebody that's I've worked with for a long time, that handles kind of first line of support.
[00:32:59] Avdi Grimm: So support emails first go to them and then they escalate them to me. I have somebody I'm working with now who's doing a lot of, like, helping me with content, like doing video editing or fixing up blog posts that have become, like their formatting has gone wonky or is out of date or something like that. Yeah. So I have a few people that just like very part-time helpers.
[00:33:21] Dr. McKayla: Yeah. I'm currently right now in this position of getting people and I find it really difficult finding the right people because, you know, if you're already in this, okay, I need help now. I don't know how you overcame that stuff, but for me, it's like, I need help now, and I can't grow, you know, without this help. But I also can't really make the time to find the right people and to teach them and do onboarding.
[00:33:44] Avdi Grimm: And that is, that is the classic catch-22. And there's no easy way out of it. You know, the point where you absolutely don't have, like, you don't have the overhead space to train somebody, but you need to train somebody in order to get the overhead space.
[00:34:00] Avdi Grimm: Yeah, I wish I had an easy answer for that one, like that parts of slog. And eventually you kind of pull your head above it, but it's hard because, yeah, like the effort involved in like getting through that catch-22 is exhausting. I will say this about it. And, and this has informed my work for a long time.
[00:34:20] Avdi Grimm: This is the most important kind of scaling to plan for. I think a lot of people in software are completely focused on either financial scaling or on like user scaling, you know, the, your user base scaling up like our, will our code base support unicorn scale. That is by far like the least common form of scaling that you have to support.
[00:34:42] Avdi Grimm: The kind of scaling you need to plan for is devolving stuff from yourself. Taking, removing yourself as a bottleneck. That is the most urgent and immediate form of scaling that you're going to face. And so one of the reasons, I have a lot of reasons, but one of the reasons that I use WordPress is because it is the dominant player.
[00:35:02] Avdi Grimm: Like, it powers like half the web now, and there is this huge ecosystem. And if I need somebody to do like copy editing, I don't need to teach them how to use GitHub and like commit things, you know, I don't need to find a copy editor, but then teach them how to use my special, precious bespoke system.
[00:35:20] Avdi Grimm: They know how to use WordPress, whoever they are, they know how to use WordPress. And you know, if I need to get somebody, you know, if I want some help with my site because I don't have time to diagnose one particular bug, it's really easy to find WordPress consultants, and there's just so many things there where it's easy to find people that can do the thing that you need help with.
[00:35:44] Avdi Grimm: And that's just as a general kind of policy. That's one of my biggest considerations when choosing anything is not, you know, not is this going to scale up, but can I scale it away from me? Can, you know, can I remove myself as the bottleneck for this in the future?
[00:36:00] Dr. McKayla: Yeah. Yeah. That's such a good mindset. And I'm currently learning a lot with it and you know, it takes much more time and much more energy than I thought, but I also see that, you know, if you have already one person, right, so finding this one person, it means that you have to work with six different people. And then you realize, oh, it's, you know, it's, it's making more trouble that what I'm getting out of.
[00:36:23] Avdi Grimm: Yeah. And I should say here, like, use my bad example for learning. I hit a crash at one point where I really wasn't like I was, my outgo was bigger than my income. And a big piece of that was that I had, I had tried to devolve too much of myself. You know, I tried to become too big and pay too many people to do too many different things.
[00:36:45] Avdi Grimm: And the funny thing about what was happening there was that I was still swamped. I still had too little time. And it was because I had basically, you know, installed myself as a manager and I was spending all of my time helping people get unstuck and managing things. And so, yeah, it's really easy, like once you, once you kind of start going down that delegation road, it's really easy to go too far.
[00:37:10] Dr. McKayla: Yeah. Yeah. I think, I think one step at a time and keeping the focus like I really would like to create more content, have more of this really quality time doing what I love to do like teaching, thinking about content, writing blog posts, right?
[00:37:25] Dr. McKayla: This is really what gives me energy and less about the administrative stuff. But then, as you say, I have to be real careful not to get people adding to my administrative stuff. So, yeah. But yeah, very, very good.
[00:37:38] Avdi Grimm: I think it's important to always know that like you can do the thing. One of my personal policies is like, anything that I'm thinking of delegating or automating, always do it manually first and do it manually for a while first and get a really good idea of what it is that I'm either delegating or automating.
[00:37:55] Avdi Grimm: And usually what I discover is that I can automate less of it than I was planning. And it's enough. Or I can delegate less of it than I was planning and it's enough, but yeah, as it's always very tempting to be like, man, there's this one aspect of my business. I just don't want to think about at all. And so I want to delegate, delegate that part of it.
[00:38:13] Avdi Grimm: And I think that's really dangerous though, that leads down that road of like now I'm just jammed up managing everyone and paying too much, you know, not balancing my books.
[00:38:22] Dr. McKayla: Yeah. I think that's true.
[00:38:25] Dr. McKayla: Do the thing the hard way for a while, figure out the smallest piece of it that you can automate or delegate.
[00:38:31] Dr. McKayla: Yeah, cool. So Avdi, thank you so much for sharing all your insights. Is there something like, if there are developers out there that think, oh, I would like to have some side hustle, you know, get a little bit more independence or maybe even go full in, what do you think what is a, is a good strategy nowadays?
[00:38:50] Dr. McKayla: You know, when there are already so many, screencasts, when they're already, you know, so many other things, so many blog posts, so many podcasts and so on. What do you think? How should people start doing it? Is a blog still a good first outlet?
[00:39:04] Avdi Grimm: There's no going wrong with blogging. Honestly, like, it really doesn't matter like what your plan is. Get good at writing about things. Like, practice writing. It's just that I feel like that skill has informed, has improved so many other aspects of my business and of my career. I mean, writing about what you learn is such great practice for even if you just stay a regular developer, you're going to be a better developer because you are better at explaining and documenting your work to other developers. And so like, yeah, there's just no downside to getting in the habit of writing all the time about the work that you're doing.
[00:39:46] Dr. McKayla: Yeah, that sounds good. Yeah, I think so too. I think that's a such a good advice. There's I think there's so many positive things that can come, be that job opportunities or maybe you have to jump on, you know, you get better as, as you said, in your communication skills, better at communicating with your colleagues and so on. So yeah, I think this is a great, this is really a great insight. Thank you so much, Avdi.
[00:40:09] Avdi Grimm: Oh, I have one other thing on that, on that note that I should include. Start building your, your mailing list now.
[00:40:16] Dr. McKayla: Mailing list, yeah. Good idea. Independent mailing list, I would say.
[00:40:20] Avdi Grimm: You know, do that blog thing and then slap, you know, go with ConvertKit or something and slap a mailing list, subscribe on that thing, and just start collecting that snowball now, because that, it takes a long time, but oh my gosh, the opportunities that come out of having a good mailing list. There's nothing else like it.
[00:40:38] Dr. McKayla: Yeah, that's true. Yeah. I think that's a great add, great addition to what you said before. So Avdi, thank you so much for taking the time and talking with me and sharing everything with my listeners and yeah, have a good day.
[00:40:53] Avdi Grimm: Thank you so much for this. I really enjoyed it.
[00:40:55] Dr. McKayla: I enjoyed it too. Thank you so much. Bye bye.
[00:40:58] 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 the 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.
-
This episode is sponsored by Tonic.ai - where your data is modeled from your production data to help you tell an identical story in your testing environments.
Yehonathan is a software developer, author, and speaker. He has tons of experience in full-stack development using various languages such as Java, Javascript, and Ruby. But his favorite language is Clojure. He bundled all this experience and knowledge into his book Data-Oriented Programming, which is already available for beta-readers on Manning Publications and should be finished this summer.
[00:01 – 06:35] Opening Segment
Check out my latest project: Awesome Code Reviews!Visit https://www.awesomecodereviews.com/ to find articles about code reviews, best practices, code review checklist, news about the latest research and code reviews, and workshops and courses about this topicWant to read Yehonathan’s book, Data-Oriented Programming?Like and retweet today's episode now and get a chance to win a digital copy!Introducing a simple way to eliminate the complexity of information systemsWhy should we unlearn objects?Relating meditation and object-oriented programming on how we perceive reality and cause accidental complexity[06:36 – 17:52] Data-Oriented Programming Defined
Data-oriented programming vs Object-oriented programmingSeparating data representation and data validationThe map is not the territoryData-oriented programming vs Functional programmingUsing generic data structures in data-oriented programming instead of custom typesThe profusion of types creates complexity[17:53 – 23:17] Changing Codebases to Data-Oriented Programming
The four principles of data-oriented programmingMixing data-oriented programming with functional and object-oriented programming is possibleComparing information systems vs data-intensive applications[23:18 – 28:21] Closing Segment
The story behind Yehonathan’s bookHe shares one of the best experiences in his writing journeyWin a digital copy of Data-Oriented Programming!Final wordsResources Mentioned:
Awesome Code Reviews - Visit for helpful information and courses for you to try!Data-Oriented Programming: Reduce Complexity by Rethinking Data - Check out Yehonathan’s book!Visit Yehonathan’s website and follow him on LinkedIn to know more about data-oriented programming.
Let’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.
-
Subscribe on iTunes, Spotify, Google, Deezer, or via RSS.
Book your awesomecodereviews.com workshop!
Links:
Emma's TwitterEmma's Interview BookLadybug PodcastStudy on Effects of Technical Interviews by North Carolina University:Blog postResearch PaperYou can also help make the podcast more accessible, by helping to edit the transcripts. You can find them on GitHub. Edits can be added trough pull requests (preferred), or by sending me an email.
-
Paige is the director of Machine learning and machine learning operations, aka MLOps, at GitHub. Before that, she was a principal product manager at Microsoft and also worked on DeepMind and Google Brain. Paige has had over a decade of experience with machine learning and data science as a practitioner.
Check out my new project awesomecodereview.com workshop!Links:
Retweet and like to win access to GitHub Codespace, including CopilotTiferet’s work, using machine learning to detect security vulnerabilities in source code.VS Code’s Python extension and Jupyter extension.Copilot website (make sure to download the Copilot Nightly extension, to get the latest features!)Applied Machine Learning Scientist – Microsoft job opening here!Github – Use it for your work and tell us how we can improve!Shownotes:
[00:01 – 10:53] Opening Segment
Check out my latest project: Awesome Code Reviews!Visit https://www.awesomecodereviews.com/ to find articles about code reviews, best practices, code review checklist, news about the latest research and code reviews, and workshops and courses about this topicGet a chance to try out GitHub Codespaces and other extensions like GitHub Copilot!Like and retweet today's episode, and for an additional chance to win, you can also leave a comment about what kind of data science work you're currently doing or what you like to doThe responsibilities of a director of machine learning and machine learning operationsDemystifying the process of reviewing complicated data science code[10:54 – 20:54] A Helpful Collaborator As You Write Codes
How GitHub Copilot becomes your partner and collaborator when writing codesIt is an extension for VS Code and generates source codeLearning from test cases and how code reviewers can perform a better jobAcquiring accurate code snippets through understanding the specific requirementsThe strive for consistent performance across every single kind of language[20:55 – 35:25] Expanding Feature Capabilities for Optimal Functionality
The beginning of deep learning techniques applicationThis targets detecting security vulnerabilities through code reviewsIt also provides recommendations for extracting functions from blocks of codeEncouraging consistency in names and stylesTake note: Microsoft is hiring!Striking the balance with deep understanding of data-driven and quantitative approachesData can tell us about users who are already using our tools, but not about those who haven't tried them yetThe key is to remain curious and constantly seek to better understand users[35:26 – 37:52] Closing Segment
Paige’s recommendation for youTry out GitHub for your machine learning projects!Final wordsResources Mentioned:
Retweet and Linke this tweet to win access to GitHub codespaces and copilotAwesome Code Reviews - Visit for helpful information and courses for you to try!Applied Machine Learning Scientist - Microsoft job opening here!Github - Use it for your work and tell us how we can improve!Tiferet's work, using machine learning to detect security vulnerabilities in source code.
VS Code's Python extension and Jupyter extension.
Copilot website (make sure to download the Copilot Nightly extension, to get the latest features!
Let’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.
- Mostrar más
