Efficiency vs. Shortcuts
From Zanecorpwiki
At my first programming gig at a company, we had a rule that you weren't allowed to use the build tools until you had built the application yourself. As a young developer eager to learn, I accepted this without question. As a generally curious person, I took the challenge of understanding to heart. I learned not only how our system was built but also how each of the build tools worked and were designed.
By the time I'd reached what I understood as the goal, I emreally/em understood how the application was built. Had all the build tools been deleted and our access to the outside world cut off, I could have recreated it all from scratch. It took awhile to do, but by the end of that two weeks (or whatever it was) I knew more about makeref group=notesmake was the de-facto build tool at the time. TODO: Haven't I ever written on why make is still better than many build tools? Should link./ref and build systems in general than most developers many, many years my senior.
Question: Why did the development group at this company insist that everyone know the build system even when we were under tremendous pressure to get product out the door? Answer: Going through the build took you through whistle stop tour of the entire code base. You got a feel for how big it was, how many moving parts there were, and you saw all the different technologies involved.
Jumping in and hitting a button to build everything then away you go developing gets you developing quicker, but you don't really understand what it is you're developing on. You do understand neither the scope nor the context nor how the pieces fit together. You'll probably get your first bit of useful work done faster, but you're work overall will be slower and of lower quality for lack of the big picture.
The other downside is that when you need to do something really new with the system, you won't be able to. You may understand the code you need to write, but you won't understand how to integrate into the system or get it built.
The majority of accepted best practices on how to code efficiently are, one way or another, a shortcut. The basic idea is to abstract something task into a simple push-button exercise. This is a good strategy, and should be done, but one should understand the issues surrounding such shortcuts.
Once you're on a shortcut, you can't get out. If your push-button build breaks in the middle, the information the tool gives you about what's wrong only makes sense if you understand what the tool is doing. It's like you're scooting through the forest on your good old shortcut through the forest when it abruptly ends. If you know the general lay of the land, you can find your way out and fix the path itself. If not, you're simply lost in the forest.
In order to help the new developer find their way, I'm going to deconstruct a fairly representative article: 10 Ways to Cut Down Web Development Time.
1) Use Frameworks
Off the shelf frameworks can be useful, but it's naive to assume that you always want to use them. Frameworks come with a lot of baggage that often makes them ill-suited for long-lived applications, applications at the core of your business, or truly innovative work. If you're project is non-trivial, you'll inevitably run into an abstraction leak (TODO: link), you're going to have a hard time figuring it out and fixing it unless you've spent a good deal of time really learning the framework--to the point of reading practical and learned criticism and going through the code yourself. The actual value of the framework is a function of the pros and cons as applied to your situation, and it's far from a foregone conclusion that the result is always use a framework.
Frameworks are a kind of shortcut, and like any shortcut, should be understood before you commit to them. Unlike most other things on this list, however, they're a shortcut to a predefined place and come with a lot of lock in, so you better be sure you want to go where they take you.
2) Use an Integrated Development Environment
Not a bad idea, but I disagree with the reasons why an IDE is helpful. Project management and collaboration doesn't need to happen within the IDE and there's frankly not a lot of gain with locating it in the IDE. Choose those tools separately and if there's a plugin for your IDE, great. If not, don't worry about it. Syntax suggestions and auto-fill are cute and maybe save a little time, but again are not a huge win. Syntax highlighting is not even worth mentioning since any editor you would ever choose to use, whether or not it's an IDE is going to do syntax highlighting. Built in FTP and syncing is like project management. You should design your build and deploy without regard to the IDE. If you've got an IDE that integrates with your tools, it's nice. If not, it really doesn't matter too much.
So, what about debugging? Some people find robust debugging tools a big help. In my experience, though, the developers who excel at debugging rarely (as in vanishingly close to never) use a debugger. Understand the system and code and there's never any need to go spelunking around randomly. Even if the error is in someplace you've never dealt with, a well designed and modularized system can be understood quickly enough. Without that understanding, any fix you may apply because you saw something in the myopic view of the debugger may be no fix at all.ref group=notesDebuggers used to be far more important because build times for large systems could be slow. Now-a-days, all but the most gargantuan of systems can be built quick enough that simple print statements and careful consideration are good enough and there's no need to learn the debugging tool. Especially since using a debugger--depending on the technology stack--can be very non-trivial./ref
It's funny, but not surprising, that they don't even mention the number on reason to use an IDE: refactoring tools. I'd love to see refactoring tools separated from an IDE, but now-a-days IDEs are pretty much the only place you find good automated refactoring. Everything else they've mentioned combined doesn't even add up to a tenth the time that a good refactoring suite can save you. IMO, where there's no good refactoring tools, an whether or not to use an IDE usually comes down to whether you like the editor.
3) Modularization
Modularization is a good idea, though I wouldn't call it coding efficiently so much as basic coding. By the time we're talking about coding efficiently, I'd have hoped that modularizing code would already be assumed.
4) Debug Front End Issues with Browser Tools
Yes! The problem is that most technologies come with their own error reporting. Not so with Javascript and HTML. You have to rely on the browser, and until fairly recently, none of them did a very good job of letting you know what was wrong. Because the browser isn't designed primarily for developers, developers have to augment them with the appropriate tools to recapture this basic functionality.
5) Code for Reusability
Again, true, but more an issue of basic coding than efficient coding.
6) Collaborate and track project status online
Absolutely. This is part of the reason I say that you shouldn't worry about whether you're IDE has project tracking stuff built in. It's more important to find the best tool for your style and project than to insist on IDE integration.
7) Automate code formatting and standardization
Absolutely.
8) Invest time in requirements-gathering and planning phases
Better yet: understand and follow the discussions on agile development and the ongoing discussion in the greater community.
9) Use code that’s already written
To their credit, the writers do provide the caveat that you should know enough to evaluate the code your including. Even so, I still say they're being naive here.
If you need feature X then finding some code on the Internet that does X is incredibly helpful. In my experience, however, it's much better to understand the code and then incorporate the ideas than it is to cut-and-paste. Cut-and-paste may work, but it's a little foolish to assume that it's what you want to do. There are some of the same concerns as discussed earlier with regards to frameworks, and even more pertinent here is the question of integration costs. It's rare that one can just drop in code without some side effects.
10) Have less features
My only problem with this is that it isn't number one on the list.
Notes
references group=notes /
