Touching again on the idea that programmers sometimes take things a bit too far, Shannon -jj Behrens remarks: Have you ever noticed that smart, interesting people have weird technical hangups? Often, they take a good idea to its logical conclusion in such a manner that it dominates their lives. Find out about his stubborn friends in Smart People have Weird Hangups.
Joel has a somewhat puzzling piece on the what he sees as the future of Ajax. He makes some excellent points about developing for the future and trusting that technology will catch up with your vision. I would say that any true technology company already knows this. Only internal IT departments code for the present. And that’s only if they’re lucky. Usually they’re developing for the past. Overall, the read is interesting, but it leaves one wondering how well acquainted Joel is with the current state of web development and the tools already available.
The comparison he draws between CICS and HTML is fair. But the fact that CICS systems are still in play means that HTML and HTTP will be around for a long time. The numerous JavaScript frameworks out there are pushing the limits to be sure, and allowing more and more UI goodness on the client side, but the browser is still a browser at the end of the day. Is all the hard work that’s been put into optimizing these JavaScript frameworks for naught? I suppose we will have to wait and see.
So what does Joel think is going to happen?
The winners are going to do what worked at Bell Labs in 1978: build a programming language, like C, that’s portable and efficient. It should compile down to “native” code (native code being JavaScript and DOMs) with different backends for different target platforms, where the compiler writers obsess about performance so you don’t have to. It’ll have all the same performance as native JavaScript with full access to the DOM in a consistent fashion, and it’ll compile down to IE native and Firefox native portably and automatically.
Unless I have seriously misunderstood the Google Web Toolkit, that is exactly what it does. OpenLazlo is another. I’m sure there are other tools I’m unaware of that do the same thing. (Joel’s own Wasabi does something similar, but not for Javascript.)
Further in, he speculates about the “NewSDK” built by “somebody you’ve never heard of, some bratty Y Combinator startup, maybe, is gaining ridiculous traction selling NewSDK, which combines a great portable programming language that compiles to JavaScript, and even better, a huge Ajaxy library that includes all kinds of clever interop features.” Who knows what Parakey was up to anyway?
Again, this is something that is already being done. Adobe has AIR and Flex. Microsoft has Silverlight. Sun has JavaFX. For online/offline synchronization, Google has Gears. The game is already in play. Sure, there are pieces missing. Identity management is MIA, but that may never change due to privacy concerns. No one likes having an ever growing list of passwords, but nobody likes trusting third parties either.
Does the future lie in any of these offerings? Perhaps. So far no one has succeeding in dethroning the browser for web applications.
Typical Programmer accurately captures the bizarre world of programmer interviews, giving names to the patterns we’ve seen time and again. As noted, “People love to talk about themselves, so no matter what kind of interview you find yourself in try to get the interviewers to do most of the talking.”
Jason Kester at Expat Software notes five ways to guarantee you won’t get the job in How to Fail at Freelancing, in 5 Easy Steps.
In short, don’t respond in a disingenuous manner. If you don’t demonstrate care or concern at the proposal stage, why should anyone think you’ll act differently if you get the job? The pressure to act fast and underbid fuel this kind of environment. Unfortunately, many clients respond to it, only to be disappointed by the delivered product. Jason gives advice how to create a thoughtful bid that just might land you the gig.
If you’ve heard folks talking about Erlang, but aren’t sure what it is, or haven’t had time to investigate, ONLamp offers up a great introduction in An Introduction to Erlang by Gregory Brown.
Erlang is known for an extremely elegant concurrency model. I’ve always been one to cringe at the mention of things like mutex locks, race conditions, and the entire motley crew of conceptual baggage that typically come along with any sort of parallel programming.
Joe Armstrong claims in “Programming Erlang” that because Erlang is designed from the ground up for concurrency, it makes life a lot easier. This, along with the promise of a small, efficient,and well thought out language implementation was enough to get me interested.
He starts with the classic “Hello World” and quickly moves up from there.
Lest you be lulled into believing you understand passwords and security, Thomas Ptacek sets you straight in Enough with the Rainbow Tables.
As the web continues to evolve into a platform, and services start to expose themselves through APIs, connecting things quickly, easily, and uniformly is of increasing interest. Allowing sites and services to communicate on the user’s behalf is convenient, but can also put users at risk by forcing them to hand over their credentials. Enter OAuth, “an open protocol to allow secure API authentication in a simple and standard method from desktop and web applications.” Hueniverse offers up a quick introduction to OAuth, and explains how it differs from OpenID.
Many luxury cars today come with a valet key. It is a special key you give the parking attendant and unlike your regular key, will not allow the car to drive more than a mile or two. Some valet keys will not open the trunk, while others will block access to your onboard cell phone address book. Regardless of what restrictions the valet key imposes, the idea is very clever. You give someone limited access to your car with a special key, while using another key to unlock everything else.
OAuth, provides a valet key for the web.
Charging for a service in the “everything should be free” web world can often be a difficult task. Paul Farnell breaks it down and makes it sound sensible in How to Price Your Web Application.
Usually for web applications the costs involved are fairly minimal. It doesn’t make sense to use what’s called “cost plus” pricing — setting your prices X% higher than it costs you to deliver the service. Instead, some things can be justifiably more expensive because of the value they add, or the time they save. In our case the target customers are web designers. They might charge in the region of $30-80/hour. A Litmus account will cost them about $50/month, so as long as we’re saving them more than an hour of time each month, it’s definitely a worthwhile purchase.
There are many essays and articles extolling the virtues of becoming a great programmer. You’ll have a sharp mind, great abstract reasoning skills, and a chance to become wealthy by working mere hours a day. This is what you’ve heard, right?
Sadly, no one ever tells you about the ways in which it will adversely affect your life. The physical effects are obvious. You’ll spend most of your time sitting, probably in an uncomfortable chair that doesn’t promote good posture. You’ll fuel yourself with food that is readily available, meaning it’s more than likely processed and full of sugar and you’ll likely choose either coffee or soda to stave off the drowsiness. A coworker once remarked, “If it doesn’t come out of a vending machine, programmers don’t eat it.”
But I’m not particularly interested in the health risks, as I said, they’re obvious. So what am I talking about? Programming changes more than your body. Programming changes the way you think. You might hear a programmer say, “I like python because it matches the way I think.” Or is it really that they’ve learned to think in python? Regardless of the language employed, you think differently when you program. No decent programmer will deny that. This is why it’s often so hard to explain to someone “how you do that” because, as clear as your explanation may be, you simply think differently. It is this change in thinking that can ruin your life.
The application of programming specific processes and habits to the everyday is where peril lies. The same traits that make you a great programmer can make you an awkward, misunderstood and miserable human being.
Programming presents you with a problem and allows you to eventually solve it provided you don’t quit. A solution is out there somewhere. Make enough attempts and chances are you’ll eventually prevail. Aren’t computers great? They afford a large degree of freedom in problem solving. If nothing else, you are able to make as may attempts as you please and it will happily execute each one. This instills in you a sense that failure is not final. Any obstacle can be hurdled. This is not true in the real world. While you may find second chances now and again, the wheels that turn in the big blue room are largely unforgiving. Time marches on in one direction.
When faced with an interesting programming problem your mind will chew it over in the background. Maybe it’s an algorithm you need to develop, maybe it’s a tricky architecture problem, maybe it’s data that needs to be modeled. It doesn’t matter. Your mind will quietly work the problem over in search of a solution. The “ah-ha!” moment will come when you’re in the shower, or playing Tetris. This practice of constant churning will slowly work its way into the rest of your life. Each problem or puzzle you encounter will start it’s own thread; the toughest and most troubling of which will be blocking.
A program is highly malleable. You can make a nearly unlimited number of changes. You can re-implement. You can optimize. You can run the compile-test-debug cycle ad infinitum. Make a change, see a result. Life is not like this. Every action you take is followed by a commit and the transaction cannot be rolled back. You can continue to make changes and optimizations as you move forward but the effects of these will not be immediately apparent. The instant feedback of development is sorely lacking in real life. Furthermore, your changes might simply be ignored. Data will be skipped. Blocks will not be executed. Optimizations will go unnoticed. The world is resistant to your tinkering.
Programmers become obsessed with perfection. This is why they are constantly talking about rewrites. They cannot resist optimum solutions. Perfection requires tossing aside mediocre ideas in search of great ones. A good programmer would rather leave a problem temporarily unsolved than solve it poorly. A good solution takes into account all predictable outcomes and solves the largest number of them in the most efficient way. This mindset prevents you from writing code with limited utility and life span. While it’s a wonderful trait to have in programming, the demons of scope and efficiency will start to assert themselves on your ordinary life. You will avoid taking care of simple things because the solution is inelegant or simply feels wrong. Time to think will no doubt yield a better result, you’ll say.
The obsession with perfection develops a forward-thinking mindset. The ability to anticipate provides a huge advantage because you won’t waste your time implementing solutions that ultimately fail due to short-sightedness or lack of imagination. You will constantly be mapping out flows and running the permutations through your head. Back in the real world, you will find yourself piecing together plans of breath-taking size and beauty that simultaneously resolve multiple problems and fulfill numerous dreams. You will attempt to kill every bird with one stone. The impossibility of actualizing these plans will be agonizing, yet your mind will continue to pour over every detail as it seeks to anticipate every possible outcome and construct the perfect solution.
Everything is now data. Every bit is worthy of attention. Every interaction is worthy of analysis. Your mind has been trained to do this since it is usually the insignificant or subtle bits that have to be rooted out when debugging. You will find it frustrating that everyone else does not collect and analyze data. You will notice details that others simply gloss over. Your penchant for detail and over-analysis will earn you strange glances and confused shrugs. Your decision making process will resemble that of your peers less and less.
The frantic pace of the software world will instill in you a sense of panic and urgency. You must do everything now. Tomorrow is too late. The thought of working constantly will no longer seem foreign or ridiculous. You will spend your free time feeling guilty about not working. But you will be working. Your hands may not be at the keyboard, but your mind will be.
The romanticized story of young upstarts toiling away in a garage to build the world’s next great company is alluring. It’s easy to convince yourself that the dream is there for the taking. But understand that there are many factors you cannot control. Luck and timing being but two. Don’t miss the life you have in the search for the one you think you want. To quote John Lennon, “Life is what happens while you are busy making other plans.” But perhaps Pascal said it best, “We never keep to the present. We … anticipate the future as if we found it too slow in coming and were trying to hurry it up, or we recall the past as if to stay its too rapid flight. We are so unwise that we wander about in times that do not belong to us and do not think of the only one that does; so vain that we dream of times that are not and blindly flee the only one that is… [We] think of how we are going to arrange things over which we have no control for a time we can never be sure of reaching… Thus we never actually live, but hope to live, and since we are always planning how to be happy, it is inevitable that we should never be so.”
Is programming the road to ruin? Or is it that those with a predilection for detail and mental gymnastics find themselves drawn to it. Perhaps it simply exacerbates a pre-existing mindset. There are certainly other traits (stereotypical or not) that most programmers seem to share. I have focused mainly on the negative impacts, but there are certainly positive ones as well. All things listed as bad can be good if simply kept in check. Obsession is dangerous, and anything great requires obsession. Programming is no exception.
A great explanation of cracking passwords with rainbow tables and the benefits of salting your hashes is to be found in Rainbow Hash Cracking.
