caloni

If there's only both alternatives, that's right. There's at least another one: spend zero.

And don't forget that, after all win the minimum, that's the new zero.

A good advice for programmers, too.

I'm a C/C++ programmer for more than 10 years for Windows, and these last years waiting for compile/link and a lot of annoying errors absolutely nonrelated to what I was doing it is really disappointing.

So I began to code in Python to test things and as my hobby language in free time/other hobby projects. Changing from a old well-known world to a refreshing and problem solving focused world was one of the best things I made last year.

I believe learning a new language has to do with this feeling, but if you are going to learn something new, try to choose a modern language that turn the problem solving in the main track, not compile error hunting.

Thanks for sharing. Good to know that it is not just me doing this flash-review =).

I write mostly about movies and I started writing my first reviews with a notepad inside the theater, making quick notes without looking as I notice something (just anything since it will be filtered later).

After four months I got confidence to just make quick notes on my brain and remember the more important ones in the final creditd. When it is write time, I dump a lot of ideas growing up with these notes.

This is my hobby so I am not interessed in spend too much time doing this (better watch another movie) so I force myself to write for every movie I watch and do it as quick as possible. The brute force is slowly improving my writing skills, do I am now more interessed in style guiding.

I've passed a lot of my first 10 professional years fixing bugs for a information security company. One of them was pretty hard to find out because it was inside the boot of a specific IBM machine in a specific version of a HD encryption bootstrap. The sympton was the machine could be turned on normally, but in the second boot we got just the black screen after the BIOS check forever. Oddly enough, in the third boot things got just right, freezed again in fourth boot and so on.

The problem with boot code is that the debug process cannot interfere with the boot memory itself or the bug won't show up. So I got to make one simple change in the assembly bootstrap, assemble the code, boot with a floppy, access a raw disk editor and replace the old bytes for the new test, boot twice and see what happens (mostly some chars printed on screen).

After one week focused the problem decided to show up. It was a micro misplaced bit operation in the blowfish algorithm (our version in assembly) that swap one or two bytes in a specific sector in the disk. This happened just in this machine with this HD and this version of O.S. because in the boot process some code in the O.S. bootstrap made a write operation in the disk just in this "wrong sector". It was not hard to fix this problem, but to find it for the first place, and after this system already running in thousands of different machines for a couple years without a clue.

It was a pretty nice week in the end.