> If you are a highly productive person (and yet have a good work-life balance), could you share your methods? In order of importance: Code: - In order or pr

> If you are a highly productive person (and yet have a good work-life balance), could you share your methods? In order of importance: Code: - In order or priority when coding: Does what you want it to, easy to understand, good performance. You can re-write something that does what you want it to to be easy to understand, you can rewrite something that's easy to understand into something with good performance. And you'll generally learn something at each step of that chain which makes the next step easier, (or possible.) - If working on the code, (not just trying to get a map of it in my head,) I only have one function open on my screen at a time. By that I mean that everything else will be collapsed or in a different buffer; somehow I won't even be looking at it. This does not, of itself, make you any faster – at least not that I'm aware of, it may lower some mental load that I haven't considered. However, if your code is so entangled that you can't write without having several functions open on your screen at the same time, then that's a very strong sign that that there's a poor abstraction at work. In which case it's often better to burn it to the ground and write a new one. Which brings us to: - Burn it to the ground and start over. Specifically with respect to hunting bugs: Before diving into a function someone wrote, or that I wrote some time ago, to hunt a bug, I'll try to write a new function that does what that function reports itself to do, (or method if I'm using OOP.) Often, it's a lot faster to write something that doesn't have that error to begin with than it is to work out precisely what went wrong the first time around. - Naming. Good naming is hard, and the decision as to what to name is non-trivial. It may seem obvious to you that a bit of code gives you something but it's not necessarily so to others. For this reason alone, though I don't like pair programming, I make time every couple of weeks to do it. It gives me some idea of what's non-obvious, both to me and to them. “What's this?” Having the right things named makes your code much cleaner and easier to manipulate. - If the function doesn't fit on one reasonably sized monitor, in other words if it's longer than a couple of hundred lines, then chances are either I'm writing it wrong or I've made some sort of design mistake; the function is too general, or tries to do too many things. This is not a strict rule as the other, and obviously varies to some degree by the syntax of the language one uses. A relatively dense language like Lisp I'd say if it's longer than 40 lines. - Don't use a new library in production code unless you have good reason to. There are far too many people who want to play with the latest cool toy just because it is the latest cool toy. Do that on your own time. Work method: - I don't have a to-do list, I have a calendar. This helps with managing interruptions and prioritising things. IME it's easy for people's to-do lists to grow far too large, without them paying any mind to when they're going to do things and the little inefficiencies involved in changing to each task. Someone comes up and wants something done I can look at the calendar and know what can be moved and when something can be slotted in. - If I can help it, and this means unless someone very senior in the company tells me otherwise, I don't book periods of time shorter than an hour for a task. If there are a lots of little tasks that are related then I group them and book an hour. If there's only one little task, it's still an hour. Preferably, however, these are things that get pushed later in the week when they can be grouped. - I don't have automatically checked email and I don't have any work-known email accounts on any non-work computers. I check my email at the start of the day and the end of the day, and that's it. Email is an enormous time sink. - I have a separate work phone and home phone, and the work phone is turned off and lives in a locked draw in my office when I'm not at work. - Strictly police your free time. If someone asks you whether you can just do this thing for them, or whether you can stay on that night to get something banged out… well, there are times to say yes, but most of the time the answer should be no. You probably need your down time. This also makes people take your time more seriously and lets them know that if you are staying on it is a favour. - I only take holiday in week long chunks of greater. Contiguous time off is, IME, dramatically more rejuvenating than a day here and a day there. - Have hobbies. All my best ideas have come from hobbies. Be that reading fiction and thinking 'I can make a shadow of that.' Or seeing cool art examples. Or meeting someone at a club who tells me about a problem they have. You might think that this is going to be a point about knowing what people want. It's not, although that can happen. It's a point about knowing how different people think about the problems which lets you generate more fitting abstractions.