Showing posts with label programming. Show all posts
Showing posts with label programming. Show all posts

Saturday, May 3, 2008

Been there, done that (no t-shirt yet)

Dilbert is (c) Scott Adams.

Gladly this doesn't happen in my current job but I clearly remember that situation right around when the dot coms were in the free growth stage.

Friday, April 25, 2008

I have The Moose

In programming circles, it is common to keep a small stuffed animal to be kept by whatever team member has done something gloriously stupid. Some places use a Big Mouth Billy Bass, but most of my friends use a moose. Whenever one of us screws something up big time, we request possession of The Moose.

Today I took a double possession. The first incident involved a boolean function. Here is more or less a breakdown of what I did:

[20:40] <VP|bofh> function returns true/false

[20:40] <VP|bofh> function uses sproc to return true/false

[20:40] <VP|bofh> sproc uses a record count to decide true/false

[20:40] <VP|bofh> zero records = true

[20:40] <VP|bofh> > zero = false

[20:40] <VP|bofh> the ACTUAL function returned zero records = false

[20:40] <VP|bofh> > 0 records = true

This basically means that my true/false function was returning false/true instead. This ate two hours of work last night, and another hour this evening.

The second incident was subtle. I had a sequence of events:

1. Check authentication status

2. Check secondary authentication status

3. Execute a function

4. Execute another function

5. Execute another function

6. Auto-login

And it wasn't working. Since I was still reeling from the boolean error, I started adding breaking points and checking every line of code. One hour into it, I found the culprit: when I copied the function I needed to use for step #4, it had a built-in self-authentication check, which made sure only logged-in users could run the function. This meant that even after I had checked the two authentication methods, I had a rogue third check within my code that was raising all sorts of hell.

So now I have The Moose.

Photo Credit: Photo by grizzbass, used under the terms of a Creative Commons license.

Wednesday, February 20, 2008

Where is your God now?

For years the FOSS camp has taken for granted that one of the reasons that open source / free software technologies will always be superior is because of the price of admission. Microsoft and many others simply charge too much damn money for their development tools. Any of us that have been around the Microsoft camp for long know that programming for ASP.net and SQL Server costs a pretty penny, plus every server that the solution is installed to has to pay for licensing. We usually don’t care about the end server licensing since the customer pays for it, but we do care about how expensive the tools are. This is why most of us are glad to jump at the opportunity to grab a MSDN license, since it is the only way that most of our shops can afford to use these products legally.

But what happens when Microsoft turns around and says, “you know what, fuck FOSS. Let the college kids use all our tools for free, so when they graduate they will be proficient and will pursue Microsoft-centric jobs.”

How the hell do you offset this? If the programmer doesn’t have to spend a penny for the tools to learn, then what is the motivation to spend his time on the FOSS toolset when he damn well knows that on graduation the better paying jobs are going to the Microsoft-centric programmers?

Microsoft did just that. College kids can now use the following free of charge, the only condition is third party verification of the student’s school status:

  • Visual Studio 2005 Professional Edition
  • Visual Studio 2008 Professional Edition
  • XNA Game Studio 2.0
  • 12-month free membership in the XNA Creators Club
  • Expression Studio, which includes Expression Web, Expression Blend, Expression Design and Expression Media
  • SQL Server 2005 Developer Edition
  • Windows Server 2003, Standard Edition
  • Sql Server Developer Edition
  • Virtual PC 2007
  • Visual Basic 2005
  • Visual C++ 2005
  • Visual C# 2005
  • Visual J# 2005
  • Visual Web Developer 2005

Oh yes. Can you feel the burn?

Wednesday, February 6, 2008

Inter-Sections » Blog Archive » How to recognise a good programmer

Many thanks to Paul for finding this gem:

How do you recognise good programmers if you’re a business guy?

It’s not as easy as it sounds. CV experience is only of limited use here, because great programmers don’t always have the “official” experience to demonstrate that they’re great. In fact, a lot of that CV experience can be misleading. Yet there are a number of subtle cues that you can get, even from the CV, to figure out whether someone’s a great programmer.

[From Inter-Sections » Blog Archive » How to recognise a good programmer]
Recruiting is by far the most frustrating responsibility I have faced in every single job I have held in the past decade. It is just too damn hard.

Screening resumes: Complete pain in the ass. If you get lucky and your wanted ad works, you get flooded with a mountain of resumes of which 85% of them will be complete trash. I remember a few years ago I was trying to recruit a programming intern. I was not picky: I just wanted a student that had the time, wanted to get paid and was interested in learning.

What did I get?

A ton of PhDs, MBAs and people that had paper certifications and no experience. I actually went back to the ad, to see if maybe it was too vague, but it wasn't. It clearly explained that it was a position designed for a student.

Phone screening: Another pain in the ass because many damn good programmers are simply terrible over the phone. If you can get him to open up on the phone call, fine, but I wouldn't hold it against him if he crawls into his shell and starts answering in monosyllables. It happens to the best of us.

The actual interview: people sometimes don't understand that for those of us working in a for profit environment, we simply don't have the time to schedule a few dozen interviews. All of us are too busy billing on projects. That interview, specially if dealing with a small company, is already straining everyone. Be there on time, and try to get as much done as you can. When I interviewed for my current job, I was screened over the phone for about 45 minutes, then I interviewed with the owner for an hour or so, and then spent a few hours doing the technical part of the interview. The whole time I was there I was talking to somebody, not sitting on my ass chilling out.

The list is far from perfect, but overall it is pretty reasonable. I totally agree with the "talk your ear out" factor, even the most introverted programmer opens up and starts yapping once you get him started on a programming topic. The other factor that is very important is the programmers ability to pick up a new technology. I have met over a hundred or so programmers in the past ten years, and without doubt, the best ones were capable of picking up a new subject simply by doing online tutorials or buying a book and learning after hours.

He is also wrong in some other things. A brilliant programmer that works long hours may not feel like spending his free time doing programming too. What you will see as a norm is that even if this kind of programmer won't spend a lot of his free time programming, he will do it to learn new material.