Good and bad, at the same time

I think it was Kernighan who ranted about the differences between C and Pascal, and how Pascal was a straightjacket and that there was no way to fix it.

I've been working with C++ today, and my mind has been thinking along two lines.

One thought has been: This is the best C++ experience I have had in a long time. And it has been a good experience, for I am using the STL for the first time. STL fixes a lot of problems with C++ and makes many things easier. The 'string' class has made many things easier, and the 'vector' and 'map' classes have also helped. I can program faster than before (in C++) and get more done.

The counter-thought has been: This is the worst programming experience I have had in a long time. And it has been a bad experience, for I am stuck in the static-type-world of C++ and used to languages such as Perl and Ruby. I have been working harder than usual to perform simple tasks. An especially difficult problem is one of collections. The static types of C++ demand that I define a collection and its contained types in advance, where in Perl and Ruby the languages don't care and accept anything you throw at them. (Well, almost anything.)

Perhaps I have learned a bit of programming in Perl and Ruby. During the day, I had various thoughts on the design of programs, but found that C++ could not handle the designs. I had to "dumb down" the design for the compiler. (Perhaps there is a way to torment the compiler into accepting the design, but it eludes me. I suspect it would involve a lot of template magic, and I find that templates tend to make programs harder to read, not easier.)

In the back of my mind is the thought: There is no way to fix C++. Kernighan's rant (if it was his) has come back to haunt me. Yes, the C language is "better" than Pascal because you can do what you need. In that sense Perl and Ruby are better than C++ because you can do what you need.

The problem seems to be the static typing. And that got me thinking.

Static typing is good, for the compiler. It allows the compiler to check operations at compile-time. (Languages with dynamic typing must perform checks at run-time, and that incurs a cost to performance.) The compiler can also optimize code.

But static typing is a pain when developing programs. It forces me to think about the program. It distracts me.

I want a language (or development environment) with variable typing. I want a language that allows me to design programs with dynamic typing and let me create the design. Then, after I have the correct algorithms and code, I want to turn one static typing. Perhaps in small amounts, or for specific objects in the program. (I would expect the IDE to show me which objects have static typing and which do not, and let me implement static typing on my schedule.)

I'm not against static typing. At least, not all the time. Only when I'm programming.

Looking back

I've completed three weeks at the gig at OMB (at gotten paid for one of them!) and things are still going well.

I've had some time to reflect on the experience of finding a job. It's something that few people do often. I hadn't done it for over nineteen years.

Some thoughts:

If you have a job, it's easy to become complacent. It's also easy to think that your skills are up-to-date. The corporate process for evaluation is not always a good indicator of your skills. Your company has its technology and culture. Other companies have different technologies and cultures. What works in one company does not necessarily work in others.

When looking for a job, optimism helps. So does discipline.

I split my time between three major tasks: job search, new technical skills, and networking. The job search consisted of the traditional things: posting my resume on job sites, talking with recruiters, and going on interviews. The networking consisted of meeting people, from former co-workers to local user groups.

I revised my resume many times. Seventeen. (I kept count.) It took longer than I expected to pull together a list of my responsibilities and accomplishments and mix in the technologies that I used.

Keeping my normal routine helped. I woke at the usual time, ate at the usual times, and stayed focused on the "work" of finding a position. Having no television (I have no cable TV and the television is an old analog-TV) made the task easier. I also set up a fake commute to motivate me to get out of bed. The fake commute was nothing more than a walk to the light rail, a short ride of about three stops, and then a walk back home. But it was enough to keep me in the "I have to get up and catch the train" mindset.

Advertising helps. Not advertising in the sense of purchasing air time or magazine pages, but other types. I used two: job-board freshness and e-mails to recruiters. The e-mails are easy: I picked the four or five best recruiters and sent them e-mails of my accomplishments. (This is where learning new tech is helpful.) I sent the e-mails twice a month: not too frequent to be a pain but frequent enough to keep me in their mind.

For job boards, I used a different form of advertising: I kept my resume up to date. I set up a weekly plan to visit the different job boards (dice.com on Monday, monster.com on Tuesday...) and updated my profile and resume. Sometimes it was as trivial as adding a space or blank line; other times I would make corrections or add new items. The point was to keep my "last updated" date on the web site recent. Recruiters who searched by "show me the latest" would have a better chance of seeing my resume.

I picked the best recruiters and worked with them. I worked with other recruiters, too. At first, I had no idea of a recruiter's skills. After working with them I could group them into three categories: Recruiters, placers, and head-hunters.

Head-hunters are my least favorite. They do very little to learn about the candidate or the positions they have. They perform a simple keyword match against my resume and their jobs and then call me to learn my interest. Their conversations are brief and to the point, usually "I have a position with ${skill} in ${city}, are you interested and what is your rate?"

Placers are better than head-hunters. They ask questions about one's skills and background. They take some time to get to know the candidate. They have a decent understanding of the position. Often they will have placed other people at the same company. But they work on a position, and once it's filled, don't bother to talk with you.

Recruiters (as I use the term) work harder than head-hunters and placers. They know quite a bit about the hiring company. They want to learn about the candidate. Often they require an in-person interview before presenting the candidate. They work with multiple companies and multiple positions. They can suggest alternative positions, and will even tell a candidate that they are not a good fit for some positions.

I don't know for certain but I expect that recruiters have a better "hit rate" with qualified candidates than the others. Which means that hiring companies, if they are interested in a long-term match, should do better with recruiters than with placers or head-hunters. Candidates should do better, too.

Starting a new gig

No posts for a week! Have I been slacking?

Hardly. I started a gig in Washington DC last Tuesday. I've been commuting in, working during the day, commuting home, and handling necessary chores in the evenings.

Starting a new gig is interesting. You meet a bunch of people (and promptly forget their names), get shown a desk in an office (and sometimes forget the way to it), and review some code. You change passwords on your new accounts. You learn the process for time-tracking and billing.

The code for this project is in C++. There are three major parts. I've looked at them and the code seems reasonable. It can be improved, but I've seen worse. (Much worse.) I used the MKS tools to count lines of code (LOC) and get a feel for the size of the three programs. (All are small enough for a small team to handle.) I wrote some Perl scripts to parse the programs and generate class dependencies. These show a lot of linkage between classes. The programs are tightly coupled. One of our goals is to make them less so.