Joshua Go

I'm really into writing documentation, and very often, this documentation must include code samples. I wanted a JavaScript syntax highlighter that: involved very little hassle in setting up, worked like a real parser using parse trees to ensure accurate highlighting, and provided decent coverage of the most common programming languages in use today. Obviously, by opting to go with a JavaScript syntax highlighter, I chose to forgo the option of doing my syntax highlighting on the server side. Doing it on the server side still interests me, but for immediate and practical reasons, the quickest way to get syntax highlighting in my documentation would be to do it on the client side. I went searching around for JavaScript syntax highlighters, and these are the top three that met my criteria. Javascript code prettifier . This was the first decent one that I found. It's pretty basic but I got up and running very quickly. The documentation is sparse and the tone of the README quite ter...

Back when I was writing software that ran on HP LaserJet printers, I hated having to wait 45 minutes for one-line changes to compile (in a ClearCase build system) and then burn to flash memory. Sometimes, a problem with the printer's behavior wouldn't even be a problem with my software. It would sometimes be caused by an obscure bug in the hardware. Because of time to market pressures, the team would have to work with prototype hardware, the design of which wasn't even finalized yet. The guys who wrote the low-level code had to write some registers and hack their way around hardware defects. Somehow, it seemed wrong to me that I should constantly be worrying about the integrity of the underlying hardware or the operating system on which my software ran. I should have been able to take it for granted. I longed for the day when I could instead work on web applications, where I could safely assume that the hardware was fine and that there were no major defects with the platfo...

Last night, I played some of my old classical music CDs — good music to program to. The songs skipped every other second because of the scratches on the discs. It appeared that my careless handling of CDs over the years eventually caught up with me. Tonight, I ripped some of these to Ogg Vorbis (an open and royalty-free file format similar to MP3) to see if I could listen to my songs without the skipping. Sure enough, they were all smooth! Now, none of this is stuff that I'm terribly surprised about, but it just served as a reminder to me that relying only on physical media to store data is a little dangerous, especially when the medium goes bad or acts flaky. The lifetime of information on the network is short, but as long as it's out there, stored and accessed frequently, it's constantly being duplicated and refreshed. Information that's alive and circulating is healthy information.

This month's Harvard Business Review contains an apt and timely article, "Leading Clever People." Rob Goffee and Gareth Jones define clever people as "the handful of employees whose ideas, knowledge, and skills give them the potential to produce disproportionate value from the resources their organizations make available to them." Still, this doesn't mean that they're better off working on their own. One of the people they quoted, the head of development for a global accounting firm, stated that clever people "can be sources of great ideas, but unless they have systems and discipline they may deliver very little." One good point they made about managing clever folks is the importance of demonstrating that you're an expert in your own right. This is to establish credibility and respect. At the same time, one mustn't be so above-and-beyond or in-your-face so as to discourage the real talent. Read "Leading Clever People" at HBR. ...