Episode 3 Transcript: The evolution of learning during our lifetime

This is the full transcript of the third episode of Inherited Composition. You can read it below, or listen to the episode

Gonto: Welcome to the third episode of "Inherited Composition." I'm Gonto, your host, and I'm here with Guido. Say "Hi."

Guido: Hi everybody.

Gonto: In this episode, we're going to talk about learning and how that changes throughout the years. At first, when you're a junior developer or a junior marketer, you're like a sponge, trying to learn every new thing, every shiny thing that appears, etc. But is that good? Should we always do that? So, we'll first be discussing about, like, you read new blog post about a hype and you want to use that hype. Is that good? Should you do that?

Then we're gonna move to talk about, sometimes you see, like, older people, and you think, "Hey, they are comfortable. They don't want to learn new things. They don't want to apply them." But, is that really the case? How does that happen?

Then we're gonna talk a little bit about, like, clickbait titles. Like, "What are the top 50 things you can do to improve SEO?" "What are the 20 things you can do to improve your life-cycle marketing?" Should we read those blog posts? When, how, and why?

Then we're gonna talk about, we're in the time of, like, information, and there's so much information that one of the hardest things is separating real information and things we want to learn with noise. So, how do we do that? How do we avoid, also, analysis paralysis of continuing to read and learn new things? And then, finally, we're gonna have a final question about, like, "Then, is it good to learn new things, what things is it good to learn, and why?"

So, let's start with the first one. So, as I said, the first part I want to talk about is like, you read a new blog post about a hype, and you want to use that hype. So, I have some questions in here. For example, yeah, you use that hype, and then you ship it to production. So, what happens then? Like, do you have bugs? Who supports that? How much time and effort was put into that blog post? How does that work? So, what are your thoughts on this, Guido?

Guido: Yeah, I think as a junior developer you're always trying to learn and, you know, use the new, shiny technology. And you can, you know, talk about you using this framework and being one of the first in the community to have experience with. And then you try to do everything possible to use that. Maybe in your product, or maybe when you're working for a client.

But, maybe you forgot to consider other things apart from, I don't know, like, the language syntax or how easy it is to implement a particular feature with that framework. As you said before, like, community. And I mean, like, the size of the developer community and also the companies that are behind those technologies. What happens when you don't know how to do something with that particular technology? Is documentation good enough? Do you think that that technology is gonna live at least for the next five years?

So, maybe those are the things that you don't consider, and after a while, you start seeing problems because you decided to choose for a particular technology just for the syntax or for some particular feature.

Gonto: And besides that, something that happens is, like, is there support? So, sometimes, like, there are companies that support, like, open-source frameworks, and you pay them for support. Like, do those companies exist? Because maybe you will need that, as there are new bugs, and then nobody's using that technology. And something that happened that I would consider related to that is, like, at first, for example, like, we were working with some of the new, shiny technology at that time, and we were, like, working faster and faster to deliver new features. But then, now we have a product where it's using, like, some old technologies. Nobody's maintaining it. There's no community. So, how do you make changes? And it's hard. And you need to read the old documentation, or read the source code, or those kind of things.

So, it's starting to be harder now, and we're working on, like, how do we migrate to a new technology part-by-part? And you start feeling that technical depth, and that technical depth starts to slow you down. So, then, how do you separate also, like, working on that technical depth versus, like, working on the new stuff? So, maybe sometimes, like, working on, like, these new hypes, you just think on the present moment, the learning that new thing, but then you don't think of, like, what Gonto in two years is gonna say about that technology. Because in two years, maybe, they don't have... Like, AngularJS. A lot of companies worked on AngularJS 1. Now it doesn't have that much support, not that much community. So it's getting harder and harder, for example, to work with that technology. And even more with Components, by [inaudible 00:04:30]. It was, like, their thing to use, like, Components and, like, with dependencies. We used to have that, but now nobody uses that, so how do you work with that?

Guido: Yeah, and also, there are other things to consider, especially if you are in a situation of having to choose technology for the next years for your product. For example, what about getting new talent and onboarding new engineers to that technology? And again, there is no rule of thumb here. It depends a lot on the context. But you need to consider that maybe that new technology or that new language that has really cool features, then it's gonna be really hard for you to get talent and to train them to use it.

And there are stories on both sides of here. For example, I've been following the community a lot, and I'll need, say, a functional programming language for doing front-end development. There's a company that's behind that do a lot of that language that's called Novra, Inc. [SP]. and they've been telling a lot of about being, really, easier for them to get new people because there are a lot of developers that want to use that technology. So they got a lot of applications since they're starting backing the language. And I've heard similar stories for people that are looking for a Haskell developer, for example. They get really good talent because, in order for you to be a Haskell developer, the learning curve is harder.

But there are also stories of other technologies where, for example, it's really hard getting developers in the market for that particular technology. So, in those cases, maybe going with a more traditional or not-as-cool technology is a good solution. And this is a conversation that I have a lot with clients when I tell them, "I'd prefer to go with Ruby on Rails. We may not be as sexy as five years ago, but it's proven. It has a really good community behind it, and it's easier for us to get talent."

Gonto: And also, like, something that to me is interesting is that there are a lot of articles about hype, and something that I always do is, like, check the date of the developers. Like, when was it created? So, if it's old, then maybe what they are saying about the support, the community, etc. is not really that new. I also check, like, who is the author? What is their street cred? Have they spoken at conferences? Have they done research on this? Have they created a framework?

And then, based off of that, you can also think about...that gives you context to think better about their blog post. Like, at least for me, because maybe if it's done by somebody who doesn't have experience working on that technology, doesn't have the street cred, and is only writing one blog post about it, maybe the things that he or she is telling me are not that interesting or are not that important to me. So, that's another part, another tip that I always do for checking, like, if it's worth reading a blog post on a particular hype.

The second problem that we want to work on is...so, we were saying, like, when I was a junior developer, I remember I was seeing sometimes, like, older people. I was working in Globant, and I was seeing older people there. And I remember one of the guys told me, like, that he hated new technologies and how the world was because there were so many options. He actually only liked working with Microsoft because it was, at that point, closed-source. C# and only, like, a few frameworks you had to use. But Java, at that time, had, like, so many frameworks, and he hated that because you had so many things to learn, so many hypes. And at that point, it was like, "He doesn't work anymore." Like, "Why is he not wanting to learn new things? Why does he hate all of these, like, so many repositories, so many frameworks, so many things?" But maybe that's not the case. Maybe these, like, older people have some thinking about this that we don't know. And, why don't they want to learn some of these things? So, what are your thoughts on that, Guido?

Guido: Yeah, and I remember when we were working together that I had a similar feeling with people I respected a lot from that company, that they thought of us as maybe the loud kids trying to play with new things. And sometimes they gave us the space just to play and, you know, be happy with that. But then, over the years, I understood why they were skeptical about using new technologies that weren't proven enough. And again, you may find people that don't want to learn new things and aren't comfortable with what they're doing. [inaudible 00:09:01] But that's true, that happens.

But also, the thing that you need to understand is that people that have more experience than you have a lot of issues, and been...probably suffer from the choices that your junior developers made about technology. So, it's important to understand their position, and trying to have a conversation with them. And saying, "Is this just because you don't want to learn a new thing because you're lazy, or because you don't want us to spend time losing focus, and just doing research, and not moving forward with the project?" So, I think it's a matter of, you know, having the right context to know when you have time to explore new things and when you need to ship and be comfortable with that.

Gonto: Something else that I think that you learn as you have experiences is that technologies, frameworks, marketing tactics, etc., everything...like, history, I think, in general, is like a cycle, that it always repeats itself. So I remember, like, back then, a lot of time ago, like, you had the mainframes. And it was, like, a central computer power, and then the computers were just, like, dumb screens that you sat at. From there, we moved to something where now our computers were, like, really powerful. Lots of processors, lots of RAM, and all of the applications were done in that computer. That was the era of, like, desktop applications. But then we moved to the era of internet, where most of the processing power and most of the things are done in the cloud. And then our computer, this just shows the contents. So, we're basically kind of going back to mainframes. Even though now it's the cloud. the idea, the concept is the same thing.

And I think that the same thing happens, with example, with frameworks. So, for Microsoft, there was a framework called CAB, and it was around, like, having, like, form controls which, basically, you were able to put objects in there, and then the view was that you were going to see objects from there, etc. And that was, like, very similar to what AngularJS was doing. And that was, like, 15 years ago, like, before Angular. And again, like, history a lot of time repeats itself. And I think that as you gain experience, you start seeing how things repeat itself. And then, by knowing the past, it's easier to predict what might happen in the future.

So, I think that as you get more experience, it's easier to understand, "Oh, this is a hype. It's gonna go away, and then it's gonna go back to this or go back to that." So you also have that knowledge, and that's maybe why...it's not that you don't want to learn a new thing, but it's actually that you really already know that paradigm because you've learned that same thing in another way. But now, like, it changes just a little bit, and it's like, "This is gonna be something that only, like, will last, like, a few years, so it's not for me."

So, that's the other part. And also, as you were saying, you know, like, for Java and, like, things like that, they have, like, a lot of support, lots of people using it, etc. So, in those cases, I think that it makes sense to use something that's proven. Even more, if you're doing, like, a big project that is gonna have a lot of code and be maintained for a long time.

Guido: You know, once you start seeing these previous technologies and these cycles, you start, like, seeing the patterns. And it's important to learn your history here, you know? Like, sometimes, some particular communities, they want to invent everything from scratch. And they don't want to look back and say, "How this problem solved before?" Something that comes to my mind is, like, the front-end community, for example. It's...like, doing UI, it's really complex. And we have a lot of history of best-of native apps before. And again, there are some solutions that didn't scale really well, but there are a lot of other solutions that work really well. And we need to learn from previous technology and know what to improve and what not to improve. And so, it's important for new developers to take some time to do some research of previous technologies to avoid making the same mistakes and learn from the good things from the past.

Gonto: Another problem, and another thing that happens, like, very often, is that now we're seeing more and more, like, clickbait blog posts. We're seeing more content that targets people so that you just click on it. Like...

Guido: Fake news, fake news, fake news.

Gonto: It's like, "Three best SEO tactics." "The 12 best tactics or," like, "things that you can do to do," like, "email marketing." And a lot of them are just empty of content, or a lot of them have tactics. So, like, do you think that...is it worth to continue reading those? And, like, why?

Guido: Every time I see one of those titles, I probably don't click on them and avoid reading them, with the exception of if those things were shared by people that I respect. But yeah, I'm very skeptical about those sort of titles, so I try to avoid them. But yeah, I think you need to spend more time curating the sources of the information that you consume. And try to, you know, get sources that you feel comfortable getting information from. And then you can relax and just read them, and be sure to...at least you trust those sources, which is not easy.

And then, as you said before, you know, once you read something that you like, you need to find the problems there. For example, if you like a technology, read a blog post about a particular technology, well, then spend time looking for people talking bad about that technology or, I don't know, raising issues, so you can have the bigger picture about it. Just don't buy the good stuff and that's it.

Gonto: Something that I like about what you say is, like, curation. And for that, I actually used an app that's called Nuzzel, N-U-Z-Z-E-L. And that application basically checks all the people that I follow on Twitter, and it checks the links on tweets that were faved or retweeted the most, and it sends me, like, a daily link of that. So, I only follow people that I think have, like, have good thoughts or interesting stuff, and then that gives me a help to not use these clickbait titles.

And then the other part is that I think a lot of these clickbait titles have things that are, like, big mistakes. So, for example, "The 12 Tips on SEO." Like, those are just tactics, and those tactics might be good for your company or they might not. So, it depends on your company. So, I think that first of all, you have to think whether those tactics apply or not. And a lot of them, as I was saying, were, like, low-hanging fruits or, like, big mistakes.

So, I think that at first, you have to do 'em. And, like, reading at first, all of those posts that are, like, clickbait do make sense. But then as you start reading more and more, they are all the same, eventually. And something that starts happening is that you're reading about tactics without thinking of strategy. So, I also think that you need to focus first on what is your strategy, and then, based off of that, start thinking, like, what are the tactics?

I've seen, at least in marketing, a lot of people saying, "I need to do a account-based marketing." And they want to do it because it's a new "shiny thing" on marketing. However, it depends on what is, like, your target market. Because maybe, for your target market, it discovers new technology solutions by searching themselves, where that means that it's gonna be inbound for you because you can write content. But, maybe your target market doesn't search, and they go to, I don't know, some particular meetup. So then you need to go to meetups and not do account-based marketing.

So that's the part that I think, for example, at least in marketing, you need to understand your audience, understand your target market, understand where their hub is, and then, based off of that, start thinking, "Okay, what things work?" And once you know what things work, then it's time to go to these clickbait titles and understand, like, what tactics you can do for those.

And then the other thing, which is something that I got as I become older that I really like, is everything is the same now. There's not, like, so much new content on this stuff. There's not, I don't know, like, new SEO tactics every day. So I think that a lot of the new knowledge comes from actually reading books that are around completely separate topics and apply it to what you do. And also, in a book, it's probably somebody who, like, put a lot of effort on it, learned a lot, did research, and it goes much deeper than a blog post.

Because I know with the blog posts, even more now, it's shallower and shallower because it's all around, usually, marketing. Like, somebody marketing their own brand, or their company, or something. And that's why they make it clickbait. So, to give you an example, I read recently "Thinking, Fast and Slow." It's an amazing book about, like, cognitive biases in people and how our brain works. And then what we did is, for starting to work on outbound marketing, we're gonna be doing, like, an A/B test. We're doing an A/B test where, for a couple of the messages, we're gonna be writing them taking into account the cognitive biases of people. So, we're applying this thing about cognitive science into marketing to try to see if we can exploit some of them and get more people, not to buy, but to at least pay attention to Auth0, in our case.

So, that's definitely something that I think is worth applying, and "Thinking, Fast and Slow," like, the guy who wrote it is a Nobel Prize winner. He's, like, an expert in behavioral economics. So, why not apply behavioral economics to marketing? And I think you can do the same thing with other topics as well. So, I definitely recommend, more and more, read books that go deeper and apply those learnings to your subject of expertise, instead of going to these shallow clickbait tactic titles.

Guido: Yeah, I really agree with that. And again, I want to reinforce the concept, like, of, "Look for the skeptics." For example, I've been doing a lot of blockchain reading, and having a lot of plans that I want to do blockchain for X, Y, and Z. And I do consider that the technology is...it's amazing, and it could be a breakthrough in different industries. But I also follow a lot and read a lot about the opinion of the blockchain skeptics, because it gives me another perspective of how to criticize the technology and find holes in it.

And a person that I really respect, I like his opinion a lot, is DHH, the creator of Ruby on Rails. He's a really opinionated guy, but he's always on the other side of, like, web frameworks and the cool new thing. He's really...like, he critiques a lot, like, React and all the new front-end technologies. And something that I learned from him that I think is really good is, don't try to apply the same solutions that companies with completely different backgrounds have to your company. For example, maybe React is the best solution for your product. But acknowledge that React solves a particular problem that an organization like Facebook has, who has a lot of engineers that need to work on a huge code base that has a lot of microservices, for example. Well, microservices is another example, that you shouldn't just apply microservices to any new product.

So, take that into consideration. Understand where were the motivations for that organization to create that solution, and try to understand if that way of tackling the problem makes sense for your organization. So, being a 50-engineer organization is completely different from the problem that Facebook has at the scale they have. So, don't try to copy everything they say because they are Facebook and they wrote it. But you need to make sure that the problem you are solving and the technology that you're using fit well together.

Gonto: As I was saying before, another thing that happens a lot now is that we are in the world of information. We're in the time of information, where there is so much information that we're actually creating artificial intelligence machine-learning algorithms that can help us process that information. So, as we start to learn new things, how can we differentiate information from noise? And also, how can we avoid this analysis paralysis where there's so much information that I keep on learning, learning, learning, learning, learning, learning, and I just don't do anything because I don't feel that I know enough things? So, what are your thoughts here?

Guido: Well, that's a tough one, because I like to learn and read a lot, so this is a particular struggle for me personally. But I would say, just start doing things. You know, like, don't spend too much time analyzing what's the best solution. Just try them and see what happens. And we need to understand that we are, most of the time, building a product or solution, and that's where our focus should be. The technology and how we accomplish that, this is something secondary. We need to solve the problem. And obviously, you need to take into account how you're gonna maintain that solution and all the things that are necessary to build a healthy product. But, at the end of the day, you need to solve the problem, and you need to pick the technology that helps you solve that problem. So I would say, like, experiment, but just try the things and get information from the real work to make the final call.

And I think the challenge is of finding this balance between when you're gonna explore, when you're gonna learn, and how you do that inside of your organization. How you generate a culture what is healthy and you have safe spaces to learn, and also know when you need to, you know, deliver and ship a new thing. So, I would like to know how you guys handle that, that tension between, you know, exploring new technologies or new methodologies and moving forward with the product.

Gonto: I think that a lot of things to differentiate noise from information are some of the things that we've said before. So, for example, one thing to me is that we should focus on [inaudible 00:24:01], strategies, and frameworks, and not tactics. Because once you learn a framework on doing something, then you can just apply it to any company and anything that you do. Tactics can only explain in a narrow thing. So, to give you an example, one tactic could be what Airbnb did to start, which was, like, paying photographers to go to people's houses just to, like, bump the pictures of them, bump how many people were, like, booking those. That's a tactic. There's a lot of blog posts about that.

But then you could have a framework on how to create better retention activation for your product, which is around understanding how to create a habit, how to create the "Ah-ha" moment, how to set up the experience, and going through all of that. I've recently done a course called Reforge. They do a course on growth and one on retention and activation, and they really focus on framework and strategies that can apply to anything. They don't give you specific tactics. They give you a tool to pick the tactics. And I think that that's definitely one of the things to be able to separate information from noise. Because once you have the strategies and the frameworks, then you can pick the tactics, and then you can understand which of these clickbait titles will work for you, because some of them you just won't scale.

So, that's a good way to separate noise. And the other thing, as I was saying, is that I think that a lot of blog posts are just done by people who just learned something, and they just write about it, etc. And they don't have the background, they don't have the experience, etc. Lately, I've been reading a lot of books from, like, Nobel Prize winners, because I know that they've done a lot of research, a lot of deep understanding, and then they wrote, like, books about it. And as I was saying, then, applying those books to what you do, you are sure that this person has put, like, enough thought about it. So, this is information and definitely not noise.

Guido: Cool, and maybe regarding engineering, or even in marketing, how do you allocate time to experiment new things without putting at risk the progress and the quality of the product? Do you have a particular, like, technique for that? Do you spend, I don't know, X amount of time per month? Do you have a methodology for that?

Gonto: So, basically, like, how we do it is, like, we treat everything as an experiment until it works. So, we try to do, like, experiments, and for the experiment, we set, like, "What is the problem that we have? What is the hypothesis of the thing that we're gonna to improve? What is the metric that we're gonna, like, check what happens? What is the goal, and what is the timeframe?" And we start doing experiments. And once we see that one experiment starts working, then we spin up a team that will work on that experiment and basically create a machinery around that. And once that works, then we create another experiment. And we keep on experimenting until we find something.

So I think that in our case, we keep on building teams, and we have teams that focus on things that already work and teams that focus more on experimentation. So, for Auth0, for example, at first, like, we didn't know how to attract new sign-ups. So, we had a lot of experimentation around, like, content marketing, type of blog post, where to share, who to share with, how to create the [inaudible 00:27:11], or how to create the content, etc. At first, nothing worked. We did a lot of work on that. Eventually, we got it working. I actually have a talk about that called "The Power of Friends" you can look at online.

And then, after that, we were, "Okay, let's create a team that does content marketing. And I will have, like, ten technical writers that work on that full time." But then the new experimentation that we started, like, two years ago was around, "How can we do better," like, "outbound marketing now, for people who are not developers? For example, are product managers or enterprise [inaudible 00:27:41]?" We started, like, trying different things, different things, different things, and then were finally starting to find something. And then we started to build up the data on that. And now we're experimenting, for example, with, like, [inaudible 00:27:52] relations and public relations. So, I think you always have to keep on experimenting, but knowing when something works and when something doesn't work.

So, lastly, and to sum up mostly everything that we've said in this episode, is it good to learn new things, and why? And what kind of things is it good to learn? What are your thoughts?

Guido: Well, I think that yeah, obviously, learning new things is a good thing. The challenge is how you manage the time to do that, and I want to apply it in the right scenario. But to give you a complete example, for example, I like learning a lot about functional programming. And I think that maybe...well, there is a lot of talk nowadays in the community about functional programming, but I encourage developers to learn about functional programming not necessary to apply that new functional programming language to your day-to-day job, but to understand the concept, to look at how you write code from a completely different perspective.

And then, when you go back to your more object-oriented programming language, you start thinking differently. You start challenging some assumptions that you thought were true, or what's the only way to write code in a particular way. And then you realize that you have a new set of tools to tackle the problems that you have. So, I think learning new things is always good to, you know, broader how you think and get new tools. So, in this particular case, it's functional programming. But, as you said before, it's also good to learn things from a completely different industry to, again, gain more tools. And you never know how you're gonna use them, but it's always good to learn new things. And you put your brain, like, in...it's like going to the gym, you know? Every day, you're challenging yourself and going out from your comfort zone. And you get that muscle, and over time it's easier for you to learn new things.

Gonto: Yeah, I definitely agree with that, and I like your point. Like, to me, learning is about opening your head or opening your brain. And to me, it's around getting new perspectives. So, for programming, maybe, if you're, as you're saying, like an object-oriented guy, learning functional programming is cool. If you're a marketer, maybe learning about, like, behavior and storytelling, etc., could be cool. But to me, it's around getting new perspectives, just because that's gonna make you think differently. It's similar to diversity. Like, you talk to other people because even talking to others is gonna make you think differently. Learning about different subjects and different things is sort of around that. That's why we're talking about, like, reading books from other subjects, focus on strategies and other [inaudible 00:30:47] and frameworks, and just, like, experimenting on new things that you know nothing about. And that's gonna, like, I think, again, like, open your mind.

Guido: Thanks for listening to this episode. If you want to know more about us, you can check out website inheritedcomposition.com. In there you'll have some of our episodes, as well as transcripts of everything we've said and links to everything we've mentioned. You can also follow us on Twitter @theiccast.

Gonto: We love feedback. we're trying to improve this every day, so if you have feedback, please send it to us at podcast@inheritedcomposition.com. Finally, if you love the show, please leave us a rating in your favorite podcast app. If you hated it, just send it to your worst enemies so we have more listeners. Thank you.

Guido: Bye.