Are We Remotely Productive?

Are We Remotely Productive?

Released Saturday, 14th December 2024
Good episode? Give it some love!
Are We Remotely Productive?

Are We Remotely Productive?

Are We Remotely Productive?

Are We Remotely Productive?

Saturday, 14th December 2024
Good episode? Give it some love!
Rate Episode

Episode Transcript

Transcripts are displayed as originally observed. Some content, including advertisements may have changed.

Use Ctrl + F to search

0:20

Hey, Ben.

0:21

Hey Matt.

0:22

We're going to have to come up with a better intro. It's just cliched now. We're actually a caricature of ourselves doing our own intro.

0:29

We can't not do it. If we don't do it, then we're doing a bit. Whereas if we do it, we're just introducing the show.

0:38

I suppose so.

0:39

Right?

0:39

I suppose so. Since I've started doing little cold intros as well, I've lost the bit where we introduce each other. Maybe we should mix it up a bit. Hello, friend.

0:50

Hello.

0:50

What are we talking about today?

0:52

We're talking about remote work.

0:57

Well, which is apt because on Fridays, that's exactly what we both do, which actually enables this very podcast.

1:03

Although I did just have a tangent idea.

1:07

Oh.

1:08

Maybe we should do the tangent idea.

1:09

All right, now let's do it. Tell me your tangent idea. Everyone, this is how planned these are.

1:12

This is like a five-minute pretangent to the remote work episode.

1:15

Go on then.

1:20

How about that?

1:21

Do it.

1:22

Um.

1:22

I believe that it's software engineer estimates time shocker.

1:25

Yeah, oh boy. Two hours later, we're still talking about this.

1:29

Yes.

1:30

Um, I thought it could actually - this just popped in that I had just as I was starting up the show - we could do a 10 minutes on...

1:36

Mm-hmm.

1:42

Two on five minutes on...

1:43

Now it's 10 minutes but already.

1:47

Two's complement, the data storage mechanism, not the podcast like.

1:50

Oh, you mean two's complement, how we store numbers.

1:53

Yeah, yeah, right.

1:55

Yeah.

1:55

It's like when you're storing numbers in binary. You can use two's complement storage to do that and why would one do that, right?

2:01

Well, why would one do anything but two's complement is more the point.

2:06

Well, yes. So if you sit down and teach like a sixth grader binary, right?

2:14

Mhmm.

2:15

It becomes fairly easy to understand when you're just using normal integer counting numbers. You say, alright, well, this is the one's place, this is the two's place, this is the four's place. You add all these things up. Then you say, OK, so computers can only store so many bits. Maybe you've heard of an 8-bit computer, maybe you've heard of a 16-bit computer. They can only perform operations on so many bits. So you can see how it would be pretty easy to just store regular old integer numbers in this thing and have the computer operate on them.

2:49

And then you might ask that sixth grader, well, OK, but what about negative numbers? And the first thing that they're probably going to say is, well, I guess you could use one of the bits to indicate whether the number is negative or not. And you say, OK, cool. Yeah, that works.

3:08

It's a fairly obvious thing. It's how we do it in decimal, after all. We either draw a little minus in front or we don't. And that's kind of our one bit of sign. Yeah, it makes perfect sense. Well, what - yeah, what we're done here end of five minute.

3:20

Yeah. End of five minute thing. And then you say, okay, well what happens? So that's true. And you can do that. But what happens when the sign portion of the bits is negative, but the value portion of the bits is zero?

3:39

What does that mean?

3:39

Right. Right. That's like, and again, in decimal, that's like writing minus zero, like the negative zero.

3:45

Right.

3:47

And you're like, well, I guess that's - I wouldn't write that down. Would you write that down? I wouldn't. So let's just not write it down.

3:55

It's just a dumb thing.

3:56

Right. Let's just not write it down. Let's just all agree that setting the sign bit to one and having all of the other bits to zero is just a dumb thing. Don't do that.

4:06

But then you could see like - but okay, computers don't like it when we waste things. They don't like that. They want to try to use everything.

4:16

Like one 256th of all the possible representable numbers in an 8-bit thing is just a "don't use me." I mean it could be a NaN or a null or empty. We could use it. I'm gonna continue to devil's advocate this for what it's worth.

4:28

You could use it for something like that. But another way - yes, yes, yes. It's like, oh, we can do it and it will work. But there is a better way. And that better way is called two's complement.

4:48

And in that world, we use that to just represent a completely different number.

4:54

Mm hmm.

4:55

I actually don't remember which side of the negative chain that is. Do you remember what it is?

5:01

Well, you negate and add one is the kind of way that I internalize it, but yeah it closes the gap between zero and minus one in terms of the bit pattern representation.

5:01

I'm going to have to Google it now so I can take a table.

5:15

Mm-hmm.

5:16

Which to me is the other thing that makes two's complement numbers really elegant. It is that most of the circuitry dealing with numbers doesn't need to know if it's signed or unsigned because it just works. It works the same way, whereas if you treat the sign bit separately, you now actually have to encode the rules about some of the things that can happen with negative and positive numbers. So it is a really clever trick.

5:43

And you'll be hard pushed to find a computer that doesn't use two's complement to represent its numbers. But until very recently, the C and C++ standards required - not required. The C and C++ had made no assumptions about the representation of numbers. And so certain things were not defined, were left as undefined behavior. You couldn't rely on, for example...

6:13

adding one to the highest possible number to get it to wrap around to negative, whatever, because, and you know, that's usually a good thing because like nobody really wants that to happen, right?

6:17

Okay, yeah, right.

6:23

If you add - but let's talk in fact about the two's complement aspects of this here. It's like, you know, we have this strange now lopsided number where the highest number we can represent with say eight bits, two's complement is 127, but the lowest is minus 128, which is kind of...

6:33

Uh-huh, yeah.

6:40

Displeasingly asymmetric. And that also means that you can't just unary negate any number and get another number because if I have minus 128 and I get the negative of it - like oh whoops, can't represent 128 anymore. So there are some weird edge cases. We've kind of pushed them around rather than at the zero point, they're now at the extents. And so it's kind of reasonable that if you added one to 127...

6:42

Right, right, uh huh.

6:53

Yeah. Yeah, yeah. Mm hmm.

7:06

And you suddenly got minus 128, you probably didn't really mean to do that. You didn't want that to happen. And so it's left as undefined behavior. And so compilers can usually optimize around that. So look, you're not - we weren't expecting you to do this. Therefore, I'm not required to do it this way. For example, it may be that you use a bigger representation than an 8-bit value when you're using a signed 8-bit value. And that means that the carry rules don't work the same way. But it's also not supposed to happen. So the compiler might be able to use a 32-bit register instead of an 8-bit like shift and add and shift and add all the time, things like this.

7:40

But very recently, they gave up on pretending that computers aren't two's complement, and they actually accept that like all practical computers these days are in fact two's complement.

7:47

You.

7:51

And I forget exactly the ramifications of this. Those who know me well know that I don't really participate much in the C++ standards stuff, but that one just came up on my radar. So I apologize for not having the, especially when you just dropped this on us at the beginning of this podcast. I haven't researched it in any meaningful way. And I have a very loud mechanical keyboard, so I can't even Google it while we're talking.

8:12

Well, I also have a mechanical keyboard and nothing prevents me from doing that other than the clackety clacks that are the low pass filter.

8:17

Oh short of me having to edit out the clacks in a minute. But no, what an awesome idea. We've named our podcast after a very neat trick.

8:33

It is a neat trick. It's very elegant. And there's just something abhorrent to me as a programmer about having any sort of mechanism that just allows for nonsensical values by its structure, right?

8:35

Yeah.

8:51

Like if I can ever find something where those types of problems just aren't possible, that is always going to be a better solution. And this does that very well.

9:00

Absolutely. Correct by construction is the sort of way that I've always internalized that. Although I will note that in the original Knuth book, The Art of Computer Programming or the various volumes...

9:04

Yeah, yeah, that's the phrase people use.

9:14

The MIX architecture - so Knuth is just such a legend for me for two reasons. One, he wrote like the book or the books on all algorithms which are like the most abstract things - like how to sort numbers all the hundreds of ways you can sort numbers very abstractly.

9:23

Huh.

9:30

Yeah, yeah, that's the phrase people use.

9:33

But then he wrapped around on the - you know, talking of numbers that wrap around - he wraps around to the exact other side where he then implements them in assembly code in a computer that doesn't exist, that he made up so that he can demonstrate the purity of his algorithms using this invented machine, the MIX.

9:36

Alright.

9:53

Nowadays, there's a RISC-based one that has MMIX or something like that. But the one I remember growing up as a kid reading was the MIX one. And the amusing thing about that is - forgive me readers, listeners, whoever they are, if I get this a bit wrong - it is a sign bit based computer that is decimal.

10:16

It stores numbers decimally with a sign bit.

10:18

Hmm.

10:20

So you do in fact have plus and minus zero. And then to your point about waste, Knuth goes as far as micro-optimizing his own made up instruction set for a computer that doesn't exist to implement algorithms that are like all about the big O notation and not about the constant factors, but he optimizes them anyway, because he's Knuth. And he starts using the sign bit to essentially encode a Boolean flag, because obviously these numbers, these values in here can also be pointers.

10:52

And it doesn't make sense to have a negative pointer. So he just uses the decimal part as the pointer address. And then you could also for free get this one bit flag. And so some of his algorithms stuff things in that one extra bit. So it's not wasted in those instances, you know, a null pointer...

11:10

With the bit clear is different from a null pointer with the bit set because it might mean null but red or null but black in a red-black tree.

11:15

Oh, oh wow.

11:19

Things like that. And just now you've just lit the litmus paper under me and I'm going now. A good friend of mine has just put together a proposal for the C++ committee about canonifying, reserving certain bits in pointers. Many things - you know, you have a pointer, it points to an address in memory, the things you point to have to be aligned at certain spaces.

11:45

So you know, if you have a double precision number, that's an eight byte quantity on almost any hardware, you have to have it at an eight byte address. What that means is every pointer has wasted bits at the bottom, which always have to be zero because it has to be in a multiple of eight, right?

12:00

Mm hmm.

12:00

There's some - if you can just mask those bits out, you can access it as a pointer. But if you mask them in, then you've got some bits at the bottom, you've got two or three bits worth of like extra information.

12:09

Mm hmm.

12:12

And so she's put together a proposal which says like, can we canonify this because strictly by the book, you're not allowed to do those kinds of things.

12:12

Mm hmm.

12:20

Because once you start manipulating a pointer like it's an integer, the compiler can lose track internally that it points to a valid particular object and whatever. But she's made it so that that's okay.

12:22

Hmm.

12:30

So yeah, sometimes if you do have redundant representation, that's wasted bits, you can find another use for them.

12:39

Well, someone will find a use for them because that's how that works.

12:41

Someone will find a use. Whether that's good or bad, I don't know.

12:43

Yes.

12:43

But no, Hana uses it in a really smart way. In fact, we had her on the podcast.

12:47

We did.

12:48

So Hana Dusíková is behind that proposal and very smart it is too. And it's definitely something I'll be looking to use myself, you know, sneaking bits in.

12:58

Anyway, that was not five minutes.

13:00

No, it was not five minutes.

13:01

But we can talk about remote work now.

13:03

Now we can talk about remote work.

13:04

So, needle scratch, tell me about how remote works works for you.

13:07

Yep.

13:12

Well, okay. The main thing for me is remote work is a trade-off between collaboration and productivity, essentially.

13:29

I...

13:29

Yes.

13:30

Currently, I'm working with people who are either in California or New York, despite the fact that we have a Chicago office, and that is just pure happenstance.

13:42

And that's where you are, for the avoidance of confusion.

13:43

That is - yes, I am a Chicagoan. We are Chicagoans.

13:46

If you can't pick it up from the accent.

13:50

Chicago - what's the multi... I don't... anyway. So I commute into our Chicago office a few days a week mostly to see my friends.

14:04

That's the main reason that I do it. Because, you know, the people that I work with are actually in California and New York, and I'm going to be talking to them over some sort of Slack or video call or something like that, no matter where I am.

14:12

Right.

14:21

So, you know, regardless of where I am actually physically, it's the same medium. But there is a lot to be said - and I know that people have made this complaint before, and this was obviously true for a lot of folks in COVID - but it's even still true for folks that sort of choose to have a fully remote... You know, they either work for companies that are fully remote or they have roles that are fully remote. Some amount of face to face interaction is, I think for most of the people that I've talked about this with, some amount of face to face interaction is really important because it's hard to develop those relationships when you are talking to everyone over...

15:03

Mm.

15:06

A video chat. And you can do it - unless people do do it - but it's...

15:14

It was interesting. I was discussing with a friend the other day about how you can keep in touch with friends from home. I've moved 4,000 miles away from most of my friends from when I was growing up.

15:29

And one way you can keep in touch with friends is playing video games where you can actually talk to people in real time. I was telling them in the pub the other day about the late nineties, where for whatever reason, I wasn't leaving the house very much. I was playing EverQuest.

15:48

And I have now made real-life friends over what was purely a text-based thing.

15:52

Huh.

15:53

And to this day, I still talk to them. Yes, you can build a relationship using text medium, using face-to-face medium like this, but it's harder.

16:05

And it only really happens well under either duress or when both sides really concentrate on it, where you both work at it to build that connection because unfortunately evolution is kind of against us. We have picked up on so many subtle cues about how humans interact.

16:34

Being in a room with someone tells you a lot about how they are and you can learn about them so much more naturally. I'm searching for the right words here.

16:44

Yeah, it's just a higher bandwidth interaction.

16:48

I think the other thing about it is that when you're remote, there are very few accidental interactions.

16:58

Yes, everything has to be really intentional. You have to schedule a coffee chat or whatever, rather than bump into someone as you're passing in the hallway to the bathroom.

17:06

Yeah, how many times have you had an all-company meeting and you get there a couple minutes early and you just sit down next to a random person and you start talking to them?

17:15

Yeah.

17:15

Maybe you know them a little bit, and maybe you know them well. But that kind of interaction doesn't happen when everyone joins the all-company Google Meet. You're not chatting in the Meet in front of everybody else. Those sorts of accidental things can play a big part. But for the actual act of programming, writing code - I'm increasingly feeling different, and I think COVID was really the thing that tipped the scales for me because I was forced to create such a productive home setup that is so well optimized that there's no question to me that I'm a more productive programmer when I'm staying at home.

18:10

I definitely agree with that, although I don't agree with having built myself a productive environment, because if you could see the camera right now, it is a catastrophe where I am. I meant to fix that today, and I did not.

18:22

The main person in my life who pointed out how important it is to go into an office is in fact my wife, who obviously during COVID was forced to suffer full time with her husband. We have a great relationship, but I think all of us suffered from being in each other's pockets for a while.

18:44

But she's like, "You need it. You need to go and see other people." And she was right.

18:48

Mm-hmm.

18:48

I like to pride myself on being rational, logical, not really driven by the more animalistic whims of our reptilian brain, but she's right. I absolutely needed it.

19:02

And yeah, I agree. But in terms of focus time, obviously, we build our own focus time in the office with headphones or by trying to find a space away from the general thoroughfares to get some stuff done.

19:19

But that's the default situation at home, dog barking notwithstanding. And the very lack of those interactions at home, the lack of the non-intentional interactions is actually the source of focus. I can get up and make a cup of tea and I'm still thinking about the problem that I'm working on while I'm waiting for the kettle to boil, whereas probably more healthily in an office, I'm talking to somebody who's also waiting for the coffee machine or whatever.

19:55

And maybe that break is actually what I do need, but focus wise, it's true.

20:01

Yeah, you definitely don't have the rubber duck effect when you're at home where, you know, you're working on some hard problem and you stand up in an equal mix of frustration and need for coffee or some other thing.

20:22

Yeah.

20:22

And then you run into somebody who will at least understand your problem and you wind up explaining it to them.

20:27

Right, they'll understand the concepts even over the right.

20:31

Right. Yes.

20:43

Right.

20:44

Oh, of course, that's the solution.

20:45

Yep.

20:46

Yeah.

20:46

Yep. Yep.

20:47

Yeah, and that's hard to recapture as you say, remotely.

20:50

Mm-hmm.

20:50

I mean, if you've got, as you well know, I'm very well versed at just puking out my thought process into Slack into a long thread of things in the hope that sometimes brings people along for the ride in terms of what I'm thinking or gives them people come in and say, "Why are you doing that?"

21:05

Huh.

21:05

But again, it requires intentionality.

21:08

Yeah. And so the plot twist of this whole thing, I think, is that you can make the argument.

21:16

And I enjoy remote work and I do feel very productive when I do it. And I do it because I'm productive. But you can make the argument that productivity, in its very purest sense for programmers, is bad.

21:31

Oh, this is.

21:32

And the reason I say that is because I have had many times in my life, and I think that this is more common when I'm remote, when I'm working by myself, when I've got my headphones on or whatever, and I'm just in the zone and I'm programming, where you are creating code. And as we've talked about before, code is a liability.

21:53

Code is not good. We're trying to solve problems, not make a bunch of code that we need to maintain and test and deploy and debug and all the other things.

22:02

And there are many times when the right thing to do is not just puke out a bunch of code as efficiently and productively as you can, but to take a step back and to maybe talk to a few coworkers and be like, do I even need to be solving this problem at all?

22:19

That my friend is absolutely spot on. I mean, yeah, so in the throws of COVID, there is at least one reasonably large chunky piece of code that I'm very proud of and is used. But ultimately is now being phased out because really was overcomplicated.

22:36

Could be replaced with something a bit more straightforward, was part of a grander vision that didn't come to being. And ultimately, yeah, perhaps should have never been written.

22:46

Mm-hmm.

22:47

And it served the purpose. It kept me amused for a few months while I was sat rocking slowly backwards and forwards in this very chair. But, no, that's a really interesting observation that, unfortunately though, as programmers, we love that state and we love doing that.

23:04

We do.

23:04

And we love that thing as we've discussed before, the whole flow and all that good stuff.

23:08

Yes. Right.

23:24

Right. Yes. Do you really need this fancy thing? And I mean, a lot of the time that is a very productive and good state to be in, but it is not strictly true.

23:33

That it is always good at the exclusion of interacting with other people, double checking your ideas, making sure that you're doing things that actually need to be done and making sure that you're doing them in a reasonable way and not just going all full mad scientist.

23:50

Right, or "10x developer", and then you've got 10x as much code that no one else understands or has seen and doesn't even need and you're like, as you say, it's a liability. Now, that's a really interesting observation.

24:01

Well, that seems like what a two-tone kind of a podcast we've recorded today.

24:07

We could split this in half and do it in two parts if it wasn't like 30 minutes long.

24:09

I don't know that I'm that skilled enough an editor for that. So I'm afraid everyone's just going to end up with it pretty much raw.

24:15

Yeah. This is going to be the peanut butter and pickle sandwich of Two's Complement podcasts.

24:21

Hmm. That doesn't sound too bad though.

24:24

It's disgusting. I don't know why anyone would eat that, but we're just going to take two things.

24:29

Actually, you know what this is like? Did you ever see the movie From Dusk Till Dawn?

24:35

That's the vampire one, right?

24:37

Well, the second half is vampires. The first half is a bank heist movie.

24:40

Oh yeah, that's, oh yeah. I just remember it as vampires, but yeah, now you say that. I'm like, oh yeah, it's like a cut and shut.

24:51

Actually, I'm not sure I do know what that means.

24:52

That's when you've had two cars that have been involved in an accident and they're cut in half and the good halves of them welded together to make one good car out of the two. No, is that not a thing?

25:04

I've never heard that.

25:05

Like you can imagine like two Ford Focuses have been, one's been smashed in the front, one's been smashed in the back.

25:10

So you just cut them in half and stick them together and you sell it as a good car.

25:15

Okay.

25:15

Only the British could be so unscrupulous as to do something like that. It surprises me, but whatever.

25:27

Yeah, yeah, yeah. The first half of this podcast was a bank heist and the second half we talked about remote work.

25:36

Well, to that effect, I think we're pretty much done for this episode. And so I will speak to you on the next one.

25:41

Yep, next time.

Rate

Join Podchaser to...

  • Rate podcasts and episodes
  • Follow podcasts and creators
  • Create podcast and episode lists
  • & much more

Episode Tags

Do you host or manage this podcast?
Claim and edit this page to your liking.
,

Unlock more with Podchaser Pro

  • Audience Insights
  • Contact Information
  • Demographics
  • Charts
  • Sponsor History
  • and More!
Pro Features