My favourite quotes by Isaac Newton

  1. If I have ever made any valuable discoveries, it has been owing more to patient attention, than to any other talent.

    Found via

  2. If I have seen further it is by standing on the shoulders of giants.

  3. I do not know what I may appear to the world, but to myself I seem to have been only like a boy playing on the sea-shore, and diverting myself in now and then finding a smoother pebble or a prettier shell than ordinary, whilst the great ocean of truth lay all undiscovered before me.

When your program takes too long, you get distracted

You should instead use the time to optimize your program or tools until these distractions cede.

Ultimately, you want to test your software until it yields the expected results, either by passing all tests or by returning results of a measurement for example. But sometimes, your initially conceived software architecture or test set or tools don’t live up to the challenge. By this time tour program has become complex enough that it takes a while to run all the tests or to measure all your data.

And during this time the distraction devil sneaks in and wastes your time. When what you actually want to do is use that time to improve your actual measurement or evaluate the data and think about what else you would want to measure.

Therefore, you should instead work on refactoring your software, your tests or improve on your tools. I have the impression the part of a programmer’s work from which interesting open source tools emerge (e.g. editor plug-ins).

Whenever you catch yourself idling (i.e. reading random stuff on the Internet in time slots which are not designated to this) then think about (and feel) where your own software or tools are limiting you. Start from scratch, improve on your tools or refactor your software until it does exactly what you need it to do.

If you’re too tired to do any of this then take a break or do something that distracts your mind from this problem for a while. But do not sit in front of the computer pretending you’re working on a problem when actually that problem has defeated you and you’re escaping the truth by facing some random distraction instead of the venue of the war. Release the pause button, get back in and fight 😉

On writing scientific papers

I recently found the essay On our duties as scientists. I liked the following sentences in particular:

The purpose of writing scientific papers is to communicate an idea (or set of ideas) to people who have the ability to either carry the idea even further or make other good use of it. […]
An idea can be a new way of looking at objects (e.g., a “model”), a new way of manipulating objects (i.e., a “technique”), or new facts concerning objects (i.e., “results”).

To me, the first sentence nicely formulates the essence of scientific papers. I imagine at least one person sitting a talk I’m giving and really thinking: “That is a good idea, I could use that, why didn’t I come up with that.”

I seems to me that in the branch of research I’m working in (neuromorphic engineering), it is more of a competitive than of a collaborative situation. People publish their circuits to show how far they’ve come and what their chips are able to do. Many of these publications are mere advertisements or computer system descriptions than scientific research reports in the sense of the above-mentioned essay.

However, this does not imply that there are no new ideas hidden in these papers. But the systems or chips that are described are, in my opinion, not solutions to well-defined problems and therefore cannot and will not be reused.

The authors of the papers whose existence I’m questioning might have found very good and new solutions for a particular problem, for example an asynchronous serial data link (or any other part of their system). Therefore, I opt for breaking papers up into smaller portions of which each one conveys only one idea that can really be useful for other people. Papers on large circuits or even on whole systems won’t help anyone in the wider scientific community except the author(s).

But, these system description papers will help the group in which the system itself has been built. So they should be written as internal technical documentation and not as public scientific articles. This has the additional advantage that there is no limitation on the number of pages and no constraint on the page layout whatsoever. The compromise which one often has to seek, between too full detail and few pages, disappears.

I think that by having to focus one’s publications on parts of one’s work that really contribute new and useful and reusable ideas one will maybe start thinking more collaboratively.

Two-Column Scientific Journal Articles

I was wondering why I find many two-column scientific Journal publications so hard to read.

I guess the main reason is that the figures are often too far away from their references. As shown here:



What you can see here is that there is a huge distance between the reference to figures 1 and 2 and the actual figures. When reading this on a computer screen you have to scroll around a lot.

The reason for this seems obvious: Journal publications layouts are still optimized for being printed on paper in letter format. Therefore, they use two columns because the lines of text would be too wide otherwise, except if they wasted more than half the page’s width by leaving it blank.

But it seems to me that the figure placement becomes really hard with these layouts. And it becomes even worse with strange  rules like “no figures on the front page” (at least it seems to me that such a rule exists. I think that it would be much more convenient if the text was laid out in one single column and if the figures were directly places next to their references (and in case of multiple references to those that explain the figure first).

Some Journals have obviously already realized this problem and I’m not telling a new story here, but still, I wonder why someone started to use this strange layout in the first place.


Programming an almost bricked AVR

The Atmel 8-bit microcontrollers have fuse registers that can easily be overwritten during bootloader installation. If this happens you won’t be able to program your AVR via a serial programmer anymore. This might result in avrdude giving you the following response:

initialization failed, rc=-1 Double check connections and try again, or use -F to override this check

The most severe bits are the bits RSTDISBL, DWEN and SPIEN. The latter one cannot be overwritten in SPI mode, so that one should be save. You’re completely spoilt however if the RSTDISBL bit is set to zero (remember: fuse bits in AVR are read out as ‘enabled’ when set to 0). In this case you’ll need to use the high voltage programming mode of the AVR which I’ll explain below. The low voltage programming mode (normal ISP mode) cannot be used anymore since the reset pin is then no longer an input pin and it needs to be set to low voltage externally to enable the SPI interface.

Another problem occurs when DWEN is set to zero. This disables SPI programming and enables the debug wire single-wire interface.

To make sure, whether you’ve programmed your fuse bits to funky values try:

avrdude -c PROGRAMMER -P PORT -p DEVICE -n -v

And put the fuse byte values into the fuse calculator at

To resolve these issues, you need to apply high voltage programming as described here:

Btw.: There’s also an arduino solution for this problem:

Helpful guides for me were:

Deutsche Übersetzung für WordPress eShop Plugin

Für den Shop von brauchte ich eine deutsche Version des eShop-Plugins für WordPress. Leider wurde ich nicht fündig, weswegen ich selbst die nötigsten Punkte übersetzt habe.

Um die zusätzliche Sprachdatei zu verwenden muss man ein eigenes Plugin installieren, dass nur die Sprachdateien enthält, wie in der eShop-Doku beschrieben wird.

Das Plugin mit meiner Übersetzung kann unter heruntergeladen werden. Der Kunde wird in meiner Übersetzung gedutzt! Die Datei enthält die Übersetzungsdateien sowie eine Datei, die WordPress benötigt um das Plugin zu erkennen.