Episode: 2179
Title: HPR2179: Mail to myself@myfirstemployment, Part 1
Source: https://hub.hackerpublicradio.org/ccdn.php?filename=/eps/hpr2179/hpr2179.mp3
Transcribed: 2025-10-18 15:22:56

---

This is HBR episode 2,179 entitled Male to Myself at My First Employment, Part 1.
It is hosted by Klackit and is about 14 minutes long.
The summary is, I expand on a list of one either advice to myself 20 years ago that I posted
on pump.io.
This episode of HBR is brought to you by AnanasThost.com.
With 15% discount on all shared hosting with the offer code HBR15, that's HBR15.
Get your web hosting that's honest and fair at AnanasThost.com.
Hi, I'm Klackit.
I recently wrote a pump.io post called Male to Myself at My First Employment and I figured
I got some questions about it and I'll expand on each of the points that I wrote in that
post.
Here it goes.
Warning number 1.
This is the only numbered one because I'm referring back to it later.
Your prototype will run in production every time.
So you have this problem you've been discussing at work and you've come up with a sort
of a half baked solution that maybe we could take this and we could take this and we
could tie that together and something like that and then you present it to someone and
they say, oh it looks great, let's use that.
So what's the lesson here?
This will happen over and over again and you will think, well they can't be with that
stupid really, they have to realize this is just a prototype.
I should put proper tests in there.
I should have covered these in these circumstances and I shouldn't have hard coded these things.
So what do you do?
Basically you can do two things.
You could, if it's not supposed to work, just make it not work.
Don't produce something that sort of does the job but instead do a presentation.
Just graphics, just a stupid HTML page that fakes everything or you put in a little more
time and you make sure the tests are there that you didn't hard code everything that you
have actually have some documentation and then you present it.
If you just cook something together real quickly and present it, you're going to have to
support this thing for the rest of your career at that place and you won't be given the
time to do it properly.
So either do it properly or don't do it at all or obviously fake doing it.
Do what's difficult by this I mean, you spend probably around 8 hours a day at work and
you could spend that time just picking low hanging fruit and making time pass and you
feel like you're getting things done but you're not learning anything.
You're not just there to get paid, you're also there to develop and by that I don't
mean software, I mean yourself.
Do the challenging things.
If you have the choice between doing something that is just monotonous work and automating
it even if automating takes a bit longer automated so you can get on with the important stuff
which is the difficult stuff.
Of course you have to do this in cooperation with your employer but I've been lucky.
The employers I've had have been giving me pretty free hands to do what I found necessary
to solve whatever problems I'm there to solve.
So if given the choice do something that will help you move forward as a developer or
possibly as a person.
Hard work is not the same as difficult.
If you took the previous point as meaning I should make sure I'm not slacking off at
work so I should go on and take on all these assignments that mean I've been sweating
hard in front of the screen.
If that sweating hard just means doing a lot of monotonous work that's not what I'm
calling difficult.
Rather it's the opposite.
Find a way to automate it instead.
And actually if it's really stuff that cannot be automated and someone will have to do it
you'll also have to be a bit selfish.
Don't take it on just because it's boring and you feel like a good person for sticking
out for your colleagues or whatever and taking on the boring task.
There will be time enough to do boring tasks if you have the chance to do something else.
To do I always say to be able to love others you have to love yourself first.
And that's always a good thing to keep in mind.
If you're just doing things at work that are not developing your skills you're less
useful to the company as well.
So you're not really being selfish if you're being selfish in the right way.
Make yourself a good resource and do the difficult things and do the automation things.
Do programming, push your knowledge.
You are there because they believe you know something.
They are probably right and they will listen to you.
This is encouragement and a warning.
So even if you're a junior developer and you just got started you might get surprised
that you say something that you feel it's just a comment like why don't we do this instead.
And someone might actually listen to you and go ahead with your suggestion.
So don't feel like you're stupid.
If you're asking questions why don't we do this or if you're giving suggestions don't
feel like you have to stay down because you're a junior.
My experience is people will listen to your opinion.
If it's well formed if you have a fact basis for it then people will take it to heart and
they may go along with your suggestion.
Even if they don't there's a point later for that.
But it's also a warning.
If you're working with the system and you say wow this is ridiculous.
This is all crap and I just want to start over and do this from scratch.
Maybe you just mend it as a comment of frustration but someone might listen to you.
They may take it as advice and that may not be a good thing.
If you're just whining over something maybe it's not a well considered opinion but maybe
the people listening to you don't really understand it's not a well formed opinion and
you will possibly be put in the seat of having to implement it.
So throw away comment is not always a throw away comment that's the warning.
Ask.
I sort of said this already but if you don't know ask a question you're not stupid for
asking a question you're stupid for not asking a question wherever you are you're there
to learn.
Even if people hire you for your expertise when you're not a junior anymore you're still
there to learn.
Every place has its own circumstances and you need to know them to do the best job.
And this also ties into something someone said on the internet.
If you're in a room where you're the smartest person around you're in the wrong room.
So hopefully you're always in the place where you can ask stuff and learn stuff.
Take a day off from doing things and listen and watch instead that's also work.
I think at every place I've worked we've been doing development they have always been
meetings where we have said hey guys do you know what we should do we should just stop
discussing what the users might want and just step away from our own keyboards go hover
over the shoulder of someone who is actually using this stuff.
Now I'm working in build systems and I should probably sit down with a developer that
is using the build system and actually see what kind of things are they doing frequently
what are what kind of problems are they trying to solve.
So far I've actually never done this which is ridiculous because I've known I should be
doing this since basically I started in this business 20 years ago.
I still think it's good advice even if I've never tried it out I should code is the
best description but heat warning number one.
This is something they talk about in IEEE and the IETF when they do a specification they
want there to be at least two implementations so that you have concrete examples of what
people are actually going to do with this protocol or whatever they're designing.
First it's to try things out but second it is because code speaks if you've written
an implementation people can actually look at the implementation and say oh so that's
what they meant because the code executes and it does things and that can explain things
better than any verbal explanation seeing things in action.
But heat warning number one if you're speaking through code make sure you're speaking through
production ready code I don't mean perfect I mean not horrible you will have to support
it later.
There's a reason whenever you look at a system and it's full of warts and crooks and crannies
and dust and spider webs and this weird thing poking out over here there's a history behind
all of those things.
If you think you can just tear it all down and build something better from scratch you're
in for a surprise because a really weird thing in the system might be a response to a bug
report where there was a corner case that wasn't covered in a specification and nobody
had thought about or it's a quirk of the language or the hodgepodge of libraries that
went into this thing.
So respect the code and always consider that there might be a reason behind why it's
doing something that looks really horrible.
There may be no good reason this is the counter point sometimes it's actually just crappy
code.
What can you do to discover if it's crappy code or if it's code that contains essential
warts?
Write tests write an integration test suite test it against the things in actual use
in production.
Change it ask someone for a code review ask someone to try it out and maybe you'll discover
that actually this word in particular could be removed.
Okay so I seem to have read at the office so I'll make this a two part.
See you in the next part.
You've been listening to Hacker Public Radio at Hacker 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 contribute link to find
out how easy it really is.
Hacker Public Radio was founded by the digital dog pound and the infonomicon computer club
and is part of the binary revolution at binwreff.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 like, 3.0 license.