Well, Time seems to fly with one of those out of service mach-3 planes these days. It’s already been more than a year since I tricked Amazon into thinking I know shit. To commemorate this grand event, I thought I’d bring this blog back from coma to post something.
This one year has probably been the best in my life so far. You might think that’s exaggerating, but try throwing in a couple of years of wasted childhood, a rural high school and four years of struggling to pass in college and you’d see my point.
But it’s not just me, ask anyone working for Amazon Chennai and they’d tell you the same thing. The brain power here is astounding. Everyone is a rock star. It’s a warm, fuzzy feeling to know that you’re probably the dumbest person in the crowd. To really tell you how cool Amazon is, I’ll have to write a 1000-page book with a 100 page appendix on why each character is cool.
But I digress.
Coming back to our headlines today, these are a list of lessons I learnt the hard way (that’s a fancy way to say that I was caught with my pants down). These mistakes were caught by highly trained individuals. Do not attempt to repeat them at home, or anywhere else.
Keep it simple.
This is the first thing I learnt out of college. You don’t need to spend 4 hours writing code for an optimal implementation if can get a sub-optimal one working in 30 minutes. You will normally have 10 other things to worry about when you’re working on this one. Just get the easiest, right way to completion. Measure. Improve. Repeat as necessary.
Relate every task to the goal
It’s easy to lose focus on the larger picture when you’re lost in the woods of detail. Here’s a simple solution – Whenever you take any decision, see how it helps you progress in the overall vision.
Always back assumptions with data
Within Amazon especially, you’ll quickly learn that numbers are your friends. If you’re crazy idea has enough numbers to back it up, you’ll suddenly find that it’s not that crazy anymore.
Never leave your code base worse than what it was
I’ve seen real war stories based on this one. Even if you can’t improve the code base, try not it add more filth into it. Overtime the percentage of good code will push you to clean up the remaining filth
Test – Code – Test
I confess. I don’t practice this myself. Well, at least not exactly. It’s usually Code – Test – Code – Test for me. I usually write out simple happy cases and then use test cases to fill in my test cases. Now that I’ve preached it, I’m now forced to practice it.
Other random stuff:
- Java is actually a nice language. Thanks to Bloch. (Someone buy me the second edition 😀 )
- Zsh is awesome!
- Ruby is not bad. But I still like Python for some reason.
- Track the time you spend working. You’ll be surprised to find how amazingly inefficient you are.
- Planning is important. The plans themselves are useless.