<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:itunes="http://www.itunes.com/dtds/podcast-1.0.dtd" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:podcast="https://podcastindex.org/namespace/1.0" xmlns:media="http://search.yahoo.com/mrss/" version="2.0"><channel><title>Laurence Tratt</title><link>https://www.spreaker.com/podcast/laurence-tratt--4628781</link><description><![CDATA[Podcast based on Laurence Tratt's blog]]></description><atom:link href="https://www.spreaker.com/show/4628781/episodes/feed" rel="self" type="application/rss+xml"/><language>en</language><category>Technology</category><copyright>Copyright Laurence Tratt</copyright><image><url>https://d3wo5wojvuv7l.cloudfront.net/t_rss_itunes_square_1400/images.spreaker.com/original/551006e685395268965594a09c1c1c94.jpg</url><title>Laurence Tratt</title><link>https://www.spreaker.com/podcast/laurence-tratt--4628781</link></image><lastBuildDate>Thu, 25 May 2023 16:41:26 +0000</lastBuildDate><itunes:author>Laurence Tratt</itunes:author><itunes:owner><itunes:name>Laurence Tratt</itunes:name><itunes:email>feeds@spreaker.com</itunes:email></itunes:owner><itunes:image href="https://d3wo5wojvuv7l.cloudfront.net/t_rss_itunes_square_1400/images.spreaker.com/original/551006e685395268965594a09c1c1c94.jpg"/><itunes:subtitle>Podcast based on Laurence Tratt's blog</itunes:subtitle><itunes:summary><![CDATA[Podcast based on Laurence Tratt's blog]]></itunes:summary><itunes:category text="Technology"/><itunes:explicit>clean</itunes:explicit><itunes:type>episodic</itunes:type><item><title>How Might Generative AI Change Programming?</title><link>https://www.spreaker.com/episode/how-might-generative-ai-change-programming--53764974</link><description><![CDATA[The use of AI (Artificial Intelligence) techniques, specifically ML (Machine Learning) and its various sub-fields, is changing many fields and undoubtedly will change more in the coming years. Most of us are at least generally familiar with the idea of using ML to identify patterns in data. More recently Generative AI ("GAI" for the rest of this post), in the form of systems such as ChatGPT and Stable Diffusion, has made itself more widely known. Rather than simply classify new data, GAI can, as the name suggests, generate new outputs that conform to the underlying patterns contained in the model. Existing ML systems, in general, and GAI systems particularly, are almost certainly the harbingers of further advances. This inevitably leads to speculation about "what's next?"  From my perspective, the obvious question is: how might ML and GAI change programming? In particular, the rapid advances in GAI have led many to assume that we will gradually do away with programming as a human activity.  In this post I'm going to try and explain why I think GAI, at least in its current forms, is unlikely to be able to fully replace programming. In order to do that, I first look at the relationship between programming and software in a slightly different way than most of us are used to. Having done that, I'll then explain how I think GAI is different than programming when it comes to generating software. I'll finish by giving some very general thoughts about how ML techniques (including, but not only, GAI techniques) might influence how we go about programming.]]></description><guid isPermaLink="false">https://tratt.net/laurie/blog/2022/how_might_generative_ai_change_programming.html</guid><pubDate>Thu, 15 Dec 2022 08:00:00 +0000</pubDate><enclosure url="https://api.spreaker.com/download/episode/53764974/how_might_generative_ai_change_programming.mp3" length="13894625" type="audio/mpeg"/><itunes:author>Laurence Tratt</itunes:author><itunes:subtitle>The use of AI (Artificial Intelligence) techniques, specifically ML (Machine Learning) and its various sub-fields, is changing many fields and undoubtedly will change more in the coming years. Most of us are at least generally familiar with the idea...</itunes:subtitle><itunes:summary><![CDATA[The use of AI (Artificial Intelligence) techniques, specifically ML (Machine Learning) and its various sub-fields, is changing many fields and undoubtedly will change more in the coming years. Most of us are at least generally familiar with the idea of using ML to identify patterns in data. More recently Generative AI ("GAI" for the rest of this post), in the form of systems such as ChatGPT and Stable Diffusion, has made itself more widely known. Rather than simply classify new data, GAI can, as the name suggests, generate new outputs that conform to the underlying patterns contained in the model. Existing ML systems, in general, and GAI systems particularly, are almost certainly the harbingers of further advances. This inevitably leads to speculation about "what's next?"  From my perspective, the obvious question is: how might ML and GAI change programming? In particular, the rapid advances in GAI have led many to assume that we will gradually do away with programming as a human activity.  In this post I'm going to try and explain why I think GAI, at least in its current forms, is unlikely to be able to fully replace programming. In order to do that, I first look at the relationship between programming and software in a slightly different way than most of us are used to. Having done that, I'll then explain how I think GAI is different than programming when it comes to generating software. I'll finish by giving some very general thoughts about how ML techniques (including, but not only, GAI techniques) might influence how we go about programming.]]></itunes:summary><itunes:duration>1158</itunes:duration><itunes:explicit>clean</itunes:explicit><itunes:image href="https://d3wo5wojvuv7l.cloudfront.net/t_rss_itunes_square_1400/images.spreaker.com/original/551006e685395268965594a09c1c1c94.jpg"/><itunes:episodeType>full</itunes:episodeType></item><item><title>Chance, Luck, and Risk</title><link>https://www.spreaker.com/episode/chance-luck-and-risk--53874446</link><description><![CDATA[Every so often, I'm asked to talk about my "career", generally to people younger than I am. I realised early on that the path I'd taken was so full of unexpected turns that it would be ludicrous to talk about it as if it was the result of hard work and deliberate choices. I therefore chose to emphasise how lucky I'd been. Not only did this have the virtue of modesty but it genuinely seemed the most plausible explanation.  However, luck as an explanation didn't get me very far when I looked at other people. The first hint was after I'd seen several instances where, for a given group of people, of a similar age, background, and talents, some ended up being more successful than others. What surprised me was how often my gut feeling about who would go on to do well, or not, turned out to be correct — far too often for luck, mine or theirs, to be a convincing explanation. The second hint was when I realised from reading history that some people were successful multiple times in their lives: it didn't seem plausible to me that all of them had done so purely through luck.  As I currently think of things, there are at least three concepts that interact with each other. At the risk of overloading commonly used terms I think of them as: chance, luck, and risk.]]></description><guid isPermaLink="false">https://tratt.net/laurie/blog/2022/chance_luck_and_risk.html</guid><pubDate>Wed, 15 Jun 2022 08:00:00 +0000</pubDate><enclosure url="https://api.spreaker.com/download/episode/53874446/chance_luck_and_risk.mp3" length="6469942" type="audio/mpeg"/><itunes:author>Laurence Tratt</itunes:author><itunes:subtitle>Every so often, I'm asked to talk about my "career", generally to people younger than I am. I realised early on that the path I'd taken was so full of unexpected turns that it would be ludicrous to talk about it as if it was the result of hard work...</itunes:subtitle><itunes:summary><![CDATA[Every so often, I'm asked to talk about my "career", generally to people younger than I am. I realised early on that the path I'd taken was so full of unexpected turns that it would be ludicrous to talk about it as if it was the result of hard work and deliberate choices. I therefore chose to emphasise how lucky I'd been. Not only did this have the virtue of modesty but it genuinely seemed the most plausible explanation.  However, luck as an explanation didn't get me very far when I looked at other people. The first hint was after I'd seen several instances where, for a given group of people, of a similar age, background, and talents, some ended up being more successful than others. What surprised me was how often my gut feeling about who would go on to do well, or not, turned out to be correct — far too often for luck, mine or theirs, to be a convincing explanation. The second hint was when I realised from reading history that some people were successful multiple times in their lives: it didn't seem plausible to me that all of them had done so purely through luck.  As I currently think of things, there are at least three concepts that interact with each other. At the risk of overloading commonly used terms I think of them as: chance, luck, and risk.]]></itunes:summary><itunes:duration>540</itunes:duration><itunes:explicit>clean</itunes:explicit><itunes:image href="https://d3wo5wojvuv7l.cloudfront.net/t_rss_itunes_square_1400/images.spreaker.com/original/551006e685395268965594a09c1c1c94.jpg"/><itunes:episodeType>full</itunes:episodeType></item><item><title>What Makes a Good Research Proposal?</title><link>https://www.spreaker.com/episode/what-makes-a-good-research-proposal--53998573</link><description><![CDATA[Research is rarely quick: it takes time, people, and (in most cases) equipment to complete. To convince those in control of the purse strings that we should be given the necessary resources to tackle a research problem, we create a research proposal. This might be: a written document, a presentation, or a series of conversations; presented to academia or industry; and aimed at convincing a manager or an external funding agency (or even oneself!).  Whatever the situation, I believe that good proposals share much in common. Unfortunately, many guides I've seen to creating proposals focus, sometimes very cynically, on the quirks or biases, real and imagined, of funders. In contrast, in this post I'm going to try to focus on the ideal core of a proposal, because that has inherent value in its own right, and also because it can be easily adapted to the specifics of a given funder.  By focussing on this core, I'm hoping that I might help you answer two questions: "do I have an idea that's worth asking for resources to tackle?" and "how do I present that idea in a way that other people will best understand?" To make my life easy, I'm going to frame this discussion in terms of "readers" and "writers", though I hope the ideas generalise beyond written proposals, and "funders" as a shorthand for those in control of resources.]]></description><guid isPermaLink="false">https://tratt.net/laurie/blog/2022/what_makes_a_good_research_proposal.html</guid><pubDate>Wed, 08 Jun 2022 08:00:00 +0000</pubDate><enclosure url="https://api.spreaker.com/download/episode/53998573/what_makes_a_good_research_proposal.mp3" length="15250227" type="audio/mpeg"/><itunes:author>Laurence Tratt</itunes:author><itunes:subtitle>Research is rarely quick: it takes time, people, and (in most cases) equipment to complete. To convince those in control of the purse strings that we should be given the necessary resources to tackle a research problem, we create a research proposal....</itunes:subtitle><itunes:summary><![CDATA[Research is rarely quick: it takes time, people, and (in most cases) equipment to complete. To convince those in control of the purse strings that we should be given the necessary resources to tackle a research problem, we create a research proposal. This might be: a written document, a presentation, or a series of conversations; presented to academia or industry; and aimed at convincing a manager or an external funding agency (or even oneself!).  Whatever the situation, I believe that good proposals share much in common. Unfortunately, many guides I've seen to creating proposals focus, sometimes very cynically, on the quirks or biases, real and imagined, of funders. In contrast, in this post I'm going to try to focus on the ideal core of a proposal, because that has inherent value in its own right, and also because it can be easily adapted to the specifics of a given funder.  By focussing on this core, I'm hoping that I might help you answer two questions: "do I have an idea that's worth asking for resources to tackle?" and "how do I present that idea in a way that other people will best understand?" To make my life easy, I'm going to frame this discussion in terms of "readers" and "writers", though I hope the ideas generalise beyond written proposals, and "funders" as a shorthand for those in control of resources.]]></itunes:summary><itunes:duration>1271</itunes:duration><itunes:explicit>clean</itunes:explicit><itunes:image href="https://d3wo5wojvuv7l.cloudfront.net/t_rss_itunes_square_1400/images.spreaker.com/original/551006e685395268965594a09c1c1c94.jpg"/><itunes:episodeType>full</itunes:episodeType></item><item><title>Multiplicity Choices Are Hard to Model and Change</title><link>https://www.spreaker.com/episode/multiplicity-choices-are-hard-to-model-and-change--53845075</link><description><![CDATA[Programming involves continually making choices, whether we realise we are doing so are not. We hope that each choice advances us towards our intended goal of making a program that does what its users will want it to do. However, because the problems we are tackling are nearly always bigger than our ability to fully comprehend them, we often make choices that we later have to correct.  In my experience, the most common type of correction I have to make is where I realise that a piece of information that I'd localised to one component is also required by another component. Depending on the nature of the components involved (functions, classes, etc.), there are various ways of fixing this. Sometimes I might explicitly pass state through all the paths between the two components; sometimes I might place that state somewhere where it's directly accessible to both components. Either way, the changes involved are invariably tedious, and often make the program's structure slightly worse, but are rarely intellectually challenging. It can be frustrating to make such changes in a statically typed language, when one can spend an inordinate amount of time with the program not compiling, but when the program does compile again, there tend to be few if any resulting bugs to fix.  There is, though, a type of correction that makes me break out in a cold sweat: when I have made an incorrect choice about the multiplicity of a piece of information. The changes I have to make are typically far less mechanical, giving me many more opportunities to introduce bugs. In this post I'm going to look at this in more depth in the context of programming languages with static type systems.]]></description><guid isPermaLink="false">https://tratt.net/laurie/blog/2022/multiplicity_choices_are_hard_to_model_and_change.html</guid><pubDate>Thu, 26 May 2022 08:00:00 +0000</pubDate><enclosure url="https://api.spreaker.com/download/episode/53845075/multiplicity_choices_are_hard_to_model_and_change.mp3" length="8107564" type="audio/mpeg"/><itunes:author>Laurence Tratt</itunes:author><itunes:subtitle>Programming involves continually making choices, whether we realise we are doing so are not. We hope that each choice advances us towards our intended goal of making a program that does what its users will want it to do. However, because the problems...</itunes:subtitle><itunes:summary><![CDATA[Programming involves continually making choices, whether we realise we are doing so are not. We hope that each choice advances us towards our intended goal of making a program that does what its users will want it to do. However, because the problems we are tackling are nearly always bigger than our ability to fully comprehend them, we often make choices that we later have to correct.  In my experience, the most common type of correction I have to make is where I realise that a piece of information that I'd localised to one component is also required by another component. Depending on the nature of the components involved (functions, classes, etc.), there are various ways of fixing this. Sometimes I might explicitly pass state through all the paths between the two components; sometimes I might place that state somewhere where it's directly accessible to both components. Either way, the changes involved are invariably tedious, and often make the program's structure slightly worse, but are rarely intellectually challenging. It can be frustrating to make such changes in a statically typed language, when one can spend an inordinate amount of time with the program not compiling, but when the program does compile again, there tend to be few if any resulting bugs to fix.  There is, though, a type of correction that makes me break out in a cold sweat: when I have made an incorrect choice about the multiplicity of a piece of information. The changes I have to make are typically far less mechanical, giving me many more opportunities to introduce bugs. In this post I'm going to look at this in more depth in the context of programming languages with static type systems.]]></itunes:summary><itunes:duration>676</itunes:duration><itunes:explicit>clean</itunes:explicit><itunes:image href="https://d3wo5wojvuv7l.cloudfront.net/t_rss_itunes_square_1400/images.spreaker.com/original/551006e685395268965594a09c1c1c94.jpg"/><itunes:episodeType>full</itunes:episodeType></item><item><title>Programming Style Influences</title><link>https://www.spreaker.com/episode/programming-style-influences--53804805</link><description><![CDATA[If you ever talk to, or read an interview with, a musician, they will inevitably, and quickly, end up talking about their influences. While there is an element of nostalgia to this, perhaps even of acknowledging debts, I see its main purpose as helping spread knowledge about who the most interesting set of musicians are.  In programming, in contrast, we rarely talk about our influences, other than a frequently expressed allegiance to a single programming language. This seems a shame to me, because it denies new people to our field helpful pointers to programmers and systems whose style might be a useful influence.  As a modest attempt to rectify this situation, I'm going to show how one particular system has had a big influence on my programming style over time.]]></description><guid isPermaLink="false">https://tratt.net/laurie/blog/2022/programming_style_influences.html</guid><pubDate>Tue, 10 May 2022 08:00:00 +0000</pubDate><enclosure url="https://api.spreaker.com/download/episode/53804805/programming_style_influences.mp3" length="5085826" type="audio/mpeg"/><itunes:author>Laurence Tratt</itunes:author><itunes:subtitle>If you ever talk to, or read an interview with, a musician, they will inevitably, and quickly, end up talking about their influences. While there is an element of nostalgia to this, perhaps even of acknowledging debts, I see its main purpose as...</itunes:subtitle><itunes:summary><![CDATA[If you ever talk to, or read an interview with, a musician, they will inevitably, and quickly, end up talking about their influences. While there is an element of nostalgia to this, perhaps even of acknowledging debts, I see its main purpose as helping spread knowledge about who the most interesting set of musicians are.  In programming, in contrast, we rarely talk about our influences, other than a frequently expressed allegiance to a single programming language. This seems a shame to me, because it denies new people to our field helpful pointers to programmers and systems whose style might be a useful influence.  As a modest attempt to rectify this situation, I'm going to show how one particular system has had a big influence on my programming style over time.]]></itunes:summary><itunes:duration>424</itunes:duration><itunes:explicit>clean</itunes:explicit><itunes:image href="https://d3wo5wojvuv7l.cloudfront.net/t_rss_itunes_square_1400/images.spreaker.com/original/551006e685395268965594a09c1c1c94.jpg"/><itunes:episodeType>full</itunes:episodeType></item><item><title>Where do Research Problems Come From?</title><link>https://www.spreaker.com/episode/where-do-research-problems-come-from--53759672</link><description><![CDATA["Research" is a much broader term than most of us who consider ourselves to be researchers realise. My occasional interactions with people in very different disciplines (e.g. biology) have tended to involve a series of culture shocks to both parties. Even within computing, there are significant differences between sub-disciplines. These seem to mostly go unnoticed or, at least, uncommented on, which is a pity: at the very least it's worth knowing that the way we do things isn't the only possible way. One of the most surprising differences, at least to me, is where people expect to find the problems that they then work on.]]></description><guid isPermaLink="false">https://tratt.net/laurie/blog/2022/where_do_research_problems_come_from.html</guid><pubDate>Thu, 28 Apr 2022 08:00:00 +0000</pubDate><enclosure url="https://api.spreaker.com/download/episode/53759672/where_do_research_problems_come_from.mp3" length="7682164" type="audio/mpeg"/><itunes:author>Laurence Tratt</itunes:author><itunes:subtitle>"Research" is a much broader term than most of us who consider ourselves to be researchers realise. My occasional interactions with people in very different disciplines (e.g. biology) have tended to involve a series of culture shocks to both parties....</itunes:subtitle><itunes:summary><![CDATA["Research" is a much broader term than most of us who consider ourselves to be researchers realise. My occasional interactions with people in very different disciplines (e.g. biology) have tended to involve a series of culture shocks to both parties. Even within computing, there are significant differences between sub-disciplines. These seem to mostly go unnoticed or, at least, uncommented on, which is a pity: at the very least it's worth knowing that the way we do things isn't the only possible way. One of the most surprising differences, at least to me, is where people expect to find the problems that they then work on.]]></itunes:summary><itunes:duration>641</itunes:duration><itunes:explicit>clean</itunes:explicit><itunes:image href="https://d3wo5wojvuv7l.cloudfront.net/t_rss_itunes_square_1400/images.spreaker.com/original/551006e685395268965594a09c1c1c94.jpg"/><itunes:episodeType>full</itunes:episodeType></item><item><title>Practising Programming</title><link>https://www.spreaker.com/episode/practising-programming--53737948</link><description><![CDATA[When we see a world-class musician flawlessly play challenging music, it can be tempting to imagine that they were always able to do so. A moment's thought makes it obvious that they must have had to spend huge amounts of time practising basic techniques in order to reach that level. One thing that most of us don't consider is that they have to continue spending considerable amounts of time simply to maintain that technique, let alone expand it.  In contrast, in programming, we have only a haphazard notion of how one should go about obtaining sufficient technique to become good enough to write good software; and we have almost no notion of continued practise to maintain or expand that technique.]]></description><guid isPermaLink="false">https://tratt.net/laurie/blog/2022/practising_programming.html</guid><pubDate>Wed, 20 Apr 2022 08:00:00 +0000</pubDate><enclosure url="https://api.spreaker.com/download/episode/53737948/practising_programming.mp3" length="5233558" type="audio/mpeg"/><itunes:author>Laurence Tratt</itunes:author><itunes:subtitle>When we see a world-class musician flawlessly play challenging music, it can be tempting to imagine that they were always able to do so. A moment's thought makes it obvious that they must have had to spend huge amounts of time practising basic...</itunes:subtitle><itunes:summary><![CDATA[When we see a world-class musician flawlessly play challenging music, it can be tempting to imagine that they were always able to do so. A moment's thought makes it obvious that they must have had to spend huge amounts of time practising basic techniques in order to reach that level. One thing that most of us don't consider is that they have to continue spending considerable amounts of time simply to maintain that technique, let alone expand it.  In contrast, in programming, we have only a haphazard notion of how one should go about obtaining sufficient technique to become good enough to write good software; and we have almost no notion of continued practise to maintain or expand that technique.]]></itunes:summary><itunes:duration>437</itunes:duration><itunes:explicit>clean</itunes:explicit><itunes:image href="https://d3wo5wojvuv7l.cloudfront.net/t_rss_itunes_square_1400/images.spreaker.com/original/551006e685395268965594a09c1c1c94.jpg"/><itunes:episodeType>full</itunes:episodeType></item><item><title>The Evolution of a Research Paper</title><link>https://www.spreaker.com/episode/the-evolution-of-a-research-paper--43010184</link><description><![CDATA[How do research papers end up looking the way that they do? I take two papers<br />that I've been involved with and detail the human story behind them and their<br />underlying research. You may also wish to look at the accompanying animations<br /><a href="https://youtube.com/watch?v=1IgtLLPL9GY" rel="noopener">https://youtube.com/watch?v=1IgtLLPL9GY</a> and<br /><a href="https://youtube.com/watch?v=JCamO4P10NY" rel="noopener">https://youtube.com/watch?v=JCamO4P10NY</a>]]></description><guid isPermaLink="false">https://tratt.net/laurie/blog/entries/the_evolution_of_a_research_paper.html</guid><pubDate>Tue, 19 Jan 2021 08:00:00 +0000</pubDate><enclosure url="https://api.spreaker.com/download/episode/43010184/the_evolution_of_a_research_paper.mp3" length="11723679" type="audio/mpeg"/><itunes:author>Laurence Tratt</itunes:author><itunes:subtitle>How do research papers end up looking the way that they do? I take two papers
that I've been involved with and detail the human story behind them and their
underlying research. You may also wish to look at the accompanying animations...</itunes:subtitle><itunes:summary><![CDATA[How do research papers end up looking the way that they do? I take two papers<br />that I've been involved with and detail the human story behind them and their<br />underlying research. You may also wish to look at the accompanying animations<br /><a href="https://youtube.com/watch?v=1IgtLLPL9GY" rel="noopener">https://youtube.com/watch?v=1IgtLLPL9GY</a> and<br /><a href="https://youtube.com/watch?v=JCamO4P10NY" rel="noopener">https://youtube.com/watch?v=JCamO4P10NY</a>]]></itunes:summary><itunes:duration>977</itunes:duration><itunes:explicit>clean</itunes:explicit><itunes:image href="https://d3wo5wojvuv7l.cloudfront.net/t_rss_itunes_square_1400/images.spreaker.com/original/551006e685395268965594a09c1c1c94.jpg"/><itunes:episodeType>full</itunes:episodeType></item><item><title>Stick or Twist?</title><link>https://www.spreaker.com/episode/stick-or-twist--41548528</link><description><![CDATA[All of us have points in our lives where we have to decide whether we<br />should continue down our current path or change to another.<br />As a researcher, I often face a constrained<br />version of this problem: should I continue on my current research path<br />or change to another? For a long time I wasn't aware that I was being faced<br />with such decisions; and, when I did become aware, I wasn't sure how best to<br />make a decision. Over time I've realised that a simple "stick or twist?"<br />heuristic mostly works well for me. I don’t claim that anything in this article is<br />novel, nor do I think I'm describing an approach that’s applicable to every<br />situation - but it might provide some useful food for thought.]]></description><guid isPermaLink="false">https://tratt.net/laurie/blog/entries/stick_or_twist.html</guid><pubDate>Wed, 07 Oct 2020 08:00:00 +0000</pubDate><enclosure url="https://api.spreaker.com/download/episode/41548528/stick_or_twist.mp3" length="9395600" type="audio/mpeg"/><itunes:author>Laurence Tratt</itunes:author><itunes:subtitle>All of us have points in our lives where we have to decide whether we
should continue down our current path or change to another.
As a researcher, I often face a constrained
version of this problem: should I continue on my current research path
or...</itunes:subtitle><itunes:summary><![CDATA[All of us have points in our lives where we have to decide whether we<br />should continue down our current path or change to another.<br />As a researcher, I often face a constrained<br />version of this problem: should I continue on my current research path<br />or change to another? For a long time I wasn't aware that I was being faced<br />with such decisions; and, when I did become aware, I wasn't sure how best to<br />make a decision. Over time I've realised that a simple "stick or twist?"<br />heuristic mostly works well for me. I don’t claim that anything in this article is<br />novel, nor do I think I'm describing an approach that’s applicable to every<br />situation - but it might provide some useful food for thought.]]></itunes:summary><itunes:duration>783</itunes:duration><itunes:explicit>clean</itunes:explicit><itunes:image href="https://d3wo5wojvuv7l.cloudfront.net/t_rss_itunes_square_1400/images.spreaker.com/original/551006e685395268965594a09c1c1c94.jpg"/><itunes:episodeType>full</itunes:episodeType></item><item><title>Alternative Sources of Advice</title><link>https://www.spreaker.com/episode/alternative-sources-of-advice--41548529</link><description><![CDATA[With slowly increasing frequency, I am asked for my advice on life or careers,<br />or something similar. Let us put aside worries about this sign of my increasing<br />decrepitude or the poor taste that some people show in those from whom they<br />seek advice. The brutal truth is that most of the advice that I've received as<br />an adult - nearly all of which has been well intentioned - has not been right<br />for me. I therefore assume that any advice I might give others would be equally<br />wrong, and so I try and avoid doing so. In this blog post, I will try to<br />enumerate the problems I have with advice as it is commonly given and look at<br />one way that we can do things differently.]]></description><guid isPermaLink="false">https://tratt.net/laurie/blog/entries/alternative_sources_of_advice.html</guid><pubDate>Wed, 06 May 2020 08:00:00 +0000</pubDate><enclosure url="https://api.spreaker.com/download/episode/41548529/alternative_sources_of_advice.mp3" length="11867961" type="audio/mpeg"/><itunes:author>Laurence Tratt</itunes:author><itunes:subtitle>With slowly increasing frequency, I am asked for my advice on life or careers,
or something similar. Let us put aside worries about this sign of my increasing
decrepitude or the poor taste that some people show in those from whom they
seek advice. The...</itunes:subtitle><itunes:summary><![CDATA[With slowly increasing frequency, I am asked for my advice on life or careers,<br />or something similar. Let us put aside worries about this sign of my increasing<br />decrepitude or the poor taste that some people show in those from whom they<br />seek advice. The brutal truth is that most of the advice that I've received as<br />an adult - nearly all of which has been well intentioned - has not been right<br />for me. I therefore assume that any advice I might give others would be equally<br />wrong, and so I try and avoid doing so. In this blog post, I will try to<br />enumerate the problems I have with advice as it is commonly given and look at<br />one way that we can do things differently.]]></itunes:summary><itunes:duration>989</itunes:duration><itunes:explicit>clean</itunes:explicit><itunes:image href="https://d3wo5wojvuv7l.cloudfront.net/t_rss_itunes_square_1400/images.spreaker.com/original/551006e685395268965594a09c1c1c94.jpg"/><itunes:episodeType>full</itunes:episodeType></item></channel></rss>
