Tag: programming

Categories
Personal Work Habits

Why the Pomodoro technique doesn’t work for me

My friend Amanda writes a great blog over at Capture30Days. Her recent post “getting stuff done” outlines the Pomodoro technique: work for 25 minutes uninterrupted, take a 5 minute break, start again. I think it works great for some sorts of work.

It doesn’t work for me.

I had tried this technique, but I found for my sort of work it sometimes was in fact harmful.  I guess my work (designing educational apps) swings between product design (creative, collaborative) and programming (a different sort of creative, lots of problem solving, often on my own) and so I sometimes need to just work through a task list and have lots of interactions with others, and I sometimes need to have long periods of uninterrupted focus.

For the programming especially (and to an extent the design also), I have to work hard to get into a “flow” state, where I get the entire mental model of what I’m creating in my head, so that I can work and create efficiently, remembering how all of the different pieces of my app are supposed to fit together.  It can take me a couple of hours to get into this state.  And when I’m in this state, I don’t want to stop.

And knowing I have to stop, because my 25 minutes is up and it’s time for a 5 minute break, or because I have a meeting, or because it’s lunch time, can seriously throw me off.  I’m not the only one.  Paul Graham contrasts the “managers schedule” (1 hour blocks, optimised for meetings) and the “makers schedule” (usually blocks into “morning”, “afternoon” and “working into the night”, optimised for creative work).  He makes the point that for a creative, a single meeting can destroy a whole afternoon.  I definitely have experienced that.

So, alternative to the Pomodoro technique?  I personally go for the 1-3-5 technique.  It goes like this:

Today I will achieve:

  • 1 Big Things:
    _______________
  • 3 Medium Things
    _______________
    _______________
    _______________
  • 5 Small Things
    _______________
    _______________
    _______________
    _______________
    _______________

I find this gives me the flexibility I need to work on big tasks that require long periods of focus, as well as help me not forget the small things that also need doing.  In reality, a day may end up looking like this

  • Morning:
    Small task 1 – emails
    Small task 3 – voicemails and phone calls
    Small task 4 – fix small bug
    Medium Task 1 – draw interface designs for a new feature
  • Afternoon:
    Small Task 5 – responding to support questions
    Big Task – programming a new feature
    Medium Task 2 – got started finding a bug, did not finish.

If I’m having trouble getting into “the zone” or “flow”, I start with the small tasks and work my way up to the big ones.  If I get stuck on one task, I jump to a different one.  Then anything I don’t get done, goes on to the list for the next day.

Finally, there’s a website which makes this easy: http://1-3-5.com/  I set that site as my homepage, so every time I open a new tab, rather than Google or Facebook, I see my task list.

Do you have any tips for staying focused and managing your time when working on creative or programming projects?  Especially when you don’t have a formal workplace to keep you accountable :)

Categories
Haxe

Language and API Design

Paul Graham has written some great essays over time, and most of them hold up surprisingly well as they age.  Take this article, “Five Questions About Language Design“.  Written in May 2001.  That’s over 12 years ago from today as I read it, and many of his predictions have come to pass (the dominance of web applications, the rise in popularity of niche programming languages), and most of his logic is still sound, and still insightful.

Two particular points I found interesting, and would be interesting to the Haxe community I spend most of my time in:

4. A Language Has to Be Good for Writing Throwaway Programs.

You know what a throwaway program is: something you write quickly for some limited task. I think if you looked around you’d find that a lot of big, serious programs started as throwaway programs. I would not be surprised if most programs started as throwaway programs. And so if you want to make a language that’s good for writing software in general, it has to be good for writing throwaway programs, because that is the larval stage of most software.

I think Haxe is beginning to show it’s strength here in gaming.  People are using it for Ludlam Dare (write a game in a single weekend), and then later the game scales up to be a full-featured, multi-platform, often commercial game.  Haxe is good for a quick win (especially when targetting flash), but then you have the options to target so many other platforms as your vision for your game/app expands.

I’d love to see ufront get this good.  I have so many things I would like to use as an app, but which I don’t feel justify an ongoing subscription to an online company.  Many of them could get an MVP (minimal viable product) out in a weekend, if the framework was good enough.  And it’s getting good enough, but still a little way to go :)

And then this:

2. Speed Comes from Profilers.

Language designers, or at least language implementors, like to write compilers that generate fast code. But I don’t think this is what makes languages fast for users. Knuth pointed out long ago that speed only matters in a few critical bottlenecks. And anyone who’s tried it knows that you can’t guess where these bottlenecks are. Profilers are the answer.

Language designers are solving the wrong problem. Users don’t need benchmarks to run fast. What they need is a language that can show them what parts of their own programs need to be rewritten. That’s where speed comes from in practice. So maybe it would be a net win if language implementors took half the time they would have spent doing compiler optimizations and spent it writing a good profiler instead.

Nice insight.  I sometimes worry that the code I’m writing will be slow.  It’s hard to know if optimisations are worth it, especially if it may compromise code readability etc.  A better solution would be to focus on making profiling easy.  On the JS target you can easily use the browser tools to show profiling information.  Another option is to bake it into your Haxe code, something that the “massivecover” lets you do.  Wiring that support from massivecover into ufront or other frameworks, and generating pretty reports, would be a very cool way to encourage people to write fast apps.

Categories
Haxe

Trying to understand dependency injection

Coming closer to the end of writing my first really complex app, I’m beginning to wish I’d taken the time at the start to properly learn and grasp some of the concepts that I see other programmers using.  My client-side code uses a basic MVC pattern, but a bunch of Flash Developers use something that to me comes across as much more complex – as seen in RobotLegs or some of the Haxe ports, such as MMVC.

These frameworks are all about Inversion Of Control (and because we love acronyms: IOC).  And they use Dependency Injection (DI) to do this.  You can see already why the learning curve can be steep, especially if you haven’t come across this pattern before.

So today I googled “I don’t understand dependency injection” and got this fantastic explanation by Kevin William Pang.  I found that really helpful, and I’m sold.  I’d been wondering how the hell I was supposed to unit-test some of my more complex client code anyway… If you’re one that, like me, hasn’t understood this concept in much detail: his article is well worth a read, I won’t bother to try and explain it here.

But, I’m still not sure where the fancy dependency injection tools and frameworks come in.  I see the value in it, and I think “injecting” it into the constructor by using arguments given to the constructor seems just fine.  Meanwhile, the tools which are supposed to help, such as SwiftSuspenders or Minject seem to me to be really verbose, and not offer a lot more than the constructor method.

Maybe that style is more relevant for gaming.  Or maybe it’s benefits show up with more complex projects.  Or maybe I just haven’t been enlightened.

Either way, I’ll try to get enlightened… I think it’s worth spending time learning these patterns.  They’ve obviously gained traction for a reason, and a lot of better developers than me swear by them, so I’ll try wrap my head around it.  Maybe one day it’ll seem as clear to me as MVC, or even OOP do now (both of which took me a while at first).

If you have any suggestions / comments / explanations – I’d love to hear them in the comments section.