[u-u] jobs @ rakuten/kobo

[arocker at Vex.Net]

>
> I tell my software engineers: you ARE going to write test cases and you
> ARE going to write documentation so the smart thing to do is document
first,
> test second and implement last

Treating documentation as the first level of specification and writing a
set of tests to break anything defined (until it's doing the right thing)
seems a good way of developing a specification for desired code. (Though
in the past, the "write tests first idea" has met a good deal of
derision.)

I'm drafting a training course for Perl 6, and I'm seriously thinking of
making commenting the first topic, before introducing any actual commands.
Then create no-op scripts that are merely a plan for the desired
processes, and proceed to fill out the functions underneath the comments
describing them.

Does that sound like too much of a departure from the traditional sequence
of a language course, or otherwise weird, to be accepted?