Where the rubber meets the road
Back when I was writing software that ran on HP LaserJet printers, I hated having to wait 45 minutes for one-line changes to compile (in a ClearCase build system) and then burn to flash memory. Sometimes, a problem with the printer's behavior wouldn't even be a problem with my software. It would sometimes be caused by an obscure bug in the hardware.
Because of time to market pressures, the team would have to work with prototype hardware, the design of which wasn't even finalized yet. The guys who wrote the low-level code had to write some registers and hack their way around hardware defects.
Somehow, it seemed wrong to me that I should constantly be worrying about the integrity of the underlying hardware or the operating system on which my software ran. I should have been able to take it for granted.
I longed for the day when I could instead work on web applications, where I could safely assume that the hardware was fine and that there were no major defects with the platform on which I was building. The platform on which my software ran would come already debugged, I figured.
Since diving more deeply into web application programming, the experience has been as good as I had imagined, for the most part. There's always a lot of documentation out there, and it's usually just a matter of searching through Google results to see which one relates best to the problem I have at hand. I rarely get stuck for long.
If you ask most web developers, the worst thing and most frustrating thing about writing web applications would probably be cross-browser compatibility. Different browsers handle CSS and the JavaScript DOM a little differently. It's the bane of many a web developer's existence.
When I'm working on getting a web application working with different browsers, the thought crosses my mind that I'm wasting a lot of time by having to check for compatibility with browsers that should just work. It seems like an enormous and unnecessary waste of time.
After thinking about it, though, every software industry has its area of "inefficiency" for developers, and that's usually where the rubber meets the road. It's where the software, however elegant it is, has to face the real world in all its ugliness and imperfection.
In web applications, cross-browser compatibility in web applications is needed because that's where the application faces the real world, where people use all sorts of different browsers.
With Unix software, there are portability issues between different kinds of Unix. There's the worry of having to work with different thread models and libraries. There's the process of having to build with different compilers, not just gcc. There's GNU make and BSD make. The #ifdefs and #defines aren't any prettier than JavaScript workarounds.
Network software has to know how to deal with extensions to a standard that may not be universal. The RFCs are great: they've helped to avert major compatibility issues in the past, but technology companies are inevitably going to shoehorn in their own little extensions to network protocols. Clients need to know what servers are capable of, and servers likewise.
The point is, when I think about it, having to check for cross-browser compatibility doesn't seem all that bad. Yes, it does mean that hours and hours will be gone from the day trying to hunt down the problem. Yes, it could have been better if Microsoft had tried to follow standards in their implementation. Yes, many other things could be done in the future to better the current state of things: there are libraries and frameworks out there that abstract away much of the pain, just like people have figured out how to create portable Unix programs (grab a copy of the autotools and run a configure script). But at the end of the day, the reality is that people out there are using different browsers to view the same site, and it's my responsibility to make sure my application works. It often seems like a huge waste of time, but it's that final push that really makes the difference.
Because of time to market pressures, the team would have to work with prototype hardware, the design of which wasn't even finalized yet. The guys who wrote the low-level code had to write some registers and hack their way around hardware defects.
Somehow, it seemed wrong to me that I should constantly be worrying about the integrity of the underlying hardware or the operating system on which my software ran. I should have been able to take it for granted.
I longed for the day when I could instead work on web applications, where I could safely assume that the hardware was fine and that there were no major defects with the platform on which I was building. The platform on which my software ran would come already debugged, I figured.
Since diving more deeply into web application programming, the experience has been as good as I had imagined, for the most part. There's always a lot of documentation out there, and it's usually just a matter of searching through Google results to see which one relates best to the problem I have at hand. I rarely get stuck for long.
If you ask most web developers, the worst thing and most frustrating thing about writing web applications would probably be cross-browser compatibility. Different browsers handle CSS and the JavaScript DOM a little differently. It's the bane of many a web developer's existence.
When I'm working on getting a web application working with different browsers, the thought crosses my mind that I'm wasting a lot of time by having to check for compatibility with browsers that should just work. It seems like an enormous and unnecessary waste of time.
After thinking about it, though, every software industry has its area of "inefficiency" for developers, and that's usually where the rubber meets the road. It's where the software, however elegant it is, has to face the real world in all its ugliness and imperfection.
In web applications, cross-browser compatibility in web applications is needed because that's where the application faces the real world, where people use all sorts of different browsers.
With Unix software, there are portability issues between different kinds of Unix. There's the worry of having to work with different thread models and libraries. There's the process of having to build with different compilers, not just gcc. There's GNU make and BSD make. The #ifdefs and #defines aren't any prettier than JavaScript workarounds.
Network software has to know how to deal with extensions to a standard that may not be universal. The RFCs are great: they've helped to avert major compatibility issues in the past, but technology companies are inevitably going to shoehorn in their own little extensions to network protocols. Clients need to know what servers are capable of, and servers likewise.
The point is, when I think about it, having to check for cross-browser compatibility doesn't seem all that bad. Yes, it does mean that hours and hours will be gone from the day trying to hunt down the problem. Yes, it could have been better if Microsoft had tried to follow standards in their implementation. Yes, many other things could be done in the future to better the current state of things: there are libraries and frameworks out there that abstract away much of the pain, just like people have figured out how to create portable Unix programs (grab a copy of the autotools and run a configure script). But at the end of the day, the reality is that people out there are using different browsers to view the same site, and it's my responsibility to make sure my application works. It often seems like a huge waste of time, but it's that final push that really makes the difference.
Comments
Good thing we haven't needed any of that mental toughness yet from you. Things are swinging along dandy. :)