Tag Archives: howto

Head Hunter How “Not To” Guide

Posted on by
Reply

Technology is dominated by two types of people: those who understand what they do not manage, and those who manage what they do not understand.

As a “Senior” software developer I get a lot of job offering emails from head hunters, most of which get deleted. A very few of the emails only make it to a second response before deletion. The problem? It’s not the “email” like you may have been thinking, it’s that head hunters don’t understand developers or how to approach us.  The end result being the content of the job offering email is usually horrible.

Here are some generalized, but often dead-on assessments of most software developers, myself included:

As a software developer, I don’t like people, especially not strangers.  I only have a very small circle of close friends, and I don’t really want to make any new friends.  I want to be left alone to write great software.

The problem occurs when you pretend to act like you’re my friend who is here to “help me” find a new job.  Why not just be truthful and act like you’re here to make money from having me hired by your client, it’s OK, really.  The truth is, any software developer is fully capable of hunting down a new job when needed.  The market is currently in our favor, there are more development jobs than there are developers, and we know that.  Most developers you contact will already be employed.  You’re not here to help them find a job, you’re here to lure them away into a new job so you can make your placement commission.  Cat’s out of the bag guys, sorry.

I hate talking on the phone.  See introvert.  The worst thing you could ever ask me to do is get on the phone and gab.  I’m sorry you guys all feel the need to talk on the phone about the position before giving away any of the juicy details, but you know as well as anyone the important information can be sent via email.  Just send a simple email and include your phone number.  If the job is relevant and there is interest on my end, I will call you.

I don’t hate talking on the phone as much as I hate being unemployed.

As a software developer, I only want the precise information required to solve the problem and nothing more.  When you send an email offering a job you are confronting me with a problem to solve.  The problem is, do I delete the job email or do I pursue the job?  Any details you give about yourself, your big fancy “senior recruiter” job title, your head hunter company, none of that, is important.

Just once I’d like to get a job email from a “junior recruiter”.  Do they even exist?

So knowing these facts, when contacting a software developer about a job, here are the ONLY things to put in the email:

Who is the client you are working for?  If you can’t give that info, then at least say what part of the town/state/country/world the client is in.

Is this job telecommute?  A lot of developers work from home these days, and this is important information one way or the other.  If it’s not telecommute then is there even a possibility of working from home “sometimes”?

What specific technology would I be expected to know for the job?  Translation:  What databases and programming languages are in use?  It does not matter if your client is calling the position “front end” or “back end” or whatever.  What matters is what technology is being used there right now today.  I’ve never once had a job where I stayed within the original job description.  Eventually a software developer is asked to work on more than just things from the original job description, so we want to know more than just some fancy buzz words like “front end developer”.

What is the salary range?  Yes, this is the last, least important question, but very important all the same.  I need to know if this job would be a step up for me or not.  And do not tell me “salary is based on experience” either, I’m well aware your client gave you a salary limit for the position.  We already know I have the skills and “experience” for the job, otherwise why are you contacting me?

Now, specifically, a developer does not want to see the following things in your email:

“What is you current salary?”  Like that’s ANY of your business!  How about you tell me your commission rate if I take the job?  Yeah, didn’t think so!  On the topic of salary, you need to tell me what the (top end) range is for the position, and that’s it.  I fully understand I may not be offered the top salary, but if the top is lower than my current, I’m wasting my time talking to you.  It’s that simple.

“Can you please call me?”  No, at least not until all the other required items above are done, absolutely not.  I will not get on the phone and waste time with anyone until I know exactly what the position is all about.

“Hey, I have an awesome Ruby on Rails job, can you call me?”  Nope.

I do not care about your head hunter company profile.  I only care about the client’s company profile.  So many times I catch myself wasting time reading junk at the top of a job offering email.. junk the head hunter includes about their own company.  I DON’T CARE about you or your head hunter company.  I only want to know about your client, the guy who will ultimately be feeding me and my family, if I take the job.

Be Sociable, Share!

Stack Trace Driven Development

Posted on by
Reply

Motivation

If your software project doesn’t “get users” it will die, bottom line. Launching a software project into production sooner rather than later greatly increases the odds the project will “get users” and ultimately succeed.

Situation

You’ve seen it time and again in recent years. You start a new project. You have project specs and a strong desire to include a test suite with your project to prove correctness and efficiency. But along the way your project specs change, you don’t launch on time, and you have a gazillion tests to update. Your hopes of actually “getting users” dwiddles daily as you cope with all the code and test code changes. What do you do?

Solution

Throw out your test suite and launch the project into production.

Having users actually use your software provides near 100% code coverage. Having your “test suite” run in production on real data means you do not waste time creating fake data in the form of fixtures or factories. Continuous integration is provided as a side effect of server uptime. You can confirm your test suite is being executed by examining server load.

Implementation

STDD is super easy to setup. On Android there is ACRA.. force closes stop, stack trace emails start, simply beautiful. In Django it’s DEBUG=True in settings.py.. user gets an oops sorry page, you get a stack trace email.

Origin

I got the idea for STDD from staring at an unread copy of “Ship It” I had purchased some time ago. I don’t know what’s in the book because like I mentioned, I’ve never bothered to read it. I’m much too busy rolling out new versions of my software projects to read a book! But the title made me think, what IS the fastest way to deliver software while still maintaining some sanity with managing coding errors? I realized the actual code could easily be considered a test suite, and since I have the test results: either it crashed or it didn’t, I followed through with stack trace email implementation to close the loop.

Probability Of Success

I created these probabilities based on my experience. I’ve never worked on a large software project with a hand-coded test suite that actually launched into production. Meanwhile most every other project I’ve worked on, without a test suite, has launched.

P(L|T) = 0.01
P(L|¬T) = 0.99

The “probability” of an actual project “launch” seems greatly dependent on the amount of academic masturbation contributed to the project in the form of a “test suite”.

If you have a project where specs change constantly, you should try STDD. It will greatly increase the probability your project will launch, “get users”, and succeed.

Be Sociable, Share!

How-to build latest Linux kernel from Linus’ git repo on Debian

Posted on by
Reply

Here’s a how-to for building a recent 2.6 Linux kernel on your Debian GNU/Linux box:

You will need to do all this as root. It’s serious business building new Linux kernels :) 

su -

The dash after the su command makes it behave as if you had logged in as root directly, a full login environment is applied.

Make sure you have the required tools and libraries installed:

apt-get install build-essential module-init-tools initramfs-tools \
procps libncurses5-dev kernel-package fakeroot git-core screen \
zlib1g-dev

Use git to clone Linus’ latest git repo:

cd /usr/src

git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git linux-2.6

cd linux-2.6

This will take a long time.

Once you have the source you’re ready for configuration. I base my new kernel configuration on a known working configuration, then trim it down from there. Check to see what configurations you have in /boot:

ls /boot/config*

Configure your new kernel source using your chosen config file:

make menuconfig

Select “Load an Alternate Configuration File”, enter your config file path, for example I used /boot/config-2.6.26-2-686. Hit exit and save.

Build the kernel and package it:

make-kpkg clean

CONCURRENCY_LEVEL=9 screen fakeroot make-kpkg \
  --append-to-version=1 \
  --revision=1 \
  --initrd \
  kernel_image

make-kpkg clean cleans up the kernel source.

CONCURRENCY_LEVEL=9 translates into `make -j9` later. make -j9 means to compile things in parallel using all your processors, so adjust accordingly for your actual system. I usually go 2x the actual number of processors +1.

screen is a command used to run another command in a virtual screen. The new virtual screen doesn’t end if you disconnect. `man screen` if you’re not familiar, it’s a very useful tool.

fakeroot provides a fake root environment in which to build a package.

make-kpkg is a kernel building and packaging tool.

The –append-to-version is whatever you want, I increment mine by one every time I build a new kernel, and usually start over when Linus releases a “stable” kernel.

The –revision is whatever you want, I set this simply for a shorter package name.

The –initrd option makes dpkg build a new initrd image when you install the kernel package later. An initrd image contains drivers your system needs before your kernel loads, for example, raid and ext3.

Build a new kernel using a distro’s (Debian in my case) default config takes a while. Everything will usually work on the first try using a distro config since everything is built as modules as much as possible, and all modules get built. You stand a good chance of successfully booting a new kernel built this way. Later you can remove stuff from the config and rebuild. Wash, rinse, and repeat until you get your kernel config down to just the hardware you actually have in your system.

Install the new kernel:

cd ..

dpkg -i linux-image-2.6.31-rc7_1_i386.deb

Reboot.

When your system comes back up..

> uname -a
Linux saturn.localdomain 2.6.31-rc7 #2 SMP Mon Aug 24 21:53:19 CDT 2009 i686 GNU/Linux
Be Sociable, Share!