How much automated/pre-written code will you tolerate in your projects?

For me it depends entirely on the source. I don’t mind using open libraries and that sort of thing, of course. And I’ve also seen programming languages like Vala, which translate into C code and run that; that’s a form of automation, of course, and it can be done quite well. In fact high-level languages in general are basically all ways to automate writing machine language.

Yet there’s a point when it becomes annoying and difficult to work with. You know where I stand on Visual Studio. I’m not that fond of bulky IDEs in general, though. gedit is my bestest buddy, nano if I’m not using the GUI. They’re simple and minimal and there’s no giant learning curve.

Of course this isn’t confined to programming proper. We’ve all heard (or experienced) the horror stories surrounding Adobe Dreamweaver, the HTML-generating application. That’s a glaring example of automated code gone horribly Frankenstein’s-monster wrong. I notice that a lot of “build your own web site” applications tend towards that fate–with the notable exception of WordPress, which I really like. (Obviously.) WP is open-source, though. It’s special.

I’ve found that anything that wants to write code based on user input from a GUI has a big hurdle to overcome. GUI input can be really nebulous, and comparing it to code is kind of apples and oranges. Reversing changes made in this manner can get even messier, but naturally the user will want to do that too.

I think my complaint is that the automation can be executed very clumsily, and such an execution can be excused and have a market because people are so afraid of code. Even novice programmers are pretty afraid of code. It looks intimidating at first glance! Even when I pull up someone’s source for the first time and try to figure out what it does, it can be overwhelming and confusing, and I’m used to seeing code by now. So people who don’t know any better will look at a GUI, or a similar graphical display of what the code’s supposed to be doing (this seems to be the appeal of flowcharts, UML, and perhaps even pseudocode to a degree), might be seen as comforting. Like a visual map. Just beware of drunk cartographers.

I think the reason we have that problem as much as we do (people wanting visual maps, not inebriated mapmakers) is that we don’t know how to teach programming. ESR’s advice in “How to Learn Hacking” is to start off with working on programs that are just a hundred lines, then a few hundred, then a few more hundred, then a thousand and then three thousand and so on. Although I don’t remember if he mentioned it and I don’t feel like digging it up at 4AM, which is when I’m writing this, this is so that you can learn to hold programs in your head. Uh… there was a Paul Graham essay about that that I liked, too. I’ll throw some links in this thing later maybe.

If you don’t learn to hold programs in your head–their structure, also known as their this-relies-on-this-which-uses-this-to-do-this–then the desire for a visual representation is a lot greater.

Again, visual representations CAN be useful. Loading a program into your head takes time, a lot of time, and that overhead is greater the longer/more complex the program is. So if you make a UML diagram as notes and that helps you reduce the time it takes to page in a program, great! If you come up with a system of monkey-scrawl notation that only you can understand and that helps you reduce the time it takes to page in your program, equally great! Because the same thing won’t work for everyone. And half the usefulness of such diagrams is in having made them and semi-consciously remembering making them. Let your buddies, coworkers, cofounders make their own; using yours wouldn’t be as effective.

Personally, I like comments in code. If someone who’d studied the programming language for six months couldn’t look at a chunk (a few lines) of code and tell in under 10 seconds what it does, it should have a comment stuck on it. Even more so if it’s convoluted and contextual. I also believe in the art of making these comments fit on only one or two lines, though. It also helps when you’ve been banging on your code at unholy hours and forgot in the morning what you did.

I also like using monkey-scrawl notation. Less as intentional reference, usually; more as paging out thoughts and ideas in order to make sense of them. But they can serve the purpose of going back and understanding what you were thinking earlier as well.

Anyway, it’s 4AM and this stream-of-half-consciousness essay needs to end. Tell me what you think in the comments, and good night.



Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s