From Timeline and Risk: How to Piss Off Your Software Developers
I believe that software developers strive to do the best work they can. Most programmers will fight tooth and nail, work evenings and weekends, and scale Mt. Everest on their hands to make sure they don't let their team down. I am, of course, speaking of teams that don't have morale problems. While I acknowledge that they exist, they're not the focus of this article.
(This isn't the point of the main article, but it illustrates the point I'm bringing up. The article itself was interesting and applies in other industries as well.)
Joel's take on a programmer's life is a little different, but I think related.
What drives me crazy is that ever since my first job I've realized that as a developer, I usually average about two or three hours a day of productive coding. When I had a summer internship at Microsoft, a fellow intern told me he was actually only going into work from 12 to 5 every day. Five hours, minus lunch, and his team loved him because he still managed to get a lot more done than average. I've found the same thing to be true. I feel a little bit guilty when I see how hard everybody else seems to be working, and I get about two or three quality hours in a day, and still I've always been one of the most productive members of the team. That's probably why when Peopleware and XP insist on eliminating overtime and working strictly 40 hour weeks, they do so secure in the knowledge that this won't reduce a team's output.
But it's not the days when I "only" get two hours of work done that worry me. It's the days when I can't do anything.
After some thought, I may have figured out my problem with productivity. I'm a solo programmer; I don't have a team to give me hell when I slack off. Or it could just be that I'm a little bipolar and it varies with my mood. It's probably both.
I'm now on my 4th CMS program for this website (MoveableType, PostNuke, PHP-Nuke and now GeekLog). They've all had advanced text editors in them. I've also used others for different sites, like LiveJournal. What do they all have in common? I find them counterintuitive.
Maybe I'm just weird, but they never seem to be able to make things look right for me. It's always been much quicker (and accurate) for me to input the HTML manually as I write the article. The automatically generated HTML never looks as clean to me. I always end up going back and editing the source HTML anyway.
For example, I was using the builtin FCKEditor for GeekLog to enter the last post. I kept switchng back to raw HTML mode because it looked funny as I typed. That and reaching over for the mouse kept slowing me down.
Then again, I could just be too picky about it.
From: WorkHappy.net :: Bloglines (and aggregators in general)
Why is it the killerest?
Do you find yourself coming to WorkHappy.net and your other favorite blogs only to be disappointed that there isn't a new update and you've wasted your time loading the page? Well I don't want to discourage you from visiting here, in fact I'm honored that you care enough to check back frequently, but there's an easier way to follow this, and all your favorite blogs, and it's a way that helps you use your time more wisely (something all us entrepreneurs need to do).
That way is through an aggregator, and I recommend Bloglines.
So I decided to try it. I have to say that it's a lot better then the aggregators I've tried previously. I may actually use this on a regular basis. I've also added a "Subscribe with Bloglines" link at the bottom of the page.
Coding Horror offerend an interesting look at .NET languages by comparing the differences between C# and VB.NET to the difference between Coke & Pepsi. My first reaction was to think I hate Pepsi. I really do. I have the same reaction to VB. The syntax of the language just bugs the hell out of me.
I guess VB.NET really is like Pepsi. I hate them both.
I'm trying to evaluate some blogging software, but there's a problem. One of the packages I'm looking at, Roller Weblogger, requires Tomcat because it is written in Java.
The problem: Java takes forever to compile, and I'm not feeling that patient today.
This relates to my last post, but I wanted to make this as a seperate point. This helps to explain why there are certain people who I have to make a serious effort not to ignore when they are writing. In particular, the last point he makes.
From: Writing Tips for Non-Writers Who Don't Want to Work at Writing
1. Punctuate, damn you: For God's sake, is it really so hard to know where to put a comma?
When people read, even in their brains, there's usually some part of them that is sounding out the words. Without appropriate punctuation, especially commas, that word-speaking part will eventually choke on the sentence. Having said that, there's a tendency to over-punctuate as well, particularly with exclamation points. Too little punctuation makes it seem you want to collapse someone's lung, too much makes it look like you're a 14-year-old girl writing an IM. You want to avoid both.
Here's a quick and dirty guide when to use punctuation:
- Periods: When you're writing down a thought and you're at the end of that thought, put a period.
- Commas: When you're writing down a thought and you want to take a breath, whether mental or physical, put in a comma.
- Semi-colon: Put these in your writing in the place where, in conversation, you'd arch your eyebrow or make some other sort of physical gesture signalling that you want to emphasize a point.
- Colon: Use when you want to make an example of something: For example, just like this.
- Question Mark: Quite obviously, when you have a question.
- Exclamation point: When you're really excited about something. You almost never need to use more than one in a paragraph. Use more than one in a sentence and you damn well better be using it for humorous and/or ironic effect.
- Dashes: You can use these when you've already used a colon or a semi-colon in a sentence, but be aware that if you have more than one colon or semi-colon in a sentence, you're probably doing something wrong.
Somewhat related: Use capitals when you should (beginning of sentences, proper nouns), don't use them when you shouldn't (pretty much every other time). Lots of people think not using capitals makes them look arty and cool, but generally it just makes the rest of us wonder if you've not yet figured out the magical invention known as the shift key. Alternately, the random appearance of capitals in inappropriate places makes us wonder if you don't secretly wish the Germans won World War II (and even the Germans are cracking down on wanton capitalization these days, so there you are).
From: Writing Tips for Non-Writers Who Don't Want to Work at Writing
5. Grammar matters, but not as much as anal grammar Nazis think it does:
The problem with grammar is that here in the US at least, schools do such a horrible job of teaching the subject that most people are entirely out to sea regarding correct usage. It's the calculus of liberal arts subjects. But grammar need not be stupendously complicated; in the final reduction the point of grammar is to make the language as clear to as many people as possible. Frankly, I think if most non-writers can manage to get agreement between their verb and their subject, I'm willing to spot them the whole "who/whom" conundrum.
Now, obviously, you should know as much grammar as you can; the more grammar you know, the better you can write. But the bottom line is just this: Be as clear as possible. If you're not confident about the grammar of a sentence, re-write it and strive for clarity. Yes, it's possible that in doing so the resulting sentence will lack style or something. But it's better to be plain and understood than to have people admire your style and have not the slightest idea what you're trying to say.
The rest of the article is great too. Entertaining and educationial. There's also some other good links in this entry from Coding Horror, one of my new favorite blogs.
I'm working on a project for work. I've got a bunch of sales data that's stored on our AS/400 in flat files. Why flat files? Because the bulk of the code was originally written in 1986, but that's beside the point at the moment. I need to get that data into an SQL2005 server. Why SQL2005? Because it makes my life easier when writing .NET code, and because SQL Express is also free.
Currently, I can easily pull the data, at regular intervals, into a MySQL database using bits of Perl code I've written over the years. This works pretty well for those tasks, but interfacing with MySQL in .NET just isn't as pleasant. So I need to find a new solution.
The Problems:
- Interfacing with SQL2005 (or 2000) is hard to do from Unix.
- Running Perl code by itself isn't as practical on a Windows box, because it lacks cron.
The best solution I've come up with uses 2-3 steps, and that's not acceptable. I've downloaded ActiveState's Perl Dev Kit to give it a try. It has a .NET component builder so I may just be able to use my perl code from within the .NET app to access the data. That may just be easier in the long run.



