About Me
Background and bio
My name is Michael Descy. I am a writer, programmer, and information systems auditor. One of my specialties is data analytics, and another is knowledge of IT controls. I have worked professionally in IT, insurance, finance, and audit since 2000, and as a programmer and technician since I was in high school. I live in New Jersey with my lovely wife and adorable daughter.
I have a personal home page and a personal blog.
Please contact me via LinkedIn.
Plaintext
I didn't always use plaintext for everything. I spent years mousing around in different organizational tools and word processors on the desktop and on the web. No matter how much I liked my current software, I would fall into the "optimization" rabbit hole every few months and evaluate every new or improved competing system. I would often switch to new software, move all my old stuff over, and then switch again a few months later, always looking for the newest and shiniest system. I should have been spending that time doing more work, using the system I already had. That's why I simplified everything severely and went all the way back to plaintext.
Plaintext is something I became passionate about because of my experience as a programmer, data analyst, and writer. As a programmer, it always amazed me that simple, little text files could be compiled into amazingly powerful programs.
Working in data analytics, I've used many different file formats, and always felt most confident working with plaintext. Sure, you have to define a format to prase plaintext formats, but mastering that one difficult step yields many dividends down the road. With plaintext data files, no meaning is hidden behind formatting (no numbers are rounded, and there are no formatting characters to screw up your strings) and everything is extractable in milliseconds with command-line tools (such as grep, head, and tail). Plus, it always amazed me just how compressible plaintext files are, especially compared to binary formats.
As a writer, I have used nearly every word processor that runs on DOS, Windows, Mac, and Linux since the mid 1980s. (And I still kind of miss WordStar.) As my writing tools have been upgraded or discontinued over the years, I have had to convert my documents to new formats every few years so I can be sure I will be able to read them a few years from now. That is not a fun process. When the OpenDocument format (which is a compressed XML text file) came out, I was thrilled. When Markdown came out, I was even more thrilled, because it simplified my file format needs even more.
Biases
If you like or dislike my work here, you may want to understand the principles behind it. These are some tenets I believe in and serve as the biases behind the organizational system I created and the recommendations I made:
- Free and open is always better than proprietary and closed.
- Closed file formats are worse than closed-source software.
- Paying for good software feeds developers, which is a good thing, and begets more good software in the future. This is especially true of open source software.
- Use the right tool for the job, even if you have to pay for it.
- Simple is better.
- You may have to go through some complexity before your get back to simple again.
- Mac OS X and iOS are way ahead of competing platforms in having excellent, beautiful, and thoughtfully designed software. Most of that software is not free. Other platforms are either way behind in some areas or have a glut of garbage and a few gems (Windows 7 is a prime example).
- Writing work is iterative. You will do multiple drafts and revisions of things. A lot of the work happens in your head while you are writing and editing in your word processor (hopefully!), or while you are away from your writing tools (typically).
- Backups and revision history are critical for any type of creative work. You don't want to lose anything, and knowing that your old work is extractable if you need it makes it much easier to "kill your darlings" when working on a big, woolly project.
- Collaboration is essential at work. You should have a final or master version of each file you are working on, and each collaborator should manage his or her own drafts of that file. If you have a centralized system with version control, that's even better.
- What works for me may not work for you, and vice versa. That's OK.
About this site
This site was built with Punch in HTML5 and CSS3 with modern browsers in mind. Icons came from IcoMoon. I wrote the content in Sublime Text, Editorial, and ByWord, and did all the coding in Sublime Text. I used plaintext as much as possible, down to the scalable vector graphics used in the iconography.