Anthony Panozzo's Blog

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.

Sometimes I come onto a project and there is no continuous integration or tests. I like working with tests and using a continuous integration setup, especially when working with others. I also think that a project’s quality will increase and the speed also increases when we get automated feedback from continuous integration.

Typically a good first step for me is to get some basic tools running. Before I even write any tests, I get some basic sanity checks in place. If I am running in a Ruby environment, for example, I may run some static analyzers and fail the build if they fail. I might also check that every Ruby file that we have at least passes ruby -c (which checks for syntax errors. In JavaScript-land, this might take the form of jshint or another linter. In compiled languages, just ensuring that you can compile your code might be enough.

I was trying to use two Express param functions in one route, and one of the param functions needed the other param to be loaded. For example, if I have the route file:

    // route file
    app.route('/api/v1/toolboxes/:toolboxId/tools/:toolId')
    ...
    app.param('toolboxId', controller.loadToolbox);
    ...
    app.param('toolId', controller.loadToolAndEnsureFromToolbox);

And an associated controller:

    exports.loadToolbox = function(req, res, next, id) {
        // load toolbox from Mongoose into req.toolbox
        req.toolbox.maker = req.toolbox.maker || 'Stanley';
    };

    // controller
    exports.loadToolAndEnsureFromToolbox = function(req, res, next, id) {
        Tool.findAsync({
            _id: id,
        }).then(function(tool) {
            if (!tool) {
                res.status(404).send("Tool not found");
            } else if (tool.maker !== req.toolbox.maker) {    // <<<<<
                res.status(403).send("This tool isn't from the right maker!");
            } else {
                req.tool = tool;
                ...
                next();
            }
       });
       ...
    };

I wasn’t positive that toolbox would always be loaded when I wanted to check it in tool. (This is kind of a strange example, but it resembles a problem that I was trying to solve.)