A lot has happened in that time: getting my first promotion, switching teams, winning a hackathon, and shipping a lot of great software. I’ve also been fortunate enough to have grown so much in an incredibly open and supportive environment at Redfin. Here are the biggest lessons I’ve learned so far, along with some advice for those early in their careers.

🧠 Prioritize for impact, not perfection.

Going into Redfin, I was very much in the student mentality where everything had to be done to perfection. As a student, the goal was to get A’s, but I quickly had to readjust my mindset since that’s not how things work in industry. There are often way more ideas than there are engineers to implement them so work should be prioritized and done based on potential impact.

This dilemma can manifest in several ways. One situation could be building a product with only a few features that solve an important problem rather than building all the features that were thought of. Another could be fixing a few bugs that account for the majority of a team’s errors rather than fixing the highest number of bugs possible. There’s always the opportunity to iterate and tackle the other work in the future.

There’s a principle called the 80/20 rule, also known as the Pareto Principle, that was shared with me that’s especially relevant here. Essentially, the principle states that we should aim to deliver 80% of the value with 20% of the effort/time. This has helped me gauge priorities and reason what we should and shouldn’t work on.

Similarly for personal growth, prioritizing what you do so you’re making the highest impact on your areas of growth can help you meet your goals and get you to the next step in your career faster, whether that’s getting a promotion or that dream job. The next time you work on something, I challenge you to question whether it’s the most important thing you could be doing right now and whether you can re-prioritize your work to make the highest impact possible.

🙋 Don’t be afraid to ask questions, ever.

Don’t be afraid to ask questions, especially a lot of them. In school, students often work on assignments alone. But in industry, you’re on a team where teammates want to share their knowledge and help you succeed. It’s a collective effort to move the team, organization, and company forward. Your success is the team’s success, which is ultimately the company’s success.

For those early in their careers, this lesson is especially important. It’s okay and expected to not know everything. This is a great time to build up technical skills, learn about your interests and passions, and grow as an individual. Setting yourself up for success now will pay dividends years into the future.

My biggest regret from a past internship was not asking the company’s then-VP of Product for a 1:1 coffee chat, regardless of whether he would have accepted it. Back then, I was lucky enough to sit next to the company’s leadership team so I frequently saw VPs and C-level executives out and about. I actually ran into this person a handful of times in the hallway and politely smiled, but was always deathly afraid to start a conversation. Looking back, I would have loved to speak with him about his journey from being a designer to a product leader. This individual is Adam Mosseri, who is now the Head of Instagram. Because of this experience, I’ve made it a personal goal of mine to ask people that I want to get to know better and learn from at Redfin for 1:1s and it’s led to some great conversations and friendships! (I’m looking at you, Han Zhu and Austin Schiebel!)

🖖 Embrace uncertainty.

In school, I was very used to everything being very defined for me. For some of my projects, professors would share software requirement documents (aka tech specs) that were up to 50 pages long describing every little detail that needed to be implemented. In industry, however, we don’t have that luxury.

The job of a software engineer includes doing technical investigations, gathering requirements, and writing tech specs. That also means frequently working with new and unfamiliar technologies and areas of the codebase. Simply put, dealing with uncertainty can be daunting. But fear not! Uncertainty is a great opportunity to try and learn new technologies and approaches.

Throughout college, I would avoid certain work because I wasn’t familiar with it. For example, as part of a group project in my full-stack web development class, I only worked on the Node.js backend while my friend worked on the Angular frontend. At the time, I only had backend experience and found writing frontend code daunting. I just didn’t think frontend development was for me, but I was so wrong.

At Redfin, I finally embraced the fact that I needed to learn how to write frontend code, specifically in React. After getting past the initial learning curve, I was pleasantly surprised by how much I actually enjoyed it! There was one particularly memorable moment when my teammates and I were looking at a screenshot and couldn’t tell whether it was a screenshot of the actual feature I implemented or the design in Figma.

Since then, I’ve had the opportunity to work with other interesting technologies such as GraphQL, Apache Kafka, Apache Samza, and Netflix Conductor!

Uncertainty isn’t a bad thing and can actually lead to a lot of opportunities. Being uncomfortable means you’re growing so embrace it!

Even though I’ve learned a lot during my two years with Redfin, I still have so much more to learn. I’ve only scratched the surface of what it means to be in industry. And even though I still feel like a new grad sometimes, I believe that just means that I’m still pushing myself to be uncomfortable and grow. Equipped with the lessons I’ve learned so far, I’m excited for what the future holds! 🚀

Acknowledgements

Everyone I’ve worked with at Redfin has contributed to my growth in some way and I’m thankful for that. However, there are a few individuals who have been incredibly impactful in my journey that I’d like to shout out. Big thanks to Don Le, Jiaqi Wang, Eleanor Nesbit, Tian Luo, and Dan Ehrman for setting me up for success while I explored my career interests and eventually made the transition to product management.

3 Lessons to Succeed as a New Software Engineer was originally published in Code Red on Medium, where people are continuing the conversation by highlighting and responding to this story.

When a SQL statement is sent to a PostgreSQL server for execution, Postgres will decipher various parts of the query and define an execution plan in an attempt to retrieve and manipulate that data in the most effective way possible The great news is that you can view these plans to gain insight into how your queries are interpreted, and tune them to make your queries faster than ever!

Before diving into the query plans, it will be helpful to know your tables: the number of rows stored in the table (that Postgres might have to loop through), the columns which have indexes (so an index scan can be performed as opposed to sequential scan) and the typical way of querying the data.

Examining Postgres EXPLAIN, the Holy Grail of Query Optimization

EXPLAIN [ANALYZE] statement

This command displays the execution plan that the PostgreSQL planner generates for the supplied statement. The execution plan shows how the table(s) referenced by the statement will be scanned — by plain sequential scan, index scan, etc. — and if multiple tables are referenced, what join algorithms will be used to bring together the required rows from each input table, plus any auxiliary steps needed, such as sort nodes or aggregate-function calculation nodes.

If you run EXPLAIN with ANALYZE option, the statement is not only planned but also executed. The total elapsed time expended within each plan node (in milliseconds) and total number of rows the query actually returned are added to the display. This is useful for seeing whether the planner’s estimates are close to reality.

Let’s walk through a real example

Let’s walk through a simple query involving three tables: listings, search_keys, and markets. The listings table is used to store data relevant to a listing, the search_keys table contains all the data needed for home search based on various filters, and the markets table stores information about a real estate market. The goal of the query is to find all rows in the search_keys table within a range of listing ids, which are also present in the listings table for a given market where country_code is null or US.

EXPLAIN ANALYZE

SELECT

*

From

search_keys this_

LEFT OUTER JOIN listings listing1_ on this_.listing_id = listing1_.listing_id

LEFT OUTER JOIN markets market4_ on this_.primary_market_id = market4_.market_id

WHERE

listing1_.listing_id between 113115554 and 113125553

AND (listing1_.country_code is null or listing1_.country_code='US')

The generated query plan looks like:

QUERY PLAN

--------------------------------------

Hash Left Join  (cost=7.92..6981.79 rows=12762 width=8369) (actual time=2.375..473.754 rows=30 loops=1)

Hash Cond: (this_.primary_market_id = market4_.market_id)

->  Nested Loop  (cost=0.99..6829.09 rows=12762 width=1253) (actual time=1.880..473.134 rows=30 loops=1)

->  Index Scan using listings_pkey on listings listing1_  (cost=0.57..1196.67 rows=9273 width=827) (actual time=0.685..452.927 rows=9896 loops=1)

Index Cond: ((listing_id >= '113115554'::bigint) AND (listing_id <= '113125553'::bigint))

Filter: ((country_code IS NULL) OR (country_code = 'US'::text))

Rows Removed by Filter: 104

->  Index Scan using search_keys_listing on search_keys this_  (cost=0.43..0.60 rows=1 width=426) (actual time=0.002..0.002 rows=0 loops=9896)

Index Cond: (listing_id = listing1_.listing_id)

->  Hash  (cost=5.89..5.89 rows=83 width=7116) (actual time=0.456..0.456 rows=83 loops=1)

Buckets: 1024  Batches: 1  Memory Usage: 271kB

->  Index Scan using markets_pkey on markets market4_  (cost=0.14..5.89 rows=83 width=7116) (actual time=0.003..0.176 rows=83 loops=1)

Execution time: 474.093 ms

(13 rows)

The structure of the query is

Hash Join

--> Nested Loop Join

    --> Index Scan on listings

    --> Index Scan on search_keys

--> Hash

    --> Index Scan on markets

The query involves three tables and the final result is built by a tree of join steps, each with two inputs. A nested loop join is performed on listings and search_keys table, the result of which is joined with the markets table using Hash join strategy. You can also view the query plan using Postgres Explain Visualizer (pev) (shown below) or PostgreSQL’s explain analyze made readable which makes the plan easier to grok.

The visualizer needs the plan in JSON format, so you will have to run EXPLAIN with FORMAT JSON option.

Let’s dig deeper into each of these steps.

Nested Loop Join

The simplest of all join strategies, a nested loop join works by fetching the result from the left relation (listings), and for each row of the result, iterating over the right relation (search_keys) to find matching rows. Let’s look deeper at each row of nested loop join:

Nested Loop (cost=0.99..6829.09 rows=12762 width=1253) (actual time=1.880..473.134 rows=30 loops=1)

This node represents the action taken (“Nested loop”). The numbers that are quoted in the cost estimate (cost=0.99..6829.09 rows=12762 width=1253) are (left to right):

• Estimated start-up cost. This is the time (ms) at which this node can begin working.
• Estimated total cost. This is stated on the assumption that the plan node is run to completion, i.e., all available rows are retrieved. In practice a node’s parent node might stop short of reading all available rows (see the LIMIT example below).
• Estimated number of rows output by this plan node.
• Estimated average width of rows output by this plan node (in bytes).

Since we ran EXPLAIN with the ANALYZE option, the query was actually executed and timing information was captured with (actual time=1.880..473.134 rows=30 loops=1) in the plan node. The numbers depict the actual start up time (1.880 ms) when the node began execution, the total time taken for node to execute (473.134 ms), the number of rows returned by the node (30) and the number of times nested loop was executed 1 time (loops value).

In the case when a node is executed more than once, the actual time is an average of each iteration and we would multiply the value by the number of loops to get total time.

Next, let’s look at the sub actions for Nested Loop node.

Index Scan using listings_pkey on listings listing1_ (cost=0.57..1196.67 rows=9273 width=827) (actual time=0.685..452.927 rows=9896 loops=1)

Index Cond: ((listing_id >= ‘113115554’::bigint) AND (listing_id <= '113125553'::bigint))

Filter: ((country_code IS NULL) OR (country_code = 'US'::text))

Rows Removed by Filter: 104

Postgres performs an index scan on the listings relation using listings_pkey as its scan key to fetch listing_id(s) that match the index condition. The index condition corresponds to the SQL where listing1_.listing_id between 113115554 and 113125553. The Filter condition shows the number of rows removed by filter condition (listing1_.country_code is null or listing1_.country_code='US')

Next, for each listing_id returned by the above step, postgres performs an index scan on search_keys to find matching rows.

Index Scan using search_keys_listing on search_keys this_ (cost=0.43..0.60 rows=1 width=426) (actual time=0.002..0.002 rows=0 loops=9896)

Index Cond: (listing_id = listing1_.listing_id)

The loops value reports the total number of executions of the node. The actual time and rows values shown are averages per loop execution. This is done to make the numbers comparable with the way that the cost estimates are shown. To get the total time and rows, the actual time and rows value need to be multiplied by loops values. However since postgres rounds up these averages, the actual row values are shown as zero.

The result of the nested loop action is joined with the markets table using hash join strategy.

Hash Join

This join strategy involves scanning the right relation first and loading it into a hash table, using its join attributes as hash keys. Next the left relation is scanned and the appropriate values of every row found are used as hash keys to locate the matching rows in the hash table.

Hash Left Join (cost=7.92..6981.79 rows=12762 width=8369) (actual time=2.375..473.754 rows=30 loops=1)

Hash Cond: (this_.primary_market_id = market4_.market_id)

The above node represents the estimated and actual cost of hash join of the result of nested loop join and markets.

Let’s look into the node which loads the markets relation to a hash table using market_id as its hash key.

Hash (cost=5.89..5.89 rows=83 width=7116) (actual time=0.456..0.456 rows=83 loops=1)

Buckets: 1024 Batches: 1 Memory Usage: 271kB

-> Index Scan using markets_pkey on markets market4_ (cost=0.14..5.89 rows=83 width=7116) (actual time=0.003..0.176 rows=83 loops=1)

The Hash node includes information about the number of hash buckets and batches, as well as peak memory usage along with estimated and actual costs of building up the hash table.

After the hash table is built, the result of the nested loop join is scanned and using the primary_market_id as the hash key the hash table is probed to find all matching rows. (Hash Condition in hash join node).

Can we optimize the query?

In the query plan, the majority of the time (452.93 ms out of total 474.09 ms) is spent in the index scan of listings table to find the range between 113115554 and 113125553 which returns 9896 rows.

The corresponding query plan row is:

Index Scan using listings_pkey on listings listing1_ (cost=0.57..1196.67 rows=9273 width=827) (actual time=0.685..452.927 rows=9896 loops=1)

You will notice that the final result of the nested loop join between listings and search_keys table returns only 30 rows out of 9896 rows matched from the listings table. Looking closely, the listings and search_keys tables are joined on the listing table’s id, which has a far higher number of matching rows for the range of listing ids than what is needed.

Let’s modify the query’s WHERE clause to select listing ids in desired range from search_keys table instead of listings.

The execution plan for above query is:

QUERY PLAN

-----------------------------------

Hash Left Join  (cost=7.92..303.55 rows=303 width=8369) (actual time=1.138..12.669 rows=30 loops=1)

Hash Cond: (this_.primary_market_id = market4_.market_id)

->  Nested Loop Left Join  (cost=0.99..293.17 rows=303 width=1253) (actual time=0.501..11.987 rows=30 loops=1)

Filter: ((listing1_.country_code IS NULL) OR (listing1_.country_code = 'US'::text))

Rows Removed by Filter: 7

->  Index Scan using search_keys_listing on search_keys this_  (cost=0.43..38.76 rows=319 width=426) (actual time=0.050..5.378 rows=37 loops=1)

Index Cond: ((listing_id >= '113115554'::bigint) AND (listing_id <= '113125553'::bigint))

->  Index Scan using listing_id_available_photos on listings listing1_  (cost=0.57..0.79 rows=1 width=827) (actual time=0.175..0.175 rows=1 loops=37)

Index Cond: (this_.listing_id = listing_id)

->  Hash  (cost=5.89..5.89 rows=83 width=7116) (actual time=0.586..0.586 rows=83 loops=1)

Buckets: 1024  Batches: 1  Memory Usage: 271kB

->  Index Scan using markets_pkey on markets market4_  (cost=0.14..5.89 rows=83 width=7116) (actual time=0.004..0.263 rows=83 loops=1)

Execution time: 13.070 ms

(13 rows)

The optimized query takes 13 ms compared to 474 ms earlier. The key difference here is:

Index Scan using search_keys_listing on search_keys this_ (cost=0.43..38.76 rows=319 width=426) (actual time=0.050..5.378 rows=37 loops=1)

Index Cond: ((listing_id >= '113115554'::bigint) AND (listing_id <= '113125553'::bigint))

An Index Scan on search_keys table is performed to find listings with ids in range ('113115554' and '113125553') which takes 5.378 ms and returns 37 rows in contrast to 9896 rows in 452.927 ms returned by the previous execution plan that scanned listings table for the same.

More Resources

https://www.postgresql.org/docs/9.6/using-explain.html

https://pganalyze.com/docs/explain

https://tatiyants.com/pev/#/plans/new

PS — The query used an example here was optimized by Ken Brush and Robert Gay during a site outage event in Feb, 2020. Thanks Ken and Robert!

PostgreSQL EXPLAIN Explained was originally published in Code Red on Medium, where people are continuing the conversation by highlighting and responding to this story.

Dan Fabulich is a Principal Engineer at Redfin. (We’re hiring!)

When I first read the definition of micro-frontends, I didn’t “get it.” Specifically, when I read Cam Jackson’s article on martinfowler.com and Michael Geers’ mini-site micro-frontends.org, I was still asking myself questions like:

• Are we already doing micro-frontends? We’ve been using UI component frameworks for years. Are micro-frontends just UI components?
• If not, how would our code be different if we were using micro-frontends?
• But, seriously, what are micro-frontends?!

After more thinking and research, I’ve now figured out why I was struggling: both articles go to some lengths to avoid giving “micro-frontends” a clear definition, instead preferring to define the term using code examples and analogies. I think I’ve figured out a simple definition that makes more sense to me; I hope it makes more sense to you.

Micro-frontends are remote UI components, where subcomponent renderer code runs in a separate process from the “composer” code that composes subcomponents.

As a result of running subcomponents in separate processes:

• You can redeploy/restart a “micro-frontend” subcomponent process without redeploying/restarting other subcomponents, or the composer process. If a subcomponent process crashes, it doesn’t take down the other processes.
• The subcomponent processes don’t have to share any code with the composer. Taken to an extreme, each subcomponent can use its own UI component framework. (We probably want to avoid this, but if we want to switch frameworks, it’s nice to have this tool in our toolbox.)
• The composer can be very lightweight, since it doesn’t have to include subcomponent code. This is especially useful when the composer has to run on the client side, where downloading more code means launching more slowly.
• Subcomponents can render in parallel. (You don’t have to run subcomponents in separate processes to render them in parallel, but running them in separate processes does ensure that subcomponents can be run in parallel.)
• As in any distributed system, sometimes the composer may be unable to access its subcomponents. Ideally, the composer can fail gracefully, rendering at least some parts of the UI that are available. (But, on the other hand, we might want a particular component to fail completely if certain critical subcomponents aren’t available.)

There are many kinds of remote UI components (many kinds of micro-frontends)

UI components come in many shapes and sizes; each UI framework offers a different approach to composing UI out of reusable pieces. Similarly, there’s a wide variety of UI frameworks that support remote UI rendering.

• Server-side frameworks can have remote subcomponents. For example, you can have a no-JS server-side composer that requests pre-rendered HTML fragments from other backend services and assembles them into an HTML document. (This composer can be as simple as a web proxy, e.g. edge-side includes.)
• Some client-side frameworks, like Turbo (aka Turbolinks), support fetching different parts of the UI with parallel requests and composing them on the client side.
• Or you can go old-school and build a page out of <iframe>s! (But iframes mess with the browser’s back button—they’re like a miniature tab in the middle of your webpage—so you might prefer to use a lightweight mini-framework, making little gadgets that look like iframes but don’t mess with the back button.)
• New in 2021, React has Server Components whose code runs only on the server side; React can fetch the HTML for these components and embed them into the page without requiring the client to download client-side code to render/rerender the components.

This is the reason why why it’s so hard to wrap your head around micro-frontends. There are so many different kinds of micro-frontends, at least as many as there are UI frameworks. It’s notoriously difficult to do an apples-to-apples comparison of UI frameworks, and micro-frontend frameworks are no exception.

Seven reasons why you might not want/need remote UI rendering

Micro-frontends are the right choice for organizations that can afford the overhead in order to scale up. But you might not be able to afford the overhead, and you might not need those benefits in order to scale.

• All of the popular introductions to micro-frontends talk about how micro-frontends “allow” you to have multiple full-stack teams of developers, each team owning their own frontend and backend code. But you don’t have to use remote UI components to have multiple full-stack teams. You can have a monolithic UI runtime, where each team owns UI components that run together in the same process. (This is how most native apps have worked, since forever.) But beware, any one component in a monolithic UI process can take the whole app down with it.
• If subcomponents need to communicate with each other, it may be faster/easier to run them in the same process.
• If each subcomponent process is running duplicated framework code, it may save server resources (memory/CPU/money) to combine them into a single process. In addition, each process has to be monitored separately, which adds to the overhead of a distributed system.
• If you don’t need to redeploy subcomponents separately, you might not need remote UI components. (For example, if all subcomponents share the same UI framework, and you redeploy all subcomponents whenever you upgrade the framework, it might be better to just run them all in a single process and redeploy them all whenever any subcomponent changes.)
• You might want to run all of your code in a single process on the client for performance reasons. First-load performance is typically faster when you render on the server, running as little code as possible on the client, but once the client has all of the code, second-load performance can be faster when you render on the client, making as few network requests as possible. It’s a tradeoff!
• Sometimes we don’t want/need graceful degradation, when we want the whole UI to show an error if any component isn’t available.
• It’s possible to allow UI teams to deploy on different schedules while running code in a monolithic UI runtime by having the composer download renderer code, rather than requesting rendered UI from separate services. On the client side, this is the difference between rendering remote HTML in an <iframe> vs. downloading remote <script> and running it in the current page. (This is a typical pattern for “Login with Google/Facebook/Apple” buttons.) When you download renderer code at runtime, you get the advantages of decoupled deploys and easy communication between components, but you also take on the risk of one component crashing the entire UI.

P.S. Redfin is hiring.

Micro-Frontends Are Remote UI Components was originally published in Code Red on Medium, where people are continuing the conversation by highlighting and responding to this story.

Dan Fabulich is a Principal Engineer at Redfin. (We’re hiring!)

In Node 14, there are now two kinds of scripts: there are old-style CommonJS (CJS) scripts and new-style ESM scripts (aka MJS). CJS scripts use require() and module.exports; ESM scripts use import and export.

ESM and CJS are completely different animals. Superficially, ESM looks very similar to CJS, but their implementations couldn’t be more different. One of them is a honey bee, and the other is a murder hornet.

Calling CJS from ESM and vice versa is possible, but it’s a hassle.

Here are the rules, which I’ll explain in more detail below:

1. You can’t require() ESM scripts; you can only import ESM scripts, like this: import {foo} from 'foo'
2. CJS scripts can’t use static import statements like the one above.
3. CJS scripts can use asynchronous dynamic import() to use ESM, but that's a hassle, compared to synchronous require.
4. ESM scripts can import CJS scripts, but only by using the “default import” syntax import _ from 'lodash', not the “named import” syntax import {shuffle} from 'lodash', which is a hassle if the CJS script uses named exports. (Except, sometimes, unpredictibly, Node can figure out what you meant!)
5. ESM scripts can require() CJS scripts, even with named exports, but it’s typically not worth the trouble, because it requires even more boilerplate, and, worst of all, bundlers like Webpack and Rollup don’t/won’t know how to work with ESM scripts that use require().
6. CJS is the default; you have to opt-in to ESM mode. You can opt-in to ESM mode by renaming your script from .js to .mjs. Alternately, you can set "type": "module" in package.json, and then you can opt-out of ESM by renaming scripts from .js to .cjs. (You can even tweak just an individual subdirectory by putting a one-line {"type": "module"} package.json file in there.)

These rules are painful. Worse, for many users, especially newbies to Node, these rules are incomprehensible. (Fear not, I’ll explain them all here in this article.)

Many observers of the Node ecosystem have speculated that these rules are due to a failure of leadership, or even hostility toward ESM. But, as we’ll see, all of these rules are here for a good reason, which will make it very difficult to break these rules in the future.

I’ll conclude with four guidelines for library authors to follow:

• Consider shipping only ESM
• If you’re not shipping only ESM, ship CJS only
• Test that your CJS works in ESM
• If needed, add a thin ESM wrapper for your CJS named exports
• Add an exports map to your package.json

It’s all gonna be OK.

Discuss on Reddit
Discuss on Hacker News

Background: What’s CJS? What’s ESM?

Since the dawn of Node, Node modules were written as CommonJS modules. We use require() to import them. When implementing a module for other people to use, we can define exports, either “named exports” by setting module.exports.foo = 'bar' or a “default export” by setting module.exports = 'baz'.

Here’s a CJS example using named exports, where util.cjs has an export named sum.

// @filename: util.cjs
module.exports.sum = (x, y) => x + y;

// @filename: main.cjs
const {sum} = require('./util.cjs');
console.log(sum(2, 4));

Here’s a CJS example where util.cjs sets a default export. The default export has no name; modules using require() define their own name.

// @filename: util.cjs
module.exports = (x, y) => x + y;

// @filename: main.cjs
const whateverWeWant = require('./util.cjs');
console.log(whateverWeWant(2, 4));

In ESM scripts, import and export are part of the language; like CJS, they have two different syntaxes for named exports and the default export.

Here’s an ESM example with named exports, where util.mjs has an export named sum.

// @filename: util.mjs
export const sum = (x, y) => x + y;

// @filename: main.mjs
import {sum} from './util.mjs'
console.log(sum(2, 4));

Here’s an ESM example where util.mjs sets a default export. Just like in CJS, the default export has no name, but the module using import defines its own name.

// @filename: util.mjs
export default (x, y) => x + y;

// @filename: main.mjs
import whateverWeWant from './util.mjs'
console.log(whateverWeWant(2, 4));

ESM and CJS are completely different animals

In CommonJS, require() is synchronous; it doesn't return a promise or call a callback. require() reads from the disk (or perhaps even from the network), and then immediately runs the script, which may itself do I/O or other side effects, and then returns whatever values were set on module.exports.

In ESM, the module loader runs in asynchronous phases. In the first phase, it parses the script to detect calls to import and export without running the imported script. In the parsing phase, the ESM loader can immediately detect a typo in named imports and throw an exception without ever actually running the dependency code.

The ESM module loader then asynchronously downloads and parses any scripts that you imported, and then scripts that your scripts imported, building out a “module graph” of dependencies, until eventually it finds a script that doesn’t import anything. Finally, that script is allowed to execute, and then scripts that depend on that are allowed to run, and so on.

All of the “sibling” scripts in the ES module graph download in parallel, but they execute in order, guaranteed by the loader specification.

CJS is the default because ESM changes a lot of stuff

ESM changes a bunch of stuff in JavaScript. ESM scripts use Strict Mode by default (use strict), their this doesn't refer to the global object, scoping works differently, etc.

This is why, even in browsers, <script> tags are non-ESM by default; you have to add a type="module" attribute to opt into ESM mode.

Switching the default from CJS to ESM would be a big break in backwards compatibility. (Deno, the hot new alternative to Node, makes ESM the default, but as a result, its ecosystem is starting from scratch.)

CJS can’t require() ESM because of top-level await

The simplest reason that CJS can’t require() ESM is that ESM can do top-level await, but CJS scripts can't.

Top-level await lets us use the await keyword outside of an async function, at the “top level.”

ESM’s multi-phase loader makes it possible for ESM to implement top-level await without making it a “footgun.” Quoting from the V8 team’s blog post:

Perhaps you have seen the infamous gist by Rich Harris which initially outlined a number of concerns about top-level await and urged the JavaScript language not to implement the feature. Some specific concerns were:

• Top-level await could block execution.
• Top-level await could block fetching resources.
• There would be no clear interop story for CommonJS modules.

The stage 3 version of the proposal directly addresses these issues:

• As siblings are able to execute, there is no definitive blocking.
• Top-level await occurs during the execution phase of the module graph. At this point all resources have already been fetched and linked. There is no risk of blocking fetching resources.
• Top-level await is limited to [ESM] modules. There is explicitly no support for scripts or for CommonJS modules.

(Rich now approves of the current top-level await implementation.)

Since CJS doesn’t support top-level await, it’s not even possible to transpile ESM top-level await into CJS. How would you rewrite this code in CJS?

export const foo = await fetch('./data.json');

There’s an active debate on how to require() ESM in this thread. (Please read the whole thread and the linked discussions before commenting. If you dive in, you’ll find that top-level await isn’t even the only problematic case… what do you think happens if you synchronously require ESM which can asynchronously import some CJS which can synchronously require some ESM? What you get is a sync/async zebra stripe of death, that’s what! Top-level await is just the last nail in the coffin, and the easiest to explain.)

It’s frustrating, because the vast majority of ESM scripts don’t use top-level await, but, as one commenter wrote in that thread, “I don’t think designing a system with the blanket assumption that some feature just won’t get used is a viable path.”

Reviewing that conversation, it doesn’t look like we’re going to be able to require() ESM any time soon!

CJS Can import() ESM, but It’s Not Great

For now, if you’re writing CJS and you want to import an ESM script, you’ll have to use asynchronous dynamic import().

(async () => {
    const {foo} = await import('./foo.mjs');
})();

It’s… fine, I guess, as long as you don’t have any exports. If you do need to do some exports, you’ll have to export a Promise instead, which may be a huge inconvenience to your users:

module.exports.foo = (async () => {
    const {foo} = await import('./foo.mjs');
    return foo;
})();

ESM can’t import named CJS exports unless CJS scripts execute out of order

You can do this:

import _ from './lodash.cjs'

But you can’t do this:

import {shuffle} from './lodash.cjs'

That’s because CJS scripts compute their named exports as they execute, whereas ESM’s named exports must be computed during the parsing phase.

Fortunately for us, there’s a workaround! The workaround is annoying, but totally doable. We just have to import CJS scripts like this:

import _ from './lodash.cjs';
const {shuffle} = _;

There are no real downsides to this, and ESM-aware CJS libraries can even provide their own ESM wrappers that encapsulate this boilerplate for us.

This is totally fine! But don’t you just… wish it were better?

Out-of-order execution would work, but it might be even worse

A number of people have proposed executing CJS imports before ESM imports, out of order. That way, the CJS named exports could be computed at the same time as ESM named exports.

But that would create a new problem.

import {liquor} from 'liquor';
import {beer} from 'beer';

If liquor and beer are both initially CJS, changing liquor from CJS to ESM would change the ordering from liquor, beer to beer, liquor , which would be nauseatingly problematic if beer relied on something from liquor being executed first.

Out-of-order execution is still under debate, though the conversation seems to have mostly fizzled out a few weeks ago.

Dynamic Modules could save us, but their star is poisoned

There’s an alternative proposal that doesn’t require out-of-order execution or wrapper scripts, called Dynamic Modules.

In the ESM specification, the exporter statically defines all named exports. Under dynamic modules, the importer would define the export names in the import. The ESM loader would initially just trust that dynamic modules (CJS scripts) would provide all required named exports, and then throw an exception later if they didn’t satisfy the contract.

Unfortunately, dynamic modules would require some JavaScript language changes to be approved by the TC39 language committee, and they do not approve.

Specifically, ESM scripts can export * from './foo.cjs', which means to re-export all of the names that foo exports. (This is called a “star export.” 🤩)

Unfortunately, there’s no way for the loader to know what’s being exported when we star export from a dynamic module.

Dynamic-module star exports also create issues for spec compliance. For example, export * from 'omg'; export * from 'bbq'; is supposed to throw when both omg and bbq export the same named export wtf. Allowing the names to be user/consumer-defined means this validation phase needs to be post-handled / ignored somehow.

Proponents of dynamic modules proposed banning star exports from dynamic modules, but TC39 rejected that proposal. One TC39 member referred to this proposal as “syntax poisoning,” as star exports would be “poisoned” by dynamic modules.

(In my opinion, we’re already living in a world of syntax poison. In Node 14, named imports are poisoned, and under dynamic modules, star exports would be poisoned. Since named imports are extremely common and star exports are relatively rare, dynamic modules would reduce syntax poison in the ecosystem.)

This may not be the end of the road for dynamic modules. One proposal on the table is for all Node modules to become dynamic modules, even pure ESM modules, abandoning the ESM multi-phase loader in Node. Surprisingly, this would have no user-visible effect, except perhaps slightly worse startup performance; the ESM multi-phase loader was designed for loading scripts over a slow network.

But I don’t feel lucky. The Github issue for dynamic modules was recently closed, because there has been no discussion of dynamic modules in the last year.

Sometimes Node can synthesize named exports from CJS (but it’s unpredictable

The Node team, noticing how painful this is, put in a heroic effort to try to automatically parse CJS files to autodetect possible named exports! 😮

Node’s cjs-module-lexer attempts to automagically detect patterns like these:

exports.a = 'a';
exports['b'] = 'b';
if (false)
  exports.c = 'c';

Object.defineProperty(exports, 'd', { value: 'd' });
module.exports = {e: 'e'}

The problem is, it’s imperfect. It doesn’t work if the CJS uses patterns like these:

Object.defineProperty(exports, 'a', {
  get () {
    return 'nope';
  }
});

Object.defineProperties(...)

module.exports = {
  a,
  ...d, // ignored
  b: require('c'),
  c: "not detected since require('c') above bails the object detection"
}

The good news is, it was specifically designed to target the transpiled outputs of TypeScript, Babel, and Rollup. If you write your code in a TypeScript .cts file, Node will definitely detect all of your named exports!

ESM can require(), but it’s probably not worth it

require() is not in scope by default in ESM scripts, but you can get it back very easily.

import { createRequire } from 'module';
const require = createRequire(import.meta.url);

const {foo} = require('./foo.cjs'); 

The problem with this approach is that it doesn’t really help; it’s actually more lines of code than just doing a default import and destructuring.

import cjsModule from './foo.cjs';
const {foo} = cjsModule;

Plus, bundlers like Webpack and Rollup have no idea what to do with this createRequire pattern. So what’s the point?

What should you publish?

1. Consider shipping only ESM

ESM is the future, and there’s a solid movement of folks trying to put this whole fiasco behind us, and have everyone writing only ESM code.

The problem with shipping only ESM is that it’s a big inconvenience to CJS users. Your CJS users will have to await import your code instead of being able to synchronously require it.

If you already ship a library with CJS, shipping ESM-only is a backwards-incompatible breaking change. (Note that it’s easy to write an ESM wrapper for CJS libraries, but it’s not possible to write a CJS wrapper for ESM libraries.)

2. If you must publish CJS, publish only CJS

If you’re transpiling from TypeScript, you could transpile to both CJS and ESM, but this introduces a hazard that users may accidentally both import your ESM scripts and require() your CJS separately. (For example, suppose one library omg.mjs depends on index.mjs, while another library bbq.cjs depends on index.cjs, and then you depend on both omg.mjs and bbq.cjs.)

Node normally dedupes modules, but Node doesn’t know that your CJS and your ESM are the “same” files, so your code will run twice, keeping two copies of your library’s state. That can cause all kinds of weird bugs.

So, if you’re publishing CJS at all, and you’re writing in TypeScript or another language that transpiles to JS, transpile only to CJS.

3. Test that your CJS library works in ESM

Write a little test in a .mjs file, in ESM JS (without transpiling) and make sure you can import your CJS in the way you expect.

If you expect your ESM users to use a default import, like import mylibrary from 'mylibrary', make sure that works. If you export your ESM users to use named imports, like import {foo} from 'mylibrary', make sure that works.

If it doesn’t, you might need to provide a thin ESM wrapper for your CJS.

4. If necessary, provide a thin ESM wrapper for your CJS

(Again, note that it’s easy to write an ESM wrapper for CJS libraries, but it’s not possible to write a CJS wrapper for ESM libraries.)

import cjsModule from './index.cjs';

export const foo = cjsModule.foo; 

Put your ESM wrapper in a file using the .mjs extension.

5. Add an exports map to your package.json

Like this:

"exports": {
    "require": "./index.cjs",
    "import": "./index.mjs"
}

Beware: adding an exports map is always a “semver major” breaking change. By default, your users can reach into your package and require() any script they want, even files that you intended to be internal. The exports map ensures that users can only require/import the entry points that you deliberately expose.

That’s almost certainly a good thing! But it is a breaking change.

(If you allow your users to import or require() other files in your module, you can set up separate entry points for those, as well. See the Node documentation on ESM for details.)

Always include file extensions in export map targets. Refer to "index.cjs" not just "index" or a directory like "./build".

If you follow these guidelines, your users will be OK. Everything’s going to be all right.

P.S. Redfin is hiring.

Node Modules at War: Why CommonJS and ES Modules Can’t Get Along was originally published in Code Red on Medium, where people are continuing the conversation by highlighting and responding to this story.

When thinking about caching data for incredibly fast retrieval, technologies like Redis and Memcached often come to a developer’s mind. I, however, want to discuss a less commonly acknowledged cache that also helps with improving data retrieval time: a cache within a database.

The ability to fetch data quickly is crucial for any high throughput application and service. For the Notifications team at Redfin (the team I work on), it ensures that we can capture the updates in the US and Canadian real estate markets and inform our users within minutes of them occurring. A difference of several tens of milliseconds in process time per update event is enough to disrupt our pipelines and prevent us from delivering updates to our users in a timely manner.

In fact, that was exactly what happened to our email and push sending pipelines earlier last year. They couldn’t process the events quickly enough during times of peak traffic, so notifications were delayed to our customers. After some investigation, we discovered that the main bottleneck was the performance of retrieving data from our PostgreSQL database replica.

Although introducing external caching stores like Redis or Memcached to our applications would have been beneficial, we wanted to make sure that we were properly utilizing our database. In particular, we discovered in our investigation that our configurations for our database could have been modified for improved performance. Let’s walk through some of the techniques we did to discover and fix this.

Investigating bottlenecks in the query performance

Before looking for a solution, it is important to first understand why the queries are slow. There can be an assortment of reasons why, and some of them may not be related to the database. To narrow down the possibilities, you should look into the general health of the machines your applications are running on and the performance of all the various queries being made.

For instance, any CPU or network bottlenecks on the machine your application is running on can negatively impact its ability to quickly fetch data from the database. Other possibilities are that the queries are poorly written or that the tables don’t have certain indices that can help speed up those queries. If only one or a few queries are slow, that’s indicative that improving those queries will resolve the problem. If all of the queries are slow, even primary key lookups, then that’s a strong signal that the problem is unrelated to the query.

In the case that all queries are slow, you should examine the health of the machine that the database runs on. Bottlenecks in the machine’s computational power or I/O means that you will need to scale up your database. Good ways to examine this is to look at the CPU utilization of the machine, disk I/O, and network I/O.

One way to determine whether or not your database is maxing out on its processing ability is to take samples of the number of active queries running. To sample the number of active queries running on our PostgreSQL database, we can query the pg_stat_activity table:

select count(*) from pg_stat_activity where state='active'

If that number consistently exceeds the number of CPU cores of the machine, then that’s a good sign that your database is under-resourced.

Investigating the database’s internal cache performance

If your investigation leads you to believe that there are database performance issues, then you should consider analyzing the cache performance of your database. PostgreSQL databases use both an internal cache and the machine’s page cache for storing commonly requested data. That way, instead of pulling the data from disk, which can take milliseconds, the database replica can fetch the data in-memory in sub-millisecond times.

Postgres provides cache hit rate statistics for all tables in the database in the pg_statio_user_tables table. The two useful columns in that table are the heap_blks_read, defined as the “number of disk blocks read from this table” and the heap_blks_hit, defined as the “number of buffer hits in this table”. If we run the following query,

select heap_blks_read, heap_blks_hit from pg_statio_user_tables where relname='<table_name>';

we get the number of disk block reads and buffer hits for that given table since the creation of the table. If we store those values and run the above query again after some period of time, we can calculate the cache hit rate for that time period. To simplify doing the math every time, you can run the below query:

select
 heap_blks_read — <result from prev heap_blks_read> as misses,
 heap_blks_hit — <result from prev heap_blks_hit> as hit,
 (heap_blks_hit — <result from prev heap_blks_hit>)::float/(heap_blks_read — <result from prev heap_blks_read> + heap_blks_hit — <result from prev heap_blks_hit>) as hit_ratio
from pg_statio_user_tables
where relname='<table_name>';

Ideally, you will want the hit_ratio to be greater than 90%. Otherwise, you may need to tune your database configurations to improve the cache hit rate.

Improving Postgres internal cache performance

One of the main reasons why the cache hit rate for a table is low is that the database doesn’t have enough space allocated in its internal cache buffer. This internal cache buffer is used for loading the table rows from disk to memory, and if there isn’t enough space allocated, then the database server will constantly have to fetch the data from disk.

For PostgreSQL databases, the cache buffer size is configured with the shared_buffer configuration. It tells the database how much of the machine’s memory it can allocate for storing data in memory. The default is incredibly low (128 MB) because some kernels do not support more without changing the kernel settings. The optimal value ultimately depends on the data access patterns for a given database, but PostgreSQL recommends that you should initially configure it to 25% of the machine’s total memory if you are using a dedicated database server. More memory can be beneficial for larger databases, but there’s a limit to the optimization since PostgreSQL databases also use the system’s cache. The more memory you allocate to the shared_buffer, the less memory will be available for the machine’s cache.

Final Thoughts

There are also many other database configurations, such as the effective_cache_size, that are worth looking into and tuning if you still are seeing database performance issues. The optimal values for those configurations will depend on the data access patterns of the database, so having a good understanding of what tables are commonly queried and rows commonly fetched can help with guiding the decisions for those configurations. Ultimately, knowing how to tune them or whether they will have a significant impact is hard to say, so it’s always good to test some changes out and see their effects.

As mentioned earlier, a possible alternative would be to place an external cache (e.g. Redis, Memcached) in front of the database. It may come with the additional cost of maintaining the cache operationally or concerns with fetching data. However, for services and applications that share commonly fetched data, it can be a quick and cheap way of reducing data fetching latency.

How to Boost PostgreSQL Cache Performance was originally published in Code Red on Medium, where people are continuing the conversation by highlighting and responding to this story.

Redfin’s San Francisco office was thrilled to welcome 23 students from Everett Middle School for a visit earlier this month. The students were on a field trip with IGNITE Worldwide, a nonprofit that seeks to inspire young girls and non-binary students to pursue careers in STEM.

The day began with a tour of Redfin’s office, including a visit to our snack cabinets for some “brain food” for the morning ahead. Next, the students divided into smaller groups led by Redfin engineers for workshops that illustrated a day-in-the-life of various technical roles at Redfin.

Our employees worked with the students to experiment with redesigning Redfin’s mobile homepage, code styling changes to Redfin’s website in Chrome DevTools, and pick out differences in an image diff to demonstrate testing a hypothetical feature.

After the workshops, we had a panel discussion with six women in technical roles at Redfin who shared the stories of their journeys to careers in tech and answered the students’ questions about college and STEM careers. One of our favorites — especially given the generational gap — was when one of the students asked when we each got our first computers. A kid after our own hearts!

We ended our time together with lunch, where we discussed our favorite apps and what it means to be a successful woman, and a final trip to the snack cabinets before sending the students on their way. We were happy to hear that after the visit, 92% of the students were more interested in STEM, and eight more would like to investigate taking a STEM course. We had a wonderful time and hope they continue to explore the world of STEM!

Coding with Tomorrow’s STEM Leaders in San Francisco was originally published in Code Red on Medium, where people are continuing the conversation by highlighting and responding to this story.

Since 2006, Redfin has had engineering offices in two locations: Seattle and San Francisco. Having multiple locations with different composition of teams and roles allows Redfin to attract a wider range of talent. Now, in 2019, it’s time to add another engineering location to our portfolio and to welcome talented engineers to Redfin in a new place. That new place is Dallas.

While we’re planning to hire new engineers in Dallas this year, we also have a few Redfinnians making the move from our existing offices, including myself! After nearly seven years in San Francisco, I’m excited to meet new people, get to know a new area, and establish the next chapter of Redfin Engineering in Texas.

Dallas is a booming area, with a lot of engineering talent. At the same time, it’s much more affordable than San Francisco or Seattle. We set out to find a growing metro with great talent and a different feel from our West Coast offices, and Dallas promises to be an excellent new home.

Redfin already has key businesses in Dallas

As a real estate brokerage, Redfin employs people across the country (and in Canada!), not just in Seattle and San Francisco. Seattle is where the company was founded, and hosts our bustling headquarters with people in every department. San Francisco has been focused on technology from the beginning, with a smaller, more intimate atmosphere. In Dallas, we’ll have something in between: we already have a diverse array of roles and businesses operating in the Dallas area, including our core brokerage, Redfin Mortgage, support operations, and most recently, RedfinNow. Our local engineers will join these groups in a brand new office in Frisco, TX, working closely alongside these teams to build even better products for our customers.

Dallas presents new opportunities

The first engineers we hire to the new Dallas office have the unique opportunity to shape our engineering culture. While joining a company with nearly 200 engineers, they’ll also be setting the tone for the new Redfin Dallas identity and how we work with our existing offices in Seattle and San Francisco. We’re looking for people who are eager to build a new team atmosphere from the ground up, who can communicate with clarity and empathy both in person and virtually, and who love to roll up their sleeves and get things done.

The first full-stack engineering positions for our new office have been posted to our careers site. We’re starting with just a few positions on our Tours team (my team!), and we expect to open a few more roles later this year. We hope our new location will offer current Redfin engineers a new option for where to live, and bring new talent and perspectives from the Dallas area to Redfin as a whole.

You can always find our currently available engineering positions here. We’re hiring in all three engineering locations!

Why Redfin Is Opening a Dallas Engineering Office was originally published in Code Red on Medium, where people are continuing the conversation by highlighting and responding to this story.

Dan Fabulich is a Principal Engineer at Redfin. (We’re hiring!)

I’ve been spending the last month or so updating some legacy HTML to support screen readers. Screen-reader software can read a web page aloud, allowing visually impaired users to understand and interact with the page.

The problem is, sometimes the developers used <span> or <div> elements where they could have used <button> elements. Keyboard users can focus <button> elements with the Tab key, and click on them with the Enter key or Space bar; screen readers use the same rules.

By default, none of those keyboard shortcuts work for <span> or <div> elements. (In some cases, developers used <a> elements without an href attribute, which, as we’ll see, is no better than a <span> for accessibility.)

The “right thing” is to convert these elements into proper <button> elements, and, if needed, update the corresponding CSS rules to match the <button> instead of the old <span>/<div> element.

But the right thing turns out to be harder than you might think. Below are a few situations where the “right thing” can run into trouble; where possible, I’ve provided ways to cheat.

It’s like the right thing, but … different.

Buttons Can’t Display Inline

Check out this sample. It includes a simple <button> with all: unset anddisplay: inline.

Even though we forced the button to display: inline, you'll find that it's using display: inline-block, ignoring the style we set. That's why the “bar” button wraps to the second line, rather than appearing on the same line as “foo.”

This is the specified behavior in the HTML Rendering specification.

10.5.2. The button element

The <button> element is expected to render as an 'inline-block' box rendered as a button whose contents are the contents of the element.

This language is a bit cryptic, but what it means is that <button> elements will refuse to display: inline, even if you use !important.

Use the Dark Side: Make a Fake Accessible Button

The only way to cook up a button with display: inline is to do the “wrong” thing, using a non-button <span> element with an onclick handler.

To make those spans behave like buttons in a screen reader, you can add the role="button" attribute and the tabindex="0" attribute. You'll also want to add a keydown handler to handle the Enter and Space keys, like this:

span.addEventListener('keydown', function(e) {
  if (e.keyCode === 32 /*Space*/ || e.keyCode === 13 /*Enter*/) {
    e.target.click();
  }
});

In my case, this is very close to what was already there in the legacy code, so adding the roleand tabindex attributes plus a keydown handler is sometimes quicker and easier than doing the “right thing.”

By using the tag name that was already in the code, I didn’t need to modify any CSS to fix selectors that were expecting a <span>.

Buttons Will Submit Forms by Default

If the <div> that we're converting to a <button> happens to appear in a <form>, you'll find that the <button> becomes a submit button for the form.

That’s probably not what you intended!

<button> is implicitly <button type="submit"> by default. To prevent this, you can use <button type="button"> instead.

type="button" is clearly defined in the HTML spec:

Do nothing.

That’s my kind of button! Some people say that nothing is impossible, but type="button"proves them all wrong.

(Or you can use a fake button, as above.)

Links Without Href Aren’t Accessible

Occasionally, UI designers call for buttons that have link-like styling. In the legacy code I’m working on, I see a lot of <a> elements with no href and an onclick handler; these are effectively buttons that look like links.

But code like this is secretly busted:

<a onclick="alert('hi')">hi</a> 

In Chrome, that HTML won’t even appear as a link; it won’t have the default underline styling, and it won’t have a cursor pointer when you hover over it. Developers sometimes work around that by adding styling:

a {
  text-decoration: underline;
  cursor: pointer;
} 

… but that doesn’t fix the accessibility issues with these broken <a> elements. You can't use the Tab key to select these broken links, and you can't use the Enter key to use them.

<a> without href is no better than a <span>.

So, what can we do?

1. Add a fake href to the link, e.g. href="javascript:void(0)"
2. Convert the <a> into a <button>, but beware the issues raised above.
3. Convert the <a> into a fake button, as above. They'll need tabindex="0" and a keydown handler. While you're at it, you might as well add role="button".

Keyboard Accessibility Requires a Visible Focus State

The default focus outline for links and buttons doesn’t always look great. Some developers “fix” this by removing the outline entirely, with outline: none styling on all buttons and links.

But when you’re tabbing around the screen, the focus outline is the only way to know which element is selected. Thus, outline: none breaks keyboard navigation, even if all of the elements are technically keyboard navigable.

(This is an example where we need to think about multiple forms of accessibility. Blind users may not benefit from visible focus states if their screen reader provides auditory cues to indicate which element is selected, but other users who require a keyboard will benefit.)

In my case, the original designers didn’t like the default focus outline, but they were careful about adding a nice hover state for all elements, using the :hover pseudo-selector. By adding the :focus pseudo-selector to those same rules, I could use our lovely hover state as the focus state.

That’s all for now! Now get out there and do your best.

P.S. Redfin is hiring.

You Can Cheat When Fixing HTML Accessibility in Legacy Code was originally published in Code Red on Medium, where people are continuing the conversation by highlighting and responding to this story.

Redfin engineers attended Seattle area middle schools to lead an Hour of Code event.

Redfin recently led an event to give back to the community and provide our engineers an opportunity for team building. During a single day of the 2018 Computer Science Education Week, groups of Redfin engineers traveled to seventeen Seattle middle school STEM classes to run an Hour of Code with over 400 students. The goal: to inspire students to explore technology. The hope: to have students get excited about a technology career they would like to explore. Maybe, some would even become a Redfin engineer! Redfin provided each of the nine participating teachers with a choice of three hands-on, “unplugged” activities. Alvin Tran, one of our engineers, said about the event, “I really liked the feeling of having inspired some children in getting more interested in Computer Science. It also gave me a good chance to meet with members of teams other than my own, and to converse with them more.”

In order to ready our engineers for the event, we held three orientation sessions, one for each activity. At these sessions, the large group of engineers watched a small group of their peers demonstrate the activity. Through this strategy, all the engineers rose to the occasion. Early in December, each group of engineers hopped in a rideshare and headed out from Redfin headquarters to their assigned school. Although not every engineer felt totally confident about facing a class of middle schoolers, each engineer who responded to the post-event survey said he or she would do this type of event again. “It felt good that Redfin was giving back to the community,” said Shri Repp another of our engineers. “Was great to do something to help a younger generation get involved in tech.”

As for the teachers, all who responded to the survey also said they would like to participate again. “[I liked] how interactive the engineers were with the students. I think it helped them see the engineers as people like them which helps with role modeling,” said Dianna King, a teacher at Whitman Middle School. According to the teachers surveyed, the activities also went over well with the students. “Several students in [my] coding [class] understood the internet better after the lesson,” said Beverly Ferguson, a teacher at Hazel Wolf STEM K-8 School.

At the end of each class, a Q&A session gave students the opportunity to ask our engineers how they got into technology and what it’s like working in the technology industry. Annie Jarnagan, a teacher at Asa Mercer International Middle School, exclaimed, “This was by far the students’ favorite part!”

One of the highlights and heartwarming moments for our engineers, was a drawing created by one of the students at Catharine Blaine K-8 School. During class, the student hand drew a picture of what she thought Redfin is. She then handed it to one of our engineers at the end of class.

If you or your organization would like to lead a similar event at your local area schools, feel free to comment on this blog article and let us know. We would be happy to provide tips and lessons learned to get your event off the ground running.

Also, if you’re considering a career change or are looking for work, Redfin is hiring! Check out the Redfin careers page to learn more and apply.

Redfin Engineering’s Hour of Code Event at Local Schools was originally published in Code Red on Medium, where people are continuing the conversation by highlighting and responding to this story.

By Kyle Wong

As someone who was born and raised in California, avocados are staple food. On my first day of internship, after meeting all the interns, my amazing team (Agent Efficiency #AE), and a few other Redfin employees, I had some free time to explore the office. Out of curiosity, I checked out the kitchen, only to realize that there are so many avocados, even more than my previous internship in Downtown LA! This inspired my daily routine during work. When I arrive at the office around 8 AM, I make avocado toasts with different variations: with whole wheat bread or everything bagel, and any combination of the following: lemon, egg, sunflower seeds, pumpkin seeds, olive oil, salt, and black pepper. Now, I can still be a Californian in the beautiful city of Seattle.

Besides the daily routine, I had a very worthwhile internship. Based on what I hear from friends in some companies, I enjoyed the fact that Redfin gives a lot of important responsibility to interns, treating them as full-time employees. For instance, my team encouraged me to take on the tech debt representative role during the Seattle Redfin Summer 2018 Hackathon, which was initially daunting since I only had knowledge in a small subset of the team’s codebase.

Regardless, no matter which Redfin office I was at, Redfin consistently has an amazing company culture.

Also, Redfin interns (aka Redfinterns) get the chance to work on something challenging. For me, I had minimal experience working in the backend, which gives my team more reason to give me a project that has a heavy backend component. While I struggled a lot, asked many questions, and getting roasted on code reviews, I ended my internship learning so much and became a better software engineer. I also ended up producing a working feature in the agent tools: New Mutual Notifications on the Deal Queue. This project provides notifications to transaction coordinators on what deals reached the mutual acceptance stage recently, so the transaction coordinators can quickly work on those deals. According to my mentor and manager, this project is impactful as it meets the quarterly goal of making the deal queue more efficient by reducing response time of new mutual deals by 10% and providing ways to improve the customer experience of buying houses at Redfin. I am grateful I got to make a real impact to the company during the short period of time that is 12 weeks.

I also enjoyed the work-life balance Redfin strongly encourages. While working, there are Slack channels that are meant to be entertaining such as the #donuts channel, where you get “donuted” if you forget to lock your laptop when you leave the room; in other words, you have to bring donuts if someone posts “I bring donut” from your unlocked laptop in the #donuts channel :woot:! In the office, there is a wonderful game room with a ping pong table, video games, and a huge selection of board games. There are also fun outdoor intern events such as white water rafting at the Sauk River and hiking with Glenn the CEO at Poo Poo Point. In addition, we also got to participate in the general company events such as the summer hackathon, “social hours,” and picnic.

Personally, outside of work, I visited many places in Seattle, from the typical Space Needle and Chihuly Garden and Glass to hidden gems such as Chophouse Row and sunset at the Volunteer Park “donut” (It’s actually called the “Black Sun”). To satisfy my wanderlust, my manager even allowed me to work at the San Francisco office for a week (they have fewer avocados, ironically), so I got to experience the best of both worlds! Regardless, no matter which Redfin office I was at, Redfin consistently has an amazing company culture. I met amazing and brilliant people at both places; without all the people I met at Redfin, I honestly would not have learned as much and would not have gotten a lot out of this internship.

My Redfin Internship was originally published in Code Red on Medium, where people are continuing the conversation by highlighting and responding to this story.