<commit_before>---
layout: post
tags: [non-technical]
title: "Blend"
published: True
images:
    - url: https://blend.com/wp-content/uploads/2017/06/blend-logotype.png
      alt: Cover
      title: Cover
---

I just wrapped up a more than a year of working at Blend. 

I feel like this year has been dramatically different from what I expected, both in a good and bad way. 
Anyways I wanted to talk about working full-time for a year, what I liked and didn't like, and what I would do differently.

**NOTE:** Take what I say with a huge grain of salt, as this is just my personal experience ($$n=1$$). 

### What I Did

I deployed and maintained several internal data servies:
- Airflow - Airbnb tool responsible for scheduling Blend's ETL jobs
- DSTB (data science toolbox) - Hosted jupyter notebooks with easy connection to our Redshift cluster.
- $$\log R$$ - Blend's log archive pipeline, which has now ingests a variety of different data sources, such as frontend event data.

I also spent a lot of time working on a variety of longshot ideas: 
- using an RNN to predict user submission
- Trying to cluster our NPS comments 
- using deep learning to identify "forzen" NPS comments. 

Most of these were abject failures, but the frozen NPS classifier is still being used today! 

Aside from all the fun engineering work I did, I also spent a lot of time writing documentation/specs/tests, resolving on-call issues, reviewing code, and helping out other engineers.

Something that suprised me was just the sheer volume of "other" work that needs to be done, and the relative importance of it. I think the most effective engineers don't necessarily spend a lot of their time writing code, but rather "managing/organizing". This is definitely something that I didn't anticipate doing (or at least that I would spend the majority of my time doing these things vs. writing code).

### Things I like about working full-time:


I think this is a skill that I've developed a lot over this year. I feel I was a lot more of a perfectionist when I started Blend, but very much less so now. 

I think I've really embraced silicon valley thinking - creating a feedback look, iterating quickly, being very opportunistic. 

Instead I try to iterate as quickly as possible. 

There's obviously a flip-side to this though, the ability to see when you can get more return for your work, and sometimes it's worth an extra days worth of work to do something better. Overall though, as someone who was very much a perfectionist beforehand, I think learning to iterate more has made me a better engineer. 

Iteration is also inherently way more scalable than doing everything in one go (you can explain to people easier.)

Another thing I like is that at work, so long as I can solve the problem, nobody really cares what I do.
Copy code, or pay for a service instead of building in-house. you're encouraged not to reinvent the wheel, to reuse code, to call into libraries, to write simple programs. 

I think the biggest thing that I enjoy about working is simply building things. You spend 40 hours of week trying to accomplish this one goal, or this one project, and that's really cool, because there's not a lot of context switching.

### Things I don't like about working full-time:

I think the biggest thing I don't like about working is that I think you get pidgeonholed. Any task you do once is something you'll probably have to do millions of time, even if it's as a favor.

The biggest reason I decided to leave Blend was that I felt that I was stagnating, not learning anything interesting at work. 
I found myself really burnt-out as well, and in general not very productive. However I was still working on my personal projects, and really enjoyed writing code there, so I knew it was a function of Work and not my overall mental health.

One thing that was kind of frustrating was that there wasn't much machine learning at Blend and most engineers there are pretty young. I would like to see more experience at the places I work at next.

There were some very good engineers at Blend, and I enjoyed learning from them, but I felt that especially machine learning at Blend was not very well developed. 

On-call rotations was ridiculous. Also I think may times at Blend we were forced to put together a shitty hack rather than taking the time to come up with a more robust solution. 

### What I learned
Good software requires legitamite effort (like a lot of it).

I think the best engineers minimize the number of lines of code that they write.
<commit_msg>updated post<commit_after>---
layout: post
tags: [non-technical]
title: "Blend"
published: True
images:
    - url: https://blend.com/wp-content/uploads/2017/06/blend-logotype.png
      alt: Cover
      title: Cover
---

I just finished working for a year at Blend, and now I'm back at UCLA as a student. 

Working full-time was actually quite a bit different from what I expected.
I wanted to talk a bit about the things I did, and what I liked/didn't like about working/Blend. 

**NOTE:** Take what I say with a huge grain of salt, as this is just my personal experience ($$n=1$$). 

### What I Did:

At Blend, I deployed and maintained several internal data servies:
- Airflow - Airbnb tool responsible for scheduling Blend's ETL jobs
- DSTB (data science toolbox) - Hosted jupyter notebooks with easy connection to our Redshift cluster.
- $$\log R$$ - Blend's log archive pipeline, which has now ingests a variety of different data sources, such as frontend event data.

I also spent a lot of time working on a variety of longshot ideas that applied machine learning to improve Blend's product: 
- using an RNN to predict user submission
- Trying to cluster our NPS comments 
- using deep learning to identify "forzen" NPS comments. 

Most of these fizzeled out, but the frozen NPS classifier is still being used today! 

Aside from all the fun engineering work I did, I also spent a lot of time writing documentation/specs/tests, resolving on-call issues, reviewing code, and helping out other engineers.

Something that suprised me was just the sheer volume of "other" work that needs to be done, and the relative importance of it. I think the most effective engineers don't necessarily spend a lot of their time writing code, but rather managing/organizing. This is definitely something that I didn't anticipate doing (or at least that I would spend the majority of my time doing these things vs. writing code).

I also came out of this with a huge newfound appreciation for good PMs, they really have a huge affect on engineering productivity. 

### Things I like about working full-time:

Industry in general is a lot more practical than academia:
- Blend felt like it was solving a meaningful problem. 
- aka tech debt, I'm gonna write a bunch of shitty code but that's okay because this isn't going to scale.
- There's a lot of cases where premature optimization kills a problem
- There's a lot of cases where we failed to plan out our projects correctly.

Iteration is also inherently way more scalable than doing everything in one go (you can explain to people easier.)

Another thing I like is that at work, so long as I can solve the problem, nobody really cares what I do.
Copy code, or pay for a service instead of building in-house.
You're encouraged not to reinvent the wheel, to use libraries.

You spend 40 hours of week trying to accomplish this one goal, or this one project, and that's really cool, because there's not a lot of context switching.

I think the biggest thing that I enjoy about working is simply building things. 

### Things I don't like about working full-time:

I think the biggest thing I don't like about working is that I think you get pidgeonholed.
Any task you do once is something you'll probably have to do millions of time, even if it's as a favor.
At the same time it's sometimes hard to branch out because you still have an obligation to maintain code. 

One of the biggest reasons that I left was that I felt that I was stagnating and not learning anything interesting at work. 

Furthermore, I found myself burnt-out and not very productive  However, I was working on a personal project (Distbelief), that I really liked so I knew it wasn't so much that I was fed up with computer science so much as I was fed up with work.

One thing that was kind of frustrating was that there wasn't much machine learning at Blend and most engineers there are pretty young. I would like to see more experience at the places I work at next.

There were some very good engineers at Blend, and I enjoyed learning from them, but I felt that especially machine learning at Blend was not very well developed. 

On-call rotations was ridiculous. Also I think may times at Blend we were forced to put together a shitty hack rather than taking the time to come up with a more robust solution. 

### What I learned
I'm a lot less of a perfectionist  now that I've spent some time working. I used to try to always search for the optimal solution, but now I feel that I am more methodical in how I approach projects - creating a feedback look and iterating quickly.

Good software requires legitamite effort (like a lot of it).

I think the best engineers minimize the number of lines of code that they write.

{'fraction_non_alphanumeric': 0.042294446835987945, 'fraction_numerical': 0.0019371502367628067, 'mean_word_length': 3.9589114194236927, 'pattern_counts': {'":': 0, '<': 3, '<?xml version=': 0, '>': 3, 'https://': 2, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '2729296', 'n_tokens_mistral': 2364, 'n_tokens_neox': 2238, 'n_words': 1564}