April 8th, 2010
You may know that Code Anthem is a startup currently in stealth mode. However, we are doing some market research using the totally awesome Ask Your Target Market survey site. Overall my experience with them has been great.
Without exposing too much, I thought you all might find this tidbit interesting. The title of the survey was “Assume that you are a manager who is hiring programmers for his/her software team:”"
These results make me happy. Overwhelmingly most people thought that a programmer’s technical skill was the MOST important factor when deciding which one to hire.
While it might seem obvious to some that this should be so, I think we all know that’s not how it works most of the time. People want a meritocracy, but we’re left a bureaucracy instead.
So what is the disparity? Is it just wishful thinking on the part of the hiring managers? Or is it that they just lack the right tools to actually make that happen?
Posted in Hiring Programmers | 8 Comments »
April 6th, 2010
I read plenty of articles about how to recruit great developers, but what if you are only interested in the crappy ones – what then? Perhaps you aren’t willing to spend good money to make money, or you just think getting work done is overrated. Whatever the reason, this series of articles on Crappy Programmers will do the trick. Welcome to the first installment: ‘How to Find Crappy Programmers’.
The job post is your potential programmer’s first impression of your company, so make it count with these offputting features:
1. List a String of Acronyms for Technologies
No matter if the person writing the post or doing the interviewing has any idea what they mean. All that’s important is that they were used in your code base at some point in time. There’s nothing developers love more than playing buzzword bingo in job posts.
JMS, XML, J2ME, AJAX, SSRS, SSIS, JSB, WCS, JSTL, HTML, DHTML, XHTML, MOSS, SOAP, BO, WPF.
You get bonus points if the technology is over ten years old. Don’t worry if it seems like you’re filling positions with checklists, developers like having years of their work marginalized into a neat little box.
2. Put an Arbitrary Number Next to Each Skill
It’s important to pay people based on the years of experience they have, not their talent, proficiency or overall competency. To that end, be sure to put a number next to each skill that represents some number of years. A job posting for a Technical Lead might then look like this:
10+ years total in the IT field
8+ years with Microsoft technologies
5+ years with relational databases, like SQL Server
3+ years with C#
1+ years with WEB technologies
Then you don’t have to consider anyone with less years of experience, even if their skill level is higher. After all, since the person is older, they will fit in better with the other old managers. Don’t actually mention age though (that’s illegal) – the proper career terminology is “culture fit”.
Plus, since they were already well into the workforce while most of the current technologies were created, they have a firm grasp of the fundamentals, like PowerBuilder.
3. Say Nothing Positive About the Position
We’re all very desperate for a job “in this economy” and you did say that the multiple positions would be “filled soon”. Don’t waste space talking about what sort of projects you might work on, what the team environment is like, how the developers work together or anything technically appealing whatsoever.
By completely ignoring what a developer looks for in a job, you’re letting us know up-front the sort of don’t-care attitude at the company. This sets the stage and limits developers asking for things when they come on-board, like non-broken chairs or licensed software.
Agile is for hippies.
4. Use Euphemisms for the Negative Aspects of the Job
Obviously, if anyone knew what it was really like to work here, no one would take the job. After all, that’s why our other developers have all left and we’re constantly hiring. Clearly we will need to lie, so here’s an easy translation matrix:
| What the Job Post Says |
What it Really Means |
| Standard work hours are 40-50 hours a week |
We expect developers to live in their tiny tiny cubes 24-7 |
| This is a support position |
We don’t allow our developers to have a life outside of work |
| You will work closely with the PM, DBA and QA |
Our environment is highly political, riddled with ridiculous rules made by people who don’t understand software, and we get very little done |
| This position involves working with our real-time application |
I don’t know what real-time means but it sounds good |
| Great opportunity for growth |
Only a desperate person would deal with this shit |
| Job candidate must be resourceful, responsible and able to work well under pressure. |
Our corporate culture is basically the ‘Lord of the Flies’ |
5. Require Resume to be in Word doc Format
Requiring resumes to be in the proprietary and platform-specific Word .doc format, instead of .pdf, .html, or .txt formats, is a nifty little test early on in the hiring process. You want to make sure that your developers are adept at jumping through HR hoops, even on technical matters.
We do not want our developers to have any basic principles in their work, or to have a keen understanding of interoperability or usability. We also like it when recruiting firms paste their logo at the top of our resumes and add lame summaries – our resumes were too much about us that.
This is a special treat for Java/UNIX developers.
So there you have it, folks. By following these simple steps, you are well on your way to hiring crappy developers.
But wait, some good developers might still slip through this cover, so stay tuned for our next installment of the Crappy Programmers series by subscribing here.
Posted in Hiring Programmers | 102 Comments »
April 2nd, 2010
There is a stigma surrounding “Rockstar” or “Superstar” developers. Sure, they are “nice to have”, but they are also selfish, egotistical and a complete pain in the butt. They would definitely hire them if they ran into one (and of course, they don’t) but they’d do it begrudgingly.
These are the same people who struggle with messy codebases, delayed (indefinitely, often) schedules and overrun budgets. Of course, they don’t notice the relationship between the two…
Fact is, superstar developers are aboslutely positively necessary.
Rockstar developers are more productive, but that’s not what makes them necessary. What makes them necessary is that they have passion. They care enough to:
- Go out and speak to users (even when it’s uncomfortable) and find out what their problem spots are and then motivated enough to fix those problems (even if it means pushing past stodly upper management).
- Implement source control, a continuous build system, automated testing, high test coverage, a good production release process and so many other things that make good quality code.
- Dig in deep into a technical problem, even if it means learning new things, reading books, tracking down experts online for advice, wading through forums, messing around with prototypes for days and even staying late to do it.
- Learn about all aspects of software even when not specifically asked to by managers, like security, encryption, redundancy.
Not only can they take on the tough technical tasks and the overhead of the items described above, but they can also inspire other team members, train them and even compensate for their slowness.
What a rockstar developer is NOT
- Someone who prefers to hear the sound of his own voice, rather than learn something new.
- Someone who prefers to insist that he was right, rather than figure out what’s actually right.
- Someone who prefers to have people think of him highly, rather than produce great things.
I think you might have confused the term “rockstar developer” with the term “douche bag”:
An individual who has an over-inflated sense of self worth, compounded by a low level of intellegence, behaving ridiculously in front of colleagues with no sense of how moronic he appears.
from Urban Dictionary
Note: just because a douche bag thinks he is a rockstar developer, that doesn’t make him one. Please don’t pollute the whole rockstar pool on their behalf. Now, back to real rockstar developers…
One or more rockstar developers can hold up an entire development team.
Ideally the most awesome developer will have some sort of technical lead role, sometimes official, sometimes not. If not, particularly if the lead is sub-par, the rockstar will likely leave.
If a development team has not a single rockstar, not a single person willing to put in the leg-work to really figure things out, then the project is doomed.
The real trouble with using a lot of mediocre programmers instead of a couple of good ones is that no matter how long they work, they never produce something as good as what the great programmers can produce.
from Hitting the High Notes
Non-technical people will ask for features, bottom-line. It’s up to the developers to figure out how to make the code extensible, maintanable, modular, service oriented, well formatted, regression tested and just overall quality code. If the developers don’t care enough (or don’t know enough, same thing perhaps) then no one will do it.
New terminology, perhaps…
Some people fuss over the term “rockstar” developers because:
Rock stars get sex, drugs, parties, limousines, fame, glory, dates with supermodels, and Rolling Stone covers. Good programmers get . . . uh . . . fewer compiler errors.
from The One Tip to Rule Them All
I actually like the term Rockstar because it’s fun and because it accurately mirrors their role with the music industry from where it came. The music industry is supported by rockstars. A label with a rockstar is huge and grows exponentially by how many rockstars they have. A label with no rockstars, but a small army of no-name-ers, is still small and there’s no amount of no-names they can add that will fix that problem.
Of course, music rockstars do also have a bad rep so maybe that contributes to rockstar developers bad rep. Let’s try something else…
Atlas Developers
Borrowed from the title of Atlas Shrugged, of course. And that title borrowed from the Titan in Greek mythology, Atlas, who held up the weight of the world on his shoulders.
Atlas Developers are developers who support the whole team. They are highly productive, highly skilled and absolutely, positively necessary to any successful software project.
So tell me, who is the Atlas Developer in your team and what have you done for them lately?
Posted in Hiring Programmers, Software Building | 3 Comments »
March 26th, 2010
7CYJRB76CFJW
Today is Ada Lovelace day, a day to celebrate the achievements of women in technology, named after Augusta Ada King, Countess of Lovelace, who wrote the first computer programs.
More Open Source-ey Goodness
In honor of Ava Lovelace day, Anil Dash talked about encouraging women to join open source – how appropriate considering I just posted about the lack of women in open source yesterday. The Ada Lovelace Day website also directed me to this optimistic post showing some women in open source.
My Female Heroine in Tech
This is the part of the show where I get to reveal my female heroine in tech. I racked my brain thinking of someone (female and semi-famous) who inspired me in technology, science or mathematics. I even perused the existing list of entries and came up with squat.
That can’t be right. There must be some female that I admired. Looked up to. Emulated. *think think*
Oh, right.
B’Elanna Torres
Oh what a cheesy world I live in it, but it’s true. Remember B’Elanna? The fiery half-Klingon and Chief Engineer of the Star Ship Voyager (it’s star trek, people). She is so awesome. She kicks ass, she’s smart and you don’t get in her way when it’s time to work. On the personal side, she seemed all hard and rough around the edges, and then settled down and had a baby (fawn).
That doesn’t count! Pick someone real!
I do see how it seems odd to select a heroine that isn’t real but the fact is I don’t even know about many women in tech. I read a lot and virtually never come across any remarkable women in technology because there are so few.
I have no desire to seek out reading about someone successful in technology just because she’s a woman. I’d much rather read about remarkable people (in tech, or not) and learn from them even if we don’t have the same anatomy. Doing cool things is not cooler just because you’re female.
In fact, I’m not particularly inspired with women who do cool things in tech, but don’t have children. Take Marissa Mayer at Google. She is unequivocally awesome. I think that men and women alike would love to have her experience and position. Except, how does she apply to my life anymore than a man in her equivalent position?
Fine.
So if I had to pick someone real, I would say Penelope Trunk, blogger and CEO of Brazen Careerist. She rocks and is in tech (despite not being an actual programmer/engineer, she has a start up in the tech sector).
She’s honest and open and it’s not pretty – because that’s life. And she really shows what it’s like to be a woman with children and be successful. What do you do when your little kid wants to cuddle in bed but you’ve got to get to work in the morning? What do you do when your husband takes a call for work and you’re watching the kids and you get a call too? What do you do when you’ve decided to stay-at-home with the kids and are so desperate for just a teeny tiny bit of professional achievement in your life?
This is what working full-time and mothering looks like:
1) Not counting working, sleeping, showering or eating, you only get 15 extra minutes each day do you:
a) bond with your child
b) talk to your spouse
c) clean the house
d) cook dinner
e) do something for work
2) Now, let’s say you need 15 minutes more (and more and more). Working is pretty much a constant at full-time. So, which category do you take them from: sleeping, showering or eating?
I don’t know the right answers and I don’t think Penelope does either, but she is talking about it publicly and that takes guts.
Posted in Open Source, Women, Work/Life Balance | No Comments »
March 24th, 2010
At Code Anthem, we’re big fans of the Signal vs Noise crew. In their book/manifesto Getting Real, they advise to hire developers based on “Actions, Not Words“:
When it comes to programmers, we only hire people we know through open source. We think doing anything else is irresponsible.
Strong words and a compelling argument. There’s only one problem. I am a damn good developer, and I have no open source contributions. And I know plenty more where I came from, comparable and sometimes superior to our open-source-contributing contemporaries in technical skill and communication savvy.
Supposedly, any smart and passionate developer would contribute to open source.
That is crap. Here’s why:
1. It’s an arbitrary distinction.
Open source is a culture. There are plenty of smart and passionate developers out there who are not part of that culture. And certainly there are plenty of dumb and curmudgeonly developers out there participating in open source.
You might as well not hire developers who don’t drink Mountain Dew or play World of Warcraft, just because there is a large subset of smart, passionate developers who do these things.
It’s like golf of the executive business world. Since the people at the top played golf/contributed to open source, then everyone they want to hire would do so also. There’s a fundamental logic flaw.
2. There are there smarter ways to spend your time.
The stereotypical open source developer works for a bumbling corporate during the day, doing dull work (but necessary to make money) and then comes home to work on his passion, OpenOKHRWUJ Framework. This is romanticized as being the high point of any developer, but how about a few (smarter) alternatives:
- A developer has found a job that is challenging and fullfilling with plenty of technical freedom, leaving no need to express his/her passion in another outlet
- Instead of doing a free project, the developer may spend his evening doing extra work for his employer, doing side contract work to make some extra money or working on a side business (still writing tons of top-notch code, except for money)
- Instead of working at nights, the developer decides to spend time with his family (work-life balance anyone?) or actually get some sleep (god forbid my developer actually be alert and healthy)
While I wouldn’t fault an open source developer for spending his time that way, it’s a hobby. Having other hobbies or spending time with your family or getting enough sleep does not make you a worse developer, it just makes you well-rounded.
3. Requiring open source contributions is sexist.
Open source is dominated by men even more so than the programming community as a whole.
 
from Women in Free/Open Source Software Development
It’s not because women developers are not as passionate or smart as men developers. It’s because women value work/life balance more than men, because the open source environment is sometimes (read:often) hostile towards women or for a myriad of other reasons.
Actually, it’s irresponsible to require your new hire developers to come from a male-oriented pool. Alas… “Underrepresentation breeds underrepresentation”.
In conclusion, the goal to judge a developer by their “actions, not words” is a worthy one. But the means of using open source as the one-stop-shop to do so is incredibly flawed.
Posted in Hiring Programmers, Open Source | 22 Comments »
March 23rd, 2010
 One day there was a team of rowers who wanted to go out on their own. They started looking for a boat to rent, and came across one for a great price called the Good Boat. It didn’t look as nice or seem as big as the boats that the other rowers had, but the boat-maker assured them that the construction was high-quality and that they wouldn’t have any problems. And just to be sure, he was willing to join their team as their in-house Professional Boat Fixer.
They began their rowing journey and a little while later, the hull had a small leak. The Professional Boat Fixer sprang to action, applying all sorts of complicated looking patches. He worked long hours and was happy to regale anyone who would listen with the complexities of his solutions, so no one could complain. After awhile, the patch broke and another leak sprang up somewhere else, so the Professional Boat Fixer became very busy, fixing the fixes and new problems. He even hired Assistant Boat Fixers to work under him and help him apply his patches under his close supervision.
The rowers decided the wanted some new benches to sit on and some other items that the Professional Boat Fixer refused to create. So they found themselves a New Professional Boat Fixer to work in tandem with the Old Professional Boat Fixer, to be in charge Things the Old Professional Boat Fixer Will Not Do. The New Professional Boat Fixer was shocked to see the horrible state that the Good Boat was in. The New Professional Boat Fixer exclaimed, ‘I can fix that!’ The captain and other rowers were interested at first (not realizing they had such a problem) but the Old Professional Boat Fixer firmly explained that there was NO problem with the Good Boat or his fixes, and also, the furniture was all shoddy and the New Professional Boat Fixer was not to be trusted. Unable to continue to work on a sinking ship, the New Professional Boat Fixer left the boat, to be replaced by a string of Newer New Professional Boat Fixers. All of them tried to fix the state of the Good Boat, but they were bad boat-fixers and not to be trusted, or so said the Old Professional Boat Fixer.
At some point, the Old Professional Boat Fixer was promoted to oversee the rowers, in addition to the Assistant Boat Fixers. After all, there was a complex system of rowing required to keep the boat going straight (it naturally veered all over the place, in no predictable pattern), so it only make sense that he should oversee them.
 To this day, the Good Boat is still chugging around the ocean, slow and not-so-steady. The Old Professional Boat Fixer and the Rowers are considering creating more Good Boats together, with the Old Professional Boat Fixer as the Overlord Good Boat Master. The Good Boat is considered a myth by some Professional Boat Fixers, but I have seen it with my own eyes and share this story as a cautionary tale.
Images by danslegrandbleu, law_keven, and rene_ehrhardt.
Posted in Software Building | No Comments »
|
