The guys involved with Play! released 1.0 earlier this month, so I bundled up a OSX installer to place the commands in convenient places for mac users.

Check it out here:

http://driftlogic.net/play_framework

Most job ads tend to take the same format, who they are, what they’re looking for, what you’ll get in exchange. Those are the basics of posting a want, the three W’s: What we want, what you want, what they want. The better companies have shorter ads and general statements about technology (See: Freshbooks). Bad ads have long descriptions and very specific technical requirements (See: Just about any posting on Workopolis). Then, there are special cases of really bad ads, lets call these the star ads.

What’s really nice about douchey ads is they’re dead easy to spot. They usually include the words ‘rockstar’ or ‘ninja’ and have code placed somewhere in a prominent location. All code job ads are particular turnoffs (see: a crappy ruby ad). Ads that include code are generally self defeating, and potentially backfire if written poorly (do you really want to show that you can’t write code to begin with?). Most developers can read through a code post in C Syntax and pick out the important bits. Okay, you’re looking for ruby. Right, you were on the Today Show (so were these guys). Really, who doesn’t think that they’re a smart, highly productive, curious, driven, team player?

I get the concept of trying to challenge people in your job ads. Employers are trying to stand out just as much as job seekers in attracting talent, but ads like this don’t show the potential that the kind of workers they attempt to attract desire: Opportunity. Ambitious and curious employees want the opportunity to rise above or explore technologies and opportunities. Things like book allowances, conference reimbursement, and paid time for personal development go further than your smartly typed ad (this blog posting by 37 signals gives me employee stiffies every time I read it). Not because of the job perks, but because they show a culture of personal and professional growth within the company.

There’s also a special kind of job ad that serves as not only a total turn off for applications, but about the company as a whole. Lets call these, the challenge ads. Challenge ads think that they’re smarter than they really are and include a unique kind of hubris reserved for ‘rockstar ninja hackers’. Case in point found here.

From the job ad alone, they’re looking for a ‘Hardcore PHP’ developer. If that means that I fall asleep to postings by Rasmus and wake up chewing through extension code, then I guess that’s not me. I think developers should have broad interests, and I’m not alone.  There are some other general turn offs to this ad, from the massive, unattractive logo pushing the job description below the fold on every normal human resolution, to the biz speak description of the developer team. But the real winner in this ad is the method for application.

If you think that you ‘have what it takes’ to become a ‘Hardcore PHP’ developer, you’re directed to http://proveyourworth.net. Defying anticipation, the site is as big a turn off as it sounds. A large ninja graphic and XKCD comic set the tone of what’s to come. I’m not going to go through the ‘challenge’ presented, but effectively, you’ll be bouncing back and forth through URLs reading source and opening up firebug to look at request headers in a challenge worthy of level zero in The Python Challenge.

Sites like this do nothing to make accomplished developers want to join your company. If anything, you should treat developers in the same way as anyone who might be viewing your site. They’ve come with a task in mind, the faster you fulfill that task, the sooner they’ll be encouraged to get in touch about working for you. If you’re asking someone to buy into your companies vision, show them what that vision is, why they should be a part of it, and what rewards are there for people who decided help you get there.

(BTW: Web development already has a set of Rockstars, and 37 signals got there first.)

A few months ago I started looking around at the JVM alternative languages, Clojure, Groovy, the J’s (jython, jruby, ect.) and eventually Scala. I have somewhat of a classical computer science background. I started at a Java school, then moved over to a college that taught C in it’s first year courses. When I found my first job after school, I started developing in PHP and for good or bad that’s what I’ve been doing the last 4 years or so.

I like PHP. It’s everything and the kitchen sink mentality makes developers tend toward hodge podge code mostly, but there can be some really beautiful creations when you start using PHP version of reflection. But ever since I started working with Java again for projects at work, PHP feels like it’s missing the power of a systems language. Having to bolt on opcode cachers to deal with compiled code and the tacked on nature of using php as a command line language felt somewhat odd. Using pure Java is always an option, and Sun has done a good job of keeping the JVM up to date with new features and enhancements, but after enjoying the lose structure of a scripting language, it’s hard to go back to verbose development.

That’s where Scala comes in. David talks about how it’s somewhat difficult getting Java programmers to switch to something functional, and maybe that’s true. I don’t think that hard core Java programmers are Scala’s potential audience. Those crazy scripting guys from Ruby, Python, and PHP will feel right at home with Scala’s half functional / half object-oriented syntax. They’ve been dealing with choice and somewhat functional constructs for years, show these guys that you won’t need to start redeveloping in a another language when your app approaches a certain level of success and you’ll get them hooked.

Couple that with the hack that is Comet becoming the norm for web based apps that need push notifications and Scala’s actors become really attractive.

Stahl left Coke in 2002 to become the president of cosmetics giant Revlon. Jack was known for his marketing savvy and operational disipline according to the article, but ultimately failed in attempting to market the Revlon brand and left in 2006. “He didn’t know what he didn’t know” defines Jack Stahl’s leadership according to one quote from the article. That concept of knowing what you don’t is one of the keys of being a software developer. It’s one of the keys of being any kind of engineer.

Being an effective developer is even more than knowing what you don’t; it’s about knowing what is possible. Being in touch with what other people are doing, what technologies are evolving, how they’re evolving and seeing how others are applying them gives you an even larger set of ideas to draw from when given a task. Some consider personal development to be learning a new language or approach, but in reality need to embracing the concept of daily learning.

Daily learning for software developers is simply keeping up to date. Reading sites like Hacker News or Reddit Programming in addition to the blogs of notable developers, then taking that next step after reading about a startup or creation by finding out how it was done. In cases where the implementation isn’t available, take that problem and find out what kinds of tools are available to construct a solution.

I spend hours each week looking at open source projects, software libraries, methodologies, and ideas. Each one that I read about gives me new ways to implement projects I’m working on now and a chance to think about how I could have done things differently with things I’ve worked with in the past. It’s not required to fully understand how to implement those solutions, but if at some point you run across a problem where that tool would be easier and more effective to utilize than reinventing the wheel, you’ll know where to find it.

Knowing what’s possible is why developers need to communicate. Through personal blogs, comments, and conferences, we share our ideas along with our code. Those ideas are always portable even if the language is not. The very first time I saw anything about AJAX was at a PHP conference and at the time, I had no idea it was even possible. It changed my view about where web development was going. When I first saw someone demonstrate the concept, I had no idea how it could be implemented, but the idea was amazing. From that experience, I learned it was possible, and started to leverage the concept in designs as I learned about the implementation.

Developers tend to think of languages and processes as tools within their toolbox. Knowing what’s possible is like having an even larger selection of tools hanging in the garage, you might never need them, but you know where to find them if you do.