As a mostly front end web developer that dabbles heavily in design, I’ve stayed away from node.js. It’s just been something that’s I’ve associated as too server side and back end intensive; I roll with it myself to check my Javascript via JSHint, but little else. That opinion may be changing though with programmer Randall Degges essay here.
Developer Dan Shipper:
When a non-technical person attempts to estimate software development time they come armed with their two basic heuristics: complexity based on size and complexity based on speed. But what they don’t realize is that software is different. Software is by nature not physical. It exists in the ether. A tiny portion of it shows up on our computer screens from time to time. Because of this when it comes to building web apps (or any type of software for that matter) our basic heuristics break down.
So many tech articles include a throwaway sentence on how developers aren’t good estimators of their work time. Rarely do they go further into the why behind that statement, but Dan’s does, and does so effectively. (via Watts Martin)
David Hansson, 37signals:
Every line of code you write has a cost. It takes time to write it, it takes time to update it, and it takes time to read and understand it. Thus it follows that the benefit derived must be greater than the cost to make it. In the case of over-testing, that’s by definition not the case.
Think of it like this: What’s the cost to prevent a bug? If it takes you 1,000 lines of validation testing to catch the one time Bob accidentally removed the validates_presence_of :name declaration, was it worth it? Of course not.
I see a huge amount of admonishments online for developers who don’t test enough. David approaches the problem from the other side; when does testing get out of control?
JavaScript engineer Rebecca Murphey:
Once upon a time, editing files, testing them locally (as best as we could, anyway), and then FTPing them to the server was the essential workflow of a front-end dev. We measured our mettle based on our ability to wrangle IE6 into submission or achieve pixel perfection across browsers. Many members of the community – myself included – lacked traditional programming experience. HTML, CSS, and JavaScript – usually in the form of jQuery – were self-taught skills.
Something has changed in the last couple of years. Maybe it’s the result of people starting to take front-end dev seriously, maybe it’s browser vendors mostly getting their shit together, or maybe it’s front-end devs – again, myself included – coming to see some well-established light about the process of software development.
Whatever it is, I think we’re seeing the emphasis shift from valuing trivia to valuing tools.
Impressive compilation of JavaScript tools, tutorials and more. Complete newbies should make a beeline for the in-browser developer tools section. If you aren’t debugging in the Chrome Developer Tools or Firebug, as far as I’m concerned, you’re not breathing as a front end developer.
Programmer James Hague:
When I sit down to work on a personal project at home, it’s much simpler. I don’t have to follow the familiar standards of whatever kind of app I’m building. I don’t have to use an existing application as a model. I can disregard history. I can develop solutions without people saying "That’s not how it’s supposed to work!"
That freedom is huge.
Having recently knocked out some side projects of my own recently, James really hits it on the head. If you’re a developer and don’t have the time space to go off and run with your own thing on your own time, you’re missing a big growth opportunity.
Sometimes the smallest of changes can deliver a huge impact. In my case, several weeks ago I switched away from the popular Mac text editor TextMate to Sublime Text 2, giving a significant boost to my productivity in the process.
Some context is necessary here: any web developer can tell you that, with the profession’s focus on coding, text editors are generally the most important tool at hand. For the last five years, TextMate was my editor of choice and I depended on it for effectively everything at work: HTML, CSS, Ruby on Rails, even extended emails and design notes. I loved the speed, the keyboard shortcuts and its slick bundling system – macros, commands and templates came together in a unified package.
But ever since Mac OS X Lion came out, TextMate’s lost a lot of its luster. The downward spiral began with the program’s incompatibilities with much of Lion’s new functionality; this only amplified the nagging suspicion TextMate would never receive a significant upgrade (its last significant release was version 1.5 back in January 2006.) The TextMate team unexpectedly announced a public alpha of TextMate 2 for release before the end of 2011, but I think it’s a case of too little, too late.