Hey, how's it going? Sorry I can't be there today, but surprise, surprise, I've got a meeting to go to.
Well, but that I didn't want to miss lightning talks, so there was something I wanted to say, so here it is.
There's this interesting thing that I've noticed about hackathon. I mean y'all all know the hackathon's coming up, so I figure this is a good
segue into that. It's something we're going to be scheduling soon for the for the second quarter,
but there's there's this thing I like to call the hackathon effect, and if you've been in hackathon, you probably know what I'm talking about.
During hackathon, we're not just productive,
we're hyper productive. I mean we get things done that we didn't think we could possibly do if we were sitting in our pods and doing that during
the compressed time frame that we have,
and it's something that is is energetic. There's a lot of intensity involved and
something that I struggle with or that I've wanted to know is, how can we reproduce that? How can we take that
feeling, that awesome feeling you get during hackathon and take it back to the pods and do our daily work that way?
And I think I've distilled it down to two main things that kind of get that help contribute to that.
One of those is there's this compressed time frame that hackathon introduced,
so there's a challenge involved in trying to meet that short time frame and do something that we wouldn't otherwise be able to do.
And second, there's this intense desire within
to deliver this out. I mean we're going to demo it to our friends and our colleagues at the end of this, plus there's somebody that
maybe there's a problem we're trying to solve for them.
So we have this intense internal desire to just deliver some value quickly.
And I think you couple those two things together and that's like this secret sauce that hackathon delivers.
So let's talk first about schedule pressure.
I'm one who hates schedule pressure. I always have, but I'm starting to realize that if you don't have schedule pressure,
there's a desire as a developer that kind of takes over.
And I know with me, I have these tendencies to be a perfectionist.
And so if I don't have schedule pressure, I do what I think is right.
And what I think is right is cleaning up my code. I refactor this.
I maybe cover it with some more tests or so forth.
But I can get in this endless cycle of doing the same things for my code base that to me is right,
but doesn't actually get the project finished.
So I get caught in that cycle and I kind of learned a little bit about that when I tried to write a book a while back.
And yeah, that didn't work out because I kept rewriting chapters.
And then I started reading blogs about writers and one of the common things of advice they tell the authors is
don't go back and rewrite your chapters until you're done with your book.
Otherwise, you will never finish it. I'm like, ah, okay, I'm already done with that idea, but a little too late for me.
However, I think we fall into that trap, too. I know I have for all of my career.
The second thing I wanted to talk about was this intense internal desire to deliver value.
I know in the last hackathon that we had, I was working on this project for someone that I knew for Greg Kiffmiller.
And whenever we delivered that to him and Tim Anderson, delivered our solution to them, they were so excited about it.
I mean, they were literally just excited. And so were we.
The whole team was just jazzed. I mean, I walked out of there feeling like a million bucks. It was awesome.
And I just longed to get everyone to have that feeling in their daily work, because it was amazing.
But that intense desire came from within. It wasn't somebody else telling me I had to deliver something.
It was me wanting to deliver it. And as a developer, we have these two motivations that we balance.
I feel this is my theory anyway. We have a motivation to deliver and we have a motivation for good code and quality.
If you don't have this motivation to deliver, you're going to do what you think is right, which is create quality code all the time.
And so you're going to be refactoring. You're going to be cleaning up. You're going to be testing.
But if you couple that with this desire to deliver, these two things begin to balance one another out.
And you start to make decisions on your own about, well, when do I need quality? When do I need to deliver?
And when you start to make those decisions internally, that's when the sweet spot hits.
Because now you're thinking about things like, okay, how can I deliver this quickly?
But I don't want to compromise the quality. So you're making decisions because you want both things.
It's something that you can't force. It's something that you can't just artificially create.
So my challenge to you is when you go through this next hackathon, think about the decisions you're making.
Think about how you're feeling when you're working. Think about the things that are motivating you.
And try to think about how can I take this back with me to the pod?
How can I get this kind of feeling every day when I work?
It's so exciting for me and I enjoy it so much that I really want everybody to feel that way all the time.
I've been on a project that's like that. I haven't been able to reproduce it for years and years.
And it was the best project I've ever been on. And I desire that for all of you because, man, it's a blast.
So that's my challenge should you choose to accept it. Have a nice day.
