Header Image -

Monthly Archives

2 Articles

Weekend Coding Babble

by dave 0 Comments

I tend to spend some time each weekend coding some personal projects, for the reasons listed below. Each reason could be a post of its own, but I’ll save that for another day.

  1. Keep up with new platforms and frameworks
  2. Experiment in areas not covered by my work.
  3. Build tools that my family or I can use around our home
  4. Because I enjoy what I do, and want to have some personal projects under my own control

But there is a huge difference in the toolkit used for my work vs my personal projects. All of my personal projects reside 100% in the browser, and are free to the public with no registration or user accounts required, and no data tracked. This is all a deliberate, philosophical choice, which could also be a post for another day.

These contraints lead to simplicity in my work. Everything is just HTML, CSS, and Javascript. It all resides in static files on my hard drive. I keep it all in my DropBox folder, so I can move between systems easily. I can test locally, there is no build process. I just need a text editor and an FTP client to push it live when I am ready.

The choice of a text editor is really the reason I started writing today. Text editors are almost a religious argument amongst developers. But my needs are simple:

  • A non-white background, to make it easier on my eyes.
  • A UI that lets me view the files/folders I am working with, and open multiple files at the same time. (I like tabbed UIs, but that is not a requirement.
  • Color-coded syntax.

For quite a while I’ve been trying Sublime Text. But it is not free. Atom.io provides a similar editor, which is free. Sublime Text feels more polished – it is more responsive, starts faster, remembers where I was better. But once I have all my files open and am really doing my work, the editors are pretty similar.

I think I am going to have to stick with Atom – its startup speed is annoying, but… free. It is really hard to compete with “Free”.

 

Sleep and Code Testing

by dave 0 Comments

Just more notes on how I tend to work as a work-from-home software developer who works on such a small team than I tend to be a lone coder for most projects…

I try to never test code as soon as I am done coding it. I’m still too close to the code at that point, and I miss obvious things. I have a hard time just flipping a switch in my head and coming at my work from a QA perspective. Even taking a break isn’t quite enough. So I almost always code on one day, then test the next day. This does put a damper on extremely rapid turnaround, but rarely do we need to be that fast anyway.

However, there are other problems that arise if I finish a piece of work, say at 9 AM on a Tuesday, and want to let it sit for a day before testing on a Wednesday. If I jump into other projects, then I am too far separated from the project to be tested, and I lose some ground getting back into that project’s groove. But if I don’t jump into another project, I’ve wasted a day, and that just doesn’t match my work ethic.

So I try to write up testing checklists as soon as I am done coding., outlining which features need tested, use cases and specific details to test. Having the lists helps me get into the groove the next morning, so I can be productive even as my brain ramps back up the next morning, and form the basis for updating overall test scripts for the entire system.

But the lists also help because as the day goes on, I tend to think of other edge cases that I should test for, or other impacts the code changes could have across our systems. Having a checklist at hand allows me very quickly add an item to the list, then forget about it and move back to whatever I was working on, improving the results of my first project without derailing my thinking on the second project of the day.

It doesn’t seem like such a profound way to work, but I definitely perform better, even if slower, when I let sleep and checklist becomes a key component of my work. I think we should call this “Checklist Driven Development”.