AMA #1: Clean Architecture, Learning, Event-Driven, Go

Quick takeaways

• Go in the AI era: Go is excellent for AI applications, as the built-in concurrency makes orchestrating parallel API calls much easier than languages like Python
• Architecture philosophy: Clean Architecture isn’t always necessary. Start simple and add layers only when you feel the pain of complexity, not because someone said you should
• Career transitions: Switching roles within tech is easier internally. Moving from sysadmin to developer works better within the same company where people already trust you
• Go design patterns: Small interfaces near usage is the Go way. Duck typing allows you to define interfaces where they’re used rather than in separate layers
• Distributed systems: Async communication often solves sync timeout issues. When dealing with chains of service calls, consider using messages instead of increasing timeouts

Introduction

In this special 10th episode, we answer community questions in our first AMA format before taking a summer break.

We discuss Go’s role in AI development, Clean Architecture implementation, career transitions in tech, and distributed system timeouts.

After the break, we’ll switch to pre-recorded episodes with improved production quality. We still plan running some live episodes like this one, so stay tuned!

Show Notes

• The new Domain-Driven Design in Go training we announced
• Team Topologies book mentioned for organizational architecture
• Join our Discord community for more technical discussions — we’re happy to help!

Quotes

Architecture sounds like something complex that architects do. But it’s basically stuff like “if you have 10 services connected with synchronous calls, what happens with timeouts?”

Five days of coding can save one day of planning. And it’s often the case. And even if it’s not visible on the first sight, it’s often visible during review that is going for ages.

I really like this idea of fixing something once you feel the pain. If something is not painful maybe it’s fine even if it’s not the best. Maybe it could be refactored, maybe it could be split to modules or whatever but if it’s not painful you probably have more stuff in the backlog to take care of.

In many cases we hired people that didn’t write a line of code in Go earlier. It wasn’t an issue in the end, because those people were productive very, very quickly.

Often people are like, I am just a developer, give me the requirements and I will transfer them into code. So yeah that’s not really helpful for most companies, because they need people who can understand the business domain, can help people figure out what the product needs.

Go is also a great language to be generated, thanks to the syntax that is simple, But it’s also very strict. So, for example, if you have some agent that is generating your code, it’s easy to verify that.

Timestamps

• 00:00:00 - Introduction
• 00:03:32 - Go in the AI world
• 00:15:00 - TDD in Go
• 00:23:44 - Career switching
• 00:38:35 - Clean Architecture interfaces
• 00:42:10 - Distributed system timeouts
• 00:53:31 - Domain vs application logic
• 01:04:09 - Small teams architecture
• 01:07:30 - Under-engineering risks
• 01:16:12 - Future plans

Transcript

Robert [0:00]: All right, so welcome in our first AMA episode.

Miłosz [0:04]: Hello everyone.

Robert [0:05]: Last episode before short summer break. So we have a couple of questions to go over today. And just as a reminder, so if you have any extra questions, just feel free to leave it on the chat. We’ll also be happy to answer that.

Miłosz [0:21]: This episode is a bit special because this is our 10th one and we will end the live format this way.

Robert [0:29]: Or at least partially. I mean, I think if you like this AMA format, there is a chance that we may have more episodes like that. So we’ll ask real questions and we’ll run it live. But in general, it will be no longer a live podcast, it will be a podcast. So we’ll basically pre-record most of the episodes and you’ll be able still to watch them on YouTube, so it will not change. And yeah i think it should improve the sound quality the video quality because well it’s not the simplest way to make it live and to make it sound great because it’s live so it cannot i mean it’s easier to tweak sound after recording obviously it’s a bit harder during the recording the second thing is obviously video uh the third thing is that a bit less obvious that is that we We don’t have our own room to record, so sometimes we need to improvise a bit to record in different places. Like today, so when you’re longer with us, you might notice that we’re in a bit different background. This real background, so…

Miłosz [1:39]: I hope the next episode should be much more professional,

Robert [1:43]: Let’s say. But you will see. It’s a surprise after vacation, so after we’ll be back, I guess, in September.

Miłosz [1:50]: Probably, yeah.

Robert [1:51]: Yeah, yeah. So this is the thing. So yeah. Improve and yeah it will be also a bit i think um content quality should be also higher because when we are recording it live you know it’s also a bit challenging to go with the flow and try to avoid a lot of pauses and try to maintain the flow obviously when it’s not live it’s much much easier because we can pause we can just cut it later we can think about topics so but yeah i think it was It’s a nice experiment to try with the live format and, again, it’s not like we’re dropping that. It’s nice that we have already working setup for that. We have the space, but it’s just a bit changing of the bars.

Miłosz [2:33]: We also received a lot of feedback. It would be useful to have some diagrams, some visual aid to what we are discussing. So maybe we’ll also try something like this in the future. So it’s not, you know, so you have a video with some helpers or something more interesting like coding, not only talking.

Robert [2:53]: Yeah, but no worries. So if you are listening for that in the podcast applications, also we don’t want to make it hard to listen, just listen. So, you know, sound is always the highest priority here. What else? Yes, I think that’s all about the format and I think we should be able to go to the questions.

Robert [3:16]: Or maybe you have something to add before.

Miłosz [3:18]: Yeah, if you have any questions, leave them in the chat so we can pick them up.

Robert [3:29]: All right so questions so the first question is what do you think the future holds golang developers in ai forward world so i think we can have i actually have pretty a lot to think to say about that because we have the mentor functionality in our online trainings and from what we see how people are using that it’s super useful and especially compared to some other ai solutions because i think it will be not only my experience that very often when you see some ai functionality it’s just unpolished i mean you can have impression that somebody just get the api of open api of open ai or cloud or whatever just put some empty simple prompt and that’s it or like for example if you have iphone i mean it’s not the best implementation in the world with everything and the AI implementation.

Miłosz [4:24]: As a user, it’s hard to get right. You can guarantee the answers.

Robert [4:31]: I think it’s also easy to have something that works, but it’s much, much harder to have something that helps. But I think it’s a bit off topic. The question is more about Golang developers in the AI of our world. So what do you think about how Golang fits with this AI world?

Miłosz [4:50]: I would expect most developers to use APIs, just call the RLMs over an HTTP API. And something that probably everyone does in Go anyway. So technically it’s not that different. And if you write more agentic systems, like we did with Mentor, The hard part probably is the orchestration of it all. So there’s a lot of loops and parallel function calls. And I think Go is actually great here. We’ve seen it work well when we designed the mentor feature, because goroutines give you very easy-to-use tools to create parallel requests.

Robert [5:47]: And to cooperate with Python, so I think we are probably pretty good people to talk about that, because we professionally work with Python for some time, and doing this parallelization in Python is hell, in a very big simplification. And Go is basically created for that. So running something in the background is just a matter of using the Go keyword. And it’s simplification obviously, but compared to Python, it’s like deadly easy.

Miłosz [6:20]: Other than that, you will use probably the same tools you use now for development with LLMs, just calling them, and you know, it won’t be that much different.

Robert [6:35]: But I think this parallelization, this is the key, because when you’re building some agentic flow, usually you’re doing some operations that are slow. They are not CTO-bound operations, but they are still calling some API, they are doing some operations, and just doing it synchronously, it’s super, super slow. And this is why I think Go is just perfect language. I think it’s not only my opinion that Go is a perfect language for building AI or LLM or Gen AI applications.

Miłosz [7:09]: Because it works. We will have a separate post on our blog soon. It writes up in detail how I do it. In short, there are a couple of complex parts, right, working with AI. One is prompt engineering. The hardest probably for me was writing evals, so testing the AI code. It’s super difficult. And the last one probably is orchestration of it all, which is the same code you are used to writing. It’s kind of like business logic for your AI agent.

Robert [7:46]: The only difference is that the result that you expect is not that strict. As you mentioned, the problem is that if you have written some prompt, it will maybe work in 90% of cases, but maybe just 10% is the hardest when it’s doing some bad things that totally unexpected, and you need to spend a lot of time to convince it that, no, no, no, it’s not about what… This is not Go-specific, but Go, I think, is helpful for that because, for example, the Go test package, it works pretty nice with that. So you can do some simple wrappers and write evals for that. So that’s pretty cool.

Miłosz [8:28]: In general, expressing business logic in Go is quite easy, or at least works for us well. Because we have this explicit approach. You have no magic in place. You can just re-read code and you know what it does. So it helps when you define Domain objects, business logic and such, and similarly, when you write this agent logic, similar idea. So it’s much easier this way.

Robert [8:56]: I think it’s one important thing to mention here that if you are talking about, writing some Gen.AI applications, it’s not data science. I mean, because often when somebody is talking about machine learning, AI, Python is mentioned, but Python is great for data engineering, for data science, but using general AI, I think it’s pretty far away from data science. It’s more backend at the end. I mean, you’re doing some API, you obviously additionally have prompt engineering, but I mean, it’s big simplification, but it’s very, very close to backend in general. And a lot of good practices that you know from backend systems are applying one-to-one.

Miłosz [9:46]: You don’t need much background about machine learning or RLMS in general to start.

Robert [9:52]: I think probably a lot of people can compare it to driving a car. It doesn’t need to be mechanic to drive a car. Maybe if you would like to go to F1, maybe you need to have some mechanics background to understand very special details of the car, but it’s just or top level.

Miłosz [10:14]: Can we comment on the audio? It’s not clear. Pull your mic closer. Or even maybe using some specialized tools of API.

Miłosz [10:29]: It’s basically the same idea.

Robert [10:38]: Okay, so we mentioned Go, how it’s compatible with AI for our world. I think it’s one more thing, because AI is very wide, ARIA, let’s say. So we have building some JN AI applications. We have also Vibe coding. We have generating some code on production. I think it’s also very interesting, we will think about Go, because Go is also a great language to be generated, thanks to the syntax that is simple. but it’s also very strict. So, for example, if you have some agent that is generating your code, it’s easy to verify that. There are no many options actually how it can be generated. Like other languages, you can do things in 10 ways. That’s making generation a bit harder and it’s also harder to get the syntax right. But in Go, thanks to having it pretty simple, I think I also seen even some studies based on that and covering that.

Miłosz [11:36]: You’ve got types also in compiling, which is a big plus compared to dynamic languages.

Robert [11:43]: Yeah, yeah. So, and I think it’s also out loud that, okay, you can probably easily generate JavaScript that will compile, let’s say, but it doesn’t mean that it will work properly. And for example, with Go, this is the language that for the first time I have the ceiling that, okay, I’ve written something, it’s compiled, and it works. With languages that are script languages, it’s not that obvious, because it can execute, but at some point it can show exception that, okay, it doesn’t make sense, sorry.

Miłosz [12:15]: Yeah, you’re relying far more on testing.

Robert [12:18]: Yeah.

Miłosz [12:20]: That’s why I remember working with Python. We need far more assertions about what, for example, what some method returns, which is just not an issue with strongly typed languages, which is, no, it’s like nothing new, but if you generate the code, the less time you need to spend reading it, the better probably. So you don’t need to analyze, you don’t need to test such as edge cases, because the compiler does it for you. That’s a B+.

Robert [12:52]: Yeah, so Tldr, in our opinion, and not only our Go is great for that. Oh, and maybe one last point about that, it’s performance, because also some people might say, okay, Python is slow, but I know maybe Rust will be faster. But remember, so what’s the battle like in your Gen.AI applications? It’s not CPU. It’s usually I.O. call done to some external server, so basically it’s doing some network calls. And for that, actually not CPU matters that much. It’s more about goroutines. And Go is I think even more efficient than Rust in running goroutines because it’s not using OS, I mean, it’s using operating system threads, but it has also its runtime.

Miłosz [13:38]: I guess you can do the same lightweight threads or coroutines in Rust but with probably not such a built-in API. But it’s also something that many people overlook. They focus too much on the performance. I’ve seen some AI frameworks that claim that they are the fastest framework in the market. And as I said, it makes zero sense because you will wait a couple of seconds for the alarm to respond anyway. So if you optimize nanoseconds or milliseconds of your framework, virtually no gain. It’s similar to how people tend to benchmark Go routers for HTTP, which apart from extreme cases is not that important. If you if you talk about network and you use JSON Marshalling and you will be kind of slow but good enough anyway so the nanoseconds don’t matter that much yep ah great

Robert [14:57]: Okay so the next question uh so the next question that you received is about how software development looks in go is it just a driven development uh so tdd yeah so it’s interesting question so i would be interested to hear more about the background but probably will not know but yeah, I think it depends a lot and it’s not like everybody does TDD in Go. I would even say that probably more people could do that.

Miłosz [15:34]: Yeah, I think TDD is very popular in Go, but probably similar to other high-level languages. I don’t think there’s a big difference there. It’s just TDD is not, no, it’s language agnostic, so it doesn’t matter that much.

Robert [15:54]: And probably compiler adds one extra step because you need to make this code compiled at least, but it’s a different level.

Miłosz [16:04]: Do you use TDD?

Robert [16:06]: It depends. So yeah, I think it depends on what kind of code I write. So for code that I know how it will behave, and it’s kind of clearly defined what I expect for that, it makes sense, because I can start with tests earlier. One nice thing about TDD is also that it’s helping to make nicer interfaces of the things, because, okay, you know what’s the expected interface, and you’re writing code for that.

Miłosz [16:40]: Or designing the API. Yeah, a nice tip.

Robert [16:44]: But, for example, when I am experimenting, or I don’t know what I would like to achieve, or I know it may be a bit controversial, but I know that for this functionality I don’t need tests, because it’s just obvious enough, and it will not add enough value. It also doesn’t make sense.

Miłosz [17:06]: I actually find it helpful when working with AI to generate code. Sometimes I will use AI to generate something like, you know, a very specialized algorithm. For example, the other day I had to process a file to, I don’t remember, remove some lines or whatever in a very weird way, and this actually is pretty cool that you can define the function interface, write the tests for it, which are very simple because you have just input and output, then use AI to generate the body of the function.

Robert [17:43]: And AI has nice specification basically.

Miłosz [17:46]: Yeah, you can even give it the tests. And what I like about it is that if it’s a small function and I can define the tests well, I don’t really need to care if it’s cover or corner cases. Basically, I don’t need to care how the code works. I can treat it like an external library when you use an external library you don’t read all of it to make sure it’s nice and I don’t know,

Robert [18:15]: More optimal sometimes better to not know yeah.

Miłosz [18:20]: Exactly and so this is similar so this is kind of TDD, I would say because I focus more on the tests and I can write down first and then generate it and now I can just take

Robert [18:33]: AI TDD.

Miłosz [18:37]: I can take a look on the generated code, but I’m like, okay, if it works, I’m fine. Whatever.

Robert [18:44]: I think also to make it super clear, so there are multiple, let’s say, classes of tiers of code. So it’s some component critical code. Probably this approach may be not best, but sometimes you have code that you don’t care that much. It’s some simple functionality.

Miłosz [19:01]: You don’t want to maintain over time.

Robert [19:03]: Yeah, maybe you’re just writing some ugly tool to do something once. And I would say that even just writing tests for that, it’s a lot.

Miłosz [19:15]: For me, it’s like algorithms in general. Like when you have to parse something, when you go line by line and save some results over time. I had a couple of examples like this recently. and this works pretty well because you can do it but it will take probably about an hour or an hour yeah unless you like doing this it’s

Robert [19:37]: Also like a cool it’s a strange hobby but I know that people like that.

Miłosz [19:42]: It’s like a cool puzzle to solve although people complain about hacker rank exercises so maybe not everyone likes that but yeah it’s But coming back to the question about what is the software development, how does software development look like in Go? I would say it’s like any other high-level language probably. There’s no specialized methods.

Robert [20:16]: But also, from my experience, it’s also pretty, let’s say, opinion, but I have also some feeling that compared to some other languages, in general, some library code quality is a bit higher than in other languages. So maybe it’s also thanks to the language, to how strict it is, but this is my feeling that I have sometimes also. I don’t know, maybe it’s subjective, but it’s something in that.

Miłosz [20:50]: Yeah, perhaps.

Robert [20:53]: Probably it’s not related to this class-driven development.

Miłosz [20:56]: There are some approaches, but I’m not sure if I would count them as a methodology, compared to the TDD. Like you know avoiding frameworks could be one example but it’s more like what the community likes to do

Robert [21:11]: Not.

Miłosz [21:12]: Really a methodology

Robert [21:14]: But it’s also coming from the language design yeah it’s I mean language is designed in a way that it’s, good that you don’t need to go into frameworks because you have some interfaces already defined that you can integrate with so it’s a nice thing It’s some special thing about Go, but it’s not a big deal for others. One good thing. I guess that the person that asked this question may not… The person mentioned that this person is learning Go, but also keep in mind that Go has one big nice advantage. You can learn Go very quickly and be productive pretty quickly. So when, for example, we had our teams, in many cases we hired people that didn’t write a line of code in Go earlier.

Miłosz [22:05]: Because it was difficult back then to find people like that.

Robert [22:09]: Yeah, but from the other side, it wasn’t an issue at the end, because those people were productive very, very quickly. And it’s not like there is some magical technique that you need to learn to use Go. It’s basically, you can learn the basics of the language and use the principles that you use in many other languages.

Miłosz [22:33]: Well, the risk here is that if you hire a team with people from different backgrounds, we have a diverse team, which is nice, but also people might start writing Go, like they used to write Python or Java or whatever. So they need to be kind of aligned. So we spent some time to help them learn.

Robert [22:58]: And I think this is an argument that we heard very often, that in terms of complex codebases that people were, copying some patterns blindly from Java or from C Sharp, but at the end it was very complex. So yeah, it’s probably something to watch out.

Miłosz [23:17]: Yeah, it’s a classic discussion around clean architecture. Is it still Go or is it Java? you should start doing it.

Robert [23:29]: Stop doing Java from Go.

Miłosz [23:35]: Well, I guess you can apply it to any language, really.

Robert [23:39]: That’s true.

Miłosz [23:41]: Go too far.

Robert [23:44]: That’s true. Okay, so another interesting question that we had was about switching a role. So the person was a sysadmin, and the question is actually how to… So we can probably generalize that. So how you can basically switch a role when you are, for example,

Robert [24:02]: sysadmin or maybe data scientist or something else and try to go into software engineer path. So maybe do you have some examples of people that did this transformation and how they approached it?

Miłosz [24:21]: Yeah, I’ve seen it happen within teams. It’s much easier to do it within the same company than just trying to be hired right away. It’s basically like starting in software development in general. Everyone knows being a junior is not ideal because we need some skills, to take proven skills into a portfolio to be hired, and it’s the same idea. But if you are already hired in some kind of team that works closely with software, it might be easier to start helping this team a bit, learning how they work, I might be doing some part-time work there for a time so I can see if you like it and if they like it. Yeah, I had a friend who was in the chat switch from front-end to back-end this way. Kind of similar, I guess. Like sysadmin to back-end and front-end to back-end I guess, pretty close, maybe front-end is a bit closer because it’s software development, but still you need some skills you didn’t have before.

Robert [25:49]: And I think, so what you said, it’s some kind of internal team transfer and if you are kind of person that people know within the company that they can trust you and you are nice, it’s a bit easier to do this transfer because if you are joining a new company, it’s harder because it requires much more it involves much more risk for this company, so hiring, this kind of person let’s say also it’s possible, but I think it requires much more time to prepare portfolio, maybe some project that you work in and yeah, it’s probably easier than just going outside of tech to tech obviously if you are within the tech.

Miłosz [26:32]: So it’s much easier because you already have some contacts with the people you can spend some time with them see how they work I’ve seen people do it from like a technical support role for example because this was area where they had to know the technology very well already to help clients and they were in close contact with developers so it was quite natural to just over time move towards development and remember,

Robert [27:03]: Be nice to other people because if you are not nice for those people, it’s much harder to do this move. But unfortunately, sometimes if you are doing this kind of big change, sometimes you need to expect some salary downgrade.

Miłosz [27:20]: Unfortunately. Yeah, for sure. And title downgrade probably too.

Robert [27:26]: Yeah, but it may be worth sometimes, especially if you don’t feel in your role that it’s something that you would like to continue with. And yeah, I think also one nice tip maybe to try, okay, if you are looking for a company where… Try to find a company when you can use both parts of your skill sets, for example your sysadmin. So obviously it’s not always easy to find this kind of company, especially if market is harder, but sometimes you may find a company when they are looking for a software engineer with sysadmin skills, for example, and it can be nice advantage. Or for example, if you’re switching from front-end to back-end, you may look for a full stack role and try to do less and less.

Miłosz [28:14]: So this is the idea of this T-shaped skills, right? They are super proficient in one area and a few others, just a bit. But it’s great if you have a team and you have someone with, for example, cloud skills or SysApp skills. So the rest of the team doesn’t need to go that deep in this topic. And this person usually is happy to handle them.

Robert [28:39]: And yeah, this is the thing that also you recommend to do to basically go very wide with the skills. Obviously at the beginning you can focus on one area, but, At some point, I think it’s nice to try other areas, for example, for a back-end developer, try a bit of front-end, a bit of data science, a bit of sysadmin, a bit of devops. Why devops is probably not the best term for that, but okay, let’s use it. And it’s nice, because maybe you may find a role that is different and you like more, for example. And I think some projects that you are doing after hours, it’s pretty good for learning that. But you might discover that, okay, maybe there is some role that you prefer more. And I think also this kind of people are also very valuable in the team, because if you need to collaborate with other teams, so with some sysadmins, with frontend, with some cloud ops or whatever, you have more knowledge and you can, you know, have a discussion and, you know, because if you are working as a developer, you often may need something from your cloud operations team. And if you have no idea how it works, it’s, you know, sometimes hard to request something.

Miłosz [29:59]: Yeah, so you have more skills in-house. You don’t need to rely that much on external teams.

Robert [30:04]: And it’s also nice because if you are working in a startup, you can just deliver more things because sometimes you may have some small front-end functionality or maybe some simple data science work and you don’t need to outsource it to other team, wait ages for somebody that will do that. You can just do it yourself. I think it’s great. And this is, for example, what we are doing in Trios Labs. So we are kind of lucky that we did many areas so we can basically work to people and we can do a lot of stuff because we can have some experience so we are not front-end experts we are not data engineering experts but we know the field enough that we can do it in the level that is and.

Miłosz [30:48]: Just use it to beat something end to end so we are not stuck or leverage some tools to help you do it. Because if you would need to hire someone to do it for you, that would be super expensive.

Robert [31:05]: Expensive and the overhead is also pretty big, because if you’re doing something alone, you can just do it, ship it, and it’s working. But if you are outsourcing it to somebody, it’s probably 10 times more expensive in terms of time.

Miłosz [31:20]: And the communication overhead is not that it’s an issue to talk with people, but there’s always this scoping and discussions and agreeing on things, so this will take ages.

Robert [31:36]: It’s not only for indie companies like ours, it’s even for bigger companies where you have teams and requiring something from other teams is just not the most efficient way. And there is a follow-up question for this question. If it’s worth to invest in some older technologies like Laravel or PHP. And I think it’s maybe also an interesting way actually to do some switch because obviously working with older technologies, okay, it’s maybe not the most interesting thing in the world. But from the other side, the upside is that less people are keen to work with that. So basically, the competition is…

Miłosz [32:22]: And there is Legasse to be worked on.

Robert [32:24]: Yeah, and you can actually learn a lot on the Legasse. Usually, I remember when I learned a lot, it was the hardest projects. The projects that are greenfield and everything is great, you will not learn that much during that.

Miłosz [32:37]: I would probably consider if the language is growing or declining rapidly. I guess if you consider Java let’s say or maybe PHP too there’s many many projects building those languages. They probably don’t grow rapidly right now. I didn’t check the indexes but I just guess. It might still make sense to go get into them because there will be lots of work in a way. But if you compare it to something that’s declining by, I don’t know, Peril? Maybe Ruby? Yeah, so that’s something that you need to watch out for probably. Not to spend too much time learning something that will be obsolete.

Robert [33:28]: Yeah, yeah.

Miłosz [33:29]: But if you are just getting into tech and you learn one language well, it will be worth it probably anyway, because then you can pick up the next one much easier.

Robert [33:39]: To switch between programming languages than between titles, basically. And yeah, probably one more dimension there, so local market. So if you’re looking for hybrid or on-site, it’s also specific.

Miłosz [34:07]: Job market in general. Check what the market looks like, which is also not ideal, because it can change in a few years, but probably not that fast. So we should be safe at least for five years or so. For example, with Go it was a bit risky when we started working on it full-time because there weren’t that many jobs, but also it was we learned quickly, so it wasn’t a huge investment.

Robert [34:41]: And the competition, if some companies started to ask about Go wasn’t that big.

Miłosz [34:47]: Oh, yeah.

Robert [34:48]: As we said, so we’re later looking for people keen to switch to Go because there were no Go people in the market.

Miłosz [34:56]: Right, yeah, and that’s also interesting. Sometimes, you know, in a situation like there’s a niche language which some companies use and they are desperate to hire, and there are a few developers who are also desperate to be hired because they want to learn in this technology. But they don’t always match each other, depending on the location and so on. So, one more thought. Maybe it’s easier to stick to the proven but old technology than learning something fresh. You know, something that’s not stable yet. Because it might never get traction.

Miłosz [35:41]: I think maybe Elixir is one example. I’m not sure how the job market looks like for it, but I remember learning it around the time I learned Go and And I think betting on Go was probably a more pragmatic choice.

Robert [35:57]: Yeah, definitely.

Miłosz [35:58]: I think by now, Go is much more popular.

Robert [36:02]: Yeah, I remember that a long, long time ago, also, it started to be some Scala hype. And I guess that you can still have some Scala job.

Miłosz [36:12]: But… Probably Kotlin killed it a bit, right?

Robert [36:17]: It’s a bit different, but it also had some specific use cases. But I think the entry point also wasn’t the best thing. But at some point, it was trying to get some traction. People went into that, but I would say that, okay, maybe in some areas it’s still there, but it’s not longer hot.

Miłosz [36:38]: So you have those early adopters, companies who jump on it and hire people, but there’s not enough of them. Over time, we just kind of die down.

Robert [36:52]: It’s just a reminder about the thing that we are advocating all the time. Don’t focus on learning specific technologies. Obviously, you should have some baseline, but we covered it more in an episode about efficient learning. If you focus on the things that are language agnostic and timeless, it will work for you for much longer. Because if you focus on learning some frameworks, languages, obviously you need to have some base, but it’s not the most important thing. And this was also the key when we were looking for people to our Go teams, that we’ve been not asking about how to implement something in Go, because we just know that it doesn’t matter that much. What mattered for us was how they are solving problems.

Miłosz [37:42]: How they

Robert [37:43]: Can for example get some requirements and stuff like that and some general.

Miłosz [37:50]: Stuff Firmina shared in the chat that Java killed Kotlin oh yeah I don’t know so I will trust you’re right long late leave Java I agree and Firmina also asks if one year and a half is enough time to let it go So, I think day and a half is good enough.

Robert [38:17]: One evening I think it’s enough.

Miłosz [38:19]: Yeah, it’s ideal. What’s the next question?

Robert [38:27]: The next question is about clean architecture. You would like to take that.

Miłosz [38:35]: Okay, so this is about where to define the data interfaces. Should you define it in a data layer or in the implementations? And this actually is something that where the language matters. At least if you compare Go to, let’s say, Java. And one cool feature of Go is implicit interfaces.

Robert [39:03]: In other words, duck typing. So, if it’s ducks, it’s a duck.

Miłosz [39:13]: In Java, in many other languages, you have to explicitly say this class implements this interface. In Go, we don’t need to do it. And it has this nice advantage that but you can keep the interfaces close to where you use them, so probably near the… not near the implementation of the interface, but near the thing that uses it. Usually the application layer or use cases or whatever you want to call it. Some people don’t like that, but I think it’s quite cool. you just need a good IDE to show you what implements an interface. That’s a bit hard. If you are a diehard emacs fan, that might be a problem. Or maybe you need some plugins to navigate. But other than that, it’s quite easier to keep the interface close to where it is injected. or used. And this solves this issue of a separate layer for the interfaces, like ports and adapters, where you need to keep them in one place. In Go, you don’t need this layer at all. It’s much simpler.

Robert [40:41]: And I think it’s one big advantage of this duck typing and this non-explicit implementation, is that it’s much easier to implement interface segregation principles. Basically, you no longer need to have interfaces that have 30 methods, for example, for some big repository. Because instead, you can just have multiple interfaces with the methods that you need in this use case. And you can inject this repository with multiple methods there. But you are making the contract of the interface much smaller. Because you are just defining which methods are required. And it’s useful for refactoring, because sometimes you have a repository with that many methods, you can just cut it to multiple repositories and just inject it a bit differently. And it’s nice. And it’s also nice for testing, because when you’re also writing tests, when you have some stubs or mocks, you can just stub or mock smaller interfaces.

Miłosz [41:40]: Yeah, that’s also great. Small interfaces and close to where they are used. That’s the idea of scenario. We covered this in more detail in the episode on Aclia Architecture. If you want to check it out, it’s the third one,

Robert [42:01]: I think. And just a reminder, so if you have some other questions, listen on the chat, so we’ll also cover it. Like, what’s the joke? Okay, so let’s maybe take a question from the chat. if MocnyŻuk asked the question. So how do you handle timeouts in distributed system in sync communication, HTTP, GRPC? So probably it can be answered from multiple levels, let’s say. But in general… How it should be handled. So I guess the question might be, okay, if it’s about distributed systems, I guess it may be about some chain of calls. So one service is called by something and it’s calling other services. So in Go, for example, it’s handled out of the box with context. So when you have the client that is calling your server and the connection is closed, so it’s propagated basically through context and it should be propagated to HTTP Hender. It should be propagated to other requests that are going further. And if you are passing context, for example, to your database queries, it should be also cancelled and it’s doing some kind of chain of cancellation and at the end the connection is closed and everything is great.

Miłosz [43:22]: What about more like a high-level approach? How do you define timeouts? Let’s say you have a service that calls another service. Do you set a constant timeout for it?

Robert [43:36]: So usually i would say that at the beginning you have some endpoints from your message handler and usually it’s good to have some default timeouts let’s say like 30 seconds let’s say for http request and the idea is pretty simple pretty similar because you have this context cancellation that is propagated to everything else basically yeah.

Miłosz [43:59]: I would keep it very very short or sync communication, especially for internal services. Because for external ones, external APIs, you sometimes can’t control it. And then I would consider hiding it behind a message. Basically publishing a message, and then this message triggers this endpoint, and if it times out, it will just be destroyed eventually. If it’s internal, I would keep it super short. Because long requests are usually a pain to handle.

Robert [44:38]: But it’s important to not forget… So if you are talking exactly about Go here, so passing context, because sometimes I notice this problem that somewhere this context wasn’t passed, and context background was passed, and it may be problematic when you are doing some I.O. Call, like if it’s HTTP or some database call, it can run for much longer than you would.

Miłosz [45:05]: Like to run.

Robert [45:06]: And even if you have middleware with the timeout, it doesn’t matter because it’s not propagated and it will run, maybe not forever, but for pretty long.

Miłosz [45:20]: Yeah. And working with timeouts, there’s one more difficulty. If you have a chain of services that call each other and they are slow, and then the timeout happens on the end, don’t really know what happened in the system, the last one. Maybe it was just network failure or whatever.

Robert [45:43]: Especially you don’t have transactions. Because if you have transactions, if you have transactions, again, we are talking about Go, but context cancellation should cancel that and it should roll back things. Yeah.

Miłosz [45:55]: So it’s often where people will consider using a distributed transaction, maybe.

Robert [46:03]: Or at least some message in the middle, maybe event or command.

Miłosz [46:08]: Yeah, so there’s something to watch out for. Ideally, those endpoints will be idempotent.

Robert [46:14]: You should try it.

Miłosz [46:16]: If it happens.

Robert [46:17]: Or ideally, the operations will be fast, and the things that you’re doing synchronously, maybe it can add something to the queue, and it’s just responding pretty quickly, and everything else is done in the background and maybe you can.

Miłosz [46:32]: Okay, I do have a follow-up. Let me read it. I have a scenario where a given call is propagated for various services via REST API. Therefore, you need to set up smaller and smaller timeouts the deeper you go in the tree of services. Oh yeah, okay, I see your point. So you have a long chain of services that call each other. And I don’t like the approach to use increasing timeouts from top to bottom. That’s why this question originated. How it should be handled? Right, so you have this chain. The first service needs to be aware. There will be lots of calls.

Robert [47:17]: So I assume that if you are mentioning that it’s not like the entire chain is executed within one second, something tells me that it’s taking a couple seconds or up to 30 seconds, for example.

Miłosz [47:30]: Yeah, maybe minutes.

Robert [47:32]: So, I don’t know. So it’s hard to say without seeing the system, but it’s maybe a case for some more asynchronous communication, for example.

Miłosz [47:43]: I would consider it,

Robert [47:44]: Yeah. Yeah, because in this case, you may have a problem of cascading failures as well. Or also other solution that I know that for other people is crazy. Maybe we don’t need as many microservices. It depends, because I don’t know this case. maybe every team has its own service and its multiple teams and its very big product. That’s fine in this case. But if it’s, I don’t know, one team has 20 services, maybe it doesn’t need to be 20 services. Again, it’s hard to say. I’m more saying, more mentioning, more alternative, let’s say, to consider that, but…

Miłosz [48:28]: But in general, if you have this spider web of service communication, I would probably try some asynchronous approach, because there are many issues there. For example, each service needs to react to some error. I’m not sure if this is like one service calling 10 or 10 in a sequence, but any time any failure happens, maybe it’s timeout, maybe it’s a network issue or some domain error. It needs to handle it and it propagates it up the stack and then the next service also needs to handle this somehow.

Robert [49:06]: And if every service in the chain is storing something in the database, I hope in transaction, but from my experience, something tells me that it may be not always the case.

Miłosz [49:17]: It’s more risky. But the transaction spans only one service anyway, so I would consider doing it with a message. Publishing a message with the first service, and then all the others reacting to it somehow.

Robert [49:32]: So, start with the question. Do you need that many microservices, PCS.

Miłosz [49:37]: Might be too late for that.

Robert [49:40]: Yeah, okay. That’s true also.

Miłosz [49:42]: But the interesting approach has the downside that you don’t get the error right away. I mean, you don’t know the result of the other services, what they execute.

Robert [49:56]: Also, one more alternative, because, maybe it’s also not that big issue, and maybe you can increase this timeout a bit more.

Miłosz [50:09]: Yeah, it’s not stuck out the most naive.

Robert [50:12]: Yeah, I mean, it’s a naive option, but we also know how it looks like. In perfect world, it would be good to join microservices, use asynchronous architecture for the places where we need but sometimes it’s not important enough and we don’t have enough time yeah.

Miłosz [50:32]: Depends how many activities are on there because if you add a new service to the chain every week, it will get much worse with times but if it’s something you don’t need to touch over the year whatever, we can just bomb the time out So,

Robert [50:52]: I hope it didn’t help. But yeah, jokes aside, so, well, favorite face. So, it depends, but…

Miłosz [51:03]: Yeah, I would consider if async approach can work here. That could simplify it.

Robert [51:08]: Even simple ones. So, also, the thing that we are often advocating for is, even if you don’t have any message broker, you have Postgres. You can have a very simple message broker on Postgres and it will be also fine for the beginning.

Miłosz [51:22]: I love how helpful we are that someone asks about sync communication specifically and our answer is to use async.

Robert [51:32]: Yeah, but this is the case of end with.

Miłosz [51:37]: Yeah, but other than that, there’s not really much you can do. You can bump the timeouts, sell it everywhere to high value and live with it maybe it’s not an issue or redesign the system work in a different way So, some frontline service that would send an event and then waits for the finished event. If you wait for a finished event, it’s kind of like a timeout. You just do it over messages.

Robert [52:16]: So, it depends if you’d like to wait for this event in context of request. So, basically, usually you do it in the way that you’re sending some event, and the request is finished.

Miłosz [52:32]: And you can, for example, have a status in the database that each service writes to. And then you can display it on some kind of UI.

Robert [52:41]: But, again, it’s not for free.

Miłosz [52:44]: It really depends on the use case.

Robert [52:46]: On the complexity of the system, how big is the team…

Miłosz [52:50]: If you want to share more about the exact use case you have, You can join our Discord and we can help you figure it out more in detail because it’s hard to…

Robert [53:00]: Yeah, I think the size of the team, the scale, it’s important here, because I think the answer depends on this context a lot, basically.

Miłosz [53:13]: Hello, full dump. Nice to see you. Thanks for joining us. And drop your questions if you have any. Okay, should we move on to the next question, is also about Clean Architecture, I think?

Robert [53:31]: Yep, that’s true. So, my team started using Clean Architecture about a month ago, and it has been quite a learning experience. But overall, we are seeing the benefits as we wrap our heads around it. One thing we got stuck on sometimes is when to determine the boundary between application and domain layers. This is the question that we all usually have. Or question, what is domain logic? This is also a pretty interesting one. So we’re using SQLRS in application layers. Sometimes the handlers are so simple for crowd operation that we don’t have any dependency on the domain layer. Other may be than entities. We have other handlers that do a lot more and that’s ended up with calling domain-specific logic. Is it common? So to recap, I think it’s about if we need to have domain logic basically in our applications or we can simplify that because it’s just some simple crud and it doesn’t make sense to do some domain magic there.

Miłosz [54:41]: Yeah, I remember the long discussions about this we used to have.

Robert [54:46]: What is domain logic?

Miłosz [54:47]: Yeah, what is application logic? So, maybe we can start with that you don’t need a domain logic in every service you have.

Robert [55:01]: Even if you have domain logic, because you can probably say domain logic about many things, like you’re doing if in SQL query, it’s domain logic.

Miłosz [55:10]: Yeah, so how I like to think about it is like, instead of four layers or whatever you might have, just think about it as a split between implementation details and the logic. That’s a very basic split. You want this domain code or business code away from the SQL queries. And then, if you find it useful, you can split this logic into pure domain logic and all the other orchestration, application things that join things together. And it’s not like a huge deal, but sometimes they work with very complex domains, where this domain layer will be huge, because the business rules are huge basically. And you need to model what your software does. And there’s no other way than writing it down in the code. So it helps to have a separate layer that’s not polluted by any database, calls, or whatever it’s just pure functions and structs and lots of tests for it yeah,

Robert [56:27]: And I think for what we advocate here is trying to be mindful about that and asking yourself a question whatever I’m doing, is it helping me or not? For example, okay, I’m not using domain layer I have a lot of logic in my application layer okay, maybe it’s not helpful maybe I should have domain layer or maybe the opposite side for example, I have domain layer with encapsulation and a lot of stupid mapping for CRUD so I’m just mapping fields between layers and not doing anything for that I don’t have tests for that and I see that it’s not giving me any value okay, it should be not there and it’s not easy to give a good answer if you should have a domain layer or not. You need to learn that. Oh, by doing. And I don’t have a better answer than just writing this kind of logic and over. And yeah, you will have some puzzle.

Miłosz [57:24]: This is the hard part that you can’t really define that. And I remember having the same issue because we have some meeting where we agree, okay, guys, this is application, domain logic, blah, blah, blah. We set this you know the system in place so everyone knows and then you have this edge case like when you for example like this person said they do just crud and then you start to wonder you know should it be there should it be there mm-hmm It’s hard to give one answer to this, but most of the time it also doesn’t really matter that much.

Robert [58:01]: Just try and be mindful. I know it’s not easy, and I think it’s also not easy with Skunko’s fallacy, because if you already spent a lot of time to build your beautiful domain, layer, and at the end you see that it’s just useless, it’s a bit hard to delete that, I know.

Miłosz [58:21]: So if you could define very strict rules for your application, we wouldn’t need probably admin developers because we would just wipe code or we would just use those builders for software.

Robert [58:40]: Or you will use spreadsheets. So I think it’s interesting, heuristic, or kind of. Like, if you’re building a crowd application and you’re feeling that this is enough, maybe you don’t need an application for that, maybe just something can do a super big spreadsheet doing that. Okay, it’s maybe not most optimal, but sometimes it’s more than enough for the beginning, especially if you’re working in a startup, because you might not know if it will be useful or it will be trolled away. and, you know, the spreadsheet for the beginning. Right, fine.

Miłosz [59:16]: I think when you said that in the beginning, it was important to you. Just think of what you get. If you are just starting out, do you need this full design of all the layers and splitting? Probably not, because you don’t really know what will be there. But if you have application layer and so handler, and you find 500 lines of code there with 50 ifs and lots of conditions, lots of arguments and so on. Then it kind of feels natural to just extract this thing somewhere else. It can be another function, another struct, or if you have many places like this, just do a separate layer of it. And that’s basically the idea.

Robert [1:00:03]: The downside is that often we don’t have enough time to do that, so the pain is starting to be bigger and bigger and bigger. But the more complex it is, the harder it’s refactor that. But from the other side, I think it’s also nice, because if something is bad enough, it’s easier to propose changes.

Miłosz [1:00:22]: You feel the pain, so you know it will help to change it.

Robert [1:00:25]: For example, Mocnej Zhuk asked about these timeouts. I’m guessing, but it may be two scenarios here. That those timeouts aren’t painful and it may be worth investing in migrating, for example, to event-driven architecture, but maybe it’s not painful enough and just increasing timeout, it will be good enough and, okay, we have some bigger problems. And the same is with refactoring. So, for example, if your model in the application layer is complex enough and it’s slowing down your implementation a lot, you might have time to actually refactor that. And obviously, it would be great to be right at the beginning and start with domain logic and have tests from the day zero, but also let’s be realistic that you may be wrong with your assumptions, that you may assume that, okay, it will be crud, but at the end, the complexity will explode. It happens. It happens even for us when you are working up. But the reason for that is not that it’s sometimes some lack of skill, but it’s often lack of understanding. That if you are starting to work on something you may not have full understanding of the problem space and you will discover it during implementation and there’s just no way that you guess that okay maybe you will have luck and you will.

Robert [1:01:51]: Implementing in a domain logic. But you may have a bit less luck and you assume, okay, it’s simple, complex, it will explode. And even if you do your best to guess it should have domain layer or not.

Miłosz [1:02:07]: You will be not always right. Next month, your boss can come in and say, actually, you know, we decided not to do this.

Robert [1:02:15]: Or we signed a customer that needs this, this and this.

Miłosz [1:02:18]: Yeah, can I just revert what you did last month? Because we need to change the domain model. And it’s actually fine, you know, when this happens. So your domain model is never ready. You need to adjust it over time.

Robert [1:02:34]: So yeah, TLDR is totally fine to not have domain layer, just put everything to the application layer.

Miłosz [1:02:41]: I use some of it and some DOM.

Robert [1:02:43]: Exactly, exactly. And what’s even better, and it’s not like if it’s good or not, but it’s, I would say, necessary for applications to have modules that have domain layer and have modules that doesn’t have domain layer. And it depends a lot on the application, but usually this is a good idea, because trying to keep consistency for everything, it’s usually a bad idea. Because usually you have these modules that, even if you have very complex applications, not everything is critical.

Miłosz [1:03:13]: Although it will be much simpler to have one standard for everything.

Robert [1:03:18]: Yeah, but it will be just very expensive compared to how much you will gain from that.

Miłosz [1:03:28]: So I really like this idea of fixing something once you feel the pain. If something is not painful maybe it’s fine even if it’s not the best maybe it could be refactored maybe it could be split to modules or whatever but if it’s not painful you probably have more stuff in the backlog to take care of and

Robert [1:03:54]: You will never finish.

Miłosz [1:03:55]: Everything yeah, you will just keep growing it that’s normal, that happens in every company every project Oh, I think we can answer this one.

Robert [1:04:09]: But we have another one about clean architecture. Oh, okay. So, what about clean architecture and small teams with complex projects? So it’s a question about the episode that we had. So the most popular thing that we have. So 10k views on just YouTube. So yeah, this is probably why it generated…

Miłosz [1:04:32]: So there we mentioned that architecture shines for bigger teams and complex projects. So if you have a smaller team or a simpler project, better to avoid it. The question is, what about small team and complex projects? Yes.

Robert [1:04:51]: Yeah.

Miłosz [1:04:54]: Yeah.

Robert [1:04:55]: So it makes sense. So we are a two-people team, and even if we are a quite small team, we are using some lightweight implementation of Clean Clean Architecture, because if you were already doing that, it doesn’t add that much overhead, and you are doing it properly, and it can basically help in many, cases, even if you’re a small team. Again, the cost is not very big if you’re already proficient with doing that, and you can just have benefits out of that. It’s also some natural way of doing things, but again, it’s about doing it in a lightweight way.

Miłosz [1:05:40]: I even do it for my own projects, very small ones, because it comes kind of natural. But yeah, the key point here is to do it in a very lightweight way. For example, not inject everything from an interface like we often see in Dan. That can be crazy.

Robert [1:06:02]: Also, the thing that we mentioned in the previous question, you don’t need to have domain layer with the clean architecture. It’s not a must.

Miłosz [1:06:10]: You don’t even need application layer if you don’t know.

Robert [1:06:13]: And probably you shouldn’t have more than four layers, because we’ve seen the comments on Redis that do.

Miłosz [1:06:19]: You remember how it was? Yeah, it was like Clean architecture is over-engineering. You shouldn’t have more than four layers in your project. We’re just free. I don’t know what some people do, but it sounds like over-engineering then, for sure. If you manage to keep it simple, you can do it for small projects, for sure. For small teams, complex projects. Sure. Why not? I’ll just watch out for making it overcomplicated for no reason. Once again, this question of why it helps can be helpful. I want to understand why you do it, not just do it because someone says, this is a nice idea. So for example, do you run integration or component tests? If you do, the bendless injection is what you need basically to do it in the same way. If maybe you don’t want component tests at all, maybe then you don’t need the prevention injection at all. Let’s try to understand if it makes sense or not.

Robert [1:07:32]: And it was an interesting follow-up question and all that. So if it’s something like under-engineering, not spending any time on architecture at all.

Miłosz [1:07:47]: Yeah my favorite quote here is that there is no there’s no such thing as no design there’s only bad design that seems similar I just don’t spend any time on proper design or any kind of architecture, you’ll end up with this big ball of mud. And sometimes it’s fine if it’s some project you do over the weekend and we’ll scrape or your vibe code.

Robert [1:08:19]: Or it’s proof of concept that you will hopefully throw away after proving if it works.

Miłosz [1:08:27]: But yeah, keep in mind it will happen. So is it what you want? If you want to maintain this thing over time, maybe just spend some time, a few hours to draw some diagrams, try to sort it out in your head how it should look like.

Robert [1:08:45]: And I think it’s one interesting thing that we covered a lot in the… One interesting thing and side effect of this node design that we covered a lot in the previous episode, how it affects code review. So if you didn’t make any design in your team, so The code review, so the PR that you may submit, may, let’s say, surprise some people. And surprising PRs are usually not best because it will trigger a lot of discussions, that resolving will take ages, that fixing will take ages, and probably it will take more time that you will spend on design. And I know nobody likes meetings, but I think I like having big PRs that are discussed for ages less than meetings. And I like the sentence that five days of coding can save one day of planning. And it’s often the case. and even if it’s not visible on the first site.

Robert [1:10:01]: It’s often visible during review that is going for ages. And later people are blaming that code review is awful because you have a lot of the comments, you need to resolve that. Let’s just push everything to main. But it’s not a problem of code review. It’s a problem of surprising people. And don’t surprise people with your code review.

Miłosz [1:10:24]: Architecture sounds like something complex that architects do. But it’s basically stuff like if you have 10 services connected with synchronous calls, what happens with timeouts? That’s basically it. Try to think about it, what will happen, how to handle this and then prepare for it somehow or either fix it or just agree it’s fine and note it, document it somehow.

Robert [1:10:55]: Or a different thing that I also remember that we faced one time is not thinking really how teams are split so let’s imagine that you have some process, and let’s imagine that the beginning of the process is handled by team a later team b is doing something the process later team a is doing something again and later some team c, yeah yeah yeah and it’s pretty problematic because nobody can really own some big chunk of the process because it’s really chopped for small parts that are between teams and it’s, hard to do some kind of handover of big.

Robert [1:11:42]: Let’s say, events in this process. And again, it’s a matter of a bit of design and thinking actually how the process looks on the high level. And obviously, it can be fixed later, but it’s also problematic because often it means that, okay, if this part of the process is handled by this team and it’s between parts that are owned by this team A, maybe this part of the process that is in the middle should be also owned by team A. And, okay, it can be done, the service can be migrated to other teams, but it’s expensive, because it was written by other teams. Probably it will be harder to maintain, because you have no idea how it works. Maybe this team will be also not happy about that, because they will say, I already have 50 services to maintain, we don’t have capacity for that. and yeah it’s like.

Miłosz [1:12:39]: A very high level architecture like an organizational there’s this team topologist book that talks about this I think it’s quite nice if someone wants more on this topic you can check it out

Robert [1:12:52]: And we also mentioned in some previous question that even if you are not manager if you are not architect it’s nice to have this knowledge from other areas for example like team topologist that is, a bit higher level, but from the other side, you can also propose better things and be promoted much faster, because very often those people that are on higher, levels, they may not know that.

Miłosz [1:13:20]: Yeah, that’s true. We can help them fix things, which can also help you in your career. Yeah, so it’s nice to have those more orthogonal knowledge. That’s pure development. That’s a good example of this, too.

Robert [1:13:39]: Yeah, and this is the thing, that if you are going to more senior roles, you’ll notice that, okay, writing software is important, but there are many things around that. And to really be beyond this senior level, you need to understand much more things and also go beyond technical things, basically.

Miłosz [1:14:01]: Yeah, and AI just confirms it. Writing code is cheap somehow I don’t hear many great stories about you know generated codes we are not probably doing much more meaningful work thanks to it to figure out anyway what you need to do in the first place and I think it’s

Robert [1:14:26]: The thing that people that are most senior can get more out of that basically.

Miłosz [1:14:34]: Yeah, exactly. So you get boring parts away, but you still need to figure it out on a high level and design it properly.

Robert [1:14:45]: Alright, cool. So I think we are shortly going out of questions, as long as you not put something in the chat. Or as long as you don’t have something to add about previous questions that came into your mind.

Miłosz [1:15:04]: So not as long in the chat if you have any more questions.

Robert [1:15:08]: Last chance before our holiday season.

Miłosz [1:15:12]: Yeah. So we can share a bit more about our future plans.

Robert [1:15:17]: Yeah, so short term, resting a bit. So I think we had a super busy time now with Go Event Driven V2. So about doing the big update, also giving you support.

Robert [1:15:33]: Any horror stories?

Miłosz [1:15:39]: We need a separate episode about startup horror stories. Oh, yeah. But I also want people to share theirs because I love reading this.

Robert [1:15:50]: One of my favorite ones is about sending a couple million SMSs to one person within one minute. Remember, add some trodling.

Miłosz [1:16:04]: Thanks for the suggestion for me I think we need a separate episode about this and I hope to hear people’s stories as well

Robert [1:16:16]: So after resting what are, our next plans I think we can officially confirm that we know what will be our next training that a lot of people were asking about. So do you want to share these news?

Miłosz [1:16:34]: Yeah, so we plan to release our next training, which will be the Domain Driven Design in Go. And there will be also a hands-on training like Go Event Driven and Go in one evening. Let’s focus on Domain Driven Design. Or I would

Robert [1:16:51]: Even say that obviously Domain Driven Design, it’s some way how to go there, but from the high level it’s more about how to build application with complex domain logic. So many questions you heard about this complex domain logic is for a good reason, because applications that are successful often have these parts that are very complex and require a bit more love than the crowd applications. And those are usually the unique part applications that are making money for the company. And the interesting thing is that, companies are kind of happy to hire people that can work with that because, one thing is that they need to usually touch this code update this code to make more money but from other side it’s also hard to find people that they can do that because it requires a bit different skill set to do that and and.

Miłosz [1:17:50]: Often people are like i am just the developer give me give me the requirements and i will transfer them into code so yeah that’s not really helpful for most companies, because they need people who can understand the business domain, can help people figure out what the product needs. Basically, product engineering. So this training is about that.

Robert [1:18:14]: We’re pretty lucky that we had a chance to work with some pretty weird domains that well, people try to use CRUD approaches sometimes there and it was actually quite interesting to see how this trying of simple approaches totally failed.

Miłosz [1:18:33]: Or maybe they thought they are using DDD, but DDD was their own idea which also didn’t end up well.

Robert [1:18:41]: Yeah.

Miłosz [1:18:42]: Yeah, so we this would be also hands-on training, like the previous ones. We learned a lot from people’s feedback. We had over thousand trainees in both trainings.

Robert [1:18:58]: Over 2000. I think two and a half thousand people.

Miłosz [1:19:04]: So we received lots of feedback. We had some things we wanted to improve. That’s why we prepared the second edition of Go Event Driven. That should be much more fun to go through and easier in general. So we want to take those learnings to the next training as well. Make it more focused on what’s the most important and focus on real life scenarios

Robert [1:19:34]: If you don’t like coding, sorry, it’s very hands-on.

Miłosz [1:19:40]: You need to code. There’s no videos to watch.

Robert [1:19:43]: And yeah, I think that this is a pretty common thing. You need to learn by practice, when to go simple way and where to go complex way. This is actually what was helpful for us. just working with many projects in a daily job, after work, and trying to get this muscle memory to have some idea what approach to use there. And this is why we are advocates of hands-on, because this is the only way actually how you can gain this skill. And you can get in work in the projects and do some crazy over-engineering stuff at the end, or maybe it’s a bit better to learn it in a controlled environment.

Miłosz [1:20:33]: So you don’t need to confess to your manager why you need two months of rework and refactoring. So you can experiment on your own project or our guidance. So this will be in Go, initially, but we probably will have more languages later, but that’s probably not the start. Just as with the other training, we will have a pre-sale, which will give the best price. So basically we want to check if there’s enough interest before we start working on it. And of course you can ask for refund and so on. That’s the same rules as we did in

Robert [1:21:19]: September so for now a bit uh a bit of rest a bit of thinking what we’ll do uh in quarter.

Miłosz [1:21:27]: And also there’s also one thing we want to complete which is go with the domain ebook so we have some cool ideas about to release the second edition or the 1.0 maybe edition is a better name

Robert [1:21:43]: Yeah because there are still some chapters that were not finished.

Miłosz [1:21:47]: That’s long overdue for a few years, so finally you should have some time to do it.

Robert [1:21:53]: But you know, probably it’s also good to share that if you have projects in your work that are taking more time than your thoughts, you’re not the owner. We also have this problem, but for a good reason often. And yeah, as we said, in September we’ll also do some updates of the NoSilverBullets form. It’s a bit secret, so you’ll see on September, but I think it will be quite cool. That’s it, I think.

Miłosz [1:22:33]: I have no more questions.

Miłosz [1:22:36]: Firmina is laughing at us, so that’s time to wrap up.

Robert [1:22:42]: Yeah so thanks for being with us and see you in two months yeah thank.

Miłosz [1:22:47]: You everyone for joining us next time

Robert [1:22:50]: See you next time ciao.