The process is part of failure.

If you’re a self-driven person, you might be like me and beat yourself up every time you fail at anything. I fail often, and when I fail I can get really mad at myself. On days where I fail at everything from getting anything done at work to losing at video games to even forgetting to eat, it’s a fun spiral.

If this doesn’t make any sense to you the best way I can explain the underlying state that leads to this is to quote Hannah on Girls:

No one could ever hate me as much as I hate myself. OK? So any mean thing that someone’s gonna think of to say about me I’ve already said to me, about me, probably in the last half-hour. [0]

Feeling like you failed sucks, and being negative about yourself even before you failed makes it suck more. But, having failed means you actually tried to do something, and for me that itself is rare. It’s something that should be internally acknowledged and congratulated.

I hate the feeling of regret. I’m a very emotional person and the intense feeling of regret is not something I like to feel. Failure and regret are a common pair, but I do not believe that you can regret a failure you can learn from. It’s something I say to myself a lot. If you say it enough it becomes an internal assumption, and those are hard to knock down. It’s all a game of min-maxing the emotions you do and don’t want to feel.

It’s not a fully logical thing, since we’re human, but I find that going through the following thought process at the very least gives me time to think and acknowledge the specific failure rather than sit and ponder on how awful I am at everything.

After the rush from the initial cacophony of emotions I feel when I become aware I’m failing at something, I try to rationally think on the set of assumptions / decisions I made that led to doing what I did, which ultimately led to failure and the imminent possibility of regret. It’s important to try to think of as wide of a set as I can, not just anything I did immediately prior to the decision. I then gather all of these and treat them one by one as a function, in the mathematical sense.

Shit probably just took a weird turn, so let’s back-up:

A function is a relation between a set of inputs and a set of permissible outputs with the property that each input is related to exactly one output. [1]

The inputs here are all the other related assumptions I had, the information I had, the information I reasonably could’ve had but didn’t, anything that contributed to the specific action or assumption that ultimately led to failure.

Each of these inputs lead to exactly one output, the best possible decision I could’ve made at the time. If enough of the inputs lead to the same decision, then we’re golden.

This doesn’t really make a lot of sense in the abstract to me, so let’s try a simple example. I’ll try to be explicit about the connections to the mathematical function. I’ll be going in the form of:

  • A specific assumption held / decision made [output of that function]
    • A prior action made that led to real output instead of “best possible” output [input]
    • An implicit or explicit prior assumption, instead of direct action [input]

For each of these specific possible contributing factors, the goal is to compare the now known best possible output and the actual output that occurred at the time.

I am 15 minutes late to my first meeting of the day.
  • Was the time that I got out of bed and started my daily morning routine early enough? Did I simply oversleep?
    • Was my alarm set to a reasonable time?
    • Did I hear my alarm or did I ignore it?
    • Did I stay up the previous night?
  • Did I change anything in my daily routine?
    • Was the order of actions (showering, brushing teeth, etc) the same as recent days, or my default?
    • Did any of the actions take longer than usual? Did I use a new multi-step beard wash, or anything else new?
  • How long did it take to get to work?
    • Was it longer than any other recent day?
  • Did I assume a long enough time between arriving at the general destination (office, conference room, etc) and my specific meeting?
    • Did I use a conference room that I knew (or could’ve known if I asked) is notorious for having teleconferencing issues? It takes a long time to write “krahjerdi” into one of those Chrome for Work boxes, it’s a tiny keyboard on a remote.
    • Was it an in-person meeting in a new building? Did I leave enough time to find the actual meeting room?

There could be a lot more of these, and they vary greatly from person to person and situation to situation, but the more you do this the better you get at doing it. It’s a game of spotting what my favorite High School Math/Stats teacher called “lurking variables” in the wild.

If when going through these questions I can’t find anything where I reasonably can say “oh come on, I knew I shouldn’t have done that”, I can logically feel guilt-free.

The examples above only list purely-me questions, since I’m self-driven and focus on failures that are 100% mine, with workplace failures these questions end up being closer to:

  • Did I have any concerns, and did I make myself heard?
  • Did I have the authority to do something different?
  • In going through this loopback system, are there any common contributing factors in this failure that existed in other ones inside the team/division/company? Have I made these findings heard?

Incorporating logic and awareness into my emotions is really important for me.

I used to be really good at ignoring myself and acting like negative feelings didn’t affect me, then maybe if I was lucky at the end of the day I would think “FUCK I have been angry all day, what’s going on?!”

I find that if a failure is something I can reasonably suppress the negative emotions around, I can screw something up publicly then smile and laugh about it 30s later, which is a great feeling! It’s nice to fail then be able to laugh about it knowing you’ll use it as a chance to learn and grow.

The faster I can get at detecting and validating negative feelings, the better I can get at feeling the feelings. Then I can finally focus on the actual lesson to be learned, which helps me grow.

Android Wear & My Daily Commute

The orphan in the title above is irking me. Suggestions for other titles welcome.

tl;dr – I wrote an Android Wear app. The code’s here.

I really enjoy being in an air conditioned environment. Even more so during the summer.

My optimal daily commute (optimal meaning the train arrives at the station the same time as I do) is sixteen minutes door to door. Eleven of those are spent on the air-conditioned subway train, one is spent walking from my apartment to the subway station and the other four are spent walking to my office. I have it down to a system.

The part I don’t have complete control over is the time at which the subway shows up. Luckily, the line I live on is decently on-schedule. My biggest problem comes from the fact that the timetable for the subway isn’t easily predictable: The C train departs my apartment on the 9s between 9 and 10 AM and on the 1s between 10 and 11 AM. It’s weird. I also never leave my office at a regular time so I can’t even instantly answer the question “If I start walking to the subway station right now, what’s the expected value for how many minutes I have to wait until a train shows up?”

This is a super easy problem to solve. I can simply type my route into Google Maps and it’ll tell me when the train leaves. Fantastic! The issue is it takes me around two minutes to actually complete that operation (I hate the Google Maps app) and very regularly the result of it is “Well, if you hadn’t just spent 2 minutes searching it you would’ve been able to catch a train — have fun waiting 15 minutes for the next one!” This, in theory, is solved by Google Now, which gives me contextually aware advice, including directions to frequently traveled locations. Sadly because I don’t live on a set schedule Google Now normally looks like this for me:

Google Now

I took that screenshot yesterday when I had waited 5 minutes underground and wanted to see when I was supposed to be expecting the next train. Quite convenient, right? Even worse, when it does consistently show me travel directions to somewhere, it’s “12 minutes to the gym”, constantly shown when I’m at home on the weekends. I can’t bring myself to swipe the card away since that feels like saying “Nah, I’m fine being fat, stop annoying me.” Stop fat-shaming me, Google.

Anyway, long story short, the above is the reasoning that led to the creation of my first Android Wear app.

It’s a stupidly simple app:

  1. I say “Okay Google, Start MTA” (or tap and select it from the list, which has a bigger actually-working rate)
  2. My watch tells my phone to figure out where I am. If I’m closer to the GPS coordinates of my office, it assumes I’m on my way home, and the reverse. Note that this assumes a terrible work-life balance. That’s on my task list.
  3. My phone, using a locally saved timetable, figures out when the next train that will take me to my destination leaves in and sends that info to my watch.
  4. My watch shows a pretty indicator like so:

As alluded to in my tweet, the creation of this was actually pretty fun. I got home at 7:46, showered, ate dinner, and then got to work. In three hours I was able to make an Android app version of the exact process outlined above. After this, I worked on transferring the data from my phone to an Android Wear app. It took a while, but I think it wouldn’thave if I wasn’t as sleep deprived.

It took me around an hour just to be able to connect my watch to my computer. Obviously, connecting it via the USB cable doesn’t work. You have to set up a bluetooth bridge between your phone (which is connected to your computer) and the device, it’s pretty clunky.

My biggest source of trouble came from the cross-device communication. There are three different ways to do this, and they’re a bit muddled. MessageApi is for the transfer of small ephemeral payloads. DataApi is for the transfer of still small, yet persistent data. And something to do with Assets (I don’t really know what that means or where the documentation about it exists) is for the transfer of big amounts of data, but you know not like “Big Data” with capital letters. The sample code is a bit scatter brained and rushes through this. It also lists out how to two drastically different operations in the same section, which to a sleepy Kasra was insanely confusing.

Once I got past my issue of not being able to read good, it actually wasn’t that bad. There’s an intense personal satisfaction that comes from having an issue, seeing a simple solution to it, and having the solution be in a real product by the time I had the issue again. I’m pretty proud of myself.

If I lived on a numbered train line, this would also be insanely more useful since those trains have real-time tracking rather than just “Maybe a train will show up in 1 minute, maybe not, go fuck yourself.”

Side-note: I did end up using the app in the morning (although starting my day with “Okay Google” made me feel like I was in that Zooey Deschanel Siri commercial, I don’t know if that’s a negative or a positive) — it said “2 min” which was fantastic since I was all ready to head out, but it ended up taking me three minutes to walk across the street due to traffic. I ended up just missing the train. You can’t win them all.

Don’t rewrite code.

This is a story about Dave.

Dave just took his first Software Engineering job 4 months after graduating from college. He’s very eager to get going and to show his chops to the senior devs.

Dave’s first two weeks on the job after his introductory period are dedicated to bug duty. Bug duty is great for new hires because it lets them jump head first into many different facets of the codebase and learn how all the different subsystems communicate while also doing something productive: fixing issues!

On his first day after getting settled in Dave realizes the company’s bug tracking software is disgusting. It’s some old interface using UI elements so old that not only are they not flat, they’re not even rounded! It’s probably whatever must have existed before Web 2.0. Dave searches around the codebase and realizes that the subdomain for the bug tracker runs using Perl. What the hell?! How does anyone get anything done with this old thing?!

Clearly the best solution here is to make a new bug tracking interface that not only looks beautiful but uses a maintainable codebase. If it’s good enough Dave can even open source it and post his blog post about it on Hacker News. Perfect.

Instead of spending his first two weeks on the job fixing bugs, Dave decides to spend it on creating a new bug tracker. Obviously he  also has to do the bare minimum bug fixing to make it seem like he’s working on what he’s supposed to be doing. During lunch his coworkers joke about how bad the old legacy systems are that Dave can’t even fix more than one minor bug a day.

After he finishes the MVP (minimum viable product) for his rewrite of the bug system, Dave excitedly sends the Heroku link for it to his supervisor, saying that that it’s something he was working on in passing and will definitely help quality of life at their company.

Dave assumes that Alice will be insanely excited. Not only did they get out of some crippling technical debt for free (I mean Perl, really?) his system also shows obvious work ethic, understandings of good the best paradigms, and the Flat-UI powered stylesheet makes it much nicer on the eyes than the old interface.

Alice replies with nothing but a link to the old system’s internal bug tracker. The link displays the first 100 historical tickets: bugs, feature requests, specifications and so on. Dave looks at it and realizes that every one of the bugs listed also exists in his system. Dave’s wasted two weeks of his life making half-functioning software that has the same issues the current system had 10 years ago.

His bug tracking system while beautiful and following Ruby coding conventions to a tee, doesn’t allow advanced searches. Or more than one-dimensional sorting. Or filtering by subproject. Or custom priority levels. Or…

When you do a complete rewrite without knowing everything about a system not only do you rewrite it, you also rewrite it’s first N bugs.

When you release a product into a competitive ecosystem, whether it’s a new video game fighting for control in an overpopulated genre or even just a new version of your own software, you’re not fighting with the initial release of the competitor.

Your product’s launch version needs to be as good as they are on whatever day they’re at now. This is the same reason every know MMO that comes out is compared to World of Warcraft as it is now instead of its first beta. This is the same reason why WP8 even though it’s in its relative infancy, gets its app ecosystem’s size compared to those of iOS and Android.

When competing with old versions of your own product you should never do a complete rewrite. Ever. If you’re the person that knows everything about the current codebase then you’ll be performing refactoring, which is completely different. Else you’re most likely just being over eager and refusing to deal with things other people have left behind. Decisions are made for a reason. You can’t just automatically assume that everything you’re dealing with was done out of pure ignorance.

If you are not the person who knows the entire system or if it’s so convoluted that no one does, you simply can’t rewrite it without breaking anything. First learn then refactor piece by piece.

This is a mistake I’ve seem at two person companies all the way up to enterprise software shops. There’s always going to be some Dave that refuses to work with an old or non-sexy codebase and for things even as simple as minor UI elements being drawn on a phone’ screen, I strongly believe that no code should be completely scrapped and rewritten unless the person who is doing it is aware of every single consideration that went into the creation of the original version.

If you’re at the point where you are aware of every decision that was made but you hate the end result, feel free to completely redo it all. It’ll feel great and should be pain-free. However if you’re unable to respond correctly to a question about a very rare edge case and how the code will react to it, you simply don’t know enough about the system to be able to safely rewrite it from scratch.

If you just spend your time rewriting everything you refuse to deal with you’ll never get anything done. Learning to deal with other people (both old co-workers and outside contributors) will allow you to develop at a much faster rate and actually focus on things that matter rather than the beauty of code or whatever the hot topic of the day is.

Lessons Learned

I transitioned from intern to full-time employee on August 6, 2012. Tomorrow, August 2, 2013 is my last day at Fitocracy. One of these days I’m going to nail this whole “having the same job for more than one year” thing, and it definitely looks like Stack Exchange, where I start in four days, will be when I do that.

I’ve grown a lot in the last year in a lot of different ways including professionally, mentally, emotionally, physically, and shoulder-width-ically; I’d like to record some lessons learned here to look back at in the future.

1. Communicate.

Talk to your peers. Talk to your users. Talk to yourself. Don’t talk to them just to say you did, communicate so that you can actually understand them.

If you have a problem with anyone (including yourself), talk to them.

Communication is a two-way street, go into every conversation you have with the intent of learning something. The biggest mistake you can make is assuming you are 100% right about something and refusing to talk to anyone about it. Don’t refuse to talk to people with opposing viewpoints. That’s not being sure of yourself, that’s called being insecure. If you’re convinced that you’re right, have others (including yourself) try to convince you otherwise.

Get inside your communication partner’s head. Why are they saying the things that they are saying? Get inside of your own head. Why are you saying the things you’re saying?

Communicate but also think. Don’t be anything but a voice recorder, hearing people’s opinions and making it your own. If you do that, you don’t exist. Hear all conflicting opinions then form your own conclusion.

2. Build.

Never ask your target audience what they want in your product. Instead, give them something somewhat usable and ask  if it enhances their life. People flat out don’t know what they want. If they did, your product wouldn’t exist because someone would have made it sometime ago.

If you ask your users what they want from your product, 99% of the time you’ll get a list of small immediate changes. If you instead communicate with your users and learn about them, you’ll be able to solve an actual need. To actually be able to make something that people will use, you need to understand them as people.

Build something you would use.

Love what you build, but remember that it’s a lot easier to criticize than to build so many people attempt to put you down to make themselves feel better. Tune them out.

3. No one cares if you’re the smartest person in the room.

You have nothing to prove. You don’t need to prove to everyone you meet that you’re smarter than they are. Even if you are, who the hell cares? Do something. If you have to go out of your way, or constantly bring others down to explain to them that you’re better than them, that just means you’re insecure.

Not only should you not want to convince people you’re the smartest person in the room, you shouldn’t be the smartest person in the room. Surround yourself with people who excel in places you fail. Learn from them.

4. Personal growth is everything.

Life isn’t a race. Life isn’t a marathon, life’s nothing but a hamster running in its wheel. Don’t live life for an end result, live life for the fucking thrill of it.

Improve in everything you do. Are you truly happy? What would make you happier? If you know, then start doing it right now. Else, learn to communicate with yourself. Just like in the professional world, this requires testing and iterating. If you give something a real try and it turns out not to make you happy, stop doing it. Never stop testing.

Never settle. Always work on improving yourself physically, mentally, emotionally, and professionally. Don’t do it so you can do X or Y, that’s not sustainable. Nothing in the world beats intrinsic motivation.

No one ever “grows up”, so don’t delay personal happiness for “when I grow up”, if you’re not happy with everything you’re doing 24/7 you’re doing yourself a disservice.

5. It’s okay to have emotions.

Not only is it okay, it’s awesome. Emotions are powerful and feelings are there to be felt. You can try your best to bottle them up, but what’s the point?

Acknowledge and react to your emotions. They are the most important part of you. Once you begin to accept that, you can think clearly about everything. You’ll be able to notice when different emotions emerge within you and acknowledge them, rather than making brash decisions that you later regret.

6. Sustainability is vital.

What’s your diet? What’s your workout program? What’s your job?

Can you see yourself doing the same thing in 3 weeks, 3 months, or 3 years? Do you want to be? Never make life changes based on short-term benefits. Instead, optimize for long-term happiness. This requires you to know what actually makes you happy, and to tell when you’re unhappy, which is a huge part of communicating with yourself.

7. You’re fucking awesome.

Simple as that. If you don’t think so, you haven’t done a lot of personal growth. If you need external validation to be happy, why are you so insecure? I don’t mean that as an insult; legitimately ask yourself that.

Watch out because most of the times you’ll think the reason is A or B and ignore the bigger issues at hand. Make sure to find the root causes of your unhappiness rather than their newest manifestation. Prioritize fixing the root causes rather than more the easily fixed issues.

8. Relax.

It’s really easy to get caught up in the circle-jerk of “I work more than you!”, but really, who the hell cares? Work must be as long-term sustainable as your diet, workout program, or whatever else you’re doing for personal growth. This includes knowing when to slow down, take a break, take a walk, or sit back and have a beer. IPAs are delicious.

9. Collect data, but then iterate, iterate, iterate.

Collect data. Don’t just collect it and assume it changes anything, collect it and use your data to make positive life changes.

Only God and Jeff Bezos know how much I’ve spent on products because I thought being able to collect data related to X would fix my issues with X. That’s idiotic. You can’t make any changes unless you actually make changes.

For example, don’t track the hours of work you per day just to track them. Track the hours of work you do and pinpoint the typical amount that results in you doing subpar work, next week, stop at that amount rather than continuing. Did it result in better work? Iterate.

At the end of the day no investor gives a crap about your an individual metric, and your level of personal happiness isn’t purely controlled by a plot-point on a graph. What matters is vision and improvement. Use your metrics to iterate and modify your goals, rather than focusing on your metrics alone.

While I loved most of my time at Fitocracy, I wish I had learned these nine lessons sooner. Although chaos theory would disagree, I think I might have stayed at Fitocracy if that was the case. I am unfathomably excited to start working at Stack Exchange, and I’m sure that it’ll be the first company I stay at for a year. I’m also excited to see how many more lessons I learn in that time.

My Self

I always jokingly refer to jobs I’ve had in the past as being from “another lifetime”. I never put much thought into it when I say it, but looking back I think I can definitively say that I’m not the same person I was a year ago, two years ago, or even six months ago.

One of the main reasons I don’t consider myself the same Kasra as the one who was doing X or Y N years ago, is that I always completely dedicate myself myself to what I do. I have quite a long resume for someone my age (humblebrag), but even for the mindless jobs I’ve had (hello, retail) I made it a necessity to make it my entire life. Each version of my self, working at each of the lines from my resume, completely considered the work it was doing to be the most important thing around.

This is kind of a double edged sword, in one sense it means I kick ass at what I do and do it well, but in the other, looking from the outside in, it is very clear that somethings do not need to be considered so important and should just be let go of at the end of the day. That’s just the thing though, I (we? all of the collective versions of myself) just flat out can’t do that.

The most telling example of this is when I worked retail. I was a low level employee handling the printing department of a technology store, yet on countless occasions I came home late and feeling like absolute shit because so-and-so over promised on an order and we weren’t able to finish it on time, leading to a disappointed customer. You may think that my emotions don’t necessarily mean I was taking my work home with me, but just mean I’m just an empathetic person

Well, most empathetic people wouldn’t immediately start creating a new customer management system to allow better tracking of orders, which would hopefully fix the root cause of the issue. But that’s exactly what I did. During a weekend, while working a close to minimum wage job, in my off hours. In retrospect, that’s time I could’ve clearly spent doing anything else to unwind, spending time with my girlfriend, watching TV, or even just playing with my dog. But that’s just crazy talk.

To be able to dedicate myself fully to a job, I need to first convince myself that my job is important and worth my time. Usually this is manifested by ignoring all the glaring issues visible when first joining a company. When I was at a social games company, I noticed some big issues right off the bat ranging from process to colliding views between management. However, if I didn’t ignore them, it’d be illogical for me to convince myself that the company was the most important thing in my life. I ended up spending nine months working there, even though I only “worked” 40 hours. I took my work home with me every single day.

Looking back at anything I was doing back then, and this must be two or three years in the past at this point, both work-related and not, I just flat out can’t connect with my past self.


Because to connect with that version of my self, I first need to be somewhere in the range of the same mindset I was in at that point. To do this, I first need to acknowledge that priority #0 on my list during that entire time was my job, and that’s simply not something I can now do, seeing how the second I left that job all the issues I first noticed (plus the compounded ones that later appeared) came to surface from hiding. It’s hilarious to think that the job was that important to me, and as a result, “game company Kasra” (and the nine months worth of life experience he has) is a completely disjoint person from me now.

None of this might make sense to you. It didn’t to me until quite recently. How could I possibly not be the same person I was 2 or 3 years ago? Well, other than the weight loss, the emotional changes, the location change, everything else should be the same! This is what I told myself until I started really investigating the idea of self. In doing this, I learned a lot of different possible theories, but the one that made the most sense to me is the Bundle Theory, excuse the Wikipedia link, but I’m on a delayed subway at the moment and can’t quite come up with the words to eloquently explain the concept.

Damn am I happy I stumbled upon it. Everything makes sense now, and even the phrases I jokingly say seem real. Maybe a past version of me already subconsciously knew that this was the case? I’m glad I finally know why I can’t easily connect fully to all the other Kasra Rahjerdis I remember.

Oh, by the way, if you’ve ever dedicated yourself fully to your job (which most people who have had to do things on tight deadlines have done in the past), you can probably notice the obvious issues with my method and the lead up for that bad word burnout, I’ll hopefully do a post soon about how that’s not an issue for me at my current company.