PHP Developer

I am taking a PHP development class at college this semester. So I thought I would browse around to see what qualification you need to get a PHP Development job. Of course you need to know the PHP programming language. It appears you also need to know some associated technologies like Drupal.

PHP is the fourth component to the LAMP stack. I guess you better know the other components as well. Seems like there is a whole host of technologies you must learn to be a web developer.

Some of the PHP jobs I found paid a nice wage. Others were weak. I liked that I saw PHP posistions that require things like Python and/or ActionScript. I plan to take classes on those languages soon. Here is the whole list of technologies I found PHP developers should have:

• Drupal
• WordPress
• Zend
• CakePHP
• Joomla
• ColdFusion
• Perl
• Python
• Ruby
• Apache
• Linux
• NoSQL
• Cucumber
• ActionScript
• cross-site scripting

Pay Based on Programming Language

I just read a post by Benjamin Podgursky on the relationship between programming language and income. Very interesting. PHP was near the bottom of the list (least paid). That was disappointing. I am trying to learn PHP this upcoming semester. Then again, the rationale behind the low salaries was that PHP is easy to learn. I will be the judge of that. But I am optomistic.

Near the top of the list was Java. Yeah. I am brushing up on my Java right now. My manager told me I should probably be learning J2EE better in the next year or two. I concur. Something surprising at the top of the list was ActionScript. I thought Flash was on the way out. Perhaps its demise was overstated.

Hard Problem

We had an old trouble ticket that we wanted to resolve in the next maintenance release. One of the developers got assigned to determine the root cause of the problem. Everyone was hoping the analysis would take around a day to complete. After a week of analysis, this developer made no progress. This was going to cause us to slip our release. Not acceptable.

The analysis got reassigned to me. I was told I had a day to complete the analysis. There was already a work around in place. A script ran hourly on the cron that tried to detect and correct bad records. I traced down one of these corrections in detail.

I was frustrated because I could not figure out how the records were wrong. In fact, I kicked it into high gear and proved that the records were not wrong. That’s when I made a breakthrough. The workaround itself was buggy. It was rooted in a timing issue. Not a rookie mistake.

Once I knew that I could not trust the work around, I found a real example of the bug. Then I reconstructed what happened to cause the problem. It was tricky too. There was an optimization in one of the database triggers that tried to skip some unnecessary updates. However one of those updates was masking crucial changes from another update. Doh.

Digging in

One of the mid-level managers on my project wanted me to show a new guy what I was doing on a big bug fix. So every morning I would call him up and check up on him. I would give him tasks to do. Then I would check back on him at the end of the day. My first assignment was for him to replicate the problem I was fixing.

You would think that this was an easy task. I did all the heavy lifting, mining the audits, and discovering the root case of the problem. I came up with an ironclad set of steps to recreate the problem. I turned the new guy loose on thse steps. And then ... he got nowhere.

New guy did not have a database schema. What? How the heck was he doing any work. I told him to call the lead DBA and get them to setup a schema. Next he did not have any database tools. So he got a copy of SQL Developer installed and configured. Then he did not have a working version of our application.

Wow. This is tough work. But it is all good. If it was too easy to step in and get settled with our system, they could hire any lackeys to do the job at a cheap price. Today the developer said the IDE was complaining that a C source file was missing. I had him check whether the Pro*C file was generating the C file. Nope.

There was a mismatch between his Pro*C code calls and the stored procedures in his database. Showed him how to get the source code of the stored procedures. He then compiled in the latest stored procs and still had the errors. Turns out he was using the wrong Clearcase view to obtain the Pro*C code. Killer. This guy is going to need to go a long way just to keep up, let alone add any value.