Illusory Follies

I don’t usually do this, but here’s a verbatim excerpt from a post on LifeDev that I just love. Having goals in the pursuit of software engineering and design is a good thing. I’ve heard most of these expressed before but not as well as this. (original post by glen on July 23rd, 2008)

Programmers are a great example of thinking outside the box because, well… programmers can actually create the box. Here are some of the ways that we can learn from programmers on how to boost our creativity.

1. Learn a new language

Programmers are constantly learning new languages, either for fun or necessity. Don’t limit yourself to what just what you know and are comfortable with. Branch out and learn a new skill.

2. Start from the ground up

If you’re going to write software, you can’t just start halfway through the project. You have to start at square one. Sometimes this is the best way to find a creative solution for a problem is to go back to the beginning and work forward.

3. Question everything

Questioning everything means taking every assumption and making sure it’s correct. All programming starts with making the most basic assumptions, and then building on those basic assumptions. If something is wrong with the code at the base, then the software isn’t going to work well at all.

Sometimes creativity is limited by assumptions. New solutions arrive when we tear down assumptions and start with fresh perspectives.

4. Do it for fun

If you know any programmers, they’re constantly building something. Even when they’re done for the day on work-related projects, they’ll spend hours of time working on fun projects for themselves. Their work is also their hobby.

Continually mulling over new ideas and solutions is something that shouldn’t be a chore. It should be something that you find yourself doing constantly, like a reflex. And it should excite you.

5. Never stop testing ideas

Programmers are constantly benchmarking code to make sure that it’s as efficient as possible. Even the smallest change can bring a program or Web site to it’s knees, so constant testing and improvement is important to any bit of software.

Ideas should be tested rigorously and refined on a consistent basis. Your ideas will change over time, it just depends how much. Constantly evaluating them and just plain thinking them through is a great way to “benchmark” your idea.

6. Find a passion

If you’ve ever spent more than two minutes talking with a programmer about his work, you’ll find out very quickly that programmers have a passion for what they do. They eat, sleep and breathe programming.

Do you have a passion for your ideas and projects?

7. Master your tools

Programmers constantly improve their knowledge and usage of their tools. A great coder keeps tabs on software and is constantly finding ways to improve his usage of them. You’ll seldom find a programmer who doesn’t tweak his toolbox regularly.

No matter what your skill set, you’re limited to your skill with the tools you use to create. The more of an expert you are with your tools, the more you’ll be able to create.

8. Start making abstract associations

• What if you used computers as telephones?
• What would happen if you used a web site as a Word processor?
• Would people care about what other people are doing right now?

The people behind projects like Skype, Google Docs and Twitter all have one thing in common: They fused seemingly abstract concepts together. Taking what-ifs and testing them is a great way to start thinking of things in a different, more creative light.

9. Think of structure as a tool, not a limitation

People associate creativity with taking a giant, blank canvas and letting our ideas flow without any sort of limiting structures. However, there’s a huge problem with this type of thinking: It’s a great big creativity myth.

See, limitations are everywhere. We can’t avoid them, we can only hope to work with them. A programmer embraces the limitations of his programming language or tools and works around them. These limitations help him as they make a foundation to work from. Sometimes discovering a new workaround will lead to an even bigger idea. Necessity is the mother of invention.

10. Don’t rule anything out until you try it.

Your kindergarten teacher was right: There is no such thing as a stupid question. If you’re adhering to #3 and dismissing all assumptions, you can’t be certain it’s not going to work until you’ve tested it. How do you know it won’t work unless you try it? You might be surprised. Even if the proposed solution doesn’t work, it may help you find a solution.

Sometimes it’s just best to start with a prototype and try it out. If your prototype doesn’t work, then trash it. If it does, you’ll have stumbled upon something that just might work.

11. Always look for a simpler and more elegant solution.

A good programmer is one that understands that finding the simplest solution is always going to be better. Complicated solutions lead to… complications. A practical approach to programming always works best in the long run.

Our ideas sometimes become too complicated. We get caught up in the novelty of the idea that we ignore how practical it really is. The simplest way to solve a problem is often the best way to solve a problem.

12. Don’t be afraid to build off the code of others.

The beauty of the Internet is that the solution your looking for has probably already been done by someone else. When building a new site I almost always use pre-existing open source code. Why recreate the wheel?

Putting a great idea into motion doesn’t mean you have to start from scratch to create it. Use existing ideas and turn them in to something better. Sometimes a great idea is only modifying something that’s already been done. Gmail is a great example. They “reinvented” email by adding useful features to traditional email.

13. Don’t be afraid to collaborate.

Some of the best coding — or any creative projects for that matter — are done not just by one coder but by many excellent people inspired to work toward the same goal. Assemble a great team, use the most brilliant ideas no matter who they come from, and let everyone contribute.

14. From the very basic, create the beautiful.

Programmers often use some very basic code over and over, and while those small bits of programming language aren’t necessarily beautiful in and of themselves, they can come together to create a final product that is amazing. No matter what creative project you’re working on, pay attention to the details, but most especially pay attention to the effect those details have on the overall picture.

Well, I don’t normally function as an advertising agency, but I thought I’d mention to anyone using OS X that there’s a splendid new application out by Lighthead Software. It’s call Papaya and it’s purpose in life is to make sharing files easy and effortless.

Sharing can be such a pain because of problems between Windows and Mac or even just silly things like firewall rules, security, etc. It would be nice if there was a reasonable way to share files that was:

1. Straightforward — don’t make me click around a lot
2. Easy to share — let me IM or email something that people can easily reference in order to access the shared material
3. Used standards that work regardless of your friend’s operating system

Papaya seems to be the answer.

Sharing files locally is automatic. Depending on your router/firewall, sharing files on the Internet may be just a tiny bit complicated but you only have to configure it once. For my own needs, this is beautiful. I can drag and drop files into Papaya, instantly get a link to share with friends and be on my way. No need to email large files, worry about acceptable formats or whatever else.

Papaya is priced at €20( $31 USD as of 5.26.08). If you have a Mac and need to share files, I definitely recommend this.

Also, Lighthead Software also makes the extremely handy Caffeine application that will keep your laptop from sleeping, having the screen dim, etc. It’s a free program and it’s operated with just one click on turn on, one to turn off. I use it often.

To Lighthead Software, thanks for some excellent programs!

There have been a few Slashdot submissions here and here. They’re concerned with an article published by two professors from NYU that assert that Java (and similar high-level languages) are damaging to teach as the “first language” of a Computer Science education. Since I wasn’t a real CS major, I’m perhaps a little outside of this discussion. However, I cut my teeth on C/C++ at school before moving on to the high-level languages (really just .NET and some very high-level languages like Ruby and Python).

I tend to agree with the conclusions. It’s not that there’s no place for Java. It’s just that without the fundamentals of pointers, memory management, and basic understanding of the construction of complex data structures which are just handed to you with Java or .NET, it’s very difficult to fully comprehend what you’re doing

I had a very good professor that taught algorithms and data structures at school and although at the time, the experience was painful, I’m sure it has helped immensely. Despite my affection for things like Ruby on Rails which is extremely high level, I’m annoyed sometimes because of the indeterminacy of functions and the vagueness of the specifications. When you write a language that can do powerful things in one line of code, you’re taking a lot of shortcuts and it can be surprising when a function returns something very unlike what you expected do the complexity of the underlying code. Basically, you ignore things like sorting algorithms entirely in favor of the “built-in” sort routine. How does it work? Well, you can dig it up in the code, but most people will simply use it and assume that it’s the fastest for all of their needs. What happens is that writing code becomes an assembling of pre-built components. It reminds me of “building” Ikea furniture. Granted it takes a certain amount of handiness to put together your new desk but you’re not gaining skills that you can use to build anything yourself without first being handed the pre-built pieces.

I tend to think of myself as primarily a Software Engineer. I’m not just a programmer because I do a lot more than write code. But I’m also not much of a Computer Scientist because I spend very little time actually attempting to improve upon techniques and mechanics of processing information. These definitions are a little vague, but I feel that Software Engineering is more what I do because I apply creativity to the process. I think one can be a Computer Scientist and a Software Engineer but I don’t think my work normally falls into both categories. I’ve always found the role of a traditional Architect to be similar to Software Engineering. It’s an application of creativity (design, color, texture, material, etc.) to a field of science (physics) that results in [hopefully] useful buildings. There are some “cutting edge” Architects that attempt new and innovative projects but most Architects are working with existing ideas and applying them creatively.

I’ve heard that Frank Lloyd Wright’s buildings although amazing in appearance and remarkable in their artistic qualities are often problematic in simple ways. Flooding basements, leaking roofs, etc. were the result of a poor implementation of a great and artistic idea. It’s not enough to be artistic and creative; a good system like a good building works and functions as it should in addition to its aesthetic qualities (which make it unique).

I’ve always seen this distinction between implementation-focused approaches and theory-focused approaches. Implementation is desirable for the production of new applications and system but will always be held back by advances in theory. It seems that Computer Science has largely lost its way in North American schools by focusing too much on implementation without teaching theory. Programmers are cheap. It doesn’t take a lot of brains to assembly code from pre-built components and creativity often is the only difference between a good programmer and a mediocre or poor programmer. Without new advances in theory, applications and systems will simply have to stand on their desirability of implementation (i.e. how easy is to use?). New ideas must be infused into the process for real advances to be made.

The use of so-called AJAX seems an interesting example. The ability to use things like the XMLHttpRequest object were available for quite some time before companies like Google began using it to do amazing things. This is entirely focused on implementation. Web 2.0 applications (whose primary distinction seems to be AJAX technology) are an innovation in implementation only. Many “hard-core” programmers find the terribly sloppy and inefficient results that often result less than satisfying. It does cool things but isn’t there a Better Way? I use AJAX quite a bit these days and it’s handy. However, I have only a bare understanding of how it works and what might be a better design. I don’t tend to concern myself with the next evolution of the Internet– I focus on building things that work with the technologies that now exist. But AJAX really isn’t a huge advance — in fact its “magic” often results in massive security holes, odd and unpredictable behavior, and hugely increased server overhead.

At the same time, a Software Engineer who truly understands the science of the code that he writes is likely to make far fewer mistakes and write much more efficient code. Even without much creativity, a programmer who can optimize code is a desirable catch for any software company. I think that everyone should understand the underlying details of code even if some end up focusing on the creative, implementation focused approach or the theoretically, algorithmic approach.

I mentioned security in regards to AJAX and this seems important. It’s well and good to provide applications that do the same things in easier ways but without a strong cadre of Computer Scientists, developing faster, more secure, and more reliable ways of doing business, we end up with applications that are never properly tested (it’s difficult to test code that just does magical things!) and never adequately secured.

A little rambling of a post — hopefully I’ve managed to convey something. Your comments welcome.