Matt O’ Rama

How Physicists Build a Bridge

How Physicists Build a Bridge « Joe Doliner

This is a short story and well worth reading.

It reminds me of a story I heard about Neils Bohr:

“Describe how to determine the height of a skyscraper with a barometer.”

One student replied:

“You tie a long piece of string to the neck of the barometer, then lower the barometer from the roof of the skyscraper to the ground. The length of the string plus the length of the barometer will equal the height of the building.”

via the almighty snopes

I love this kind of thing.

Debugging By The Numbers

The other day my team had an all-day meeting to try to debug a very weird, ugly problem with some accounts in the new billing system we’re finishing up implementing. During the process of trying to figure out what the root cause of the problem was, I went through a process I’ve been through a few times and thought I’d share.

The issue was with how some money was distributed to the account. Sometimes people get money back and it has to be used in a specific way. In this case it appeared it wasn’t being spread out the way it should have, and the numbers looked very strange. In the main example case, we were using there was a number on the account’s invoice that didn’t match anything. When you’re debugging, these mysterious numbers can be very useful. While everyone else was looking at other stuff, I took a little while to try to find where that number was coming from. Code (hopefully) doesn’t just invent numbers so it had to come from somewhere and I’ve had good luck in the past figuring out big problems just by figuring out the numbers.

In this case, the important numbers on their invoice were

• A payment of $562
• A credit of $629
• A big refund of $2438
• A check issued to the account for $1348
• A credit balance of $562

First, we don’t usually do credit balances at all. It should have been $0. Then, $1348 didn’t immediately jump out as having any relation to the other numbers. Our non-technical project owner’s first inclination was to believe the program was making things up but I usually go on the assumption that this isn’t the case. :)

The first thing I figured out was that the $2438 had been split into 2 chunks of $1219 on 2 invoices. Since I didn’t know that this shouldn’t have happened (score another one for ignorance), I accepted it and figure out that $629 was $1219 – $562. So this was half the refund minus their payment, which is what should happen. Good.

I then saw that $1348 did have a relation to the other numbers, it was $629 * 2. I started going over this out loud for everybody (also an extremely valuable debugging technique) and it all fell into place. What I finally saw was that the $2438 had been split up over 2 invoices. Then both the month’s payments had been taken out of the refund -> $2438 – ($562 * 2) = $1348. The system had accounted for all the money the account would owe us, taken it out and refunded them the rest. It then held on the $562 for next month’s invoice in order to pay it off then. Whew. Only took about 2 hours.

So going over this math with a clear head and no expectation of what the system should have done, I found the underlying problem. Everything should have collapsed onto one invoice and done everything at once. The refund shouldn’t have been split up and both $562 payments should have been made at once, one of them shouldn’t have been held onto til next month. This is a big issue that makes people’s invoices look weird but the important thing for a billing system is that no money is missing. People had originally thought maybe we were over-paying accounts but that isn’t the case thankfully. Now we need to figure out how to fix it going forward but that’s a job for the billing people.

In the end, once again ignorance saves the day. I didn’t know about some of the particular workings of refunds in this case so I wasn’t making assumptions about that. I know I don’t know all the bits and pieces of how the invoices work so I went through the exercise of finding where the mysterious numbers came from and that led me to the answer. If you’re debugging numbers, writing it down and going through them all with a calculator is immensely helpful. Add them up, subtract them from each other, try to find where the differences are. And talk it out. Maybe you’re going down the wrong path or your lack of knowledge about something is something basic you do need to know. It’s debugging, it’s hard. There’s no map. But don’t let those mysterious numbers float out there, they might be the key to the answer.

Scope

Scope at reboot11, Matt Webb, S&W

This is a brilliant presentation about design and how it can affect us. Extremely worth reading.

The Psychology of Incompetence

YouTube – The Psychology of Incompetence – Ron Burk.

Very cool Ignite talk (5 minutes long) about incompetence in programmers and authority. I guess I’m okay because I have no illusions about my competence. :)

(via Ben Northrop)

TheBowlingGame Kata

Here is a kata for the Bowling Game problem. I have broken it down into the same tiny little steps that I do when I demonstrate it. However, as is usual for a kata, I have left out most of the explanatory comments.

A kata is meant to be memorized. Students of a kata study it as a form, not as a conclusion. It is not the conclusion of the kata that matters, it’s the steps that lead to the conclusion. If you want to lean to think the way I think, to design the way I design, then you must learn to react to minutia the way I react. Following this form will help you to do that. As you learn the form, and repeat it, and repeat it, you will condition your mind and body to respond the way I respond to the minute factors that lead to design decisions.

via TheBowlingGameKata by Uncle Bob

I’m going to go through this Bowling Game “kata” as soon as I can. There’s some very interesting stuff even just in the first few slides of the presentation.

I’ve seen a lot of these kata exercises and have always wanted to go through more of them in a more organized way; as in make a schedule to do a couple a week. This one though, is the first I’ve seen with enough detail that right away I can tell it’ll help a lot. More on my results / experience with this kata soon.

Just Enough MBA to Be a Programmer

I’ve always been curious about what MBAs really do. In my weaker moments, I’ve even thought that the only reason people got an MBA was to demand a higher salary or to “move up the corporate ladder” into some management job. What did these MBA ninjas actually learn in school? Would having an MBA help me better understand how I affected my company’s bottom line? Although I had the curiosity, I never acted on it. This changed when another programmer recommended that I read The Ten-Day MBA by Steven Silbiger.

via Moserware: Just Enough MBA to Be a Programmer.

This book looks like something both my wife and I would both like. I’m like Jeff Moser here, I’m curious about what people actually learn doing this stuff but not enough to read a bunch of boring books full of business-speak. $12 for an overview sounds good to me. It never hurts to be more well-rounded as a team member in any case. Even if I just get an overview of the financial pieces and the jargon people use, it’ll be worth it.

My wife is also in the process of setting up a business with a couple of partners to market some software she wrote. Even though she’s the programmer and her partners are the sales/business end of things, it’s never good to cede control over something that important to somebody else with no understanding of what they’ll be doing.

Jeff does a great job of going over the various sections of the book and what you’ll learn in each and I applaud him for the effort. If you’re cheap, you can probably get by with just Jeff’s post, to be honest. But an overview of an overview is one level of remove too much for me. I read fast anyway so it’ll be time well spent I think. Plus, when somebody asks me something about business I can say I read a book about MBAs, not that I read a blog post about a book about MBAs. :)

Project Coin Updates

Project Coin Announces Second Candidate List on InfoQ

At the JavaPosse Roundup a few months ago I got the chance to hear more about Project Coin, Sun’s “small change” additions to Java. I also got the chance to annoy the project’s leader, Joe Darcy, about the fact that BigDecimal math operators were off the table for Java 7. That still hurts but the latest updates to potential changes to be included in Java 7 takes quite a bit of the sting out. This is some cool stuff.

3. Indexing access syntax for Lists and Maps. Shams Mahmood Imam’s proposal aims to provide a consistent syntax for access elements of Arrays, Lists and Maps, so you could write:
myList[0] instead of myList.get(0) and
myMap["key"] instead of myMap.get("key")

I love this change. Much more readable and in line with how other languages do things. I’m always afraid when I say I like things because they’re more Perl-like that it will scare people away or they’ll change it just because of that but this does match my Perl biases from my former life so I like it. :)

4. Collection Literals. Intended to coexist with indexing access syntax for lists and maps and similar to a second proposal from Imam, Josh Bloch adds support for immutable list, set and map literals with a syntax similar to that of array initialisers. An example from the spec:
final Map platonicSolids = { 4 : "tetrahedron",
6 : "cube", 8 : "octahedron", 12 : "dodecahedron", 20 : "icosahedron"};

Same with this change, I like it a lot. Much less code for the same thing and it’s just as readable. Again, more like Perl without losing readability == good stuff.

Large arrays is a good change to give people flexibility, same with byte and short suffixes and using _ as a comma substitute in long numbers. Perfect “small change” inclusions.

It of course still depends on how much of this stuff gets in but just based on these lists of proposals, it seems like Project Coin will be a success. Everybody running the project and making proposals should be proud of themselves and be congratulated. Java 7 will be quite a bit nicer language because of their efforts.

Good old ignorance

I’m a big fan of ignorance. One of my favorite quotes goes something like “The one saying something is impossible shouldn’t interrupt the one doing it.” There have been a lot of times in my life where I was glad I didn’t know anything about the project I was doing beforehand because I wouldn’t have done it if I had. This is a very valuable way of looking at things, even though it can be hard to figure out when you actually do need to know something ahead of time so you don’t waste time or reinvent too many wheels. Every time I start a project I think about this balance but I haven’t figured out how to figure it out, if you get my meaning. In this post I want to talk about another benefit of ignorance, being willing to admit your own and how that can be a big help.

The other day at work we had our first design / planning meeting on a new piece of infrastructure. We’ve got enough different pieces needing to communicate that we’ve wanted to put a middle-layer in place for awhile now. Since we’re going to be starting our next big project soon, we all wanted to get this piece done before starting. In the meeting, my old friend ignorance played a big part. Specifically my personal ignorance.

The other 2 main Java programmers on the team and I were meeting with a programmer from our big vendor who also knows waaay more than I do about this middle-layer piece. It might have been annoying to my teammates but since I knew very little about how we were going to build this solution I kept questioning everything and having to have it explained to me. The reason I think this is a useful thing to do is twofold. One, we need to be able to explain this and justify it to everybody so having all of us understand is very valuable. I’m a pretty smart person overall so if I can’t catch onto something or see why we we would do something it’s a good bet others won’t either. The other reason is more important: explaining something to somebody who doesn’t get it forces you to think it through. If you take the first thing that comes to mind and just do it, you might end up with something more complicated than you really need or you most likely will have to redo parts of it later when you hit walls or are otherwise forced to think it through then. I don’t mind being the dumbest one in the room at all because of this. My personal preference goes along with the Agile/XP teaching of “Do the simplest thing that can possibly work” so I bring that along as well. After our meeting we came up with a really good design that builds on things we already have (reducing the amount of work needed), is easy to understand and justify, and will add real value to our system. It’s a testament to how well our team works together that we all contributed bits of work and knowledge and didn’t just rubber-stamp some design we all weren’t happy with.

Not being afraid to question things is a very helpful trait, even though some people might not like it. If you have questions about a design your capital-A “Architect” is proposing, do yourself and your team a favor and ask the question. Make people explain it. You have to be comfortable with the design of the things you build so if somebody else designs it, they need to make you comfortable. At the very least, that’s a courtesy to the team. At best, the design will get better as the designer has to think through answers to questions they might not have considered.

Thanks to the Dilbert Strip finder for helping me find this old favorite.

No is for wimps

No is for wimps. No is for pussies. No is to live small and embittered, cherishing the opportunities you missed because they might have sent the wrong message.

There is a point in one’s life when one cares about selling out and not selling out. One worries whether or not wearing a certain shirt means that they are behind the curve or ahead of it, or that having certain music in one’s collection means that they are impressive, or unimpressive.

Email interview with Dave Eggers

I have no memory of how I found this interview, really just an email to the author Dave Eggers and his replies from 2000, but it stuck in my mind and has probably ended up being one of the most personally important things I’ve ever read online. It’s religious to me in the way that Frank Llyod Wright’s buildings are religious to me; they inspire me and awe me and make me want to be better to live up to their standard.

I was recently in San Francisco and finally made it to 826 Valencia, a free tutoring center fronted by a pirate supply store, and I knew it wouldn’t happen but I was really hoping Mr. Eggers might be there so I can thank him for this interview. I’ve read his work and bought every issue of The Believer for a few years, but this is what I would thank him for. The message of saying Yes to things, to not give a shit what people think or how this or that might affect your rep really resonated with me.

What matters is that you do good work. What matters is that you produce things that are true and will stand. What matters is that the Flaming Lips’s new album is ravishing and I’ve listened to it a thousand times already, sometimes for days on end, and it enriches me and makes me want to save people. What matters is that it will stand forever, long after any narrow-hearted curmudgeons have forgotten their appearance on goddamn 90210. What matters is not the perception, nor the fashion, not who’s up and who’s down, but what someone has done and if they meant it.

It’s long and some of the specific references are a little dated but the overall message, the way Eggers smacks down this pseudo-intellectual hipster prick whose asking him “what steps are you taking to keep shit real” with an honest and open soliloquy on saying yes to new things and no to fashion and what others will think, is something I re-read regularly and would memorize if I could. I really encourage you to read it as well, there’s something for everyone to take from it.

I try to live up to this, even though it’s hard for me. I’m incredibly shy and have a problem with new things sometimes but I try to remember “No is for pussies” and press on. When I feel like I’ve let myself down by giving in to my introverted nature I read the end of this interview and am renewed.