Maybe it’s just me, but one of the things about programming is that many of us pre-occupy ourselves with is the need to find the right way to do something. Contrast this with the mindset of “I just want to get it working” and you’ll know what I’m talking about.

Basically, it’s never good enough just to get something working.

Of course, there are exceptions: creating prototypes, working on a small demo to show someone how something may work, and so on.

But when you’re working on a professional grade product, there’s a number of things that go into getting things to work – anything from the design of the product architecture through how the various functions, modules, or pieces of code are going to interact with one another.

Continue reading

I think that one of the biggest things that developers – myself included – could be better at doing is testing. I’m not necessarily talking about just writing unit tests, or just doing usability tests, but just the general act of testing.

That is to say that perhaps it includes all of the above, perhaps it includes just providing automated and manual testing for part of an application, or perhaps it includes something else that hasn’t been mentioned.

Whatever the case is, testing is important. I’m not afraid to admit that it’s arguably my weakest aspect when it comes to working on projects for myself or for others. To be clear, this isn’t to say that I don’t test (because I do), but that I have room to improve (because I do), and I think we all do.

In fact, I think that there’s something psychological about developers and testing; otherwise, why would there be so many books, articles, and tools on the topic?

But here’s what I think: Developers get into a weird mind set when they’re working on a project and think that a minimal level of testing is enough not because we’re malicious or because we’re lazy, but because I think we think we know how the the users and the context of where our code is running will respond.

But we don’t and this has been demonstrated time and time again.

To that end, there are a number of ways to improve the way in which we test our work. And if you’re not testing at all, then one of the easiest (and even one of the most complete) ways to go about testing your work is through the use of a software test plan.

Continue reading

This is the second post in a series about my thoughts an experience in building a team. Read the first, as well.

In the previous post in this two-part series, I talked about there are different types of teams that are out there and that work together on certain types of projects despite the fact that most of the material that we read is oriented around teams that make up a startup, a business, or a company.

Specifically, I talked about how I used a team to help test my WordPress theme prior to releasing it for sale, and how each person on the list was vetted and provided invaluable information, we didn’t have any type of strict hierarchy.

Instead, it was basically everyone person working together to make sure the product was as solid as possible. But there are more reasons on why you need a team.

As I’ve continued work on the next iteration of the WordPress Plugin Bolerplate, I’ve been working with a very small, focused team of developers all of whom are doing a stellar job helping to bring this project to fruition.

Continue reading