In the tech space, we have a certain responsibility, we are
creating things that crash. We are creating things that
don't work. It's a reminder for me that, you
know, when we do with software, when we develop it, and when we
deploy it, we are part of a larger system where our failures
in software are no longer about us.
There are about other people. They become very visible in a
world that runs on software. That becomes a problem point.
Hey everyone. My name is Henry Surya, we
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 to all of you, my friends and my listeners, welcome to the
package, you know, podcast the show where you can learn about
technical leadership and Excellence from my conversations
with great thought, leaders in the tech industry.
If this is your first time listening to technology, you
know, don't forget to subscribe and follow the show on your
podcast app and on LinkedIn, Twitter and Instagram and to
support my journey. Creating this podcast, subscribe
as a patron at technology. Not deaf / Patron, My guest, for
today's episode is Carolyn honey.
Carolyn is a consultant writer and speaker on software
development and he has written and edited several popular
software development books. In this episode, Carolyn shared
his three favorite things. Every software engineer, should
know, based on the two books, he edited 97 things.
Every programmer should know, and 97 things.
Every Java programmer should know, he explained the
importance for developers of taking an occasional break when
working on deeper. Work putting code comments,
wisely, and using testing not just for checks but also for
communication tool. Carolyn also brought up some
Timeless software development Concepts that every developer
should learn from the past such as cohesion coupling and code
quality. He also explained why he becomes
associated with public software failures, widely known as
Carolyn, hennesy screens and how the trend started in the
beginning towards the end, Carolyn shared his views on why
it is Important for developers to improve public, speaking
writing, and having more compassion towards each other.
I really enjoyed my conversation with Kathleen, Kathleen
emphasized, many essential things.
Many of us software Engineers, tend to neglect, especially on
some Timeless Concepts such as cohesion, coupling and testing.
And I really like his explanation that many things in
software development are about communication.
And not always about the code. And its correctness.
If you find this episode useful, please help, share it with more
people. So many more of us can also
benefit from listening to this episode.
Also, Leave this podcast of five star rating, and review on Apple
podcast and Spotify. It will help me a lot to make
this podcast easily, discovered by others.
Before we continue to the conversation with Carolyn.
Let's hear some words from our sponsors.
Today's episode is proudly sponsored by skills method.
The global community and events platform with more than 100,000
software professionals here members, can organize their
learning experiences around the technology topics.
They 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 whether 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 easy. See to keep up with the latest
tech Trends. Hello everyone.
Welcome back to another new episode of the pycnogenol
podcast today, I'm very excited. I met someone who I went to a
talk in 2013, which was a jail. Singapore.
And I saw his talk very inspiring.
I think he talked about architecture back then and since
then I followed some of his talks, I mean he's very
influential in the tech industry.
A lot of keynote speakers and things like that and he wrote
some books as well. So if you know Oh, this series
called 97 things haven't actually help to edit a few
books, 27 things, every programmer should know, and 97
things. Every Java programmer should
know. So Carolyn really looking
forward to have this chance to talk to you today, and welcome
to Tech to Juneau. Thank you very much for
inviting. Me Henry, great to be here.
So, Carolyn I always ask my guests to share your career
Journey. So make sure to maybe mention
some highlights or turning points that you think are
interesting for the listeners to learn from Yeah, so I didn't
know that I was going to end up in software.
I don't think that was part of the plan, maybe something
technological, but I didn't know that either.
My first degree was in physics and I realized part way through
that. Although I had some interest in
the sciences and physics, this was not the direction I wanted
to take. And I had been reading a lot of
stuff on at the time, Ai and just learning about all kinds of
interesting things to do with computers.
It was a good distraction. I kind of finish my degree.
I had no idea what I was going to.
Do in a friend of mine said, Hey Kevin, I've just gone for a job
interview at a company and they're looking for programmers
and you don't have to have a programming experience and I
thought, well, I've got some programming experience from my
degree and also being interested in home computers originally, I
just went along and kind of that got me into this.
And by the most interesting things, the work itself was not
necessarily that interesting. Although hindsight I think there
were some really interesting opportunities.
What was interesting is that my boss had this bookshelf, this
huge book shelf of books that Were absolutely nothing to do
with anything that we were working on and I started reading
up on computer science and programming languages.
I think programming language is absolutely fascinating.
I had no idea at this point. I was just looking through this
stuff and this is great. I really into this absolutely
fascinated by this. And after a couple of years, I
decided I want to take a different direction.
I'd started learning about object, orientation and coming
across these ideas. And I thought I want to do
something else, but I decided actually I do a master's degree
in parallel computers. Systems, which happened to have
some of the AI stuff. I was interested in, but I also
realized it was a lot of good programming Paradigm stuff in
there that kind of sealed the deal for me is like, yeah,
you're going to be in software development, that's the way it
goes. And so, I ended up working after
that procedure is companies, typically was kind of back-end
or embedded type stuff. Although I did do a whole lot of
UI stuff relatively early on, but eventually there came to be
a point where I was getting really frustrated with company
politics. I think a lot of people work in
environments where I was just like, yeah, I'm enjoying the
Yes, there's my colleagues. This is all good.
I'm enjoying all of the technical challenges, but the
politics and the people stuff can kind of weigh you down.
And I reached a kind of Crossroads thinking well, what
am I going to do with this? You know, I've got this
interest, but I didn't feel like where I was working was working
out for me. I would far too often come into
conflict with company called sex and I eventually decided, okay,
I'm going to take a completely different direction.
I'm going to go into training and consultancy, so I joined
another fertilizer. I'd been doing some Contracting
at that point. Which is kind of a good way to
seal yourself off from craziness up to a point but that's where I
really discovered, I really enjoyed.
I really enjoyed when I was a team leader, I really enjoy the
kind of like the connections that I was making these people.
I enjoyed the use of white board discussions.
I enjoyed writing, I'd written a number of Articles and I was
writing more and more articles and this was kind of this
opportunity to use your knowledge and frame it
differently and it also changed the way that I thought about
software development as well when you Communicating it, you
start realizing the, you know what some of those really great
ideas you had, they don't sound so good when you say them,
they're great in your head. When you try to explain the to
other people, you get a very different feedback loop.
And I think that's really where I started appreciating much more
the social side but also how much I got out of communicating
things. So from that point on, I knew
that that was going to be part of my work.
That's how I thought about stuff.
That actually the process of training people had allowed me
to be a better programmer and I found so many different
connections that and Really, I decided many years ago, I would
go independent fully autonomous and I've been that way ever
since my work is kind of flowed between kind of workshops and
training and consultancy and coaching and writing.
So I get to choose a lot of the mix of what I'm doing.
I went to a, there's Betty major turning point since then.
Because for me it's all one big flow of many possibilities
sometimes, one month is the same as the next and other times.
I might be doing something completely different.
I guess the only other thing that really changed was the
pandemic. She completely online which has
allowed me to change the way that I run an offer things like
workshops training and also talks they tend to do a lot more
specific talks for companies these days sometimes in person
but a lot of the time online and that I find for me that's always
a great discovery against that communicating things.
I tend to learn a great deal by trying to communicate my
thoughts. In other words, I thought I knew
something and then I tried to communicate it and I normally
see more opportunities in it. More possibilities all the
flaws. In what I've just I said become
much more obvious. So for me, that is part of what
kind of keeps me going. It's not going to be the same
for everybody, but for me that's one of the things that unlocked
some of the more interesting parts or software development.
Thanks for sharing your story. I think it's pretty interesting.
When you mention about finding Fascination in writing speaking
and getting feedback loops, I always find you pretty natural
in speaking and engaging with audience.
I think that's really cool and I think for those listeners who
also aspire to be not just a coder, Later on we will discuss
how you can follow K Journey, maybe to write more and speak
more in order to get that social aspect of the software
development as well. Maybe, let's start with some of
the things that you edit it from your books, 97, things, every
programmer should know, maybe if you can distill three to five
key lessons, because we won't be able to cover 97 thing's for
sure. What would be.
Some of your advice for developers here, what things
they should know what God said it should avoid, or maybe just
some things that you think they should.
A should you know, dive deeper? Yeah, I think that's an
interesting one because obviously there are 97 things in
each of the every program should know and every Java program
should know. So therefore what are three or
five that I would choose. It's difficult to pick favorites
but actually what I might do. The easiest way for me to kind
of pick a few is just a think of the ones that I've used in the
last week or directed people towards in the last week.
Here we are 20 22.97 things. Every program should know that
book was published in 2010 and 97 things every child program.
She knows probably In 2020. But the funny thing is the first
books 12 years old. Now and 12 years is a long time
in software development and yet I keep going back to the pieces
of advice in that book because they are relatively Timeless,
you won't find mention of microservices, but you will find
mention of functional programming, you will find
mention of caring about your dependencies in your structures
and the rest of it, the names that we use for various things
have shifted, but actually a lot of the interests and good ideas
are surprisingly stable and timeless.
So I often use these in my tools because I think it's also good
to point out whenever I'm talking I tend to regard what
I'm doing. As I'm a Clearinghouse
everything, I teach or communicate, typically came from
somebody else and if synthesizing these and put
together. So I think it's always really
kind of important to highlight that in the last week.
One of the ones that I've certainly referred to is
birkhoff naugles. Piece in 97 things.
Every program should know. He also contributed a Java
program should though, but the one that I always come back to,
in 97 things, every program should note is the Entitled, put
down your Mouse step away from the keyboard.
I like this because it works on two levels.
First of all, there is the general advice of the peace
which is exactly captured in its title.
The idea is that sometimes when you've been working, when you've
been beating your head against a problem too closely, you've
exhausted everything that you can do at that level that
detailed level, where you are concentrating intensely looking
at the screen that line of opportunities run dry.
Otherwise you have solved it, you've done everything.
Nothing you can at this level and doing more of it is not
going to help. So therefore this point thing
you have to do is disconnect disengage go do something else.
And I think that the lesson of this is psychological in the
sense that this tells us a little bit about how the brain
works. That you are very much in this
kind of focused style of thinking, which is not
necessarily creative, you may be focused on detail.
You'll try to understand how things fit together, very
detail-oriented, very procedural and that flushes out certain
Also, problems and issues. But the associative connection
oriented style of thinking, the more lateral thinking, that
doesn't normally happen at the same time or you can't force it
on. And that I think is also a huge
reminder to us because I think many people work in environments
where the most common thing I get asked.
What if we don't have time, we don't have time for this and
it's just like, you know what you do have time.
It's just that the thing, you're not good at and I don't mean you
as picking somebody else. I mean, you as a human being
Being and not necessarily good at is knowing how to use your
time. This is not a strength that we
have with very poor at this. Then actually, if you want to
save time then stop working. This is counter-intuitive.
Some people, I know I need to put in more hours.
I need to put in two more hours on this problems.
Like actually you're probably going to solve that problem by
not working on it. Go and do something else.
The solution will come to you you know five minutes you'll
have solved it you can't tell. When that five minutes is going
to be, maybe it's while you're having breakfast, maybe it's why
sharing, maybe it's while you're on the subway, on the way home,
the point there is that Once you've let go, your brain is
just no longer concentrating on that and the ideas will connect.
You got to kind of trust the fact that you're not trying to
control the process that it'll happen.
So that's the kind of the broad message was peace, but I also
like his peace because he shows a concrete example where he
experienced this, it's a piece of code and he shows us the
tidied up version. He shows us the piece of code
after it's been reflected and it's really messy and
complicated and procedural. He does the right thing but then
he steps away and realizes Know what?
This is just a pattern matching problem.
I'm trying to approach it with kind of ifs.
That's what I tend to see in a lot of code.
Oh yeah you're trying to solve the problem by using a lot of
ifs. It's this otherwise it's just
like there's something simpler waiting to happen and you just
don't know what it is. He reveals that it's one of
those things like take the foot off the pedal and a lot of
things get solved. So thinking is important in
software development therefore you got to learn there are
different ways of thinking and some of those are not about
pushing yourself there. Exactly about pulling yourself
away, the exact opposite. So I really like that piece
because it has a detailed technical message showing us
perhaps where unmanaged technical debt comes from and
how code can become complex through no fault of our own.
But it also shows us the relationship that we have with
time and our attention and Co so that one I think for me always
sticks out as a, quite a big one.
Another one I'm going to pick on although this is a little bit
self-serving because I wrote it, but it seems to come up a lot in
the last couple of weeks, the title tells you everything, it
is a piece on comments, comment only what the code cannot say,
the whole question. I have comments is an
interesting one in software because comments are code.
That is not code. You know, as they don't have a
formal syntax, they are code, that is not cone which means
that they don't get checked for correctness.
Most comments are wrong and if they don't start out that way,
they become that way. But because they don't trigger a
compiler error and they don't fail a test and they don't cause
a bug. Our attention is not drawn to
them. So they don't have a process
that causes us to correct. If you broke the build, you're
going to go and fix something, okay?
That's the thing. But if your Punctuation is a
Messy and your comments. That's not going to cause
anything. If you're stating things that
are factually incorrect, that's not going to cause anything.
And so people have these various different philosophies of
comments, and it's an interesting one because it's a
kind of like we have this absolute freedom.
Absolute freedom is a quite a frightening thing.
People don't know what to do with it.
And so we have these observations about, okay?
Your comments, become out-of-date more rest of it.
But we also have this desire to be helpful.
We want to help people. There are two extreme schools in
this one school. People is like, don't comment
your Code, all comments are bad. Always kind of star.
Your code should be self documenting from one
perspective, I look like, I lean a little bit more towards that
camp but my system of belief on this one is slightly different
to the way that these are articulated.
The idea is, I don't think that all comments are necessarily
bad. That's not the useful position.
I also don't think that saying that you shouldn't have comments
in automatically improves your code.
Although I've seen coat which would be improved by deleting
the comment, I don't think it's an automatic consequence.
So there's a lack of nuance. For most devices, like don't
comment your code. Lacks intelligence Nuance, you
want to understand why? But at the other end, the
common, everything crowd is just like it's just noise.
And I've seen far too many examples of that fail.
So, the way to understand this is don't comment what the code
already says, that's a fairly standard piece of advice, that
tells us some of the things we don't want to do.
But there's a really interesting connection here between
understanding what it is that you're trying to communicate.
So for me there's a deep message here.
What am I trying to say? How am I communicating and what
is then said in your code and for me that's the driver is like
what can I say, why would I want to put a comment here?
I would want to put a comment here because the code is not
obvious. It doesn't say what I, it's not
obvious, what I'm saying. Okay.
So recognize that as a neat, that doesn't mean you need a
comment yet, it just means, oh, there's a communication
shortfall between what I'm looking at on the screen.
What I've just created perhaps, or what somebody else has
created. There's a Caishen gap between
that and the thoughts in my head, what I feel.
I want communicate. We're not saying everything that
we want to, so that's a good first candidate for baby why we
want to comment, but don't do it just yet.
If what is it that you would want to say and then suddenly
say hang on. Could I say that in the code?
Could I say that in the thing that is going to get checked?
Or am I just apologizing for the code?
In other words, if I've got a variable a and I put a comment A
is for altitude, then I'm In for the code.
Why don't I call it altitude? There you go.
I've got a better name for it and I was, I can say it in the
code. If I got a big block of code and
I've got a big banner up at the front.
Let's go like, well why is this not a method?
Because that's what a method is. It's a named block of code.
You know, when we see large methods that are hundreds, if
not thousands of lines long, there are two thoughts.
Here is just like, why we not factoring this out into methods?
That's what therefore, they are blocks.
That is what a method is fundamentally.
It is a catcher block with a name and a Clear set of
parameters. And if that deserves, an
appropriate, javadoc style Comet, then that's fine because
that comment is for external documentation, it's not for the
reader of the code, it's for the user that belongs to
documentation, says, post being something that is in line with
it. So that leads to the advice.
Comment, only what the code cannot say, not what the code
does not say, but what can't it say, in other words, what can I
do to get to the point and that the way I often motivate people,
imagine you didn't have comments in your language now, right?
Code, write the code if you didn't have God.
Right now you've done that. Is there anything else you'd
like to say to the reader? You've said, everything you
possibly could. Whatever is left, is the thing
that cannot be easily communicated that you couldn't
say in the language. Now, you have your comments back
again and at that point, your comments increase in value.
That's the key to have things that are of value.
One of the ways we drive value is scarcity.
A kg of iron is worth significantly less than the kg
of gold. Although iron is technically
more. Useful, as a material, the
higher value, gold is defined by scarcity.
If you had as much gold in the world, as there is iron, a kilo
of gold be worth a lot less than a kilo of ironing.
Not a very useful substance in that quantity.
So the idea there is scarcity helps to find the values.
You put comments everywhere they worth nothing.
So for me, that's something I find.
I'm communication to people. It's much more balanced way of
thinking and it caused me to think about how do I value
these. What do I think?
Is a useful way of thinking about this?
Probably a third piece. I don't think there's a specific
therapies except that I would say, what's interesting in both
of the books that 97 exemplary program should notebook.
And then I've said, things, every Java program should do
book is there is a really strong emphasis people have really
consistent on testing. I got a lot of pieces and very
well, written pieces on test this idea that as part of the
coding cycle, that is part of the fabric of software
developers, not something else, it's not there as software
development and there is testing, testing is a part of
software. Element that is a consistent
view that has been with us for a while.
But perhaps I think there is continued scope for improvement
on that. I think we can always do that.
We can always do that better. And in fact there's a really
nice piece in 97 things, every Java programmers should know
from research Van Dyke on this where she really breaks down the
value of communication in testing.
So you can actually find all the book items online, somebody
moved in to get books. I intentionally created book
with a Creative Commons license, so that people could do that.
So there's a gift box version of it. 497 things every Java
programmer should know. We took submissions through
Medium as well as through a kind of Google form style thing but
all the medium stuff is still online.
Including use testing to develop better software Faster by Marie
Van dijk, Marie breaks down really.
The intention about what makes a good test.
That's the other thing that I think is really important is the
idea again. Think of your testers,
communication tests are not merely checking anybody who's
kind of communicating. Oh yeah, tested.
Just checks, you have totally missed, how to do testing in
software, but sure, they have value as checks, but that's not
the full story. That's kind of the sound of one
hand clapping. It's like, it's part of the
story, but you really got to understand some Act of
communication that makes the story.
Much, much bigger it reframes. The way you think about tests
tests are not merely checks. They are expression of
intention. There are four of communication,
they're kind of an opportunity. Not only for somebody else to
understand what's going on. They also an opportunity for
whoever's writing the test, whether you're doing that on
your own as a pair part of a mob of trying to all what are we
trying to say here? And that's actually the hardest
thing mechanics of the test or something.
I think we get drawn into a lot but actually that's not the hard
part. The hard part is one of you
actually trying to say here that is the challenge.
So that for me is the most important.
Thing about testing tests are not second-class citizens, they
are an opportunity to express something that perhaps again,
you could not say in the code. So this Next with what I just
said about comments, is we have all these other means of
communicating or intention and again sometimes I might be
writing a piece of code and I say okay here's the thing.
I couldn't say always not easily said in the code and I might
start writing a comment. I said well maybe if I showed
you an example of interaction. What a great idea.
An example of interaction. Let here's piece of example code
it shows the interaction that's of interest and just to make
sure that we're all good. I'll put a bunch of assertions
at the end. Bingo you've got to test.
You've communicated Tasted intention, you've created the
test from understanding that you are trying to say something that
was not otherwise easily set. So I for me, these for part of a
thinking system sets, I know it's very hard to pick favorites
from the 97 times to. I don't know whether there are
any overlaps from the two books just to summarize.
The first things about being detached from working intense
for a long time, right? So sometimes we as developers,
we Crack the Code, we just rash and we just deliver features of
a bitches sometimes when you are in this Kind of coding
mechanics. We tend to probably don't see a
pattern that we can improve in terms of maybe problem-solving.
Exactly looking at the code and things like that or even ideas
how we can do things better. And the second one is about
common, don't put comment if the code can already say, is that.
So I think it's really crucial because sometimes I still see
comment. Like you mentioned.
Write the comment is totally wrong.
The code, has evolved Maybe by multiple people editing it so
the comments did not get updated.
So I think it's really crucial. Don't put comments if you don't.
Have to. And the last one, I think is
very important testing. I think almost everyone is
talking about testing testing, tdd testing as a practice and
what you mentioned just now is about communication, or it's not
just for validation. I think there are still some
examples that I saw from time to time that people just put
validation as the main intent of test.
But the test names, the test cases, all the things that are
inside the test, probably as just a random variables and
things like that. And it makes it hard for people
to maintain and update over the Time.
So I think thanks for sharing that test is communication.
And again, that idea comments is communication.
If we regard what we're doing in creating a code base for
creating a system of knowledge, and we want to communicate that.
And when you start looking at it like that, you suddenly realize
what you do want to do. But also what you don't want to
do, and we also realize the half-truths, in other words.
Sure, test, do validation and verification.
That's a part of their story, but that's not the whole of
their story, they can tell us a lot more.
And I think that idea, when we start stepping back and going,
oh, yeah, it's Just a mechanical thing.
It's an intention setting. So one thing that I noticed when
you mention in the beginning before you grief these three
things is you mentioned the books have been written like 12
years ago and there are still some things that are Timeless
and this is something that you mentioned before.
We had this talk that we can all learn from the past, there are
many things that stays relevant there, many things that stays
true even till now. So what would be some top key
lessons from the past that you think we as programmers covering
the old programmers? And new programmers should know
what are the things from the past are still stays relevant.
So let's go back to origin story.
So I read a lot of books. When I got into software
development was the end of the 1980s, which is quite a long
time ago and the world has changed a lot.
Since then the books that my boss had were from the 1980s and
the 1970s and I read a lot of these things so they were kind
of already historical all of them.
But what I found was a surprisingly Timeless quality to
some of the books and their advice.
So I was brought up on a lot of ideas about how to think about
code in terms of cohesion and coupling, we are losing these
message. People have got distracted by
guidelines that don't emphasize these properly or have watered
them down in a particular way. It cohesion, and coupling
cohesion, the degree to, which things cohere and naturally hold
together. Now, sometimes people kind of
psycho wasn't that the single responsibility principle, well,
not really it. They kind of cohesion, it's not
about responsibilities. The original quote, has the
single responsibility principle is actually about single reason
for Change has nothing to do with responsibilities, so naming
is hard. We know that single reason for
change. What does that actually mean?
It does really mean much. It's a kind of cohesion, but
there are other kinds of cohesion.
So why people have got fixated on one, kind of cohesion, to the
exclusion of others. I don't understand.
We should be teaching people about cohesion.
And then again, if we look at things like the solid principles
or many of the principles people describe, they don't talk about
coupling. In other words, dependency
management, the degree to which things connect and we have far
more dependent And it sees in code bases.
Now, for some people when they talk about dependencies they are
talk about. External dependencies, you sort
of say, oh dependency management.
Yeah. And they show you all their
external dependencies. Like yeah, he got half a million
lines, count. It I'm talking about the
dependencies in the code base, not just outside the code base.
Some people are kind of ended up kind of losing track of that.
So coupling cohesion, these are ideas in the 1970s.
They do not go away. They are fundamental, there's a
lot of things. People have been trying to push
as fundamental. Those are coupling, cohesion are
for us. They are for For our benefit, by
the way, the code doesn't care. The compiler is just going to
compile what you give it. It doesn't care about coupling
and cohesion. The processor you're running on
doesn't care about coupling, cohesion.
It's just going to execute what you say company, cohesion, for
our benefit there. So that we understand so that we
can maintain so that we can build.
That's what that's about. So for me, these are really old
ideas and more appropriately Timeless ideas.
They don't go away, we should be building on them, not trying to
muddle a message there for paying attention to.
This stuff is important. And I think that's A lot of
people are trying to do when they reiterate all try and
reframe these, they're trying to get that message out but then,
there are other things that I think we haven't paid attention
to go quality. So these days, the popular way
of framing things in terms of issues of Co quality, is in
terms of technical debt. Now, that's not really quite
right, but it's not a bad metaphor, although we do misuse
it a little bit, but if you look back at the past, people have
been talking about quality issues forever, since they
realize there was an issue. One of the things we've learned
is that this really does make a difference to the future of
development. So how can we expect people to
easily add things in future? Put it another way.
Most developers are living in the past.
When somebody sits down in front of a piece of code, they are
projecting themselves into the past, maybe it was the past
them, maybe it's passed somebody else.
But when people are working on a code base, they are spending,
let's say in an eight-hour day, they are spending about seven to
seven and a half hours dealing with the problems of the past.
Oh, I'm trying. A feature?
Yeah, I can see. You're trying to add a feature
but actually what you're doing is you're grappling with the way
that the code is evolved, you actually fighting the past
because, you know, that you want this feature to be different but
you don't understand the code that's there or you're fixing a
bug. Fixing a bug is living in the
past, try to understand code. That was written that living in
the past working around, something that's living in the
past, writing a test for piece of code.
That doesn't have a test that's living in the part, you know,
because these are all things that should have been solved in
the past. People spend most of their time
living in the past. And I'm not saying that.
Don't do that or shouldn't do that.
We will, there's always gonna be some percentage.
But I think that actually defines most of what programmers
do very few developers actually spend their time, genuinely
adding value to code bases. They spend their time
compensating for the problems to pass and this is a distinction
that systems thinker, John said and highlights just value Demand
versus failure demand, the demand for your work, how much
of your work is actually spent on dealing with problems that
have Arisen in the past and more importantly for me problems that
are actually solved problems. So let me Bring something more
up-to-date so refactoring that I think for many people are just
assume that car of the software development landscape actually.
Until the late 90s, that wasn't really a known term or a popular
idea in one sense we've done really well here.
But if you go back and you look at Martin Fowler's original book
on refactoring, or the original writings, and terms of extreme
programming, which really focused trying to bring
refactoring as forward to the front as it were so refactoring.
Many people's heads exist in I have two spaces all refactoring
that big work, we do on our Legacy code base.
You know, Refractories to do with Legacy is to do with bad
code and then the other one is 0 refactoring.
Yeah, that's a shortcut key. That gets me to rename things
and occasionally extract method. And it's just like, actually,
refactoring is a design practice and it's not always about by a
code refactoring. Is the idea that your software
is supposed to be soft. And therefore, when you come up
with a better understanding of something you do, we make this
better way of writing this, I should be able to reshape it
easily. So that I reflect my current
thinking instead of me using yesterday's thinking I've got my
current thinking I keep the code fresh.
Therefore it's constantly in the state of improvement and
response because we're always operating with incomplete
knowledge. We can never know everything.
It also allows me to be more forgiving if you like yeah we
got that wrong but now we can make it right?
And that's not a big deal. That's part of what we call
software development is still a separate thing.
It's not a separate activity. I have to ask somebody
permission for, it doesn't have that idea.
Oh, it's just part of the flow and so I think that although you
open up a modern IDE, it's got refactoring their.
Most people don't use them apart from Reno cut of have a standard
Joe when I point out to people is just like, isn't it great,
these days, we don't have Legacy code because when I joined the
industry, we had Legacy code. Hey, in fact, the term Legacy
was first used in 1989. So the term Legacy applied to
code was, actually the year that I joined the industry and I say,
isn't it great these days that we don't have Legacy code
because we've got a refactoring tools that eliminate most of all
the problems. You know when people Used to
complain. Oh, we got this method.
It's too long. It's so good that we don't have
that problem anymore because we have ways of breaking up efforts
and people say, oh yeah, glasses that are too big, the game.
We don't have those problems because you can extract class
eventually kind of people get the idea that I am joking.
And actually, I'm asking a deeper question, we have these
tools. So why do we still have all of
the problems that these tools solve and what that actually
teaches us? It was not a tooling problem.
That's what it teaches that we have given everybody, everything
they need. So in other words, this is the
interesting thing for most Software.
We know how to deliver it with low defects with low.
I manage technical debt, and to deliver a close to being on
time. These are solved Problems by the
end of the 20th century. Every single, one of the
problems I've just mentioned, was salt and yet we still
struggle with them. So for me, that's the bit of the
past. You want to live in, what are
the good ideas? We are still not apply
consistently. I still have to discuss with
people whether or not they should test that shouldn't even
be a discussion. Okay, you write tests if you can
get high. Even coverage well done.
There's other forms of coverage but that should be the minimum
when people say, oh yeah, we've got less.
Do you have 100% statement coverage?
No, no. We're in about 50%, okay?
You do know that 100% statement coverage is really easy to get
and people are always shocked by that, it's just like, well,
yeah, you just do test-driven development, that's it.
People who do tdd, don't worry about coverage or rather, they
worry about when it needle, dips below 100 because that normally
means there's some dead code statement.
Coverage is only interesting for people that don't do tdd or
other forms of continuous testing the So if you are doing
continuous testing coverage is not interesting.
It's a figure that you always expect to be high because you're
always writing your code and your test together.
Maybe you lead with the test TD style, this is a solved problem
we solve this years ago but people still struggle with it.
They try to justify having to write tests.
I was talking to somebody yesterday from Microsoft, about
this whole thing about why is that the people are not using
static analysis and high warning levels more there are reasons
but they're not very good ones. Why do people that have clean
build once you All of all of these leaves you with the real
problems that are interesting. Once you've cleaned up the bad
code, once you've cleaned up all of this kind of stuff, you will
still have Legacy, but that Legacy will be there for a
different reason that Legacy will be left over decisions from
the past your challenges now, to deal with like yeah we took this
decision but the technology landscape all the requirements
of mu. So that decision is no longer
appropriate. Not a bad decision.
It's just doesn't fit the world in and we wrote this code in
good faith, but now it's no longer.
Right? So we need a better fit for the
code in the world. So don't worry, once we've
solved all the problems, there are still plenty of problems.
But what I'm saying is that, most of the things that people
have said, hey, modularize your code, use a coherent Paradigm,
have less state mutability. That doesn't mean you have to go
doing functional programming. If your unit functional
language, that's absolutely brilliant.
If you're in a language, that really nudges you in that
direction, that's great. But even as somebody who's
worked in C and Fortran, I'm going to say you don't have to
have highly imperative code, that's never been a great idea.
And you're not forced into that, there are simple techniques, you
can deal with, modularize your code, use various techniques, a
class has a module. In this sense, it is a modular
construct, any for data, abstraction is a modular
construct, microservices. A modular constructs at a larger
scale, but the idea is, if you think that microservices are
going to solve your poor modularity, in your code,
they're not when everybody says hey, we're doing microservices
because it's going to improve the structure of our code.
Well, you don't need microservices to do that
microservices, solve a very specific problem.
I'm related to deployment and scaling.
That's what they're really good at if we have had so many
paradigms over the last few decades, that are about how to
organize your code. You don't need anymore.
You've got every single tool. And if you can't do it with
that, then you should take a step back, put the mouse down,
death away, from the keyboard. Go wait, what's really going on
here? What is it?
That we are missing as a team collectively to reinforce these
practices. So yeah, past is an interesting
place, we get drawn back to our mistakes in the past, but we To
learn from our successes. So that be my general advice on
this one. Listening to your explanation is
very fascinating because I love developers these days.
Chase this hype driven development, right?
Oh, that's the new cool Technologies.
New framework, new libraries new paradigms, like microservices
event-driven and things like that.
But if we look back to the past, they're probably so many
theories that still stays relevant.
And in fact I notice some of these thought leaders in the
tech industry like they finally Robert Martin Uncle Bob they
wrote books Book's title like, modern software engineering and
clean craftsmanship. But if you look at the things
that they are advocating, actually, it comes from the past
the same fundamental things that stays relevant even up until
now. So, I think the key message
here, I want to emphasize is that for developers.
Please go back to the fundamentals.
Don't always chase the new shiny things.
There are still things that we can probably Master to become a
better developers here. And I think the value is, when
you understand, that gives you a more solid foundation and when
something new and shiny does, Come along.
You now, have a more objective assessment.
You can separate out and go. Okay.
Yeah. This is building on foundations.
There's nothing new. And then you can look at the
bit. That actually is shiny and go.
This is the value of this or you may say, wait a minute, there is
nothing shiny here. This is just repackaging.
The past and also its mistakes. So maybe, let's not do this one.
It gives you a more objective sense.
Of course, most people in technology, get into technology
because they like the excitement of something.
So we have to kind of watch ourselves a little bit on this.
We are Our Own Worst Enemy at this one.
So adding that a always find fascinating.
Also, because they are tools that are built by developers,
that makes things easier for us to turn out code, but not
necessarily comply with this, cohesion, or this coupling.
So I think of it like the Frameworks of are Frameworks,
right? So I think that's also another
thing that is fascinating, like with then do one shortcuts and
if we're something faster, but not adhering to the good, best
principles that software should be written in.
So Cavalier, another thing that you are very popular in its what
people call Carolyn hennesy, Right?
You can see in felonies Twitter, just look at what we call
software failure. And these are normally public
software failure and people just send, you know, pictures of this
software failures to Kaplan. So maybe the first thing is tell
us what the story is all about how come people actually, send
all these things to you. So you can story goes back a
long way. I used to take screenshots
whenever something crashed on my machine or take a screenshot of
it and sometimes I would integrate it into a talk then,
of course, phones have cameras. So I started taking pictures of
software failures in public places because software runs the
world, but it doesn't always run it in the way to re-watch it to.
There's a lot of reboot screens and screens, which Trace very
elegantly, the whole Tech stack, that's just crashed.
I started taking photographs of these.
Again, I did incorporate those into talks or I just kind of put
them on with screen when running a workshop, a good source of
entertainment. But also going back to this
question of quality as something, I've always had an
interest in, it's a reminder of like yeah in the tech space, we
have a certain responsibility, we are creating things.
That crash we are creating Don't work a bug isn't personal
inconvenience to you or configuration issues a personal
inconvenience to you or it just becomes a ticket.
The thing is to realize that it exists in the world, it's not an
abstraction. It's actually exist in the
world. It's amusing.
Sometimes would also probably preventing somebody else be able
to do something. So I kind of highlighted these
then as a result of this people within start, emailing me these
things. Then we hit the social media
error, so it's much easier. They don't have to email me.
They can just tag me. So this is Coming a popular
thing on Twitter, in particular what I would do because that's a
very public space is that I would just retweet this.
Then people started making a point of doing this and in 2016,
somebody actually started saying, oh, okay, Evelyn any
screen because it had reached a particular points.
And so that's how my name got associated with it.
That point there's even somebody put an entry in Urban Dictionary
and there's even a mention on the register of this stuff
though. That's kind of an interesting
thing. I was also asked by somebody
Then what is it? Feel like to have your name
associated with failure? So thick it is, and it's just a
way of looking at it. It's just like, yeah, I don't
cause these screens, but it is interesting because it's a
reminder for me that when we do with software, when we develop
it, and when we deploy it, we are part of a larger system
where our failures in software are no longer about us.
There are about other people. They become very visible in a
world that runs on software. That becomes a Prominent Point.
Some of them are quite revealing in a way that you don't want to
be revealed. Like I said, sometimes you get a
complete stack Trace. In fact, I saw one yesterday
which was quite interesting. The stack Trace was not visible,
even though there was an error because whoever created this had
the wisdom to say, you know what, we're showing our internal
structure that can be used against us from a security point
of view. You discover the somebody's
using an unpatched version of something you go.
Oh yeah, that's interesting. I got a new attack Vector there,
but it also tells us something about the organizations that
run. I still get images of Windows
XP, both screens and failure screen.
Like peas been out of support for a very long time.
Again we're living in the past. A lot of the world is running on
stuff that everybody thinks they left behind but there isn't it?
Actually all there. We have a responsibility there.
We need to get a little better at this but then we also get the
obvious program. I level bugs is just like, yeah,
we should have perhaps configured that looking more
carefully or tested that more thoroughly.
It tells us about us. That's what a lot of these
things do. But what is also interesting, is
that sometimes when people tagged me, particularly with
something like public, Transport.
They will also tag the public transport company.
And some of the time, the public transport, whoever's on Twitter
that point was at all. Yeah, sorry about this or yes.
We've saw this problem has been resolved or please tell us more
because, you know, this is embarrassing for us, so it's
also a public service at level. I hope you all the programmers,
who build systems never had a chance for your systems to be
sent to Kevin honey for failures but I think the story that you
just told, right? I think there's a lot of things
here that I insights. So when you deploy software,
especially for public Systems like public transport airport.
Sometimes I see all elevator. So there are a lot of
responsibilities software failure can impact a lot of
people. These kind of things are
definitely for one thing is funny.
Yes. But at the other end is
something for us to ponder about software failures.
Should be treated more seriously.
So, coming back to the beginning when you mention, you also love
writing public speaking and things like that.
You mentioned that, developer should focus, not just on
coding, maybe you can explain why we should all think about
writing more, or speaking more, or having more In which you
mentioned as well before we talk.
So people have many different roads into software development,
the flight reflects different motivations.
So this is my story as a teenager, I was interested home
Computing, all this kind of stuff, this was the
technological change that affected me and was a natural
area of interest but of course that was very much about you
being an individual and solving problems and playing around.
It was ultimately all about play there is that idea, but it's
also ultimately about you. Other people arrive in software
from very different paths. It's because They work with
team. So I know number of people who
have moved as it were from the customer side of the product
owner side, the business side into being a developer because
they work so closely. So in other words, their initial
point of contact with software was not in the technical ground
up perspective, it was not the bits in the B.
It was not that perspective. It was not as a formalism, it
was as a business tool and working in teams.
So they have a much more social perspective of that.
So some people already have that view of software developer.
I think many people end up in software developed without
properly. Appreciating the war, they're
trying to do is communicate, ultimately, that's what we did.
And we're not just talking to a compiler.
We are talking to ourselves our future selves.
We are talking to our colleagues.
We are talking to people, we will never meet in one very
simple sense. We are organizing our thoughts.
That is what a programming Paradigm.
Is it is a framework for organizing your thoughts and
your knowledge. You are taking knowledge that is
technological and Technical. You're taking knowledge of the
problem domain and you are bringing together in a formal
structure. And you are saying here is how
I've chosen to meet this requirement to the best of our
knowledge, and best of our ability at this particular point
in time, that's what you're effectively communicating, by
the way, it compiles and runs, that's kind of important, but
there is an idea here. When we take a step back and we
realize communication is the clarity of our own thoughts, we
often don't think clearly to ourselves.
It's a discipline different philosophical Schools.
Go back to actually thousands of years.
They are often about how do we do the day-to-day?
How do we communicate or intentions?
Clearly, how do we Take a step back and separate what we
believe from what actually is because sometimes our beliefs do
not match up to the way the world is and these are age-old,
questions, software is one of the places we bring these all
together. So for me, that idea means I
need to have a bigger understanding than just.
Hey, I can use a framework or I understand formal systems and
perhaps I have a mathematical background and so the word
itself communication comes from the Latin communis, meaning
together, it's about be together.
That's what it is. That's the whole idea.
It. And what is it that causes that
and improves that for me different people have different
parts in. So I think writing is an
interesting one, because, when you look at advice for writing,
a lot of it transfers straight into software development,
there's no boundary. There you go.
Oh, yeah, the intentions of the same, but it reminds you that
you are an author for somebody else, you're not merely
instructing the machine, it's not merely a functional thing
that it should go. In fact, that's a reminder
software development, not about project is about products.
It's a project is something that you finish we're a software
development. Generally the goal is not to
finish. I don't don't deliver.
I mean the idea is that we are always building.
We are not aiming for a release. We are aiming to keep on
releasing the name of the game, is to keep on playing the game.
And so therefore we need to create a sustainable environment
and code is the environment we create.
So we need to get better at communication and that also mean
communication to ourselves, you always have a way more
overconfident belief that, you know what you did in future that
I'm the near future and in future, you will come back and
go. I have no idea what I was
thinking. When I wrote this, you remember,
it was clear in your head, but you don't remember why?
So that idea of genuinely organizing your thoughts and for
me writing is one of those techniques and the advice that
we find on writing translate very well to and one of the
things in code. But then also things like
speaking, speaking is an interesting one, because many
people fear it because you're standing up in front of
strangers or if our colleagues you are potentially very
vulnerable. And that's a big ass.
It's not something that necessarily everybody's going to
feel comfortable with but the one thing we can say and this
goes for writing as well and other works, you know, so
occasionally I run across people who Express themselves
differently. There's a very high number of
people who play a musical instrument in software.
For example, that's you expressing yourself.
It's not expressing yourself in the same way with the same
intent, but that is you creating a structure and enjoying doing?
So, what can you take from that? There are two things, one you
are The structure that supposed to make sense, There are rules
and boundaries on their structure.
Some of those rules and boundaries can be broken to
create new rules and boundaries but there is also skill and
there is also enjoyment. Hey, these all town like things
that I would like to think I could bring to my work as well.
My pastime. So the idea is, there's a lot to
be learned from these other forms of expression and so
sometimes people will be more than happy to stand on stage and
play guitar. But we say, oh no, I can't stand
in front of people and talk in front of slides.
And it's just like, take a step back and think, hang on.
What could I transfer between these world?
Can I move my Skillet communication and expression
into something more verbal because code, is ultimately, a
verbal construct. Its word based.
It doesn't mean everybody's going out speaking the same or
necessarily it was going to be totally comfortable with it.
But the more you do it, the easier it becomes.
You start realizing your own gaps, your own shortcomings and
you generally get a bit better. If you were nervous at the
beginning, you're less nervous in future.
If you are very nervous at the beginning, you're just nervous.
Listen future. If you were a little bit
nervous, you're not nervous in future just by doing it and
repeating it. But that also goes to
compassion, because just now you mentioned compassion.
And also just said, when you write, if you publish a Blog,
you are potentially vulnerable. You are exposing your thinking
and your thoughts and your writing particularly if you are
writing a language that is not your first language.
You may feel very vulnerable that made things.
People always a lot Kinder than you think they are actually will
appreciate your effort if you think you have.
Nothing new to add yeah, you're mostly wrong infant.
That what I don't like to tell people their role but you must
be wrong because you have a point of view.
I was telling somebody the other day, I said, there's something I
envy you for because I will never be able to go back to that
stage at this point. I will never have that journey
of Discovery game because I remember most things but you're
about to enter a point in your career where you're going to
start learning things for the first time and they're going to
be exciting and you're going to discover, you can do things, you
didn't think you could, you're going to have technical
insights, you've been working with Frameworks that you Talked
about but then you're going to go above and beyond that and
you're going to suddenly realize hey I have a bigger picture here
and I understand something about architecture that nobody's ever
told me. And you see that for yourself,
there's a whole load of things there that you and only you can
experience. So you have that ability to
offer that to other people. And wouldn't it be a shame if
the thing that holds you back from doing?
That is a fear of your own communication and that doesn't
mean you're going to write the perfect thing but you know what
if you don't write, it will definitely be very imperfect.
The world is missing that contribution.
But that's the idea compassion is also very important.
We literally fell in love compassion means to suffer with
somebody. Compassion means to understand
that you see somebody else's. They're making a bunch of
mistakes. And yeah, you know what, I know
what that feels like else is struggling to give a talk or
organize their thoughts. You know what, maybe they're
having a bad day or I understand what that feels like.
All of these things is that kind of recognition that we spend so
much time working with machines and tools, we've got to remember
our yes humans. So, for me, I think that's a
really important. Important emphasis, the emphasis
has come about slowly Through The Years.
Seem people talk about this in a few years ago, April Wenzel
really kind of coined. This idea of compassion.
Coding is just like that. It's just like oh yeah this is a
big signal. This is absolutely okay.
For everybody to talk about this stuff it's okay to make mistakes
to understand the other person is human.
Which means hopefully they understand that you are human,
which takes a lot of pressure off.
I think a lot of people are under a lot of pressure to form
and expectation and soul. If you can take a little bit of
that off, it goes again back to following.
Put the mouse down step away from the keyboard.
It's allows you to think differently and more Loosely.
If you are constantly being pressured, that's going to box
your thinking that's going to reduce your ability to be
creative and have insights. You become a machine which we've
already got those. So, you need to kind of give
people that space, there's emotional and social space there
as well, which I think is. So for me, that's part of the
message as well. And again, when we look at a
piece of code and we don't like it, it's really easy to go man.
Whoever wrote this was an idiot. It's just like Like maybe it was
you maybe the Ada was passed me but more to the point is.
Yeah. You know what, maybe they
weren't an idiot. Maybe they just had a bad day,
maybe they were working to the best of their ability.
That idea is that in the future, you will always know more than
you do now but the code is not been written in the future.
It's being written today, we may revisit it in future, we may
refine it in future and again it goes back to that idea of like
refactoring. Being a forgiving process,
you've got to work with what you've got today.
Unless you have a time machine, you going to work with something
else, so do it. But that also means in future,
you got to go back and go out. Yeah, I remember thinking this.
Yeah. I was wrong.
There's nothing wrong with being wrong, but you've just got to
frame it in a way that goes like.
Yeah, we did our best but now we know better and that's
absolutely fine. That's a better frame that damn
we were idiots. We should never be allowed near
keyboards again. It's a very harsh way of looking
at it. So that the me compassion is
that missing ingredient and that was never made clear to me when
I joined the industry or in fact for most of the time I've been
in Austria, that's actually an important ingredient in creating
large software. Teams and companies based on
software, you kind of have to rid of that if you want to have
the longevity and all those quality and productivity
aspirations people have. There's a magic ingredient and
it's the appreciation of other people while they're so many
things straight from your explanation, right?
Starting from how to organize start clarifying, your thinking
process many programmers probably started their career
thinking that they will work just with machine and keyboard.
They don't like talking with other people but actually
software development is about communication.
Medication with other people, not just from business, but
maybe with your users, or maybe some other people as well, when
you can clarify and communicate better, I think you become a
better software developer as well.
And I think compassion I hear you loud and clear many people
these days especially in the tech industry in the startup
World, they tend to just thinking of fast-paced always
deliver always churning out things but they lack compassion
thinking about the thing that they are, people are chasing.
It's actually thinking about the people aspect as well, not just
producing code. So, I think you're Message is
really important for all of us here to think about compassion,
and not to always downgrade people.
As a developer, we have skills in abstraction, we should be
careful about applying those skills to people.
Yeah, yeah. So we should not downgrade
people thinking they're just developers.
So, Kevin has been a great conversation.
Unfortunately, due to time we have to wrap up.
I have one last question though that I would like to ask you,
which I call the three technical leadership wisdom.
So think of it just like advice for other people to think about
or Ponder with their Journey as well.
So maybe can you Share with us. Those three technical leadership
wisdom. Yeah, I think they asked kind of
follow on from the previous points.
We making interestingly enough, that's taken us to a very
interesting plate. The first thing I guess a really
simple one. When we talk about technical
leadership is definitely lead, by example, and that's a harder
than it sounds, but the idea is, when you are trying to instill a
change, we are taught about telling people and funny enough
in the writing World, there is this idea of show, don't tell,
when you write something, the idea is, what is it in your
You're writing that communicates.
What's going on? Don't just give a description of
everything that's going on and you don't have quote marks
around. I don't love you anymore.
She said, angrily, what's that? Would angrily doing there?
How do people behave when they're angry?
She slammed the door, as she left are slamming little wow.
Okay, she's angry. And I was show me the think,
don't just tell me the things show me the thing and I think
same thing applies paid to richer picture.
So is very easy to fall into a position where potentially, if
we're advocating a practice within a team, we're telling
people Sure that message might get through, but it probably
doesn't, and he probably doesn't mean anything.
You got to work at the level. What does it mean?
If I recommend a practice, can I show you what it is?
What if I do that? What if nobody else does that?
That's fine. But imagine you did it and you
were able to point to it. What's that you're doing?
Oh, okay, that's kind of interesting.
I see you're using a different commit, message philosophy to
the way that I'm writing commit, but your commit message
philosophy, seems to have a clearer communication and you
break your commits down to smaller levels than perhaps to
other people in the team do. And you realize they much more
transactional. Well, there you go.
You've got an example lead, by example is a really important
thing and sometimes that means leading, before you tell do that
in practice, it becomes more of a habit that you're also in a
better position to talk about the adoption of it.
It's an example, not just because you're not being a
hypocrite, hey, I'm telling you to do something going to do
something else but also because it may mean more to people when
they actually see it in action, whatever that practice is
whatever that advocacy is. Well there that recommendation
is, if you can see it in the world, it makes A lot more sense
to me than just being told it. So I think that's kind of the
first one, the other one. So people get called team
leaders, they get called technically, there's an
organization they get called leaders but that doesn't always
mean, you are leading to be a leader.
You have to have people who follow.
They can either be told to follow you all the kind of
follow you. So the leading by example is one
thing but the other thing is you got to realize that if you are
trying to Advocate things, you are not going to come up with
everything. You're not going to lead, you
shouldn't do all the work, otherwise you're going to end up
in a position where you become a micromanager know to lead.
And also recognize that particular when we talk about
teams and organizations, they are social constructs.
Again, we're back to the people. There's a lot of intelligent
people at software. There's a lot of creative
individuals and everybody knows something that you don't need.
You know, they know the things that, you know, they will know
them. Different cannot know, something
for somebody else, and you cannot know it necessarily in
the same way and she rely on other people to come up with
ideas. It's not your job to do, all of
the work rely on other people and give them credit.
So that's the important thing make That visible.
I sometimes see with people who consider themselves to be
leaders as they think they have to do all the thinking.
No, actually your value goes up by recognizing and letting other
people do this and make it explicit that they came up with
that. That's where people go.
Yeah, that person to leader. They credited me.
They see what I'm doing. You got to see them and make
that visible and make sure other people see them.
So, that's a really important idea.
And the other one picks up on another theme that we've had
throughout our conversation today.
Which is admit you're wrong, you're going to make mistakes
and a really hard thing to do. Sometimes that may be at our
personal communication level with somebody, you may make a
mistake, you may misjudge something.
You may be too emotional. You may miss read somebody
else's emotion, but it may also be something technical perhaps
that you kind of always staked your career on, we're going to
do this and you got to go. You know what?
I was wrong. Actually, that wasn't the best
option and now, I understand why that whole thing rather than
trying to hide it or dig into it that even more deeply.
That's a really important thing. Again, your stock goes up as a
result of that, but also, that's a compassion for yourself.
Don't hold yourself to unreasonable standards because
otherwise you'll always miss. So that's very much the idea of
work with a growth mindset rather than a fixed mindset.
So yeah, you're going to make mistakes.
We are always operating with incomplete knowledge and we are
inevitably imperfect and that's absolutely fine.
Just roll with that. That's the way that you do it
and there people will see them. Yeah, admitting we are wrong.
Sometimes is very difficult. We putting our Ourselves with
vulnerabilities, some people fear about being vulnerable
people being attacked, right? Yeah.
If I'm supposed to be the ACT but and I got something wrong.
Does that mean I'm no longer the expert on my got, that puts you,
in a very vulnerable position. As a perfectionism there, that
becomes quite predatory and quite dangerous and doesn't help
anybody's mood. Whereas actually is
occasionally. Yeah, you know, what you were
wrong and that's fine. It's okay to be wrong.
Yeah, especially in Tech where people have egos and have
impostor syndrome. So they tend to hide all this.
So I think that's a very beautiful message, not to fear
of admitting, we are wrong sometimes, so Carolyn for people
who love to connect with you, or maybe follow some things that
you write or speak about. Is there a place where they can
find you online? Yeah, I'm going to number of
different places. My parents were kind enough to
give me an internet unique name before the internet was
invented. So, Carolyn Hannah is an easy
thing to find, so you can find me on Twitter there as Kevin
Haley, you can Follow me on Mastodon as Carolyn at Mastodon
social you can find me on LinkedIn.
So these are the most obvious places where I hang out and so I
look forward to seeing people online.
I'll put that in the show notes, thank you so much for this time.
Kevin I learned a lot from you today.
Thank you, Henry. Thank you for listening to this
episode and for staying, right until the end, if you're 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 tackling
Journal, dot death website, including the full transcript
interesting. Chords and links to the
resources mentioned, from the conversation.
And lastly, make sure to subscribe to the show's mailing
list on package. You know, dot f to get notified
for any future episodes. Stay tuned for the next
technology. No episode.
And until then goodbye.