Anything invented before your 15th birthday is the order of nature. Anything invented between your 15th and 35th birthday is new and exciting. Anything invented after that day, however, is against nature and should be prohibited.
As well as being very funny, in some ways I find this terrifying.
I notice this with people at work – people who are over 35 do struggle with this. I’m turning 25 in two days time, so I have a little while to go with things being “new and exciting”.
In some ways, I can already feel it coming. When I first started using Office 2007, I hated it so much I uninstalled it. It was only when I was forced to use it at work, and needed certain features (the ability to view more than 65536 rows in Excel, the ability to have more than three bits of conditional formatting, sumifs etc) that I got used to it. Now, I love it, and dislike Excel 2003. But it was actually the enhancements to certain features that won me over. If there had been a version of Excel 2003 with those features in, I’d have stuck with that.
In occurs to me, again, that change is a real challenge. It’s an effort to change, and so it’s easy to sleepwalk into stagnating. I’m not advocating change for changes sake, but I think it’s important to continually examine what you’re doing. I guess, really, that’s the whole point of this site. In many ways, writing these daily “things learnt” is performative – that is, the act of writing them, in itself helps me to examine my life (“the unexamined life isn’t worth living” and all that).
I haven’t fixed all the things I need to fix (my sideboard is still a mess!) but I’m aware of it, and it’s on my list of things to do. I think, too, before putting something down now.
I’ve moved house.
My new flat is lovely, but I’ve spent the last four days without the internet at home. And you know what? I actually loved it! It’s really changed my life.
I remember now that I’ve felt this way a few times when I’ve been without the internet. I’ve suddenly had… time! There’s, like, five hours between getting home and going to bed.
I usually fill a good part of this with the internet. Without it, I have time to do stuff! Loads of stuff. I’ve taken up listening to Radio 3 (oooh, classy!) which is incredibly relaxing. And I’ve done some writing, and reading and just got on with things.
I don’t think I can give up the internet fully, but I think I may try to go one day without it.
But how have you been writing this without the internet, you may ask. I wrote a couple at home and posted them at work, and one on my iPhone. It’s really not that much of a problem.
I wrote once before that this site wasn’t turning out quite the way I was expecting.
My intention was for the things learned to be relatively factual – you know, how to tie your shoelace, how to do long division etc. However, other than the occasional blasts of knowledge, most of this so far has been morals or styles of thought. I put this down, really, to the fact that I’m at home for Christmas, and have switched my brain to sleep mode. I’m hoping this will change a little next year.
Well, that turns out not to be true – most of this is ideas or ways of looking at things, rather than “blasts of knowledge”.
The thing is, ideas come cheap. Realising things, or figuring out ways of doing things is quite easy. There are books and books full of ideas. The hard thing is converting those ideas into changes in behaviour.
This has struck me quite a lot recently. There are lots of best practice things that I know. You know, each piece of data should exist only once. Minimize your code by reusing the same data. Make code portable. Etc etc. All of these things I know as concepts are good things to do.
Yet, in reality, time and time again I break these rules. Not because I forget them, but because living your life is quite different to thinking about your life. It’s so easy to unlearn things; that is, un-fix a problem that you’ve already solved in one place.
I don’t think I necessarily have a solution for this, other than lots of calibration. This blog helps, since it forces me to think about what I’ve learnt. And by adding in lots of links to previous articles, in encourages me to remember things I’ve written before.
But I think there’s a missing piece still, and that’s forcing myself to “practise what I preach”. That’s going to be my aim for the next few days.
In many ways my last few days have been filled with thoughts about scope creep. As I said a little while ago, a lot of my projects are suffering from this. And partly it’s because I’m being a little bit too ambitious. So I’ve intentionally dialled back on what I’m doing to make sure I hit the core values.
Part of this has involved reviewing my coding, and I’ve reminded myself of the importance of building a central, maintainable framework.
“Maintainable” is the key word here because “code rots”:
Code is bad. It rots. It requires periodic maintenance. It has bugs that need to be found. New features mean old code has to be adapted. The more code you have, the more places there are for bugs to hide. The longer checkouts or compiles take. The longer it takes a new employee to make sense of your system. If you have to refactor there’s more stuff to move around.
You realise this when you come back to something you were working on several months ago, try to run it and it crashes.
- Partly it’s because of that bug that you never got round to fixing but knew about and knew the workaround for.
- Partly it’s because something else changed along the way and broke it.
- Partly it’s because you’re not caring for it and fixing bugs and improving it any more.
As soon as you stop actively looking after it, it starts getting worse.
Of course, you can’t look after every project at once, but what you can do is write a centralised code library, look after that, and pull much of your stuff from that. That way, you’re actively looking after most of the code at once.
Jeff calls this “tending to your software garden” and I think I agree with him. I think I need to come up with more ways to keep my garden well looked after.
I was talking to my colleague today.
He and I don’t get on very well. We have different views on many things. But I realised today one thing we disagree about is responsibility. He regards any failure as being the responsibility of the team beneath us.
“They’ve not managed to do this…”
“They can’t tell us this…”
Sometimes, his complaints are completely unrealistic.
However, I realise that I’ve started sharing that responsibility. And I think that’s the right thing to do. The team does what we tell them to do. They get their attitudes and values from us. If they fail, we fail.
I’ve never thought it quite as clearly as that, but I think I will from now on.
And I think this is important when you manage teams. You have to share the responsibility. That way you get involved with the problem and help them solve it. You also remember that your attitude affects them in so many ways. In many ways, managing a team is like having children. They look up to you.
I’m reminded of the speech Daniels gives in the final episode of the first season of The Wire:
Couple weeks from now, you’re gonna be in some district somewhere with 11 or 12 uniforms looking to you for everything. And some of them are gonna be good police. Some of them are gonna be young and stupid. A few are gonna be pieces of shit. But all of them will take their cue from you. You show loyalty, they learn loyalty. You show them it’s about the work, it’ll be about the work. You show them some other kinda game, then that’s the game they’ll play. I came on in the Eastern, and there was a piece-of-shit lieutenant hoping to be a captain, piece-of-shit sergeants hoping to be lieutenants. Pretty soon we had piece-of-shit patrolmen trying to figure the job for themselves. And some of what happens then is hard as hell to let down. Comes a day you’re gonna have to decide whether it’s about you or about the work.
I’ve realised that I’m really bad at taking notes. It was sort of one of my New Year’s Resolutions to take better notes. But that hasn’t worked out so far. As you can see below from a typical meeting:
There’s two things that strike me about this actually.
Firstly, the “quick win” rocket, and how messy and ridiculous a lot of this is.
Secondly, how unimportant a lot of this is. It’s not that I don’t understand these notes – a lot of them were just unimportant or not chased up.
I’ve been thinking about this note taking problem. And I think it fits into a few other things. Quite a few of my projects (and projects in general at work) are dragging on. There’s a lot of scope creep and project failures.
I think all of this can possibly be solved by setting slightly clearer boundaries and “logging” things correctly.
Take notes, for example. There are a finite areas or workstreams that I am involved with. Every note I take should fit into one of them. If it doesn’t, I either have to create a new one, or not take the note. In many ways this fits back into my idea of a software solution that encourages you to work, communicate and log in the appropriate area. Taking notes on a per meeting basis is wrong, because it means all your notes are sorted by meeting, or event. But in reality, you want your notes sorted by category, or type.
Computers are very good at this sort of thing, since you can log a many-to-many relationship. But humans not so much so.
I wonder if one option here is to make a small note logging application of some type and use a computer to take notes.
Whether I do this or not, I think I’m going to have to start logging notes in a more project based way, because it’s beginning to get ridiculous.
I’m reminded again about this bit of wisdom from Coding Horror:
Truly lazy developers let their machines do the work for them. This is partially motivated out of self-interest, it’s true, but smart developers know that people don’t scale— machines do. If you want it done the same way every time, and with any semblance of reliability, you want the human factor removed as much as is reasonably possible. I know for every problem I encounter at work that causes me to lose time, I ask myself— how can I make sure I never have to deal with this problem again? If my solution fixes it so nobody ever has to deal with that problem, that’s a nice side-effect, too.
It’s close to my heart, because I’m very lazy as I keep saying.
But while I know this, and I mean it and I say it to anyone who will listen, I keep encountering problems that I solve by doing a bit of manual work. And suddenly, I’ve got loads of manual systems that I’m involved with.
I don’t really know a way around this. This is something so close to my heart, and yet I still get caught up in things and end up in a manual mess. I think the only thing to do is keep track of all your project somewhere, and recalibrate regularly – possibly every month. If this blog has taught me anything it’s:
- Doing things regularly works. But only if you stick at the regularity
- You need to recalibrate regularly. More regularly than you think. As humans we get used to things very quickly.
Last night I made myself do some writing. I was lying in bed, thinking about writing, and in the end I said, actually out loud, “Just do it.” Unfortunately for me, my motivational phrase is the Nike slogan, but it worked really well. I picked up the laptop and got on with it. And, as I’ve noted before, once I started I really got into it, and it was fine.
Sometimes you have to just get on with it. And it doesn’t matter how many times I tell myself this, it’s still hard. Saying it out loud helps, I think.
I spend a lot of times putting things off. Often I come up with reasons for why I can’t do it. “I just need to watch this episode of 24, otherwise the thought of it will distract me.” I’m lying to myself, of course. When I finish that series of 24 I’ll just start the next one. And when even when I’ve watched all of 4 I’ll just find something else to watch.
It made me realise that I often lie to myself. Or say things to other people that aren’t quite true to convince myself that they are. I need to stop lying to myself. It’s pointless, because I know it’s a lie. I came up with the damn thing!
I had to tell someone off today.
It’s the first time I’ve ever done it. All my life I’ve been the pupil, the child, the employee – and generally I’ve struck a fine line between compliance and rebellion. (My English teacher once called me “subversive” which I took as a massive compliment. And knowing him, he probably meant it as one).
In the words of Jack O’Neil from Stargate:
I have spent my life sticking it to the man. Now I am the man.
But I think this is probably good. You want your people in authority to have a healthy distrust of authority. You want them to be challenging themselves and aware of what authority does to people.
I think I handled the telling off quite well. It struck the right balance, something L has always been good at at work, between chastising without getting personal.
The one thing I did forget to say was something along the lines of “this isn’t an exercise in fault finding, we just want to make sure it won’t happen again”. But I think that was the general impression.
I didn’t bulldozer quite as much as I have before, and in hindsight perhaps I should have a little bit more. But what I did right was leave it a few days. The “incident” (I’ve made it sound a much bigger deal than it was here) happened on Tuesday, but I left it until Friday, once everyone had calmed down, to have a chat about what had happened and to give the firm message that this wouldn’t happen again.
If you can keep your cool, I think you keep your respect as well. Fear isn’t any way to manage, and if you get too authoritarian, people will start coming up with ways to bypass you.
There’s a couple of projects I’ve been working on that I thought were going to be really easy and were actually incredibly difficult. I’ve realised, there are so often so many unforseen circumstances.
I’ve realised that even though I’d read Jeff’s article on estimating before, I’m still rubbish at estimating how long things will take:
When you compare the original single-point estimates to the Best Case and Worst Case estimates, you see that the 11.25 total of the single-point estimates is much closer to the Best Case estimate of 10.5 days than to the Worst Case total of 18.25 days.
You’ll also notice that both the Best Case and Worst Case estimates are higher than the original single-point estimate. Thinking through the worst case result can sometimes expose additional work that must be done even in the best case, which can raise the nominal estimate. In thinking through the worst case, I like to ask developers how long the task would take if everything went wrong. People’s worst case estimates are often optimistic worst cases rather than true worst cases.
I need to start doing this in my projects, and, also, asking other people to do this as well.
I had to get angry with our outsourced IT partner this week as they came to a meeting having not done the one thing I asked them to do. I think I got the balance right – calm but very displeased. So we’ll see if they do it again.
Afterwards, they were so eager to please me that they said they’d get the next bit of work done within a week. I probably should have pushed more for best case/worst case estimates.