Hi everyone, my name is Patrick Aku and today's episode is all about becoming a better software engineer and it turns out that non-technical topics are more important than technical ones. Joining me today is Farjat Dovari, software engineer and a strong believer in collaborative software design, simplicity and autonomy. It doesn't matter if you're early in career or a seasoned software engineer, this episode is for you, so enjoy. I think the best way to learn
anything is to build something. Yeah. And especially if it's technical. And similarly when when it comes to skills also, the best way to learn is to put yourself in a situation where you have to use those skills and try different things, fail and see what works and what doesn't. So yeah, that's what I always do. I I fully agree with you with
that. Like a clear goal, especially from a learning aspect is really going to help drive and move you forward to it. I mean, those goals have always come kind of professionally because on a, on a personal level, like, man, I do technical stuff professionally. Do I want to do that on a personal level? I usually go wide and I have other hobbies than more
technical things. But I really admire people that like senior language want to play around with, they have a really good use case and execute on that. Yeah, that's really cool. Yeah, yeah. Well, do you remember Stack Overflow like when, when it was not like on decline because of the eye? No, I don't know if it's really on decline, but I think there I saw like some report that shows me too, things are not very
well. But back then what was super interesting was that there was a community that was focusing on teaching people or consulting people in identifying the problem and solving that. And language didn't matter. Like, if you looked at the contributions of top users of Stack Overflow, you would see that they answer questions from a wide range of, I don't know, tags and technologies.
But they always had this approach that they like communicated back and forth with the person who asked the question to understand why they have this problem and then avoid the XY problem situation. Do you know about XY? No, no. So XY is a situation where someone who's like an expert or not an expert, someone who wants to solve a problem thinks that the solution to their problem is something they go and ask about that a special solution or that special thing that they're stuck on.
And then that leads to waste of time and effort from other people because others help with that particular thing. Whereas this might not be the actual solution to the problem that they had or or this might be the wrong problem to solve. So it's always better to go with the real intention that you have for the requirement that led to a technical solution and maybe someone has a better idea or a better approach.
Yeah. And sometimes like the tools that you're using, for example in the Stack Overflow, and we're talking about, that's a regular expression, is a very popular tag and people try to, for example, parse HTML with that. But this is not built for that, right. So HTML is not a regular language. So a lot of questions are, Yeah. I mean, a lot of answers are like, yeah, just don't use this, yeah. They'll do that do. Something else? Yeah. That's quite funny.
Like most of the questions that like that pop up for me is you're, you're talking to a person that loves go, then XEB. I also give go foundational trainings and recently I I did that at bull.com, for example. And then people ask, OK, what if I want to do XY and Z and go? And then it's like, OK, I can answer that question, but it's more of a question of, OK, do you want that? Why would you want that? And that's usually the the approach I take.
Yeah. And then people are like, huh, yeah, maybe this is not a good use case or maybe I shouldn't do this in the 1st place. Yeah. But then from a curiosity perspective, they're like, but. But still, yeah. Absolutely, yeah. But sometimes also trying dumb ideas or, I don't know, like the the things that you think are not going to work is very rewarding. It is, yeah. Like you do something just to learn what goes wrong and how, how far they can go. Yeah, in terms of being wrong.
So that's also a good way of learning. I think so. I think so too. I mean, for me, I'm always trying to balance technical depth and technical skills versus other skills that I think I need as well. And maybe it's because I'm a specific type of person, but I see a lot of things that are interesting to me. Like curiosity is a big driver. I've done a year of product management and I think that still is fascinating. Yet I still miss the kind of
hands on experience. And I like technical depth, but I don't have that like inkling to do it on a personal level. Like with my personal time, I like facing challenges, not professionally and like solving those goals either by myself or with the team. Usually with the team gives me more fulfillment. So balancing than technical skills as a software engineer versus other skills that I think I need has always been tricky. Yeah, yeah.
Indeed, Yeah, I like that to use the word balance because there needs to be a balance. And I think we had some conversations earlier about like, how do you like balance that technical stuff and non-technical stuff? And yeah, looks like, yeah, a common misconception here is that a lot of people think that building software is mostly about knowing your tech and how to use technologies and how to put things together. But yeah, all other skills like
that are required. If you like, put them on the table, maybe they get a bigger portion of your timer. I don't know, like they might be even more important than the technical things to do something right or to to build something that's useful. Yeah. I I wonder if that's so I think I agree with that. Like if I look at my time spent previously on successfully deploying software to production, whether it be a first release or continuous release or a new added feature.
I don't know if it's the fact that I was in an organization with aligning with people with different kind of goals and agendas and interests. That that's why like the non-technical side or the non-technical skill was not necessarily needed. But more of the aligning people or figuring out what the right value is or what problems to solve. I don't know if it's because of me being part of an organization.
Let's say if you and me do a startup and we have just the two of us, probably we align quite quickly and then we start from from scratch. So the building part of it, more of the technical side is going to be at the forefront, Yeah, I think. Yeah, Yeah, I think so. Yeah. Well, so if when you have a smaller team, of course, the challenge of communication or like splitting the roles is less important because like there are two people, everyone knows that they need to take different
roles. And then you probably have the same mindset or same goals when you want to start a business with somebody else, right? So that's very unlikely that you want something totally different or need to sit like, I don't know. For hours. For hours and then and talk about work. Yeah, yeah. But when when the organization gets bigger, the challenge of people also increases.
So you have to find a common ground with others, make sure that everybody knows where they need to go, make sure that there's safety for everyone to speak up and come up with new ideas. Of course. Right. So and, and make everyone happy so that they don't feel like they, they, I don't know, code monkeys and just executing orders and, and these are all the, the non-technical aspects of building software or building anything. I think so, yeah. It's not very technical, especially at scale.
Yeah, I mean, I was wondering, because we had this conversation before the show and I was wondering why that is the case, right, That there is this notion that grading software is like a super technical job. I mean, I agree to a certain point where the people aspect is huge. I wonder if it grew like that, because right now if you look at knowledge, like a lot of stuff is out there online with AI, we
now have intelligence as well. So when we're trying to figure out something from a learning perspective, information is out there. And maybe 20 years ago it was not as much out there. I mean, definitely so. And it has gradually increased. So getting something up and running was already a skill in and of its own. And now getting something up and running gets easier and easier.
So it's I think more about solving the right problems and finding alignment and then being productive and effective with what you're doing. Yeah, exactly. I think there's a set of problems that require a lot of special specialized knowledge and like a lot of focus on just the technicalities of how things work. Like for example, if you create a database or like the kernel of an operating system. Of course, that's mostly about like the technicalities of how things work.
Even then, you still have to have like a community and a lot of people who want who you would want them to contribute to the project and and all sorts of things. So again, people aspect is there too. But if you're solving business problems, like in a company, of course, it's, it's less about, I don't know, like building
something super technical. And it's more about, like you said, talking to stakeholders, understanding the problem, prioritizing things and, you know, making sure that you're going in the right direction. Like sometimes things are not very clear, but at least you have to take bets and make decisions and then collaboration, of course, like the taking these bets become super important in in this
setup. And, and you do this with all of your yeah, like communication skills mostly and and use less of your coding skills to to move forward in there. Yes. So I think it has to do with scale and the types of problems that you're trying to solve. Yeah. Yeah, I wonder if for someone starting out like they will absolutely likely focus on their technical skills, right, Because usually that's the barrier of entry. Can we execute? Can we see that you learn? Can you think on the fly?
But the communication, yeah, it's going to be huge aspect of that in and of its own already. I'm wondering what your advice is for people that are more so starting out, what would be the the tipping point where indeed they they kind of have hard skills and then they focus more on soft skills. Because I've also seen people where they think they know a lot of hard skills and they focus very much on soft skills. And then they try and leverage because of, for example, product
managers. They might have a certain technical background and they use that to drive decisions forward, but it's not really their responsibility anymore. So like, I feel like that tipped in the wrong skill then with regards to hard skills and kind of the responsibilities they have. Yeah. Yeah, well, there are two, I think you mentioned 2 two things. So 1 is like the separation of responsibilities, which is an interesting topic on its own.
So let's talk about this after the the career path. But if you look at the, the software engineering as a career path, of course, when you're an entry level person joining an organization or a team, the expectation of the organization and, and the expectation of you from yourself should be to just like have like have influence just on yourself. Like learn how to work with the code base and how to do the, the, you know, basic things that they, that are expected from
you. So this is the entry level. Then you grow a little bit like you learn the skills and you manage to have like a balance between, you know, using your technical skills and like talking to different people. And then you become a Meteor engineer. And as a Meteor engineer, well, your area of influence is mostly your team or your peers. And well, the expectation from you is always on that level. So you have to have the, the right skills to be able to communicate with the people that
you often work with. And after working with people, of course, you get a feel for how things work and you know who you should listen to. You're probably have some other senior people in the team who make some tough decisions and what not. And then you become even more senior. And then there you have have to have more influence. So the, the the more you move forward in your career. Of course, you have to find ways to communicate with a broader set of audience and and talk to
more people. And then your communication skills need to be stronger and stronger. And then you probably even won't have enough time to use your technical skills as much as you had like when you were a mid level or an entry level civil engineer. And that's why a lot of, I don't know, architects or you know, people who have to talk with many, many, many different teams
And people don't write code. And like, for example, a product person, of course a product person needs to talk with a lot of stakeholders and do a lot of coordinations and make decisions and whatnot. So even if that person has technical skills, probably they can contribute, but maybe it's not their job to do that anymore because they're more interesting things for them to do. I've thought about it like,
because that's the part I miss. And then indeed, what you mentioned really really was also my head. Like there's only one person that does all the other things basically. So my time is better spent doing that rather than scratching this this itch that I have for fulfillment. Yeah, but also I don't like separating concerns or like the the the interpretation of separation of concerns when it comes to some technical stuff.
So for example, they say that well, I want one person to take care of database and for infrastructure and I want one person to take care of, I don't know, something else in technical stuff. And then you create basically silos and communication overhead between those people and also about talking with with the stakeholders. You know, so when when you say that, yeah, an engineer's job is to just like write code and then turn specifications that are pre written into like some solutions.
And then the job of like a person who communicates with the stakeholders is just to talk to them and then write those specifications. I don't think that's a winning combination. So there needs to be some kind of overlap or at least some involvement like across these different aspects for like for something meaningful to happen. Yeah, I fully agree. Like I've been experimenting with that. When we kick off a new milestone that we're going to research and design that I want to involve
everyone. That's what I've done a few times. But then I've noticed that involving everyone, the full engineering team very early on where things are very unclear, their feedback has been or things were very unclear. Yeah. And I'm like, yeah, that like it makes sense. So now I'm experimenting with only involving a few people.
And then when things are more clear, like communicating that more, which would be more like the time spent on communicating, then later on is bigger, but things might be more clear, but then we might not catch everything in advance. So it's it's kind of trade-offs that I'm trying to figure out. I've also like I fully agree with you where we do need feedback from stakeholders fully allow the team. I mean it's not even an allow. They know basically they can
reach out to whomever. But then the opposite, that's where I'm like, OK, sometimes that's not always the best thing where people on stakeholders directly reach out to the team, not just through product person with regards to priorities or when is what done. And then that kind of amps the the stress level of the team so that I'm a bit more cautious of maybe a bit more mindful and, and guarding in I would say.
Yeah. I would say like going through product person is some kind of solution to a problem, right. And if you look at the problem is that there's no structure or no common understanding of how things should work to build a software. And when a stakeholder that has like some kind of urgent need and has no context of everything else that's happening to the team, reaching out to the team. When that happens, of course, things could go wrong, right?
But then this is the problem. And and you could also solve this in in multiple different ways. So for example, if you have some collaborative sessions with those are stakeholders where everyone are there and you do
this like very often. And of course they can still talk, but they also walk out the room very happy because they they Co create with the team and the team kind of understands the perspective of the stakeholder and you kind of like let them in into the process of building the product. So I think this this is a more effective approach than the proxy approach. Of course I know that you didn't
mean the proxy. Yeah. I think a very, very common pitfall I see in many teams is that of course, because they want to be very protective of the priorities, they put proxies. Yeah. And then that's also like a roots, too many problems. I think that's what I did early on, like because product management was new to me. I was like, well, it makes sense that things go through me. Like that's what I've seen from the software engineering hat,
let's say. But then I realized that I'm, I'm a bottleneck, like, and if I'm not available, things either come to a standstill. People don't know what to do. So then opening up those communication lines has been
really helpful. Yeah, indeed, Co creating also, I mean we haven't had any Co creating sessions, but complete transparency with regards to demos, what we're doing, what we are going to do, what works well, what doesn't work well, our learnings as well from retros, that's all been shared. So that really helps. Yeah, I think get a common understanding of what, what goes on. Yeah. And the heft of my time has been educating other people how to create a software.
Basically, yeah. Yeah, exactly. When, when there's a road map and we have a million items running in parallel and everything is high, the priority, I'm like, this is not how reality is. Basically, we have to scratch that, wipe it off the table, and people get really scared. Yeah, yeah, yeah, yeah. But then we have a better way of working, although some people are happy because we deliver. Yeah. What is promised? Exactly. And that's like how the team grows, right And stakeholders
can grow with you as well. Like they they learn how to think along with you and everything will become better as as you do it more I think. Yeah. But for me, the the funny part is so I can leverage the technical experience to kind of go against certain processes that have been put in place or certain status quos because I have a vision of because this is what I believe in. If someone doesn't agree, we have a conversation basically.
And I'm not black and white, like I am quite flexible with regards to my thinking, but I also believe it's something. So that's what I stand for, and that's what I'll fight for. Yeah. For people that come into positions and they might not have the right background, I do see a lot of people kind of going with the flow, following status quo. Why are we doing this? Well, that's what I got taught, or that's something that we've
always done. And that's where I'm like, yeah, we don't really improve or we don't really innovate. Yeah. And sometimes I think that's a shame. Yeah, I think the worst thing that you could do to yourself or the environment that you operate in is to just like follow. And yeah, following is good. Of course, if you want to change anything or if you want to challenge the status quo, it's probably best to like, yeah, walk a mile in other people's shoes and then start to talk
about, yeah, of course. Like at some point you have to be a little bit critical and then use your critical thinking skills to come up with some improvements for yourself or your environment for the product that you're working on. And of course, like, yeah, if if you just go along and. Yeah. Don't challenge anything and it's not good for you and not good for the organization and the environment that you operate on.
Yeah. I feel like when you touch some kind of the different stages in your career, like very early on, looking at your own sphere of influence, trying to be effective and productive in what you're doing and solving the right problems. And then kind of going beyond from that team aspect. I think that's where it starts.
When you're looking into, OK, what makes this team effective, not just me as an individual, but what processes or what ways of working are there and what's my opinion on them? Because I feel like not everyone has an opinion. But when you actually look and see and think, if you were to be responsible, would you do the same things? That's when it kind of, you might think, oh, that I'm reinventing the wheel, but for me, that's where it starts,
right? If you have a through critical thinking, if you have a good idea, I like the flexibility of trying things out and experimenting. And teams that experiment, for me, they're always learning basically. So that's definitely what I advocate. For indeed, yeah, even sometimes those experiments are the things that have been tried before. And maybe there are some somehow controversial or, I don't know, the industry might think that, yeah, this is not the right way
of doing things. But still, like there's value in trying different ideas and, and seeing why it doesn't work and how of course, like there, there needs to be a limit or a balance in there. But yeah, I think you should never say that we're not going to ever try something because, yeah, well, I'd read somewhere that it doesn't work, you know,
and. That's the like, that's the sad thing from certain leadership or what I've seen going from organization to organization, There are there is kind of this aspect of do I let people experiment or do I prevent mistakes that I know are going to be mistakes? And I am more so of the mindset of let people make mistakes. You give advice if they don't follow it, let them learn.
And then there's kind of the balance of how big of a mistakes that you like allow and stand for when it comes to security or impacts critical paths that maybe you you're a bit more strict. But when it comes to something innovation, like, yeah, people learn, let people fail and and grow from there. But I've also seen people where it's like, no, this is what I know, which means I've tried it. And then that's more of the black and white thinking, which
I don't like. No, and and you won't be able to influence anybody to follow the like let's say you're a leader somewhere and and you want to lead other people to follow a vision. And if they don't experiment some kind of pain, sorry, experience some kind of pain, or if they don't experiment with different solutions that they have in their minds and understand why they don't work that way and why they should go your way, they will never listen
to you. So one, one thing to do is to like enable the team to do like experiments and fail fast without making a lot of cost or, I don't know, like casualties. And then yeah, let them after they, they realise and learn what could go wrong, then you tell them, hey, you know, I have a solution for the problems that you're facing. And then they will listen to you much better and they will follow you. And that's how you also gain
credibility. And when people say like leadership without authority and whatnot. So that's I think like in line with this way of working and not like the approach that they, I say that you should do this today. And, you know, listen to me because I say so. And I have tried everything that. Yeah, yeah. Yeah, like the collaboration aspect, it's, it's really what I enjoy, like thoroughly talking to people, figuring out what the right problems are to solve. Testing also in production.
When when I first joined a project and we did a lot of AB testing, honestly my mind was blown. It was like, oh, everyone thinks it's this now it's this e-commerce. Someone clicks on a product tile, it opens up in a new tab. From a user perspective, I hate that. From a conversion perspective,
it worked wonders. Well then you don't have a leg to stand on. Basically, that's what we do to optimise conversion, even though personal preference, yeah, they keep that out of there, but that that's clearly something I enjoy. I've also worked with engineers and I don't know where that mindset sometimes come from, but they really get the energy out of technology innovation with regards to technology. And for me, that's not always
what a business needs. There's a very specific niche where you really solve interesting problems from a technology standpoint. I recently had a conversation with Bofan Laut. He's the CEO of WE V8 Vector Search Database. Very interesting problem. You're creating a database with vector search capabilities with regards to embeddings, those are probably very specific technical problems when we're talking about the majority of businesses, they're not going to be all database companies.
They don't all need that level of expertise, which means the engineers that work there need to solve business problems, and those might not be the most interesting problems from a technical aspect. Yeah, or, or some business problems that they face or some problems that customers bring to them could stem from, like, for example, the wrong use of their
technology. Or maybe because they have more experience with certain things, they can nudge their customers in a direction that they use the technology in a way. Or they change the problem a little bit and, I don't know, refine it and hammer on their problems so that they can solve it with the tools in a much better way. And that's also like something that's super important.
And well, yeah, so it's again, we got back to the point where it's not technical even when it's in a very technical domain. What I've seen is that some people like those types of engineers that I'm describing, they still try and find a way to work on innovative technology professionally, even though that's not what a business might need.
And that's where I see things sometimes also go wrong, where you see like an exotic technology all of a sudden be a backbone of an infrastructure or an organization where it's all of a sudden hard to hire people or find people that really know what's going on in this set of the code base or this set of the technology. I don't know how to solve that.
Like, for those types of engineers, would it be better if they're not in that organization or an organization which tailors more towards very specific niche problems? I don't know how to solve that. But I have noticed that not every business problem is interesting for engineers. Yeah. It's yeah, I guess it's when we talk about the individuals, of course, like when when we talk about the behaviour of an individual and when it doesn't match with what you expect inside an organization.
The easy answer is to say, yeah, well, this engineer is, I don't know, having some is not a match or is not a fit, but it's always a little. I think it's more nuanced than that because the environment you're in also has a lot of influence on how people work. Imagine that you work in an environment where there are so many like shackles around you, and then you're not really allowed to experiment or talk or, I don't know, like you're not involved in anything.
So these people will probably fall back to playing with technology and want to just touch the technology because that's their that that's the amount of authority that they have and they want to use it and they want to feel good doing those types of things right. So if your organization gives like space to people to grow into having that type of mindset, then you can expect people to like show that behaviour and then you can like work on growing that aspect in
in their behaviour. So I think this is also very important when we are talking about individual performances that your environment should also cater for it. Yeah, yeah. The environment having influence on like the behaviour of people is something I've really underestimated. I've been in organizations where, I mean, coming from CIBA, we go from organization to
organization. You have preference in how you execute, which is sometimes against processes or status quo by virtue of trying to be effective in executing. And that blows people's minds. Sometimes it's like, oh, this is what you can do and this is no longer needed and this is actually not useful. It's quite, quite funny to have that because from my personal side, like I go from organization to organization and I have done that quite often.
And for people that have been within the same organization, they are kind of, yeah, not part of the wallpaper, but those processes are like ingrained in their behavior. And it might be eye opening to then have a fresh perspective. And I don't know what would happen if those people would go to another organization and kind of bring that like experience with them. Yeah, yeah, indeed. Yeah, I think it's funny to have that realization.
I don't know if I would advise like going from organization to organization, but there is a lot to learn from looking behind the scenes of of what goes on. Yeah. And outward facing, I always wonder. Well, I think the disadvantage of going from one organization to another too fast is that you don't stay there to see the if like the the outcome of your decisions or other people decisions that you have witnessed during your time in
that organization. But you know, if you manage to somehow find a way to keep in touch with people and like we say, customer intimacy for like a part of the, the ZBIA core values, of course, like if you managed to find a way to do that, then of course you can like learn and take those
experiences somewhere else. What I see in consultancy a lot is that people join an organization, bring like a solution or, or a toolbox of the solutions and they build the same thing as the other organization and they move on and do the exact same thing. And then the whole industry gets affected by that or like a a large portion of clients and companies get affected by that. But that's not like the best
that you could do, you know. So it's always good to find ways to get some meaningful feedback about what you're doing and be critical about your solutions as well before you move on to your next challenge. And I think that's also very important for people to keep in mind. Yeah, it's interesting because for me, the the best we can do is very subjective. Yeah, and it needs to be a match with what the organization wants.
If we have an amazing technical solution, but that's not what a business wants, because a business wants speed and validation of assumptions, then it's kind of a mismatch, right? And then looking from a certain lens you can say that's an amazing solution, or looking from another one you can say that's a complete mismatch, which makes it not an amazing solution. Yeah. But also thinking along with people that have those specifications and want those solutions can be very rewarding
and useful. Like if you just go to an organization and then do what they say without talking to them and maybe like teaching them how to, like, think about some aspects that they haven't thought about, then they might actually change their opinion and say, Oh, no, actually I don't want this solution. I want you to advice me on what solution I need. And then you Co create. Yeah. And then it's much better, I
think than this execution. Yeah, this is like a, an amplified version of the Stack Overflow example that you gave. Yeah. Where you there's a certain ask and it's like, is this the the right way to do it or should we do this in the 1st place or what are the other options? Yeah, on the table. It's very hard though, when like time is tough and it's crunch time, people usually panic.
And that's exactly the opposite of what I think you should do because then it's like, OK, the decisions that we make, they matter, or really do they? At least we have to verify the assumptions that we have. And that's going to take time, but it's time well spent. Basically. If we go in a certain direction, it's a bigger bet, which means the losses will be more severe. But that's usually what I see happens. Like panic mode, someone says this direction, it's like all in it's code time.
Exactly. That's also very human though. Like The funny thing is there are a lot of human aspects within organizations. I wonder, like maybe it's because I've been recently talking to a lot of people that are in smaller organizations and more have more responsibilities just by virtue of being in a start up phase, what that environment looks like. Because then you're, you're dealing with a smaller set of people, less people problems, I
think. Or maybe when there are problems, they're more severe just by virtue of having less people. But the environment's very different, which means also the learnings from an engineering side are going to be very different in the 1st place as well. Yeah. Well, so you see that, for example, a start up with seven people can challenge the biggest organizations with many, many
people and unlimited resources. And the reason I think is kind of related to the the way that you describe this start up environment, people communicate with each other better. The kinds of problems that they run into are very visible because that's like a very small group. And then people who can take action are usually part of this group in which they notice that these problems exist.
And, well, if, if you want to solve a problem, you're just like one call away or, I don't know, like a few steps away from the, your colleague's desk to talk about it and then address it. But in a, in a large organization, so a team might be suffering and the, you have to wait for the next, I don't know, performance review, I don't know, metric review session to see that, Oh, this team actually suffers based on the metrics that we defined.
And then you have to go down and then talk to that team. You know, sometimes these hierarchies and those processes that we have, I'm not judging them, but in general, like the pitfall or the problem is that they, they can like make things very slow and, and they might kind of like turn into a handicap for you to understand what's happening in the organization and which areas could use some improvements.
So yeah, I think that's, it's, it's very nice to have a lot of resources and a lot of people to rely on, have backups and whatnot. But at the same time, it's very nice to be effective and reachable. Yeah, yeah, yeah. Zooming in on that hierarchy because I, I agree, that's also what I've seen. I've now seen organizations trend more towards engineering managers, for example, that are always have a certain technical aspect of their role and they try and steer for 5050.
And then it's probably up to the person what that balance looks like. But I like that that there's people responsible for personal development and growth within certain teams that also do hands on work and that are not like fully all in in only people management, which I think is a good thing for organizations with more hierarchy. That's where I've seen leadership or managers actually
be out of code. And then it's very hard to get by in like to get even on a level of empathy, like figure out what people are dealing with or from a person that's a software engineer, Like having an understanding that my manager understands my problems because if they don't experience the problems, then how can they? Because the problems from 10 years ago, not the same problems anymore. Yeah, indeed. Like those are more problems that I see with that type of hierarchy then.
Yeah, indeed. Yeah, yeah, exactly. Your so there's a book called It doesn't have to be crazy at work. So it has some very good ideas or I don't know the controversial ideas as well about how how you should run a business. So it's about people who run the company base camp and also they have a service hey.com like these, these different services. And so in one of the first chapters, there's a sentence
that I like a lot. So your company is a product and you're responsible for building this product. People inside the company need to know how to use this product and your product needs to have a good user experience. So think about this and then apply this.
And then of course, like it doesn't matter how large your organization is. So you have to you still have to create some process or think about not processes or like think about a mechanism there for detecting problems as addressing them as soon as you can and then running the whole business more efficiently. So I think yeah, it sounds. Fascinating to me, yeah. Like from I think an early age. Well, I think this is what I wrote down on my high schools.
Like at some point I want to own my own company. And I feel like now time is catching up. I am talking to people and it's very inspiring to see how they do that and like having a company and treating it as your product and like building and growing that out. I still think it's an ambition of mine. It's something that at some point I'm going to dive deep in and and try and experiment. I wonder if for you it's the same because you have a lot of organizational knowledge, a lot
of theoretical knowledge. I don't know what your ambitions are with regards to your own path. Yeah, at some point, at some point. Well, yeah, I like. Well, I'm not sure if if at this moment I'm ready for the challenges of running a full business. And of course it needs some
knowledge on that front too. So I'm mostly like involved with technical problems and not necessarily like those technical, but tech roles, you know, like staff engineer, like principal engineer, you know, these types of roles. And to run a company and to know about business, it's just like a whole different world. And of course, at some point I will be ready for that. I'm going to definitely try that. That's nice. I like that we share that ambition.
Like I talked to another colleague of ours. I'll introduce you in a bit. I think he's he's in now, but what's holding him back is like a really good idea. And I could see that like, I think I have many ideas, but to be like, OK, this is the idea I want to execute in is hard for me. I've seen very successful organizations building around and tailoring towards developers by virtue of having like an open core.
Yeah, either starting a community around something open source and building a platform around that. Yeah. Or starting with something closed source and then opening it up and building a community around that. Yeah. Tailoring towards towards developers. Yeah. Seems like a very attractive, Yeah and fun business model to be honest, because that's when you also kind of keep that technical as core of your
business. Yeah, I think if I built something that would probably be related to developer tooling or you know, something that that that's that has technical people as the customers, like some B to B business model. Yeah. But you mentioned something very interesting about the ideas. I think in this age and in this era, like having an idea, well, it's very good, but that's not the the most important thing. So it's everything is like collage, right, Because people have figured out a lot of
different problems. So it's it's about building a product. So you need to figure out what would solve a problem or, or which like portion of the market you can target, find a niche, do something different and then build a user brace around this. And I think this would be more challenging. Than like necessarily coming up with an idea, at least to me, you know, and then like building
around that idea. So, so having the sense of what how to build a useful product and how to build a user base around it, I think it's much more challenging. Yeah, and I feel like like looking at that and that's my ambition. It's not a skill that I'm developing. And if that's going to be the most crucial part, it's like, how do I develop? That is what I'm wondering recently. Yeah, I I saw a video that opened AI released I think
yesterday. When it comes to a new functionality they have, they call it deep research where you, for example, from a product sense are analyzing the market and you're saying, OK, this is my context, this is what I'm looking at. Can you give me data on XY and
Z? And it might take 10 minutes for this program to actually crawl whatever information sources it can find online or not, and then give you the answers that you're looking for, actually doing the research for you with regards to market segment, user penetration and so on and so forth like that. For me, the tuning is getting more and more advanced to indeed figure out what the right problems are to solve. And that's for me, very exciting. Yeah. Well, finally very exciting. Yeah.
OK, so here comes an interesting or controversial take on AI. Now, I think many of the problems that are currently being solved with AI are not really problems that you should with Gen. AI mostly, I mean like are not the kind of problems that you should solve with Gen. AI, OK. But like the the type of problems that require search like in a very large like corpus of data, I think that's that's where these tools can excel.
And you know, of course, like this tool that you describe sounds like a very, very good application of this functionality. Yeah, yeah, I'll definitely try that. Well, you have to pay 200 bucks a month. You have to have like the the highest tier license, but it will be available at some point. Yeah. Like I, I agree with you. Like I like the the funness of generating content. I think I don't know how much it has influenced social media or
my LinkedIn, for example. I, I see people make a lot of assumptions that, oh, this is bots or this is fake and this is generated. I have no clue to be honest. Like for me, those are all assumptions, but it's the fact that people have that tool like very, very readily available. I can see how that happens. Basically for me, indeed it's going to be leveraging whatever manual processes and, and
automating that. But even that from what I've seen, like the embeddings in a vector search database, it's very similar to like search and keyword rankings and stuff like that. Like they are still software engineering problems that we're, that we're having and that we're solving. Not necessarily data science problems, although data science people are now actually playing around with Gen. AI and LL apps, which I think is
quite interesting. Like, that's how a lot of those facets and worlds are colliding and coming together. Yeah. When I played around with embeddings and I was playing around and a colleague actually said, yeah, this is what Elasticsearch does basically under the hood. And this might be slightly different, but then you also have variances. And how do you split up your embeddings yet there's different variances. And that's also quite relatable to how you do search. Yeah.
I thought it was quite funny. Yeah. Yeah. So one question for you, do you think that with all these advancements, the number of skills that a person as like a as a someone who works in an IT organization or as someone who calls themselves a software engineer is increasing? Like for example, maybe 10 years ago you would be like a back end developer, yeah, or a front end developer or a database engineer. Now you are all of these things at the same time in one team.
The newsletter example that you mentioned in the beginning is another top ten engineering skills, right? So maybe like in the future it's expected from. Do you think that it's the case that it will be expected from software engineers to also know those kinds of skills and then wear more hats than they are wearing today? Yeah, For me it's going to be depends on the organization.
Like what I've seen is when especially during COVID for example, or people are being hired, people also being laid off. And the people that were laid off are were more specialists in the type of work they're doing, right? If I have a generalist that can do kind of a little bit of everything and times are tough and I have to make decisions, then a specialist that can only do one thing is someone that I might let go of compared to the
other basically. And now with tooling and intelligence, I think learning is going to be faster. So it depends on, yeah, the organization, what is expected of you as an engineer. Indeed, I think you can do a lot. But I've always believed that with a small team, you can achieve a lot.
That's even without AI, like what the cloud provides us in kind of reducing a total cost of ownership from a team and certain decisions that you can make in your infrastructure to have things up and running smoothly with almost 0 operational overhead. I think that was already there. So now if we go even smaller. So if I don't look at a team of four people, but a team of one. Yeah. A team of one is also risky, right. If I have software as the backbone of my organization, I
have one person responsible. That person gets hit by bus screwed. Yeah. So then am I going to have two? Well, if both are on holiday, and that's also a problem. So I will always have to have, I think, a a team of people that executes. Yeah, but now the the cross functional aspect of teams I think in with the recent advancement can can be stronger.
So like, instead of having one person who knows about one thing, you could have like multiple people who can, who might not be specialised in everything, but who can have like a wide range of skills or who, who can deal with problems in different domains. And I think this is kind of exciting for the future. I think so too.
Like the for me, that team aspect, I hope is going to play a very crucial part in that because a team that knows each other, that knows, for example, I know what your preferences are. I know what you're good at. I know what you're learning path is, what you want to grow in, in ambitions. You know that of me as well. And we have kind of the experience to communicate effectively with each other just by virtue of having done many things and going through like rough times and good times.
Basically. That makes a team resilient, right? And new people can come in and people can go, but the core of that team will be stable, I feel like. Which means that if it's a problem and you and I both haven't kind of figured that out yet, we'll be like, oh, we'll figure it out, right? Because I feel like you can be way more confident in the team and your role in that team then maybe sometimes in an individual because you have your own insecurities.
You might be like, oh, this is a whole lot of responsibility for a whole lot. I don't know. So that team aspect is going to be very crucial, I feel like. Yeah, exactly. And that the whole team can actually go and solve problems instead of splitting the problem and saying, hey, you do this part, just focus on this part and the other person just focuses on the other part. And then you in the end, the great yeah things. Which is going to take the longest.
Yeah. Like for me, the only problem I see is like this chicken and egg, where there's a lot of knowledge out there. You can learn quite quickly. But this foundational knowledge that you need an experience, you will always need experience. And for people that are coming into organizations, indeed, if they get that generic role or it is expected of them to kind of do a little bit of everything just by virtue of having intelligence. So knowledge and learning goes faster.
They will miss the experience of having done that specifically for a little bit longer. Yeah, that's a good point. Yeah. And I don't know if that's a valid concern, but that's what I've seen. Like if I were to be responsible for front and back end and a little bit of product, I've done all three, like as a specialist sole responsibility, which makes me more comfortable to do that. And then within a team, that can be my comfort and that can be other discomfort in other parts of the team.
But then together you figure it out. If you have a new person which hasn't had any type of experience but all of a sudden starts very generalistic, I don't know how that's going to grow. Oh, so maybe their balance is to swing between the different roles. Like, sometimes it can be a very specialized person in one area, and then you can go back to becoming like more of a generic person or a generic role. And then if you keep doing it, then you kind of like accumulate
some knowledge. And at the same time, you are not disconnected from some areas that you often don't touch when you're like an especial, like a specialist focusing on just one aspect of the job or the problem. So yeah, based on this conversation, I think swinging is a good thing. Yeah, yeah, I think so too.
The funny thing for me is when I started out, like I I might not have had the best foundational knowledge because I didn't have a a traditional education, computer science, but then I find myself being very good at executing. But then certain things executing, I was like, man, this is taking a long time. I have to Google things and I'm not quite sure with regards to what I should do or which direction like. And that's when I realized like my foundational knowledge needed some tweaking.
So then I swung back and forth between executing and working on that more foundational knowledge. And that, I think has really helped. But now you're in a position where you might not have the right foundational knowledge yet. And that's going to be, I think, crucial where we figure out how to get the right level of foundational knowledge to be comfortable and executing and then learning on the go. Because the biggest skill, I agree with you, is still going
to be learning. And now it's just going to be amplified and you're going to have more tools to learn faster. The time is still the same, which means, yeah, it's going to be a funny, funny way of working, I think. Yeah, indeed. Cool, Man. I've really enjoyed this conversation. For a judge, this was a lot of fun. Yeah. Same for me, I have lots of food for thought. Yeah, same here. I'm definitely going to re listen to this because I think this was a good one. Yes, thank you very much for
hosting this. Thank you. Thank you for coming on. I'm going to round it off here. If you're still listening, if you're still with us, like the episode, If you liked it, let us know in the comments section what you thought and we'll see on the next.