… or, Prefer this scope to closure scope, Prefer stub scope to this scope
If you’ve heard of the Module Pattern, you might think that this is a well-settled question. But the Module Pattern gives you lots of leeway in implementation. In this post I’ll take away most of that wriggle room.
My morning began pleasantly with an easy drive from Columbia to Silver Spring. Kudos to the House Republicans who shut down the federal government just so I could have a faster commute to NationJS! I can’t say how much I appreciate having congressman who know how much I hate sitting in traffic and are willing to go to such great lengths to convenience me. As I write this now, it’s been nearly two weeks of the shutdown. I guess I forgot to tell my Tea Party friends that NationJS was only one day.
This very first NationJS was being held at the Silver Spring Civic Center, right next to the Silver Spring Metro Station. I parked right across the street for $1 an hour. Probably not the cheapest spot, but it won’t break the bank.
Breakfast was provided — muffins, bagels, coffee, juice. Quite a few people were there early, which surprised me. There were also plenty of extension cords, but I’m glad I brought my Haskell laptop, so I didn’t have to constantly worry about trying to find an outlet.
The following are my impressions of the four morning sessions I attended. They are in no way meant to be anything near a complete transcript.
I’m on a contract that may start winding down in a couple of months1, and so I’m starting to both look backwards and forwards to think about what I’ve learned and what I can do better. One of the ways that I think I can do better is to change my attitude toward taking on legacy projects.
In the past, I’ve always been fairly picky about my assignments — I choose assignments which will stretch me as a developer. I also use the interview as an opportunity for me to scope out the employer to see if there are any organizational or development process dysfunctionality that will keep me from doing my job effectively. As a result, I usually shy away from legacy projects.
But I’ve grown more confident in my ability to effect change in an organization, and so here are my list of things to do for getting off to a quick start on a legacy project.
Work the Way You Want to from Day One
… even if you haven’t convinced everyone that your way is the right way way
Coming onto a new project, you can’t always work the way you want to. There are legacy anti-patterns you just have to follow if you want to keep your job, and it doesn’t do you any good to be the new guy who’s always complaining. But the good news is you can just add your best practices on top of the bad ones you have to follow…. Continue reading →
I especially like how they go against many of the old saws I’ve seen in management books, and then give reasons (but not evidence) to back up their principles. The argument against loyalty, both from company to employee and vice versa, is food for thought.
The most interesting point in the slides to me is their analysis of why companies become more bureaucratic as they grow. Their hypothesis is that small startups have high talent levels, that top talent is self-motivating and requires less supervision overhead, and that the typical company growth pattern results in talent dilution. The end result is that more supervisory bureaucracy is needed to manage the diluted talent. Netflix’s answer is to strive hard to maintain the talent density, which enables a much flatter organizational hierarchy and thus less bureaucratic process. It’s a nice argument, though I’d really like to see if there is any research backing this up.
If I ever decide to become a manager or join a startup, I’ll definitely keep these principles in mind. Unlikely, however, as I enjoy coding too much to give that up.
I participated in a code review yesterday, and while there were many things I wanted to say, I only think of the right thing to say an hour after it’s all over. What I wanted to say was
The most important thing you can do to improve the quality of your code is to choose good names.
At least, that’s the way I feel right now. I reserve the right to change my mind tomorrow.
It’s really important to remember that naming is not just an action you apply to passive code. The goal of good naming should drive your design and your coding in much the way that Test-Driven Development’s goal of writing tests first is supposed to drive your code design.1 In fact, this practice of active naming so important, I think that it deserves a name — Name-Driven Development. Anyway, here are some advice on naming methods.