CodeWorks 09 Vital Stats
Random Statistic of the day
Number of takes for me to get a video right while sitting at a table with the waitresses all staring at me: 2
Number of takes for me to get a video right while sitting at a table with the waitresses all staring at me: 2
If you know me, you know that PHP is my passion. Talking about PHP is fun, working with PHP is fun, helping others work with PHP is fun. Heck, I love PHP so much that I’ve worked it so that my day job for the last 3 years has been working with PHP and developers.
Over the past nine years of having fun with PHP, began to see that there are five categories of tools that I rely on more than any others. Sure, I’ve got a code beautifier, a standards checker, and a hand full of hand-written scripts I use for various things to make life easier. However when it comes down to it, there are five that I rely on every day.
So here they are in acceding order of importance. Let me know, what are your five? (let’s not start a meme or anything though, ok?)
Whether you prefer PHPUnit or SimpleTest, Unit testing has proven it’s usefulness in the development process. As a professional PHP developer, you should be familiar with the concepts behind Unit Testing and Test Driven Development. You should also be able to identify when unit testing is a good idea and when it’s a bad idea. (Yes, there are times when it’s a bad idea)
As with unit testing tools, there are multiple options for you when it comes to debuggers. dbg, Zend_Debug and xdebug all provide professional PHP developers with tools to break down their code and find problems. Debugging tools allow you to step through your code, stop execution and examine the environment at any point. Debuggers are a developer’s best friend and every developer should have one installed on their development server. Bonus points if you’ve also got FireBug installed. Find you a good debugger and invest the time necessary to use it, it will be time well spent.
If you are doing serious PHP work then chances are good that you are working with a database. At some point your database structure will grow too large to keep in your head, you will need a tool to keep everything straight; that’s where an Entity Relationship Diagram (ERD) tool comes into play. Tools like MySQL Workbench help you visualize your database structure. More expensive tools like ERWin or Embarcadero’s ER/Studio give you more options for importing and exporting models and keeping your database model in sync with your actual database.
No matter whether you are working on your personal project or the corporate database, an ERD Tool will help you manage it.
CVS, SVN, Git, or a host of other options both free and commercial will help you keep your code safe. Whether that’s safe from your development server’s hard drive crashing or safe from you next coding binge where you change something at 2AM that you really shouldn’t have; keeping your code in a version control system will help. Which system you choose will largely depend on how you or your team work. You need to research the options available and work with your team to make choices like central vs. distributed.
The most important tool any developer can have in their tool box these days is a framework. Let’s talk about two different types of frameworks.
The first type of framework is a Content Management System. These days CMS systems are complex enough to be thought of as specialized frameworks in their own right. You need to know one good enough to get it installed, up and running and extend it to get the job done. If your needs are easily definable and your CMS of choice has extensions available to fit more of the functionality then learning one could pay for itself in only one or two projects.
PHP has a lot of good CMS projects available and listing them here would simply mean that I would forget one so I’m not going to try. Dig around on Google and you’ll find one.
The second type of framework that PHP programmers need to have in their toolbox is a more generic programming framework. In the PHP world we have a lot of frameworks from which to choose. Most developers chose one of three or four major frameworks.
The framework you chose will largely depend around the type of projects you work on your style. Each of the above frameworks has it’s own strengths and weaknesses.
Regardless your choice, you need to know one framework well enough so that when a project comes along, you don’t burn a lot of time “Yak Shaving” but can get the project up and running quickly.
There you have them, my 5 tools that every PHP developers should have in their toolbox. One thing that did not make the cut was an IDE. An IDE is great for those who use them. However, if you don’t want the overhead of an IDE, there are a lot of good Programmer’s Editors out there for you to use.
For me, I use Komodo. Yes, I know Komodo bills itself as an IDE and it has all of the important features of one. However, it doesn’t force me to code it’s way. I can use Komodo to write PHP or edit my hosts file. Active State realizes that every file is not a project and that a developer should only have to use a project when they actually want a project.
Until next time,
[Editor’s Note: This is an editorial that was originally published on Freshmeat back in 2000. As I’m cleaning up my content, it stuck me that I had never published this here.]
Me to the everybody: “Hi, my name is Cal… and I’m… I’m a manager.”
Everybody: Hi, Cal!
I am a developer who made the conscious decision to move into management. My training, my experience, and my love has always been developing software. I’ve worked under sales managers, business managers, and (shudder) a CTO who believed that all the good software had already been written so we didn’t need to write anything; we could just buy everything we needed. I made the leap into management for one reason: I had a manager who “got it” and showed me by example that developers can make great bosses for other developers. (Thanks, Paul M.!)
During my career as a developer, I learned many different things but the one thing that has stuck with me is this axiom:
“If you have never been a software developer, you have no business managing software developers.”
There, I’ve done it again. At least one third of you are now mad at me. But regardless of your feelings towards me, I stand by my statement because, time and again, whether through personal experience of 24 years or war stories from others, it has survived.
Before you fire up mutt and flame me, let me be quick to point out that I do not believe that this maxim is universally applicable to all situations or walks of life. I am not belittling any person or occupation, but I believe that, in most cases, we as humans, co-workers, and professional colleagues have enough shared experience to be able to relate to each other. I do not believe that this maxim applies to the sexes or to races. However, there are a few areas where it does apply, and the one I know most about is software development. Here are three different thoughts on why I believe this is true, what I believe has caused the current crisis, and what I think we can do about it:
There are very few professions that combine the creativity involved in good software development and the rigorous deadlines, often imposed from the outside. Hurry up and create! The ideas have to keep flowing, they have to be scheduled, and they have to be completed on time. If you have to go figure something out, go. But make sure you are back after lunch and make sure your schedule doesn’t slip. Developers, especially now as we work in Web years, are under increasing pressure to “Get it out the door fast!”.
The rigorous detail work of quality software development, however, has not changed. It still takes time to develop quality software. (You can have it good, fast, or cheap; please pick two.) To those on the outside, it may sometimes seem that what we do is easy. (Heck, we may feel that what we do is easy!) The ease with which developers manipulate the tools of the trade is often misconstrued as ease with which the task can be completed. Only a developer understands the countless hours it takes to master new tools, new languages, and new concepts. In this age of rapid development, new concepts come at us like a fire hose of knowledge. We are supposed to know how to soak it all up and be able to use it in our next project. This is almost a bearable burden if management understands what we are faced with. The problem is that, having never been there, most managers cannot empathize. (And most don’t even bother to sympathize.)
It’s generally accepted folklore in the IT community that managers are managers because they can’t do anything else. What has led us to this state, a climate in which developers don’t respect their managers and managers try to manage a software development team like an accounting department? Volumes have been written on when and why people are promoted into positions they are not qualified to hold. I won’t rehash that here. I have a different take on it.
The question we ask should not be “Why don’t managers understand software development?”; the question should be “Why don’t those of us who do understand the process step up to management?” The obvious answer is that there are very few developers who want to be managers.
In the past, developers would have to turn away from promotions to management (and sometimes raises) so they could remain in development. These days, they find other companies to work for that will pay them more and allow them to continue to develop (but that’s a story for another day). The problem exacerbates itself. The more developers steer clear of management positions, the unhappier software development teams will be with the candidates that become their managers.
We, the IT community, have the bosses we have because we refuse to step up to the plate and take the job. I am not advocating that all developers climb the management ladder; far from it. In most cases, a developer pressed into service as a manager will do no better a job than an accountant forced to code. But until the development community learns to train its own management structure, we are doomed to be managed by PHBs.
So now we are all on the same Merry-Go-Round from hell. What can we do to get off? At least part of the answer is obvious. We, as a community, have to train our own managers. For me as a manager, that means that as I interview candidates for development positions, I have to keep my eyes open for potential managers. I have to make sure that I mentor as I was mentored. I have to realize that if I don’t train new development managers, I’m as big a part of the problem as non-development managers.
For me as a developer, and all other developers reading this, we have to make sure that we educate our managers.
We have to teach them concepts like:
I’ve found that, in many cases, they can learn. They want to learn. They are PHBs because they’ve never been taught not to be. There are some that won’t learn or, worse yet, think you have a lot to learn about business. If you are under one of these and you work in America, change jobs! Life’s too short and the job market is too tight to deal with goobers like that.
To fix the present situation, we, as developers, have to make one of two choices. We can take a stand at our present jobs and educate upper management so that we don’t work for PHBs, or we can find other jobs. But make no mistake about it; it is ultimately up to us to fix the problem.
Until next time,
I’m really curious about the origins of the Seven Things Meme. Anybody know where it started? Anyhow, I’ve been tagged by my friend Matthew Weier O’Phinney so I’ll play along. (It forces me to blog, something I’ve not done a lot of in the past 6 months)
When the start-up went tits-up, I started doing contract work until I found something I liked. One of the contracts I started working on was this new site that Zend was building and Jayson was in charge of, DevZone. One thing led to another and after about 3 months of working on contract for Zend, and constantly asking Jayson if there were any positions open at Zend, I got an email from him. He said that Mark de Visser, his boss, would be in Nashville the next week for a Red Hat conference and wanted to interview me. I had a great interview with him and had an offer letter in my email in box when I got back home.
It was probably the weirdest journey to a job that I’ve ever traveled, but it was worth it. :)
Ok, there are my Seven Things. Now for my Seven People. I think this part may be harder than the seven things.
And now, the rules:
Until next time,
I’m going to cover a lot of ground in this post so unless you are friend or family, you may just want to read the next summary and skip the rest.
For those who have not heard, yes, I will soon be leaving Zend and moving to Ibuildings. Yes, that means I am also leaving Nashville, TN-US for Utrecht, Netherlands. No, the lovely and talented Kathy will not be going with me immediately but will be joining me after my son graduates high school. Yes we are both very excited about it.
The first question most people ask me is why? I mean a lot of people asked me that. As I’ve said to just about anyone who would listen, I have a great job! Zend is a great company to work for, they provide for their people, and I have absolutely no complaints about my time at Zend. This will come as a surprise to a few Zenders as all they have ever seen me do is complain. I’ve been allowed to create my role at Zend and that is a rare thing at any company.
I was originally hired at Zend to be an editor for DevZone and I was just supposed to write articles and code. (those of you who have seen my spelling and grammar gaffes can stop laughing now) Over the course of 2.5 years, Mark de Visser, with the backing of Andi, Harold and the rest of this awesome company, put up with my antics. They paid me to work with the PHP community. I got to travel to conferences, hang out in IRC, they even let me be the Master of Ceremonies of ZendCon. This truly is a dream job. It is so great that in the 2.5 years, I’ve turned down most offers to interview and the few serious offers that came my way. This was were I felt at home.
So back to the question, why leave a dream job at a great company? The only answer I have is “opportunity“. Most of you have never read my article “Nerd Herding” (and I don’t recommend you bother now) but in it I talk about the fact that for developers, interesting projects are just as important as a good salary. While I still love what I do at Zend, the opportunity offered to me by Ibuildings was just too great to pass up. So that is why, after over a month of thinking about it and discussing it with the lovely and talented Kathy, we decided that this was a chance I couldn’t pass up.
One of the great things about my job, both at Zend and at Ibuildings is that I get paid to work with the PHP community. I told someone this at ZendCon but it bears repeating here.
PHP is my fifth programming language, that means I’ve been a part of 5 programming communities. None of those communities have come close to being as vibrant, fun and welcoming as the PHP community. PHP developers should not take this community for granted, it is something special.
It is to this awesome group of mixed nuts that we call the PHP community, that I give a big hug and say thank you. Thank you for all the tweets, blog posts, IMs and irc well wishes today. Thank you for your friendship. Thanks you for welcoming me in even when you didn’t have to. You guys and gals are teh awesome and I wish I could call each of you by name and say thank you. (if I tried, we’d be here a while an even then, I know I’d leave someone out so I’m not going to try) It has been a blast working with you while at Zend and I look forward to working with you at Ibuildings!
I’ve talked a lot about Zend in this post but I can’t close without saying a big hello to my new Ibuildings family. Thank you for welcoming me in such a warm fashion. I’ve never had this much attention paid to me coming to a new company. Honestly, it humbles me to think that I’m moving to a new company and country and yet I already have good friends in both. I am looking forward to working with each of you!
I am positive that Zend will be hiring someone to take over DevZone and my other duties. I know that phpc will embrace them as you did me. (because again, you guys and gals rock!) DevZone has become a regular daily stop of a lot of PHP developers and I am sure it will only get better.
As for me? well, I’m not going anywhere. (figuratively speaking) I’ll still be hanging around on Skype, IRC and IM. If you need to contact me, my contact info is always on my EPK. I encourage you to ping me if I can help you.
It’s been an awesome 2.5 years at Zend and I look forward to a number of awesome years at Ibuildings!
Until next time,