LinLog

There were a few interesting threads on the Joel on Software discussion forum last week. They proved to be interesting reading on just how wrong a developer can go, with or without realizing it.

The short version is that poster Brice Richard took issue with the recommendations of other posters that applications should be written as, in his words, "all mini-functions." He then went on to describe his coding methods and argue that his way was right; if not for everyone, than at least for his circumstances.

Now, the title of that second thread was actually a little misleading. I actually read that one first, and I initially thought he was referring to the arbitrary guidelines on subroutine size that you often hear thrown about without any real supporting evidence. For example, some people say that a function should never be longer than a dozen lines, or that all functions should fit on one screen in you editor. That last one always sounds nice - unless you have poor eyesight and a small monitor.

But that's not what Mr. Richard was talking about. He only believes in writing separate functions when:

1) there is a bona-fide reason to believe that the code will be re-usable in other apps
2) when you have duplicative functionality within your application that results in the need to create a function that defines that functionality through either value or referential arguments allowing your code to execute variably when used.

And apparently he doesn't view 300+ line functions as a cause of concern. And all this from someone who has been in the consulting business for 8 years.

Part of the reason for this is probably that Mr. Richard is, in his words, a self-taught programmer who always works alone. Of course, there's nothing wrong with being self-taught. In this business, we're all self-taught to various extents. To quote Dr. Kelso from an episode of Scrubs, "If you've been out of college for more than five years, half of what you know is obsolete." There are always new technologies to learn and most schools don't even come close to covering all of what you need to be a professional developer.

However, as Jeff Atwood pointed out today, working alone can be dangerous. And it's not just the project management issues described in the essay he cites. When you don't have other people to learn from, you end up having to work harder to educate yourself. You need to read more, experiment by yourself, and try to validate your results based on just your research rather than peer input. You have no one to practice with or bounce ideas off.

It's important to remember that this is 2007. Software development is still a young field, but it's no longer in its infancy. Translation: you don't need to go about rediscovering how to do things. When people talk about "doing things your own way" and the like, that's usually what they mean. It's much better to study the recommendations of the experts and use or adapt them as appropriate.

When you're working alone and aren't vigilant in your studies, it's easy to fall into bad habits. It's also easy to get stuck in your ways and not learn new techniques or technologies. The forum threads I mentioned above are a good example of this. Working alone isn't necessarily detrimental to your skills, but it's much better to have smart people around to give you an occasional reality check.

Of course, you can still end up working with other developers who have no concern for modern practices or procedures, and hence don't help much. But that's a different story....

After succesfully forgetting to weigh myself in the morning for several days, I finally managed to get a couple of readings in a row last week. For a while, I had been hovering around 187, but last Friday, I got a consistent reading of 184.6. That puts me at a total loss of 49 pounds and within 5 pounds of my goal of 180.

I've actually been loosening up on the diet lately. Partly it's because it's summer time, which means it's time for ice cream and cooking burgers on the grill. I've been careful not to over-do it, though - only 1 ice cream cone a week and mostly chicken and turkey on the grill.)

The bigger problem is that we've been very busy lately. I think we've been out of town four or five weekends in the last two months, which generally means we eat out. (Plus my cousin's wedding - he got married across town, but we still ate out for that.) Most of the other weekends we've spent most of the day working on the house or in the garden, and after that we often just don't feel like cooking. But so far, it doesn't seem to be a problem. Even when we eat out, I'm trying to choose the healthier foods and stick to sensible portions. (Translation: no, you don't have to eat that whole plate of fries!) At the very least, I'm not seeing any negative effects yet.

I think learning proper portion control has been a big help to me so far. I've learned to try to eat slowly and not force myself to finish an overly large serving. Most of us are used to the gigantic portions they give you at chain restaurants like Applebee's or Chili's, but the truth is that they normally give you enough food to feed two people. It was a big step for me just to realize how much food it takes to fill me up and stop there. Since it typically takes longer for my body to send the "full" message than it does for me to overeat, I've found that eating slowly helps to narrow the gap and keep me to a sane amount.

The second half of my latest upgrade arrived from NewEgg today. I ordered two more gigabytes of RAM - one for my desktop, one for my laptop.

As a brief aside, the laptop upgrade was much smoother than I expected. I'd never tried upgrading a laptop, so I wasn't sure how hard it would be. Turns out adding more RAM to my Inspiron B120 was actually pretty easy. I just followed the Dell service manual. The process was pretty much "open up the correct panel, then slide in RAM module."

The desktop upgrade arrived just in time, since I was about to disassemble and move the system anyway. That's because I just finished "upgrading" my computer desk.

We've consolidated office space, so Sarah and I are now sharing one large desk. Of course, I still have to finish putting the doors and drawers back in and get some keyboard trays, but it's basically done. I built it out of kitchen cabinets and laminate counter. It's a little higher than a normal desk, but it should serve us well. It will also be a lot sturdier than the pre-fab fiber-board desks its replacing.

Following in the spirit of Mark Pilgrim's post from the other day, I thought I'd a short list of things I don't care about. I do this mostly because I'm tired and grumpy, and it's hard to come up with positive, insightful commentary when you're tired and grumpy.

1) Safari on Windows. Maybe it will be good for testing. But then again, I didn't care about Safari when it was Mac-only, and I see no reason to change my attitude now.
2) The iPhone. Yeah, it looks very cool and it's probably much easier to use than any other cell phone on the market, but you can buy an actual computer for less money.
3) Font rendering. Joel Spolsky and Jeff Atwook both commented the "revelation" that Safari for Windows was using Apple's font rendering engine instead of the Windows one. I've heard many complaints about the font rendering on Linux too. Who cares? I never got the obsession some people have with how their fonts look. As long as I can read it without getting eye strain, I'm happy. Hell, half the time I can't even tell the difference between two similar fonts.
4) VB6 programmers. I came across this link from a couple of years ago lamenting that .NET was killing hobbyist programmers. It's an argument I've heard before: .NET is just too hard compared to VB6. Well too bad. Learn to freaking program. VB6 seemed good 10 years ago, but in retrospect, it was nothing but a recipe for hideously bad code and huge magenta buttons. Good ridance! And I was a VB6 programmer, so I'm allowed to say that.
5) Out-sourcing/off-shoring. I'm sick of hearing programmers wailing about their jobs being moved to India or China. You know what? If your job is really in danger from that, it probably sucked anyway. Upgrade your skillset and next time don't work as a code monkey.

This week I've been looking at Mono a bit more. I've been trying to spend more time on one technology at a time rather than jumping back and forth between a bunch of different things. So for this week, I'm putting off Ruby on Rails and doing Mono.

To me, being both a Windows and Linux programmer, Mono is a very good thing. If nothing else, it has the benefit of making mainstream Windows programming knowledge usable on Linux. And really, C# and the .NET framework are pretty good in their own right. Mono means that we have another good language and framework that brings with it a high degree of source- and binary-compatibility with Windows. It even has a GUI that isn't horrifyingly ugly like Java's Swing. What's not to like? Unless you're a rabid Microsoft hater, nothing.

So far, my complaints are mostly with the development tools. I'm using Monodevelop 0.12 from the Ubuntu Feisty repositories. While Monodevelop is a fork of SharpDevelop, it is, sadly, not quite as good. It's missing many of the nice little features #Develop has. However, my main complaint is those damn panels. You can't easily minimize groups of them and the positioning gets screwed up when you close them. And if you leave them open, you get stuck writing in a tiny code window.

It's also somewhat annoying that there is no WinForms designer for Mono. Apparently this is because appropriate designer surfaces haven't yet been implemented in the framework, but it's still annoying. After all, if you want to write a cross-platform GUI, WinForms is the choice.

My other complaint is gnunit2 version 1.2.3 that's included in Ubuntu. It has no options, doesn't reload the assembly between test runs, and includes a "preferences" menu item that doesn't do anything. Of course, there's always the NUnit plugin for Monodevelop, but the aforementioned panel annoyance means that isn't significantly better.

On the up side, a new version of Monodevelop came out today. I'll have to try it out and see if it's any better. I only hope that I don't end up having to recompile huge numbers of packages in order to get it working.