Archive for the 'Software' Category

Stop Seeking Out the Ninjas, Hackers, and Rockstars: How to Write Better Developer Job Descriptions

Friday, April 2nd, 2010

This post is for all the recruiters, hiring managers, and human resource professionals hiring developers today. At some point, someone decided that it would be cool or differentiating to post job listings asking for Rails Ninjas, Front End Hackers and Rockstar Web Developers. It’s an unfortunate practice to get your job advertisement noticed, and I urge you to stop.

For developers, words and names are important. From my personal perspective, here’s what these titles say:

  • Rails Ninja – You want me to creep around the codebase late at night and inject transient bugs to foil my developer nemesis? Should I do everything on my own, or do I have an exclusive ninja clan that I hang out with? You want me to do everything my way, or the way that’s been handed down to me from centuries ago? So, basically, you want a lone wolf that goes about their business without any collaboration or direct engagement?
  • Front End Hacker – Hacker? To hack a frontend project immediately resonates as short term fixes and solutions that aren’t elegant or user friendly. If you want to recruit hackers to do any type of coding beyond security and vulnerability detection, you’re in the wrong business.
  • Rockstar Web Developer – This is probably the most prevalent and astonishing of titles – do you really want what this stereotype personifies working in your organization? I immediately associate this with someone that’s arrogant, self-serving, and apathetic. Besides, how effective can you be at solving problems at 9AM when you’ve been up until 4 the night before partying like a ‘Rock Star’? Please.

Some of these questions or perceptions may seem silly, but like I said, words matter. Stop using these titles! What value does this add to your job posting? What does it convey about how you perceive developers? Developers want to be respected and appreciated, not trivialized. Developers want to be understood and stimulated. Here’s three better titles that I guarantee will yield a better candidate pool:

  • Pragmatic Programmers – (Note: this book is required reading for developers and anyone hiring developers) – Don’t you want to hire problem solvers? The best developers solve business problems with the simplest solution possible. They have a demonstrated history of making things work, and shipping. That’s what pragmatic programmers do.
  • Motivated, Lifelong Learners – Technology changes. New platforms arise, and new languages and frameworks emerge. For the best developers, the technology doesn’t matter. As mentioned above, developers are problem solvers first and programmers second. Finding the best talent is all about finding people that can identify the best tools to solve problems, and they’re unintimidated when it comes to learning and evaluating them. These individuals are typically well informed and love to read. In almost all cases, they thrive on learning new things, inside and out of their industry.
  • Social, Connected, Passionate Professionals – Books aren’t the only source of learning and discovery. For top notch developers, they realize the importance of community and engaging with peers. Exceptional talent will quickly get discouraged if they don’t have the challenge and stimulation of discourse with other stellar developers. Not to mention, connected individuals bring in more talent and great people. To solve problems, you have to communicate and collaborate. Sure, developers can tend to be introspective, but that doesn’t mean you shouldn’t like or connect with the people you work with.

Think about it from your own perspective for a moment. Can you picture yourself applying for a “CEO Rockstar”, “Recruitment Chef”, or “CTO Samurai” position? So, stop using silly titles. It only distinguishes you as someone who doesn’t regard software development as the art and science that it is.

A New Dynamic for Early Stage Product Development

Thursday, January 7th, 2010

The current system for developing conceptual applications is broken. Many early stage entrepreneurs clamor to find developers that can build their product on a tight budget so they can get it in front of venture of angel funds for further development and proof of concept. These entrepreneurs consistently seek out a pool of developers that are few and far between: those that are willing to work exclusively for equity. This search typically results in two unsuccessful outcomes. The entrepreneur encounters an incompetent team that fails to develop a quality product, or the entrepreneur becomes frustrated and abandons the project entirely.

Why Does This Suck?

As a developer, I love new and innovative concepts. As an entrepreneur, I love disruptive ideas that can change the landscape of business as we know it. How many of these ideas meet with either of the two fates above? In today’s world of abundant talent and money, why do good ideas die without a fair chance to prove themselves?

I meet early stage entrepreneurs with cool ideas all the time. I want to help them, but they very often can’t allocate the budget to turn their ideas into reality. What results is a chicken or egg problem: the entrepreneur needs a product to pitch for funding, and the product developer needs funds to develop the product. What ultimately results is a dead idea that was never given the chance to get off the ground.

And Now…For Something Completely Different

What if a term sheet wasn’t in dollars and cents, but in developer time? What if VC’s wrote two checks – one to the entrepreneur and one to a recommended product development firm?

There are many intelligent individuals that are emphasizing the importance of building great products. In my opinion, the best people to build products are those that have done it before. If that’s the case, then, how many first-time entrepreneurs know how to build a product? It’s my claim that it is an investor’s fiscal responsibility to ensure the entrepreneur is connected with the right resources to develop their product.

Ideas like TechStars, YCombinator, and small, localized incubators and organizations have done a ton for the online startup community. Good luck getting into an esteemed mentorship program like TechStars without a developer on your team, though. All of the people around these ideas recognize the need for sound, technical talent, but rely on the entrepreneur to supply it! It is my belief that the investors can provide entrepreneurs with this talent as part of their investment. Whether they staff engineers permanently or furnish a recommended list of vendors, I believe the investors are more qualified to discern between developers that can deliver results and the unfortunate bozos that pervade our industry.

Why This Works for Investors

I consider the investors I know to be wonderfully connected and resourceful. They usually have a demonstrated track record of building successful products and companies. If I’m a first time entrepreneur, why not rely on my investors to connect me with a team of capable and efficient developers? As an investor, wouldn’t I want to be connected to developers that can make my portfolio truly shine?

If you’re connected to the best and battle-hardened developers, that creates a lot of value for your firm. Having engineers at your disposal to assess the complexity and costs of doing business during due diligence would allow for investigators to help discern between the money pits and the lean, money-making machines. Additionally, having an elite team that can get the job done right and fiscally efficient would allow you to cheaply evaluate business concepts.

Why This Works for the Entrepreneur

To say it matter of factly, entrepreneurs without software development backgrounds simply do not know how to hire solid, technical talent. If investors are helping to recruit and screen candidates, that really can increase the efficacy of such crucial hires. Not to mention, investors can train and mentor entrepreneurs on what to look for in a sound, technical hire to sustain future growth.

When entrepreneurs get funding and can make hires, do they really know how to evaluate a potential engineering employee or contractor? Potentially, a seasoned entrepreneur with a product development background may have a list of contacts to reach out to when they become flush with cash. How many first-time entrepreneurs, however, waste valuable time and money on incompetent people that don’t bear any fruit for their clients?

In early stages, most business-oriented founders want to focus on strategic partnerships and sales, anyhow. While there’s an increasing and encouraging awareness of how important your first technical hire is, it’s not something a first-time founder is really equipped to do.

Why This Works for the Development Community

There are a lot of bad developers out there that sustain themselves on unsuspecting, first time ventures. In a world where investors help to build a sound framework for screening candidates, these bad apples fall out of our industry. This effectively would raise the bar for everyone in the field, which would make the most meritorious developers more valuable and respected. Good developers would no longer have to tolerate those that didn’t carry their weight because they simply wouldn’t be found on the same team together. This would result in higher job satisfaction and retention, in addition to better output and creativity.

Additionally, developers love new projects and business problems to solve. If the investment community could provide a capable and elite team with a continuous supply of cool concepts, I bet you’d have a happy team of developers.

The Grass is Always Greener

I’m not necessarily knocking the present state of affairs. I can certainly understand why investors don’t want to manage the hiring process to this extent, and why certain entrepreneurs would view this type of involvement as intrusive. My intent here, is to raise the point that investors usually have the know-how to assist entrepreneurs with their product development efforts, and that they should use that know-how to the benefit the value of their portfolio and benefactors.

That being said, there’s also the issue of observing how a team stands on its own, which is probably the strongest case against this model. The development team sponsored by the investor won’t always be there, so it would be important to recruit and phase in a technical cofounder at some point in the product’s development. An investor might not want to finance this endeavor, and they generally want to invest in a full-strength team from the onset.

In the end, we’re in unfamiliar territory. Perhaps all we need is a better way to match good developers with promising teams and ideas. Brain power and attention are becoming the scarcest of resources, and my desire is to create the most efficient economy to maximize the outlay of these resources. The idea, the founder’s passion, the developer’s capability, and the investor’s money are all necessary to create successful products, so let’s all work together to optimize what results.

Update: Nick Plante tipped me off to a company trying something like this named SproutBox.

It’s Not Just About Code – A Boston.rb Presentation

Wednesday, November 11th, 2009

Last night I spoke @ Boston.rb about everything that happens around code.

Lately, I’ve been heavily interested in discussing the process behind software development. Our field is still very young, and I think there’s a lot we can do to improve the way in which we do our jobs.

Slides are below. I described the talk this way: We spend so much time focusing on conventional programming. Everyone focuses on standards, code clarity, testing, and what gems to use. Let’s chat about what’s done before your fingers hit the keys. Let’s talk about brainstorming, requirements, stakeholders, mock-ups, and writing solid user stories and acceptance tests with Cucumber. Every project has a story – how will your next one end?

If you attended the talk, I would love your feedback at SpeakerRate

Friday’s Software Enlightenment #4 – Rumble Edition

Friday, August 28th, 2009

The 2009 Rails Rumble was a huge event! The results are simply stunning with great apps like Lowdown and hi.im. It really is amazing what can be built in 48 hours. If you get a chance, please head over, register and vote on the Rails Rumble Site

So without further ado, here’s some tools I found immensely useful in the creation of my rumble app. I’d really like to write a full post mortem, but in the spirit of Friday’s short list of links, here goes:

  • SearchLogic – excellent derived named scopes and search form capabilities.
  • AuthLogic – my favorite authentication system out their for Rails today.
  • Formtastic – a great utility for generating forms quickly.
  • Inherited_Resources – Jose has done an awesome job with this helper that handles your typical (and not so typical) RESTful controller actions
  • Stringex – useful for permalinking
  • under_construction – a handy javascript utility I’ve written to quickly note what design elements need to be implemented from a development standpoint.
  • serverjuice – Great for getting an Ubuntu VM up and running quickly
  • SpreadHead – although it required some adjustments in the way it handles routes, I really think this is a great way to get a quick CMS integrated with your site. It’s definitely useful to have some editable pieces of your application when there’s a code freeze in 48 hours. I currently use it for CMS partials (a way to have editable content inside a page), but I do not for individual pages themselves. There’s an issue in the gem version where the routes are added to the top of priority instead of the bottom. I’m hoping to help with a fix for this
  • tab_menu – I always seem to need tabs or a nice menu system, so I use this code pretty frequently
  • ThemeRoller – easily roll JQuery UI styling.

The combination of formtastic, searchlogic, and inherited_resources has really changed the way I code. I think a post on the power of these tools in combination with chronic

Some of these tools and more are available in the Enlightened Template I maintain on Github. There were some updates after the rumble. I hope you find it useful!

Focus on What Matters – Manage applications with Concentrate.app

Thursday, August 13th, 2009

concentrateapp.png

Do you find yourself checking your email when you should be coding? Reading Reddit while your test suite runs? Finally, comes an app that is off to a great start when it comes to focusing on the task you’re performing. Concentrate!

You can set up profiles based on the context of your action. My contexts are set up as follows:

Away

  • Sets Skype status to “Away”
  • Sets Adium status to “Away”

Blogging

  • Opens up MarsEdit
  • Opens up Things – I often track blogging ideas there
  • Closes my GMail Prism Instance
  • Closes Tweetie
  • Sets Adium status to Away as “Writing”
  • Sets Skype Status to Away

Code

Conference Call

  • Launches Google Calendar Prism Instance
  • Launches GMail Prism Instance
  • Launches Skype
  • Sets Adium status to Away as “On a Call”

GTD

Getting Things Done is a methodology for organizing tasks and projects. I practice it using the following workflow:

  • Opens Firefox
  • Opens Things.app
  • Opens VoodooPad – my personal wiki
  • Opens Jott in Firefox – when I’m on the road, I will call in actions as they pop into my head. Jott isn’t great at transcribing my messages but I can re-listen to them when I’m doing my weekly review, etc.
  • Opens my RescueTime Dashboard – I use this to analyze productivity and see what apps I’m using heavily

Marketing

  • Opens Firefox
  • Opens Gmail Prism Instance
  • Opens Tweetie
  • Sets Adium Status to “Away”
  • Opens Google Analytics in Firefox
  • Opens my Fat Free CRM instance in Firefox
  • Opens up the WWR Forums in Firefox

I will continue to refine this list and add to it. Having used it for over a week, I can say Concentrate.app has helped me become more efficient and focused when I need to switch contexts. There are some problems with it and Vimperator I think, but overall it has become a de facto tool. I hope you find it useful!