More common lessons

My last few blog posts have been in the realm of “things i am tired of repeating to everyone I care about” so let’s just go for it. None of this is new information, I didn’t come up with any of this.

Learn the real meanings of “introvert” and “extrovert”.

Don’t lie to me, you’ve done dozens of Myers Briggs tests, at the very least just to see which Harry Potter character you would be. A lot of really smart people get hung up on these. If you take a test and it says you are an “introvert” but you really like being social and hanging out with friends, it might be discombobulating.

Extrovert doesn’t mean outgoing and social, introvert doesn’t mean lonesome and likes-to-read-in-a-quiet-corner. These are side-effects, not the cause.

An extrovert is someone who generates energy when in a loud bustling social setting, and expends energy when they’re quiet/alone.

An introvert is the exact opposite. Someone who expends energy when in a social setting, and recharges when alone reading a book in a dark room (preferably with a cute cat).

If you define the words this way, being a huge introvert who is a social butterfly makes sense and seems less contradictory.

Knowing how you recharge is a godsend. When stressed, tired, etc, you can say “oh, I need to be alone”, or after 5 days of 8 solitary work hours you can say “I need to go out this weekend to feel more alive”.

Knowing in which situations loved ones / friends and family recharge and in which they expend energy is a godsend too.

The people who understand this in my life know that when they invite me out and I say “fuck I really want to but I really can’t, I need to be alone right now” — I’m not insulting them, I’m not lying to them, I am legitimately in need of solitary time to recharge. I love them.

There’s a lot to gain just from labeling something. Whether it’s a new relationship (Are we dating? Are we fucking?”), your own self (it took me until I was 24 to learn I had ADHD, but then a lot of what I felt were personal shortcomings started making sense), or the habits of you and those in your life.

You don’t do good work when you’re tired or stressed.

It’s 6:30 PM on a Thursday. Your entire team works faster than you, knows more than you, and could’ve finished everything you have spent all week doing in their sleep. What do you do?

GO HOME.

If your answer to this was “that situation doesn’t happen to me”, yay you might not have awful imposter syndrome. This is rare in my friend groups. Pat yourself on the back.

If your answer is “stay late at work to finish just this one last thing” or “go home and continue working” — I feel you, trust me I do, but we both need to realize this is bad.

I’m lucky enough to have the experience and real memories to say “haha I can’t believe I spent 4 hours trying to finish that one-last-thing, got super angry and stressed, went home and shouted at a wall for a while, then when I came in the next day I looked at the problem from a different angle and fixed it in 30 seconds.”

This feels good to do, vindication and solving a hard problem is great, but it should not be happening at the expense of your sanity.

It might take you until you experience this enough to really believe me, but _you don’t do good work when you’re tired_. You just don’t. Go home, relax, read a book, play some video games, cook dinner, sleep. Be a full human.

If you feel that you’re constantly behind on schedule and failing, try figuring out if the failure is really a failure, and if it’s your failure then learn from it. Don’t just keep spiraling. Leave work when you leave work. Don’t bring it home.

You need a snap-on strainer.

Okay this isn’t really in tune with the other pieces of advice but holy shit look at this thing:

There’s a bunch of different products like this, the one I use (and the one in that stock photo) is $12 on Amazon. That’s not a referral link. Buy this, or a cheaper one. Please.

It makes making pasta a lot easier, it makes blanching broccoli a lot easier, that’s 2 major food groups right there.

I also strongly recommend silicone pour spouts. They just attach onto anything and let you pour liquids easily without making a mess.

I was talking to one of my good friends about how I need to get a new big-enough saucier with lip so I could pour things from it into containers easily, I went on a huge rant and sent him 4 options to help me decide and he said “ok hold on what’s your actual problem” — turns out the solution was $7! I use these things at least 3x a week. There’s some lesson here about “stepping back and looking at the real problem, not your possible solutions”.

Okay. That’s all I got for now. Text or tweet me your Harry Potter character.

On developer hiring

As you may or may not know, we have a job platform on Stack Overflow, aptly named Stack Overflow Jobs. We’re pretty meticulous about what is allowed and what isn’t allowed, and as a result our sales team needs to be pretty high-touch with clients.

Since we have the eyeballs of every developer in the world, we have lots of fun data to let employers precisely target their job listings. But it’s not just a numbers game, the quality of the job listings (and jobs themselves) matters too.

One of the ways we help curate quality content on our job board is through a internal mailing list called “Ask At Stack”. Anyone who has a technical question (typically sales reps but not only sales reps) can send an e-mail to the mailing list and the opted-in pool of techies go through them whenever they can.

I’ve been involved in the mailing list since the first days of its existence, and it didn’t take long for me to realize I was repeating the same advice over and over. So… here’s some of that advice!

To set the context: A lot of jobs may not be perfect for a lot of people, I’m mostly focused on increasing the quality of job listings which seem interesting and relevant but are squandering the opportunity. That opportunity being “a developer who has this skill-set and interests is looking at my job listing, I hope they hit apply.”

Pet Peeve #1: Mentioning things that every developer job has.

This is typically in one of two places, either in the beginning of a job listing while talking about the company (“We are a collaborative software development shop”) or under the requirements (“Collaborate with designers and product managers to build products”). This is just noise.

Your job listing shouldn’t have a low signal to noise ratio. Any extra work someone needs to do to figure out if this job is interesting/applicable to them is a opportunity to close the tab or move on to the next listing. Your bad job listing hurts my platform because it results in people thinking “the ad was interesting, I clicked it, why do I have to work to get the info i want to get?”

Pet Peeve #2: … and the kitchen sink

Compared to women, men tend to apply more to listings where they don’t match all the requirements. It’s a pretty reasonable assumption that the more requirements you have, the more likely it’s going to be that a prospective candidate doesn’t match every single one of them.

Now, with that in mind, read this bullet point from a real job listing (which has thankfully been modified):

Bonus with experience in data analytics; statistical analysis, machine learning, security, performance, deployment/operations, responsive design; development in iOS, Android. AWS or Docker experience a plus.

I don’t even remember what kind of role the job was supposed to be hiring for, I think it was a Full-Stack Web Dev, but for any role other than “co-founder / CTO”, this is insane.

Speaking of requirements: Does your job listing list a required degree or years of experience? If so, even if your years-experience requirement makes sense (e.g. you’re not asking for 5+ years of experience with a language that’s existed for a year), what purpose does it actually serve?

As a developer without a degree, I think hard-set degree/years-experience requirements only reduce your total candidate pool without giving much benefit. You should be looking for people who are Smart & Gets Things Done (sidenote: if you’re a friend reading this and haven’t read the book, i have 100s of copies, i can send you one), a degree isn’t a helpful top of the funnel filter for that.

Meta: I wrote out a bunch more pet peeves and it just ended up in angry ranting, so let’s try to do a positive pivot.

What should a job listing have? Here’s a direct quote from a response I sent to Ask@ about a year ago:

The job description for both positions doesn’t say anything unique about the company, job, or role. I’d really enjoy if they had:

1. What the company does. Do they make a product themselves? Do they sell things to other companies? What kind of industry do they work in?
2. It says there are other [ROLE_NAME] engineers, what do they do? What’s the hardest or most fun thing one of those engineers worked on recently?
3. What are hard challenges they’re working on? What problem do they have that they’re hiring people to help them fix?

The second and third points in that quote, I repeat almost every day. Even if a job listing does a really good job of explaining what the company does and how (and hopefully mentions that they’re adults who go home at 5 PM every day), what I really want is to know about their challenges.

If you spend some time at developer meet-ups you’ll witness a lot of men say “Oh, you’re a developer?” to the women at the meet-up, which is super infuriating. But also, you’ll see people sharing war stories. Every good developer has some “hard lessons learned” that they carry around like a badge of honor.

If your job listing mentions some of the badges of honor your current developers carry around, the prospective candidates reading immediately start thinking about how they would’ve solved the problem. This is inception. You just got a smart, clever person to start thinking about your company’s problems before they even thought “Do I want to work at this company?”


More personally:

I, as a developer with a diverse skill-set and years of experience, know that I am privileged enough to be able to have a new job any second I want one. Your Android developer job vs my Android developer job vs their Android developer job are all Android developer jobs, even if the apps look different.

Almost every mobile app is just the same REST consumer showing different data in a list then you tap on it and it shows more info. BO-RING. Why would I want to go from working on my boring CRUD app to your boring CRUD app?

I have a list of standard questions I ask every time I interview for a new role, some of them are:

– Who is allowed to have new ideas, how do those ideas get shared?
– Who decides what people should work on?
– What does an average day in a developer’s life look like at your company?
– How siloed are you? If I’m blocked on something in my mobile app because of the API, can I just work on the API? If it’s allowed, do people actually do this at your company?

You’ll note that most of these are questions that typically only a developer working at the company can answer. That means to get answers to these questions I typically have to: Apply, pass a resume screen, pass a phone screen, get to the first technical interview, pass the coding part, get to the last ten minutes when I can ask them my questions.

I’m okay doing this for some roles. I have to be really excited about the role to put in that effort. Typically this only happens when I’m already excited about a company and ignore most of their job listing. This is a huge hindrance for smaller / less-known companies.

If only it was possible for the HR manager writing the job listing to ask a developer some questions about their day to day before they post the listing… Wait a second, why the hell don’t people do that?!

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:

Failure
  • 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.

Why?

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.