Welcome to Pragmatic.
Pragmatic is a weekly discussion show contemplating the practical application of technology.
Exploring the real-world trade-offs, we look at how great ideas are transformed into products and services that can change our lives.
Nothing is as simple as it seems.
This episode is sponsored by Aqualia and specifically their great product Solver.
Solver is an amazing calculation app that works the way your mind does.
When you're working out a maths problem on paper,
the more powerful than a calculator but simpler and quicker than a spreadsheet,
Solver can help you solve your math problem.
Please visit the URL in the show notes for more information.
This episode is also sponsored by Space Nation and specifically their app, Hue Party.
If you have LIFX or Philips Hue bulbs, Hue Party can control them and add some neat effects to it.
It's a free app for up to two bulbs, so you can check it out at, with no commitment, at hueparty.com/pragmatic for more information.
I'm John Chidjie and today I'm joined by my guest host Guy English. How you doing, Guy?
Great, happy to be here. Cool. Thanks for agreeing to come back on.
Before we get stuck into the topic today,
Which oddly given you know, you're my guest host is related to software
I just wanted to quickly cover off a few things. So firstly a quick
Thank you, too. And I love the name the username. Yo crystal ball
In the US for the lovely review in iTunes. Thank you very much
But more poignant as of today, I'm going to be live-streaming each show of pragmatic
So we I used to do this with Mixler on episodes 10 to 14
But then episode 15, we started having some technical problems with it, decided it was
best to stop.
That was back when I was at Fiat Lux.
And it's been a while between drinks, so it's been exactly 20 episodes since the last one
that was live, but now we're going live again.
So this time, however, I'm doing it the more, I'd say traditional, but how about the more
current way, which is there is an IRC chat room on freeno.net.
The chat room is #pragmaticshow, all one word.
If you go to the URL techdistortion.com/live, you can listen to the stream, you can access
the stream there, or you can use the embedded IRC chat box in that window to join in during
when the show is live.
Of course, if you have an IRC client, like I use Colloquy, is that how you pronounce
that guy?
Colloquy?
- Colloquy, yeah.
- Yeah, I'm more-- - Close enough.
- Yeah, I-- - That's what I use too.
- Yeah, cool.
It's not bad.
So I never know how to pronounce it, but anyway.
So feel free to join in and what we're going to be doing right now, first of all, is I
don't have the ShowBot up and running yet, working on it.
It will eventually, probably in the next week or two, I don't want to set a deadline because
that's crazy talk.
So yeah, at some point I'll get ShowBot running.
I'm actually going to take Casey List's ShowBot for a whirl.
I had a look at the 5x5, I know.
I know.
That'll work out well.
Oh, come on.
It's not too bad.
I'm kidding.
that. So I want to give that a shot anyway. So, hopefully we'll see the results of that
in the next few weeks. In the meantime, I'll just go back over the stream. So if you have
title suggestions, feel free to make them. Any contributions, obviously chime in at any
time. But because it's a very focused show, I tend not to go off on too many tangents,
or I try not to anyway. So, you know, there'll be a balance. But what I want to do differently
is if you have a question, specific question,
either for me or my guest hosts,
then please ask it in the chat room,
but prefix it with an apostrophe Q or apostrophe QA.
The idea is that after the show's wrapped,
that I wanna have a question and answer session for people.
So what I wanna try and do is separate
the actual questions and any interruption of the show,
and we'll have it as a separate Q&A session at the end,
which is hardly a new idea,
but it's just something I wanna try.
We'll see how it goes.
Okay, now just one more quick word about sponsors. I've been really fortunate to have some great
sponsors in the last few months and honestly if you would like to sponsor the show just
go to techdistortion.com/sponsored again and touch. This is the first and only time I'm
going to spruik sponsoring the show on itself. I think it's a bit strange but I haven't done
it before so this is the first but I won't do it again anyway. Basically the rates I've
have got a very aggressive, they're targeted at indie developers. I think that we're about
one third of the cost of relative to total downloads of some of the other podcasts out
there. So I'm trying to be as good value as possible. And just to give you an idea, it's
sort of, it's absolutely blown my mind, but our most popular episode just recently cracked
20,000 downloads. So I'm over the moon and stoked at the same time. And a big thank you
to everyone who's given the show a chance and especially those that are still listening.
of course, and even more special thank you
to those who are in the chat room right now.
So hello chat room.
Right, that's my pre-show preamble blurb
and now we can get stuck in.
Okay.
So I have always wanted to go into this one
in a little bit more depth,
which is my code's nicer than your code.
Everyone likes to think, you know,
that they know the best way to write their software,
the best way to structure it, the best way to name things,
the best way to put it together, essentially.
And honestly, I guess back in the early days,
I say the early days, when programming was first a thing,
there really wasn't much choice.
I mean, you had machine language, assembly language,
and there really wasn't much latitude.
It was like, you know, move this there,
you know, op codes and so on.
There was no artistic license 'cause there was no art.
There was just, that was just it.
So I guess you could structure your program
slightly differently, but you know,
it wasn't object oriented.
It wasn't, yeah, it was just, you had to deal with it.
You had to speak in machine speak
in order to actually do anything.
So when there is no choice, there is no problem, right?
But as soon as you start having a choice,
you start having a problem.
So as we evolved and we added abstractions
and sort of increased that distance between the programmer
and the machine level of code,
so we had the opportunity to make the code
potentially more readable and potentially more maintainable.
And the biggest leap I think is the idea
of object-oriented programming.
And that makes the software potentially easier
to separate and improve independent components of it
and distribute amongst larger teams.
But I say potentially, when I say potentially,
I mean, a lot is about how you go about that implementation.
So just 'cause you have the opportunity
to make it more readable, more maintainable and so on,
doesn't mean you actually will just by virtue of the fact
that you can, if that makes sense.
But anyway, so yeah, and when it comes
to writing better code, before we dive in,
just get this clear right now,
it's not all about other people.
People will say, "Okay, I'm gonna write this code
"to be more maintainable for the next program
"that comes along to look at it."
Okay, great, that's nice, but seriously,
you're gonna come back to it in six months time
and you're gonna look at this code
and you're going to be a total stranger.
It'll be, I don't get it.
And I often, I get the same kind of BS
from younger programmers all the time
that I'm working with.
It's like, I'm always going to be maintaining my own code
so I can do whatever the heck I want.
You know, structure doesn't matter.
Comments are optional.
Yeah, I'm going to call my loop variables,
count one, count 1,970,
counting the count count if I want,
'cause I can, right?
Then they give you a look.
they pout and they go all sullen and fold their arms and sulk, you know.
Have you ever witnessed that phenomenon? Yes, it's been a long time because I've
been a professional programmer for, I don't know, about 20 years now, I guess.
Slightly longer than I've been doing engineering or thereabouts. So, yeah, it's-
Yeah, long enough. So, you know, when you've been working with professionals for long enough,
that kind of stuff drops away.
But certainly when you're starting out,
I think especially if you're--
so when you're starting out and you're
learning the way to do things, I think individually
you get to a level where you feel really accomplished.
And you are.
You can probably do all kinds of really fancy stuff.
And you understand the way the computer works
and your code works.
But translating that into professional space
is totally different.
Because once you start with working with other people,
everything changes.
Like you're no longer the smartest person in the room.
Hopefully, with any luck.
At least you shouldn't be.
Yeah, I have--
And so yeah, you need to learn to be
able to work with each other.
And that sort of necessitates a common culture,
or culture of the code.
like a common way of doing things or a common way of writing up
variable names or function formatting, whether it be camel
case or, you know, the underscore hyphen one, whatever
they call it. Snake, snake style, whatever the various
different styles are.
How about we just agree on indentation of your code?
Yeah, well, that's an extra horrible one. It's the answer is
spaces, by the way.
No, what? No, it is. I'll tell you. Well, I'll tell you one in
bit. Okay. All right. All right. Cool. Cool. Good. But yeah, you
need to be able to agree with all of this kind of stuff. In
order to become like an actual professional programmer. Because
you're no longer just dealing with the machine, you're dealing
with the machine and a bunch of fuzzy humans.
Absolutely. Hopefully not too fuzzy.
No, but well, I mean, everybody's got their own
different perspective on stuff, right? So exactly. It's like,
It's an extra order of magnitude in terms of trying to get stuff straight.
So if you can keep in mind the way your program works, if it's all hacked up and crazy with
go-to statements and jumping around, then that's fine.
But you need to be able to stand that not everybody's going to be able to have the same
subset of knowledge of the code base as you are.
And so you're just increasing the order of difficulty if you don't properly organize
and document your code.
- Yeah, exactly.
It's sort of, you start out and you'll create something
and it looks really awesome to your eyes.
And it's like, oh, this is the most, this is really cool.
And then with time, as time passes
and you start working with other people
and you start showing it to them,
and if it's not standardized code,
they no longer see it as, oh, that's great.
They see it as that's horrible.
And you start to appreciate
when other people actually follow all of those,
you know, all of those little details and all of the rules and making sure that the code is consistent,
suddenly that becomes your measure of, gee, that's great code.
Because you know, you're doing what everyone else is doing.
And you're actually working together as opposed to on your own.
Yeah, I should say that I'm not a style guide Nazi.
Well, some people are right.
Some people that if you put like, let's say you're writing C, and you put the you put an if statement,
and you put the opening curly brace
on the same line as the if statement,
you can either put it on the same line
or the next line indented the same level as the if, right?
Can you picture what I'm saying?
- Yes, I can, yes.
- Okay, so you can do one or the other of those.
Some people would insist on one or the other happening.
You know, in code that I,
certainly that I'm responsible for,
I'm okay with minor stuff like that.
- Right.
That's a minor style thing. It's more when you you know, if you
start naming your Objective C method names with like
underscores in them, that gets you know,
This underscore is underscore a underscore method.
Right? Yeah, that's that's important. Don't don't do that.
Yeah.
Fingernails on the chalkboard.
Yeah, exactly. So you know, like minor stuff. Spacing. I prefer a
lot of blank space. I don't like dense code.
Yeah.
It makes
Some people do.
Yeah, you're right. Denser code is more difficult to read. I try and space out logical blocks.
So, if there's a section of code that has a particular function, then I'll try and separate
it with a line above, before and after it. Yeah. And in fact, sometimes when I do that,
especially back in the day, C didn't let you declare variables that weren't within a pair
of curly braces. Okay. Because if curly braces would define a scope. Okay. But you
could put curly braces in the middle of a function. So somewhere in the middle of
the function I might put a curly brace, write a bit of code, like declare which
new variables I need, write a bit of code and then close a curly brace. So those
variables were only visible within that small scope and I could put a comment
just on top of that sort of section, that scope,
describing exactly what it did.
And now what I've done is I've encapsulated
exactly what this little section is going to do.
And if the overall function starts getting too big,
well, I've already got my sections kind of mapped out
so I can know which ones to pull out
to make their own little functions with.
- Yeah, I understand.
- I'm discovering as we try to chat about this,
how hard it is to describe visual code stuff over the radio.
But yeah, yeah, it is.
It is. It is.
And sometimes when I'm on this show, I'd give anything for a whiteboard.
But yeah, it's just not going to work.
So anyhow. All right. Cool.
And we've made a we've made a bit of a start, but I guess there's a few things
I just wanted to quickly sort of
I feel like a starting at the basics is really with with comments.
But before we get to that, actually, there's an essay that I found
when I, I don't know how long ago it was months ago.
And it's called "How to Write Unmaintainable Code"
and by a guy called Rody Green.
There's a link to it in the show notes.
It's a joke, right?
It's a joke essay, but I mean, geez, it's long,
but it is so funny.
And the funny thing is if you've got time to read it,
it's actually got some really great advice in there.
I mean, it's framed as a joke, right?
Here's, do this if you want to make yourself indispensable
because no one else will be able to understand your code.
And you read through it,
and there's just so much really good advice.
It's like, well, and every now and then,
I would now and then and now I'd cringe.
And I'm like, oh, I used to do that.
- Yeah, of course.
- No, anyway, so I recommend reading that one.
It's really quite funny.
And you can learn some lessons about what not to do.
And by, you know, obviously through inversion,
what therefore you should do.
And the other thing that if you do any kind of research
on this specific topic is the internet is absolutely swimming
with advice on how to write good code.
Jeez, it was just similar to the whole coffee thing.
You know, everyone thinks they know the best way,
but anyway, there's lots of tips and tricks,
but you know, let's face it.
The problem with that is that the internet
was put together by programmers for the most part.
So, you know, obviously that's why
there's so much of it out there, but anyway.
So we'll just focus on our opinion
and frame it that way, I guess.
Okay, yeah.
So code commenting, code commenting.
So, code comments for me are meant to augment the code such that they improve
its overall readability by mentioning details that you can't really
capture in the code itself.
What do you think of that kind of definition?
I agree.
I have to see an example.
So, I mean, there's two types of comments.
There's comments that point out something particularly tricky that's going to go on.
And then there's comments that I use to sort of tell a story.
Right. And so when I say tell a story I say let's say a function,
I don't know what it does, it collects something, it sorts them, it spits out
a like a fixed up list. So in the first half, the first third
of the function, I'll put a comment saying now we're
going to collect all of the objects that match blah
you know and then we'll do the for loop and I know modern languages have much
better ways of doing this, but stick with,
bear with me. We'll do the for loop and
we'll collect all of the objects that
match a certain predicate into the
new array.
And so the first comment will say, "Okay,
we're going to collect all the items and
it'll end with an ellipsis, like dot dot dot."
Then after we've done that, when we get
to the next section of code,
I'll put a new comment and I'll start it
with an ellipsis
and say, "After having done that, we will
now sort them all,
dot dot dot," and then I do the code for
sorting them all.
And then in the final thing, it'll be like, and now we repackage them into X format.
Like, so it would end with, it would start with dot, dot, dot, and then repackage all the objects into format Y period.
So you could read, like, if you, if you look at the function, you could read the comments with the ellipses joining them together.
And it tells you the story of what's going to happen.
Um, and from there, hopefully the blocks of code that you're describing are atomic enough and basic enough that once
you've been given the rough description, you can see how they work.
And the reason I like that kind of story, kind of commenting, is that even if you
change the particulars of the way any block of code is going to work, the top
level comment will still be valid. You're still going to be collecting them. Whether
you do it with a for in loop or you iterate with an enumerator or do
something else, the purpose of what you're trying to accomplish is at least
labeled at the top. Now obviously I don't do that for every method or function because basically
most methods should just be that in the first place but if you do have like a complicated
series of operations that are going to happen in one method that's generally the approach I take.
Cool. No I absolutely agree and I try and do something relatively similar to that and I guess
I suppose just to extend that, the things that I don't like seeing in comments are things such as
a code comment. I don't think a code comment should be the English version of the code verbatim.
No, that's horrible. I know. Yeah, it's the worst. And I've seen this. I've seen this. You know,
programmers will say, "I've got..." It's always the younger ones. Well, actually, not always. I've
I've had a couple of older ones that do it anyway. So count plus plus.
And then the comment after it is in English,
variable count is incremented by one. And I'm like, oh, thank you.
That's so helpful. And I can't put more sarcasm into that. I mean,
that's worthless on pretty much every level because the audience you're writing
for in programmers.
Yeah. By the end of CompSci 101 or CompSci, whatever,
whatever language course, the first one you do it,
If you can't recognize like a counter being incremented, you've got problems.
Yeah. You've got major problems.
Yeah. So.
No, tell it, tell the story.
You know, for me, it comes in very handy.
Um, when doing graphics processing, like I'll take an image, I'll invert the image, I'll translate it, uh, and then remap it with a different color and then transform it into something else, like scale it up or something.
Now, if you just write that out with pure graphics code, it's kind of inscrutable.
Because graphics code is like very terse, right?
It's you have like, GL bitmap do this or flip a coordinate or affine transform this.
So if you don't have a story, like a basic premise of what the code is supposed to do, it becomes hard to understand it.
Yes. Yeah, it's it's a it's very analogous to the PLC code that I write sometimes if you've got so if I create a block that's a queuing function, for example,
then I'll write that most likely in structured text STL.
And when you're doing that, obviously, well, not obviously,
but yeah, you'll have, you know, load address,
load address register one, load address two, you know,
TAC, I'm talking in Siemens talk at the moment,
but you know, you have a whole list of commands
and unless you've got in your head
exactly what data's in what register going where
and multiplying, dividing by what,
you'll lose complete track of what the hell you're doing.
And that comment, that story is absolutely crucial.
Otherwise you'll look at that code in six months time
and think, what the heck is that there for?
- Yeah.
- So cool.
So yeah, and so from my point of view,
I find the comments to be most useful at the beginning
just to lay out the basic function and that's it.
And the obvious ones are,
I also am a great believer in embedding author
and revision history in the header.
I know that that's a contentious one.
actually. What are your thoughts on that?
In the header? Yeah.
So personally, I like headers.
I know a lot of
languages don't use them.
People say that they're anachronism and modern languages
shouldn't have them. I find headers to be
compiler-checked documentation,
as far as I'm concerned.
Yeah, I think the author
and the date at the top
is fine.
I mean, it gets put there automatically, but it pretty much
all the tools, so that's fine.
It used to be invaluable. These days with Git stuff, I think people can say it's not a big deal.
Yeah, but you hit it exactly with my problem though, is that if you've got an external tool that's managing this, that's fine so long as you're using that external tool.
Exactly.
As soon as you stop using that tool, you've lost all of that revision data, you've lost all of that information.
So then what? It's kind of analogous to I want to use rich text and markdown versus I'm going to use Microsoft Word.
You know what I mean? Because once you...
Yeah.
Well, I mean, if you lose your Git repository, if you, for whatever reason, you have to check everything, you move from Git to Super Git, like it, then it's not compatible somehow, whatever the next thing is, you know, so you have to import your repository.
and for whatever reason it can't import all of the code changes.
You've just lost all of that data, right?
Like you have no idea who initially wrote the file or when or even under what circumstances, you know?
Yeah, exactly.
So, and for exactly that reason, that's why I will embed author and revision history.
You know, when you cut a revision and what comments you make is another discussion, but you know, well, is it?
No, I don't know.
Maybe it is.
Do you keep it rolling as a log in the top of the header?
They used to be pretty common practice.
I, okay.
I tend to keep it rolling between major revisions.
So if I've got something that's released, it's 1.0 and I'm doing iteration on that, you know, in the simulator, then I'll, I'll, I'll, I'll keep one, 1.1.0.1.0.2.1.1.1.2.1.3 and all that revision history.
But as soon as I got a 2.0, it's a clean slate.
That's what I can do.
Because otherwise, you know,
'cause sometimes I'll be iterating on these things,
you know, a dozen times just.
- True.
- So, and if I did that for every revision,
then I'd have an enormous lot of comments.
And yeah, it is also backed up.
So what I'll do at the end of every day
is I'll zip and back it up, but that's a manual thing.
And you know, one of the things that I hate
about PLC software is that it's not,
it doesn't support version control tools
like Git or Subversion very much, if at all.
it's all like a continuous block.
It's like you're working on a Word document.
You know, you can't just save a paragraph or a sentence,
which, you know, really sucks.
And it makes working on larger scale projects difficult.
- Okay, well, that's a great reason to do what you're doing.
- Yeah.
- Which is keep a log in the header.
- But I mean, even in the,
even in OO code that I've written, I still do it.
Maybe it's just force of habit,
but I still think it's the right thing to do.
- But one can't hurt, right?
- Yeah, exactly.
it could be useful someday. Like, well, what did I change in between this and this? And it's like,
okay, go straight to that point in the code and you figured out, okay, right. I screwed that up.
It's usually why you go back. That's usually why I go back. Anyway. So, there is something though,
I hear that the expression, and I actually sort of expounded this there for a few years,
is the concept that well-written code doesn't need any comments or hardly any comments. It's like
code should be self documenting.
I believe that to a certain extent.
I think yeah, I thought I said, I think it's an idealistic
viewpoint, you know?
Yes, yes.
Like, that can be the goal. But it's okay, if you don't get
there, it's okay to still have some comments in there.
Of course. Yeah. I mean, that's why that's why I like the COCO
frameworks and Objective-C. Yeah, it is very expressive.
Like it reads like a sentence. You have, you know, the target
of the action, the method, the message and any parameters that
are coming. Okay, it's like an English sentence. Yeah. So and
so do this with that.
We've got we'll talk about it. Yeah, I actually quite like it
too. When I first when I first got it, I got into my brain into
the Apple way of thinking. With all their frameworks. You don't
even after a while, you don't even look up the the name, you
just start typing away what you think it's going to be. And nine
times out of 10, it just pops up in autocomplete. And you're
like, yep, I knew it'd be something like, you know,
yeah, half the time, you can just guess it anywhere. Yeah,
that's it. And that's, that's beautiful. It's beautifully
consistent. It's Yeah, anyway, right. I'm gonna stop gushing
about it just for the moment.
So I mean, I mean, that, that doesn't obviate the need for
comments, of course. But it does mean that I think you get to do
more of the storytelling comments than the low level
particular comments, right?
Absolutely.
Especially with, especially with named parameters in Objective-C,
and now I guess Swift and Ruby and other stuff does it, but you
know, named parameters helps a lot in terms of helping to
document your code because you don't have to go look them up
all the time.
No, exactly right. So, okay. Um, I also had this other thing
years ago, when I was working in the reliability group at Nortel,
when we were looking at software reliability, and one of the
metrics that was thrown around for a while, and I think it still is in some circles, which
depresses me, but still, is comments per KLOCK.
I knew you were going to say KLOCK in there.
Am I showing my age?
But I don't know.
Anyway, look, the thing is that I just, from my point of view, adding comments does absolutely
nothing to make your code run better.
You know, that's it.
Bad code is bad code.
I mean, how many comments you have? So I mean, because we did
the we should we're so K lock is 1000s of lines of code. Yes. By
the way, if anybody doesn't pick that up.
Yeah. Okay. LOC. Yeah. Because for a while there, when they
started throwing it around in meetings, you haven't been in
that situation where you got a bunch of people in the room
that have been an organization for a while they're throwing
around every acronym under the sun and you're like, what did
what did you just say?
I just had a I just had a client that is in a big retail
operation. Yeah. Holy moly, do they have a lot of act there?
Oh, yeah, Nortel was so bad that they had the little book of
acronyms. I kid you not, it was literally this little thing.
And it was these guys have like an internal wiki to look up all
the acronyms.
And that's of course, yeah. And honestly, yeah, that's, that's
the modern equivalent back then. There's no wiki but anyway. Oh,
dear. Anyway, all right, cool. So
Two more things about code comments, and I think we've probably done that to death, and that is
the other problem I have with too many code comments that are specific, the specific code
comments, is that you tend to get a divergence. And you sort of alluded to this earlier on, is that
it doesn't matter how you choose to iterate, you were talking about enumeration versus
loops and blah blah blah. That point there is that, well, if I'm going to be really specific
about what this code does, and I'm going to replicate some of that in my comments,
then as you develop the code, what tends to happen is you'll be told,
there's a bug in this object, go fix it.
And you're like, right, looking at the clock,
it's like five minutes to five in the afternoon.
Now, this is if you've got a job, right?
You know, but let's say that at five o'clock, you've got to go
and watch your daughter playing hockey or whatever, right?
I don't know.
I'm trying to come up with a home working equivalent.
But the point is, you're deadline.
So you get in there, you check out, you go through and you fix the code.
yeah, yeah, yeah, good, great, check back in, go. Did you remember to update your comments?
No. And this is what happens, right? So then you get this divergence of what's in the code and
what's in the comments. And then the poor bugger that's reading the code is then you've just
doubled the difficulty because they'll read the comment thinking that's going to help them
understand it, but it's not. It's just confusing. Yeah, to lie. Yeah. It's like, well, it's just,
you just totally misled. Yeah. Thanks. Thanks for leaving me that inaccurate comment. Really.
Anyway, so those small kind of comments are
really good for when you do something insane.
Yeah, like in the Doom or the Quake engines there's a lot of weird math
tricks that have to do with the way integers work on the computer
and you can divide by a certain magic number and then shift by
one and it'll do some it'll figure out the square root or something like
there's always some weird trick. Explaining what you're going to do
with that? Very good. Because that's
completely non-obvious. But explaining
what you're doing in the Munitia when
the implementation can change drastically
is... I think not only is it a waste of
time, I think it's not just a waste of
your time to write it, it's a waste of
everybody else's time who comes and
reads it and it's just let down the garden path.
Yeah, exactly right. Exactly. So the last thing about commenting
that I want to talk about is dead code. And yeah, yeah, you
know what I mean? When I'm talking about dead code, right?
Yeah, I'm bad for this. But yeah,
oh, so am I. So okay, so when I'm iterating my code, what I
tend to do is I will take a block of code that sort of does
what I want it to do. And then I'll copy paste comment out. And
that's my way of sort of like, I'll just park that to one side.
And then I'll iterate, iterate and now it's working.
That's great.
And then I'll delete out that dead code that I commented out.
At least that's what I try to do.
Often when I'm going to, when I'm done, like I'm totally done with something,
I'm happy as I'll go through and I'll do a cleansing or purification,
purify my code and just go through and strip out anything that's the dead code
because the dead code sort of creates that confusion for programmers,
and even for yourself going back over it,
was this commented out for, why was that left in there?
Was that part of an experiment or is it a branch
that you kind of were chiseling away at
and you're gonna come back to or what,
why the hell is it there?
So.
- So if I comment, well,
if I comment a blocker code out,
often it's for testing something.
Like I'm like, okay, I wanna get rid of this chunk
and see what happens.
But I'm getting much better at this,
but it used to be pretty bad because,
you know, versioning systems weren't what they are today.
So I'd comment out a chunk of code
that I may want to come back to.
Like I may have a totally different implementation
of a function or two sections of a function.
Generally what I try to do when I do that
is put a comment on top of the commented out code
saying exactly why it's commented out.
so that when I can come back to it in the future,
I'd know what's going on.
And then every now and then I try to do a cleanse.
- Yeah, that's it.
- These days I'm relying a lot more on source control
and just being able to go back in time and find.
- The tools are great.
- 'Cause I don't wanna, yeah, yeah, exactly.
I mean, what happens is I don't have something
that's working now and then I'm like,
oh, I can try this different approach
that's gonna be faster or whatever, more efficient,
whatever thing I'm particularly trying to optimize.
And then ditch a bunch of old code
and then find out that the new one is kind of broken in some way and have to reintroduce something from the old one
and not have it to hand. Do you know what I mean?
Yeah.
And without version control or proper version control, that is a huge pain in the ass.
And that's why you just ended up with a bunch of dead code.
These days, it's easier to go back and see what revisions were made and just pull the right stuff forward again.
Yeah, that's true. As I was saying, yeah, the tools have come a long way.
And I guess some of the way that I program is force of habit.
And that's and I'm not moving with the times and using some of the tools that are available.
So I acknowledge that.
But even with those tools, dead code is something that I still come across.
And, you know, I mean, the other form of dead code, which is far more subtle, is the objects with a bunch of methods that are never called.
and you're forever wondering, you know, do I need, is this part of the framework or isn't it?
What will, you know, because you're, I remember there was two similarly named objects that I was
working on and I even got confused, this is, you know, years ago and I even got confused. I'm like,
okay, so which one was the one I was working on and which is the one that I left for dead? Right,
so before we go on any further, I think we might just take a quick break to talk about our first
sponsor which is Solver and that's a calculation app by Aqualia for both the Mac and iOS. It's
great by the way, I use it every day. Yeah it's fantastic isn't it? Once you start using it,
it's like how did I not, I mean I've just given up, there are a whole bunch of things I used to do
through Google search and I just do them through Solver because it's just so much quicker.
No it's one of those apps I'm jealous of because I'm like oh man I wish I'd thought of this. Yeah
I know. So okay all right so I'm careful to call Solver a calculation app because it's more than
than a calculator and it's quicker and easier to use in a spreadsheet. You
just start typing away and in real time the answers will show up in the
right-hand pane. So let's say you want to add two numbers but one's in
hexadecimal and one's in decimal. Well you know type 0xFF + 10 and there's
your answer and you can have it in whichever you like. So yeah it's just
that easy. Converting currencies. Okay so I got 10 euros plus 10 US dollars in AUD
for Australian dollars. Boom! You get the answer in Australian dollars. It does all the currency
conversion, gets the rates and so on. It's just magic. So crazy things. If you want to do crazy
things you can. Yeah like if you want to know how many minutes you've been alive. Okay that's a
crazy one. Try 38 years to two weeks as minutes and it turns out that I've been alive 20 million
six thousand two hundred and twenty nine minutes or so. Something like that. Anyway yay. Sometimes
Sometimes what something I use it for for pragmatic is the conversions between Celsius and Fahrenheit
So if you type in 120 F in C, it'll give you that in Celsius. Boom done
It's just it's just that easy and that's just a handful of examples, you know
But you type them in as you would think them and you get an instant result
You can link different results together easily to create more complicated calculations
You can share you're working in your results list goes on and on it is awesome
So anyway, if you're not convinced,
then why don't you go to the URL in the show notes
and check out the Mac version.
It has a 10 day smart trial,
meaning you only pay for the days
that you actively use it for.
So that's 10 days of total usage time.
So for me, I used the trial for three days
and I loved it so much I just bought it.
It was just that good.
So Solver is available through the Mac App Store
and the iOS App Store,
and there are links to the apps from Aqualia's website.
If you use the URL in the show notes,
it'll help out the show.
So please use that URL in the show notes to learn more about this helpful little app.
So thank you to Aqualia with their great app solver for sponsoring Pragmatic.
Highly recommended. And they're not paying their dime.
No, it's a great app. It really is a great app.
Yeah. It's like I said before, it's one of those ones that once you start using it,
you're like, how did I not, how did I not use this for forever?
Cause it's just that good anyway.
Okay, so it's related to commenting, but it's not commenting,
it's variable naming. So, we got to talk about this. And in my
parlance, for example, in PLC land, they're referred to as
symbols or symbolics. But you know, same diff kind of thing,
right? So, I think that the overarching rule with naming is
verbosity is good within reason. I think that if your variables
end up being 150 plus characters long, you're really writing a
sentence, you probably need to work on that and shorten it a
bit. But yeah, yeah.
It's got to fit in a tweet.
That's the new, that's the new measuring stick, is it?
Yeah. It used to be that they had to be less than like, what,
eight characters. Now it's like, yeah, variable names go over a
tweet length. That variable names, method names may go a bit
longer. Maybe an objective C, even that's really pushing it.
Yeah, well, I think it's Yeah, well, put them in the same
bucket. Why not methods, variables? You know, why not?
I mean, it's just 140 minutes is a good guideline, right?
Yeah, yeah. But well, if only because a variable name is going
to be describing one thing, while a method name is going to
be describing a process and a process is by its nature more
complicated than one thing.
Okay, yeah. Okay. So let's say you got a method that's
add number, you know, with number, from number, you know, whatever. Yeah, okay, that's true.
Well, you know, it's like connect to network X using radio Y, on frequency Z, like, you
can get like, pretty long.
Yeah, I suppose that's fair enough. So definitely watch the verbosity, but it's okay to be verbose
because that's what the tools are there for. There's no prize for having a short variable
name. And one of the things that I've been frustrated with for years is knowing how good
the development tools are, for example, with Xcode and then going into PLC land and dealing
with the fact that you're still restricted to stupid things like 24, 32 characters for
symbol name. And it's what century is this really guys? And this is the thing that really annoys me
is that you know the state of the art of software development in PLC land is abysmal. So compared to
what else is out there. So I live and hope that someday they will step up and realize that yeah
it would be handy to have more than 24 characters. Is there a reason for that? Like they just don't
invest in the compile technology or it's just there's no pressure to I honestly don't know I
know I can speak to one product because I know the answer for one product and one product is called
SciTech and or as it's more affectionately known SciTech it's anyway it's built on DB4 and every
time you change the column width in DB4 you have to change the way it's compiled because everything
is all based on fixed width columns and it's just ridiculously old. No, there's no link
list, there's none of that stuff. So, when they change and add more characters, then
it increases the size of the database file for the variable list and that then causes
a backwards compatibility problem. So, every so many years, like every four or five years,
they've said, "Okay, well, we've extended it now to 32 characters, thumbs up." And I'm
Really? Only 32?
Yeah
Goodness me
Well I guess if they just, if they went to 128
then everything would balloon right? You've got very limited RAM so
Yeah well
But the problem is the symbolics for example in a Siemens PLC aren't stored in the PLC's memory
And yeah it's stored in an offline file so you just download the raw code
And what you see on the front end is that it overlays the symbolics over the top so that it's human readable
So in that case, there's no advantage, disadvantage.
And with SciTech, that's SCADA, again,
yeah, it's sitting on the computer and I've got a five--
- Oh, that's weird.
- Terabyte hard drive.
Yeah, it's BS.
- So these symbolics never get onto the device.
- No, well, not all PLCs are like that.
Some PLCs, they do.
They actually download the entire project to the memory
and some PLCs will have it segregated.
So you'll have like a program memory
and you'll have data memory.
So you download, you're literally doing a split download.
you're downloading compiled code to the run to the to the actual
live program memory. And you're downloading a copy of the
project for archival purposes and retrieve a later that has
everything in it. So depends on the PLC. But still,
wait, that's cool. So you could you could pull out the entire
source code for the for the programmable bit. Yeah. Oh,
yeah. Yes, that's cool. Well, because it goes along with like
the physical object, right? Like, you can that's right. One
of the things that sucks, though, it's cool. That's a good
- It is a good idea.
- Yeah, not all PLCs do it, but you know, for example,
some PLCs, I think the Quantum's or the Premium's,
I think the Schneider's, I'm trying to remember,
it's been a while, but if you don't have to have
a memory card for some of these, it's optional.
And if you don't have the memory card,
then you don't download the entire project to it.
And then you just download the compiled raw code.
At which point then, if you ever want to upload it,
you'll upload it, but you'll just get raw memory addresses
and raw function calls, and you'll have like,
what the heck is FB165 doing with M7.3?
Oh, good.
- Right.
- Yeah, it's, and believe me,
that's the worst kind of call out to get.
You get a call out at, and I haven't done this for years,
but I used to get these sorts of call outs
where the machine stopped working, it's two in the morning,
you know, they're losing thousands of dollars an hour,
and they're like, right, fix it.
And you're looking at this machine,
you've never seen it before.
You log in on your laptop,
and there's no backup of the code.
You upload it, and you're looking at this thing,
and it's like, right, I'm staring at raw machine code.
Now I have to figure out why.
- The machine isn't running.
- Oh, that's where daddy drinks.
- Yeah, damn right.
(both laughing)
So yeah, I'm out of that game at the moment,
but I'll tell you what,
it was a certain buzz doing that, I will admit.
But anyway, that was a while ago.
Okay, I digress, I digress.
So I need to do another,
I need to do an episode just about PLC programming
and all that stuff.
I'll get to it someday, but anyway.
Okay, so I think embedding the variable type
into the variable name is sort of a pseudo common practice, would you say?
Yeah, like B for brilliant.
Well, Hungarian notation, right?
Not familiar with that terminology. I have to put my hand up. I'm sorry.
Okay, so I forget to name it a guy, but he was a dude at
Microsoft back in the 80s or early 90s. And he
popularized this way of naming
variables which included type information at
the beginning. So if you had like a
window handle, it would be H, like underscore
not underscore, lowercase H W N D
and then a capital which would start off
your window name. So you'd have
Hwind main window. Do you get what I
I mean? Yeah, I think I do. Yeah. Or like, so maybe more
familiar would be like, if you have like an unsigned int, it
might be understood, like, lowercase u, i, and then a
count of indexes or something. Yeah, count of people. Yeah,
that's it. Yeah. That's that is exactly what yes, it's exactly
what I'm talking about. So there you go. I learned something new
for the day. There you go. Cool. They didn't know that I actually
had a name. I think he created it, which is but like, whatever
could be something else. One of those things that his name has
been attached to it ever since sort of thing. Yeah. Cool. Well,
The thing is, I was looking at this recently on a project that I'm currently working on,
and I was reviewing someone else's code.
And one of the problems that they've had is the coding standards available.
You know, read from that comment what you will.
But anyhow, what they did is if you're going to do that, do not mix your naming schemes, please.
So what they did is they said, OK, well, we're going to have B for Boolean, I for integer.
OK, so far, so good, shrug, whatever.
And then they're going to say, we're going to have S for set point and P for process value.
But they're going to put it in the same character position as in the first character.
So I'm like, OK, so if I've got a set point that's an integer, which way around is it?
Is it IS or is it SI?
And they're like, well, because not every variable is going to be a set point, not every variable is going to be a process variable, process value.
So, what they'd done is they essentially blended the two naming schemes together.
So, it should be consistent, like the first character.
If you're going to do this kind of abbreviation thing, which I guess is okay up to a point,
then, you know-
Well, you need an order of precedence, right?
Yeah, exactly. And they hadn't defined it.
And I'm just, you know, so, yeah, think it through is, I guess, my advice if you're going to do that sort of thing.
Because I think that there's a diminishing return up to a certain point.
Because some languages that are, what's the expression?
Heavily typed or the,
so a language like,
in a lot of instances,
you can read the variable in context
and figure out what it is.
And honestly, I find sometimes the abbreviation concept
to be a little bit redundant.
And I try not to do it myself.
I have done it to be consistent usually
with other people's code, but it's not really,
I wouldn't necessarily recommend it.
But I know why people do it.
But anyway, so.
- I hate it.
I don't want to do it.
- Yeah.
- I think it's a bad idea.
- Yeah.
- I think in some languages, maybe it makes sense.
Maybe more for your stuff.
- Potentially, yeah.
But that's better.
- In higher level languages,
no, I don't think it makes sense.
I think a variable name should describe
what the variable represents.
Whether that is in a float or a double,
that may change over the course of the development.
Oh yeah, sure, absolutely.
- Like let's say you've got a, I don't know,
location in world, in a float,
and then you discover that floats
don't kind of accurately represent
the size maps that you want, so you move up to doubles.
- Yeah.
- You really don't want to go and have to rename
every single variable everywhere.
- No.
- 'Cause that would be really annoying.
- And search and replace is the blunt hammer
that will wipe out otherwise working code.
- Yeah, so then I get what you do in C or something
It would be like you type def something to be,
I don't know, like CG coordinate float.
But then what do you prefix in front of all of your variables?
Like you put coordinate, so you've got C, O, R, D.
It just gets silly fast.
And it's just a bunch of line noise, and it gets annoying.
And again, the tool should be doing this for you anyway.
They should be helping you out with this kind of stuff.
I feel the same way with a lot of programmers,
and this is even inherent in Objective-C now,
but a lot of programmers in C++ at least,
would put M in front of the member variables
of their classes.
- Yeah, yeah.
- So that when they were being interop,
when they were being operated upon inside methods,
you could tell if a member variable was being messed with
or something defined locally,
like a parameter or something being defined locally.
Objective-C has this kind of built in now
where if you don't specifically synthesize a property,
you automatically get underscore property name,
which is how you know that you're messing
with something directly.
I'm not a fan of that.
I really don't like the M prefixing stuff.
Underscore a little less so
because I usually just do self dot,
so it's less of a big deal.
But the M stuff just reads like line noise
And I honestly feel that what we're kind of using code readability.
Yeah. Yeah, because if you because the tools aren't good enough, right? Like, the tool should be color highlighting and all of that or telling you exactly what you're doing wrong or pointing out mistakes, right?
Yeah, well, exactly. So I guess from what I'm, what bugs me about the practice is that if people do it, they'll use like M for method, like I say, I for integer, B for Boolean, blah, blah, blah.
And it's sort of that implicit, then they'll have the rest of the variable name or method name in fully described in text.
So what is it exactly about the type that needs to be abbreviated that makes that different and special and OK?
you know if you're gonna write boolean write boolean you know it's a high level
yeah which yeah if you're really gonna go down that road why do it I mean in 6
to 12 months time let's say you've come up with a naming convention and that
naming convention is you know whatever it is and that naming convention is Q
short for qubit I don't know whatever are you really gonna remember in 12
months time what the heck the Q stood for because I'm gonna bet you're not
unless it's something that you it's all your code and you know again you're not
working in a team you're in isolation and you come up with your own naming
thing just because you can and that's just anyway cool yeah so I mean again if
I operate in anybody else's code base I respect their their their style yeah
just for my own and as a sort of philosophical point,
like I don't like mixing up type information
with the name of the variable.
And like you're saying,
well, like I was saying before with the coordinate thing,
I would rather put a unit coordinate
than C-O-R-D unit.
- Yes.
- You know, like the--
- Absolutely.
- Just write it out.
- Yeah, and another thing--
- If you have to.
- Absolutely, another thing about writing it out too
is the separation of names.
So yeah, please, we said before, do not use underscores.
That just looks so horribly horrible.
But--
- Well, okay, I have a different opinion on that.
- All right.
- Oh, wait, so in Objective-C methods,
yeah, don't do that, for sure.
- Yeah, okay, but what about in variable names?
So you're happy with them,
so if I wanna have variable names,
this underscore is underscore my underscore count.
- Well, okay, so here's one thing I did years ago,
and I think it worked pretty well.
One of my-- the first game engine I was lead on, actually.
Anything that you shouldn't be calling,
unless you knew exactly what the hell you were doing,
would be written in sort of old school underscore style.
Like all lower caps, all lower case, underscores.
Structs would be so and so.
Like it would be like, I don't know,
vec3_t, that kind of stuff.
And on top of that would be something
that looked a lot more like what's it called?
Oh, Core Graphics.
Wow, Core Foundation.
Like a very Core Foundation looking API on top of that.
And the Core Foundation API could call
into this lower level stuff as needed to get stuff done.
But if you were just a general programmer,
you would only be operating at the core foundation level.
And the reason I did this,
and the reason I think it worked out really well,
is that it was basically impossible to visually,
like you had a very visual cue
that you were dropping down to a low level.
And if you knew, if you were messing with one
at some other level, you knew you were screwing up.
Certainly if you were in one of these,
if you're writing a function,
'cause there's all functions back then.
if you're writing a function that called anything that was all caps,
like, or that did, that looked like a
core foundation function,
you were screwing up,
because you were visibly going up the stack in terms of
abstraction.
Yeah.
Do you know what I mean?
Like, so the underscore one was like a visible way of being like,
this is the lowest level of abstraction.
If you're calling this from on top,
Okay, maybe you've got a good reason, but if you're calling the other way, you're around your your script like don't yeah
Definitely don't do that
So as long as they're consistent like and these were functions keep in mind I would never do that with objective C code no
Because that is you've read objective C code properly like it's it's got its own culture and language
So so that's that's and that's fair enough use of an underscore that that's cool
But I guess what I was one of the things that I was sort of getting at is that it's okay to
For the for the one with a better way of saying it's sentenceifying and that's actually I don't pretty sure that's actually not a word
But anyway, when you're when you're making your variable name into a sentence of sorts be to help describe it
Yeah
Just using capital letters to didn't to break apart the words
Because there's nothing more frustrating to me than looking for a jumble of letters as a variable name
Yeah, irrespective whether this is underscore at the beginning or not to denote its level in the code, but I guess more so about-
Oh wait, wait, wait. No, I'm sorry. I think we misunderstand each other.
Oh, sorry.
When I was saying underscore,
in camel case you use the capital letter to break apart
the words.
Right.
In the case I was talking about, I would use an underscore. Like everything would be lowercase and I would use an underscore to break apart the words.
Okay, I'm apologizing. Okay.
No, no, don't apologize.
No, it's just because it's hard for me to communicate, right?
Yeah, you're right. This is actually tougher than I thought it would be to talk about.
But yeah, honestly, can I just put my head up and say I still wouldn't write like that, but that's okay.
Maybe that's personal preference.
No, so I wouldn't, I don't either. That's why it was visibly, it's like the most Unix-y, level-y kind of stuff.
Yeah, exactly. It's got a very Fortran sort of feel to it.
But anyway, I, yeah, so I guess what I'm railing against is all lower
cased or run together.
Like for me, that's the worst.
Please, God, don't do that.
It's illegible.
Yeah. And I know this is tangentially related, and it's the wrong in chauffeur that, but still,
when you're doing a hashtag on Twitter, try and do it there, too.
Take your learnings from programming and breaking it up by
using capitalization and apply this to your,
your hashtagging exercises in your spare time.
Because there's nothing worse than reading a hashtag
and you're trying to break out,
okay, is that supposed to be an a,
like an a or is that on or if?
- Yeah, that's the worst.
So, wave Michael Johnson,
Pixar guy had a good one the other day.
It was co-designing and co-designing.
- It's the same, it's spelled the same way.
- Oh yeah, hey cool.
- It's the exact same word,
they mean two totally different things.
- Oh, that's brilliant, I love that.
- One's kind of fun and the other one
is definitely, definitely not fun.
- No, no, no, that's right.
Okay, cool, well, before we go on,
I'd just like to take a quick moment
to talk about our second sponsor for this episode,
and that is Space Nation.
And they make a neat Mac and iOS app
for the iPhone and iPad called Hue Party,
that's H-U-E, Party.
and Hue Party can control your LIFX or your Philips Hue bulbs.
I thought it'd be an interesting fit for the show,
seeing as how LIFX have been a previous sponsor of the show.
And still follow up as well for this month.
So it's free to try.
It has many of the same features that you get out of the standard LIFX app,
such as candle flicker strobing, color change,
based on the music playing through your device's microphone.
But in addition, there's two interesting little twists this app has,
is if you tap and hold the Hue Party icon
and shake your device, it turns the lights off.
Also, if you tap and hold the icon
and turn your device in the air,
using the gyroscope and accelerometer,
it changes the brightness setting of the bulb.
I could only really test it on a LIFX bulb
since I don't have any of the Philips Hue bulbs,
but Hue Party found my LIFX within five seconds
and the rest was pretty straightforward.
The best part is it's a free app to try
on both of the app stores,
the Mac App Store and the iOS App Store.
So try it out and if it works well for you
or if you have more than two light bulbs you wanna control,
then the $3.99 US in-app purchase will unlock
the unlimited lights to control in your network.
So please visit this URL,
hueparty, all one word, .com/pragmatic
on your Mac and iOS device
and follow the links to the App Store from there
to help out the show.
You can search for the app in the store,
but if you use that URL in your browser of choice,
then that'll help the show out.
So thank you to Space Nation's Hue Party app
sponsoring Pragmatic. Okay, I want to talk about something that Joel Spolsky wrote about,
and he's written so much good stuff. That's a rather generic comment. It's just hard to
know where to start with this. But yeah, and this one was actually an article was written
back in 2000. But the thing is, kind of like the mythical man month, it's timeless. So,
I kind of, yeah, anyway, I love his stuff.
Anyhow, he doesn't write so much anymore though.
- Oh yeah, he's doing great.
Very smart guy.
- Yeah, oh yeah.
So, okay, it comes back to,
and this is now getting more into coding practice,
but it's still important.
And that is perfecting functions or objects.
At least that's, I guess, the title
of what I'll sort of lead into this,
because when you write an object or a block,
I'm a firm believer that you should spend
as much time on it as you can and then leave it alone.
So perfect it as much as you can, then leave it alone.
Try not to extend it too much.
Don't refactor it too much
because you get buried with it.
If you've been buried in code for weeks or months,
or hopefully not months,
your brain is so connected with that code,
it'll make sense.
But if you take a break and then you come back again,
I've found that you can never really quite get back
to the state that your brain was in when you wrote it. Have you
ever found that?
Yes, very much so. I think that's one of my major problems
with C++ actually. Yeah. Is that I think, well, there's so many
tools available to it that I think some programmers begin to
fetishize the writing of the code. And how, not abstract, but
how not even clever, but just how concise and, I guess,
smart it feels to have written that code.
I fear the same may be true of Swift,
because Swift does some of the same things.
But no, I totally agree.
I mean, the purpose is to build a product, right?
Yes.
And I think you have to keep that in mind.
So you write your object to do what you need it to do,
and then move on, and then write the next object.
And if you have to come back to add some new functionality,
then perfect.
I think what happens when you're starting out
is that when you write that object the first time,
it's not good enough.
It's screwed up in some way.
But with more experience, you get
to write these things one off. And they will have a design
sensibility that will last throughout the lifetime of the
project, you won't have to go back and change up a bunch of
stuff.
Yeah, exactly. And it's one of the it's this, there's this two
effects that I see is the whole, I'll just do enough to get it
working. And then I'll move on because I've got to get this
thing out. And yeah, then there's the effect of well, the
block, the function object, it almost does what I need, but I
I just need to do a little bit more.
So I'm just going to go inside and mess with it again,
six months later or something.
And that's when I go, please don't do that.
Because if you've put in all this effort
and you've done all your test cases
and it's as solid as you can make it,
you move on and then you just leave it alone.
Because I find that that's where things really start.
That's when you start to get crazy bugs
is when you go in six months later
and you just extend it just a little bit.
I mean, and obviously, okay, this is not,
And I don't mean this to sound,
geez, what's the word?
I was on either or choice.
I'm not saying that you can't extend it.
I'm just saying that there's other ways of getting around it.
Like you could either, you could potentially clone the block,
you could put a wrapper around it,
you could pluck out certain features.
I don't know.
There's other ways of dealing with it.
But, you know, and honestly,
I'm just a great believer that once code has been written
and dealt with, then it's best to leave it.
And one of the pull quotes,
just from the article I've linked in the show notes
by Joel Spolsky from 2000 was,
"It's harder to read code than it is to write it."
It doesn't matter who you are, that's a reality.
So once it's written, yeah, anyway.
So.
- No, so I totally agree with that.
I think that is one of the arguments
in favor of test-driven development though,
is that it gives you a bit of latitude
in order to go back and make sure
you're not screwing anything up.
True.
So in theory, I'm a big proponent of test driven, driven
development in practice. Not many of my projects really lead
themselves to it. Or at least I haven't been able to figure out
how so.
Yeah. Yeah, it's it's one of those. Yeah. Sometimes I catch
myself talking to the junior engineers and saying, Yeah, you
need to test your code, you need to test your code. And then I'll
quickly run in and write some code. And I'm like, I really
need to test that. And you think, well, that the automated
testing, right? Yeah, yeah, yeah, yeah. Where you can, I
mean, obviously, in my case, there's some tests I simply
can't do automatically, because of the nature of the SCADA and
the PLC software that I use is that they're not lending
themselves to that. But, you know, if you have decent
development tools. Sorry, that's kind of the bane of my
profession really is the state of the software just depresses
me daily. But anyhow, okay, so once you once your code is out
there, there's this this terminology I like to use called
soak time. And I don't know if it's an engineering term. It
actually comes I think more from electrical engineering, isn't
it? Well, yeah, the idea is it's if you've got a product, like a
but we see this at Nortel.
So when we're making the MetraCell BTS
or any of our electronics products
is you put them into an oven
and you run them at a high temperature.
And they call that a heat soak.
And it's designed to accelerate any failure rates
that you might have.
If you're really, really so inclined,
you would get a temperature cycling oven
such that it would ramp the temperature
at a temperature profile.
And that would simulate the effect
of the devices being in the field.
because there was for quite some time,
and even still now, there are lots of places
where you don't have temperature
and humidity controlled environments.
So you're putting these cars into a base station
and it's out in the sticks during the winter time,
it's quite cold during the summertime, it's quite hot.
- Yeah, if you put something out here in Canada,
like we range from like minus 30 in the winter Celsius
to like plus 30 in the summer.
- Oh yeah, man, I felt it.
I was in Calgary, man.
- Yeah, yeah.
- Pretty big range of temperatures.
- Yeah, massive, massive variation.
But I mean, the daily one is just as bad
and I'm sort of treading on reliability engineering here.
But the idea is that you get temperature cycling
and what we are different.
Temperature cycling, you get differential expansion rates
and that introduces fractures and blah, blah, blah, blah.
Point is that heat soak is,
and soak time is a concept
that I sort of ripped off from that.
But I have heard it used in the context of software as well.
And it's sort of used interchangeably with field time
or real world use.
Or what term would you use?
It's out there, it's in use.
What terminology would you typically use to describe that?
Well, automated unit testing.
No, I mean, your code is out there in the field. It's been
live in use by customers for 12 months. What would you refer to
that time as?
Oh, point release.
Yeah, okay.
This is why I had to rip it off.
for 12 months. There's no, I don't think there's,
I don't have a ready term for that.
- Okay. - So sometimes great for me.
- Okay, cool. So we're gonna run with soak time.
There you go. I've just dragged that in
'cause it works for me.
And the idea is that it's out there.
It's been soaked in real world use,
but not physically wet.
Anyhow, so once the code is out there in the world,
it's been heavily used and exercised.
And I guess that's the caveat, exercised.
Okay. - Yeah.
I love it when people say,
oh, we've had 5,000 downloads of our app.
Oh, but no one's used it.
- Yeah, it doesn't mean anything.
- No, no one's used it.
It's like, well, they've used it for five seconds
and then it's crashed and they stopped using it.
And it's been out there for six months.
So it must be solid.
No, no.
I mean, actually exercising and using your code.
So hopefully at that point,
the more bugs have been fixed
because you'll be getting those reports back
and it's like, okay, so it's crashing a lot less now.
And yeah, it's solid and stable.
My code base is nice and robust.
So the longer the soak time, the longer the stress testing,
the better your product is inevitably gonna be,
the better your code is inevitably gonna be.
And the longer that goes,
the more it has to reinforce in your mind,
don't mess with the code.
'Cause it's, you know, the temptation is,
oh, but it could be done so much better if,
well, no, no, no, don't do that.
And another great pull quote from Joel's article is,
"When you start from scratch,
there's absolutely no reason to believe
that you're gonna do a better job
than you did the first time."
And there seems to be this-
- I'm like 99% of the way there with them.
- Yeah.
- In fact, that's right.
In reality, I probably totally agree with them.
In theory, it's like if you wrote something five years ago
and you come back to it, you could be like,
"Yeah, that's, it probably could do better."
I still don't think you should fix it,
quote unquote, fix it.
I mean, if it ain't broke, don't fix it, right?
- Oh, yeah, sure.
But-
- Kind of just sums it up, so.
- Yeah, exactly.
I just, I find that the idea of people just say,
"Oh, well, we're gonna tweak this and make it better."
And I'm thinking, A, is it broken? No. Okay. So there is no
B.
Well, so that's, I think that's a matter of what you're focusing
on. I think the correct thing is to be focusing on the product
or the the usefulness towards the customer. Primarily. Yeah,
fair enough. But I think some people see code and they're
like, Oh, I could do it better if I rejiggered this algorithm.
That's like, well, does that solve what problem?
What real world problem is that solving for anybody?
Because if the answer is none, then don't do it.
If it's working now, all you're doing is potentially introducing bugs.
That's it.
You're not actually solving a problem with anybody.
You're potentially creating them.
And all of that time that you spent being fancy and then fixing being fancy, it's
time that you haven't spent fixing other real problems that real people are facing.
So I think it's a net loss, except for maybe your ego that
you made something fancier.
Yeah. And the problem is that that's that's that whole, the
last bit of what you just said is, there's a belief that
you're going to do it better or fancier the second time around.
And inevitably, I don't think that's necessarily true. Not all
the time, most of the time, it isn't. So it's just that
thing.
Even if you do, who cares? I mean, you haven't fixed any more
problems. Does it matter if it's fancier or not?
Yeah. Someone once said, I wish I had the exact, the person that
said this, but refactoring is a loss leading exercise or
something like that. So, you know, I don't know.
To be clear, I'm not against refactoring when it's needed.
Oh, sure, sure.
You just have to identify the need rather than the desire.
Yeah, I mean, if you find those two big differences.
Yeah, exactly. I mean, if you fundamentally messed up the
structure of your object, and you need to add a bunch of
functionality, and there's simply no way to do it any other
way than to rewrite it and refactor it to include that
functionality, you know, okay, fine. That's fine. But honestly,
that doesn't happen as often as you might as well, once you've
got code that's out there, I find it doesn't, that doesn't
happen so much. So anyway, yeah. Okay, so I've got a few more
points. Small ones. So grouping data into structures, and this
may be, you know, if we're talking about object oriented
code, I keep saying object oriented, because, you know,
Just sounds cool, I guess, whatever.
Grouping your data into structures is something that is a choice in a lot of,
you know, PLC platforms.
But it just for me, it makes finding data you're looking for much quicker and a lot more
sensible rather than just having, you know, and there's how many people have written
articles about, you know, global variables versus, you know, and global is evil.
I think global is OK up to a point, but you should do everything you can to minimize
global and pass around what you need and group it, because
otherwise it's really hard to find what the hell you're
looking for. And I realized that I've just crossed about three or
four different programming styles in the last five
sentences. So if that's kind of risky, but yeah, thoughts,
comments?
I think that's almost unarguable.
Structures are in terms of globals.
I mean, that should be exceedingly rare.
Yeah.
Uh, you know, in objective C, all of the classes are effectively globals.
Okay.
That's one thing.
Sure.
Uh, the application is a global because, you know, guess what?
You have to tell me one process running.
So that just makes sense.
Grouping data into structures is a no-brainer, as far as I'm concerned.
I mean, I've been doing that since Pascal, for as long as you possibly can.
Even before I could wrap my head around what an object was,
I thought structures were the most obvious way to go around getting things done.
Is that really even up for debate anymore?
Do people argue about that?
No, I don't think it is.
And I guess this is one of the other problems I had when I put this in the notes to talk
about is that, at what point is this just given and understood and we've been doing
this for long enough now that we just accept it?
And maybe that's just one of those and we should just move on.
So let's just-
So, well, one book that I wanted to bring up while we're chatting about this is an old
book called Code Complete, which if you haven't read is
brilliant. I think I've got like three of them around the
house somewhere. Okay. It is a book by oh my god, I'm going to
blank on his name. It's not Charles Petzold. Hang on. I got
to Google this now. I can't believe this. Steve McConnell.
Steve McConnell. I'm going to guess I haven't got there yet.
Yes, Steve McConnell, brilliant guy, Microsoft Press, 1993.
This book is terrific.
It's written in 1993, mind you, so I mean, keep in mind that,
you know, it may be a little bit outdated.
The second edition is 2004, so, you know, maybe that's a little bit more modern.
But it is a terrific book that lays out all of this kind of stuff.
In fact, I'm pretty sure there's a chapter about exactly what you just talked about.
I highly recommend it to anybody.
I gotta put my hand up to say I haven't read it and I am now going to read it.
You really should.
It's still worth your time.
I mean just skim through the... so if you go to the Wikipedia page, right on the bottom,
there's an external link called "Code Complete Checklists".
If you just scan through that, it's literally asking most of the questions you're asking
now.
Cool.
All right.
could you could look up structure and be like and so and so for the checklist
format is basically it's like you're writing a structure have you thought
about this this this this and this and if you can check off all of those boxes
when having made that decision that set of decisions you can feel confident that
you've got a pretty decent design yep and you don't have to check all of the
boxes he's it's just more of like a mental like you know it's a mental model
of looking at things. And if you don't, if you can't check a box,
it doesn't mean you're wrong. It just means that you've
considered why you can't check that box. So it's a good way of
thinking about stuff. And that covers inheritance and
structures and globals and all kinds of stuff like that. It
even covers commenting, which we talked about before.
Cool. Yeah, and I mean, I will I will put this out there. This
is this this whole episode talking about, you know, all the
different things that we think go into making better code and
do's and don'ts and so on. This is not new, this has been a well covered topic and so
on but I hadn't covered it specifically on the show and I thought it's definitely worth
exploring from the show's point of view. I'm going to add that to my reading list and I
will get to that and I'll let you know what I think.
It's actually a compellingly quick read. You'll probably just tear through it. It's well written.
cool. Okay, so a few more points that I had and then I'll leave it open for any
others that you wanted to quickly mention and that is that breaking
the code down. So break it down. That was terrible. Okay, so when you're
about to write and this is the thing when you're about to write your
program, your code, whatever, just take a little bit of time up front to map out
roughly the objects or blocks, structures, functions that you're going to use. It
doesn't have to be to the nth level of detail necessarily, but as the project
gets bigger and you've got more and more people on it, for goodness sake you
absolutely have to do this. But it's still a very useful exercise if you're a
one-person show. And on bigger projects as well, just write an interface
spec so that people know what the hell to expect from your objects, from your
from your functions and so on. Because if you're going to work on this object,
they're going to work on that one. Yeah.
You've got to know how the hell the messaging is going between them.
You've got to define that. You just have to.
To me, that's the value of a header file.
Oh yeah, sure. Absolutely.
Because you get to put exactly what's public and you get to comment on it.
Yeah, absolutely. And I'm not saying the format in which you need to document it.
I mean, in my industry, we typically do it, unfortunately,
in a Word document, but hey, whatever. I can't,
I can't stop them from using that.
But this is not a word versus pages comment.
This is a, I'm a great believer in,
well, why don't we just put it in the code
and distribute the framework and say, right,
here's our framework of the code
and you go and figure it out from that.
But nevermind, that's fine.
One day I'm gonna win that argument, but nevermind.
So yeah, so yeah, definitely break it down.
Like MC Hammer, God.
- It's okay.
- Bring it up again, you know, why not?
second time around the joke is funnier. Anything else to add to
that one guy?
I love MC Hammer. I know, I think that's good advice. So,
for me, I think if I mean, I don't want to say do the snaps
all the time, because that's far from the truth. But once
you've had a lot of experience, you don't necessarily need to
putting that much time up ahead because you know the general structure that
you're gonna do. Yeah. Do you know what I mean? It's like, oh this kind of problem,
okay here's what I'm gonna do. And it's a common approach that's not
just for me, but it's what I've learned from working on other projects that are
similar to it. So you don't necessarily need to write out like an object graph
specifically. Certainly you do when you document it for other people, that's
great, but if you're using common patterns and common approaches then and
you're not doing anything fancy pants, then you know you don't necessarily need
to spend that much time up front. That said, you know, measure twice, cut once,
never hurt anybody. Yeah, absolutely. So definitely give it some
thought. Especially if you're unsure of how to approach a problem, don't just go
in gun blazing. It will not work. If it's a problem you've seen before and
you've seen three or four different solutions and you've seen one of them or
two of them be particularly successful while other two had failings, well now
you're better. You can cull a bunch of possibilities right off the beginning,
right? Yeah, exactly. Yeah, that comes more better with time. But if you
don't know how you're going to approach something,
don't just start.
Yeah, exactly.
And well, if you do, do the thing
where you build one to throw it away, because guess what?
It's not going to be any good.
You may get it working, but you must have heard that expression,
right?
Like you build the first one, and then you
throw it away because it's garbage,
and then you go do it the right way.
Oh, yeah.
Well, that's the way of doing the first path where you're
just trying to figure everything out.
but it's the nitty gritty way of doing it, right?
Like you build your doghouse and it's all screwed up
and then you're like, okay, well, this kind of sucks.
So you got to take it apart and build up a new one
using everything that you've learned the first time.
- Yeah, exactly right.
And something else that occurs to me
when we're talking about this is that
just because you do set out a path early on
doesn't mean you're stuck with it.
And if you- - No, no, no.
- Yeah, if you- - That's the worst.
- Yeah, oh yeah.
And so do not make a rod for your own back in that sense.
I mean, okay, that came out wrong.
It's okay to make the rod for your back,
but you can modify that rod as you go if necessary.
And the longer you wait to tweak it,
the more a pain you will feel.
So if you get in a few weeks into your development,
let's say, and it's gonna take you,
you're working for three months on a bit of code
on a project, and it comes out after a few weeks,
you realize you need to extend this, this,
and or create or change this object slightly
or modify this and so on,
for goodness sake, do it sooner rather than later.
Otherwise, you know, it's just so much more work and pain, the longer you let it go.
So because I've noticed that there's a in larger companies, there's this momentum effect whereby it's in the interface
spec. So that's what you're going to get. And if you want to add things, the longer it goes, the harder it gets. And
it's like, oh, geez, I wish someone had spoken up sooner. And you speak to the developer, and they're like, Oh,
well, I realized this weeks ago. Why didn't you say something? And I oh, well, because yeah.
political reasons or whatever.
Yeah.
What's that?
What's that expression?
Yeah.
Politics.
What's that expression?
Uh, a foolish and reading.
So it's a hobgoblin of a small mind.
That's cool.
Something like that.
Yeah.
It basically just means like, if you're just, if you're just being
obediently, foolishly, like just.
If you're just being obedient in this case to the, to the plan,
yeah, uh, you're ultimately just being kind of a dummy.
Like you need to continuously adapt the plan to what you've been learning.
It doesn't mean you throw everything out. But if you're not being
responsive, and I don't mean that in like, technical terms, but I mean, if
you're not responding as an organization to what you've learned as you're
building the project, you're not helping yourself in any way.
That's right. And a lot of that pressure comes from, you know, project
managers that'll look at, well, I only care that you ship something on this
date and anything that requires going back sounds like a bad thing up front.
But the funny thing is with software is that sometimes it can actually be a good
thing. If you iterate early, it can save you time in the long run.
And trying to explain that to someone in project management that doesn't
understand software, that thinks linearly is an exercise in endless
frustration. So, you know.
I've actually had a few good experiences with project managers that have been
trying to warn ahead of time that we need to make changes.
Sure.
And then the top person is vettisant to do it.
Wow.
So I don't want to just bash on any one.
Like this kind of stuff can--
and I think that's worth pointing out,
is that this kind of--
what's the quote?
I found the quote here.
"A foolish consistency is the hobgoblin of little minds."
Love it.
Cool.
But this kind of foolish consistency
can come from any part of the organization.
Anybody can stick their feet in the mud
and refuse to change or refuse to realize that things
will need to change.
Yeah, exactly.
So it's not-- often it's project managers
because they're less close to the stuff,
but it doesn't have to be.
It could be a programmer who's got a particular being
that's bonded about taking a particular approach that's
currently not working or a designer that is like,
he won't bend, or she won't bend because it's like, they're so
enamored with the design that when it becomes impossible to
actually implement, they just won't. They won't give it up,
you know.
Yeah, so it's a fair point. And I honestly, I rag on project
managers all the time. Because usually, they're the bane of my
existence.
But they do have it coming.
Yeah, they yeah, damn right. But the thing is that I say that,
And then in the next breath, I got to put my hand up and say, I've done plenty of project management myself.
And I mean, and on a couple of occasions, I was accused of, you know, not fully comprehending, you know, what I was adjudicating on.
And the problem is the level at which you're managing.
So if you're project managing at a code level, and you're just looking at code, that's one thing.
but if you're their project, you take a step up.
And when I was in terms of level
of what you're overarching in your project plan,
for example, when I worked at MPI Engineering,
we built switchboards, we did the physical installation,
we wrote the code, all of that,
but they're all very different things.
They're very, very different animals.
And whilst I had a lot of experience writing the code,
I had less experience building the switchboards,
although that changed the longer I worked there
and same with the site installation.
So I had very little installation experience
And then I accumulated that as years went by.
But when I was doing the project management,
I would often get into strife,
particularly with the workshop
that we're building the switchboards
because they would say, well,
you've given us however long to fit,
blah, blah, blah to the switchboard.
We need double that amount of time.
And it's like, well, okay, fine.
So I mean, I acknowledge the fact that,
yes, I've been a project manager.
Yes, I have messed it up as well sometimes.
But I'm also a great believer
that that's an unfair position to put me in.
and the way that, yeah,
'cause I was put in that position, right?
I was told, look, you've got to do the project management
on the whole thing.
And on larger projects, we can justify the cost codes
and say, well, okay, we're gonna have a representative
from the workshop manage their schedule.
We're gonna have a representative from the install team
do their schedule, and we're gonna have you
do the software schedule, John.
And I'm like, great, that would work perfectly.
And on the really big projects,
like the $10 million projects, that worked
because we had enough cost to,
enough cost codes to go around,
enough money in the budget to do that.
However, when it was just me and the budget was tight,
they're like, "Well, we've got enough money
for you one person to project manage it.
So it's all your problem."
I'm like, "Ha, yay."
- Yeah, but you don't have the expertise
in the various fields.
- No, it's not.
At that point in my career,
this is going back six or seven years ago
before I'd maybe even eight years ago.
Time flies and you're having fun.
But yeah, I was still getting that experience.
I mean, I'm a lot better now.
If I look at the switchboard,
I can say, yeah, 14 to 16 weeks for that one.
'Cause it's, you know, like 10 meters long
and whatever. - Well, you know why?
It's 'cause you got thrown in the deep end.
- Yeah, oh, sure.
Yeah, absolutely.
So to all the project managers out there,
I don't hate you, okay?
I really, I don't. (laughs)
I love you really.
But just note that sometimes there is frustration.
Okay, anyway, all right.
Enough aside on that.
The last thing that I have to talk about quickly is testing.
And the one point I wanna make about testing
that irritates me is that so many people test to make
and they don't test to break.
And I love that expression because it rhymes.
Test to make, test to break.
So in other words, if you don't know what I mean by that,
it means, I mean, test the functionality
such that it functions the way the specification
has described or the way that you have functionally
intended it to work.
So I'm going to send this message
and I'm going to get this response,
or I'm going to act on this and I'm going to get that
blah, blah, blah. All that is testing to make in other words,
make it work the way it's intended. What about sending a
gibberish? Send it something that's out of bounds, send
something that's illegal, invalid. Are you testing that
test to break it, try and break this thing. And it doesn't just
work on a on a code level, it go up to a user interface level, if
there is a user interface, you know, click on stuff out of
sequence, do stuff that that, you know, get someone that's
never seen it before to try and break it. Because, yeah, you
just think, no matter how long you've been doing this, you
think, this code is ready to ship or almost ready to ship. I'm
not going to name names, but someone recently that we both
are acquainted with, made this comment recently, perhaps on one
of your shows, regarding stuff that they wrote, where, yep,
it's, it's a few weeks away from being shipped. Anyway, and then
it went out for testing. And it's like, oh, crap. So the
point is that getting other people involved to try and break it, you know,
absolutely invaluable. And when you test it, you should test both angles that
that's, I guess that's what I'm trying to say. And as for whether you should
test it or not, I think that's self explanatory, please, God, yes, test it.
Yeah. So I think I'm kind of guilty of that myself. Like, I'll implement a
feature, and then I'll go and test it out. And oh, yeah, look, the feature
works. You know, eventually, after a couple of iterations, you compare and
contrast that to somebody like Daniel
Jelka. You can give him a piece of software and
he will break it within minutes, doesn't
matter what it is. He's really, really good
at breaking stuff. And it really is.
I mean, it's frustrating. It's good,
I know, I know, I know. It's just
depressing to get the bug reports back.
But a good... so one of the things that I
I learned early on in my video game career is that a good tester is worth their weight in gold.
Oh yeah.
And especially in video games.
They're often young kids.
They pay them like crap because these kids come in thinking that like,
"Oh my god, I get to play video games all day?"
And it's like, "Yeah, have you tried playing broken video games all day? It's not as fun."
And you know, they have weird incentives like the number of bugs logged and all of that.
So it's kind of garbage in terms of repro cases.
But a good tester with a good repo case who will sit with you and
exactly figure it out is oh my god that's like a blessing from god right
there. And because a lot of like the good
ones do exactly what you say, they test to break and that's wonderful. I
don't have that in me because I'm my loop is I get a
like an endorphin rush from the creative process right?
Well I say creative but you know from making something work.
Yeah, like I'm a kid. I've got nothing. I've read a bunch of code. I run it.
It doesn't work. Iterate, iterate, iterate. Oh, that works. Oh, that's amazing.
Yeah, you're right. It's a rush. Yeah.
Yeah, and then some, often along the way, I'll notice that something else screwed up and I'll be like,
"Ah, okay." So then I'll have to go and fix that. But I very seldomly, just during my regular, I mean, I do,
just during my regular day-to-day, I don't often go and try to break the app that I'm working on.
For my own app, for my own company.
I've got like two partners.
We do spend some time trying to beat on it.
It's not a day to day thing for me.
I think one of the things that occurs to me is that we
ourselves, the developers of the code specifically that we've
developed, are perhaps not the best people to be trying
trying to break that which we created.
You almost...
- Well, you really don't want it,
you don't even want to see it break.
- Yeah, well, that's it.
It's part of our pride, I think, maybe, to an extent.
- Oh, I've seen things in games
where once they got pointed out to me,
I'm like, you know what?
I've been coddling that.
Like, I knew kind of maybe in the back of my head
that that was not gonna work.
- Yeah.
- So I just didn't do it.
And games have this weird dynamic system.
So, you know, you can avoid weird edge cases
that you even subconsciously, you know?
And once they've been pointed out, I'm like,
oh yeah, I kinda, in the back of my mind,
I kinda knew that was probably gonna screw up in some way.
- Yeah, that's it.
- Which is depressing, but good.
I mean, ultimately you can't get good software
without somebody having beaten on it, so.
- Yeah, absolutely.
So I guess that advice by extension
is that if you're working on your own,
having a beater is absolutely essential.
if you are working in a team,
having other people in the team try and break your code
is essential as far as I'm concerned.
And when it comes to adding functionality,
it's important to go back over the tests
and regression tests,
those things that you already do to try and exercise
and try and break the code again,
because every time you modify the code,
is it's potential for you to mess up
what previously used to work.
And that's another thing that irritates me
is that people add functionality to a function
or an object and they'll say, oh, I only have to test the bit that I put in that the new bit works.
And I'm like, well, what about all your regression testing on all of the other things to break the code?
And they're like, oh, but I only changed this one line.
Yeah. With code that's running, you know, equipment, like in my particular case,
specifically in the moment in oil and gas, if you get it wrong, I mean, there are some pretty
massive consequences. So, you got to do that. If it's, you know, and another thing, even if you're just putting stuff into the app store
and you put something out there, "Oh, I just fixed this bug, push it out. Time and review, time is money. Let's get it out there.
I've got angry customers." Well, guess what? You fix one problem, you just create two new problems, let's say by accident.
And then suddenly you're like, "Oh, no, oh, no." Yeah, take that time, try and break it. Make sure that it's solid before you send it out.
that's that's anyway, so I'm not sure how many other ways I can
say that if I thought about it, maybe two or three more, but we
might just leave that.
No, I completely agree. Yeah, good testing is invaluable.
Absolutely. So that's the end of my list. Did you have anything
else that you wanted to talk about that you see as being
critical or useful in terms of going into good code?
I think we covered most everything that I wanted to
cover. Mostly because I got to bring up CodeComplete, which despite being 20 years old, I still
think has some tremendous insights and is invaluable to programmers, especially new
programmers. It's a remarkable piece of work that hasn't just lasted 20 years. It'll probably
last another 20. That's how good it is.
Yeah, cool. All right. Well, we might wrap it up there. And we've had a few questions
come up during the show in the chat room. So please stick around after the show and
we're going to do a Q&A. And that will appear after the outro music. So keep listening.
But if you'd like to talk more about this, you can reach me on Twitter @johnchidjie and
check out my writing at techdistortion.com.
If you'd like to send any feedback,
please use the feedback form on the website,
and that's where you'll also find show notes
for the episode under podcasts pragmatic.
You can also follow Pragmatic Show on Twitter
to see show announcements like when we're going live
and other related stuff.
I'd also like to thank my guest host, Guy English,
and what's the best way for people
to get in touch with you, Guy?
- I'm @GTE on Twitter,
and I write very occasionally at kickingbear.com,
and I have a show called "Debug."
- Fantastic, definitely listen to Debug, it's great.
If you're into programming, it's awesome.
- Thanks.
- Yeah, the latest one also,
the Revolution 61 was really good too.
- Oh yeah, those guys are great.
We got one coming out soon with,
it's a conversation with Don Melton and Neaton Ganatra.
- Ooh, okay.
- Neaton ran the apps group for iOS
and Don did a lot of the,
he was in charge of the internet stuff.
- Yeah. - That's right, yeah.
- So that was fun.
- And thank you for introducing me to Don Melton.
And when I say introduced, I don't mean like personally,
but I had no idea who he was when I heard him on debug
and he's a great guy.
So lots of- - He is great.
- Yeah, so- - He's great in person too.
- Cool, I'm excited about that now ahead of time.
So cool, awesome.
Alrighty, I'd also like to thank
two sponsors for this episode.
So thank you to Solver by Aqualia for sponsoring Pragmatic.
You've tried a calculator and a spreadsheet,
but if you haven't tried Solver,
you're missing out on a great app that fits perfectly
with the way your brain actually thinks
about doing a calculation.
Solver's available through the app stores,
but there are links from Aqualia's website.
But if you use the URL in the show notes,
it'll help out Pragmatic.
So please use that URL in the show notes
to learn more about this helpful little app.
And also I'd like to thank Space Nation
and their Mac app, Hue Party, for sponsoring the show.
If you have LIFX or Philips Hue bulbs, or both even,
Hue Party can control them and add some neat effects.
It's a free app for up to two bulbs,
So check it out at hughparty, or one word,
dot com slash pragmatic for more.
And for our live listeners, please stick around.
We'll be doing a Q and A after the show
and to everyone else,
thanks for listening and thank you, Guy.
- Thank you.
(upbeat music)
[Music]
(upbeat music)
[MUSIC]
(music)
(upbeat music)
[MUSIC]
YUX Huang. I'm sorry if I'm mispronouncing that, mate. Okay. Don't really want to open that big
can of worms, but what about fighting political battles when trying to get a technical direction?
I guess my- - That's a whole show by itself,
by the way. - I agree with you. It is.
- Well, it's really hard to give a single answer to a political battle, right? Because it's the
nature of human interaction that that's
always going to be different.
I think
one thing that you need to be aware of
is that the best technical decisions
aren't necessarily the best
decisions for the product. Yes.
Not only that, I don't think that
in all cases that the best decisions for
the product are the best decisions in
in line with what the company wants.
Do you know what I mean?
- Yeah, absolutely.
Oh yeah.
- You could have a product that, I don't know,
pushes some other aspect of the company.
I mean, let's take, I'm trying to come up with an example
that I haven't worked on so I can actually talk about,
but let's take the Twitter, native Twitter client.
- Yep.
- Clearly they make some decisions in there
that are not the best for the product, obviously.
like the Dick bar being the big one and sponsored ads
and a bunch of other stuff.
But they are best in line with the goals of the company.
So they make the product worse, but with the hope
of making the company better.
And so in terms of the technical design,
you need to understand that you're on at least a three
axis matrix here.
trying to figure out the best solution for all
of these various goals.
And they may be weighted differently
depending on what stage of the development
or the financial straits of the company you're at.
So in terms of dealing with the politics,
I think you really need to try to understand
everybody else's perspective and why
they're trying to do what they're trying to do.
Because while a lot of it sounds really stupid,
most people have a good reason.
Yeah, I think that's the one of the-
At least from their perspective, right?
So, could be wrong, but.
Yeah, I agree.
I think the biggest problem that you face
in a larger organization when you're developing software
is that, well, honestly, doing any kind of design,
to be honest, is that when you're getting political push,
people tend to simplify it and they tend to vilify
the people that are pushing that down.
And it's like, oh, well,
I don't really understand the technical problems.
So then I really know this is really the wrong decision
and so on and so forth.
And I think everyone's sort of guilty of that
at some point being the programmer or the engineer
that's trying to do the implementation.
And our initial reaction is all politics is stupid
and they just don't understand and so on and so forth.
But the funny thing that I found is that
Once you start getting into higher up in the business and you get to those business level decisions,
they start to make a little bit more sense.
I mean, don't get me wrong, don't get me wrong.
There's always going to be an idiot that says, I want it pink because it's because pink's my color and whatever.
And it'll be some kind of nonsense that makes no difference to anything, adds no value.
And you're just trying to get a technical direction.
What color do you want this thing to be?
And, you know, whereas the far more useful approach would be, well, you know, we know that blue is a nice color
because it relaxes people or whatever the heck.
Was it Microsoft that looked into what shade of blue
was the most relaxing for their background at some point?
I forget, but.
- I wouldn't be surprised.
I mean, I know Google A/B tested a bunch of colors
at one point too.
- Yeah, so yeah, but I mean, as ridiculous,
almost ridiculous as that sounds, funnily enough.
- Well, there's a reason that so much stuff is blue, right?
- Oh, sure.
- Just put it that way.
- Yeah, exactly.
Yeah, we need everything to look like the sky blue.
But anyway, I guess what I mean is that
once you get talking to the people who are making the political decisions and understand where
they're coming from, you might just be surprised that there really isn't a political will necessarily,
it's more about a, you need to understand the bigger picture. And it's so easy to get stuck
into the, you know, get stuck into the weeds of the development that you just, you vilify the
the politics and you start getting all worked up and angry about it, when in the reality is,
you know, chill out, man.
Just it's okay.
I think a big one for me coming up was game
design versus marketing.
Oh, yeah.
Where game design is like, basically, screw you, we're the artsy-fartsy guys, we're going to do what we want.
Marketing is like, we just can't sell this game.
And you're like, oh, sure you can, you can convince them.
and it's that's seeing marketing's job is to convince them that your artsy-fartsy vision
is the correct one and everybody should buy it is not appreciating what they actually do for a job.
Yeah like they it's it's a two-way street and I'm not saying that marketing should dictate all of
your decisions but I'm saying that pretending that they don't have any kind of input or insight into
to the outside world is pure folly.
Sure.
And you should be working together in order to kind of come to a solution
that, that, that hits as many of the, of the, um, uh, the goals of the various
points of the organization as, as possible, which isn't to say like design
anything by a committee, but it is at least be respectful of what other people
in the company are trying to achieve.
Because nine times out of 10, they're going home just as
frustrated. Like when a project is going poorly, they're also
going home being frustrated that the project is going poorly. So
either you can just all get mad at each other, or you can kind
of try to work it out. And I guarantee you, if you go into a
meeting with that perspective, you will come out with a better
result for yourself.
Yeah, absolutely. It's all about frame of mind.
Yeah, which isn't, which isn't to mean that this is a selfish
thing, but it, you will get better results by understanding
other people's position, because you will know you, you can learn
to understand where they can can negotiate and where they really
can't. And through that understanding, you can better
figure out how to fit your plans and your objectives into that
framework.
Okay, cool. No, I do. I totally agree. And on the marketing
side. Yeah, it's tough because marketing has this stigma, almost, I would say.
Yeah, exactly.
Associated with it.
You kind of want to hate them.
Yeah, it's the episode of Dilbert where Dilbert comes in and says to the marketing department
of the Nirvana company and he sits down to the marketing department and he says, "You
know, I can't believe you have a company without a marketing department." So, they create a
marketing department for me sits down and the marketing guy
across the table says about his underwater barbecue, he says,
Okay, just a couple of thoughts. This is the marketing guy. One,
does it have to be underwater? And two, does it have to be a
barbecue? It's like, okay. So, you know, and that's the
perception is that marketing somehow don't know what they're
doing. But the reality is, marketing know a lot more about
marketing, you know a lot more about programming. That's why
you're doing each of your respective jobs. The two of you
working together, we'll get a better end result.
Well, okay, so here's the other thing. In the framework of that
cartoon, the person who developed the underwater
barbecue wasn't able to communicate to the marketing
team why that was a good thing. Yeah, I mean, like, there's two
there's two reactions to that. Marketing can be like, I don't
understand underwater barbecue. And that's because the
development team needs a little bit of a pitch guy. Like you need to be able to
pitch in a certain way to be like no no this is cool because look at this look
at that. You need to have a little bit of internal marketing from your own thing.
You need to be able to sell your own perspective and to do that you need to
understand what they're want to buy in terms of it and then this is confusing
all kinds of terms because I'm talking internally and externally right. But if
you can't pitch your own marketing people on something they can't pitch it
out to the outside world. You need them to buy into your
project. And there's two that you can either be like, "Screw
those marketing guys, those idiots." Or you can go in with
the attitude of like, "No, I'm totally going to convince you
it's awesome, because it really is awesome."
Yeah, and the longer I've been doing this sort of thing,
pitching the idea, as you say, it's not just important to the
marketing. But here's the thing, pitch it to yourself first. If
you can't pitch it to yourself and convince yourself that it's a good idea, why are you bothering
pitching it to anybody else?
If you can do that and start with that and then pitch it to marketing or the high level
management or whoever is who has the final say for a feature for your product, whatever, you
know, then you've got to start there.
And absolutely, it's all about you.
It has to be something useful other than just it would be cool if, insert feature here,
right? Because that's not enough.
just isn't. Time is money. So and I know that sounds ruthless,
but honestly, that's business. And that's just reality. If
you're not thinking like that, you're not going to be in
business for long, I think.
Yeah, that's it's a business thing. I mean, I love art games
as much as anybody, or even really opinionated software, but
opinionated software that's not useful, doesn't deserve to
succeed in the marketplace. It doesn't. You still need to earn
that, right? Like you don't just get it because you've got
something cool up your sleeve.
Yeah, exactly. So you should buy this because it's cool under the
hood. But you can't see it. And there's no useful features. But
it's cool under the hood, man. So it's Yeah, exactly. How do
you? All right, cool. Now, I also have another question.
The last one.
Last one. Behavior driven development.
Behavior driven. So the question just for the listeners from Mac
Birdie in the chat room. Thanks for this one. Any tips or ideas
on applying behavior driven development to apps that are
mostly UI experience focused. Okay, so MacBirdies provide a
bit more. More generally, he says provide or he or she says
they say, providing a kind of contract, how the app should
work instead of creating tests for the apps algorithms. So
okay, oh, so taking that testing,
it'd be like working from the from what's that development
process? The agile stories?
Yeah, something like that.
And then you'd say define some stories and then you keep developing your app until you fit a story.
Yeah, essentially, your testability or your judgment for the success of your testability is done at a higher level at the UI experience level rather than testing the raw algorithms.
At least that's the way I'm reading the question.
I think, no, you know what, I think that's a natural way to develop.
If I'm understanding it correctly, I think that's a natural way of developing software.
I mean, you figure out how you want your software to be used,
and then you keep iterating on it until it fits that use case.
I see it as layers. You start out at the lowest level, and you can just confirm that it's something
like Stories, yes. So, from that agile development sort of angle then.
Okay.
So yeah, I think that I--
well, certainly, coming from the game world,
yeah, I mean, you develop a level with a certain number of scenarios in it,
or like little cool things you want to have happen,
and you write the game in the engine,
and then you develop all the assets in order to make that happen,
and until that happens, you're not done.
And it's certainly in games,
you don't really get to do a lot of unit testing,
just because, like I said earlier,
It's a vast dynamic system.
And testing any one unit is cute,
but it doesn't really help the--
it's a dynamic system.
So there's so much state flying around
that it's really hard to figure out what anything
means in isolation, which is what unit testing is about.
You take something in isolation and you test it.
In a giant system, that doesn't really
help because the magic comes out of the system
rather than the isolation. But yeah, no I
certainly when I develop my software I aim to, I don't, we don't
do an agile thing per se but we have a use case that we want to
achieve and we do that and we just keep iterating until we get that.
Any obstacles we hit we try to resolve them.
If I'm understanding this BDD specifically correctly is that
It's unit testing plus the end of the story stuff.
Whereas in the games and the stuff I do, I
often end up skipping the unit testing
stuff. Do you know what I mean?
I'm mostly testing the top layer of what the user is actually going to be
interacting with rather than the entire stack, which is what I think BDD is trying to
achieve. Okay, so when I'm doing testing on my code, what I'll do is I will
start and I will get the code at a low level as solid as possible and make sure that it's
test to make, test to break and those will be very very thorough testing. But once you start
assembling the blocks together I pretty well stop doing that unless there's a big issue of course
but and I go back to read to go back over that but the low level testing but when you get to the
the top end the end-to-end functional testing perhaps is the best way I'd describe it
whereby you've got a certain functionality that calls on a bunch of different
functions to do what it's going to do and then you get a certain result whatever that might be
and I'll have a list of tests and I'll ensure that those tests that they pass but I will
seldom go back to that low level after that unless there's a big problem. Or I'm doing
massive modifications and I'm going to go back and regression test a lot of it but you know
hopefully that doesn't happen too often because that really sucks but anyhow. So I'm not sure if
I'm not sure if that answered the question,
but thank you for the questions, guys.
This is a, again, it's a new thing I'm trying,
so I really do appreciate the questions.
Hopefully I'll have the show bot up and running
in the next few weeks,
and it'll be a little bit more automated.
And as the show goes out and people become aware
that it is being streamed live,
then hopefully we'll also get some more people.
But a special thank you to everyone
who's listening live in the chat room right now.
You're the best.
Thanks for coming along and joining in.
I really appreciate it.
- Thanks a lot, man.
Thanks for having me.
- Yeah, no worries.
[8-bit music]