Anthony Panozzo's Blog

I like writing, and I often write at night. However, writing at night on a computer monitor increases exposure to bright light and blue light, which delay sleep onset and suppresses melatonin production, respectively. Even tablets have this drawback, which is why I try to avoid reading on them at night.

Alternatives

I looked for an alternative to writing on a standard computer monitor. I considered finding a Kindle-like screen that has e-ink technology. This seemed technically feasible, but difficult to set up and maintain as well as being expensive.

I briefly considered writing by hand, but this has the disadvantages of being slow and difficult to get into electronic form.

I also took a look at some electronic typewriters (yes, really!) I could type on a familiar keyboard layout and then scan the resulting copies and use OCR on them to get the text extracted to a digital format. This seemed cumbersome and error-prone, and lacked many of the simple editing tools that a modern word-processor would use.

What I really wanted was a few line LCD display. I remembered my parents had a small address book that ran off of a few batteries, and figured maybe I would have to make something like that. In a last ditch effort, I posted to Twitter:

I happened upon an open source tool for refactoring JavaScript that has been useful. The tool is named Grasp, and it enables searching and replacing on the AST (abstract syntax tree) of your JavaScript code. This is powerful because instead of finding or replacing bits of text throughout your codebase, you can replace only identifiers, for instance. Or you could find matching blocks of code that are spread across lines, since we look at the entire syntax tree, not the text representation of it.

There is a fantastic blog post on the Grasp website. It provides several examples of common refactorings (rename variable, changing a function to accept an arguments hash instead of adding another parameter, etc.) It really does a great job of showing why standard tools like sed and grep fall short during refactoring. The examples are clear and provide good starting points for your own refactorings.

I was on the swim team in high school, and we would do weightlifting a few days a week in the morning. In the weight room there was a sign that read: "The beatings will continue until morale improves." At the time I thought "this is a typical meathead thing to say. Shouldn't stopping the beatings improve morale? I mean how is this supposed to pump me up?"

There are several really good software engineering people that I know who have moved into more of a management or product ownership role. The thing that causes me to lump them in one bucket is their ability to get things done in their more advanced roles while clearly stating a desire to get their hands dirty in the low level details. I think a common thread is "man, I'd love to jump in the code with you guys, but I have this meeting."

I think that changing roles naturally results in this feeling. When you have different or higher priorities, you must deprioritize other things.

I think these managers yearn for the simplicity of having just a technical problem to solve, now they are thrust into solving the hardest problems of the organization and doing this by coordinating resources they have never previously needed to worry much about. For managers who have been "out of the game" for longer, there may be a bit of nostalgia for the thrill of coding and having a clearly defined problem to work on. There are the war stories that drive experience but then they realize it has been ten years since they had that experience.

When our development team pushes up new code to be reviewed, I like to review it quickly. Why?

Personal reasons

Generally reviewing code has little cost of delay for me, especially if I am already interrupted or have not started new work. Reviewing code is a good mental shift after I push up my own features.

I like being able to give feedback on code. I think that it improves the quality and consistency of our project.

I also like seeing what everyone is working on. It gives me better context for when I am working on new features or fixing bugs. I get a really good sense of what everyone likes to do and how they like to do it. Sometimes I realize that a teammate is working in a similar (or the same!) area, and I need to communicate more to not squash what they are working on.