Episode: 2180
Title: HPR2180: Mail to myself@myfirstemployment, Part 2 of 2
Source: https://hub.hackerpublicradio.org/ccdn.php?filename=/eps/hpr2180/hpr2180.mp3
Transcribed: 2025-10-18 15:23:40

---

This in HBR episode 2,180 entitled Male to Myself at My First Employment, Part 2 on 2.
It is hosted by Clacket and in about 8 minutes long and carrying a clean flag.
The summary is, I expand on a list of one line of advice to myself 20 years ago that I posted
on pump.io, Part 2 on 2.
This episode of HBR is brought to you by an honest host.com.
At 15% discount on all shared hosting with the offer code HBR15, that's HBR15.
Better web hosting that's honest and fair at An HonestHose.com.
Hi everybody, this is Ken, just a special note we heard yesterday that Lord Dragonbloth has passed away.
Clacket has sent in the following message to the mailing list and I just want to make sure that
everybody has the opportunity to participate. Requesting Lord Dragonbloth's eulogies.
Hi everybody, Nightwise just told me in IRC that Lord Dragonbloth, a long time friend of Hacker
Public Radio and its many iterations and been rev well before that has lost his battle with cancer.
Lord Dragonbloth was a good friend and it's just such a huge loss that he's gone.
I'm going to record a few thoughts in his honour and post it as an episode but it would be cool if
anyone else who knew Lord Dragonbloth wanted to do the same. I'm happy to collect and edit the
recordings together and post them. I don't have a deadline but let's shoot for 14 days from now or so.
Cheers, go go hug, I loved one, tattoo.
And now we'll have a few moments of silence.
So long Lordy.
Hi, I'm Clacket and this is part two of my further elaboration of one-liner advice given
from time traveling me to 20 years younger me, professional advice. I think we ended off with
try it. No sorry, we ended off with there may be no good reason so I'll continue with try it.
So the advice is try it but heat warning number one.
And this of course means if you're in doubt if something is going to work or not or what's the
best way to do something the best information you can get is by just doing it and then see what
happens. Be careful though when showing your results to someone either it should be unusable
in production I mean completely unusable or it should be more or less production ready.
You shouldn't have to be scared of supporting it for the rest of your professional life at least
at that company. Those who talk may also have something to say but it can take years to learn who
these people are and what they're actually saying. When I say those who talk here it's a bit
too straight of a translation from the original Swedish. Those who keep talking all the time
is the intended meaning here. Those who keep talking all the time may also have something to say but
it can take years to learn who these people are and what they're actually saying.
So several of the layers within the software industry consist of people who go to meetings and
present slides to other people who go to meetings and present slides and it's very easy to
fall into the trap of believing that all these people are always talking garbage. They're not.
A lot of them are and it seems like can be quite easy to get away with not really knowing what you're
doing but some or even a lot of these people actually do know what they're doing and if you can
parse enough of what they're saying and see what the technical reality behind the oh what's the name
for that we call it a oh there's a catch your name market yes market texture that's the
lie of an architecture that you show to the customer that's the market texture but even behind
the market texture you can see what kind of thought has gone into this into a system existing
system or potential system and with enough experience you can actually learn something from even
quite shallow presentations you can suss out if there is something worth considering behind this
stuff or not you need to be able to determine what slogans are just slogans and what slogans are
useful labels for things actually thought through and it's not easy but if you can do it you can learn
from from these people the good ones have a really great high level grasp of things
and have been designing several systems on a high level and know what kind of trouble you're likely
to run into an architect for that trouble so that the system can work in the long run
so learn to identify these people and learn to parse what they're saying and you can learn a lot
if you don't speak out you won't get the chance to get corrected
don't be scared to voice your opinion or to ask questions worst thing that can happen
someone will correct you correction worst thing that can happen is everyone ignores you
and what may feel like the worst thing that could happen is someone corrects you
but actually that's a good thing of course if you never learn anything and you always ask the same
question so you ask questions that show that you haven't really understood the context that's one
thing but you're probably smart enough to know when you're just not understanding some detail and
when you're completely out of your depth if you're completely out of your depth then you probably
shouldn't have gone to that meeting or been in that discussion in the first place so I think it's
unlikely that it happens a lot if nobody sees your code you won't get the chance to correct it
you won't get the chance to get corrected
this is maybe even more important a really good way to learn how to program well is to read
other people's code and an even better way to learn how to program is to write code and have
good programmers read it and suggest improvements that's how you really
get the craft of programming into your system and the last point finish quickly
then improve but he'd warning number one so this is a rephrasing of
Eric Rayman's release early release often get yourself out there
perfection is the enemy of finishing if you're always going to
add one more feature or remove this little quirk then you're never going to get this thing out
there and you can't benefit from other people commenting on it maybe even just telling you maybe
not even just telling you what should be improved but actually sending you patches
code review is a great thing code review by thousands of people is awesome
so get your stuff out there and benefit from the knowledge of all the people who may find it
interesting same as with this podcast if you have something to say just say it if you're wrong
someone else was in an episode and tell you you're wrong and then you'll learn something
I hope that people are listening to these episodes these two episodes will provide their own
comments or audio commentary or both so we can all learn how to become better programmers
and how to teach others to become better programmers
you
you've been listening to hecka public radio at hecka public radio dot org
we are a community podcast network that releases shows every weekday Monday through Friday
today's show like all our shows was contributed by an hbr listener like yourself
if you ever thought of recording a podcast then click on our contributing to find out
how easy it really is hecka public radio was founded by the digital dog pound and the
infonomican computer club and it's part of the binary revolution at binrev.com if you have
comments on today's show please email the host directly leave a comment on the website or record
a follow-up episode yourself unless otherwise stated today's show is released on the creative
comments attribution share a light 3.0 license