Hey, a quick message. For those of you who are listening to this episode on Spotify. I have a small favor to ask Spotify. Now allows mobile users to rate podcasts. I would really appreciate it. If you can take a quick, pause to go to the technique Journal podcast page, and leave your favorite show. Your best rating on Spotify. It will help me a lot to get this podcast to reach more people on the platform. Thanks a lot.
You're good examples. If you have someone in a really fast car like a Ferrari and you have someone else in a Bicycle, the Ferrari is faster. But if you go in the wrong direction, the bicycle is better. If you're trying to get to the right place, a bicycle might be better. So, I see a lot of people in programming we talk about velocities. We're talking about how fast can we do things and there's nothing
wrong with that. I mean, it's good to improve your processes to make them faster and more efficient is good. But sometimes people lose track of was even more important is doing the right thing in the first place. Hey everyone. My name is Henry Surya with Robin.
And you're listening to the technology, you know, podcast the show where I'll be bringing you the greatest technical leaders practitioners and thought leaders in the industry to discuss about their Journey ideas and practices that we all can learn and apply to build a highly performing technical team and to make an impact in your personal work. So let's dive into our Journal. Hello again, to all of you, my friends and listeners. Welcome to a new episode of the
fact that Janelle podcast. I am your host Henry Surya Vera Wang. Thank you for tuning in listening to this episode. If this is your first time listening to technology, you know, subscribe and follow the show on your favorite podcast app and social media on LinkedIn, Twitter, and Instagram. And if you are a regular listener and enjoy listening to the episodes, subscribe, as a patron at Tech, did you know
that laughs? As Patron and support my journey to continue producing great technology, new episodes every week. Many of us may think that implementing domain driven design means using object-oriented programming and paradigms, especially when looking at some of the DD technical design patterns and some of us, especially the functional programming practitioners, May wonder whether functional programming can also be used to implement domain-driven design.
And if so how we can do that properly. This episode tries to provide you some answers to that particular question. My guest for today's episode is Scott Russian. He is the author of domain modeling made functional and the popular F sharp sight. F sharp for Fun and Profit.com in this episode Scott began by sharing his view of the need for developers today.
To become more polyglot developers and learn multiple programming languages as someone who learns a lot of programming languages and even being really good at five to six different languages, Scott provided some great insights on why we should try to at least learn and practice more than one language.
Scott then shared about functional programming fundamentals and how functional programming differs from object-oriented programming, as well, as sharing some cases when one is better suited than the other Scott, then explained how we can use functional programming. When implementing domain driven design, including how to model some of the DD technical designs and Transaction boundary
throughout the conversation. Scott shared why F sharp has become his favorite and go to programming language and why he thinks it may be better from the other available. Functional programming languages, towards the end of our conversation. Scott touch on important advice about Effectiveness versus efficiency. And what leaders need to be aware of regarding doing the right thing versus doing the thing fast.
I really enjoyed my conversation with With Scott learning about functional programming, how to apply it in domain driven design, and a good reminder about the importance of Effectiveness rather than efficiency, and I wasn't really aware that F sharp is actually now available outside of windows platform. If you also enjoy and find this episode useful, please share it with someone, you know, either your friends, or your colleagues, who would also benefit from listening to this episode.
Also leave a rating and review on your podcast app or share about this. Out on your social media platform. It is my ultimate mission to make this podcast and the knowledge available to more people. And you can play a part towards fulfilling my mission. Before we continue to the episode. Let's hear some words from our sponsor. Today's episode is proudly
sponsored by skills matter. The global community and events platform with more than 100,000 software professionals here members, can organize their learning experiences around the technology topics that Care about most you get on-demand access to their latest content thought, leadership insights, as well as the exciting schedule of tech events running across all
time zones. So where the devops our data science is your bus or you are fan of functional programming or all things Cloud. You can make real connections with people who share your interests head on over to skills method or Cam to become part of the tech community that matters most to you. It's free to join and you will find it. Z to keep up with the latest tech Trends. Hello everyone, welcome back to another new episode of the packaging of podcast today.
I'm very excited to have someone with me, is name is Scott Russian and he is actually the famous author of the book domain modeling made functional. So if you are into domain-driven design and also into the functional programming, I'm sure. Maybe you have heard about this book. He's also the creator of popular F-sharp website called f sharp for fun. And Profit.com, the name itself? Sounds really fun.
So got really looking forward to have you in the show today and looking forward also to learn more about functional programming and maybe also domain-driven design at the same time. Well, thanks for having me Henry. It's nice to be here. So Scott, maybe in the beginning. I'd like to always ask my guest to introduce themselves and also to tell us more about your highlights or turning points in your career. So I'm quite old, I've been
around since the dinosaurs. So I first started programming back. The 1980s that so old I am, that's when everything was still in black and white. The very first computer I ever used, was actually a CPM machine before dose, even it was a kaypro and it had two floppy disks and now hard drive, very exciting. But, you know, it's amazing. What you can actually, learn given how nowadays, we consider these machines really tell, but
you can learn a lot mean. I learned all my programming on this machine and the first program I actually used was debase to, which was The Microsoft Access of its day or the fox probe its day. It was like everybody used it for doing database. Programming ahead of a programming language, you're scripting language built in. So I started programming database and I actually end up writing some really quite complicated things and it will fit on one floppy disk or two floppy disk.
And then, of course, this is pre-internet. I used to be a big subscriber of all those computer magazines like B magazine. Dr. Dobbs journal. And my favorite one is actually called computer language, which is all about computer. Languages you get introduced to all these interesting. Things that you would know about. So, I learned prologue and I learned small talk and I learned a language called icon, which is sort of a predecessor of python. I played around with all these.
You could basically get floppy disks with all these programming errors on it and a funny sort of way because there wasn't any standard language really people would experiment. There's a lot of experimenting people try all sorts of stuff and I think nowadays people actually do less experimentation. There's so much to learn. You can spend your whole career just doing JavaScript or Java or c. Shot. So you'd end up not experimenting with all these
different other things. So, there's actually great for me because I learned all these interesting things. So I actually got a job doing Small Talk programming back in the early 90s. This is pre Java. So, small talk was actually used by Banks and insurance companies and these big corporate businesses. They thought the small talk was gonna be their Enterprise language. So for a couple of years, it was and then the internet came along and Java came along and small
talk basically died. So then I switch to using python. Python program for a while. And then I switched it C sharp when dotnet came out in 2001 or 2002 study, using C sharp. Then back 2010. I started using F sharp and so F sharp.
I've really loved ever since that's been my kind of main programming language ever since, although I still do bit of C sharp and I still do Python and if I have a contract that's going to pay me a lot of money that we use whichever language they're paying me to use, I would say back in the early days. There's a lot of creativity around learning programming languages. The The big thing I did and this is what I would recommend everybody is again back about 10 years ago.
I started doing my blog but if shop for Fun and Profit and I did that originally, as a way of teaching myself, F sharp. The idea is, I would try to explain it to somebody else, you know, there's a static thing. If you try to explain it to somebody else, it forces you to learn it really well by something. I already knew. And so I thought I'd do that and every weekend, I would write a blog post about something in a shop and it turned out a lot of
people found. It really useful, not just me and It turned out to be really quite popular blog. It still is quite popular blog. And so that's nice. I would recommend anyone if you're looking for career advice is to do blogging or something, to make yourself, stand out from the crowd, having a Blog, a big, an expert in something doing conferences. These are all good. Career moves as well as being fun. I really enjoyed writing the blog and it was very good for my career as well. Right now.
I'm just doing a mixture of writing books and doing contracts with people, and that's how I make my living. Thanks for sharing your story. It's since a long time ago, even I Unborn their tithe. It is a long time ago. Yeah, it's really interesting to hear that last time, there was not even a hard disk, and you mentioned that you have learned so many different languages, right?
So maybe if you can count 10 20, like Chennai, will probably say this five or six languages that I'm extremely good at including sequel. I did also act as a SQL DBA for a while. So I'm pretty understanding of how SQL in relational databases work, which I also think is a
useful skill for any developer. Yeah, I would say it's probably five or six languages are very Open the apps and a couple other ones I could probably do. If I have to, I'm not really a JavaScript expert but I can hack it if necessary. First. I don't identify Myself by a language. There's some people say I'm a Java developer. I'm a c-sharp developer. I think of myself as a developer. I've solved problems the language that you use to solve the problems. It's not that important.
It does actually make a difference. Different languages do make a difference in how you think about the problem, but I'm not particularly bothered by having a language debates about which is the best language and all the stuff is just going. Trivial really one of the topics these days that is very hot. Right? Whether you should be a polyglot developers or not. So coming from your background learning so many different languages and even expert, five to six different languages that
you say. You can be really good at all. Why do you think developers should think about being a polyglot developers? I think the first of all, there's a couple of different reasons. The first one is that the more different languages, you know, it makes makes your toolkit bigger. So if you think about, if you're a carpenter, you have a hammer for you. Also have a Driver.
And you also have a wrench and you also have a drill and you have all these different tools and you use the right tool for the job. A carpenter only ever used a hammer and never use a screwdriver would be a very bad confident. And so, it's the same thing with programming. I think different programming languages are different tools, and they have different ways of working with the tool. So if you sequel, It's a completely different way of thinking.
Then if you're using an imperative language, like C sharp or something, it basically changes the way you think about programming, so it expands your mind. So for my purposes, Personal point of view. It's very good. And then just from a practical point of view, the more languages, you know, the more job opportunities you have that's another thing.
But also when you do work on a job as a contractor, you can just walk onto job and do not going to be complaining that you don't like the syntax or you don't like the style or you don't like them do this way, some programmers like to rewrite everything, using the best way, when I come into a job, what I call a Brownfield project where the codes already written it, as a legacy project, leave the code use the same. Style that the people they're already using do within reason.
Obviously, if it's horrible, you can refactor it. But basically don't try and impose your perfect Style on existing code, just adapt to the stylus or do that. If you've done many different languages, you tend to be much more open to that. If you had limited experience, you tend to be much more picky and you say, well, has to be this way, is the only way I know and this is the way it has to be. That's not very good as a professional. I don't think you should work
that way. Yeah, a lot of cases these days, especially developers who just came into a project. Maybe they started a new career new company or their consultant. They join a project. So yeah, definitely one of the most common remarks made by those new joiners, of course, the code base is probably not so well done. We should refactor this, we should rewrite. And I think you brought a good point that if you have so many different paradigms and you are familiar with them, and maybe
also good at that. Maybe you can adapt yourself to different code bases, right? That's right. The good example. Is I just did a python contract M4 experience in functional programming and also very experienced in object-oriented programming. But for python, I think the right thing is just basically, at a Chic kind of procedural programming. And so when I was writing this code, I didn't use a lot of
weird functional stuff. I didn't use monads and all this stuff, and I didn't use super nested class hierarchies with lots of inheritance because I think python has a certain style of working. Yeah. I have seen people do JavaScript or Python and they ringing monads or they bring in some wood functional stuff. There's not fair to the person is going to have to maintain it. I would say that's not being a professional programmer. You have to think about other people.
It's not all about what you want to do. It's what makes life easier for other people. I would never use Advanced functional programming techniques in a project where people didn't care about that stuff. That's not the right way to do it. Yeah, and also, I saw one of the most popular tweet that you. Did you mentioned that by being a polygon developers? You start treating syntax as it is, it stops being a big deal that you don't being nitpick
about certain writings. Yeah. The Test example, is Curly braces. So F sharp doesn't have curly. Braces python doesn't have curly braces. Sequel doesn't have curly braces, a lot of programming language do not have curly braces. And yet I have seen some developers say, well, if it doesn't have a curly brace, I can't understand it. Then I just think that's silly. That's just very limiting. The curly brace does not make a big difference in the syntax of which that what the keywords are
and stuff. That's not the important thing. It's about expressing yourself. So, anyone who says that kind of stick, I just think they need to get out more. They need to try more different languages and learning. In a bit, get out of their bubble and try some more things. So, let's move to the main topic of today, which is aligned your book dumb in modeling made functional these days. A lot of crazy about domain driven design, functional programming as well. A lot of people swear by it.
That's like the ultimate programming language. I myself come from more object-oriented, programming background. So, maybe in the first place, right? Maybe if you can share with us, what is the functional programming, why people should maybe try to understand it? And why is it probably much better in some respects to all people. So first of all, there's no official definition of
functional programming. My definition is, it's a programming style where you use functions to do everything in object-oriented programming. The basic unit is a class and in functional programming. The basic unit is a function in
function program. If you want to change the behavior of something, like the strategy pattern you pass in a function, if you want to compose a bigger set of functionality, you combine two functions together, basically everything you do is functions, you take these functions and you Chain them together, typically into some sort of pipeline. You might even have a function where the input is a function
and the output is a function. And so you might call that a function Transformer. So you basically have some kind of function and it doesn't do what you want. So you want it to this function Transformer and it turns into a different kind of function, which does do what you want. So it's just a different way of thinking about how you build software. Another part of functional programming is also, immutability is typically the default Behavior because in a classic mathematical function
things don't change. When you say two plus two, the number two doesn't change when you add something to it. You've got a new number back. You don't change the original numbers and the same thing with dates when you add time to a date, you don't modify the original date. So if you apply that logic to everything, that nothing changes and you always create new things.
It makes understanding the program a lot easier because you always know that the things that you've worked on, haven't been touched, and you've always got new things to work on. So, the combination of work using functions everywhere and having immutability. It's a very hard thing to get your head around when you first start learning. Programming. It's really, it's weird. I mean, when I first started learning I've shot by was thinking, how can you write any code?
When everything is the musical? That's just not possible. And then, yeah, if she turns out, you can and turns out that's not too hard. And then how can you do things without using classes? How many wider program with you? You see classes and methods? Well, it turns out you can, so it's definitely another way of expanding your mind. So why is functional program? Now? Like I said, I love of Georgia programming.
As I said, I used to do a lot of small talk, then I love small talk, but I think from Modern. Enterprise programming, specially, functional programming because of this immutability and because the composition, there's no inheritance and so, everything tends to be very explicit. Every parameter is passed in explicitly with class based programming. There's a lot of implicit code. I mean, you could have a methods with no parameters. It returns void and has no parameters behind the scenes.
It's doing things because it's using instance variables or something, but you can't really see what it's doing. And that's the whole point of all going to probe. The whole point of object when it is encapsulation. You're supposed to I doubt it's working, but I think functional programming is the opposite, the ideas. Everything's transparent. Everything is exposed. There's no hidden data, and you might think well, that's a bad thing. There's no hidden data.
But again, if everything is immutable exposing it tends not to be that bad because you can't change it. Obviously, things like apis as a different thing in general, when you're coding, if everything's immutable, it doesn't really matter. If people can see the internals of an object because they can't change. And one aspect of immutability that I understand as well. Right? So if everywhere it's immutable, it also supports For concurrency really?
Well, so you don't have side effects and you don't have to worry about multiple processes, accessing the same instance. Yes. Exactly. Although I have to say it's a little bit overblown. But I mean, that was one of the things they hyped up about functional programming, is it to concurrency really? Well, they did processing really well which it does but even if it didn't I don't think that's the main reason to use it. I think the main reason is because the programs that you
write with functional programs. I think they're just going to be a lot clearer and easier to understand sometimes with objects. To get what I call object soup where an object is talking to another object which is talking to another object which is talking to the first object. All these objects are talking to each other and it's really hard to disentangle. Them should ever debug something like that. It's really painful. There's nothing in object-oriented program that
stops you doing that. There's no pressure. It's always easy. Just to add another method. Functional programming is somehow. It doesn't quite do that because the pressure is to keep things. Simple, when every single parameter is passed in, it's really hard to have 100 parameters. There's a natural pressure to keep things simple and make small components that are glued together. Heather. So, again, about concurrency stuff. I just think function program is
a really nice technique. That's not the only technique. One of the things I like about our shop is it actually has an object-oriented component as well? So you can actually choose, which ever is the best Paradigm. Sometimes I'll get audited, is actually the right Paradigm for certain things. And so it's nice to be able to have a language which supports both and you can just switch
between them. But typically I would call myself a functional first program in, which is I start by doing functional and if that doesn't work properly or it doesn't feel right then, I switch to When do you see this? As the Tipping Point when you started as a functional first, but then what made you switch to the ob Paradigm? What do you think are some of the good problems with to solve
my old pee? Well, if you really talk about Behavior, if you really do want to encapsulate, if I have a bunch of things and I don't care about the data. I only care about the behavior, then that's what LLP is really good for. If you think about agent BAE Systems, agents are basically oop just very similar model, especially if you're doing a user. Face or something of your origin.
Interfaces is so nice thing because, you know, they're button class and a listbox floss and I think they all have basically the same behavior you want to click on them. So that of your origin program is wait for that. Graphical, programming objects are great for agent, based programming the goods. Sometimes I say where you have a kind of plug-in model and you don't actually care how its implemented. So it is useful. In those cases. I do mix and match between the
same piece of code. And sometimes you really do want it. Sometimes it's really nice to have inheritance occasionally not massive deep in her in the street. They sometimes nice a base class with a couple of sub classes that inherit from it. Sometimes it's just nice to have that. So in domain-driven design most of the literature that I read actually they used the or Ps. Ml sample reference, you and came out with a book domain modeling meet functional, which
is kind of unique in a sense. So what made you think that the domain modeling can also be solved by functional programming Paradigm? This is very interesting because you're quite right, that domain driven design is not attached to any particular programming. In Paradigm, it really shouldn't be domain-driven design. The idea is that you focus on the domain instead of the technology. So you try and focus up, use the words from the domain. You try and model The Domain in the code.
And you try not to contaminate your domain with all sorts of technical stuff, which is not relevant to people. So the got nothing to do with which programming Paradigm use. But one of the nice things about functional programming is because in object order program, it's very easy to have a lot of extra complexity or what people ceremony, extra stuff like that. Sauces and all this stuff, and it's quite easy to end up with code, which has a lot of stuff in it, which isn't really part
of the domain. So, you have a base class. We're in the real world. You don't have base classes. You don't have proxy classes. You don't have manager classes. You don't have interfaces The Real World objects do not have that in functional programming. It tends to be a lot simpler because ocean foam doesn't have classes. So then that stuff happens, it basically has data and it has
actions on the data. I think also lot of people, when they do domain with a focus on the data side of things, And you often have database driven design where you start with the database tables and you work back from there. I think what's happened is people have realized in what businesses care about analyzing a real system. It's the events. It's the actions. It's the workflows the activities.
These are the things that are actually important and the data is just a way of transferring stuff. But the activities you want to model an activity. You can model is something with an input, you send me this letter and I do this action. You send me an e-mail or you create this event and I do something. A function is Jackie, that's an input and output. So functions are actually very good for the main model. Now, there's another thing which applies to certain functional.
Programming languages namely the statically typed ones. So not things like closure, the things like F sharp a camel Elm. They have a type system, which is very different from an object oriented type system in the functional. Programming type system. This is called an algebraic type system or a composable type system. You can actually build bigger types from smaller types in a couple of different ways. But one of the ways you can do
it is you can do it as a choice. So you could say this thing is, a choice between this thing or this other thing. Think of it, kind of like an enum. The glorified enum. I mean most audio two languages do not have this. It turns out this Choice modeling is super important for most of Maine's. If I say, I'll send you an e-mail or I will send you a
letter that's a choice. I want a model that choice and it's actually surprisingly hard then obviously to language and you can have two different subclasses, but it's kind of painful in a functional language with an algebraic type system is actually really. See, so a lot of my book is actually talking about modeling things with the type system, just modeling things as choices, and then as record types, which is very common and then these functions with inputs and
outputs. So I think there's a very good match for functional. Programming, one aspect of the domain driven design is actually what they call tactical design. So, these are things like design patterns commonly used in DD things, like entity aggregate value object service repository. And there's so many others and normally they kind of like being modeled as Opie. That was also the Paradigm that
stick to it my head. So when you implement those kind of tactical design in functional programming, maybe you can give some examples. How can you really design at the d-class of an aggregate class in f p? So a lot of those things I think do, apply only the very object oriented these low level domain driven design things like entities language value objects in DD is an object where if you have a different object with the same data in it, it's the same
thing. So if you have to address, Data structures and they have the exactly the same address data in them. They're the same address. And what's interesting in functional programming. That's the default in object-oriented programming. That is not the default in object-oriented programming, every object is a different reference.
So if you want to make two things equal, you have to override the equals method and the get hashcode method and all this other stuff and in functional, programming languages, that's the exact opposite. So that's nice. And then in object-oriented programming entities are considered to be mutable objects in functional programming. They're not.
Immutable obviously. So really, they just objects where there's an ID. They have something ID field so that as you change them they have the same identity. I don't like having all this. Jargon. I think it takes away from making people understand these things, but you can totally do the same things. Things like the concept of service, which provides a service. That's not special to any particular programming language. One thing I should point out
though. Is this repository pattern, which is used in domain-driven design is actually used outside of domain driven design, people almost never use that in function. Going so it's very common in object-oriented programming to mix up database, access and code and business logic. You might have an object that saves itself. You might have a save method on an object which saves itself to the database.
That's a very common style. This used in C sharp with Entity framework and with python with Django. And so on in functional programs that we can be considered an anti-pattern that would be considered a really bad thing to do. Because in functional program, we tend to separate predictable stuff from unpredictable stuff. Of deterministic code from non-deterministic code. What we called Pure function is a function that always gives the
same result with the same input. It always give the same result. So adding two numbers together, always gives the same result. Now, reading something from a database is not like that. If I read from the database again, I might get a completely different set of data. So, in a functional program, we hate that we hate having unpredictable data.
So what we tend to do in Fontana program is separate anything to do with databases or file system or network, which And move it outside the Core Business. Logic. So we have this Core Business logic in the middle. And anything to do with the outside world is on the edges of the application typical examples, you might load up some data from the database. And then you do all this business logic and then you save some data back to the database
of the end. So the database stuff is on the outside and then the Core Business logic is in the middle. So it's completely opposite from the classic interior architecture where you have the database layer at the bottom. In the function program, the databases on the outside, not on the inside. This is not necessarily a functional, programming thing. People have been talking about this in other architectures. There's the ports and depth architecture. There is the onion architecture
that clean architecture. The hexagonal architecture. All these things is to try and keep the domain logic in the middle and keep the rest of the world on the outside. There's another way of saying which is an imperative shell and a functional called as taught by Gary Bernhardt on that topic. So what's interesting is in object oriented.
People have to be encouraged to do this, but in functional programming, it happens automatically, it's the default Behavior. So you don't really have to try and persuade people to do it this because this is really the only way of doing it. So I think one of the reasons going back to why I think functional programming is quite nice, is that there are some languages where you can do something, but it doesn't really encourage you to do the right
thing. The language can let you get away with all sorts of terrible things. So for example, let's talk about C. So C you can be very cautious with your memory management and your bounds checking stuff, but the language doesn't work, doesn't really encourage you to do bounds checking. There's nothing in it, which forces you to do. So. It's very easy to make mistakes. So I like a language where you're really kind of forced to
do the right thing. So a language which is immutable and doesn't let you do database stuff. It kind of forces you to keep the database stuff separate from that Core Business logic. And so that's what I like about functional languages. They really encourage you to write code in a certain way. Nothing that you couldn't do and I'll be Odin language, but somehow it just seems easier when you're using functional style. I don't know why that is so I'll be bubble half wrap their head
around these paradigms. I think it makes it intuitive another aspect that I want to ask. Because it seems very interesting topic and domain-driven design is the concept of transactional boundary in dddd. Advocate aggregate should be the scope of the transaction. So how do you actually do this in FP with just now, when you mentioned predictable, pictures and predictable? Where is that layer for the
transaction part? Well, let me just about to boundaries of their all into my rooms on the first boundary this, what they call a bounded context. The idea of about a contest is you break your program into subsystems, but each subsystem does one thing. Well, Well, it's kind of like a giant object everything in the sub system uses the same terminology works in the same way. Again, it sounds really obvious. But it's very easy to write systems.
I have seen lots of big systems where everything's kind of Tangled together and you have pieces of codes that they all interact in a big mess, big ball of mugs. And so that's the first thing is to have these bad a context and then within a band of context do want to guarantee that certain constraints or Integrity the met. So if you have an order, something you want to make sure that the price Charging is the sum of the prices of the items.
Are you want to make sure that an email address always has intact sign or something that's various rules about things. You can just enforce that with a function. And again, if you have an input and output, you can just say, well the only way you can change this thing is through this one function. I think this is because it's very common with a mutable object because you can mutate any of the fields. It's very easy to mutate one field and then forget to mutate one of the other fields, and
that might be wrong. There might be some sort of a strange. Ain't that if you do this thing, this other thing also has to happen. So if you have immutable data, you can't have that problem. If you can't mutate values, then once it's correct, then it can never ever change. Very simple example. If I have an email object. When I create this email object, I validate that it has an at sign or whatever. Once I've created it. It's immutable I never ever have
to check it ever again. There's nobody can mess it up. So I don't ever have to worry about revalidating it or double-checking it or so on. This immutable, it can never ever be changed. So he actually ends up with a lot less defensive programming. If you have immutable data, you typically validate things at the very beginning that the edges of your program. And then once you're inside your
program, you basically trusted. It's all valid because it can't possibly be changed so that even applies to bigger things. But if you have a thing where if you change this field, this other field has to change at the same time in an object-oriented thing where they're two separate fields that would be card to enforce but if the only way to change it is through this special. The function and the function changes both things at the same time and spits out a new one
which is valid. And if the things aren't correct, it returns nothing. You've always got a valid piece of data. So, a lot of these things about integrity, constraints and stuff. It's really easy to do. It's not even that big a deal. It's not something you have to make an extra effort to work on because that's just the kind of way. It works. Naturally. Again. This is where the program Paradigm encourages you to write stuff in a certain way. Okay, then I'll join the program.
You can have a class where you can only set things. Instructor a none of the fields are mutable. And if you want to change any of the fields, you have to create a user Factory method or something, which validates, everything you can totally write code that way in 0 as well, but it just kind of feels it's hard. It's like you're going against the way the language works. The language doesn't make it
easy for you to do that. It's not specific to functional programming but I do think it's the way that functional programmers. Think about these problems Maps, very nicely onto this kind of issue in the book that you're chose F sharp as the Language to express your thoughts. You also create your website, F-sharp for Fun and Profit. Maybe you can tell us why F sharp. Why people should use F sharp instead of closure and all the other functional programming. Well, I think F sharp is a very
nice multi-paradigm language. Educated depends on the environment. You're working a bit of time. Talking about typical business applications for Enterprise stuff. First of all, I would say it's nice to have a statically typed language and if you're working by yourself, that's fine, but I think statically. Typed languages are definitely the way to go if you A team of people, so that eliminates closure and so on.
And then, in terms of the statically, typed functional languages, you have Haskell. You have, oh camel you have Elm. They have F sharp what I like about their shop. Is, it's on a big platform. It's on the.net platform. For people who don't know, dotnet actually runs on Linux
really? Well, it's no longer a Windows only thing and because it's only on.net, any kind of thing you want to interface with, there's a dotnet API for it probably or donut library and you can just plug that into a shop and go so you don't have to Write your own libraries all the time. So, just in terms of productivity. I just think it's my favorite language would being productive. It's also got extremely good tooling. Most of the function languages do not have as good to link.
The obturator languages don't have much better Tooling in general, but I would say of the function languages have shot, probably has the best Tooling in terms of refactoring and then the editor hints. And so on. There's a very nice plug in 4 vs code called iron, I'd Visual Studio supports F sharp out of the box and jetbrains Rider supports shot out of the box. So it's just a very nice
experience a language. Like Haskell is a very, very powerful language, but it really does hurt your brain, because it's so strict about immutability and strict about doing I owe. So if you want to learn functional programming, that's actually a very good language to learn because it will force you to learn this stuff. But in terms of actually being productive, I think F sharp is a little bit easier to be productive in one of the
problems are with languages. Like Haskell is some people like to get really advanced in some of the stuff. They do men have to go, sort of encourages that a lot of people. To write weird car stuff in Haskell. It makes it very hard for other people to come along and maintain it because it's just crazy. So you can't get too weird enough shopping at some people think well, that's bad. But I think that's nice. You can't go overboard with advanced stuff. You can never get too much that way.
So again this very practical very pragmatic language that way. So looking at the other thing that you are big, about you mention about productivity. Just now you mentioned that programmers need to be more effective versus being more efficient. So I think you have topic is a big thing in Productivity world, right? So effective as insufficient. Maybe you can give us your thoughts as well. What do you mean by programmers? Should be aspiring to be more
effective versus efficient. So, efficient is doing something better. Like, an LED light bulb is more efficient than incandescent light bulb. It uses less power and Global doing a task with less energy and with less money, that's being efficient, but we do tend to focus on efficiency instead of Effectiveness. Now. Effectiveness. Is doing the right thing, so it's not about how efficiently you do it. It's about. Are you even doing the right thing in the first place?
The good example is, if you have someone in a really fast car like a Ferrari and you have someone else in a bicycle, the Ferrari is faster, but if you go in the wrong direction, the bicycle is better. If you're trying to get to the right place, a bicycle might be better. So, I see a lot of people in programming.
We talk about velocities when it's all about Sprints, and velocity, and story points and all Stuff we talked about how fast can we do things and can we take off features fast and all the stuff and there's nothing wrong with that. I mean, it's good to improve your processes to make them faster and more efficient is good. But sometimes people lose track of was even more. Important is doing the right thing in the first place. I've had a bad experience where I spent a long time building a
product. We had a really good team. We had really expert programmers. We had really good. Processes is very agile, all this stuff. But after we finish building the product nobody wanted it. It was a failure because we didn't actually build what people want it. We were so obsessed with our own efficiency. We didn't actually talk to anybody. We don't actually talk to the end users ever since then.
I've been very concerned about doing user experience, testing, getting feedback from the customer, getting feedback from other programs, thinking about other people and listening to other people. Not just doing what you think. You again, techie people tend to be very concerned about technology that this is a technology solution for every problem. Sometimes it isn't a technology problem. So people button and so you have to improve your people skills, your listening skills.
And like I said, try to understand what is the right thing to do, not just how fast you do it. Well, I had a tweet, a funny tweets about this. A few weeks ago, which is there's a famous detective series in America in the 1990s called Murder. She Wrote, it was set in this very small town in America. Every episode, some personal get murdered this woman. She was really good at being a detective every week. She solved the murder. Eager. And so she was very efficient at solving murders.
So she sold hundreds and hundreds of murders, but that's being a very efficient. But really, if you want to be effective, you should be saying, why are there so many murders in this small town. And why don't you stop these murders from happening in the first place. That would be effective, not just being efficient. It's very hard to think about Effectiveness as no metrics for it. Effectiveness is very hard to joke. It's a judgment call.
Are you doing the right thing? We sometimes do the same thing. We focus on solving the problems quickly. Well, then actually trying to figure out. What's the point of solving this problem. If it's not even the right problem to solve, there's a social component which is if you are seen as a very efficient person, you get a lot of credit. If you solve all these murders, you consider the great detective and everyone thinks you're
fantastic. If you stop, the murders from happening in the first place, nobody cares. Because you never even happened, and therefore, people don't think you're doing anything. So, unfortunately, we don't get rewarded for being effective. We only get rewarded for being efficient. So that's something just to be aware of if you're ever, Were in a management position, don't just watch people for being efficient and productive reward, people for doing the right thing.
So yeah, I was about to say that people probably don't associate high-performance with Effectiveness unless the management has actually already realized about this.
So they tend to see people who can work as many times as possible within a short amount of period of time or probably the person is just busy all the time, but always get things done, but there are people who tend to maybe perceive as lazy but they are actually doing the right thing that solve the problem at the root, cause probably tend to be less visible unless they can mention about the impact and all that.
So what do you think will be your Advice to managers or leaders to always have this mindset to be looking at the effectiveness versus the efficiency. There is a tough one. The problem is, it's very hard. It's just hard to measure and now we're not even in the realm of Technology. The person I would recommend is a guy called Peter Drucker. He wrote books on management Theory, back in the 1950s and 1960s.
He is the person who she came up, this idea of the difference between Effectiveness and efficiency. It's not an easy thing to do. It's so easy to get sucked into the whole efficiency thing one way. To listen to the outside world. So again, rather than working on something and thinking that, you know, the right way to do it, listen to users, listen to the feedback from people and change direction. If you're going in the wrong direction, you want to know as soon as possible.
So I guess would be having feedback loops as many feedback loops as possible, so that you can change direction. If you realize that people aren't happy with what you're doing. And he comes back again to the direction, Vector speed. You may send the beginning if you have a Ferrari, but if you go to the wrong direction, it's even worse. Exactly, exactly. Really? Yeah, and unfortunately, I've seen a lot of tech companies to exert. They build a product that nobody wants.
It's nothing to do with a little quality of the team. It's just literally you're building the wrong thing and you haven't actually listen to your customers. So, it's sad. And that affects this day. I mean, social media and all that people also wants to Crave instant gratification or instant achievements. Sometimes you also need to think about. Are you going into the right direction with that speed or actually something that matters to you. So that's a food for thought for everyone here.
So Scott is In a pleasant conversation learning about functional programming. I myself get intrigued by all these nice things about functional programming, and maybe I'll give it a try as well in my day to day job. But before we wrap up our conversation, I always like to ask my guests to share. Three technical leadership is done. So, this is something like a message. You want to share to the audience here for them to actually also reflect and maybe
learn from your experience. So, would you be able to share your tree? Technically, the ship is tomatoes? Yes. So the first thing I would say is to read more about nonsensical, things in particular, a lot of the stuff. I've learned this come from reading about architecture, or reading about systems thinking or reading about other engineering books, right? Mechanical, engineering or something. It gives you insight into your problems again, getting out of your bubble and getting
feedback. One of my favorite books is the Design of Everyday Things by Don Norman. None of my favorite books is how buildings learn by Stuart Willie. Some books. They're not about programming at all. But you can see, they really do apply to program. Another piece of leadership. Wisdom is literally what we just talked about. Yes, to be careful about focusing, only on efficiency of focusing on metrics. Make sure you're building. The right thing.
Another thing is, getting out of the house, talking to people listening to people, and don't think the, you know, all the answers something which has been very useful to me in this area is actually reading about anthropology of all things. So, anthropologists, their whole job is to listen to people. And to learn things in a non-judgmental way again recent popular and apology and I think it will help you be a better programmer, just gonna interesting.
And the third one I would say is again in the whole Spirit of getting outside. Your bubble is being a poly got programmer and learning different paradigms. It just expanding your mind in any way possible. It's so easy to focus on one thing and just do one thing all the time. The other ways of doing that is to stop burnout. I did have a big problem with burnout and I think other people have problems with Not. And one way to stop burnout is to have fun.
Fun is really important. It's not all about work. And so do things that are fun for you. And if that's learning a new programming language or expanding your horizons and other areas. I just think that's a really important by this. The whole thing is not just about your job. It's about your whole life. So that's my last bit of wisdom for you. Thanks for plugging in the burnout message. So, I think you have many people probably also experience burnout with the insurmountable amount
of work as video. Is this internet? Is everyone can reach everyone very easily. So Scott for people who want to continue the conversation with you any place. They can find you online. I'm only pretty much on Twitter. Not trying to avoid social media, but I am on Twitter and my Twitter handle is stop lotion. That's another piece of my study of social media. If you want to be protective. That's actually a very good thing about Effectiveness versus efficiency. They measure stuff by
engagements. They want to get you angry, the more Angry, you get them all clicks again. I do think it's very unhealthy spend a lot of time. Social media. I just don't think it's good. So yeah, stay off social media and focus on the real world. There are. Yeah. Yeah. Yeah. Thanks for that message. So Scott. Hope you enjoyed this conversation. Thanks again for sharing your knowledge.
Thank you so much. Thank you for listening to this episode and for staying, right until the end if you highly enjoyed it, I would appreciate if you share it with your friends and colleagues who you think would also benefit from listening to this episode. And if you are new to the podcast, make sure to subscribe and leave me your valuable review and feedback. It helps me a lot. In order to grow this podcast better.
You can also find the full show notes of this conversation on the episode page at technology Arnold death website, including the full transcript enter. Resting courts and links to the resources mention from the conversation. And lastly, make sure to subscribe to the shows mailing list on pack leader. No dot f to get notified for any future episodes. Stay tuned for the next technology. No episode. And until then. Goodbye.