May 5th, 2010
Conventional business wisdom states that every business wants to improve. They want lower operations costs, higher profits, happy customers and to retain their best employees. Virtually every business will attest that’s what they want too, albeit in varying orders of priority. But they don’t.
Fun will now commence – Seven of Nine, Star Trek Voyager
 They say they want to make more money, but are content to live with failed software projects, poor programmer productivity and operate on software that isn’t fit to be used.
They say they want happy customers and happy employees, but they plow through both of them with high turnover rates like they’re completely expendable, replaceable and without value.
Great programmers are not made for companies like that.
As a great programmer, how do you spot a great company from the rest of them? Here are 3 questions to ask the hiring manager or recruiter.
1. What sort of technical exam do you use to screen programmers?
This could be a coding sample, a coding test, a strenuous technical interview or even an aptitude test. A few rounds of “What is your experience with X technology?” does NOT cut it. If they’re considering hiring you without properly testing you, just imagine the low level of talent that has crept through their process over time.
2. What do you do to make your programmers lives easier?
Some crappy managers will actually pause in confusion at this question. After all, managers are only there to tell the programmers what to do, and then reap the rewards. Other crappy managers may come up with some lame answers, like from an HR cover sheet. Good answers might be to allow them to work from home occasionally, to give them the freedom to use new technologies, etc.
3. What percentage of the developer’s time is spent in meetings versus uninterrupted coding time?
The ideal answer would probably be something like “a few minutes every day, a planning meeting every two weeks at the start of the iteration.” A more realistic but possibly acceptable answer would be, “a couple of hour-long meetings with different businesspeople, as needed.” It’s up to you how much is too much. Beware an answer like “we try to limit meetings and restrict them to as needed” without specific time durations.
Let’s take it to the masses. What do you look for in a great company to work for?
What do you look for in a great programming job?
Posted in Hiring Programmers | 7 Comments »
May 3rd, 2010
I have a guest post up at Remarkablogger today about the great response to the Code Anthem blog in our first month from you fine folks. It’s a good read for anyone interested in blogging, start-ups or general movement-starting activities. Or if you just want a meta-post about what’s going on behind-the-scenes here at Code Anthem (on the blog/marketing side, at least).
“I am in the process of launching my startup, Code Anthem, for great programmers and the companies that hire them. I was thinking over some of the logistics of running a private beta program and realized that I needed a group of people who could be my beta testers, early adopters and even evangelists when we launched.
I decided to start a blog and open a twitter account. That was 1 month ago, and since then I’ve had over 50K visitors to the blog, over 500 subscribers via RSS and email, 221 comments and over 150 Twitter followers. I didn’t have an existing audience of any kind to pull from, so this was all starting from zero.”
Posted in Uncategorized | No Comments »
April 29th, 2010
Businesspeople have two distinct roles in software building:
- To determine how software should look and behave as a user
- To prioritize the feature/bug fix list based on business priorities
By businesspeople, I mean the customer, the client, the program manager, the product owner, project manager, client liason, customer proxy or any non-technical and non-design person involved in a software project. Ideally this should not just be a guessing game, but based on their relationship with the customer, including feedback and user testing, as well as market research, etc.
If they do any less than this, then your software project will end up somewhere totally useless, even if it technically works.
If they do any more than this, then your software project will end up totally useless and will not work well technically either.
That’s the function of a businessperson on a software project.
There’s no sense in being precise when you don’t even know what you’re talking about – John von Neumann
Instead, most business people try to stick their noses where they don’t belong. Dictating technical and design decisions based on their qualification of, you know, having used MS Office before. They also try to manage software projects as if we were building a bridge instead of software, and as if we were low-skilled, replaceable cogs in a machine, instead of highly-skilled, professional craftsmen.
The result? Ugly, broken software.
 Dr. Spaceman from 30 Rock Would you, could you, to a doctor?
It’s like me trying to tell a surgeon how he should be performing surgery based on, you know, having body parts. No, I don’t think we need those extra sutures. Oh, you should be using the 1/5″ scalpel instead of the 1/8″.
Nevermind that he is a well-trained, highly skilled professional who has done this before. By employing him to do work for you, you clearly not only have the right to dictate how he does his job, but also clearly know better than him.
Of course, any decent doctor would NOT comply, and probably has an ethical obligation not to do so. Software development professionals should behave the same way.
What’s a highly-skilled professional to do?
The crux of the problem is that even though we know the right way to build software, most of the people who employ us don’t know it.
One solution would be to go work for a company that is run by technical people. Apple and Google are the big examples, but there’s plenty of smaller fish out there.
Or you can find a position in a team with a strong technical leader. The company may have a lot of BS, but a strong technical manager can shield his/her team from it and give them the freedom to build great software.
Both of those are great options, but to truly solve the problem wherever you are, it’s going to take education. It’s not a particularly sexy idea, but it’s at the heart of every movement. We can either sit around and whine that they don’t get it, or we can make it better.
Businesspeople just don’t know what they don’t know.
If we intend to work together (and it really seems inevitable, doesn’t it?) I submit that we need to help them understand what it would take to build great software. As in, please do the two things outlined at the top of this post, and do them well. And for everything else, please let us do what we came here to do: build great software.
Posted in Software Building | 9 Comments »
April 26th, 2010
 This is a follow-up to the popular How to Find Crappy Programmers. If you’re interested in having a team of crappy programmers, instead of those annoyingly bright and passionate good ones, you probably want to start there.
Despite your best efforts, some good programmers slip through the cracks – how can you get rid of them while keeping your coveted crappy programmers around?
1. Focus on Punctuality and Butt-In-Seat Time
Never mind that a good programmer can produce more valuable work in a 30-hour workweek from home than a crappy programmer can toiling 60 hours in the office. There’s no point in getting useful software in a timely manner if you don’t get the all-important face time.
Good products are nice, but there’s nothing more fulfilling in a manager’s life than seeing a roomful of people, heads-down, typing away in tiny cubicles at 8:00 am in the morning. Coming in at 9:30 am is wholly unacceptable – those guys are just having too much fun.
You get people on salary so that they aren’t on the clock, and that way you don’t have to pay extra when they work longer than 8 hour days. Then again, don’t be afraid to insist that they work at least 8 hour days all the time. Who cares if they have nothing to do, or if they have already gotten way more done than the guy next to them, surfing the internet? It’s butt-in-seat time, baby.
2. Set Their Salary Based on Their Age or Time at the Company
Setting salary based on your age makes a lot of sense since you, the manager, are probably old. That way you get more money. Since that’s illegal, you should base the pay on “years of experience” which equates to age for everyone who didn’t go on a 5-year+ sabbatical. Don’t worry, that’s pretty much only working moms, and you probably don ‘t want to pay them much either.
You might have an employee who’d rather be paid based on their productivity or the value of their work or even their skill level. Blasphemy! Clearly, that person is just looking for a free ride, without having to pay their dues. Say it with me people: “We care about everything except for the actual work you produce.”
3. Reduce Time Spent Coding
It’s important for developers to spend a lot of time in meetings. That way they can get a complete understanding of the minutia in the business side of things. And also, it’s more fun to have a big audience when you ramble on in meetings. Don’t worry that we won’t have any time left to do actual work (ie. coding), we’ll just come in early and stay late to get that part done.
Another fun thing is having your programmers do your desktop support. Really, anytime your Outlook or your iPhone is acting up, feel free to call them over to troubleshoot the issue. It’s so handy having geeks around.
4. Monitor and filter their Internet usage
Developers just can’t be trusted, everyone knows that. We are always hacking things and downloading illegal music and that sort of thing. So, you should definitely install a program to monitor their internet usage. You could also block sites that you deem to be a waste of time, but then that might tip your hand that you’re monitoring them.
For that matter, you ought to go ahead and dictate what development environment and tools they have to use. After all, you picked the setup with the longest feature list (not to mention the sales guy took you to lunch) so those developers shouldn’t have anything to complain about. Anyone who wants to use anything else is just a prima donna.
5. Make Them Build Crappy Software
This is the most important one of all. A crappy programmer can only make crappy software. However, a good programmer has the ability to make both good software and crappy software, right? Wrong!
Good programmers hate writing crappy software. They’re always yammering on about code design and trying to test everything, what a pain.
Force them to write inline queries, develop in VB on the command line and fix bugs in 1,000 line methods. They may fight it at first, but pretty soon they either leave or become a crappy programmer also. You’ll know that they’ve come over to the dark side when you see that empty look in their eyes and when they see a Dilbert cartoon they laugh … maniacally.
The reality is that not everyone is interested in managing good programmers. Sure they get things done and know a lot about technology … yadda yadda. They also challenge your assumptions and push to improve the system and that’s just not going to work in your business.
The fact that it’s been done that way before and hasn’t imploded yet (or lately) is good enough for you. You can use these handy tips to keep your crappy programmers while firmly excluding the good ones.
Like this post? Subscribe to the blog or follow us on twitter for more fun updates. Code Anthem is a startup aimed to help programmers show what they can do and connect with great companies. Stay tuned.
Posted in Managing Programmers | 45 Comments »
April 22nd, 2010
 The Christmas classic ‘Rudolph, the Red-Nosed Reindeer’ is basically one big bundle of awesomeness, but this is a personal favorite:
Hermey: Hey, what do you say we both be independent together, huh?
Rudolph: You wouldn’t mind my – red nose?
Hermey: Not if you don’t mind me being a dentist.
Rudolph: It’s a deal.
There are people who see the world as a zero-sum game.
That would mean that in order for you to be successful, I would have to fail. And then in order for you to be more successful, I would need to fail more.
It’s the reason why everyone scrambles when a pinata is broken because there’s a finite amount of candy on the ground and in order for you to get some, the other guy needs to get less.
One thing that contributes to that mentality is that programmers are not paid in proportion to their productivity, or their skill level. At best, they are paid based on their ability to negotiate. At worst, they are paid based on how old they are.
If programmers were paid based on their skill level or productivity, or something that even remotely resembles value to the company – what would be different?
If programmers were hired based on what they could do and not what they said, how could everything not be better?
- You could spend less time on value-less things that you hate to do, like resumes and more time on honing your craft
- Companies could spend less money on recruiting and hiring techniques that are notoriously horrible at predicting success and get back to building software
Obviously, this is a step up for the currently under-valued great developer who toils away thanklessly, buried in a team of non-starters. Even if this were a slight step-down for a more junior developer, at least there would be a clear path ahead where competency and achievement would be rewarded instead of having to play the corporate games and politics.
The only person this would not help is the person who is not productive nor skilled and has no desire to become so. To them I will say: your life is about to get a whole lot harder.
Things are in full swing at the Code Anthem HQ and the excitement is building. Code Anthem is going to change the way developers are hired, for the better. Get ready.
Posted in Developer Skills | 4 Comments »
April 21st, 2010
 The software industry is sinking. Software projects fail at a ridiculously high rate. Software developers are miserable in their cubicles . Companies are applying more and more duct tape in vain. Something’s gotta give.
In a 2009 industry study of software projects, 44% were challenged which are late, over budget, and/or with less than the required features and functions and 24% failed which are canceled prior to completion or delivered and never used. 24% of software projects, which represents billions of dollars and thousands of hours of time, were scrapped completely.
If the recent financial crises have taught us anything, it’s that the software industry is neither too big nor too important to fail.
Business are putting more pressure on ill-equipped development teams to deliver software full steam ahead. Meanwhile, developers are being weighed down by company-imposed anchors.
Development gets delayed by endless meetings where people drone on and on. Then there are more meetings where we all discuss why development is delayed. And no one is really interested in building good, useful software. Is this what you signed up for?
Does fun development really need to only happen on the side? On open source projects, or moonlighting projects?
With so very many smart people on the job, how did we let this gloom and doom scenario happen?
Our first mistake was to ever let non-technical people manage software projects.
Our second mistake was to let non-technical people manage the hiring of technical people.
We need a coder revolution. A grassroots movement to put smart technical people at the head of software projects and to fill up the team with other smart technical people.
This is a call to arms to all of my skilled and productive developers. Developers who have passion for their craft and are willing to fight to make it better.
We’ve waited a long time for the big companies to come to their senses, but it’s not going to happen. Those bloated corporations are too large to see their own feet, much less walk around. And the smaller companies who should know better are just angling to be a big bloated corporation.
We have to make this happen ourselves.
- Business jargon and marketing speak only impede successful software building. Let’s cut it out.
- Clueless non-technical managers have no idea what it takes to build great software. Let’s do it ourselves.
- Buzzword-riddled resumes are a preposterous way to identify skilled developers. Let’s find a better way.
- Recruiters don’t add any value to the hiring process for computer programmers. Let’s go direct.
- Talking about building software does not indicate any technical ability. Let’s show what we can do.
Posted in Software Building | 10 Comments »
April 20th, 2010
Recruiters are a bane to the software development profession.
Finding good developers is extremely valuable to companies. The problem is that recruiters can’t even get that right. Even if they could, they’re so abominable to deal with that developers are scrambling for any other option.
In my professional career I’ve probably spoken to hundreds of recruiters, not even counting the spammy emails and unsolicited phone calls I ignore.
Pretty much any developer who’s been in this game for any period of time knows what I’m talking about:
All they do is take up posting space on the job boards, alongside real companies postings that are actually interesting.
In the trenches
Take this little gem from a contractor who had promised 4 weeks notice to his current employer:
“Couldn’t you just walk out?”
“Despite the fact I gave my word about a notice period?”
“Yeah, you’re a contractor, you could just walk out.”
“So you’re suggesting that I should start my professional relationship with you by doing something really unprofessional to someone else?”
“Well, yeah.”
Usually I don’t allot much time to recruiters, but in one instance I met one for coffee based on the recommendation of a friend. After discussing my work with C#, ASP .NET (along with a myriad of other Microsoft technologies), she checked her handwritten list and asked “So, have you worked with Visual Studio before?”. I replied “Um, yes. Well, usually when you use C#, it’s with Visual Studio…” She said, “Ok great,” and checked it off the list before offering, “You know, you should really put ‘Visual Studio’ on your resume. You know, just to highlight all of the different technologies you’ve worked with.” I could only nod along quietly, “Sure, right…”
Then she suggested that I take the job she was working on that would be a 20% pay cut AND be contract instead of full-time with benefits. She said, “Well, you know, sometimes it’s worthwhile to take a job for less money at a good company working for a good manager – someone you could learn a lot from.” I said “Oh, so what do you know about this company?” She then told me that she did not actually know anything about this company or manager since it was not her account, but maybe she could find out, if I was interested.
Wait, so I should consider a huge pay cut and loss of benefits because of a great manager, which you have no idea if you even have?
Something smells fishy
In their defense, some of them seem to have noticed a problem. Here, one recruiter claims that the profession was originally “to both find and court the ideal candidates for our clients.” but admits that they’ve wallowed into a position where “sourcing” (ie. finding) a candidate is their bread and butter. He goes on to say:
“Gone will be the days when finding the candidate somehow filled a gap in the recruiter job description – technology will take care of that.”
Indeed.
Says another recruiter:
Recruiters need to become experts in selecting candidates, they need to be better than the client at predicting which candidate will succeed in each role in each company.
Except how could they be? When the biggest problem companies face is finding skilled developers, how could a non-technical person ever tell whether someone was qualified?
No really, I’m asking.
I understand why candidates continue to talk to recruiters. As painful as it is, sometimes a position is only open through them. But why would a company want to pay exorbitant amounts of money (something like 10-30% of the annual salary) just to be put in contact with someone they got off Craigslist? Whose naked pictures do they have?
Posted in Hiring Programmers | 17 Comments »
April 19th, 2010
 This post is based on a true story and also the book Alexander and the Terrible, Horrible, No Good, Very Bad Day (affiliate link) which is a classic kids storybook and current favorite for bedtime at our house. The interspersed quotes are from the book.
In my last semester of college, I had a good offer from a company I liked that I was poised to accept. Then Microsoft called and wanted me to fly up for an interview based on an on-campus interview that I had with them. Being a southern girl with family and a fiance firmly planted in Texas, there was very little reason I would want to move up to Seattle … but still, it was Microsoft. So I arranged to fly out late that Thursday night, after I was done with work and classes, in order to be done in time for my main offer’s acceptance deadline.
“I went to sleep with gum in my mouth and now there’s gum in my hair and when I got out of bed this morning I tripped on the skateboard and by mistake I dropped my sweater in the sink while the water was running and I could tell it was going to be a terrible, horrible, no good, very bad day.”
I am one of those people who not only does very poorly on little sleep but also does not drink coffee (possibly related?). So I woke up the morning of the interview running a tad late (typical) and very very tired from having gotten in so late the night before. It was still dark outside and rainy and I had to drive this monstrous Chevy Suburban (that was all they had and I’d never driven one before) on the slick streets.
After a brief meeting with the HR/recruiting person, they had me go on a coffee meetup with someone from my school. We went to one of the Starbucks kiosks inside the buildings and (since I don’t do coffee and it was chilly) ordered a hot chocolate. We chatted and I got about half-way through the hot chocolate before I realized it had a funny taste to it. Another sip confirmed – I think it had bad milk (or something) in it. Yuck, and uh oh.
My bath was too hot, I got soap in my eyes, my marble went down the drain, and I had to wear my railroad-train pajamas. I hate my railroad-train pajamas.
Then we started the actual interviews. First I got some questions about writing the code to sum up the numbers in an array or something like that. Then I got this gem: “Let’s say you were tasked with designing parking meters – how would you do it?”. Of course I know what they are, but I’ve never used them before. Seriously, I live in Texas, we have space enough for parking lots. So, guessing what it would be like to use them … think think. Uh… well, requiring the use of coins is probably a deal-breaker for many prospective parkers, so I would allow the use of dollar bills… and then I sort of fizzed out after that.
The next day, when I visited Pike’s Point, I saw that the parking meters in Seattle are actually 1 per block (instead of 1 every car or 2 cars) and they accept credit cards and have touch screens. Never seen that before or realized it could ever be cost-effective. I even had the thought “accept credit cards?” flit through my mind and figured, no way. Wow, clearly we were operating from a totally different starting point on what is possible. So of course then I had a million ideas, but too late.
But then again, that sort of design overkill is exactly what Microsoft is known for, and exactly the kind of over-engineering that I eschew in my development. Aside from bugs in functionality, I have no issues with the way that parking meters work. If it’s not broken, don’t fix it. Microsoft does not agree, apparently.
So then we went to the shoe store to buy some sneakers. Anthony chose white ones with blue stripes. Nick chose red ones with white stripes. I chose blue ones with red stripes but then the shoe man said, We’re all sold out. They made me buy plain old white ones, but they can’t make me wear them.
Somehow, out of the marketing-esque descriptions on the brochure they handed me 2 minutes before my on-campus interview, I had selected that I wanted to be a “Program Manager”. During each of my 5 interviews, the person would explain that a program manager is someone who does not really write code, but rather encourages the engineer who writes code to do it well, but has no real power at all. They all emphasized this. This ability to influence the engineer to make something that the customer would want and to do it on a reasonable schedule, but have no real ability to affect change at all.
They would state this and then ask, “Does that sound ok?”. “NO it doesn’t!” I want to write code. I don’t want to be an influencer on the coder. But there I was stuck in a whole day of interviewing for a position I did NOT WANT. So I said, “Sure, … ” and then followed up with some lame example of how I worked in a team and influenced some positive outcome. Even I didn’t believe me.
“It was a terrible, horrible, no good, very bad day.”
Around the second interview, my stomach started to grumble. And then gurgle. And then gargle. And then we moved to full on cramping. That damn hot chocolate. In the 10 minute break between interviews (that included walking/drive time between buildings) I would run to the bathroom to do unseemly things. I think my face looked green. I did not feel good! But the day just went on like some horrible Microsoft gauntlet of runny poo (sorry).
There were lima beans for dinner and I hate limas.
There was kissing on TV and I hate kissing.
When it was finally over, I felt no (ok, a little) hope but a whole lot of relief. They had already setup a dinner with two program managers that evening. They explained that I should definitely go to Pike’s Place because, among other things, the original Starbucks was there (insert feigned excitement).
They took me to a very stuffy restaurant that is one of their “favorites” where the menu is a single page and everything has weird ingredients and I was way underdressed. The waiters all wore black and white and had towels draped over their arms and I just wanted to sleep. I was too tired to talk much but I don’t think the program managers noticed. They were very happy to converse with each other about how great they both were and laugh about people working for companies other than Microsoft.
At some point one of them asked if I liked sushi and I said I did. Then he commented that they would not touch sushi that was made in Texas. They thought it was hilarious.
“Some days are like that… Even in Australia.”
So, no I did not get the job. And no, I don’t think I would make a good “Program Manager”. And no, I don’t think I fit in Seattle or anyplace where they consider food in entire regions of the country to be laughable. And in case you’re wondering, the original Starbucks looks like all the other Starbucks except there is a plaque and a longer line.
I accepted my other offer doing actual software development, at the company that took me out to PF Chang’s and again for pool and some drinks, and lived happily ever after.
Posted in Developer Interviews | 14 Comments »
April 15th, 2010
The less the median developer on a software project team is paid, the more the project will cost to complete.
Traditional business wisdom states that paying less for a developer results in a cheaper project cost overall. So companies lower salaries, cut bonuses, and outsource for cheaper labor.
Except the less money you pay, the less skilled and motivated the worker. Sure they bang away at the keyboard for less money per hour, but will they produce high-quality, clean, concise code? Will a cheap developer have the skill or the motivation to find an elegant and simple solution to a complex business problem? Experience says not.
When you try to turn real people’s passion into interchangeable “man hours”, then what you end up with is a guy banging on a keyboard, not great software.
Posted in Programmer Pay | 15 Comments »
April 13th, 2010
Heard this before?
Old programmers are out-dated and outmoded. All they want to do is program in Cobol and they don’t know anything about modern technologies, as in, ones from this decade. It takes them half a day to write an email, the other half is spent checking stocks. And yet, they get more money and higher positions just because they are older.
Or this?
Young programmers are immature and think they know everything, but they don’t know anything. They think that just because they wrote little programs in college, that they know how to build complex business software better than me. They’re always telling me what to do, as if I wasn’t once bright-eyed and bushy tailed myself, but now I use my experience to work smarter.
Yes, I went there.
The Self-Esteem Police would say that’s not nice and we shouldn’t talk about that and gee gosh, can’t we all just get along? Here at Code Anthem, we’re pro reality so we’re talking about it.
The reality is that there are crappy developers of all ages. And good ones of all ages, too.
We know that and that’s why “education” is not a solution. We can’t teach people “all old programmers aren’t outdated” and “all young programmers aren’t ignorant” because we know that already. We’re jaded, not stupid.
These generalizations are clearly not true all of the time, but it’s true often and that’s why the generalization sticks around.
People my age often don’t ask the fundamental questions. When people say things to me, I actually check every one of them. I would encourage you to challenge every assumption. – Eric Schmidt, CEO of Google on TechCrunch
For every one older programmer talking about Ruby and Git there’s several more spouting incomprehensible business-babble or hacking together some monstrosity with a billion LOC. For every bright and productive young programmer, there’s several more yammering away about the latest acronyms and Web 2.0 and have no idea how to make useful software. The generalization is there because it’s often true.
The solution is not to cower from the reality of the situation but to face it head-on.
You can become a student and explorer at any age. If you count us older folks out this time, I think you’ll be disappointed to find out that some of us really do get it and have the energy and ambition to create great software. – Dave Winer, Scripting News from Java is a Brand
At whatever age you are, what can you do to provide more value to your business with better technology and better ideas?
Innovation + Usefulness
Inspiration + Experience
Creativity + Application
That is how programmers can come together.
Tags: Programming Skills
Posted in Developer Skills | 14 Comments »
|
They say they want to make more money, but are content to live with failed software projects, poor programmer productivity and operate on software that isn’t fit to be used.