I read a very dissapointing post by Anthony Ferrara called Rambling on Internals last week. It describes how frustrated Anthony has become with PHP’s internals mailing list, the process that PHP uses to select and create new features, and the plain fact that there are many trolls on the PHP internals list who have their own agendas, not the agenda of the PHP project, at heart.
Reading Anthony’s article was an eye-opening experience to the challenges that PHP faces. And while I can’t say that I agree with all of his statements or choices, I can say with some certainty that I understand his point of view. PHP Internals has long been known as a troll’s paradise.
Five months ago, I had an opportunity to accept a contract to work at Mozilla as part of the webdev team. There was a match for my skills on a contract basis, and even though it meant leaving permanent employment for the uncertain world of contracting, I knew it was something I would never forgive myself if I didn’t engage. I didn’t know then just how right my decision was, but after spending a week in Portland with the team at OSBridge, I was shown just how right my decision had been.
Mozilla, along with Emma, hosted a party during OSBridge. During the party, we asked attendees a simple question: “What do you want the web to be?” A video was compiled with their responses, which you can view here:
Every developer has a toolkit of favorite tools and applications that help them develop more effectively. Being individuals, developers often differ (and in some cases, argue) about the tools they use. One of the most frequent questions I’m asked is “what are the tools you use?” and that was the genesis of this blog post. While there are many tools that I would feel lost without, I have listed the five that I see as most crucial to my ability to effectively develop software.
Dual monitors with a fast machine
Last week, I began working on something that didn’t pan out. For whatever reason, I went down the wrong path, and ultimately abandoned the task I was working on. In discussing it with my boss, he mentioned to me that it was better to realize early on that something wouldn’t work than to trudge onward, insisting that it be finished due to the “sunk cost” of the time already spent.
This got me thinking about how often we consider the “sunk cost” in our decision-making process, especially when it comes to our software development.
I talk a lot about how having a spec is a critical component of software development. But how do you know that your spec is good, and that it has been developed enough? Simply put, how do you distinguish between a good spec and a spec that is lacking?
This problem had confounded me for a good bit of time, because it’s hard to create a rule surrounding spec development. Since most developers (myself included) are also generally bad at developing good specs, it becomes even more difficult to create such a rule. However, I heard a great adage from someone recently that I thought summed up how developers can see specs nearly perfectly.
On Tuesday, Marco Tabini told us that we were doing it all wrong. He makes some fantastic points about software development overall, and about the state of our profession. This article’s point isn’t to be a rebuttal, but a corollary to what he had to say.
Marco is right: every one of us is “doing it wrong.” If we examine our development practices, and compare them against the “best practices” of our industries, we’re never perfect. We always fall short of the goal. Yet our code doesn’t fail; in fact, for almost all of us it works and works well – it’s the only reason we haven’t gone on to basket making as a profession.