Learning Software Skills fast: what worked for us best in the last 15 years

Quick takeaways

• Focus on applying what you learn - reading books or watching videos isn’t enough without practice
• Build real projects that challenge you - trivial examples don’t expose you to the hidden complexities you’ll face in actual work
• Expect and embrace frustration - feeling stuck often means you’re learning something valuable
• Learn timeless concepts over framework-specific details - aim for universal software skills like modularization
• Mix theory with practice in small chunks - read a bit and code a bit, rather than consuming large amounts of content at once

Introduction

In this episode, we discuss how to learn effectively as a software engineer. Why some people seem to learn faster than others? What are some practical ways to speed up your learning? Instead of promising magical shortcuts to becoming a principal engineer in months, we focus on a more balanced approach that helps you build skills by mixing theory with practice.

Notes

• We mentioned our learning platform
• Domain-Driven Design was referenced throughout - check “Implementing Domain-Driven Design” by Vaughn Vernon
• The Pragmatic Programmer by Andrew Hunt and David Thomas is a great book for timeless software skills
• Watermill - our open-source library mentioned as an example of a project that taught us while helping others: github.com/ThreeDotsLabs/watermill
• Event-Driven Architecture traces back to 1950s, but was formalized about 20 years ago
• The Repository pattern blog post

Quotes

Just going fast is a trap, because you can go fast in the wrong direction and spend years learning things that are useless in practice or maybe are useful in the short term but not helping you during your entire career.

Once you tackle building something more complex that you’ve never built before, or maybe never even seen before, that’s when things get interesting, and that’s where your skills are tested.

I learned the most with the hardest projects that I worked on. The projects that were easy, greenfield, and everything was known - okay, it was nice, fun, but I wouldn’t say that I learned that much at the end.

If you feel frustrated while learning, you are probably onto something. Because you are frustrated that you can’t make it work. And then it also motivates you to push through.

What helps to learn much faster is trying to focus on things that are timeless. You can get benefit from the compounding knowledge over time.

Until you start fighting the obstacles, struggling to make it work, you probably won’t learn much. The hard part is figuring out what to build that’s a bit more advanced and will test your skills. If you pick up an idea and think ‘I have no idea how to do it’ - that is probably a good direction.

What also helps is sometimes feeling as the dumbest person in the room. Work with people that are more experienced than you. And if you sometimes feel that you’re not the dumbest person in the room, maybe it’s time to try someplace where you will be.

If you work alone, you don’t need to care that much about code readability. If you can fit the entire context of what the application does in your memory, you can use a single file that’s 5000 lines long. But as you work with someone else, it starts to get more complicated.

Timestamps

• 00:00:00 - Introduction
• 00:05:13 - What is real learning?
• 00:12:10 - Theory vs practice
• 00:15:29 - Learn by building projects
• 00:27:33 - AI for learning
• 00:36:19 - Is learning supposed to be fun?
• 00:42:22 - Learning from social media
• 00:50:17 - Timeless skills
• 00:58:11 - Diverse skills
• 01:04:12 - Making notes and teaching others
• 01:08:36 - Mentors and communities
• 01:11:54 - Q&A session

Transcript

Robert [0:07]: Ever worked with someone who’s been coding for more than 10 years but still makes mistakes? Or have you seen a junior engineer write code that blows your mind? It’s not always about intelligence. The real secret sauce is how you learn. Learning the wrong things can feel productive, but it won’t get you far. In this episode, we’ll explore the art of fast, effective learning. I’m Robert.

Miłosz [0:27]: And I am Miłosz, and this is the No Silver Bullet live podcast, where we discuss mindful blackend engineering. We spent almost 20 years working together in different projects and teams. During that time, we learned that following advice like “always do X” or “never do Y” doesn’t work and can limit your growth. In this show, we share multiple perspectives that will help you make smart choices and grow.

Robert [0:55]: Yeah so if you have any questions please leave them on the chat we’ll try to address them on demand if not we’ll have Q&A session at the end of the live so we can answer other questions, anynthing to add?

Miłosz [1:11]: Good let’s go

Robert [1:12]: All right so I think it’s important to start with setting expectations because sometimes you may heard from many people that there are some magic way to learn faster you can be principal engineer in one month or maybe half year but well unfortunately it’s not that simple so everything what we’ll mention in this episode wouldn’t be advice like that it wouldn’t give you any magical power to be principal engineer in one year but definitely it can accelerate your car and it should definitely help you with not staying junior or mid engineer for four years because i think everybody probably met such person during working with software that as we mentioned at the beginning this was mid this mid engineer for forever yeah.

Miłosz [2:04]: And magic recipes usually don’t work, and often means someone wants to sell you something, so watch out for silver bullets.

Robert [2:16]: But still, sometimes there are people that learn really, really fast. And today we’ll share a couple hints that, from our observations, made them very effective learners. And again, it’s not about being smart, because from my experience, sometimes being smart can be even a trap, because you may try to be too smart and try to maybe dig too deep to some things, but it’s not always the best idea.

Miłosz [2:55]: Yeah, it depends on what you are smart about. But you can easily see this in different people you work with, especially in teams. Some people seem to learn much faster than others. And seems there must be some secret behind it or at least some ideas that can help you learn faster

Robert [3:22]: I’m not sure if you agree but from my experience it’s often not about what to do but actually the opposite so what you shouldn’t do to actually not be slower so I think we can probably compare it to going somewhere by the car so let’s imagine that you have Lamborghini and, slower car, but you don’t have a map when you’re going with Lamborghini. And in this case, you might get somewhere really fast, but not in the place that you need to go, actually.

Miłosz [3:52]: Right. So the destination matters, basically.

Robert [3:54]: Yes, yes. Because just going fast is a trap, because you can go fast to the wrong direction and spend years on learning things that are useless in practice or maybe are useful in short term. But they’re not helping you during the entire career because probably you work as an engineer for…

Miłosz [4:17]: Yeah, and it’s hard to differentiate because it’s easy to feel like you’re learning something. You can accommodate some trivia or ideas but you never put them in use. So I guess what we want to talk about today is learning skills.

Robert [4:36]: Something.

Miłosz [4:37]: You can put into practice you can use somehow in your work or just projects in general

Robert [4:45]: Yeah so probably it would make sense to start with some kind of maybe high level maybe not definition but idea what learning, means because you can do many activities that may sound like learning but it may not that’s useful for you to use in Rework.

Miłosz [5:13]: So maybe the fact that you can use a skill to build something in practice would be the primary one for me. So it’s not only about having the knowledge about some tool, library or programming language, but being able to use it in work to build something actually useful. And probably not a trivial to-do app or something most tutorials teach you. Right, so it’s quite easy to use any programming language or library to spin up a trivial web application, because there are tons of tutorials like this. And nowadays AI can generate this for you right away, because it could learn on so many materials on this. But once you tackle building something more complex that you’ve never built before, or maybe never even seen before, that’s when things get interesting, and that’s where your skills are tested.

Robert [6:25]: Yes, and I think maybe it may sound familiar for you, when, for example, you did the opposite. So, for example, you’ve been on a conference, you’ve seen some cool idea, or you read a book or article about this cool idea, and you’re trying to apply it later in work, and for some reason, it doesn’t work as it was promised in…

Miłosz [6:49]: Yeah, because you missed some hidden complexity or edge cases that were not mentioned there, or maybe the tutorial didn’t cover it, and now you’re stuck. That’s a pretty usual experience when starting to learn something new in software especially.

Robert [7:09]: I think we can probably compare it to playing an instrument or driving a car. Let’s imagine that you are trying to learn driving a car by just reading a book or watching some video tutorial on how it works. Okay, maybe it can give you some useful hints how to do that, but as long as you will not really do that and, put it into practice, you cannot really say that you can play an instrument or drive a car. Because in practice you discover a lot of hidden complexity that, okay, maybe on the movie it looks simple, but in practice there is much, much more and it’s harder than it looks.

Miłosz [7:54]: And there is some danger, because you can feel like you actually know how to drive or how to play a guitar, let’s say, after just reading about it. But then in practice you don’t have any experience, so you won’t be able to do it. And it’s quite similar to reading books maybe, on programming especially. And I think we read quite a lot, especially 15 years ago when there weren’t many online resources, videos and so on. The books were primary learning material for us. And sometimes the theory gives you nice ideas how to work with codes or mental models, but you have to actually start writing code to see if you learned anything.

Robert [8:48]: And it’s because you can read about many things, but often what’s described in the books it’s applied in some very specific context. And the project that you are working at this time may not really fit this, or it may fit, but it’s a bit different problem to solve. Because there are many similarities between multiple projects, but there are also some small things that are a bit different, but it can make problems much, much more different.

Miłosz [9:20]: And because books are focused on just one area, they can’t give you the entire context. And I think we felt this because we came up with many examples to teach people some concepts. And it’s very hard to come up with something that’s not this trivial to the application, that’s not complex at all, and come up with something that’s kind of like in real life, but also can be used to teach someone something. And same issue with books many books try to introduce this idea of a project or something like that But it’s quite hard to do it well. And to cover some real-life scenarios that someone can later put to use in their own projects.

Robert [10:09]: Yeah, and there is also one thing from our perspective of people that we’re creating online examples, articles, book. It’s also hard balance because, okay, in theory we can create an application that is as complex as a super complex application built by 100 people. But from the other side, it will be also a bit hard to work with that and learn from that. So it’s a hard balance that we are trying to achieve. The other thing that is also coming to my mind is that it’s connected to the thing that context in the book may be a bit different than yours. For example, when a couple years ago we were switching to Go programming language, we were working in some projects that required some more advanced tactics to write software like domain-driven design. The other side was that there were not all the materials. Actually, I would say that all the materials that were out there about domain-driven design was totally wrong.

Miłosz [11:10]: Yeah, it was a very long time ago. Yeah. It was very in the early stages back then.

Robert [11:17]: It still didn’t change that much now. There are some materials that are good, but still, most of them are still missing the point. But anyway, I think we spent probably half a year to figure it out, how to do it in a way that is compatible with Go programming language. And you can say that, OK, it’s just using it in a different programming language, but in practice, it requires time. So it’s not that easy.

Miłosz [11:42]: Yeah, especially if you do it on a live product. in a team where no one has experience like this. Thankfully, we could use some books, like implementing domain-driven design back then, which was helpful. But still, there was a lot of iteration, and I remember the first approaches were much different than what we ended up with. And probably not that great.

Robert [12:10]: Yes, probably we can summarize this first anti-pattern as this theory is not practice, and we’re taught to not be the person that is reading 50 books and think that, okay, I know how to solve many problems. Because just reading about that, it may be not enough. Because on paper, everything looks great, usually, but in practice, it’s totally different stories. And I know some people that were like that, that they were reading about many things, and when it comes to solving some problem, they were like, oh, let’s just do it like that. I wrote about it. It will be simple. But I know already that it’s a bit different in practice.

Miłosz [12:50]: Yeah, sometimes it’s fine to read just for fun if you are curious about something. But it doesn’t mean you have to use it in your day work. But it’s much different than learning skills, I would say.

Robert [13:05]: So it’s all about extremes. So don’t be a terrorist that is detached from reality. Don’t be like an Envoy Tower architect that knows everything best from theory but doesn’t touch this code and doesn’t need to write it.

Miłosz [13:18]: If reading doesn’t work, maybe video cursors. Do you like video lessons?

Robert [13:26]: No. No, because I think it has a pretty similar problem. So maybe it can give some more feeling like you’re looking like somebody is implementing something and it’s a bit closer maybe to feeling that you’re really implementing that. But it also has one risk that if you’re looking, if somebody more experienced is writing something, this person is probably skipping a lot of complexities that the person already know or just going straightly forward to the solution because, well, the person already know how to do that and doesn’t struggle about that.

Miłosz [14:04]: If they show you a big project on screen, you probably won’t be able to grasp the entire context just by watching the video. Although I think it’s a nice format if you want to give a quick overview of some code, or if you want someone to see how to do something exactly, like refactor something. What comes to my mind is live coding on presentations. That’s quite a nice format because it is like 5 or 10 minute video. Not video, it’s live on presentations of course but it’s a different format that can be useful but what I don’t like is a video course that I open and I see there’s 24 hours of video watching ahead of me and I am already bored I didn’t even start and I know there will be lots of filler content in there and yeah, that doesn’t make me want to learn.

Robert [15:14]: Yeah, so what are the solutions here?

Miłosz [15:18]: Probably build something.

Robert [15:20]: Oh no, I need to get my hands dirty. Touch the keyboard and implement stuff. That’s so bad.

Miłosz [15:29]: Yeah, it’s basically what we mentioned about this iteration while learning from a book. Until you start fighting the obstacles struggling to make it work you probably won’t learn much and probably the hard part here is figuring out what to build right because again you can pick up a tutorial and build some easy application some trivial application but it won’t teach you much so you have to pick up something that’s a bit more advanced and that probably will stress you a bit i mean test your skills so if you pick up an idea and you think like i have no idea how to do it that is probably a good direction i would say because you will need to figure it out yeah

Robert [16:27]: I think we can compare it to like playing instruments with planning to play a gig. It’s probably similar to how you should approach learning. For example, if you’d like to play a gig, you probably should start with something simple, play guitar yourself, later some rehearsals with your band, and later going to a gig and playing that. Obviously, it’s not easy, it requires a lot of time, but let’s imagine that instead you are watching a video on how to play guitar and you’re going strictly to directly to play a geek it will be probably not the best idea yeah and you’ll be super stressed and probably it will be a disaster but it’s similar thing it’s similar thing with learning programming skills so your geek is well the job that you’re working in and again you can try to learn something from just book from video and try to do your geek directly and okay, it will be a bit maybe faster, but from other side the result will be much worse.

Miłosz [17:35]: A parallel that comes to me is in software world it’s like your employer gives you a video course buys it for you you watch some 20 hour video and then you’re expected to apply it in the company’s project which you’re probably not ready to do it yet and you will experiment on a real

Miłosz [18:02]: product that’s used by real people. So there’s a risk that you will not apply it correctly and it won’t end up that well.

Robert [18:12]: And it’s another risk that I can see. So if you have some concept and the best place that you’ll see to apply that is the project that you’re working on your job, there’s a risk that you may end up with doing the CV-driven development. So basically, you are applying all patterns that you can see in your job project, and it will be probably a disaster for the problem.

Miłosz [18:39]: Of course, I applied the saga pattern in my previous year.

Robert [18:43]: Yeah, and probably somebody is applying it to the context that it’s not helping. So it’s making the project worse, and also you’re not relearning. Because if you are not applying those patterns for the right problems, you will also not learn how to do it properly, because you just apply it in the wrong context.

Miłosz [19:05]: So the ideal scenario, I think, is to have a pet project, but one that solves some real problem. Sometimes it’s hard to come up with something like this, but it doesn’t have to be super complex, but at least if it’s something that does something real, it gives you this kind of illusion of working on something more serious than a simple to-do app that’s free handlers and that’s it. It’s best if you can run in production and treat it as a production-grade deployment in general. So you have a domain and some servers or cloud or setup or whatever, set up some alerts, monitoring and so on. If you treat it like this, then you will start finding all the issues that can happen in a real-life project too. The hard part is finding this idea of what to build.

Robert [20:16]: But it’s probably one even harder problem, because you can test it on some pet projects, But I think it’s also essential to, at the end, apply it to some real project with some team. Because I think we’ve been trying multiple patterns in some smaller projects. But after we have used it with teams, it also changed how we’ve seen all that. Because if you’re working on a project alone, it’s a totally different dynamic, let’s say. Because it’s just much simpler. because if you overcomplicate something, you probably know how to go over it. But if you’re working with a team, and if you overcomplicate something, you’ll be not the only person that struggles. Your teammates will struggle much more, and they will also not be super happy about it.

Miłosz [21:10]: That’s a good point, since if you work alone, you don’t need to care that much about code readability, for example. If you can fit the entire context of what the application does in your memory you can use a single file that’s 5000 lines long and you don’t need many patterns there because you just know where everything is but as you work with someone else it starts to get more complicated it. So maybe that’s a good advice too, to seek someone else you can share a project with. I think that’s also how we started our more serious projects when we worked together.

Robert [22:03]: So there is a question on the chat that, like with playing guitar, so it’s good to have friends to play with, but what if you have no friend to play together or practice with? How you motivate yourself to learn guitar until you join a gig. So we’ll have some solution for that. So we and Milos are probably pretty lucky that we know each other and we’re building projects together for almost 20 years. But yeah, we know that it’s not the thing that everybody, not everybody has this luck, but we’ll have some hints that can help with that definitely.

Miłosz [22:41]: I guess the primary one would be you can find a community online and join someone with building a project but

Robert [22:51]: We’ll touch on that a bit later.

Miłosz [22:56]: Do you want to go over the two comments we have?

Robert [23:01]: Yes let me just check what from that we’ll cover later, I think we’ll cover so we can cover them a bit later when we’ll have something in those contexts so let’s wait for a while but yeah, we have in on our list.

Miłosz [23:27]: Martin mentions that he feels what I said about video courses and that they are like a torture yeah, I feel the same I think it’s interesting format for shorter things, showcases or screencasts, for example. But, yeah, like 20-hour video courses are…

Robert [23:51]: Or maybe for some, let’s say, more soft skill-related… Maybe not really soft skill, but not coding-related skills that are also important, but they’re not about writing the codes. And yeah going maybe into the problems that are there so finding the friends to go together or, maybe you don’t have a time because we know how we know how it’s changing with the time so when you are younger you can code over nights and over the weekends but if you’re getting a bit older you may have family, you can have multiple more duties. And it’s a bit harder because, there are multiple obstacles that you have. So the first one is that you need to find some project to work in. And we already mentioned that this is the hard part of it, because Because it’s sometimes hard to find a good problem to solve that is fitting the pattern that you’re trying to use.

Miłosz [25:03]: Not some artificial problem, but something that actually solves something.

Robert [25:08]: And it doesn’t oversimplify that. Because if you learn that, okay, get some simple problem and try to apply domain-driven design for that, and you will try to move it to real projects, it will just end up with some over-engineering stuff and it will be not the best. The other thing is probably also related to this torture with videos that you have super big chunk of knowledge to ingest, like 20 hours of video, you are watching that and later trying to apply that. And it’s super hard. And sometimes you maybe don’t have one or two hours to watch this video. It would be better to just have some smaller chunks to work in. And already I’ve seen on the chat that somebody mentioned that my main struggle when learning new skills is finding clear, consistent, practical and consistent material. I hate huge as boring text-only documentations and more visual and neat short tutorials. So this is basically it. It’s not easy to find this.

Miłosz [26:22]: Documentation especially. so it varies widely between projects. Some projects have really nice docs that you can get started easily, by the way. Give you some short examples and such. But some, yeah, not so great. You have to dig through the docs yourself and figure it out. So it’s definitely not easy.

Robert [26:47]: It’s also sometimes hard to find one place that is going from A to Z and explaining everything. And sometimes you need to go over 100 websites to find how to do that. Some alternative is Ask AI for that, but also you know that sometimes it can give you some hint, but it can lead you into the trouble.

Miłosz [27:09]: AI itself is a topic that suffers from this issue exactly. Because it evolves so fast, there’s probably no one place you can go and learn about how to use it. It just depends on which model you use and so on. So you have to go through many documentations and websites probably to learn it well.

Robert [27:35]: And there is actually a question. So what’s the AI impact for New West that skip the regular learning process? Do you recommend AI for using it? There are, starting learning.

Miłosz [27:48]: Software development?

Robert [27:49]: Yeah.

Miłosz [27:50]: So basically the question is how about using AI for learning?

Robert [27:56]: What do you think?

Miłosz [27:57]: I think there’s The same issue as with books on one hand, so it can teach you theory, and maybe even worse, sometimes it can give you ready answers, which you just copy paste or use directly in your IDE and you don’t touch the code, which can work, but you also probably won’t learn as much if you don’t struggle. And the other thing would be hallucinations, which is the primary reason I don’t use them much. For example, learning a library. I tried a few times to use AI to generate some use case for a new library I didn’t know, or an SDK. But very often it makes up function names, or just sort of invents something that doesn’t exist. And in the end, I just prefer to read the docs myself and do it from scratch, because it’s often confusing and I I don’t like the fact that I have to double-check everything it does for me.

Robert [29:21]: Yeah so i i think i have pretty similar point of view that i would say that it’s double-edged sword so it can help for many cases but you need to be really careful about what it’s saying and double check that okay because sometimes it’s helping to discover some thing that it may be harder to find somewhere in the internet or in the documentation and it’s helpful but it’s all about, verification that, okay, what it said, it makes sense. And I think it’s probably easier to use for more senior people that already know more context and more understand how, what’s the impact of the things that it’s generating. I can imagine that if I would be more junior developer, it would be the risk that, okay, I’m getting what it’s giving me and putting it to the project, And I’m spending ages to debug that and understand what’s happening. And if I would just follow the way that you mentioned that I would do it from scratch, it will be just much faster.

Miłosz [30:26]: If you want to learn the skill, I mean, you can argue that you won’t need the skill in the future because of AI. That’s a separate discussion. For now, no one knows for sure, so let’s leave it. But I also think there’s so many use cases for how to use AI for learning it’s very easy to give one answer because making it write the code for you is probably not the best idea if you want to learn some skills but I can imagine you could use it to give you some roadmap on what to learn you could prompt it with something like I know JavaScript and I want to learn Go recommend some concepts I should read about probably more helpful than just copy-pasting the code it gives you.

Robert [31:22]: Yeah, and I think there is one thing that with AI can be pretty helpful, and this is something that we’re actually working for last more or less one month. Because there’s also one problem when you’re learning something, you may be stuck on some stupid typo or some stupid mistakes, and sometimes AI I can help you with being unblocked. So actually, since one month, we are now working on implementing that kind of mentor functionality in our learning platform, because we noticed that some of you were stuck on some, again, some typos or some simple mistakes. And it can be actually pretty nice in finding those typos or mistakes and unblocking you. But from the other side, it can also say some stupid things. And I would say that this is the biggest challenge that we are fighting now, is ensuring that it would not give you some false advice and learn you something false, basically.

Miłosz [32:23]: And that’s something that’s very hard to understand if you are not an expert in the field. Because it will sound very confident. And if you have no experience with what it talks about, you want to know better. So I will be careful there.

Robert [32:41]: The good news is that we found some ideas what we can make to make it less wrong and pretty moderated on what it’s saying. But again, it will be never like 100% accurate. But let’s imagine that probably you remember some cases like you were building something for fun and you were stuck for 10 hours because of some stupid typo. So it will be just super useful to be unlocked because it’s not something productive let’s say to be stuck because of type of our 10 hours and it’s just frustrating.

Miłosz [33:13]: Yeah that’s a good point so also important to not be not go too far to the other extreme and say I won’t use AI ever because it’s not a good idea just use it as a tool as any other tool

Robert [33:32]: And I think it’s in general useful to making this tough process of learning by building stuff a bit nicer. Because we’ve been doing that and sometimes we’ve been really frustrated by the structure of building something. So basically we are trying to make this process more nice. So we are also, in our learning platform, giving some projects that you can work on. So you don’t need to find out the problems for the techniques that you are learning. And I think it’s also pretty cool because, again, in our life we built a lot of different projects and it took us some time to find some nice projects to learn stuff. But we know that it’s sometimes hard, especially when you don’t have that much free private time or sometimes you maybe would like to just have five minutes to work on something. And we’re trying to cut this learning to some small steps to give you ability to just spend five minutes a day and progress a bit on this small project that we’re giving.

Miłosz [34:48]: I like the fact that we recreated the way we used to work in the beginning. So you read some theory and then you solve some exercise, you write some code and you see it applied live.

Miłosz [35:07]: And still to this day, I think, is the best way I know of learning. You need some theory and then some practice. So this is what the other platform gives you as well.

Robert [35:19]: I think it’s also nice that it has some path with some proven techniques and you are just following those techniques. And you don’t need to look on hundreds of websites to find how to, for example, do event-driven architecture or something like that. But again, it’s not for everybody. So when we’ve been younger, we have just time to figure it out, go over internet and try to find all these techniques, try multiple different techniques, try to find a project to implement. But yeah, it’s also fun. Yeah, yeah, definitely.

Miłosz [35:53]: We can spend the time.

Robert [35:55]: It’s not for everybody, but again, if you are looking for some nice learning resources, go to our websites and it’s tab, trainings and courses. Again, it’s not for everybody. We’ve been not using such a platform because it didn’t exist, but again, it’s also not only way to learn, so you can easily replicate it yourself. Okay so the next thing about learning that i think i heard pretty often is that learning needs to be fun and interesting yeah and i think it’s also a bit risky because, it’s easy to start to optimize for fun in learning and in my opinion it’s not the best thing so if you compare it to school so well school is not about making so primary goal of school is not making to make learning fun it’s about learning if you would like if you are optimizing for fun not learning it’s kinder regarded, what do you think about yeah.

Miłosz [37:05]: And what comes to my mind is this gamification of you know different learning products so you get some prompts or badges and so on.

Robert [37:17]: Like Duolingo, for example. I’m not sure if you’ve been playing with Duolingo.

Miłosz [37:21]: A few years ago.

Robert [37:23]: I remember that it was actually quite cool that you have badges, you can have some frozen…

Miłosz [37:29]: You can invite friends and do it together. It seems like fun.

Robert [37:34]: And at some point you’re actually realizing that you’re not learning that much. I mean, you’re clicking some funny stuff every day and you have to take 100, days, it’s great, but it’s also like, okay, it’s very repetitive, and maybe it’s fun, but okay, I don’t feel that I went very far away.

Miłosz [37:55]: So I actually have a recent realization I had. So we were working on this AI stuff for our platform, integrating LLMs. And it’s a new technology, you know, there’s many things that have no standards yet, you have to discover many things and so on. And initially, I was very frustrated while working with it, because it’s a different mental model too. For example, you mentioned about hallucinations. We are used to programs being very strict and predictable. But with LLMs it’s just the other way. It’s a bit random at times. And it was initially frustrating. And then we figured out ways to make it work, basically. And it hit me that this frustrating part is usually the sign that you are learning something, you know.

Robert [39:07]: But I think it’s interesting because it’s often frustrating from one side, but it’s also a bit exciting. I’m not sure how to describe that, but…

Miłosz [39:16]: It is exciting after you struggle.

Robert [39:19]: Yeah, yeah, maybe, maybe. And at the end, you don’t remember that much this frustrating part.

Miłosz [39:24]: Yeah, yeah. So, I think that’s actually what you should be striving for, maybe? I’m not sure if that’s a good word to put it, but basically if you feel frustrated while learning, you are probably onto something. Because you are frustrated that you can’t make it work. That’s how I feel about it. And then it also motivates you maybe to push through, or maybe demotivates you to give up. But I think it’s a better sign than having fun. You can be having fun vibe coding. It’s a fun thing to do.

Robert [40:08]: Or making games. So for example, something that you recommend.

Miłosz [40:12]: Yeah, making games is fun too. But also can be frustrating if you don’t know how to do something. It’s a similar thing.

Robert [40:19]: And I think it’s similar when you’re working in some projects. So probably we worked sometimes in the same projects. And I’m not sure if you agree, but from my perspective, I learned the most with the hardest project that I worked. So the projects that were easy, greenfield, and everything was known. Okay, it was nice, fun, but I wouldn’t say that I learned at the end that much. I think I learned the most with the projects that, you know, it was sweat, blood, and at the end we succeeded to kind of overcome that. But there were times of this project that it was really hard to just go over it. And well it was tough it was frustrating but at the end we’ve been able to overcome that and i think it only works probably when to also be clear here so it’s not only about projects that it’s hard tough and it’s you’re not doing about anything about that because this is a death march it’s not learning but if you are in the hard project and you have some plan how to improve that and you are implementing this plan, you are learning a lot. For example, you have some super legacy application used by many people with super complex logic, and it will require a lot of skills on multiple levels to just overcome it.

Miłosz [41:41]: And you just have to figure it out. That’s the hard part and also the best learning moment. Like when you lose sleep because you fight with some issue you can’t figure out the solution for and then you the next day you wake up or you take a shower and you somehow grasp it unconsciously but that comes after this struggling part it’s not, you know, you are not just happy about it and having fun the entire day you think hard about how to solve this.

Robert [42:23]: And I think the opposite, I can sometimes see the opposite in people that think that are learning from social media, let’s say. So you on X are observing multiple programmers that are doing some cool stuff and you read that and you feel that, okay, I know how to overcome some problems that people shared. But I think it’s also dangerous because it’s worth mentioning and reminding that social media is full of shows, let’s say, making grass greener than it is, and a lot of populism.

Miłosz [43:06]: Yeah, so basically extremes.

Robert [43:09]: Yes, so what works on social media is writing about something that is controversial. Many people will disagree, comment on it, but unfortunately this is what works. And you may think that, okay, I’m reading those comments, ideas, and I’m learning a lot from that. But I think it’s not like this in practice. And if you have more experience, you see that a lot of that is just making grass greener and hiding the bad parts of some approaches.

Miłosz [43:44]: Yeah, it’s not really learning according to what we talked about initially. Because you don’t use the skills and you don’t learn any skills actually. Just learn some trivia maybe or some strong techs of some tech influencer.

Robert [44:03]: Especially those a bit less experienced that they don’t know that they doesn’t know and they think that, okay, you are overcomplicating stuff. You don’t need to use X. It’s not that, just go simple.

Miłosz [44:17]: Yeah, it may also seem like you contact only the extreme views on some topic. Because that’s what attracts most comments and trolls and discussion in general online. You are very extreme on one end of the spectrum about something. In reality, there are probably not so many easy answers, and it depends on the context. Our last episode about clean architecture is probably a good example of this, where you can find as many people who love it as those who don’t want to work with it ever again.

Robert [45:10]: But again, it’s a risk, because it’s easier to just scroll through social media and have something of learning, but again, it’s not really learning. It’s probably also similar to watching some fun programming streams and people doing some fun on coding. So it’s probably easier to ingest and it may be fun. But again, I would separate the fun from learning.

Miłosz [45:42]: It’s entertainment.

Robert [45:44]: Exactly.

Miłosz [45:45]: For example, my YouTube feed is now full of drummers doing some white tricks. But I’m not even playing drums. It’s something that’s cool to watch, but it’s not learning.

Robert [46:03]: So again, what’s our tactic here? I would say that entertainment is also important, but it’s also good to separate some time for some deep dive content that is not making grass greener and making ideal world in places where it’s not. It’s better to sometimes find some deep deep dive videos or articles, basically something that we believe that is teaching you a lot. And this is actually something that we’re doing on our blog. So for example, we have multiple blog posts that are super long and they’re probably not as easy to read as some five minutes articles. But from the other side, the alternative is reading some simplified articles and later struggling to implement it on production, because it’s usually how it’s ending up.

Miłosz [46:59]: And even if you read this deep dive article, you still need to apply it somewhere to truly grasp it. Right so it gives you a more more more tools more context but still it’s best if you just use it yourself

Robert [47:16]: Yeah and don’t take us wrong so it all doesn’t mean that learning doesn’t need to be fun it’s just about putting the priorities so the first is learning because if you spend time on learning wrong stuff you just lose a lot of time and for example if you’re prior to prioritize, fun but i would maybe say that you know you should not you should not optimize for fun but for excitement rather so find some exciting project that you can work on that will excite you to go forward and even if you’ll be frustrated this excitement will try to you.

Miłosz [47:58]: Want to see it live

Robert [47:59]: Yeah that’s the motivation.

Miłosz [48:01]: Here that’s very nice

Robert [48:03]: And i think that it’s for example what which helps me often to overcome this hard part.

Miłosz [48:12]: When the frustration hits, you need to use this excitement to look forward and push through.

Robert [48:19]: And I think it also helps at the end when you spend a lot of time on this frustrating project, but at the end somebody’s using that and you see that it’s useful for people and it’s like, oh, okay, it was better. And I think, for example, I have sometimes like this with Watermule, with the library that we created, that sometimes working on fixing some flaky tests or merging some PRs or spending time on doing some reviews, it’s a bit sometimes boring. Maybe it’s a bit sometimes tough to do. But at the end, when we see that we’re making a new release and people are happy about it and people are using this, it’s giving some kind of fuel to progress with it.

Miłosz [49:02]: And it also started as a small library that solved our specific use case maybe also a good example of how we can start working on something that is useful for someone else and can help you learn something because we also learned a lot about maintaining an open source project over the years thanks to it definitely Definitely.

Robert [49:30]: So, okay. Now we, I think, covered pretty deeply what is the good direction, what you should basically learn. So, let’s imagine that you have your map now, but let’s now discuss for a while how you can get faster to this place that map is showing you to go.

Robert [50:01]: So, the first thing that I have in mind in this is, again, what you should learn. Or, okay, actually what you should learn. So, I think what helps a lot is focusing on things that won’t get out of day pretty quickly. Because to take some example, let’s imagine that you are a front-end developer and you are some framework specialist. And the risk is that your knowledge may become obsolete much faster if we compare to learning it some universal skills. So in other words, I think what helps to learn much faster is trying to focus on things that are timeless. And basically, you can get benefit from the compounding knowledge over the time.

Miłosz [51:10]: Maybe also not stick too long to one technology, if you see something else that you could use. Which on the other extreme is also not that nice if you just keep jumping from one programming language to another. Even take frameworks, it may be useful to know more than one, even if you primarily use one, even to just learn some different concepts. Maybe that’s actually a good one about programming languages, but you can learn some just for for some different point of view even if you don’t do it on production But it can also teach you those timeless concepts you mentioned.

Robert [52:03]: That’s true. That’s true. But I think one help that can help you evaluate… Because you are totally right. So it’s important to not go into extremes like, okay, I’m not learning any framework, I’m just learning the things that are timeless. But it’s more about not going in an extreme and trying to mix it and not being a framework specialist. I think we already mentioned it in previous episodes multiple times. And in terms of AI, you will be never better than AI in learning some framework quirks. Because it’s just a limitation of your memory and it will be more updates than you can ingest. and you will be out of date sooner. But there are things that, well, AI will be never as good as you maybe. And like modularization or splitting bigger problems into smaller things like that. And it doesn’t matter actually what programming language or what stack you are using. For example, if you learn how to modularize things or split some problems into smaller. It will always help you, independently what technology you will use.

Miłosz [53:23]: It’s still relevant sometimes after decades since the invention.

Robert [53:29]: For example, I tried to check event-driven architecture that we are maybe not advocates, but we see many use cases where it’s useful. So from what I found, the first origins was in 1915, so pretty long time ago. Current form, it was formalized around 20 years ago, so a pretty long time ago, but again, the idea is pretty old. And the cool thing is that probably when you learned in this eight years ago something about it, it will be highly relevant still. And if you learn that many of the things that are universal and timeless, it will just help you over the entire career.

Miłosz [54:22]: Yeah, you can apply it to other languages or frameworks or whatever. Sometimes it’s fine to see how the solutions are reinvented in a different way. And this is like something fresh.

Robert [54:38]: Yeah, we’ve been touching this in an episode with clean architecture, I think, at times.

Miłosz [54:45]: Or, let’s say, like, Go channels, which seem quite fresh when coming from some language that doesn’t have these concurrency primitives built-in, but they are, too, not some new concepts, right? It’s just a concurrency model applied to a new programming language.

Robert [55:12]: I think it’s also pretty interesting that Vibe coding is a pretty hot topic, let’s say, now. And let’s even imagine, so I think it will not happen soon or ever, but let’s imagine a scenario when LLMs and Vibe coding totally replace programming. And still, in this world, skills like modularization or splitting problems into smaller, it will be still pretty useful. So you can try to hint this LLM a bit to how to split this problem into smaller, just to not have 5,000 lines of code, file, with everything. Because it will just struggle to do that. And it’s visible now, when you’re vibe-coding something and you’re trying to put everything into one file, it’s just a disaster. And it’s not that obvious how to split it into smaller chunks, let’s say. But if you have already this skill, it’s much easier because you can hint this model how to split that and its performance will be just much better.

Miłosz [56:17]: And modularization is probably a good example of this topic you can’t really learn that fast. And there are many extreme takes on it, like use microservices. And once you work with software for a while you know it’s not that simple and it’s also not something you can learn from a Twitter thread you learn in 30 seconds where someone says use this directory or whatever you just have to work through many different projects and learn some patterns learn some mental model that will help you later apply this approach.

Robert [57:02]: And I think it’s a similar case with testing. So, again, let’s imagine this work when we are no longer writing code, we are vibe-coding everything, fine. But it’s still useful to know what kind of tests you would like to have, and, how they are made. Because even if your model is great, it’s good to ensure that the next prompt will not do some regression in the logic that you had. And I would say that if this word will come, a bit won’t, but never say never. I think it will be critical to have proper tests for that, to ensure that does other prompt will not break things that some previous prompt did?

Miłosz [57:48]: Yeah, we can see it with the work we did recently. But similar testing principles still apply. Exactly. Even if you use new tools.

Robert [58:00]: Don’t be afraid. If AI will take your job, learn testing and modularization and techniques that you’ll feel that will be timeless.

Miłosz [58:13]: Maybe it’s a more general suggestion to have a diverse skill set. Probably everyone specializes in one area and it’s fine, but it’s useful to know a bit more about some fields similar to what you do. Like if you specialize in backend programming, you can still grasp some front-line ideas. So it makes it easier to communicate with teammates and solve more high-level problems than just looking at code.

Robert [58:50]: Yeah, and I think it’s something especially good for some more senior people, let’s say. So if you’re a junior, okay, let’s maybe try, you probably should try to master one area, let’s say. What more senior you are becoming, Link. More you should learn some other areas because i think what’s also useful is the fact that you can borrow from different areas let’s say so if you are even doing back-end you can borrow some ideas from front-end maybe from data science maybe from i don’t know ux or something like that so there are many nice ideas in different areas that can help you solve problems, or maybe even some areas that are totally not related to programming, like accounting, for example. You worked with some accounting domains. Actually, I think accountants have some cool ideas that you can apply to different domains, and it can help you to solve those problems nicely.

Miłosz [59:56]: Yeah, especially since the more senior you get, the more you work with people outside engineering. And you solve more high-level problems than just fixing bugs in the code. You have to figure out the entire process of a feature, let’s say. So the more you know about some other fields, the better you can do it.

Robert [1:00:21]: And what I think helps here is, again, doing some pet projects that… It’s probably our example. It’s not that pet project because now we’re doing it full-time, but before doing it full-time, we’ve been creating those pet projects and we needed to learn how to do front-end, how to do some basic data science, how to do some basic UX, and I think it helped us over the years when we were working on just back-end engineering, mostly in a daily job. And also there’s one thing that it’s sometimes good to, learn is about some management basics. So if you’re a software engineer, it’s sometimes nice to work for a while as a manager, because you can also understand the wider picture and maybe understand how the component dynamics are working. Because often we can go into some extremes like, why those stupid people want something from us? And if you work as a manager for a while, you know that there is sometimes some reason for that and it actually makes sense.

Miłosz [1:01:38]: The dangerous extreme here is thinking of yourself as, I’m just a developer. Tell me what to do and Don’t make me figure out your issues. So, yeah, that’s probably what you don’t want to do, because then you become, well, easy to replace, basically, because you are just typing code.

Robert [1:02:13]: All right so we’ve already said that uh from where you can to recap maybe from where you can learn so books so that this is the typical place from where you can uh learn from and it’s good direction but remember to put the things that you learned in practice because you will just forget you learn pretty quickly and it will not give you that much uh that you read this book basically.

Miłosz [1:02:44]: What I like about books here is if they stood the time of test of time and became classics like the Pragmatic Programmer for example it’s an easy way to figure out that there’s something valuable in them but you have to be careful because the quality varies there are some books that probably could be could have been blog posts but there are also some timeless classics and it can also teach you some theory that’s very nice to know.

Robert [1:03:17]: Yeah, so videos, as I said, we are not big fans of videos. There are some for programming knowledge. Maybe it’s nice for some soft skills, but as somebody mentioned, it’s sometimes a torture. And I think it’s also a hard process of learning like that, because you cannot spend five keynote on watching that, switching to code and later watching, I think it’s not working best, basically. Or for example, watching something for one hour and going to code.

Miłosz [1:03:50]: It’s easy to get distracted or bored.

Robert [1:03:54]: Yeah, so I think we more recommend the way that, for example, we are promoting in our learning platform that you are learning some small part of knowledge, applying that learning piece of knowledge and applying that. But you can also do often similar things with the book, basically. What’s also helped to remember stuff, at least for me, but I think probably for most people, is making the notes of the book. I think it may sound obvious, but sometimes you may not have enough time to do that. But I highly recommend that because without those notes, the chance that you forget what you just read is pretty big. What also works for me pretty nice is doing mind map for some more complex content for more complex or more complex concept content yes, because it’s also helping to navigate through them easier and basically.

Miłosz [1:04:56]: Writing down in your own words often helps you think differently about the concept and also teaching others is very useful. Because then you try to figure out how to describe this in a simple way. It’s often when I write about some topics on our blog that I start to get a deeper understanding of it. Because you have to construct this series of thoughts that someone can read and understand. So having your own blog or even writing in private is super useful for having a more deeper understanding of those ideas you learn. And you can go back to it later in the review. Even if you don’t, it’s worth the effort, I think, because it just helps you think better.

Robert [1:06:00]: And again, writing notes with your own words, I think it’s very important because it’s forcing you to do some thinking process and just remember it better.

Miłosz [1:06:14]: And something I really like to do is mixing theory with practice. We mentioned it before as well.

Miłosz [1:06:25]: So, you know, it’s easy to go to the extremes here. So on one hand, you can be the person who just reads the entire documentation first and then starts applying it, which can take a long time and probably you will forget some parts of it. Or you can just try to blindly write it yourself and never consult the docs. It’s also probably not a good idea because you can miss some concepts. So usually what I like to do is, let’s say I use some new technology or library or something, to get the example from the documentation and have it running on my computer. That’s the first contact you have with it. You can see it compiles, you see it running, you can play with it. That’s how you learn how it works. And then you will probably run into some edge cases you don’t understand. This is where the frustration begins. And this is when it’s time to read the manual. Just go back to the docs, find maybe some theory of how it works and you just go back and forth between practice and reading. I think that’s what works best.

Robert [1:07:52]: One thing that sometimes people are mentioning that it’s great to learn from mistakes and That’s true, but it’s also not the most optimal way. So often you can lose a lot of time going… Around some simple solution that you don’t know that exists and in perfect word it will be cool if you can have some mentor so sometimes you can have some mentor in the work that you’re working on if not find some communities so for example like our discord that we have or there are some communities around our trainings maybe reddit and x may be tricky part because a lot of online communities are extreme and if you are less experienced, it may be tough. Some asking AI, it can be also sometimes.

Miłosz [1:08:47]: Yeah, it’s a bit like this. If you don’t know what you don’t know yet, describing this to someone, maybe AI, maybe not, can be helpful. I remember how I was a junior programmer, it was super useful to have some seniors around that I could nag with questions during the first few months of work. I think it’s a super fast way to learn. If you have some problems at hand, you need to solve, but you don’t know how, so you ask someone who is an expert in this area, and they can explain why and how it works.

Robert [1:09:36]: Yeah, and I think from my experience, probably sometimes we missed this mentor, this person that could say us that just do it in this way, because we spend sometimes a lot of time to figure out some stuff, just to learn later that… This is the typical way of doing this, and if just somebody said to us, it would save a lot of time. On the other side, it’s also a nice process sometimes to find a way to solve some problem and, it was also useful.

Miłosz [1:10:09]: But i

Robert [1:10:10]: Think it’s important to have some balance basically here.

Miłosz [1:10:16]: Yeah but yeah maybe i i use for this can be a good idea sometimes because you not everyone can afford to have a more senior person sitting next to them and teaching them about some concepts so if you can have the the model explain some things or explain why something is done this way or another. Coming back to the previous discussion we had, if AI is good for learning, that might be one good use case.

Robert [1:10:47]: Watch out for that, because it can sometimes say some stupid stuff. What also helps? I think it’s also good to sometimes feel as the dumbest person in the So basically, work with people that are more experienced with you. And if you sometimes feel that you’re not the dumbest person in the room, and maybe it’s time to try someplace where you will be the best person,

Robert [1:11:22]: and you have some people to learn from. Because this can really help you to accelerate your learning.

Miłosz [1:11:35]: So maybe online communities are a good example of that. If you don’t get caught in a flame war.

Robert [1:11:44]: Yep. So watch out for that. All right. So something to add, Miłosz, or we can go to Q&A session.

Miłosz [1:11:51]: Yeah, I think we can wrap up.

Robert [1:11:54]: So yeah, just a reminder. So if you have any questions now, please just leave on the chat, and we can answer that. Okay. Okay, so there is a question about our event-driven training. So it’s one typical question that we have. So yeah, the plan about event-driven training is that, as we mentioned a bit earlier, so now we are working on our AI mentor that is integrated with our training platform. After that, we are planning to do big update to event-driven training before releasing that, and after that we will release that. So this is our plan. If somebody who is listening to that, if you already have event-driven if you already own go event-driven training, no worries you also have access to this because, as we promised you have lifetime access and lifetime updates of it basically this is the plan, we don’t have exact dates because what is the reality of estimation so.

Miłosz [1:13:00]: We received many suggestions and feedback from trainees on the training.

Robert [1:13:09]: We also had a lot of feedback like this is the best training that I ever had but we all are aiming even higher.

Miłosz [1:13:16]: We also received some issues that we could solve and we wanted to build another training first but we probably will first update, go event driven before the next sale. So you will hopefully be able to learn even faster and better with it.

Robert [1:13:39]: If you are not in our newsletter, the best way to know about this is obviously joining that, so you’ll be the first person to know. Again, we don’t want to commit on any date because we don’t know. When it’s done, it’s done, but, trust us it will be really cool update together with this uh ai mentor that we’re working now so we are at the last mile let’s say and it’s really really helpful with many cases when you are basically stuck or you need some hint what’s about what this exercise is it’s it’s cool okay the.

Miłosz [1:14:19]: Next one from ryan hi self-taught two years in career changer i know i need to build and learn as i go i’ve been studying tdd bdd any tips to navigate the design of my data modeling user stories i’m so noob don’t worry and so this is about the modeling of Yeah, modeling of the design of the application, I guess. It’s a bit like DDD, but maybe more general.

Robert [1:14:54]: Yeah, so I think we already have some blog posts about domain-driven design. They’re not that big about modeling, I think, on our blog. So you can have some hints, but this is definitely the topic that we’d like to explore deeper because it’s useful for more complex domains. And we had some experience with that, so we’ll be happy to share that. So we have somewhere the plans to write some new blog posts about that and have also a training that is around it but well as we said for the previous question so we have pretty long backlog before before that but.

Miłosz [1:15:31]: Maybe the follow-up is relevant because then royans says learning to deal with malleability of software and wanting to design things as from the beginning as possible is crippling me. So I think that’s the core issue. You need to let it go. This is something we talked about in the episode about architecture. And maybe in some others as well, that you can’t figure out the perfect design from the ground up. It never happens, because the software will change with time. So instead you need to adapt, try to start with something simple enough that works well, and see what the issues are, and then iterate.

Robert [1:16:18]: Yeah, and I think what’s helpful is the approach that model will be never perfect. It needs to be useful. That’s it. It’s a bit like a map. So when you have map, we’re talking about map multiple times during this episode, but when you have map, it’s not a picture from satellite or it’s not very, it’s just detailed enough to know how to go from point A to point B. But it doesn’t have all details, but again, it’s useful. So I think thinking about models in a similar way is useful. that you can try to make it perfect but it will be never perfect as you said you change over time or won’t.

Miłosz [1:16:58]: Be complete probably

Robert [1:17:00]: Yeah yeah but it also doesn’t mean that you should just do YOLO and you’ll improve it later because it’s also not the best approach because if you just, take the old approach it will probably hurt yeah.

Miłosz [1:17:15]: This is the the hard balance between making software that’s hard to extend and going to the other extreme where you try to foresee all possible future use cases and try to adapt your software to be universal so it’s it’s quite hard but it’s like i think it’s a good philosophy to start with that you know you want something good enough for now and something that is easy to change in the future and

Robert [1:17:44]: Make it as simple as possible but not simpler.

Miłosz [1:17:48]: Yeah that’s that’s hard to do i mean we touched on on this in the first episode about writing low quality code it is a bit similar topic um where to you know strive for this super high quality where everything is perfect but the reality is you probably won’t get it and I think we’ve seen it best in one system where we tried to model this accounting domain. And I remember, I anticipated this moment when we will finally cover all the edge cases and it will be finished. But then it turned out, even our stakeholders who were accountants didn’t know how to do some things. And we just kept iterating and struggling for months. Turns out that’s the reality of them.

Robert [1:18:46]: And don’t be afraid that it will be not perfect because it will be not to set expectations. Also, when we are building some models that are far from being perfect, they are sometimes wrong. But again, as long as they are useful, it’s good. And practice helps with time. So you’ll have more idea how to get this pass. But, well, practice, practice, practice.

Miłosz [1:19:15]: The next comment is about this, exactly. I switched six years ago, completely self-thought. Plus about two years of theory courses before the actual switch. The only way for me is to get as much real-life experience as possible.

Robert [1:19:31]: Yeah that’s it i see that also martin mentioned so yeah without.

Miłosz [1:19:37]: Practice no theory will stick

Robert [1:19:40]: Oh yeah i think i can confirm that it so you have the same feeling after 20 years thank.

Miłosz [1:19:46]: You for summarizing our episodes in one sentence that’s exactly

Robert [1:19:51]: This.

Miłosz [1:19:54]: And as soon as you feel comfortable at something, it’s time to learn something new. Good point. I’ve switched to Go plus DDD a few months ago, and it’s still frustrating to learn new things. I’ll buy it a bit faster. Yeah, that’s a good point as well. I shared before that I felt a bit like this, working with LLMs recently. Because for a long time we didn’t touch much new technology i think we just know because we we’ve seen that for many product issues very often technology is not the solution you can you can stick to very boring and stable technology and basically achieve what you need but yeah learning about something new is exactly this is exciting at the same time but also can be frustrating if you don’t know how to move forward. The good part is, once you do satisfaction and you actually know you learned something.

Robert [1:21:04]: I think it’s also really that something really new appears that can solve some new problems. I think LLMs are pretty different because it has some use cases that it wasn’t possible to cover earlier, but from another side also a lot of companies are trying to find a problem for the solution. And it’s also pretty problematic because it should be the opposite. So you have the problem and you’re finding a solution for that.

Miłosz [1:21:35]: Okay and ryan wrap up props up um i also go back and review material frequently when i can remember something without looking it up um yeah

Robert [1:21:48]: I remember that when we worked in one company we have the book about ddd on our desks all the time and we were all the time opening the book and looking for stuff and it was like ah yeah it was something like that. But I think we learned during the time a lot. So it was just, okay, we had something in mind that it was solving similar problem. We were looking to this block. Unfortunately, the example was in Java. So it was like, okay, this is how it’s done in Java. Let’s try to figure out how to do it in Go.

Miłosz [1:22:23]: Yeah, but it sure helps to have this material Or documentation. Another way to use AI maybe is to have it summarize some parts of it for you.

Robert [1:22:34]: Or maybe put everything to RAG and query.

Miłosz [1:22:39]: That’s another good use case probably. Because you won’t host it as much if you provide the full context to it.

Robert [1:22:47]: It’s a very fancy search, but it can do more things than search. Because it’s not text search, it’s more like meaning search.

Miłosz [1:22:55]: But when I think about it now, you know, going back to this project where we started using DDD, imagine we had an AI fed with this entire book and we could just ask questions about something specific or make it change the examples to go. That could be quite cool. But also it probably wouldn’t be exactly what we arrived at. So I’m not sure if that’s a good or bad.

Robert [1:23:23]: Yeah, yeah. But it was definitely a value in figuring it out yourself. And, well, I think it may be hard to be junior now, basically, because, as Samadhi mentioned, it’s probably trying to avoid LMs in some cases, but it’s not always possible, let’s say. Okay and the last question on the chat so well why how did you decide to teach it’s more rewarding for you than just programming i want to teach and do presentations but i feel like i have no enough experience how would i start uh so yeah um so how we decided to do that i don’t know how I.

Miłosz [1:24:20]: Remember that there was some New Year’s Eve party, and I told you I thought about writing a blog, and you said, yeah, me too. Okay, let’s do this. Sorry, created a blog.

Robert [1:24:36]: I don’t have that good memory, but it sounds like a good beginning story.

Miłosz [1:24:42]: There was no grand plan, I think. For me, writing about stuff is, on one hand, satisfying and on the other, it also helps me think better about the subject. So that’s what we mentioned about teaching others. So I think if you feel like it, definitely go do it.

Robert [1:25:04]: And I think you don’t need to be super experienced to do that. So i think earlier you begin then better and don’t be that much afraid that okay i will write something stupid or something like that it’s not that big deal to be honest i mean it’s hard to overcome that but at some point you will forget about that so if you start but so i think the good thing about is that it’s as you said it’s helping you to structurize the knowledge that you have and also i believe that skill of writing clearly it’s useful in multiple cases so as we mentioned a bit earlier so it’s helping you to convince for example your teammates to go in some direction write some design documents for some problems that you are doing and you can benefit in many fields from this skill, basically.

Miłosz [1:26:05]: And especially presentations are also not exactly about what you invented or discovered. There’s also how you present, how entertaining it is, and so on. So you don’t need to invent something great to be a good presenter or to be a good writer and yeah there’s probably still like space for for new articles good articles because especially now I think we are you know scattered with this AI-generated trivial posts on topics and spend time to write something great.

Robert [1:26:57]: And yeah, I think it’s again no silly bullet but what we recommend is creating the deep dive articles that are five times longer than average article in the topic and I think that this is some niche. And obviously, it requires more time to write that. Less people will read it. But I think in long term, it will just work nicely. And I think it’s also good to write about timeless things. So we mentioned those timeless things multiple times. But to give you a good example, so the blog post that we wrote about repository pattern six years ago, I think, probably last month we have like 50,000 visits because it was just reposted on Reddit and it went over the entire internet. And again, it’s probably since the start of the blog, I don’t know how many people read that, probably, I don’t know, 200,000 people or something like that. But it wasn’t in this one year. It was over six years and it’s still pretty valid and it will be valid probably in 10 years. So, but again, it took us some time to write that, but from other side, probably there are no other articles on repository pattern in Go that are that deep. So it’s some niche, obviously. And you also asked if it’s more rewarding than just programming.

Robert [1:28:22]: Oh yeah, definitely. And I think it’s also worth mentioning that probably you are still programming more than teaching. Well, we love to write code and I think it’s allowing us to have more ideas what we can teach, but it’s about some balance. And I think it’s just making it all more fun.

Miłosz [1:28:46]: Maybe we still do program what we teach through the platform. And maybe just one part of the story here is that we wrote a blog post, we had some example projects, and we wanted to recreate this idea. We talked about in this episode about being able to read some theory, write some code, and do it back and forth. To help people learn. That’s how it happened.

Robert [1:29:24]: So TLDR, I recommend it.

Miłosz [1:29:28]: And share with us once you do.

Robert [1:29:30]: Yeah, definitely. If you would like to also have some feedback, we can also help a bit. Right, so it seems it was the last question that we had. So last minute to… To ask us questions.

Robert [1:29:57]: Alright, and so while we are waiting for the last questions, just in case if they will arrive, so just a reminder. So if you are not part of our newsletter, I recommend to join that, because we recommend to subscribe us on all platforms where you are watching us, listening to us but newsletter is the best way because we cannot control magic algorithm of other platforms but newsletter you will be sure that will notify you about new episodes, so remember to do that uh if you have any comments questions leave us comment on youtube we’ll uh we are answering all the comments and we can also improve the and or touch it in the future episodes please don’t forget to leave us thumbs up five star review because again deadly argo algorithms are are ruling the world and without that more people will not hear about about our live podcast so yeah that would be it for today i think so thank you miłosz for today’s episode and see you in two weeks where we’ll talk about the popular Go opinions we have.

Miłosz [1:31:16]: Exactly. And why are we controversial?

Robert [1:31:18]: Hopefully.

Miłosz [1:31:19]: Can do it.

Robert [1:31:20]: And if you are not writing in Go, join us as well. Maybe you’ll learn something new.

Miłosz [1:31:26]: Or you can learn Go in two weeks using our learning platform.

Robert [1:31:30]: Or maybe in one evening.

Miłosz [1:31:33]: Okay. Thank you everyone for joining us today. Thank you, Robert. See you in two weeks.