A couple of weeks ago I was having an informal discussion at work about another developer’s performance on a project. The developer had strayed from company convention and in his eyes had used many ‘best practices’ to improve things.

However, despite his best interests, the implementation was not only detrimental from a maintenance perspective (having increased the cognitive load for other developers by breaking from ‘the norm’) but also from a technical standpoint it was ‘best practice’ mis-used.

This was an unfortunate predicament but far from unique. A combination of inexperience and programmer’s ego had lead him to re-invent the wheel. Development time had doubled due to re-writing existing code (that worked).

I didn’t write this post to bash this developer as I’ve stood in his shoes on more than one occasion and re-written tried and tested code because I could make it ‘better’. The mentality of good developers is to do things right, not provide short cuts for convenience.

“I could use less code to do the same thing more efficiently and make it more cohesive, great!”

I thought to myself, so I did… it was fun; I was learning, getting to try out all my new found knowledge but it took me twice as long (at least) to fix bugs and implement new features as I re-invented the code base, byte at a time.

Fast forward to the present, when reflecting on this conversation I realised I still shared many of the same ideals as said developer. The key difference experience has taught me is to leave my experimentation at home and try not to bring it to work unless I’m confident that a solution that looks great in theory is also great solution in practice. Don’t make work your play ground.

Not being the developer in question and observing another’s work provided me with a different perspective. It allowed me to see how dissolved we developers can become with the problem and not see the bigger picture – we’re there to help run a business.

I find this both motivating and depressing. Motivating because of the responsibility and opportunity to produce a great product, on the flip side depressing because I’m not sure commercial programming still leaves room for what attracted me to programming in the first place… fun and freedom for creativity on the job.

I think the fun factor that every programmer feels when they first start or learn a new way of doing something will always be on a rocky road of high and lows. Gaining experience means those highs are spaced further apart.

Merry Christmas!

Update: I know it should be satisfaction minus minus but Wordpress thinks otherwise! (dammit, it won’t even let me write it in this post)

It’s hard to drag a community the size of PHP’s towards such things as standards and using frameworks. From my experience many PHP developers still struggle/refuse to adopt others standards.

When I started PHP, PEAR didn’t exist, and even when it did (and probably even today) much of community is used to “rolling their own” solutions for 99% of tasks. Most developers I’ve worked with don’t trust/use PEAR classes and I can’t really blame them. Most early efforts were authored by developers who at the time didn’t really grasp the OO concept and made god classes.

The Ruby community has one up here, their community was kick started by Rails – many good programming practices have been spoon fed from the start. Couple this with Ruby probably not being many Ruby-newbies first language. I digress…

In every company I’ve worked at code re-use has been low because “every problem is different”. Now this isn’t normally true, the nucleus of the project is but the rest is made up of much of the same stuff tackled on every project (database abstraction, session management, form validation, data sanitisation, the list goes on…).

What holds the PHP community back from adopting frameworks and standards is the majority of the community’s obsession of prematurely optimising the mundane (++$i vs $i++ in loops etc). Just check the comments in the manual on language basics, or most forums – how long has the single vs double quote debate been running?

I’ve read threads about removing white space and pre-processing include/require statements to speed up execution. Neither of these would address the true bottleneck in an application.

Only in circumstances where the coding has been exceptionally poor has PHP ever been a bottleneck on the sites I’ve worked on, 99% of the time it’s the database that you’ll run up against before seeing any PHP performance issues. This obession with squeezing performance before a performance issue has been identified scares most developers off the idea of using a “bloaty” framework that’s too heavy weight for their needs and instead they go back to re-inventing the wheel again.

When the larger community becomes seasoned enough and recognises the biggest bottleneck is developer time and not double quotes then hopefully we’ll see some proper standards materialise.