In this episode Wojciech will tell us about a new course he is preparing for us all. It’s called Maintainable React Native. Enjoy!
You can find us on https://brainsandbeards.com/
You can find our course on https://brainsandbeards.com/mrn
Key Moments
Hello, wonderful listener. Today, you are listening to a new episode of the Brains and Beards show, where Patrick and Wojciech discuss programming, building teams, workflows, and everything else that it takes to deliver great mobile applications. In this episode, Wojciech will tell us about a new course he is preparing for us all. It's called Maintainable React Native. Enjoy.
So welcome Wojciech. Welcome, Patrick. Happy to hear from you. Yeah, me too. And I'm really curious, what will the course be about? Well, it's not bait and switch, so it's going to be about building maintainable React Native apps.
It's an email course, and targeted towards experienced developers, and it will help them create good maintainable architecture for their mobile apps. It teaches the foundations of making good long-term software design decisions,
because that's the thing that will ensure that your team can stay productive for years to come. And that's the end game for maintainable software, staying productive. In practice, it means that you get an email every week, where we talk about software design concept, and end with a practical takeaway.
Week by week, we'll go over all the major parts of a modern mobile application.
We start with the ways of handling remote data. We can talk about state management design systems, and a lot of stuff in between, up to the latest point of the release cycle, which basically is mobile DevOps.
So yeah, we want to touch on every significant part of your mobile app. When I think about online courses, you have to invest some time into it, in the way that, OK, I will subscribe, and I will want to finish it, but sometimes the content is not for me, because it's all too easy or too hard. If you can describe for us, who is it for? Do I need to have a specific experience to join? Or if you can give us a little bit of hints,
what do you need to know before joining? Yeah, that's true. I mentioned experienced developers, and this is a term that means a lot of things to different people.
So let's narrow it down.
I mean, people who already know how to build a React Native application, because we're not going to go into the details how to, I know, add React Navigation to switch between screens.
But at the same times, those people who might not have the time to figure out by themselves the right patterns that they need to make the app maintainable in the long run. So there are a couple of questions here. It's the course for me.
Most important question, am I working right now on a React Native application professionally?
If yes, then if you're experienced enough to work on one, probably it's for you already, like you filled the basic threshold. But there's a second question. Do I need this course? The symptoms that I would say mean that it would be worth for you to join, as if you experience one of the following happening to you or to your team. Because if you in particular do not have a particular issue, but your team does, it's still your issue. You have to solve it somehow. One of the symptoms would be that you start working on a new app, and the work goes pretty fast. Everybody's adding new features. But as the code base grows, you notice that productivity slows down significantly.
Of course, we know that productivity will always slow down with the size of the code base.
But it shouldn't be such a huge difference, as we often see, because that's what maintainability of an application influences. If it's hard to add new things, and up to a point where you feel like you work hard through the whole sprint and nothing came out, yeah, you definitely need some help there. Another symptom would be if you find it hard to debug what your code is doing and how the data is flowing, what's happening inside your app. It probably means that you might have a case that, like, everything is connected to everything else, and it's hard to figure out what's going on. That issue, I feel, is very important to be able to figure out what's going on in your app. This kind of grokability or readability of your code is, my opinion, super important. And if you don't have it, like, I talk a lot about how to get it.
And the third symptom that is interesting is that a lot of teams don't have a concept of what is an architectural decision and what is not. They just, like, build features and they add packages that they need. And sometimes we lack the vocabulary to talk about issues that we might encounter or lack the vision to see them. And if you cannot see them or you cannot talk about them, there's no way you can spot the issues or solve them. And I think it's important to have some understanding of basic software design. And it's also what I'm hoping to teach you in this course. Like, it's a side effect because it's focused on practical takeaways and building great apps. But I feel it's something that you will have to pick up on the way naturally. Can we expect an outcome? Like, what would the new me be after the course? What can I expect I could take away from the course? Of course, taking this course, like, you take it for a reason and you're expecting, like, a before and after of your day at work. I believe that after is that you will know how to shape a code base that you can keep modifying without getting bogged down by the sheer growth of the code base. The size, you can avoid most of the unnecessary complications. So the new you knows how to shape a code base instead of making just changes that you feel are beneficial in the short run, but without having the long run in mind.
Another thing that you will learn is a new, a clear architecture that you can easily explain to when onboarding new colleagues, because you will learn the vocabulary, how to talk about the design choices. And also, I offer advice on what I think, well, what is the best choice for my project. So if you're not unsure, like, what approach to take,
there will be a guideline for, like, hey, I would do use the X approach, use the Y approach. But I'm not trying in any way to force anybody to use the right tools. I don't believe there is, like, one particular way of building things. And I talk very heavily about the trade offs of all different approaches, because I believe that it's critical for any architectural choice, not on not talk about the benefits, but to talk about the drawbacks, because the benefits are easy to see. But the drawbacks is what people often forget.
And they're always there. If you cannot see them, it means probably that you didn't evaluate an option or DPNAF.
So the final change would be, you will learn a skill, how to evaluate external libraries for your team's independence. So a lot of times we evaluate the libraries, as I mentioned, for the benefits they bring.
But we forget about the lock-in. So if you choose to use a library that will be present in every screen in your app, then you have to know what kind of doors does it change for you. So, for example, you use GraphQL that will handle data fetching for you. You have to take into account that basically data caching is done by GraphQL layer right now. And if you want to modify it, it's going to be more work because you're not working with your caching system. You have to hook into GraphQL, which is always going to be more complicated. And there might be things that are just not possible. So you're getting a benefit, but you're sacrificing a bit of the flexibility.
And that's something we also talk a lot because, as they say, the best choices are the ones that give you benefit but still keep the options open for the future. So you can pivot easily. SL. Oh, at least explain the others that, because sometimes perhaps you have to use it, but people don't realize what are the disadvantages of the choice. SL. Yeah, I think it's very important to take into account the flexibility when you make a decision and make it part of your decision making. It's not the most important factor, but I think it's very important that it is a factor in the decision. SL. Okay. So what does it cost? Do I have to give up my arm and liver for this? Or what's the deal? SL. No, definitely not.
It will never be liver priced.
And for now, it's free, actually. The reason it's free is we're still experimenting with the format. And I don't want to have the additional pressure of not matching the expectations of the people who paid for it. So for example, somebody expects X because I promised this in this podcast. And over the next couple of months, I decide to spin a bit in a different direction. But they already paid for it. They would have a good reason to be made about it. And the course right now is a bit dynamic. I'm still working on it. It's not a "sona finish" thing. I have a good reason to believe that while it reaches the final version, it will probably be paid. So there's one good reason to join right now. If you do now, we're not going to cut you off in the middle and tell you to pay the money. If you subscribe now, you'll be able to finish it all the way until the end without paying anything.
But the second benefit, which might actually be more important than the money cost, is that if you join now, you will also be able to react to the content that you're getting. Because as this course is evolving, I'm very keen to hear your feedback at this phase. And if you have particular subjects that you would like to discuss in future lessons, or you have an interesting approach that you would like to share, I am very happy to let it influence the course itself.
So yeah, if you're excited about ideas like this, and you have thoughts to share, definitely you will have an option to share them. At least in this stage, it's not meant as a passive piece of work that you have to absorb. It would be great if you want to treat it as the start of a discussion. I'm always happy to discuss those subjects as all my colleagues know pretty well. So it's free for now, and you can help shape its future. So it's a very good moment to join and to use this opportunity.
And so perhaps, okay, you heard a lot of cool things about it. But we probably need a little bit of credibility. Why should you subscribe and invest the time in reading those emails from us? So why us? Probably you don't know it, but recently we had an eight year anniversary of our company. And we've learned a lot along the way. And we've jumped on the React Native bandwagon fairly early, like, I think seven years ago, something like this. So we have collected a lot of experience. And we worked on...
I did not count it for this podcast, but I'm sure above 20 different React Native projects, probably well above that. And we've seen, because we're often involved for a long time with a project, then it's not just an experience of working on the greenfield stuff. We handle a lot of legacy.
So we've seen teams and businesses evolve around the code base and also seen the code bases adapt to changes in the organization.
Basically, I feel those lessons are important.
And of course, not many people have the luxury to invest 10 years into working through with different React Native apps to get the experience yourself. Because of course you can learn all those things yourself. But yeah, it's based on a lot of experience down in the trenches that we have. That we just want to save you from. For me personally, it is sad how many times I've seen some of the mistakes happen in multiple places.
And I believe that we can save at least some of them by sharing the information that we learned. Similarly, how we do this podcast. The reason is not that we like the sounds of our voices, because we actually don't. I don't like mine. But we feel that we kind of owe it to the community to let people benefit from all the mistakes that we did in the past and all the great things that we managed to do. SL. Yeah, and perhaps just to add something on the top here. It's not only about the eight years what we were doing with React Native, but as well our experience from the past.
Voiteng and me, we were actually writing backends in Ruby on Rails and other languages
many years before that. So we not only have the perspective of the one side. We are not only like say the consumers of the APIs which builds the front end from the apps, but as well we were on the other side of the fence writing those APIs. We know how the APIs change and what versioning is and so on and so on.
We can share this perspective as well and the other view of development of the application.
SL. I'm glad you touched on that, because there's one more thing I forgot. We were discussing the technical perspective of the course, how the front end and the back end and the data flowing and versioning. However, a lot of the experience how you work with a code base is based on communication within a team, between the teams, on project structure and requirements changing. All of those influence how we write our software and they are all things that I talk about in this course. I take them into account. There are some things that I suggest that might not be the best technical choice, but are the safest choice from the perspective that I've seen.
For example, changing requirements. Even if the business says that we're going to do it one way and it's never going to change, probably it is useful to not trust it and build your software in a way that it can adapt to a situation that five years down the line new information comes in. Those basic things that were supposedly set in stone are different right now. This is a big context that I share in this course, because I very strongly believe that it's an important part. SL. As Wojtek said, you may be happy right now, but I suggest you join this course and you can be happier yet. SL. True. The worst case scenario, you're just not while reading the email and you feel better for yourself that you already know those things. It's always a nice way to start your week. SL. Perhaps if it's not for you, you can recommend to some other colleagues.
Everybody of us is on a different path on a different state of the journey. Even if it's not for you, you're going to have for sure other colleagues which could benefit from it. So thank you for this great description and thank you for listening.
I hope to see you soon in another podcast. SL. And I hope to see all of the listeners on brainsandbeards.com slash mrn, like maintainable React Native, and subscribe. I hope to see you there. SL. See you everybody. Bye.
SL. Thank you for listening to the episode. Please subscribe if you haven't yet and if you like our show, consider sharing it with your friends. You will find notes to this episode on our page, brainsandbeards.com slash podcast, where you can as well give us feedback or suggest a topic for the future episodes. We would be very happy hearing back from you. Stay safe and curious. Till the next one. Bye.