Perl Shop Maturity Checklist: Technical Concerns

| 2 Comments

In the spirit of helping recruiters understand the Perl community better and how to identify a good Perl programmer, perhaps it's useful to discuss ways to identify a good Perl programming shop.

I see three aspects of maturity in any programming job: technical, cultural, and specific to the programming ecosystem.

These aren't rigorous guidelines. I'm not writing a purity test, and you don't have to answer all of these the same way I do to get a perfect score. (Why would you want a perfect score from me anyway? I run my own business and, while I'm available for contracting and consulting, I'm not currently looking for full-time work.)

Disclaimer aside, if you find yourself disagreeing with these questions (or if you've never considered them), your workplace may not be inviting to good programmers. Process for its own sake isn't interesting, but the ability to define what should happen when and who does what and how to resolve conflicts is vital to having a healthy business.

Let's start with the technical questions.

  • Do you use source control?
  • Do you stage deployments?
  • Do you have a defined process for deployment?
  • Do you have a defined process for rolling back a failed deployment?
  • Do you have code that "no one knows what it does"?
  • Do you have critical business code written more than five years ago that people are afraid to touch?
  • Do you have coding standards?
  • Does most of your code follow it?
  • Can you tell who wrote each piece of code by its style?
  • Do you have a standard technology stack?
  • Across multiple applications?
  • If some applications don't meet it, do you have plans to refactor them?
  • Do you refactor at all?
  • Do you have a defined process for handling bugs?
  • ... for handling feature requests?
  • ... for scheduling delivery?
  • Do you have a training or mentoring process?
  • Do you have multiple developers?
  • Can you retain developers for longer than one year? Five years?
  • Do you use automated tests?
  • Do your tests all pass?
  • ... before you check in?
  • ... before you deploy?
  • Do you have backups?
  • ... for servers?
  • ... for developer workstations?
  • ... and do you test them regularly?
  • Are developers their own system administrators?

In short, how predictable is your development process? Can you manage risk? Do you? When surprises happen, how much work is it to recover? The better your answers to these questions, the more likely that you can attract and retain talented developers—and make the most out of their abilities.

What other questions would you put in this list? Why?

If you'd like a detailed discussion of how to apply this list to your own company, I'm available for consulting.

(Next time: cultural questions.)

2 Comments

Recently I posted some tips for LinkedIn which as inspired by these Perl job related posts, of which there are some pertinent tips to go along with this post. http://rantage.com.au/item/My-LinkedIn-Strategy-for-Success/

---

Final advice...

When recruiters call, insist on their clients company name, salary range and full job description. Anything else is a time waster. Google is especially bad at this, they will waste days of your time then offer you pittance if at all. Also, lots of start-ups who think they are the next Google will do the same. Typically they will also provide free soda, install video games on cheap flat-screens and throw around a few bean bag chairs - then cut your salary offer by $10k. So avoid them and don't be afraid to decline job offers if you don't like the feel of the company. Soda is cheap and after work go sailing or something, don't hang around at work playing video games! When the company offers they will offer less than their maximum so counter offer for 5-10% more , its far easier to get this now than it will be to get a raise later.

Good points! It's so true, especially the Google recruiting nonsense.

Modern Perl: The Book

cover image for Modern Perl: the book

The best Perl Programmers read Modern Perl: The Book.

sponsored by the How to Make a Smoothie guide

Categories

Pages

About this Entry

This page contains a single entry by chromatic published on July 9, 2012 9:00 AM.

Testing Templates (or User Experience and the Seams of Architecture) was the previous entry in this blog.

Perl Shop Maturity Checklist: Social Concerns is the next entry in this blog.

Find recent content on the main index or look in the archives to find all content.


Powered by the Perl programming language

what is programming?