Cody Powell (@codypo) is the cofounder and CTO of Famigo. Famigo's main offering is a cross-platform recommendation engine for mobile content, helping families find things like the best android apps, best iPad apps, and free apps. He's a graduate of Trinity University, an ardent supporter of the Texas Rangers, and he makes a mean mojito. Cody is a DZone MVB and is not an employee of DZone and has posted 26 posts at DZone. You can read more from them at their website. View Full User Profile

8 Questions To Identify A Lame Programming Job

02.13.2012
| 21291 views |
  • submit to reddit
We all know and love the Joel Test, Joel Spolsky's quick quiz to determine the quality of a software team.  If you're searching for a job, it's a great idea to run potential employers through the Joel Test.
There's a problem with it, though.  Well, there are multiple problems.  First, who the hell cares about hallway usability testing?  Second, you're only checking for the good qualities of a team.  What about the horrendously bad qualities that will eventually drive you towards both insanity and a crippling dependency on cough syrup?  10106989_0579f7be13.jpgWe need something like the Joel Test to measure the potential crappiness of a job, or else each of us might stumble into becoming Milton Waddams.
Ladies and gentlemen, I present to you the Codypo Test, aka 8 Questions To Identify A Lame Programming Job.  If you are in an interview, you give the company the Codypo test, and the job scores more than a 1 or 2, you need to pull the fire alarm and get the hell out of there.

1.  Would I be paid below market rates?
If they're looking for 10 years of hardcore, multithreaded C++ experience and they're offering 48k, these people have lost their minds.  Expect this sort of delusional thinking to appear in everything they do.



2.  Would I always be on call?
No one likes being on call, because as soon as you're on call, someone is going to page you at 3 AM on a Sunday because the Reset button on the support portal is a different shade of blue than they're expecting.  Occasional on call stints are both understandable and tolerable, but 24/7 is for doctors and exorcists.



3.  Am I the IT staff?
You are a programmer.  You make software.  You are happy to support your software.  garfield_1.gifThis does not, however, mean you are a computational master of the universe, and just the guy to ask why the receptionist's laptop got all weird after she installed that Garfield screensaver.



4.  Would I work with a single monitor?
It's no longer 1998.  We don't have to stare at a single 17" boat anchor all day while rocking out to Smashmouth. You can buy huge, thin LCDs for $100 each.  If doubling your productivity isn't worth $200 to this company, then this company may just be a really elaborate practical joke played by an eccentric billionaire.



5.  Will I be maintaining any ancient system, and what's it written in?
If you dig deep, you may hear, "Yeah, we're going to get into Ruby on Rails, but first, we'll need you to bust out some VB 4."  It is never, ever that easy.  
That VB 4 system will refuse to die, just like Rasputin.



6.  Would my internet usage filtered or monitored?
Programmers solve problems, and to solve problems effectively, you need resources.  The internet is the single greatest usage available.  Any company that refuses to accept that and blocks you from Usenet/ Google/Stack Overflow/whatever is treating like you a child/deranged porn fiend.



rasputin.a.gif7.  Would I be the only programmer?
More than anything else, I have grown as a programmer thanks to my peers.  We answer each others' questions, we review each others' code, we whiteboard together, and we come up with creative insults when somebody breaks the build.  If it's just you, you're not going to get any technical feedback and you're not going to get any better.  Also, you'll only be able to insult yourself when you break the build, which might get you reported to HR.



8.  Am I expected to travel every week?
A bit of travel is necessary from time to time, particularly for face to face meetings with customers or offsite colleagues.  However, expecting you to leave your home every farging week is absurd.  We have the internet now; it allows us to communicate virtually.  Let's use that instead of me becoming BFF with the night receptionist at the Best Western.




I think those 8 questions constitute a good sanity test for a potential job.  Sure, there are valid reasons for a job to score a 1 (eg, you might be the IT Staff or on call all the time at a startup).  However, once you get past one Yes to these questions, it's time to leave the interview through any means necessary, including faking a heart attack.
No matter how great the potential projects and teammates might be, I don't think you can do truly meaningful work in an environment where you, the developer, aren't empowered to succeed.  If a company doesn't get that, then they don't get software.


Source:  http://www.codypowell.com/taods/2009/12/the-codypo-test-aka-8-questions-to-identify-a-lame-programming-job.html
Published at DZone with permission of Cody Powell, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Alex(JAlexoid) ... replied on Mon, 2012/02/13 - 6:58am

You can throw out the #8 as meqaningless if you will work in the consulting arm of the business... Even if you are a developer there.

There are a lot of circumstances where weekly travel is essential.

Jonathan Fisher replied on Mon, 2012/02/13 - 10:28am

>>Will I be maintaining any ancient system

 If that's your attitude towards existing code, I would never ever hire anyone like you, simply because you YOURSELF are the cause of many poor programming decisions. 'Legacy systems' are caused by inexperienced programmers acting like drama queens. You get these people in your organization that insist that your architecture sucks because it isn't written in Scala and uses MongoDB, yet you can't trust them to do even the simplest of maintenance tasks correctly. These type of people should be stamped as inexperienced and non-hirable with the understanding that the massive technical debt they introduce will cause your business to buckle like Greece's economy.

 You can learn a lot from legacy code in two ways: What to do/What not to do. Don't be an elitist, you don't know everything and you shouldn't act like you do. (So says the man who wrote a Java <--> COBOL bridge for his last job, and had an absolute blast doing it. Who would have known that COBOL was using a NoSQL called ADABAS database back in the 1980's? Hmm)

Collings Jim replied on Mon, 2012/02/13 - 10:32am

I had a CTO pressure me to express "confidence" in my work. She wanted, for example, for me to say that I could "rip out HTML/Java etc.". Of course, engineering isn't like that for all kinds of reasons I can think of. First we do design for example, so immediately there's no reckless "ripping" of anything. There will be unpredicted problems along the way, of course. Lastly I don't believe in confidence because it is such a poor substitute for evidence. If we want to have a good idea of how fast we can produce some particular piece of the project, there should be some statistical history maintained for this purpose. When you ask a developer to predict "How fast can you get X done?", you make sure he/she does so with that evidence in hand so all they have to do is account for problems and complexities that didn't exist in previous endeavors. Sounds like a lot of work but it's actually hardly any work at all. Your bug database has most of the evidence already and what ever system you use for assigning tasks. I prefer it when these are one and the same which is to say that when I am assigned a task, I like to start by writing a bug that says, "Feature X as noted in System Y not yet implemented." Then I write out my complete understanding of what Feature X is so that it can be known exactly when I knew A about sub-feature B. Another question I always like to ask is, "What CPU do most of your development machines run on?" This one question has been very telling. If it's something you can't buy these days, pass immediately. Here is another one: "On average, how many mid-sprint changes do you have?". This one tells you about the customer and whether or not the team's sprints are short enough. "Describe the last deployment you took part in." is another one.

Collings Jim replied on Mon, 2012/02/13 - 11:27am in response to: Jonathan Fisher

Negative, Ghost Rider, I disagree... Well, sort of. Evidently you are passionate about some bad experiences you've had and I empathize. ;-) 1. It depends on how legacy legacy is. "Huh? ADA? Punch cards? Really?" ;-) 2. It depends on whether or not you want to work for Google or AT&T. 3. It depends on what ACTUAL development model you are using. IMHO Waterfall with a surface layer of Scrum = something worse than either. This is to say that if you have projects that work great under Scrum, use those to sell Scrum to your customer but DON'T try to use Scrum if your customer won't also fully commit. 4. It depends on what you have agreed to be paid for. If this is what they told you it was at the interview, you do indeed need to shut up and sit down or without complaining, get a new gig. Yes, by all means advocate but don't obstruct. ;-) 5. It depends on how well those old systems are documented and at what level of complexity they exist. Well documented systems shouldn't be a problem. Of course, few older systems are well documented, so if they will not allow a research project to fix the docs, you have a problem. 6. It depends on whether they insist on "band-aids" or if they will allow you to build the proverbial Java/COBOL bridge. Often you get these shops that only want short term fixes for the legacy stuff and we know where that leads and what it implies about the entire system. ;-) 7. Etc. etc. etc. It always depends.

Andrew Thompson replied on Mon, 2012/02/13 - 1:53pm

"If that's your attitude towards existing code, I would never ever hire anyone like you, simply because you YOURSELF are the cause of many poor programming decisions. 'Legacy systems' are caused by inexperienced programmers acting like drama queens."

 

Generally I agree with the above sentiment.  But I do find that there is a corner case where a developer is hired expecting their job to be "Scala/MongoDB/FlavourOfTheMonth" and find that the real position is patchwork on an undocumented Perl app with strict instructions to "never touch this part of the code.  there be bears".  Which there's nothing wrong with - but the actual job doesn't match to what the developer accepted the position based on.

Vadim Horban replied on Mon, 2012/02/13 - 3:51pm

На данный момент компания поставляет Windows 7 для планшетов, а вот запуск операционной системы Windows 8 может очень сильно поменять расстановку сил на карте. http://novye-tehnolgy.blogspot.com/2012/02/netbook-navigator.html

Jonathan Fisher replied on Mon, 2012/02/13 - 5:27pm in response to: Collings Jim

Everyone likes to greenfield projects, but if you have a problem working on other people's code, you really ought to do some introspection. I learn most when I ask questions about why a particular choice was made. Programmers that immediately crap allover doing any sort of maintenance work do not belong in a role where they are designing a system from scratch.

Andrew Spencer replied on Thu, 2012/02/16 - 4:05am

Question 9. Do they use Clearcase?

 

Jeff Dickey replied on Sun, 2012/02/19 - 11:46am in response to: Andrew Spencer

Nobody uses ClearCase, just as nobody uses Windows XP. You, my friend, are the usee, the one who must make endless random modifications of workflow and blood sacrifice to unknowable pseudo-deities in order to maintain the appearance of making progress on a regular basis. (Accomplishing progress is impossible by design; it's a feature, not a bug.)

 Seriously, ClearCase is one of only two alleged source-control management systems that are automatic disqualifiers for any further interest in a position, and the serious evangelism of same by individuals or teams reporting to me will get an R. Lee Ermey-level extemporaneous rebuttal, at minimum.  I have seen roughly 20 projects in my career that were infested with ClearCase. None shipped on time, on budget, or to spec — pick any one.

 (Shudder

Kristy Sheppard replied on Wed, 2012/06/06 - 8:42am

I believe, a lame programmer's work is not that hard to identify, it shows itself, nevertheless, it was still interesting to read the article, some useful tips are included and I love the language on the whole.

 

http://pictureeditorfree.org

how to edit a picture

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.