Walk the Walk Before Talking the Talk

Clay… don’t see any contact info anywhere, but I was wondering… would you be interested in doing a Podcast with me. The story of Feedster moving to php 5 sounds like it would make for a great conversation. Get in touch with me: http://podcast.phparch.com

- M

This is the best blog I’ve read all day. Your bullet points are now officially part of my development commandments. It would behoove all developers, at any level, to do a regular ‘look in the mirror’ in regards to these examples of disciplined coding. I, myself, am regularly guilty of not following half of them (documentation and strict error reporting in particular). I’d like to single out documentation in particular: there seems to be many formal ‘ways’ to document your code, be it javadoc (or phpdocumentor for us PHP folks), but even sprinkling comments about what your code does throughout the source is a good start. Good code is usually simple and well structured code… it will practically document itself if done right.

Well said Clay.

Nice list… and I even do the majority of them which kinda surprised me. I haven’t regularly used version control and have never done unit testing but they are on my todo/learn list (which never seems to get shorter – no matter how much I learn)…

Maybe when I’ve been doing this for 30 years I’ll feel comfortable enough to say I’m an expert – but I doubt it since there is always so much more to learn.

Marcus: I’d enjoy that, thanks for the invitation. I’ll hook up with you via email. (And thanks for the reminder to get my email address up on this placeholder blog!)

Shawn: Thanks for the kind words.

> Spend more time reading the PHP online manual and less time
> booking speaking engagements billing yourself as someone
> intimately familiar with the language. Seriously.

So funny.

By the way, error_reporting(E_STRICT) doesn’t do what you think. E_STRICT has a value of 2048 and is independent of the others. E_ALL is 2047, which is the sum of all the others. So, if you want both E_ALL and E_STRICT, try this:

error_reporting(E_ALL | E_STRICT);

P.S. I’ll never be a pro, because I’ll never type will all 10 fingers.

See? There ya go — learn something new every day. Thanks, Chris — I stuck with E_ALL in the Feedster frontend re-write since it depends on so many PEAR libraries which aren’t E_STRICT compliant.

Great post! I could not agree more with your points. And here is a toast to all of us, may we hope to climb higher on your ladder of professional development.

[...] One of my colleagues over at Feedster, Clay Loveless, has an interesting blog post regarding Professional Software Development and Professionalism in Software Development. [...]

What happened to LoveCookies.com? I don’t think you mentioned your sweet tooth business in your mini-biography. =)

My idea of a good project code:

1) Consistent code:

Style of coding should stay consistent.

2) Not everything has to be objects.

Use objects to re-use code, simplify usage, not because “objects” are better.

I blame programming books in glorifing the beauty of objectifying everything. Create objects for what you need, as you need them. Most web sites do not need to have everything as php objects with methods and event handlers. Code bloat, speed, bad readibility, code bloat.

Sometimes, I just need a shovel. I don’t need a shovel with constructors, destructors, parents, static/public/private attributes. Give me a shovel cause that’s all I need and will need for the future.

3) Speed/Performance equals one word: understanding.

You need to understand every single line of code in the project if you expect code performance and scalability.

I don’t buy the don’t reinvent the wheel concept. If an external open-source module does what you need but using 10K line of code with 90% useless methods to your needs, write the code yourself.

To control peformance is to shed fat, use lean code, and control i/o follow from point to point and through every single line of code.

Xing Li (The comment before this one),

While I agree with your statement about not making everything into objects, however, if you are working on a bid enough project it makes more sense to make them into objects. Each object contains a layer of functionality along with a the code that implements these routines. This allows you to do many different things.

One of them being consistancy which you complain about earlier. Also in most objects you shouldn’t need to use a constructor. It might just be bad design when you are looking at some of those.

Allowing for static methods you can utilize an object somewhat like a namespace which then allows for much more consistancy. Controlling the flow of performance is almost just as great if you utilize your objects correctly, if not sometimes better.

Walking the walk…

Clay Loveless has an excellent article on professional PHP development attitudes.

I couldn’t agree more about the rules, especially that last one. My own PHP coding (in pretty much the exact circumstances described!) has come on by leaps and bounce…

Clay:
> Shawn: Thanks for the kind words

You are very welcome. Thanks for the great blog.

> I stuck with E_ALL in the Feedster frontend re-write since it depends on so many PEAR libraries which aren’t E_STRICT compliant.

I’d love to know how this worked out for you in your development efforts. I too use a LOT of PEAR libs in my applications and almost all of them throw tons of notices when strict reporting is turned on.

No amount of discipline will altogether compensate for a lack of talent. Both are needed. For some projects other skills, such as empathy for your client/prospective user, also come into play.

Walk the Walk……

I ran across a really good blog entry by Clay Loveless (of Feedster fame) yesterday that really cut to the heart of what it means to call yourself a software developer. In his words: discipline. I highly recommend everyone who considers themselves a de…

Jason: Cheers! I hope to climb higher on the ladder myself. I often still find myself at the crossroads of a new project being tugged by my old bad habits. I’ll think “nah, *this* doesn’t need to be in Subversion…” but really it’s much easier to just decide on everything going in, so your bases are covered.

Xing: You’re absolutely right about knowing what’s going on in each line of code. Ideally, in a well-formed class/package, there’s been some thought put into segmenting out the essential pieces so that you’re not required to load up a bunch of overhead crap just to use a method or two. As for LoveCookies.com — after putting on too much weight running that effort, plus having our first child, my wife and I decided to close that down. Was a great learning experience, though!

Shawn: Ultimately I just came to the realization that for now, if you want to use PEAR libs, you can’t run under E_STRICT. Slowly but surely more and more PEAR packages are evolving to E_STRICT compliance, but I suspect it’ll be another year or two before we get there. In the meantime, I’ve been developing with Zend Studio 5 and running the “Analyze Code” routine over my code and checking to make sure that the debug output isn’t complaining about E_STRICT problems in what I’ve written. That way I’ll be in the clear when my dependencies are E_STRICT-ready.

Paul: I agree — some core competencies are certainly a pre-requisite. However, I feel like otherwise mediocre-to-poor developers can be made passable through the adherence to some Best Practices.

After all, even my grandmother can grasp a ’switch’ statement; she executes one every time she goes out to run errands. “If this store is too crowded, go to this one instead and pass back by the first one on my way home…” and so on and so on.

[...] About « Walk the Walk Before Talking the Talk [...]

[...] Clay Loveless: “A question that eventually comes up for programmers who stick with it long enough is: Am I an expert yet? Do I have the chops to throw down with The Big Kids?” [...]

[...] Walk the Walk Before Talking the Talk [...]

[...] back to what I was really wanting to post about… I ran across an article of Clay’s today that I think that any PHP developer needs to read. If you do not know Clay, or have not read that post, give it a read. It is worth the time for any [...]