Remember how I said you should never sign non-compete agreements?
Mystery: why is it that some of the biggest IT consulting companies in the world do the worst work?
Why is it that the cool upstart consulting companies start out with a string of spectacular successes, meteoric growth, and rapidly degenerate into mediocrity?
Big Macs vs. The Naked Chef tries to explain it.
ADP has the worst web programmers in the world.
Jared was trying to check his 401K info at this site.
Enter social security number, press tab, enter PIN, press tab, and press Space to press the "Login" button.
Because the morons who wrote that page are using the "tabindex" attribute without understanding it, this actually activates a button way down at the bottom of the page which locks you out of your account and mails a new PIN to you via snail mail.
That's why Fog Creek stopped using ADP for our Payroll - now we use Intuit QuickBooks and it's a million times better.
And while I'm complaining...
Thinking of wireless networking? Stay away from SMC Networks. Their products are terrible. We tried a bunch of their 802.11 wireless networking PC cards and discovered that they barely worked at 10 feet; one wall was enough to stop them cold. Serves me right for buying the cheapest brand.
We switched to the Lucent/Orinoco stuff, which works much, much better.
How exciting, my book is already on Amazon!
It's not shipping until March, though. And the cover image they have on Amazon is just a mockup, it's not the real thing.
The Onion says it better than I did...
When you're using source control, sometimes one programmer accidentally checks in something that breaks the build. For example, they've added a new source file, and everything compiles fine on their machine, but they forgot to add the source file to the code repository. So they lock their machine and go home, oblivious and happy. But nobody else can work, so they have to go home too, unhappy.
Breaking the build is so bad (and so common) that it helps to make daily builds, to insure that no breakage goes unnoticed. On large teams, one good way to insure that breakages are fixed right away is to do the daily build every afternoon at, say, lunchtime. Everyone does as many checkins as possible before lunch. When they come back, the build is done. If it worked, great! Everybody checks out the latest version of the source and goes on working. If the build failed, you fix it, but everybody can keep on working with the pre-build, unbroken version of the source.
On the Excel team we had a rule that whoever broke the build, as their "punishment", was responsible for babysitting the builds until someone else broke it. This was a good incentive not to break the build, and a good way to rotate everyone through the build process so that everyone learned how it worked.
Read more about daily builds in my new article Daily Builds are Your Friend.
I'm going on vacation for a week. Now behave and don't give the babysitter a hard time or I'll dock your allowance.
1111 posts over 13 years. Everything I’ve ever published is right here.
There’s a software company in New York City dedicated to doing things the right way and proving that it can be done profitably and successfully.