Not long ago I would have said using a Lisp dialect for web development, but now I think that might actually be trendy.

Pencil & paper for a lot of the design & architecture work. I write a lot of little notes to myself in a spiral-bound notebook.

Using immutable data structures. I've jiggered up some Python decorators to handle the copying for me, so all my setters return a new object instead of mutating the old one.

Writing code that's both Flash and JavaScript. A lot of our product is written in the common subset of both languages, with a compatibility library to paper over differences.

It's sort of a bootstrapping process. You build yourself the most basic girlfriend possible, and use her to compile one that's more complete.

Agreed. Great read. And the second point

Leave Yourself a Place to Start (or: Leave work with something small broken)

is something I do all the time. I work Java at my day job, and have found that leaving out the semi-colon at the last place I touched (so that eclipse shows a compile error) really helps me get back to what I was doing the previous evening (or the friday before) so much quicker.

And the last point, get to know your tools. I am currently trying to learn emacs, but I have pretty much mastered eclipse (and other tools that I use). Not having to use the mouse to get to different views and perspectives to browsing around for files, absolutely necessary for improving your productivity at work.

In addition to the last point, getting to know additional tools outside of the development environment really helps. I read websites like lifehacker and have learned of tools like Launchy (on windows). Yes, it takes a while to get used to these tools, but once you have figured them out and configured them to your liking, you can really fly. Though i do get made fun of at work, considering the number of shortcut key combinations that I keep in my head. Invariably, someone will stop by to ask me for a key combo, and I have to type it out because a lot of the times its muscle memory.

[My apologies for the long post]

For my desktop application I've decided to spawn processes rather than threads even though the trend these days is to use processes.

It separates the engine of the app from the GUI, and the interface between is well defined. I use txt + UNIX Pipes to communicate.

Also, any stability issues and memory leaks don't effect the entire app and I get to avoid all the weird concurrency issues of threads.

Agreed. Blub can do everything I need anyway.

I think that being constantly bombarded with images of the Apple and Google UIs, with their unattainable zenlike simplicity, has given me the hacker equivalent of an eating disorder.

Complex GUI -> GUI Complex

Not that it's necessarily a bad thing. I suppose a little cognitive purging now and then never hurt anyone.

The problem is that the third party you refer to has the legal authority to affect what happens to you. It is a different matter entirely, in that case.

so they're roughly on par with World of Warcraft, except they have a much weaker brand?

Yes.

He didn't blame it on Google, which suggests a very strong inability on your part to read. And the fact that you ignore the squeeze on basic freedoms in the U.S. over the last eight years suggests either woeful ignorance on your part, or typical Republican jingoism.

Not cool.

Unfortunately, Google seems to be going the way of America: descent into mediocrity, if not lower.

this blog should come with an option to turn verbosity off.

For Openomy, one of the things that makes our project really exciting day-in and day-out is that we went to a service based architecture early. We don't have one single application for everything and we don't have one single database for everything.

For instance, we have a user service (which controls accounts, sessions, etc and has its own database), a metadata service (which controls what files we know about, what tags they have, etc and has its own database), a file service (which controls the actual binary data of the files and has its own database), etc (we have a few others, but that gets the point across). They talk to each other through REST -- though it could be anything, of course -- to get anything done they might need.

This allows us to scale each service independently, which is great. I'm always surprised at how long it takes folks to move to a SOA.

But, perhaps, the coolest part from an always-hungry-to-try-new-things development team is that having a service based architecture means that we are free from programming language constraints. As long as the language can speak HTTP, we can try it out for a new service or a new client. There's nothing like the feeling you get when mastering a new language. And there's no better way to master a language than write something tens of thousands of people will be using.

So, we have an old front-end built in C#/Mono, we have a couple Rails services, a Java service, our new APIv2.0 (http://api.openomy.com) is written in Haskell/HAppS (which I'm particularly proud of), and now we're writing a client in Scala. And, besides that, we use Perl for some offline scripting tasks.

I think it's pretty unconventional-- but it shouldn't be! I highly recommend going this route.

It's true! When I'm with the ladies I can go on for hours about a random content generator I'm working on for fun, I can forward tons of /. links with explanations about what makes them interesting, I can call with a frequency and average message length just past the line of "creepy," I can be visibly nervous and embarrassingly insecure, and I can show up for teh love having skipped a shower and on 3 hours of sleep. But as long as I throw on a $75 hoodie, some prefaded jeans, and a pair of Pumas, my shit is tight!

""shortly after the US Senate voted away the right of Habeas Corpus""

I am foreign living in USA, and this troubles me a lot. I basically have no right, and can wisked away at will from any american agency, and have absolutely no right to do anything about it if I was labeled a terrorist.

I come from a allay country of USA, but still the lack of abilities to appeal in court, is very frightening, almost fascistic.

Of course not: 91 = 100 - 9 = 10^2 - 3^2 = (10 + 3) * (10 - 3).

1. Forget coding, study management. Managers get more money.

2. NEVER put the word 'test' on a resume. Do not mention it in any interview. If they ask if you tested anything, say no. Lie, if you have to. Say the other guys on the project tested. The kind of people who want to be coders usually do not want to be testers. But if you're a tester once, they'll make you do it for years.

3. As the twig is bent, so grows the tree. The title on your first job will stereotype you for your next, limit some opportunities and opening others. The first two combined will stereotype you even more strongly. And so on.

So be as demanding as you can get away with. Don't just accept what they tell you, unless you really have to.

4. Go to grad school instead. You'll end up making more.

5. A young programmer has to build a rep. One way is by making something famous and open-source. Another is to put "Google" or "Microsoft" on your resume as your first job. Or something like it.

6. Figure out where you want to live. If your career is in finance, the headquarters is often in New York. Embedded systems work is on the West Coast, but all over, too.

7. Defense contractors do a lot of software, mostly embedded. They've been known to write a compiler for an airplane. So drop your al-Queda membership and apply to Lockheed. But it's more bureaucratic and "Methodical" in that world.

8. There are three places to be employed in software: a) A software company. b) A hardware company. c) Everyplace else. Software people are first-class citizens in a software company, second only to the hardware engineers in a hardware company, and somewhere below that in stock brokers, banks, and shoe factories.

By hardware company I would include Intel, Cisco, and Sun, for example.

Web companies might be a 4th category, but I don't know those companies as well. Instead of MBA's or electrical engineers (finance and hardware) you have graphic designers.

What I'm getting at is that if you will be working with other professionals in their kind of company, you will need to learn their needs and their business. In a software company it's a bit of the other way around. At least in terms of status: who is in charge.

8. The right answers have to depend on you, otherwise the advice would be the same for everybody. And we'd all be trying for the same job.

9. I'm not rich, so why believe me?

He interviewed me, or I interviewed him, depending on your perspective; but after Google made their offer (obviously, before I decided against accepting it) rather than during the main interview phase. This was largely a response to the recruiter screwing up and not scheduling any interviews for me with anyone in Google Research.

If you really wanna work at Google, why not build something cool and possibly get bought out by Google instead? Better than trying to join through this (broken?) interview process.

Personally, I'd rather not have 10 different bosses above me... but that's just me.