4:52 how to *see simple solutions* in complex problems 5:28 try not to be distracted by lots of other things going on 5:34 *find the essence of the problem* 6:28 Focus on the problem being solved 6:32 take away the *noise* and come up with clean solution 6:50 the other aspect: separation of concerns 7:11 *Thompson's work approach:* 7:16 *whenever you saw any sign that piece of code you are working on is trying to do two things, immediately try to refactor the code* 7:52 Thompson's comment: I likes to *generalise* 8:13 I have very limited brain capacity, unless you isolate it, you can't really focus on that 8:28 the really important things we learn when we are young is *filtering to remove the noise from everything through what is working out and what is important* 10:56 what makes a good software developer 11:48 *we could be good at writing code in a language we haven't used before* 12:03 12:22 Martin Thompson: *doing a few things really well is quite powerful* 13:24 what are the things that you value in the people you (Thompson) admire 13:50 answer: *curiosity* 15:04 *growth mindset* 15:15 senior people won't accept change 17:39 *fundamentals don't change quickly* 19:59 about *straight-line programming* 21:28 22:20 fundamentally it is about feedback 23:05 25:43 what is true expertise and specialization 25:50 being very sensitive about *feedback* 27:43 incremental development 28:47 appreciation on *embrace change* from Kent Beck 30:52
As someone who has been working from home since March of 2020 due to the pandemic, having a stimulating conversation around software engineering has become a rare occurrence, and I fear I am worse for it. I am grateful to you sharing these conversations with me so that I can be engaged and connected with a subject that has been my lifetime passion, even if only for the occasional hour or two. My fervent hope is to someday work in an environment where these sorts of conversations are happening all around me, and encourage me to continually reevaluate my positions and practices. And, with any luck, I'll get to become an ugly, grumpy old software developer of value myself.
Patrick! I couldn't agree more! Exactly the same scenario and hopes for the future here too. Would be awesome to work with Trisha, Dave, Martin and Dan North at some point.
I understand what you mean. But I am aware remote isn’t for everyone but until we all get what we want, the organisations need to have a remote friendly culture that understands that such avenues of discussion could go online. Discord rooms… tech chatter zoom.. extensive pairing. There are ways
I've known of Martin for about a decade now and I have tried listening to a few talks of his, even live. He seems really knowledgeable, but this talk really helped me with hearing what he has to say. Usually he speaks really quick about really complex matters. You are a star, Martin! And thanks for these conversations again, Dave.
32:30 how to fix performance problems in big organisations 37:48 modeling 38:17 42:16 The big failure Thompson often see: technologiests try for perfection 42:28 important is *try to have a protocol that deals with the imperfection* 51:57 mechanical sympathy 52:28 53:49 with software 54:36 the point 59:30 about Reactive Manifesto
These sessions (and or course what I would call the "mediums" and "shorts") are for me a sign of what is missing all too much in our industry - taking the time, even a little time, to step away from the tools and the coalface; pause and encourage thinking and conversation about the bigger picture. Over the past 5 years or so, I've evolved my role into one that encourages conversation, discussion and a lot of the time common sense, often supported by anecdote, often supported by analogy to the real world and what matters. I think I've become a better engineer as a result, and I'd like to think that it's an enabler for those I work with to do the same. I encourage everyone I meet to check out this channel, and even if they don't agree with some of the material, use it as a basis for debate. Thankyou!
Hearing the term Mechanical Sympathy a few months back lead me to follow Martin and some of the open source projects he's worked on. Can't wait to watch this!
Really decent conversation - was fantastic listening in. I'm just going to keep investing in good habits and soaking in these bigger ideas. Will work on feeling more comfortable without perfect. Interesting bit on straight line programming/problems solving. Proper chunk to chew on.
Thank you for these conversations. I am learning how to name my intuitions and refine or correct some unfortunate ideas, but the vocabulary for explaining these ideas to my teammates is priceless.
39:00, I use to take a walk. I call it "thinking the software strategically", in a global, less precise but vast/inspired way, than "tactically", when sitting, writing something precisely. I'm convinced that both are equally important. The hard part is to make your boss understand that a walking meditation is different than leaving the work. But I'm always able to demonstrate every bit of the plan I'm developing. 40:19, the OO in C++ pushes you to this. What is private/complex will remain private. It's not that joke Java does, "hiding" something and at the same time offering a public method for everyone mess with it.
I haven't finished this very good episode yet, but a question comes to my mind as it's a topic I'm thinking about a lot on at the moment. What questions do you ask during interviews to assess whether a candidate is curious, and able to adapt to change ?
Juniors are able to adapt, but also make more mess. But if you interview a senior, I guess you should just discuss some ideas, to see if he is attached to them.
Perhaps not the answer you're looking for, but if you are a paying TH-cam subscriber the app will allow you to listen to videos with the screen off, as if you were listening to a podcast.
I disagree with the perspective about music, but otherwise great video. I make a similar yet differently concluding argument that coding business apps is not really the time for maximum creativity as where music is a more personal place to push the limits. It drives me insane how little thought goes into the topics like coupling, cohesion, various strategies and patterns.. You don't need to even know the "official terms" you just need to reflect on your code and the terms do help you to think somewhat more effectively, but a lot of it can be understood intuitively as well through experience.
It sad seeing developers thinking that every new framework is the next big thing and optimize and make thing work more speedy and its what the software make better and easier to maintain... also it makes me sad how people just put every junk of code on fribtend, and talk about SSR, monorepos, microfrontends like yeah, we need this, while domain logic is rotten on the frontend... If u just follow CQRS and ES u can go far, without bothering u will be your next frontend or backend framework...
Before anyone on my team wants to "shake things up" and move to a new framework or the like, I always ask them to explain what problem this solves. I certainly can appreciate wanting to work with bleeding edge stuff, but that's not always the best solution for a running business.
I bet the "old, grumpy and ugly" comment was made at one of the git flow videos. How hard it is to convince this crowd that you don't need to make a pull request to someone who's sitting 2 chairs away.
4:52 how to *see simple solutions* in complex problems
5:28 try not to be distracted by lots of other things going on
5:34 *find the essence of the problem*
6:28 Focus on the problem being solved
6:32 take away the *noise* and come up with clean solution
6:50 the other aspect: separation of concerns
7:11 *Thompson's work approach:* 7:16 *whenever you saw any sign that piece of code you are working on is trying to do two things, immediately try to refactor the code*
7:52 Thompson's comment: I likes to *generalise* 8:13 I have very limited brain capacity, unless you isolate it, you can't really focus on that
8:28 the really important things we learn when we are young is *filtering to remove the noise from everything through what is working out and what is important*
10:56 what makes a good software developer
11:48 *we could be good at writing code in a language we haven't used before*
12:03
12:22 Martin Thompson: *doing a few things really well is quite powerful*
13:24 what are the things that you value in the people you (Thompson) admire
13:50 answer: *curiosity*
15:04 *growth mindset*
15:15 senior people won't accept change
17:39 *fundamentals don't change quickly*
19:59 about *straight-line programming*
21:28
22:20 fundamentally it is about feedback
23:05
25:43 what is true expertise and specialization
25:50 being very sensitive about *feedback*
27:43 incremental development
28:47 appreciation on *embrace change* from Kent Beck
30:52
@@ruixue6955 tabs or spaces? 😂 thank you for indenting the timestamps!
As someone who has been working from home since March of 2020 due to the pandemic, having a stimulating conversation around software engineering has become a rare occurrence, and I fear I am worse for it. I am grateful to you sharing these conversations with me so that I can be engaged and connected with a subject that has been my lifetime passion, even if only for the occasional hour or two. My fervent hope is to someday work in an environment where these sorts of conversations are happening all around me, and encourage me to continually reevaluate my positions and practices. And, with any luck, I'll get to become an ugly, grumpy old software developer of value myself.
I wish you luck 🤣🤣🤣😎
Patrick! I couldn't agree more! Exactly the same scenario and hopes for the future here too. Would be awesome to work with Trisha, Dave, Martin and Dan North at some point.
I understand what you mean. But I am aware remote isn’t for everyone but until we all get what we want, the organisations need to have a remote friendly culture that understands that such avenues of discussion could go online. Discord rooms… tech chatter zoom.. extensive pairing. There are ways
I've known of Martin for about a decade now and I have tried listening to a few talks of his, even live. He seems really knowledgeable, but this talk really helped me with hearing what he has to say. Usually he speaks really quick about really complex matters. You are a star, Martin! And thanks for these conversations again, Dave.
32:30 how to fix performance problems in big organisations
37:48 modeling
38:17
42:16 The big failure Thompson often see: technologiests try for perfection
42:28 important is *try to have a protocol that deals with the imperfection*
51:57 mechanical sympathy
52:28
53:49 with software
54:36 the point
59:30 about Reactive Manifesto
These sessions (and or course what I would call the "mediums" and "shorts") are for me a sign of what is missing all too much in our industry - taking the time, even a little time, to step away from the tools and the coalface; pause and encourage thinking and conversation about the bigger picture. Over the past 5 years or so, I've evolved my role into one that encourages conversation, discussion and a lot of the time common sense, often supported by anecdote, often supported by analogy to the real world and what matters. I think I've become a better engineer as a result, and I'd like to think that it's an enabler for those I work with to do the same. I encourage everyone I meet to check out this channel, and even if they don't agree with some of the material, use it as a basis for debate. Thankyou!
Great talk, Dave, as usual! Thank you so much for it!
Glad you enjoyed it!
Hearing the term Mechanical Sympathy a few months back lead me to follow Martin and some of the open source projects he's worked on. Can't wait to watch this!
These types of interviews are great. Thanks for the video.
Every time Martin Fowler interviews it's like an ad for working at Thoughtworks, in a good way!
Really decent conversation - was fantastic listening in. I'm just going to keep investing in good habits and soaking in these bigger ideas. Will work on feeling more comfortable without perfect. Interesting bit on straight line programming/problems solving. Proper chunk to chew on.
Thank you for these conversations. I am learning how to name my intuitions and refine or correct some unfortunate ideas, but the vocabulary for explaining these ideas to my teammates is priceless.
Amazing conversation, thanks again for sharing 😊.
Thanx for this conversation with this amasing guest!
What a great conversation! Thank you so much, I feel like I've learned a lot!
“We can’t fit the complexity in our heads” Yes! This isn’t said enough!
39:00, I use to take a walk. I call it "thinking the software strategically", in a global, less precise but vast/inspired way, than "tactically", when sitting, writing something precisely. I'm convinced that both are equally important. The hard part is to make your boss understand that a walking meditation is different than leaving the work. But I'm always able to demonstrate every bit of the plan I'm developing.
40:19, the OO in C++ pushes you to this. What is private/complex will remain private. It's not that joke Java does, "hiding" something and at the same time offering a public method for everyone mess with it.
What a great interview, enjoying it while writing this, I have a long journey to reach your knowledge guys.
I haven't finished this very good episode yet, but a question comes to my mind as it's a topic I'm thinking about a lot on at the moment. What questions do you ask during interviews to assess whether a candidate is curious, and able to adapt to change ?
Juniors are able to adapt, but also make more mess. But if you interview a senior, I guess you should just discuss some ideas, to see if he is attached to them.
Is this series of recordings available as Podcasts?
Is there any plan to make these available as a podcast? Hard for me to find an hour to watch something.
I usually watch at 1.25 or 1.5
Not at the moment
Perhaps not the answer you're looking for, but if you are a paying TH-cam subscriber the app will allow you to listen to videos with the screen off, as if you were listening to a podcast.
Great episode! This series should become a podcast; I'd love to sub via RSS.
Thank you for this great talk !!
Glad you enjoyed it!
Found it! Thanks!!!!! Dave you read my mind xD
Great conversation with Martin. I love these videos. I'd love to see one with John Osterhout at some stage.
And maybe Allen Holub too please
I disagree with the perspective about music, but otherwise great video. I make a similar yet differently concluding argument that coding business apps is not really the time for maximum creativity as where music is a more personal place to push the limits. It drives me insane how little thought goes into the topics like coupling, cohesion, various strategies and patterns.. You don't need to even know the "official terms" you just need to reflect on your code and the terms do help you to think somewhat more effectively, but a lot of it can be understood intuitively as well through experience.
Any favorite book[s] to cover these topics?
Check out this episode 5 Books Every Software Developer NEEDS
th-cam.com/video/RfOYWeu5pGk/w-d-xo.html
It sad seeing developers thinking that every new framework is the next big thing and optimize and make thing work more speedy and its what the software make better and easier to maintain... also it makes me sad how people just put every junk of code on fribtend, and talk about SSR, monorepos, microfrontends like yeah, we need this, while domain logic is rotten on the frontend... If u just follow CQRS and ES u can go far, without bothering u will be your next frontend or backend framework...
Before anyone on my team wants to "shake things up" and move to a new framework or the like, I always ask them to explain what problem this solves.
I certainly can appreciate wanting to work with bleeding edge stuff, but that's not always the best solution for a running business.
wow
Getting to the essence
09:04 Well done!
Old, grumpy and ugly developers are the ones... :)
I bet the "old, grumpy and ugly" comment was made at one of the git flow videos. How hard it is to convince this crowd that you don't need to make a pull request to someone who's sitting 2 chairs away.