Work Smart. Seldomly Work Hard.

I know many, many people out here in Silicon Valley who, despite being extremely bright in some areas, are ignorant when it comes to being productive. Young, single males with ambition are incredibly likely to pull long hours that hurt them in the long run. 

The basic rule of thumb is that If you are pulling >40 hour weeks for more than a couple of months you're being less productive. "Not me", you say, " I was the smartest kid in my class and I have incredible mental endurance!". 

Nope, everybody makes bad decisions after working long hours for a few months. For all the coders out there, think about it like this: How many genious decisions have you made at 3am after working for 15 hours? Now think about how many egregious hacks you wrote at 3am to get something out the door. Compare the two.

Read more here.

Software Analogies

Nearly all software is buggy, but anyone who's ever written a modicum of software is not in the least bit surprised by this. The layman does not share this understanding, to put it mildly. Since the process of programming, debugging, and shipping is not a readily understandable topic if you've never thought about logical implications to the 4th or 5th degree, one needs a good analogy. Here's mine:

Imagine most everyone has a robot in their home that takes blueprints for any object (a toy, a piano, a house, etc.), can build said object really quickly, but can't make any intuitive decisions. That is, the robot follows the designs on the blueprint exactly, for better or worse.

Most of the time objects come out of the robot just fine, but what if whoever wrote the blueprints didn't think about how his toy design would work when covered in baby slobber? What if the house the robot built was designed for 3 people but 7 people are trying to live in it? What if the blueprints for the desk the robot built didn't account for handicapped people?

Writing software is tantamount to making blueprints for builder robots that people end up making in their own home. When you're writing the blueprints you don't really know how people are going to use your stuff. You might not properly get the Feng Shui right in your house blueprints and people across the country using your blueprints get depressed. You never intend all of this stuff.

The blueprints are the code. The builder robot is your personal computer. The door that doesn't quite close is a bug.

Keep it Simple.

A useful truth about programming is that it always takes more effort to debug a piece of code than it does to write it. If, at first pass, you make a piece of code as clever as possible then you're not smart enough to fix it.

Most people hear that insight and think "I'm fine, I can still debug my code", but that's only the first piece of the puzzle. Unless you are actively trying to make work for yourself and others, write all code as simply as possible. If you ever do something clever, ask yourself if it is truly necessary. Odds are it isn't and you're just making more work to be finished later.

What to Look for in Startups

How Much Can I Learn?

Learning is, on some levels, the only goal. All else grows from getting better at life, the universe, and everything.

Don't be evil

Is the company's effect positive (e.g. kiva or goodguide). Don't be Farmville, where a majority of revenue comes from psychologically addicted users paying for in-game currency. 

Have Impact On the World

What's the end goal? Change the world or put change in your pocket?

Employees Can Drive, are Given Freedom

Early-stage companies still have most of the risk ahead of them. Early employees are quasi-founders and should be given a seat at the table. Empowered employees are happier and perform better. If the founders have 100x the equity of your first few employees, like most companies, then you're doing it wrong.

Internal Impact, Not Face-Time

Caring about hours-in-office instead of results is a sign of management ill-suited for engineering. Engineers make non-linear contributions.

Expertise Guides, Data Drives

While you need domain expertise to give your company direction, the day-to-day operations should be driven as much by data and science as possible. Startups are attempting entirely new things; Even experts have the wrong ideas all the time. Do you have an analytics dashboard where you can track the health of everything you care about at all times? Do you A/B test as much as you can?

Transparency

Internal transparency about company information. Transparency to your users for trust and long-term growth.  "Beware of he who would deny you access to information, for in his heart he dreams himself your master".


The Beer Test
Getting along well with your peers makes you happier, but it also helps honest dialogue over difficult subjects. And you can work with each other 2 weeks into crunch time at midnight.

Smart Workplace

Don't be penny-wise but pound-foolish with your tools and environment. If a keyboard, monitor(s), chair, and programming environment is how you get your work done, they need to enable.


Engineering Results, not Engineering Fashion.
It's good to be aware of them, but don't waste time constantly installing/rei-installing/configuring/researching the most-recent, fashionable framework unless it seriously helps you. Consider the Lindy Effect: The longer a technology has been around, the longer it will stay around; It has been battle-tested.


You can't have everything you want, though. An amazing work environment, great compensation, and great coworkers can overshadow a mission that's not exactly to your liking, and vice-versa.