June 17th, 2010
Just a quick note to let you know about the launch of Programmer Puzzlers, a new site with logic, coding and math puzzles designed for programmers. Stretch your mind, have fun, challenge your friends or gear up for an interview.
The first puzzle, Burning Ropes, is already up, but a new puzzle is published every week. So if you’re interested in solving puzzles, be sure to subscribe to Programmer Puzzlers via RSS or email.
You can also submit your own puzzler here.
Posted in Uncategorized | No Comments »
June 10th, 2010
Why do resumes suck for hiring programmers?
- They emphasize short, buzzword-filled entries that work well for people full of business-speak (and the other kind of BS). Is that really the kind of person you want floating to the top of your candidate pool?
- Hiring managers reject candidates based on resumes, when a resume has absolutely no ability to demonstrate technical skill.
- It rewards those who are willing to lie, without very little recourse for verification. This is not something I think about very often as I don’t lie on mine, and when I read resumes, I assume they are not lying either. However, occasionally I’ll hear a story about someone who did verify and found a blatant lie, and it reminds me that this probably happens more often than I’d like to think.
In a recent Inc magazine article, Jason Fried of 37Signals claims that you should “never read another resume”. He doesn’t, but then again, his company is in a unique position of having a flood of great candidates after investing a great deal of time building their image.
It should be fairly easy to recognize technical skill, right? Thousands of currently-employed crappy programmers and millions of horrendous LOC are a testament that it doesn’t work that way.
What are alternatives to resumes that would factor in technical skill?
Open Source Contributions
This is the option used by 37Signals, and I have an entire article devoted to why open source is not a good way to evaluate potential programmers. In short, there are plenty of great developers who don’t spend time on open source, as well as plenty of crappy ones who do. This complete lack of relevance to technical skill makes it a useless and even harmful barrier to entry.
Certifications
This one is an oldie, but like Monthy Python, it’s not dead yet. Certifications are granted by some body that claims to have authority, but they actually make money by people taking the tests, so it’s in their best interest to allow a reasonable percentage to pass. By taking money from test-takers, they have ruined their objectiveness. Plus, they rate developers in a pass/fail system: you are either a certified developer or not. This is not a reasonable way to judge developers since their skills range quite widely. And as soon as you’ve seen a couple of crappy developers who are “certified” their credibility is destroyed also.
Stack Overflow
The Joel on Software/Coding Horror camp described the problem perfectly, but the solution fell short. Since your Stack Overflow score is based on your activity on their Q&A site, it promotes people who spend a lot of time on their site, instead of the best programmers. That model certainly serves Stack Overflow well, by providing an incentive to spend time on the site, but doesn’t work so well for busy programmers or the companies that want to hire them.
Coding Tests
This one is really the best option for employers because it is the most accurate, but it’s also extremely time consuming for both parties. Even if you require a coding test before you’ll interview someone it’s still very time consuming to check all of the submissions. And many companies don’t want to require this: it turns off a lot of good programmers from bothering to apply (why should I spend an hour of my time just for the chance to speak with you?)
So what’s left … Code Anthem! Coming soon to a browser near you. Sign up for the beta now.
Posted in Hiring Programmers | 19 Comments »
June 8th, 2010
Let’s say your a hiring manager and you need to hire a software developer for your team.
Well, most people start with a job posting:
- Dice: $459
- Monster: $395
- Career Builder: $419
- Joel on Software: $350
- Signal vs Noise: $400
You may also want to browse existing resumes:
- Dice: $895
- Career Builder: $600 for 2 weeks
- Stack Overflow: approx $500 per week
And if you’re having trouble you may need to use a recruiter:
- At about 20% of your new hire’s annual salary, that’s $10,000 – $20,000 per hire
So now you have a giant pile of resumes, time to spend hours and days and weeks on:
- Reading and sorting through resumes
- Following up with candidates
- Doing phone screens
- Administering coding and technical tests
- Doing technical interviews
- Doing behavioral interviews
- Doing management interviews
- Considering a hiring manager’s salary, that is some serious $$$
If you don’t find anyone, you have to start over.
- Losing money in opportunity cost as we wait weeks and months just to find the right person
If you do find someone, you may want to test the waters:
- Hire them to do a project for you on the side: $5-15K
- Hire them on contract for 3 or 6 months: $20K-40K
So, how much money does it cost to hire a good programmer? A lot!
That doesn’t even take into account what happens when you get it wrong and hire a bad programmer. You waste all that time on training them on your system and incorporating them into your company. To top it off, crappy programmers actually mess up your system worse than when they started.
Imagine this.
5 programmers who can really write code at the level required. You can test them all you want, but it’s not necessary, they’re already qualified and capable through and through. They are all looking for jobs and geographically located near you (assuming you care).
You meet with them to determine mutual culture fit and pick the one that gels with your team.
How much would that be worth?
(Put your answer in the comments)
Posted in Hiring Programmers | 7 Comments »
June 7th, 2010
There is a lot of mystique associated with being “agile”. Even for developers who are usually so tech-savvy, they talk about agile in odd terms – like my grandma might ask what the web is used for.
Like:
“I guess I’m a little a bit agile, but I really like to use use cases – does agile have use cases?”
Or,
“I woudn’t want to do scheduled releases like agile because I don’t want to send the customer half-finished features.”
They really just have no idea what agile is…
I get it. I hate buzzwords and bandwagons, too.
The difference is that I’ve been on multiple agile teams that were so incredibly successful that I am sold.
- I never have to feel that sinking feeling in the pit of my stomach just because my customer found a bug.
- I don’t have to fight with my customer over whether something is a bug or a feature request.
- No more working crazy overtime at releases.
- No more holding your breath at the big, scheduled demos that it will actually work.
So what is this magic? In the effort to spread a little knowledge and good cheer, this post is just a small tasty sip of the agile KoolAid:
- Agile is a set of ideas, not a religion
Agile is based on a set of ideas called the Agile Manifesto. For example, value “individuals and interactions over processes and code”. I have no idea why so many agile proponents try to indoctrinate everyone into their little cult, but that is the opposite of what agile is about.
Agile doesn’t say you can’t use any process, agile doesn’t say you can’t use any up-front design, agile doesn’t say you can’t use your previous use cases!
You don’t have to worry if agile is going to destroy some precious aspect of what you do, because by definition if it’s working well for you and the project then it’s agile.
- Agile doesn’t increase project risk, it reduces it
Agile recognizes that feature creep and unexpected bugs are going to happen. Traditional project planning basically crosses your fingers and hopes it won’t happen, or punts it to some later date (I’ll deal with feature creep when it happens, We’ll handle all bug fixes at the end).
Instead, agile puts the reins in the hands of the customer/client/PM/whatever. By allowing them to reorder the backlog however and how often they choose, we ensure that the programmers are always working on the most important thing at any given time.
If you run out of time in an agile project, by definition you have already completed the most important things. If you run out of time on a “traditional” project, you most likely have something completely unusable, like a database and middle layer but no UI.
Listen, agile doesn’t make crappy programmers write good code and it doesn’t turn useless products into good ones. All it does is allow programmers and PMs work together on the same side the table and focus on the things that matter, like getting to done.
Posted in Managing Programmers | 2 Comments »
May 28th, 2010
Development Driven Development (DDD) is a revolutionary new approach to development that focuses on … you guessed it, development! DDD takes a radical approach in an industry filled with tests, metrics, and processes by allowing smart developers to write code. Some managers and even developers have a hard time wrapping their heads around it conceptually because it does require a shift from existing thinking.
How does it work?
- First, the developer thinks about the problem they need to solve
- Then, they solve it (usually by writing code, not always)
- Repeat until done
DDD vs TDD vs BDD vs FDD vs ADD vs …
There are people out there writing code who really shouldn’t be. They produce bad code and crappy software.
The obvious (and correct) solution to this problem is to only use bright, thoughtful programmers.
Instead, the software community reacted by putting in place safeguards and frameworks and processes.
Since the more thoughtful programmers tended to be the early adopters, the code that was produced was better, and the frameworks appeared to be a success. Now all we have to do is get more people to use the framework, and the code will just get that much better. This is similar to selling diet drinks to gym trainers and noting that they do, in fact, lose weight and look great.
In reality, crappy programmers will always find a way to produce crappy code, even if they are using XDD.
But I am a good programmer and I want to use XDD!
Good programmers will write good code regardless of whether or not they use TDD or not. Certainly, these tools can be helpful and there’s nothing inherently wrong in using them. It becomes ridiculous when people start to think that this tool that may be useful to some is going to save us all from bad code and crappy software. Or that a smart, productive developer who does not use XDD must be a bad developer.
Frameworks and processes don’t build good software, people do!
Posted in Software Building | 33 Comments »
May 24th, 2010
It’s graduation time again and that reminds me of a particular experience as a hiring manager for a company that was small and highly technical. The structure was pretty flat: there were only a few managers in a company of 30-ish developers and they wrote code everyday too. It was an extremely productive environment.
We were looking for people who were bright and could either write great code, or learn quickly. The pay was good. We had people with bachelors and advanced degrees, with no experience to 20 years experience+. Basically, if you could make it past the gauntlet, you were in. And, like most coding shops, we were constantly hiring.
I found out that the local university was holding a job fair for their computer science department, so the Operations/HR person and I packed up some banners and things from their trade show materials and went over.
We stood at our table along with other companies as the soon-to-be-graduates made their rounds. The people graduating with their bachelors were as-expected, overall bright and motivated, and we pinpointed a couple to do callbacks.
For some odd reason, there were more people who were graduating with a masters degree than a bachelors there. Not sure if there were more masters graduates than undergraduates (really weird!) or whether the MS people were just having a harder time finding a job (my guess).
I watched one exchange between an MS graduate and our HR person:
MS Grad:“So, do you have any jobs for Masters Degrees?”
HR: “Absolutely! We hire people with masters degrees or with bachelors degrees – we don’t really care so long as you can write good code.”
MS Grad: “Oh… “ [wanders off]
That disinterested and entitled attitude mirrored my own conversations with the MS grads.
Being the technical of the two, I would talk about how we had a great flat structure, how we were given the freedom to write great software and how gratifying it was to work with other smart people. They, in turn, would ask about management positions and architect positions.
They expected that since they had a masters degree, they would automatically be put in charge of the lowly bachelors degree people. And from my brief technical discussions with them, they were not nearly up to even working with us, much less managing. The lowest, most junior developer at our company could out-code and out-design them any day of the week.
Now, if we would have hired a MS grad, they most definitely would have received a higher offer than their bachelors degreed counterpart. And they would have been thrown onto a moderately complex (read: interesting) task without as much, or any, mentoring as a completely inexperienced junior person. And honestly, having the advanced degree probably would have allowed them to move up more quickly into management than someone else. The workplace was progressive in some regards, but old habits die hard.
But based on their general lack of impressiveness, not a single MS grad of the many many that came to our tables got a callback.
When I discussed my experience back at the company, someone mentioned that maybe it was because it was a local university, instead of a top school. But I don’t think so: the undergraduate students were a reasonable pool of candidates, and we found a few possibilities, and they were better than the MS grads.
I’m sure that there are plenty of very smart and very innovative MS grads out there, but I think it makes sense that they would be snapped up before having to make the rounds at a career fair.
The reality is:
There is no shortcut to being a manager, and definitely not a good manager.
There is definitely no shortcut to being an architect or technical lead.
And there is no shortcut to being a decent programmer.
What is a MS in Computer Science worth? The knowledge you take from it of course, and not a penny more.
Posted in Hiring Programmers | 22 Comments »
May 18th, 2010
 Iron Man 2
For every job post calling for a “superstar” programmer, there’s a ranting blog post about how ridiculous it is.
Programmers are not like gurus because no one can possibly know that everything.
Programmers are not like rockstars because they don’t get gratuitous sex and drugs.
Programmers are not like ninjas because they don’t have throwing stars.
Supposedly, if you call a programmer any of these things, they will get lazy and arrogant. I’m pretty sure plenty of programmers were lazy and arrogant well before HR folk came up with those titles.
They became necessary because the system for hiring developers is fundamentally broken.
Those terms are the only existing way to succinctly express that you want a highly skilled, very productive person who is more focused on getting things done than process and more focused on doing quality work than playing politics.
The current hiring system for programmers emphasizes all the wrong things while ignoring all the important things.
- We emphasize age through years of experience, neither of which have a strong correlation with skill and productivity, and not even much to do with maturity.
- We emphasize the ability to condense your achievements and work ethic in business-speak riddled resumes, which has nothing to do with technical ability and douse any personality whatsoever.
- We emphasize the ability to communicate using generic cover letters that spout more business-speak and feel-good messages sprinkled with obligatory specifics grabbed off the company website. Is this the sort of templated slop you want in your software as well?
- We emphasize the ability to describe a design over actually implementing one. We emphasize being able to fit a problem into a neat little pattern over writing an algorithm.
- We emphasize getting along with QA, management, executives, marketing, etc over being able to get the job done. As in, don’t rock the boat.
The people who are successful in this environment are rarely the great developers.
So what do you do if you need a good developer? Maybe you don’t even understand WHY the system is broken. But you know that the people who are passing through the traditional hiring barriers are just NOT cutting it.
So you slap a “Rails Rockstar” or “Silverlight Guru” title on your job posting. Most likely the mediocre programmers will be scared off (“that sounds hard!”) and some great programmers will perk up (“that sounds interesting!”).
For those disgruntled among you: yes, it is an HR marketing gimmick. Because they don’t have any other way to get the good ones.
——————————————————————-
If you think there must be a better way, you’re right. Code Anthem is a way for employers to easily find great developers. If that sounds interesting, subscribe by RSS or by email, or follow us to stay tuned.
Posted in Hiring Programmers | 12 Comments »
May 14th, 2010
Google is known for its fantastic amenities including from free gourmet meals, massages, elaborate workout facilities and recreational centers. Paying for these amenities provides Google with plenty of benefits, including increased productivity (from happier employers who stay at work longer), improved retention of their employees and a great recruiting tactic.
While they are at the far end of the spectrum, many companies have spent time and money on employee friendly workplaces. Available amenities range from free sodas and ping pong tables to on-site gyms and hosted conferences. And for their efforts they get also get the benefits, in proportion, for productivity, retention and recruiting.
Even with that whole coolness factor, Google and other companies are still scrambling to find top talent. There is enough talent in the world, but there just aren’t that many people who are already located nearby or who are willing to relocate there.
Progressive companies are moving towards distributed development teams.
Distributes teams are teams where the developers work together … from home. There may or may not be an office, but most of the developers’ collective working time is spent not there.
Probably the most well-known example of this is is 37signals. It is based in Chicago with office space and half the team there and half the team distributed, and anyone can work from home. They not only practice this but encourage it on their blog and recent bestseller Rework (affiliate link). Another recent headline maker in has been Stack Overflow with a half-distributed team as well.
A few other high profile examples include DailyBurn, Gravit, Automattic and DotSpots and there are plenty of lesser known examples as well.
Elephants can dance, too
It’s not just restricted to small, very agile companies. I’ve even seen larger companies embrace distributed teams on a team-by-team basis. As outsourcing and global collaboration becomes more mainstream, distributed teams are much less scary.
It’s just smart business for companies to move towards distributed teams. You can reach the best talent, including people who would never ever move to where you are geographically located.
Plus, they take the place of those fancy Googleplex amenities:
- Instead of enticing people to stay at work longer, you can move work to them. Passionate workers will naturally work more when it’s so convenient and built-in.
- Instead of having your employees go through hour-long commutes, get more working time, go green and reduce stress (also reduces need for those free massages).
- Instead of manicured lawns, give employees some breathing room by allowing employees to work in natural setting with easy access to comfortable outdoor settings.
- Instead of installing ping-pong tables and video games, avoid burnout by letting employees enjoy fun in their own homes
- Instead of hosting a childcare center so that employees can be near their children, let employees select great childcare options near their homes, see their children at home anytime if their spouse or nanny watches them there, and greet their children when they get home from school.
- Instead of filling up employees with unhealthy sodas or expensive gyms, save money while improving the health of your employees with access to their kitchens for easy homemade foods instead of fast food.
And for those companies that just want to spoil their employees rotten, you can still provide great services like paying their gym memberships or team vacations.
… why can’t everyone lavish these sort of perks, and this sort of environment, on their employees? Well, because we’re at a weird time in the history of the growth of the Internet. At this (perhaps anomalous) point, the business leverage resulting from the focused application of human intelligence is so high that all these benefits and all this freedom, considered through a pure cold profit-and-loss lens, are cheap at the price.
Tim Bray in Life at Google
Look for more smart companies hiring for their distributed team at a location not-so-near you.
Posted in Managing Programmers | 7 Comments »
May 13th, 2010
How do you know if you’re software project is going to crash and burn? Use these handy tips. Consider it a reverse Joel Test.
- It started out with Waterfall and then once they completely derailed and went into a free-fall, started calling it “Agile-ish”. This is also known as fake agile, or “fragile”.
- Fixing a bug always exposes another bug. If the software is so buggy that you cannot even GET to certain parts of it due to the bugs, then fixing one just exposes another one, and another one, and another one. This is not the same as causing a bug with your bug fixes, although that’s not good either.
- One or more of the central technologies became unsupported by the manufacturer before the project even started. Even better if the technology line has been discontinued entirely.
- You’re using PowerBuilder or any other “rapid development tool” that abstracts away actual code in favor or checkboxes and drop-downs. Libraries, toolkits and APIs are all fine. These tools are like playing Twister with code.
- The technical lead cannot correctly use his email client or browser. If someone cannot even use basic, standard software, how can he properly lead a team of programmers?
- The Project Manager is writing code and a developer is managing the schedule. Seen more often than I’d care to admit.
- There are more business or domain people on a team than actual technical folk. 1 programmer with high turnover + large code base + critical system + huge bug list = no problem?
- There is a test suite from a previous programmer but half of the tests are failing or don’t compile. For extra fun, check if reported bugs would have been prevented if the test suite had been used.
- The process for adding a single line of code requires multiple lines of commentary. A comment at the line stating the reason and your name. A comment at the top of the file putting your name and update date. A per-file commit with descriptive message. Update to the bug-tracking/PM software. Etc, etc.
- The phrase “it’s not a bug, it’s a feature” applies to most of the “features” in the product. “The system wasn’t designed for that.”
Have any other signs from the trenches?
Posted in Software Building | 10 Comments »
May 10th, 2010
One day a developer started at a company and on his first day, while setting up his development environment, pulled out a memory stick. It contained all the old code he had written at previous companies, so he could write code more quickly, he proudly proclaimed.
Aside from the fact that it’s illegal and unethical, it’s also stupid.
Code that is not being actively maintained and refactored degenerates quickly. So instead of his output improving and learning new and better ways of doing things, it actually is getting worse over time.
Short-cut thinking sabotages software projects.
More and more developers are content to write bad code and build crappy software products. We’d like to blame it on the managers and the companies that push us to produce more on shorter schedules.
“I’d love to do automated testing or TDD, but they just don’t give us time to do that.”
Automated testing and TDD are part of coding, not a separate activity. When you deliver a software product, or even just a snippet of code, you’re putting your signature on it that it works. Automated testing and TDD are not optional to the company, they are optional for you.
If you are truly confident that you are shipping quality code without them, then maybe they’re not needed. But don’t push the decision off to the (usually non-technical) manager. He may not explicitly give you time to do “automated testing” but he sure as hell expects the thing to work properly.
“I know this is a hack, but they said we just need to get it working right now, and we can come back to it later.”
If this is the mentality at your company, how many times do you actually get downtime to go refactor and improve your code? Rushing and hacking and crunch-time just begets more rushing and hacking and crunch-time. The more you rush, and skip good design and quality practices, the worse your code will be. You’ll introduce more bugs and more unnecessary complexity. That will delay your schedule even more, resulting in … more crunch-time.
It’s a vicious cycle that we as developers are not only complicit in, but actually cause by producing poor quality code.
“This code isn’t very important so it doesn’t need to have a good design”
What would happen if this code doesn’t work correctly? If the answer is “not much”, they you should probably go work on something else. If the answer is “a whole lot” (it probably is) then do it right.
Writing bad code is viral.
- If you write bad code on certain parts of the codebase, it will become a habit and it’ll start to bleed over into all of your coding.
- It’s the broken window syndrome: if some parts of the code are written poorly, there is less impetus to write better code in the other parts.
- Your code base is the primary training manual for new developers on your team. If they’re learning from crappy code, that’s how they will write code too.
- Letting bad programmers onto your team can actually have a negative productivity impact. More diligent team members will spend time fixing their crappy code, and other programmers will fall into the crappy code slump alongside them.
If the code is important enough to be written, then it’s important enough to be written correctly.
How has the bad code virus spread in your software team? Have you been infected? Got any natural remedies to suggest?
Posted in Uncategorized | 7 Comments »
|