The other day I had read an interesting post by 37 Signals entitled Why We Don’t Hire Programmers Based On Puzzles, API Quizzes, Math Riddles or Other Parlor Tricks (say that 10 times fast). Then I was pointed to another article by C for Coding entitled Interview Programming Problems Done Right. That got me thinking about the interview techniques that I’ve used at my current and prior jobs. It’s a different style than either of those two posts, so I figured it was worth talking about.
I came across a rather interesting post yesterday entitled The MicroPHP Manifesto. The author made clever use of a very interesting analogy (drum players) to try to prove his point that less is more. The article makes a very interesting read, and I would suggest that everyone reads it. Go ahead. I’ll wait.
With that said, I have to disagree with the article rather vehemently. I think the message is somewhat right, but for all the wrong reasons. Let me try to explain:
One of the most frequent questions that I get asked is “How can I become a better developer?” I think that it’s a very good question to ask that deserves a good response. But how can you respond to something like that? Becoming a better developer depends so heavily on past experience (where to grow), interests and rationale (why do you want to grow), that it’s really hard to answer without a fair bit of discussion. This post reflects my experiences from both my own growth and the growth that I’ve seen in others.
Recently there has been a rather heated and intense discussion on whether the PSR-0 autoloader “standard” should be included as part of the PHP core (in ext/spl to be exact). I’ve tried to stay out of the discussion and have successfully done so. Until today. I feel that there’s something that’s been missing to the discussion. So rather then posting this to the internals list, I feel it’s better served by a blog post on the subject. So here’s my take on it.
TL;DR:
I don’t think it should be included in the core.
A tool is only as good as how it’s used. It seems like such a simple concept, yet it’s amazing to see how many people get caught into the trap of thinking that because a tool is there, they are safe. We see it all the time in almost any industry. Company X pays untold millions of dollars for a product, just to find out later that it didn’t do what they needed. It’s such common sense that it’s hard to think of someone logically arguing against it. Yet the same mistake is made over and over and over and over again. And on August 18th, we saw a really blatant example of this with PHP’s 5.3.7 release.
Let’s face it: error handling in PHP is crap. Actually it’s worse than crap, it’s craptastic. The core has almost no support at all for handling errors. Sure, PHP has a robust error reporting and logging system, but it has no real way of handling those errors. If you want to write robust code, you need to be able to actually handle errors. So how can we handle errors in PHP?
Today’s IDEs (Integrated Development Environments) provide a lot of features that make development significantly easier. From error checking and debugging to intelligent syntax highlighting and refactoring, there are a significant amount of time saving features available. One of these commonly loved features I have disabled, and found it has made my life easier as well as the code I write better. The feature I am speaking of is autocompletion…
I recently read a post entitled Dependency Injection: An Analogy, and I think it does a pretty good job explaining two of the types of Dependency Injection. I really like the theme, and feel it really brings down the topic of DI to easy to understand language. The only problem with it that I can see is that there are actually 4 flavors of DI available to us. The other two flavors aren’t even touched in that post. So let me expand on that theme a bit here (Borrowing the same core analogy base from that post):
Quite often we see people talking about the best way to approach a problem. Usually this involves taking a relatively simple concept and making it fairly complicated to make it as flexible and maintainable as possible. While I’m all for maintainability, I think that sometimes we miss the point that it all depends on context. It seems like most people don’t understand the difference between good and good enough.
Part of being a developer is making design decisions based on conflicting goals. Our job is to choose the line that’s appropriate based upon our experience and the needs of what we’re doing. But there-in lies the problem: How do we know where that line really is? How do we know when we’ve actually reached the point of good enough?