Loading...Web Development
A Bloody Good Developer
Over at joshuaink.com John Oxton's got another one of his rants, "No I am not bloody sorry". You've got to subscribe to this guy's blog if you haven't yet, it's both informative and entertaining.
This post in particular hit home with me because it's something I've been thinking about a lot. What's the right balance of "good code" and doing a "good job" on a project? Priorities are different on every project of course. I see it a lot with W3C Web Standards "standardistas" ranting about things not being 100% exactly right in some random context. Typically my reaction is they haven't worked in corporate or enterprise environments. Yes, we need to push the right, Web standards ways of doing things, don't get me wrong.
Some of this made me think about my prior post on CSS for the Large Enterprise. It wasn't a stunning bit of writing, but the point was that there's "good code", and there's getting the job done. You need to be careful and make the right choices. It often involves sacrifice and weighing the pros and cons. Sometimes you'll have to make sacrifices early on in a project, sometimes you'll have to make sacrifices later at the end. Ideally, you'd never have to. It can happen, but typically it comes down to schedule, budget, and priorities. I was telling someone that works with me just the other day, there's this whole other part of being a good developer or "consultant", for lack of a better word, that has nothing to do with the quality of your code.
John writes:
So no, I am not [expletive] apologizing anymore. For what? For doing the best I can within the scope of any given project? For getting some [expletive] content management system to at least have a go at web standards?
I can go on and on about Web Standards-based Web development all I want, but 9 times out of 10, it's just a means to an end-- yes it's the "right way to do things" and it's the tools I'll use. Yes, there's been projects that I've worked on that had a specific goal in mind when they asked us to do the work, and that was to bring their code up to speed with modern best practices (I love those jobs). Yes, you want to use best practices and organize and write your code in a way that makes sense. Yes, you want to make sure it degrades well and is accessible to as many people as is possible. Yes, you want to tell people the right way to do it.
The problem today is, most enterprise tools and backend developers can't do it, don't do it, or don't know about it. What I have found though is, the lack of these very standards which we're touting now are a big reason a lot of these backend developers got away from doing front end code to begin with. Tag soup didn't make sense to "real" programmers. When they see the "new", right way to do it, I've actually seen programmers get excited about UI development again.
In the end, it's a small part of a larger whole and frequently you're crunched for time or it's a lower priority than getting that content to even come out of the CMS looking right, not to mention formatted right, much less make sure you have a validated XHTML Strict document. If compliance or compatibility with another system is an issue, it might matter (not necessarily the best example). However, it's a good developer who can look at the big picture and weigh the pros and cons on any given project. It's a good developer that can look at the project objectively and be efficient.
I don't think I know a single Web designer who is 100% pleased with the way their designs ultimately end up translated into the end product 100% of the time. It can happen, but like life, there's compromises. Designs get diluted, functionality put first, bug fixes are paramount and matter much more than validation. The same holds true for the code: Does it work? No? Ok, it needs fixing, and fix it fast. Did the solution solve the problem and does the site work? Yes. It might not matter if validation wasn't achieved. Yes, do the best you can, but decide where to put those energies. If you can come back to it later, make a note of it.
John Oxton's right. His "Colin Collegeboy" is showing his inexperience and his true colors. Don't get sucked in, be a better developer.
This notion might seem obvious notions to some, but to others, you'd be surprised...
Jul 8, 01:05 PM in Web Development (filed under Web-Standards)
Possibly Related Articles
Commenting is closed for this article.