Today I Learned: Wood Finishing

Posted on by Eric F. Savage

I took a beginner wood finishing class at Woodcraft last night, and was very happy with it. It was taught by Gary Wood, and I’d highly recommend it to anyone that is intimidated by the craft of finishing, as I was. Some highlights:

  1. Put simply, dye is a color liquid, while stain is a suspension of pigment particles. This means that dye will get into your wood, while stain will sit on top. This means dye will preserve the beauty/grain of the wood better, while stain is easier to work with.
  2. You can add color at any step of the process (stain/dye, seal, fill/glaze, finish, polish) so you can get the color just right. Doing colors at different steps will also increase the “depth” of the finish.
  3. Don’t oversand when you’re applying a finish – I learned this the hard way on my own, sanding some maple down to 320 and subsequently seeing the wood fail to pick up any finish. Most of the time you don’t need to go past 180, and never go past 220.

The 3 Ingredients Necessary to Make a Really Good Developer

Posted on by Eric F. Savage

I’ve been doing development long enough that I can now look back and have some perspective on the art/craft/profession. I’ve been asked many times “how do you become a developer?” and I now have a decent partial answer. They are not being “super smart” or “good with computers” or things like that. I think those are artifacts of these other attributes. I’d also guess that these apply to engineering in general, but I’ll limit myself to my own turf.

Curiosity

Good developers have a compulsion to understand how things work. they open files with text editors to see if its just xml or a zip file with a different extension. They run benchmarks against things that don’t seem to matter. They add query parameters like debug=true to websites. They try to break stuff. And not just software, they probably know how an internal combustion engine or an air conditioner works. They probably can tell you a bit about how the minimum wage affects inflation. My grandmother used to give me old radios and gadgets strictly so I could disassemble them.

This attribute is probably the one that separates the wheat from the chaff the most. There are lots of people who can code, or manage a system, but the ones that excel will need to understand how things work, and know that every juicy answer yields even more delicious questions.

Focus

The ability/requirement to focus is the subject of many other blog posts, but I view focus in a slightly different way. Focus is not eliminating distractions or even maintaining “flow”, focus is the ability to keep a problem in your head until you’ve solved it. Distractions can hamper this, so can multitasking or other external factors, but good developers can work on something, go to lunch, or go home for the evening, and pick up right where they left off.

Hard Work/Genuine Interest

I think there is a certain amount of innate aptitude, but I don’t think development is an exception to the 10,000 hour rule Malcolm Gladwell popularized. Luckily, its a trade where we can log those thousands of hours at an early age and make it look like we’re goofing off. I started with LOGO in the second or third grade, moving onto translating my piano music into BASIC, learning that a coda is just like a GOTO. On to writing databases to track fantasy baseball status with MS Works, and so on. Sure, we spent many college nights taking over IRC channels with bots, and crashing MUDs with scripts and floods, and that may have looked like simple nerd mayhem, but those experiences have tremendous value in the “real world”.

You can know all the buzzwords and put on a good show, but you can’t really fake the level of interest that side projects demonstrate. There are plenty of good-enough developers out there who punch in and out, and there are even jobs where you do cool enough stuff that you don’t feel compelled to break out of the rut (we try to be this way), but if you still need to hack on your own, you’ve got potential.

Fortune smiles on those who smile back

Posted on by Eric F. Savage

I’ve always considered myself a pretty lucky person, whether it’s spotting opportunities, avoiding bad ones, getting good jobs, etc. This article claims that you actually do make your own luck, and the way that happens jives with how I go about things. Some snippets:

  • Lucky people tend to respect hunches
  • Lucky people try to introduce variety into their lives
  • Lucky people tend to see the positive side of their ill fortune

So, if you’re feeling unlucky, take a deep breath and try something new.

Buying a car

Posted on by Eric F. Savage

I won’t say I’m some kind of genius buyer or that I have a bulletproof system, but I think I’ve done pretty well when I’ve gone shopping for a car, and this article backs up some of my ideas. I don’t think any tricks or deceptions are really going to help you, your opponent in this game is likely to be much more experienced than you. My rules:

  1. Make it clear to the dealer that under no circumstances, no matter what, will you be making any decision today, and that you need real numbers, in writing. This is not a trick, you really do need to walk away and sleep on it. The pressure will mount when he realizes you’re serious, and it’s hard to resist, but it’s well worth it. You’ll have real numbers to review, show someone else, fit in your budget. If you get the “I can’t hold this car for you for any longer” line, ignore it. Either he’s bluffing or he’s going to sell the car to someone else. Either way it’s no big loss for you, there are always other ones out there.
  2. Say as little as possible (not difficult for me). The article mentions not talking about credit or how you’re going to pay for your car, which seems obvious to me. Don’t talk about trade-in (if pressed, be indecisive, “my sister might buy it off me”) or how long you’ve waited for this model to come out, or anything like that, until you get the numbers from #1. Do your research, but don’t go in with a bunch of stuff you found online about invoice cost and think you’re going to get the guy to sell the car and not make a profit, you’re not.

Other tips: If you’re leasing, buy early in the model year. If you’re buying, buy later. And try to take something off the lot, you lose alot of wiggle room when you need to order it.

Contrary Opinion: Code coverage by checked exceptions

Posted on by Eric F. Savage
This is the first in what will hopefully be a series of statements that I may not entirely believe, but to put out there to see if they are viable…

Conventional Wisdom: Unit tests are great, you should have lots of them. More code coverage is better.

Conventional Sentiment: Checked exceptions are a hassle, more trouble than thier worse, promote sloppy coding, etc.

Contrary Opinion: Checked exceptions are a better way to address code coverage than unit tests.

On a scale of 1-10 of using and advocating for checked exceptions, I’m probably an 11. I completely disagree with pretty much all of the conventional complaints against them. They do not promote spaghetti code, they actually clean up your normal logic and neatly compartmentalize your error handling. They do not promote sloppy behaviors like exception swallowing, that’s entirely the programmer’s fault. Adding or removing exceptions breaks client code. Yes, it does, why is this a problem? You added additional error conditions, meaning you changed your contract with the clients, and they should be revisited. If you didn’t have this obvious way to signal a change, chances are that the client would handle things incorrectly. Even some of the major voices in computer science have fallen out of love with them, but usually the reasoning is based on people using them wrong (or being too hard to use right).

On a scale of 1-10 of using and advocating for unit tests, I’m probably a 2. They absolutely have their uses. A straight-up algorithm, especially things like math and parsing, should be unit tested for various input values to assure they’re returning the proper value. However in most modern business/consumer software these represent a very small portion of your code. There are far more lines of code dealing with things like authentication, user inputs, file loading, database and network operations, etc. These are complex activities. Even simple CRUD applications can end up invoking hundreds of functions across dozens of libraries for every operation.

The crux of my argument is that if you use exceptions properly, you don’t need to test if an operation completed properly. If the operation completes, it did so properly, all other conditions would fail to complete. Since you want to be using exceptions properly anyways for cleaner code, unit testing this code is redundant but a waste of time and energy to write and maintain. Not only that but exceptions give you code coverage at compile time AND error handling at run time, which unit tests cannot do.

If you disagree, please tell me why!

Blog posts come to life: Marginal Revolution edition

Posted on by Eric F. Savage

As I entered the 7-11 in Central Square the other day, there was, as usual, a man seated outside the door. The unusual aspect was that another man was challenging his right to use the spot, threatening violence. As I exited the store, the two were discussing how much the new man would pay the old man for the spot. The asking price was at $0.50.