On the Laravel News site there's a new post that tries to answer the question "can you be a an expert developer in 10,000 hours?" This is based on some prior research (not specific to programming) that anyone can be an expert on anything in about 10 thousand hours worth of work and study on the subject. This post takes the ideas presented there and applies them to the world of development, trying to see if there's a good match.

Back in 1993, psychologists K. Anders Ericsson, Ralf Th. Krampe, and Clemens Tesch-Romer said that 10,000 hours of deliberate practice of a specific skill will make one an expert. Fast forward 15 years, and Malcolm Gladwell’s Outliers made the 10,000 hours rule famous. And in 2012, Macklemore solidified it’s fact status: it officially takes 10,000 hours to be an expert at anything.

How does this rule correlate to coding? If you’ve been working full time as a dev for five years, you’d be considered an expert by the parameters of the rule. [...] The problem with the 10,000 hours rule to excellence is that most domains aren’t static.

The article goes on to talk about the ever-changing world of technology (as compared to static activities where the rules aren't going to change). They talk about the Laravel framework and how it has evolved since beta/version 1 and how, if the 10k rule is applied, no one is an "expert" as it changes so fast. There's also a link to a study that debunked the 10k rule and so they shift to trying to answer another question: how much does it take to be just considered "good"? This is related back to software engineering and where in the process could it be that you move from "good" to "great".

Maybe the real question here is instead of trying to be an expert software developer, what aspects of your job can you improve in 20 hours of practice? Maybe the focus shouldn’t just be on the code; after all, your job is more than just staring at glowing screens all day. Identifying specific areas of weakness that you can devote time to strengthening every week may be the key to becoming that expert that you desire to be.

Shawn Stratton has an interesting new post to his blog about startups, working environments and a few ideas that could change things a good bit for the average developer's workplace.

I've come to several conclusions after making observations on several articles by successful founders, thinking back on the startups I've seen and interacted with, and seeing the common mistakes that have been made thus far in the businesses and projects I've been involved in and let me just state that it has been a most interesting journey.

He suggests a few things that could make up an "idea workspace" scenario including less (required) work hours and more time off, giving full benefits, promoting an open environment instead of a "cube farm" and the encouragement to always keep learning. He even suggests something that could help make it easier - replacing a lot of the usual means (like books and training courses) with a Kindle loaded and ready to go.

I'm hereby making an open call for people to argue with or contribute to my ideas, let's fix what's wrong with the current corporations and thereby making our economy and our lifestyles sick and dying.

Want to comment? Head over here and share your thoughts...

The symfony blog has announced a new initiative for developers using their framework to get involved in - creating a website for a cause. The first step? Identifying the causes:

This event will take on the basic structure of other 48 hour web application development competitions, such as Rails Rumble, but with a special twist unique to symfony. The applications we create during the course of the competition will be gifted to different socially-minded organizations around the world. Once the fun is over, our work will live on and hopefully do a lot of good.

Since the first step involves identifying the causes the sites will be created for, they've laid out a few guidelines to help you submit the cause of your choice.

On the Bakery (the CakePHP blog), there's a new case study on how a group of developers created a "Web 2.0 dating site in 66.5 hours" (just short of 3 days worth of work).

Let this be a testament to Web 2.0 and the effectiveness of rapid development frameworks: I built a full-featured dating website (http://mingle2.com), from concept to launch, in 66.5 hours. In a typical 9-5 job this would amount to about a week and a half. Deliverables included: the idea, planning, design, development, testing, and launch.

The study is broken up into the (long list of) key steps that were followed:

• Identify an Opportunity
• Brain-dump
• Generate ideas from your competition
• Brain-dump some more
• Have a specific goal, don't try to make the website do everything
• Keep. It. Simple. Stupid
• Minimize interference
• Avoid "feature creep"
• Web 2.0 names are going to be very tacky in a few years
• If you get stuck on something, put it on the backburner
• Prioritize features so you can give prominent real estate to those that need it
• Put a lot of work into the functional mockups
• Mix it up, keep things interesting

And finally, "The Design" where he looked at achieving balance, got a "holy crap, that's pretty" reaction, and to make things look up to date. The end result of the labor is mingle2.com, a 100% free online dating website.

On the Bakery (the CakePHP blog), there's a new case study on how a group of developers created a "Web 2.0 dating site in 66.5 hours" (just short of 3 days worth of work).

Let this be a testament to Web 2.0 and the effectiveness of rapid development frameworks: I built a full-featured dating website (http://mingle2.com), from concept to launch, in 66.5 hours. In a typical 9-5 job this would amount to about a week and a half. Deliverables included: the idea, planning, design, development, testing, and launch.

The study is broken up into the (long list of) key steps that were followed:

• Identify an Opportunity
• Brain-dump
• Generate ideas from your competition
• Brain-dump some more
• Have a specific goal, don't try to make the website do everything
• Keep. It. Simple. Stupid
• Minimize interference
• Avoid "feature creep"
• Web 2.0 names are going to be very tacky in a few years
• If you get stuck on something, put it on the backburner
• Prioritize features so you can give prominent real estate to those that need it
• Put a lot of work into the functional mockups
• Mix it up, keep things interesting

And finally, "The Design" where he looked at achieving balance, got a "holy crap, that's pretty" reaction, and to make things look up to date. The end result of the labor is mingle2.com, a 100% free online dating website.