Final Thoughts

[00:00:00]
>> [MUSIC]

[00:00:03]
>> Douglas: Let's talk about responsibility. Who are you responsible to when you're programming? Well this is my answer, this is who I think I am responsible to when I'm writing code. My number one responsibility is to The People. To the poor bastards who have to use my software. I want to work really well for them, I don't want to frustrate them, I don't want to confuse them, I don't want to hurt them, I don't want to lead them to ruin, I want to give them the best experience possible, I want to make their lives better to the extent that I can.

[00:00:36]
We imagine in the software industry that we're making the world a better place despite all the obvious evidence to the contrary, we'd really want to believe that but we should at least try to make it true for the people who are using our stuff as they're using it.

[00:00:51]
We should at least do that. I've seen teams where they have contempt for their users, they hate their users, the user's always complaining, they don't understand how to use their stuff, they don't appreciate our genius, they're stupid, they're awful people, hate them, which I think is totally toxic, that it's inexcusable.

[00:01:09]
We should never be thinking like that. Everything that we do should be in service to humanity. Number two, The team. I want to be writing the best code that I can, the clearest, best, well documented, easy to understand, good code because other people who I'm gonna be working with are gonna have to take that code and make it better and I don't want to be setting them up for failure, I don't want to be frustrating them, I don't want to be making their lives worse, I want to make their lives better, I want good code for everybody and I expect them to do the same so programming can be a solo activity but generally we're trying to do stuff which is so complicated.

[00:01:55]
We're trying to do it so quickly. We're working in teams almost all the time and sometimes big teams. And in large literary efforts, there's this idea of writing with a single voice. Like if you're writing an encyclopedia, or if your a couple of authors writing a book, or if you're writing a magazine, or some other thing we've got lots of writers working on the same project.

[00:02:19]
They're all trying to write in the same voice. And that doesn't interfere at all with being able to express good ideas and presenting it clearly. And I think we need to be doing that in writing software too, so I want us to be writing all in the same voice and that voice is the smartest most professional programmer who's ever lived.

[00:02:42]
I want everybody on the team to be writing up to that level. I don't want anybody dumbing it down because they think they need to express themselves by leaving out the semicolons. I want everybody to be writing really well. Then number three, Management. If they ask for it and it makes sense, okay we'll do that too.

[00:03:02]
Now some managers might be saying, woh, what a minute, we're supposed to be in charge here, shouldn't we be number one and I don't think so. I think number three is the right place for them. If you look at what a CEO does one of their most important responsibilities is to help the company look out.

[00:03:19]
There's a tendency in the company especially as they get bigger that everything is focused inside. There's competition for resources and attention and promotion and all of that stuff, and you tend to forget about the customer and you can forget the and you tend to forget about the marketplace and all these really things that are actually much more important than what's going on inside and part of the CEO's role is to remind the company of that and you see CEO's always saying things like be the customer and be customer focused and all that stuff that's what that's all about.

[00:03:53]
And that's very compatible with what I'm what I'm saying and saying number one, The People. Then one of the biggest problems that companies have is that their code bases are awful, that they're full of croft there with the call legacy it's just awful stuff and that seriously impairs the company's ability to compete.

[00:04:17]
That you can't make changes, you can't extend, you can't grow because the software is holding you back because of it's poor quality. The software becomes a liability rather than an asset. And I think we can change that if we're writing high quality of software for the team, that we allow the company then to be much more competitive, much more responsive, much better to serve the market.

[00:04:43]
Suppose you're writing your own software, your home and you're doing your own stuff, what are your responsibilities then? Number one still The People, assuming that someone else is ever gonna have to write your stuff you really should write it well for them whoever they might be, even if you don't know who they're gonna be should still have somebody in mind when you're writing this stuff.

[00:05:06]
And then number two The Team, if you have any ambition of this stuff getting good enough that you might wanna open source it that means your team is now potentially every programmer in the world. So make it good for them. And then number three your management so knock yourself out.

[00:05:28]
That brings us to the end. I can't think of anything else to tell you. So, thank you all very much. But before we go, I've got one piece of advice. This is really serious, I hope you don't forget this. This is, I'm really serious now. Please, don't make bugs.

[00:05:45]
>> Speaker 2: [LAUGH]
>> Douglas: Thank you.
>> [APPLAUSE]
>> Speaker 2: We've got a couple random questions from Chad. I'm not sure if you want to take any more questions but.
>> Douglas: Are they good?
>> Speaker 2: Well it's just kind of opinions, opinions on Swift. I don't have an opinion on Swift. [CROSSTALK]

[00:06:14]
>> Speaker 3: How about your opinion on typescript?
>> Douglas: On typescript, I see typescript as a trap, it keeps you in a classical model, you'll never figure out functions if yours locked into typescript.