Slow start to a new project

I'm working on this new project, you see, and it has the proverbial, and necessary,  "blank page".  It's the place where I must execute the work, in the way a writer writes on the blank page.

And I'm staring at it.

And it's staring back at me.

I stare at it, take a sip of coffee, and stare and stare again.

And it stares back at me. Waiting, uncaring and bored.

It's an awkward pause.

Some time passes, the coffee in my cup disappears, and I'm still staring at this blank page thing, and my mind wanders.

And the page stares back at me.

I stare at it.

I blink.

It doesn't.

I stare, increasingly foggy-eyed.

It stares back.

And so on and on. I'm clearly stuck this morning. I'm in a staring contest with my blank page...

...until I'm not!  Aha!  Lightening strikes, and I write something down (so to speak, since I'm not really writing and I can't tell you what I'm doing, but writing is a good-enough analogy).

Bam! Take that, $%#@&!

And now I'm staring at a formerly blank page.

I'm staring at a jejune attempt at work, typographically set and still in a sea of white paper.

Well, crap.


Deletedeletedeletedeletedeletedeletedeletedeletedeletedeletedeletedeletedelete.

And the blank page stares back at me.

Music review

I finally put in my order for new music software (and a few bits of hardware) from my local music gear shop. It's been a long time coming - my last music project dates back to around 2004 or so.

This is exciting! Music software & hardware have come a long way since then, and my last composing & recording rig dated back to mid-90s synthesizers and software.  Some of the new stuff I'm getting is way, way cool.

But the specifics of gear is not what I want to talk about right now.

This whole gear-purchasing spasm really came about as I've been thinking about music ideas for the last two years or so, especially applying my recent experiences in engineering & product to music composition.  In effect, I've had music rattling around my head for a while now, and it's becoming impossible not to compose and record (as a hobby, and not with aspirations of quitting my day-job. I like my day-job, thanks very much).

I've also been listening to my previous catalog of work & critiquing it, asking myself "What works? What doesn't? What keeps my interest? What moves me to abject ennui? What's too long? What's too short? What takes forEVer to get to the point? Have I engaged the listener? Have I kept their interest? Do I surprise them or delight them or challenge them?"

The album from 2000 to which I've been listening. And yeah,
the cover makes no sense.

Specifically, I've been listening to my 2000 effort "Tonecluster" this week, since that was a project in which I was experimenting with space, a limited number of textures, and trying for specific moods. I wanted to hear what worked from a technical perspective, and what my efforts at "slimming down the sound" were like 12 years later.

Some pieces really work for what I intended; some don't, and some are great little experiments that I might never try again, but at the time were real reaches (for me).

Anyway, after listening to this album a few times over the last couple of weeks, I've decided I'm confidently in the "less is more" camp, and will be purchasing the minimum number of virtual instruments necessary to create another album of music that I have boinging (and fizzing and banging and thumping) around my noggin'. And, since 2004, I've sold or given away a crapton of music gear, so I'm left with four different real synthesizers ranging from vintage to modern.

You can hear this old music for yourself, at this link. (You can also download the music, for free, which I encourage if you find you like it enough to add it to your collection).

What will the new music sound like? Heck if I know. I'm all over the place, with ideas for loud rock tumbling around with separate ideas for textures & beats you'd find in a Chillout session.  I will probably end up with a non-genre-specific project (and since genres are arbitrary rubrics anyway why the hell not?),  which is frankly more fun for me anyway. I get to be rust-never-sleeps loud when it suits me, and Tosca-like chilled when it suits me otherwise.

Music on vinyl making a comeback

Old turntable and LP.
(jazzology.blogspot.com)

I've known about the increase of music-industry vinyl sales for few months now, and when I heard about it I was pleasantly surprised.

Not long after I'd heard that sales of music on vinyl were up over the previous year, I was in a conversation about music with some folks at our local bar.

So the kid says to me, "Hey, there's this new thing, it's music on vinyl, like a big disc. You need a special device to hear it, kind of like a DJ turntable. You should check it out, you like music".

Now, either he thinks I'm really young (oh, bless him the little scoundrel), or he's unaware that vinyl pre-dates the recent LP release by Vampire Weekend. I suspect it's the latter, though I'd be happy with the former.

Yes, Virginia, I know what vinyl is.

Tubes.

My first amplifier was my father's hand-me-down Fisher tube amplifier (which started with a primer button - you kept it pressed until the tubes were properly lit). The turntable was some used thing I picked up at the local used-stereo-equipment store (we had those back then), and I'd buy records from the stacks at our local used-record-store (we had those back then).   There was nothing like lying on the floor, album sleeve in hand, reading the back cover. Back then we listened to music. We'd just be there, and listen.

Even when the Walkman cassette players were ubiquitous, we'd still find time to listen to great music. As we were able to buy better gear, the old used stereo rigs were replaced with better-quality amps, speakers, receivers, and so on.  Quality music and listening for the enjoyment of listening hadn't yet been replaced by the convenience of portable, lower-quality music and the use of music simply as a background, a soundtrack, to our (increasingly frenetic) lives.

I'm glad to see vinyl making a comeback. The quality of the LPs are better now then they were at the end of the LP-era; they're thicker, heavier, with deeper grooves.  The quality of music from the big black disc should be high, provided you're using an analog signal chain (whether tube or solid-state) or a digital signal chain containing an excellent DAC (digital-analog-converter).  The LP master (for manufacturing) is probably cut from a 24-bit, 96k sample-rate studio master (or better, if you're artist's producer had the foresight to record at 24/192). In some cases the original may be 16/48k (16 bit, 48k sample rate), but that's still better quality on analog vinyl than you'll get from an mp3.  These days, 24/96 in the music studio is common, so what you're hearing via vinyl is much better than you'll get either on CD (16/44.1) or mp3 (a conveniently small file at the cost of degraded audio quality).

Now, what I really want is a convenient, portable high-quality music I can listen to as the soundtrack for my increasingly frenetic life and an analog system at home with LPs for recreational listening.

Good, bad math joke

An infinite number of mathematicians walk into a bar. The first one tells the bartender he wants a beer. The second one says he wants half a beer. The third one says he wants a fourth of a beer. The bartender puts two beers on the bar and says “You guys need to learn your limits.”

Oof.

Change (again)

Last Thursday, we at Slide (now a part of Google) got word that we were officially shut down, and we'd be moving to other (very interesting) opportunities within Google.  Slide is over, and it's been an interesting and educational run.

Last January, my team was directed to a new project: Photovine. We launched to the public just over a week ago, so one week from launch to dead-pool is about the quickest death of a project I've yet to experience. It was also the best product I've been a part of, and one of the ones about which I'm most proud ("Just Three Words" being the other, outside of a couple of my music projects).

During the time to launch, from January through last week, I had the opportunity to learn how to develop software for the iPhone (iOS, Objective-C), how to be a better engineer in python, and had the opportunity to take what I'd learned from my previous products at Slide and apply them - and so improving overall as an engineer. If any mistakes were to be made, they'd be new mistakes and not repeats of old ones.  ("Tomorrow, make better mistakes". - old sign at old Slide offices)

The Photovine team was comprised of some of the smartest and most talented people I've ever had the good fortune which which to work. To say that it was a collection of creative, smart, hard-working, professional, self-directed and pleasant people would be an understatement.

In the end, we delivered an absolutely fantastic product. Here's what some of the tech writers and bloggers had to say about it during it's short run:

"...and we think it goes without saying Photovine was Google’s best designed piece of software. Period."

"The concept is certainly fun...Definitely worth checking this one out."

" Design-wise it’s beautiful....The community is growing at an exponential rate and there are some seriously clever, interesting and beautiful photos being shared already."

I'm very proud of the work we did on this app. It could have been just another photo-sharing app, but it was most definitely not that - it was a way to discover people via the medium of a topical, shared photograph. The fact that a community sprung up almost immediately around Photovine (within days of launching our restricted-access beta version) does not surprise me.

As an engineer, I had a great time - we went from knowing next to nothing about iPhone development to becoming very proficient in a very short time, and I had the opportunity to work with engineers whose styles and proficiencies in many ways complemented my own. I learned a lot from those guys, and I can only hope that they in turn learned something from me as well.


So now, on to new things. I don't know what these new things are yet - the upcoming weeks are filled with meetings and planning - but I'm certain it will be interesting.   New opportunities, and new possibilities, and although every day offers nearly endless possibilities, at the moment that fact has a clarity of focus that is pretty exciting.

In the meanwhile, I've started up some music projects again. It's been six or seven years since my last music work - you can hear it over at www.jasonrubenstein.com and all of my music is free for download, and free for listening. I'm seeing more and more work being done (and more and more companies started) in the intersection of music and social, and am keeping my eyes open on this one.

And I'm still fiddling around with the website project I started many weeks ago. It's on my personal (non-public) server at home, and now that I'm out of a "OMG we're launching a product" kind of schedule, I'll get back to it.

How to survive identity theft

Waitasecond. Someone out there is pretending to be me? Attempting to get credit? In my name? Why those dirty bastards!

This, dear readers, is how to prepare for, and deal with, identity theft.


What happened?
Someone, persons unknown to me, pretended to be me in order to attain credit at department stores and buy things. Expensive things. Really expensive things.


How'd they do this, JRub?
They had my name, my SSN, my phone number, and a driver's license with my current address.  They walked into a few really swish department stores and, pretending to be me, tried to buy designer-label goods. Little do they know I'm an Armani or a Zegna kind of man, and clearly not a Ferragamo or a Paul Smith dude. Pfft. Idiots.


How'd they get that info!?
I haven't a clue. I have some guesses, all semi-educated, as to how they might fish up my personal info. But lets leave it at that - they got it, and they used it.


What happened?
Very little. Most credit for this schmuck was denied. And I found about it out so quickly that the door of felonius opportunity slammed shut so fast that the dumb bastard couldn't get away with very much.


How'd you find out?

• I subscribe to a credit-monitoring service (see below) and received an alert of several credit inquiries against my report.
  
  
• One of the retail stores called me to ask ..."if I still wanted the Ferragamo". I did not; That was not me; I was not in the store that day (or week, or month). This confirmed the credit-monitoring alert that someone was pretending to be me. I got as much information as I could from the store clerk who called me.
  
  
• I received a letter from another retail credit company asking for verification of identity. Again, it wasn't me.
  
  
• Once I knew there was fraud going on, I called each and every credit fraud dept at each business for each incident of which I was made aware by the credit monitoring service. I asked for as much information from them as possible and answered all of their questions. 

How to protect yourself before any fraud occurs. Or: the paranoid, proactive part of the story
Years ago I purchased a subscription to one of those credit-monitoring services. Whenever there is a change of any kind to my credit on any or all of Experian, Equifax, or Trans-Union reports, I receive an email indicating the change and the approximate date of activity.

This, it turns out, was a wise move:

• Good: I received an email within days of several credit inquiries against my credit history.
  
  
• Bad: Some (but not all) of the reporting was up to 4 days behind the actual credit inquiry event, and two days behind a fraudulent credit event. I'd have liked the notification to have been within hours of every, and not just some, activity, but: a few days at most is better than nothing, or than a month.
  
  
• Summary: GOOD, because I found out that something fishy and illegal was going in within days, and not weeks, of the event(s). I was able to respond very quickly and shut the door of criminal opportunity.

Without this service, I would not have known that some loser was out there lining up credit in my name, using my personal information, as quickly as I did.


What happens when someone steals your identity (Or: the reactive part of the story):

1. As soon as you get notice from your credit-monitoring service (usually via email, but you can get notices via SMS) that funny business is going on with your credit history, read this: The FTC Guide to Recovery from Identity Theft.
   
   
2. Place a fraud alert on your credit reports at all three agencies.
   
   
3. Place a security freeze on your credit reports at all three agencies.
   
   
4. Immediately, and I do mean immediately, contact the creditors' credit-fraud departments and get the credit lines canceled (or suspended).
   Get as much information as you can from them as possible as to what information the thief had, what they purchased, when, and where. Get the mailing address and email (or fax number) of the credit fraud department, and if they have their own fraud claim form, have them send one to you. You'll need the information you receive from them in later steps, below.
   
   
5. File a police report with your local police. (I walked to my local police station with all the paperwork I needed, organized, and prepared. The officer was very helpful: I made his job easy and he went the extra mile for me).
   
   
6. File an FTC Identity-theft complaint form. You can use this to help get the fraudulent credit canceled by the creditors as well as removed from the credit agencies' reports. This is where you'll need the information you asked for from the credit fraud department (above).
   
   
7. Send a copy of the FTC form, and any police reports if available (you should at least have the report or case number) to the creditors' fraud claims department. Send it via fax, email, and regular mail. If the fraud department(s) have their own form, of course fill that out and return it as well.
   
   
8. Contest any fraudulent credit reporting with each credit bureau. You may need to send them copies of the reports as well.
   
   
9. Don't let up until the fraud has been removed from your credit reports, and you're not responsible for paying anything. Not one thin dime. Keep contesting the credit report, and keep at it.
   
   
10. Watch your mail over the coming months. You may receive a bill for credit you've never asked for, or a letter requesting clarification of identity, or a bill for some new service, or a collections notice. This is indication of additional fraud the credit monitor may not have picked up or been alerted to, and you'll need to act.

In summary: Do not fuck around. Act, and act immediately. Show the world (and the would-be creditors, and the credit bureaus) that you are like-a-goddam-heart-attack serious.

WTF are these credit bureau or credit agency things you're talking about, Mr. Rubble?

• Experian
• Equifax
• Trans-Union

If you don't know what a credit bureau is, and you're in the U.S., read this: http://en.wikipedia.org/wiki/Credit_bureau#United_States

Can't I get a free copy of my credit report?

Why yes; yes, you can. Read here for more info:

http://www.fdic.gov/consumers/consumer/ccc/reporting.html

What else can I do to prevent loss, web identity theft, hacking, or other financial damage?

Here are some general tips that can help you reduce the probability of significant financial loss.

1. Register with a credit-monitoring service that covers all three major bureaus, or with the credit-monitoring service of one (or all) of the credit bureaus.
   
   
2. If the monitoring service alerts you to activity that you did not initiate, act immediately. (see above)
   
   
3. Use complex passwords for every website you use.
• a simple password is one that reads like a real language or sequence: examples are "fluffy", "fido", "123 Main Street", "123456789", "1020304050" or even keyboard patterns that are easily guessed like "1q2w3e", "qwerty", "asdfgh", and so on. Also, any proper name like "Chicago", "Dixon", "Sacramento", "OMalley", "Goldberg", "Lee", "Twilight", "Harry Potter", "Serenity".   Do Not Use These.
  
  
• a complex password is a password made up of a wild mix of UPPERCASE letters, lowercase letters, digits, and if possible symbols ("@#$%&_.").  A great example of a complex password looks nothing like a real language: for example "nj2.TXd5", "A7&M20vkL", or "788$jK6b00Y4H!".
  
  
4. Never, ever, ever, ever, ever use the same password at more than one website.
   
   
5. No, really, I'm not kidding. Re-read that until you are ready to puke potted-violets. Never, and I mean never, use the same password twice. Don't complain to me about how hard it is to remember crazy complicated passwords all over the place! This is YOUR bank account / IRA / 401k / Level 85 Night Elf Warrior. Not mine. I'm just trying to give some reasonable advice here. Use unique passwords.
   
   
6. If possible, for banks and other sites that have access to your money (whether cash or credit), use the longest password possible. If you like, use a password manager. Some of my passwords are 32-characters long. No kidding. And they look like a someone left a box of Alpha-Bits on a live land-mine.
   
   
7. And, whenever possible, use different user names (login IDs, whatever you want to call it). Some sites restrict you to using your email address  ("johndoe@some-email.com"), but if you can use different ones for different sites, go for it: "john.doe", jdoe1975, johnqdoe, johndough, and so on.
   
   
8. Shred any documents at home before tossing them into the recycling bin.  (Hey, look! Shredders!) Believe it or not, some people like to dive into the dumpster behind your apartment building and look for documents that contain personal information. Yes, I know: these people are losers. But rather that sit there and psychoanalyze these jerks, instead do yourself a favor and buy a shredder.
   
   
9. Go through your email and delete any email that has a password from a website in it. On the odd, but possible, chance your email is compromised, at least the thief won't be able to get to any other accounts whose credentials are lurking in your email. Make sure you "Empty the trash" of your email service, if possible. 

There are probably more things you can do to protect your credit and your assets. This is  a good start. 

There is no such thing as perfect security. But remember: "Perfect is the enemy of Good". These steps should reduce the probability that your online identity will be compromised.

Finally, a new project

I'm finally working on a new personal website.

It will be jasonrubenstein.com.

I haven't worked on a personal project of any kind in a few years. I haven't had the interest, really, but in the last few weeks something has been nagging at me. I needed to build something because NOT building anything was Driving. Me. Nuts.

So, a new personal website, my little "ME!" on the interwebs.

I'll have my music up there, and some words made into sentences corralled into paragraphs, and some photos, and some other things.

Yesterday morning, after the rolling up of sleeves and the brewing and drinking of coffee, I dove into hand-coding html and css to create a basic prototype of the design I have in mind. The design is minimalist, with at most three fonts (two sans-serif and one serif). Much like in music, where what is between the notes is as important (and sometimes more important) than the collected notes, what's not in space is as important (and sometimes more important) than what is collected in other parts of the space. I'm keeping this in mind as I go.

Back to yesterday: once I had a working prototype of a webpage, I shattered it into several pieces.

Those pieces became the building-blocks for several web pages.

Once I had the pieces of the shattered webpage, I jumped into python and built a little webpage-builder function that consumes shards of  shattered prototype-webpage and produces several new, different, webpages.  This little, and simple, html rendering engine builds the pages for my new website.

Once I turned the webpage-shards into proper webpages, I used a couple of open-source packages to set up a webserver. Using Greenhouse and Feather, I set up a little server in the comfort of my own home. (The future! It is here!)

I made a deliberate and certain decision to eschew the use of a templating engine (Cheetah, Mako, etc). I'm having more fun writing my own rendering functions.  I'm not using a framework because, well, what fun would that be? That and I'm not framing a subdivision of houses, I'm building a little mid-century-modern joint with big windows and Helvetica.

I may use jQuery or some other javascript library, but at the moment have no need for one.

I'm shooting for simple.

I decided against more commonly used http server solutions as I want to work with a newer open-source package and help work out the kinks in whatever way I can.

Yesterday, from 7am through 7pm, was really, exceptionally, fun.

I've been experimenting with fonts with the intention of beautiful web typography. I love typography and clean, minimalist design, and I'm going to see if I can get what's in my imagination out onto the screen.

I'm learning different things than I learn at work, and remembering things I have forgotten I knew. (Or at least I've forgotten that I remembered how to do some of this stuff a few years ago but in the meantime of non-use had forgotten to remember it, or simply forgot it, and now have remembered where I put some of this knowledge).

This project is going to take a while. I have a few pages of content to work through followed by wrestling some css into submission. Not to mention some spit&polish of the http server, the image server, and deciding from where the hell to serve the mp3 files of music.

But since I have an addiction to shipping product, this thing will be live relatively soon.

The most important thing, the thing that is most important, the point that makes the point is: I'm finally, Finally, finally working on a project for the love of working on, and shipping, a project. I want to learn, hands-on,  how servers along the lines of Greenhouse and Eventlet really work, and how something like Feather or Spawning really work. I want to hack at css to make pretty san-serif to happen on my computer screen, even though the problem has been solved 132,619 times already.

So, I'm doing this because not doing it was becoming impossible. Well, and the vanity of my name on a live website that's all about me.

Vanity might have a little to do with this.

Update: At lunch, a friend asked me if I thought I was over-engineering a solution for a very simple project (a static website). Yes, I am! The website is the macguffin , the thing that gives me the reason to go on this journey of coding. I could just set up nginx and serve html and be done with it. But that's not the point to me; the point to me, right now, is rolling up my sleeves and playing with some tech.   Next round, I'll work on something that solves a real problem.  This round, the problem I want to solve is personal, and not technical.

"What qualities make a good startup engineer?"

My answer on Quora.com to the question "What qualities make a good startup engineer?" (originally written on Quora and copied below):

1. The ability to "get s*** done. This is too vague a description for an attribute, so: The ability to recognize a "best fit" solution to a particular (product) problem or requirement and implement it as quickly as possible, also recognizing that the best solution for the product **right now** may mean acquiring some technical dept to be paid later. Another way to say it is the ability to ship as quickly as possible probably without adherence to some engineering dogma. Ship! 

1a. Very important: knowing when to pay off technical debt. It can be more of an art than a science, and at times it's blatantly obvious; I'm not sure whether this is an acquired or a native skill, but it's important. 

1b. Love your own code, and love to rewrite your own code. Don't be precious with it. Your code is not you, you are not your code. Rewriting your own work is a perk of the job, not a chore. 

2. The ability to learn very quickly. I believe this implies some (high) level of intellectual curiosity, as the best learners (in my experience) are also very intellectually curious. This doesn't just mean learning new-to-them engineering knowledge, but also new-to-them people/management/social/etc. knowledge. 

3. The ability to suspend the behavior most commonly associated with jerks, a**h***s and know-it-all software engineers. Also, see #2, as a part of working in groups is learning how to work in groups as a civilized person and not akin to a chimpanzee throwing your poo at people you think are idiots. This is especially important (it seems) for extremely intelligent engineers accustomed to being the smartest person in the room in most other situations. 

4. Related to #3 is learning to trust the other people in your startup, and trusting that they are just as smart (and in some areas of expertise, smarter) than you. Trust that the people around you are fantastic. And learn from as many of them as possible. 

5. Also related to #2 is learning very quickly how to handle stress. I must put the emphasis here on learning what shifts in behavior and habit will get you through it all over purely cognitive solutions. Changing diet, getting enough sleep (where "enough" is relative, but learning when "enough" is enough if you get my meaning), and other changes in lifestyle are what I'm suggesting (among others). It's one thing to convince yourself that you're handling the stress, it's another to actively take action to counteract the effects of stress. Pro-tip: breakfast cereal at every meal and 3 hours of sleep per night only get you so far - probably to MVP. After that, you're in a marathon; learn to run a marathon. I'm not suggesting a "work/life" balance. I'm suggesting a "work/recharge-for-more-work" balance. 

6. Experience. If possible. If not, see #2. 

7. Somewhat related to #6 is knowing what tools to use in your trade. For example, knowing when something is more appropriate to use (I.e., well-established, broad base of support, very active and numerous community) vs. when some new, hot, (probably fashionable) new technology is at least not entirely inappropriate (brand new, not proven to scale, but so very very cool new tech) but probably inappropriate for the immediate task at hand. And vice-versa - when it is OK to use some yet-to-be-annealed-in-the-furnace-of-a-quickly-growing-product-of-a-successful-startup technology.

8. Honesty, personal responsibility. I've seen otherwise honest engineers show their compulsive-liar side when put under extreme pressure (usually after very little sleep), or called-to-task for some error of judgement. Stand up, admit mistakes, and see #2 as usual. Learn from the error

Avoiding Burnout

Sure, all-nighters can be fun once in a while. And 16-to-20-hour-days can be very rewarding when you're starting your own company or working at one about which you're excited. But no one, even you the 20-something hyperactive borderline-ADD super-evil-genius engineer, can keep it up for weeks on end and remain effective.  Beware burn-out!

How do I know?

The Mayo Clinic advises the following as possible signs of burn-out:

• Have you become cynical or critical at work?
• Do you drag yourself to work and have trouble getting started once you arrive?
• Have you become irritable or impatient with co-workers, customers or clients?
• Do you lack the energy to be consistently productive?
• Do you lack satisfaction from your achievements?
• Do you feel disillusioned about your job?
• Are you using food, drugs or alcohol to feel better or to simply not feel?
• Have your sleep habits or appetite changed?
• Are you troubled by unexplained headaches, backaches or other physical complaints?

Advice for the Engineer

Learn to run a marathon, not a sprint. Learn how much sleep you need every night to perform at a consistently high level for many years. Consider vacation a part of your compensation; the way you consider a paycheck. (Would you really want your boss withholding a paycheck because "it just isn't a good time right now"?)  Learn when you need to recharge your batteries, and go away and recharge them.

Live, sleep and eat in such a way as to maximize your cognitive abilities.

Find something away from work on which to focus. Whether it's the gym, cooking, riding a bicycle, reading.. whatever, as long as it isn't coding. Do this thing most days of the week.

Find a manager you trust, and trust your co-workers to carry the load while you're away. If you can't trust them, find some to trust.

When you're working - work. Focus, concentrate, pay attention, do your absolute best. The same goes for when you're not working: when you're asleep, your job is to sleep. Focus on that and don't worry about work. Divide your time into highly-focused, separate cycles. When you're not working, focus on not working.

Find the number of productive hours per day that works for you. I bet it's many more than 8 and less than 18. How many of those hours are ones in which you're working on difficult problems that require highly-focused cognition, and how many are those in which you're only good for answering emails, perusing CSS, tuning documentation, or catching up on Hacker News? And at what point are you a useless, over-caffeinated lump in a hoodie, only useful for converting O2 into CO2? Figure out what works for you.

It's more fun to be pleasant, happy, and fun to be around! Being a cranky, burned-out curmudgeon sucks, for you and for people around you. If you see someone who's work habits are leading them to a crispy end, try to mentor them a bit into a better work cycle:

Take responsibility for your people. Work on lowering the probability that someone will burn-out. If you see someone who's burned out (and they report to you), get them out of the office and in a vacation. It's either that or work them until they quit - or get fired. 

If your employees (or subordinates) are not important to you, and if the intellectual property in their heads is not valuable to you, by all means work them to the bitter-end, until they quit.  

If you care about your company and want to keep talented, very-hard-working engineers in your employ, help them prevent burning-out and make sure they take vacation (as a manager, you should worry that your best and/or most enthusiastic engineers won't take vacation at all rather than worry they'll take too much). Assist them in their "work-life" balance. For many engineers, work is their life and their life is their work; instead, you may need to assist them in their "work-recharge" balance.

Take responsibility for yourself; if you start to feel edge, cranky, cognitively dull, stressed and unable to sleep you may need to get away. Better yet is to plan vacations months in advance, and make them indelible in your calendar. Be proactive with your "recharge" time. Take responsibility for it; it's best to be the engineer your manager never has to watch for signs of burn-out because you've already preempted the possibility.

What do you mean by "Everything"?

I had a great meeting with someone the other day who, during the course of our conversation, questioned my statement in my post below¹ that "Everything does not need to be a Class".  His rationale was that if something had attributes, it should be a class. I realized that this point of mine needed clarification.

I like Classes that represent some real-world object; whether tangible (car) or intangible (transaction). It's a thing that has real attributes which, when taken as a whole, comprise that thing.  So sure, create a Class and instantiate it a few times as needed to get a few things happily bouncing around your system. If it has an analogue in the physical world, it's an excellent candidate for a Class.

What I object to can be shown by example: A Class composed of a collection data transformation functions. Why does this need to be an Object? It's a module full of functions, really, and does not need the additional layer of Class in there to wrap the methods. This Class doesn't represent a thing, and doesn't have attributes. I'd recommend module-level functions.

Another example is best demonstrated by a process that does the following:
1. Generate some JSON for consumption by a web client
2. Wrap this JSON in an instance of a class (no other attributes).
3. Send this object to the client.
4. The client unwraps the JSON from the object
5. The client consumes the JSON.

I object that there needs to be an Object here.  I'd rather see
1. Generate some JSON for consumption by a web client.
2. Send the JSON to the client
3. The client consumes the JSON.

I fully realize that all of this sounds (and is) absolutely elementary.  And yet, I run into over-Objectification more frequently than I believe is desirable. (The whole wrap-JSON-in-an-object was rationalized by the engineer, "Everything in the system is an object, and I wanted to be consistent".  Someone else was optimizing for the future, "We might need more stuff sent to the front-end someday. This makes it a no-brainer for the next engineer".)

"If all you have is an OOP, everything looks like a Class".  I believe that engineers should have a whole box of tools from which to choose, and OO is one of those tools among others. When everything in your system is an object, it's clear that your toolbag contains only one tool. Even worse is when every object inherits from some other object, sometimes in stacks of 5, 7, 12 Classes high. (e.g., no use of object-composition whatsoever: conflation of the "Is-A" ad "Has-A" relationship concepts, conflation of data and function, etc).  And, once again, ultimately we're engineers in a business; our responsibility is not at all to the gods of OO, it is to the business.  It's very valuable to learn when a Class is absolutely appropriate and awesome, and when It Is Not.


1. http://jasonrubenstein.blogspot.com/2010/04/thoughts-and-advice-part-0.html

News

Quick update:

Yes, I'm back at Slide, and yes, we've just been acquired by Google.

Look out, world.

Thoughts and Advice, part 0

General advice regarding engineering

Some tenets:

1. Everything does not need to be a Class. 
2. When you do use Classes, consider composition.
3. Keep it simple.
4. Ask yourself, "Now that I consider this complete, how can I make it simpler?"
5. Can any reasonably talented and/or experienced engineer read what I have created and extend it/modify it in as little time and as effectively (e.g., regression-free) as possible?
6. Ask yourself, "Have I separated data from function?"
7. See 3. (above)
8. "There are many right ways to do the task" does not mean there are not wrong ways to do the task[2].  If one can say "All things being equal, this is a correct way to do this task", one must remember that all things are never equal, and the solution you are proposing may violate or lay beyond the principles of the existing robust architecture. If it does violate the principles of the existing and robust architecture, it is indeed a bad solution and you probably shouldn't do it.
9. When in doubt, find two or three engineers whom you respect and ask their opinion. Better yet, get them together and present your idea/solution to them (preferably at a white-board). The act of explanation slows down your thought process, and activates a different part of the brain (you engage in a different cognitive process than you do just sitting there, ruminating). It forces you to clearly articulate and  linearly work through the solution. Then: make an educated best-guess.[3]
10. If your rebuttal to anything starts with "Yeah, but..", stop and reconsider your argument.
11. Rationalizing a bad decision does not alter the quality of that decision. While not all bad decisions can be mitigated right now, don't conflate time- and project-management with the idea that "it was the best we could do at the time, therefore it's as good-code as everything else in the system".  Rather, "Yeah, I know it sucks, and we'll fix it when it's opportune; for the moment we have to live with it".

Some fallacies:

1. Everything needs to be a Class.
2. Functional programming "doesn't work"
3. Imperative (procedural) programming "doesn't work"
4. [software that is used very successfully around the world] "doesn't work"
5. Everything must be an Object. 
6. The more complicated it is, the better the system.
7. "I don't need to explain myself, just do what I tell you."
8. Picking emotionally immature managers will result in a mature, professional organization.
9. "Ur doin it rong". (See 7. and 8. above)
10. Great engineers always make great managers.
11. Code is a good outlet to demonstrate to other engineers/the world/my mom how brilliant I really am.
12. "My code will help The Singularity arrive more quickly".
13. "The names of things doesn't matter - a good engineer should be able to read the code and know what things are". (Imagine an Exception class named "Fred".  raise Fred('there has been a problem') is meaningless).[4]

[1] Project specifications are generally a static 'snapshot' of an evolving business process. The business changes rapidly as the people running the company must respond to changing market conditions. It's dynamic. We are engineers, but we do not work in a vacuum. We must act as engineer/entrepreneurs.

[2] Via Libor 

[3] If you work for a good manager, they'll  understand that part of their job is to help you recover from bad (although reasoned) decisions and failures; they will also understand that it is not a part of their job to try to prevent you from making bad (although reasoned) guesses/failures. [http://hbr.org/2008/09/how-pixar-fosters-collective-creativity/ar/1]. They should strongly advise you against making unreasoned, and unreasonable, decisions.

[4] _items = items.item.Item.items() and from items.item import Item is also ridiculous. As are one-letter attribute names and attribute names that still conform to 1970's-era 6-character name limitations.  Also ridiculous is code that isn't sufficiently namespaced: import game.store.items as stitems and import game.trade.items as tritems is ridiculous.  Worse yet is import game.challenges.exceptions as lolufailz. No, really. Don't do that.

How to be a Programmer

Time and time again, I return to this classic essay by Robert L. Read.

Debugging is the cornerstone of being a programmer. The first meaning of the verb to debug is to remove errors, but the meaning that really matters is to see into the execution of a program by examining it. A programmer that cannot debug effectively is blind.

Idealists that think design, or analysis, or complexity theory, or whatnot, are more fundamental are not working programmers. The working programmer does not live in an ideal world. Even if you are perfect, your are surrounded by and must interact with code written by major software companies, organizations like GNU, and your colleagues. Most of this code is imperfect and imperfectly documented. Without the ability to gain visibility into the execution of this code the slightest bump will throw you permanently. Often this visibility can only be gained by experimentation, that is, debugging. 

 If you're an engineer, this is a must-read.   Related: this thread on Quora. And more quotes from the essay after the break.

Discover Information

You might have noticed that if you scroll down on this blog, a bar appears at the top. Go ahead, scroll down a bit now, I'll wait.

Cool, isn't it? It's means that I have Apture 2.0-beta installed on the blog. This is a way to discover more information. Gain more knowledge! It's also a way to share that information and knowledge with the world.

For example....
Now try this: highlight this word: Iran. (You can highlight a word by double-clicking on it, or by dragging the mouse over it). See that little thought-bubble that says "Search"?  Click it. (or hit Control-C)

Now you have a bunch of relevant links to information up to your right. Click on one, and a small box with that information appears. Now click on a few. Now you have a few windows of relevant information for the term (or phrase) in the page about which you wanted more knowledge and.or were curious about.

Information, knowledge, context, discovery
This is cool. So when I write all sorts of technobabble like "I'm skeptical about the value of designing systems in python using only object inheritance without also considering object composition", readers unfamiliar with the esoteric nomenclature of object-oriented programming can use Apture to quickly and easily learn more about wtf I'm talking about, and gain a greater context in which to understand the discussion.

You are not entitled to your opinion; you are entitled to your informed opinion. If you are not informed on the subject, then your opinion counts for nothing.
~ Harlan Ellison

I want it everywhere.
I've been using Apture 2.0 beta for a few days now, and I'm addicted to it. I want it on every page I visit, especially on those where I frequently find a term or subject with which I am unfamiliar.

So enjoy! And please let me know what you think.

Update: More information at our Apture blog.

.

Brian Eno on context

Brian Eno discusses context by way of the analogy of how one listens to Miles Davis:

[from The Wire Dec./Jan. 1993] When you listen to Miles Davis, how much of what you hear is music, and how much is context? Another way of saying that is, 'What would you be hearing if you didn't know you were listening to Miles Davis?' I think of context as everything that isn't physically contained in the grooves of the record, and in his case that seems quite a lot. It includes your knowledge, first of all, that everyone else says he's great: that must modify the way you hear him. But it also includes a host of other strands: that he was a handsome and imposing man, a member of a romantic minority, that he played with Charlie Parker, that he spans generations, that he underwent various addictions, that he married Cicely Tyson, that he dressed well, that Jean-Luc Godard liked him, that he wore shades and was very cool, that he himself said little about his work, and so on. Surely all that affects how you hear him: I mean, could it possibly have felt the same if he'd been an overweight heating engineer from Oslo? When you listen to music, Aren't you also 'listening' to all the stuff around it, too? How important is that to the experience you' re having, and is it differently important with different musics, different artists?

Miles was an intelligent man, by all accounts, and must have become increasingly aware of the power of his personal charisma, especially in the later years as he watched his reputation grow over his declining trumpeting skills. Perhaps he said to himself: 'These people are hearing a lot more context than music, so perhaps I accept that I am now primarily a context maker. My art is not just what comes out of the end of my trumpet or appears on a record, but a larger experience which is intimately connected to who I appear to be, to my life and charisma, to the Miles Davis story." In that scenario, the 'music', the sonic bit, could end up being quite a small part of the whole experience. Developing the context- the package, the delivery system, the buzz, the spin, the story - might itself become the art. Like perfume...

Professional critics in particular find such suggestions objectionable. They have invested heavily in the idea that music itself offers intrinsic, objective, self contained criteria that allow you to make judgments of worthiness. In the pursuit of True Value and other things with capital letters, they reject as immoral the idea that an artist could be 'manipulative' in this way. It seems to them cynical: they want to believe: to be certain that this was The Truth, a pure expression of spirit wrought in sound. They want it to 'out there', 'real', but now they're getting the message that what its worth is sort of connected with how much they're prepared to take part in the fabrication of a story about it. Awful! To discover that you're actually a co-conspirator in the creation of value, caught in the act of make-believe. 'How can it be worth anything if I did it myself?'

I remember seeing a thing on TV years ago. An Indonesian shaman was treating sick people by apparently reaching into their bodies and pulling out bloody rags which he claimed were the cause of their disease. It all took place in dim light, in smoky huts, after intense incantations. A Western team filmed him with infrared cameras and, of course, were able to show that he was performing a conjuring trick. He wasn't taking anything out of their bodies after all. So he was a fake, no? Well, maybe-- but his patients kept getting better. He was healing by context-- making a psychological space where people somehow got themselves well. The rag was just a prop. Was Miles, with a trumpet as a prop, making a place where we, in our collective imaginations, could somehow have great musical experiences? I think so. Thanks, Miles, and thanks everyone else who took part, too.
BRIAN ENO 

 (via hyperreal.org)

Closing one door, opening another one

Today is my last day at Slide. After two-plus years of being a Slider, I resigned a couple of weeks ago to join the gang at Apture. While I'm sad to leave Slide, I'm excited to join Apture.

I'll be moving from a company of over 100 people to a company of around 10 people.

When I started at Slide, we were somewhere between 50-70 people, and each team within the company felt like a mini-startup. I worked wild hours and loved it, and had a lot of fun working with the brilliant people by whom I was surrounded. Literally surrounded: our office at the time was essentially one big room, and we were packed in like obsessive-compulsive python-chewing sardines. At one point I shared a cheap Ikea desk with a QA engineer's pet fish.

Slide is a bigger company now and, while still maintaining some of the "scappy little startup" atmosphere, has grown into the "now we're a real company" phase. And while I loved going to work every day, I began to yearn for the 5-10 person sized company.

I had no intention of leaving Slide so soon, and I won't be ready to start a company of my own again until I've slept for a month straight and taken a vacation in some sunny, gin-and-tonic laden locale. But after several serendipitous conversations with Tristan, Can, and Steven, I felt that we could "make good jazz" together (I'll explain what that means in a later post).

Slide was, and is, a great place to work. When the opportunity to work at Slide came to me in an email from Max, I drove from Los Angeles to San Francisco the next day. Within a week of signing the offer, I had packed almost everything from the home-office rental in Topanga (from where Paul and I launched several products including our reasonably successful Facebook app) to SoMa. I'll miss the place and the people at Slide.

I'm very excited to work with the team at Apture on an extremely cool-and-useful product, and once again with some very smart people. You can see some of our product in this blog-post, but I'm sure that the best is yet to come.

Programming as an objective art

Managing or working with any team of highly motivated, passionate and creative developers presents this problem, as a group: how can you objectively judge code while preserving the sense of ownership by the author?

The first step to objectively judging code in my opinion, is to separate it from the individual who wrote it when discussing the code. For a lot of people this is easier said than done, particularly for younger engineers like myself. Younger engineers tend to have "more to prove" and are thereby far more emotionally invested in the code that they write, while older engineers whether by experience or simply by having written more code than their younger counterparts are able to distance themselves emotionally more easily from the code that they write. Not to say older engineers aren't emotionally invested in their work, in my experience they typically are, it's just a matter being better at picking battles.

Apple on Design

During the design process, if you discover problems with your product design, you might consider applying the 80 percent solution—that is, designing your software to meet the needs of at least 80 percent of your users. This type of design typically favors simpler, more elegant approaches to problems.
If you try to design for the 20 percent of your target audience who are power users, your design may not be usable by the other 80 percent of users. Even though that smaller group of power users is likely to have good ideas for features, the majority of your user base may not think in the same way. Involving a broad range of users in your design process can help you find the 80 percent solution.

Read the whole thing, as they say.

Of the ten best engineers with whom I have worked...

6 do not have a C.S. degree,
2 have a liberal-arts degree,
1 has an engineering-related graduate (and post-graduate) degree,
4 did not finish college (or did not attend), instead opting for entering business,
2 are women (because I know someone's going to ask), 
5 are over 40.

This deserves some additional commentary, to which I will have to attend later. 

(I'd been thinking that of the best engineers I know, the majority did not finish university or did not attend. I'd also thought that many, or most, of them had some sort of liberal-arts study. I quickly compiled a list and derived some elementary statistics in order to do a quick analysis of my supposition. More on this later.)

test

asparagus

squiggle

Suicyclists

You ride a bicycle?

This is your must-read for today:
http://unethicalblogger.com/posts/2010/02/i_hope_you_bump_your_head

Plan for community

If people love your game/site/product/etc., they'll be compelled to talk about it, brag to their friends about their involvement with it, share ideas about it, complain about it... in short: they'll feel a natural compulsion to get involved.

While working on an idea for a product, make sure that the community elements are intrinsic* to your product.  Your product must be comprised of many things, one of which must be some sort of mechanism for community involvement.

For example, if you're building a game, insure that one or some of the core mechanics implemented are dependent on community involvement. For a non-game, insure that there's some necessary community involvement from the earliest customer contact.

From the start, make certain that community is one of your behavioristic design components**.

The alternative is to build something, launch, and subsequently "bolt-on" a community, usually in the form of a bulletin board/forum. What happens in this case, unfortunately, is that (usually) by the time you get around to it there's already one out there created by your fanatic customers, and you now have to either co-opt theirs or build your own and compete with it.***



*adjective: belonging naturally; essential
** And please, don't be cynical with your behaviorist design. We're not mice, and you're not building a Skinner Box. 
*** When Paul and I built "Just Three Words", two separate forums popped-up within a week of each other, very quickly after launch. We'd missed the boat on creating our own, and so became members of a customer-operated community.