<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*qD0JDT3Kk5RqJNwbE4E6FA.jpeg" /></figure>In the dynamic realm of relational databases, PostgreSQL stands tall as a versatile powerhouse. When it comes to optimizing database performance, there is a crucial tool that every developer and database admin relies on — indexes. In this blog post, we’ll take a closer look at PostgreSQL indexes — a handy tool for improving database performance. From demystifying what they are to mastering their creation, understanding when to use them, and ensuring they’re finely tuned, we’ll cover it all, peppered with real code snippets and examples.<h3>Decoding PostgreSQL Indexes</h3>Let’s start with the basics. An index in PostgreSQL is like a map that turbocharges your queries, enabling swift data retrieval. Picture an index as the table of contents in a book — it’s your shortcut to finding exactly what you need, without flipping through every page. Without indexes, databases would slog through entire tables to fetch data, leading to inefficient query performance, especially for large datasets.<h3>Crafting Indexes in PostgreSQL</h3><pre>CREATE INDEX index_name ON table_name (column_name);</pre>Indexes can be sprinkled over one or multiple columns in a table. But, hold on! The columns you pick for indexing and the type of index you choose are pivotal.<h3>The Index Selection Dilemma: When to Index</h3>Indexes are strong tools, but they’re not without their trade-offs. While they boost read performance, they can slow down write operations due to maintenance overhead. The key is to choose your battles wisely. Here are scenarios where indexes shine:<ol><li>Frequent Searches: If your application heavily relies on frequent searches within specific columns, indexing is the optimal choice.</li><li>Joining: Columns used in joining tables are prime candidates for indexing, ensuring faster data retrieval during joins.</li><li>Sorting &amp; Ordering: For columns playing sorting and ordering roles, indexing steps up the game of ORDER BY and GROUP BY clauses.</li></ol><h3>Navigating Index Types</h3>PostgreSQL spoils you with index types, each tailored to specific scenarios. Let’s explore a couple:<ul><li>B-tree Index: Your go-to choice. Great for range queries and equality comparisons.</li></ul><pre>-- Create a B-tree index on a single column CREATE INDEX idx_column_name ON table_name (column_name);</pre><pre>-- Create a B-tree composite index on multiple columns CREATE INDEX idx_multi_column ON table_name (column1, column2);</pre><ul><li>Hash Index: A heavyweight for equality checks, particularly when dealing with limited distinct values.</li></ul><pre>-- Create a hash index on a single column CREATE INDEX idx_column_name ON table_name USING hash (column_name);</pre>Since it <a href="https://www.postgresql.org/docs/current/indexes-types.html#INDEXES-TYPES-HASH:~:text=Hash%20indexes%20store%20a%2032%2Dbit%20hash%20code%20derived%20from%20the%20value%20of%20the%20indexed%20column.%20Hence%2C%20such%20indexes%20can%20only%20handle%20simple%20equality%20comparisons.%20The%20query%20planner%20will%20consider%20using%20a%20hash%20index%20whenever%20an%20indexed%20column%20is%20involved%20in%20a%20comparison%20using%20the%20equal%20operator%3A">uses equality checks(=)</a> If we specify a separate operator (such as pattern matching), it does not use the hash index.<ul><li>GIN (Generalized Inverted Index): A power player for array data queries and full-text search.</li></ul><pre>-- Create a GIN index on an array column CREATE INDEX idx_array_column ON table_name USING gin (array_column);</pre><pre>-- Create a GIN index for full-text search (requires the &quot;pg_trgm&quot; extension) -- Enable the extension if not already enabled CREATE EXTENSION IF NOT EXISTS pg_trgm; CREATE INDEX idx_full_text_search ON table_name USING gin (text_column gin_trgm_ops);</pre><ul><li>GiST (Generalized Search Tree): Versatile and valuable for various data types, including spatial data.</li></ul><pre>-- Create a GiST index on a geometry column (requires the &quot;postgis&quot; extension) -- Enable the extension if not already enabled CREATE EXTENSION IF NOT EXISTS postgis; CREATE INDEX idx_spatial_data ON table_name USING gist (geometry_column);</pre>Please note that for some index types (e.g., GiST and GIN), you may need to enable specific extensions (like “postgis” for spatial data or “pg_trgm” for text search) before you can create indexes of that type.<h3>Harnessing the Power of ANALYZE</h3>The ANALYZE command is your backstage pass to index insights. It offers statistics about table distribution and index usage, helping you evaluate their effectiveness.<h4>The ANALYZE Command:</h4><ul><li>The ANALYZE command is used to collect statistics about a table or an index. It provides the PostgreSQL query planner with information about the distribution of data within a table or index.</li><li>When you perform an ANALYZE operation on a table or an index, PostgreSQL takes a representative sample of the data and collects information about how the data is distributed.</li><li>ANALYZE is employed as part of regular database upkeep to ensure that the statistics remain current and relevant.</li></ul><pre>ANALYZE table_name;</pre><h4>EXPLAIN ANALYZE:</h4><ul><li>The EXPLAIN ANALYZE command is used to obtain the execution plan and performance statistics for a query without actually executing the query. It&#39;s a tool for understanding how PostgreSQL plans to execute a query and how long each part of the query takes to run.</li><li>When you run EXPLAIN ANALYZE followed by a query, PostgreSQL generates the query execution plan, executes the query, and then provides a detailed breakdown of how the query was executed, including the time spent on each step and the number of rows processed at each step. This information is valuable for query optimization and performance tuning.</li></ul><pre>EXPLAIN ANALYZE SELECT * FROM table_name WHERE column_name = &#39;value&#39;;</pre><h3>Indexing Strategies in Action</h3><h4>Scenario 1: Basic Indexing</h4>Imagine you’re overseeing a table named customers, which stores valuable information about your clients. You often need to search for customers using their email addresses. Here&#39;s how it looks:<pre>CREATE TABLE customers ( customer_id SERIAL PRIMARY KEY, first_name VARCHAR(50), last_name VARCHAR(50), email VARCHAR(100) ); INSERT INTO customers (first_name, last_name, email) VALUES (&#39;Arik&#39;, &#39;Jordan&#39;, &#39;Arik@example.com&#39;), (&#39;Jane&#39;, &#39;Smith&#39;, &#39;jane@example.com&#39;), (&#39;Michael&#39;, &#39;Johnson&#39;, &#39;michael@example.com&#39;);</pre>Without an index in place, when you want to find a specific email address, it’s like searching for a needle in a haystack. Here’s what the query would look like:<pre>EXPLAIN ANALYZE SELECT * FROM customers WHERE email = &#39;Arik@example.com&#39;;</pre><figure><img alt="" src="https://cdn-images-1.medium.com/max/684/1*1TwA_a0pSjS-ulV6Fpeg0Q.png" /><figcaption>EXPLAIN ANALYZE comman’s output — without index</figcaption></figure>Now, let’s create an index on the email column to speed up these queries, and see the output of the EXPLAIN ANALYZE command:<pre>CREATE INDEX idx_email ON customers (email); EXPLAIN ANALYZE SELECT * FROM customers WHERE email = &#39;Arik@example.com&#39;;</pre><figure><img alt="" src="https://cdn-images-1.medium.com/max/790/1*3Zb7hKTlX0VICjYpSDRcqQ.png" /><figcaption>EXPLAIN ANALYZE comman’s output — with index</figcaption></figure>Now the query plan using an index scan instead of a regular seq scan.Wait..! but you said ‘speed up’, it is taking longer now, how is that possible?we will figure it out in last section: When to Avoid Indexing: Situations to Consider.<h4>Scenario 2: Multi-Column Index</h4>In a slightly different scenario, you’re tasked with managing an orders table that keeps track of customer orders. You frequently need to find orders based on two things: the customer&#39;s ID and the order date. Here&#39;s how the orders table looks:<pre>CREATE TABLE orders ( order_id SERIAL PRIMARY KEY, customer_id INT, order_date DATE, total_amount DECIMAL(10, 2) ); INSERT INTO orders (customer_id, order_date, total_amount) VALUES (1, &#39;2023-01-15&#39;, 150.00), (2, &#39;2023-02-10&#39;, 200.00), (1, &#39;2023-02-20&#39;, 120.00);</pre>To make these order-based queries faster, we can create a multi-column index on both customer_id and order_date. It&#39;s like giving your database a roadmap for finding orders efficiently:<pre>CREATE INDEX idx_customer_order_date ON orders (customer_id, order_date);</pre>Now, your queries involving filtering by both criteria will be optimized for speed.<h4>Scenario 3: Index Order and Included Columns</h4>Imagine managing a products table with detailed information about various products. You frequently search for products based on their category and manufacturer. To create a covering index, including the product_name column in the index might enhance performance.<pre>CREATE TABLE products ( product_id SERIAL PRIMARY KEY, product_name VARCHAR(100), category VARCHAR(50), manufacturer VARCHAR(50), price DECIMAL(8, 2) ); INSERT INTO products (product_name, category, manufacturer, price) VALUES (&#39;Laptop&#39;, &#39;Electronics&#39;, &#39;ABC Electronics&#39;, 999.99), (&#39;Smartphone&#39;, &#39;Electronics&#39;, &#39;XYZ Mobile&#39;, 599.99), (&#39;Chair&#39;, &#39;Furniture&#39;, &#39;Furniture Co.&#39;, 149.99);</pre>Create an index with columns ordered by category and manufacturer, and include the product_name:<pre>CREATE INDEX idx_product_search ON products (category, manufacturer) INCLUDE (product_name);</pre><h3>Multi-Column Indexes Order</h3>Consider a scenario where you manage a database of products. The table includes several columns: product_id, category, manufacturer, price, and availability. You frequently run queries to filter products based on their category and manufacturer.<h4>Column Order Matters:</h4>When creating a multi-column index, the order of the columns is crucial. The leftmost column in the index plays a pivotal role. It should align with the most frequently filtered or sorted criteria in your queries.In our case, since we often filter by category first and then by manufacturer, the optimal index order should have category as the leftmost column.<pre>-- Correct Index Order (category, manufacturer) CREATE INDEX idx_product_search ON products (category, manufacturer);</pre>Now, when you run queries filtering by category and manufacturer, the index&#39;s hierarchy aligns perfectly with your query patterns, leading to efficient data retrieval.<h4>Incorrect Index Order:</h4>Conversely, if you create the index with an incorrect order, say, starting with manufacturer, it might not yield the same performance benefits:<pre>-- Incorrect Index Order (manufacturer, category) CREATE INDEX idx_incorrect_order ON products (manufacturer, category);</pre>Queries filtering by category first would not benefit from this index as much, as it doesn&#39;t match the leftmost prefix of the index.<h4>Querying with the Correct Index</h4>Now, let’s see how this well-ordered index improves query performance:<pre>SELECT * FROM products WHERE category = &#39;Electronics&#39; AND manufacturer = &#39;ABC Electronics&#39;;</pre>This query efficiently utilizes the multi-column index, benefiting from the leftmost category column.<h4>Querying without the Correct Index</h4>Contrast this with a query that doesn’t align with the index order:<pre>SELECT * FROM products WHERE manufacturer = &#39;ABC Electronics&#39; AND category = &#39;Electronics&#39;;</pre>This query might not fully leverage the index’s potential, resulting in potentially slower performance.<h3>When to Avoid Indexing: Situations to Consider</h3><ol><li>Highly Volatile Tables: Tables frequently changing with new data or updates may not benefit from indexes due to potential write performance impacts.</li><li>Small Tables: For very small tables with few rows, adding indexes may not significantly boost performance and could be unnecessary.</li><li>Low Selectivity Columns: Columns with limited distinct values might not gain much from indexing; focus on columns with higher variety.</li><li>Frequent Full Table Scans: When queries scan the entire table without leveraging indexes, the overhead of maintaining them may not be justified.</li><li>Batch Insert Operations: During large data imports, temporarily removing and then rebuilding indexes can expedite the process.</li><li>Temporary Tables: For short-lived tables rarely queried, adding indexes might not be worth the effort.</li><li>Queries with Low Complexity: Simple queries with minimal filtering may not see significant performance gains from indexes.</li><li>Low Latency Tolerance: In real-time applications, even minor indexing delays may not be acceptable, necessitating other optimization methods.</li></ol>Keep in mind that whether to use or skip indexes should be based on a thorough analysis of your specific database and your performance needs. It can be beneficial to closely examine your queries, both with and without indexes, and employ the EXPLAIN ANALYZE command to determine the actual impact on performance.<h3>Conclusion: Mastering the Art of Indexing</h3>Becoming professional in indexing is a must skill when working with the PostgreSQL database management system. By knowing which columns to index and understanding how indexing really works, you’ll have the tools to make your queries faster and more efficient. Don’t hesitate to experiment with various types of indexes, monitor their performance, and leverage included columns to create efficient covering indexes. Armed with these practical examples, you’ll be well-prepared to enhance the efficiency of your PostgreSQL database, ensuring that your application remains responsive and fast, even as your data continues to evolve and expand.<img src="https://medium.com/_/stat?event=post.clientViewed&referrerSource=full_rss&postId=5e4b0dc293e5" width="1" height="1" alt=""><hr><a href="https://medium.com/autodesk-tlv/mastering-postgresql-indexes-for-optimal-performance-5e4b0dc293e5">Mastering PostgreSQL Indexes for Optimal Performance</a> was originally published in <a href="https://medium.com/autodesk-tlv">Autodesk TLV</a> on Medium, where people are continuing the conversation by highlighting and responding to this story.

In the dynamic realm of relational databases, PostgreSQL stands tall as a versatile powerhouse. When it comes to optimizing database performance, there is a crucial tool that every developer and database admin relies on — indexes. In this blog post, we’ll take a closer look at PostgreSQL indexes — a handy tool for improving database performance. From demystifying what they are to mastering their creation, understanding when to use them, and ensuring they’re finely tuned, we’ll cover it all, peppered with real code snippets and examples.
Decoding PostgreSQL Indexes
Let’s start with the basics. An index in PostgreSQL is like a map that turbocharges your queries, enabling swift data retrieval. Picture an index as the table of contents in a book — it’s your shortcut to finding exactly what you need, without flipping through every page. Without indexes, databases would slog through entire tables to fetch data, leading to inefficient query performance, especially for large datasets.
Crafting Indexes in PostgreSQL
CREATE INDEX index_name ON table_name (column_name);
Indexes can be sprinkled over one or multiple columns in a table. But, hold on! The columns you pick for indexing and the type of index you choose are pivotal.
The Index Selection Dilemma: When to Index
Indexes are strong tools, but they’re not without their trade-offs. While they boost read performance, they can slow down write operations due to maintenance overhead. The key is to choose your battles wisely. Here are scenarios where indexes shine:

Frequent Searches: If your application heavily relies on frequent searches within specific columns, indexing is the optimal choice.
Joining: Columns used in joining tables are prime candidates for indexing, ensuring faster data retrieval during joins.
Sorting & Ordering: For columns playing sorting and ordering roles, indexing steps up the game of ORDER BY and GROUP BY clauses.

Navigating Index Types
PostgreSQL spoils you with index types, each tailored to specific scenarios. Let’s explore a couple:

B-tree Index: Your go-to choice. Great for range queries and equality comparisons.

-- Create a B-tree index on a single column
CREATE INDEX idx_column_name ON table_name (column_name);
-- Create a B-tree composite index on multiple columns
CREATE INDEX idx_multi_column ON table_name (column1, column2);

Hash Index: A heavyweight for equality checks, particularly when dealing with limited distinct values.

-- Create a hash index on a single column
CREATE INDEX idx_column_name ON table_name USING hash (column_name);
Since it uses equality checks(=) If we specify a separate operator (such as pattern matching), it does not use the hash index.

GIN (Generalized Inverted Index): A power player for array data queries and full-text search.

-- Create a GIN index on an array column
CREATE INDEX idx_array_column ON table_name USING gin (array_column);
-- Create a GIN index for full-text search (requires the "pg_trgm" extension)
-- Enable the extension if not already enabled
CREATE EXTENSION IF NOT EXISTS pg_trgm; 
CREATE INDEX idx_full_text_search 
ON table_name 
USING gin (text_column gin_trgm_ops);

GiST (Generalized Search Tree): Versatile and valuable for various data types, including spatial data.

-- Create a GiST index on a geometry column (requires the "postgis" extension)
-- Enable the extension if not already enabled
CREATE EXTENSION IF NOT EXISTS postgis; 
CREATE INDEX idx_spatial_data ON table_name USING gist (geometry_column);
Please note that for some index types (e.g., GiST and GIN), you may need to enable specific extensions (like “postgis” for spatial data or “pg_trgm” for text search) before you can create indexes of that type.
Harnessing the Power of ANALYZE
The ANALYZE command is your backstage pass to index insights. It offers statistics about table distribution and index usage, helping you evaluate their effectiveness.
The ANALYZE Command:

The ANALYZE command is used to collect statistics about a table or an index. It provides the PostgreSQL query planner with information about the distribution of data within a table or index.
When you perform an ANALYZE operation on a table or an index, PostgreSQL takes a representative sample of the data and collects information about how the data is distributed.
ANALYZE is employed as part of regular database upkeep to ensure that the statistics remain current and relevant.

ANALYZE table_name;
EXPLAIN ANALYZE:

The EXPLAIN ANALYZE command is used to obtain the execution plan and performance statistics for a query without actually executing the query. It's a tool for understanding how PostgreSQL plans to execute a query and how long each part of the query takes to run.
When you run EXPLAIN ANALYZE followed by a query, PostgreSQL generates the query execution plan, executes the query, and then provides a detailed breakdown of how the query was executed, including the time spent on each step and the number of rows processed at each step. This information is valuable for query optimization and performance tuning.

EXPLAIN ANALYZE SELECT * FROM table_name WHERE column_name = 'value';
Indexing Strategies in Action
Scenario 1: Basic Indexing
Imagine you’re overseeing a table named customers, which stores valuable information about your clients. You often need to search for customers using their email addresses. Here's how it looks:
CREATE TABLE customers (
    customer_id SERIAL PRIMARY KEY,
    first_name VARCHAR(50),
    last_name VARCHAR(50),
    email VARCHAR(100)
);
INSERT INTO customers (first_name, last_name, email)
VALUES
    ('Arik', 'Jordan', 'Arik@example.com'),
    ('Jane', 'Smith', 'jane@example.com'),
    ('Michael', 'Johnson', 'michael@example.com');
Without an index in place, when you want to find a specific email address, it’s like searching for a needle in a haystack. Here’s what the query would look like:
EXPLAIN ANALYZE SELECT * FROM customers WHERE email = 'Arik@example.com';
EXPLAIN ANALYZE comman’s output — without index
Now, let’s create an index on the email column to speed up these queries, and see the output of the EXPLAIN ANALYZE command:
CREATE INDEX idx_email ON customers (email);
EXPLAIN ANALYZE SELECT * FROM customers WHERE email = 'Arik@example.com';
EXPLAIN ANALYZE comman’s output — with index
Now the query plan using an index scan instead of a regular seq scan.
Wait..! but you said ‘speed up’, it is taking longer now, how is that possible?we will figure it out in last section: When to Avoid Indexing: Situations to Consider.
Scenario 2: Multi-Column Index
In a slightly different scenario, you’re tasked with managing an orders table that keeps track of customer orders. You frequently need to find orders based on two things: the customer's ID and the order date. Here's how the orders table looks:
CREATE TABLE orders (
    order_id SERIAL PRIMARY KEY,
    customer_id INT,
    order_date DATE,
    total_amount DECIMAL(10, 2)
);
INSERT INTO orders (customer_id, order_date, total_amount)
VALUES
    (1, '2023-01-15', 150.00),
    (2, '2023-02-10', 200.00),
    (1, '2023-02-20', 120.00);
To make these order-based queries faster, we can create a multi-column index on both customer_id and order_date. It's like giving your database a roadmap for finding orders efficiently:
CREATE INDEX idx_customer_order_date ON orders (customer_id, order_date);
Now, your queries involving filtering by both criteria will be optimized for speed.
Scenario 3: Index Order and Included Columns
Imagine managing a products table with detailed information about various products. You frequently search for products based on their category and manufacturer. To create a covering index, including the product_name column in the index might enhance performance.
CREATE TABLE products (
    product_id SERIAL PRIMARY KEY,
    product_name VARCHAR(100),
    category VARCHAR(50),
    manufacturer VARCHAR(50),
    price DECIMAL(8, 2)
);
INSERT INTO products (product_name, category, manufacturer, price)
VALUES
    ('Laptop', 'Electronics', 'ABC Electronics', 999.99),
    ('Smartphone', 'Electronics', 'XYZ Mobile', 599.99),
    ('Chair', 'Furniture', 'Furniture Co.', 149.99);
Create an index with columns ordered by category and manufacturer, and include the product_name:
CREATE INDEX idx_product_search 
ON products (category, manufacturer) 
INCLUDE (product_name);
Multi-Column Indexes Order
Consider a scenario where you manage a database of products. The table includes several columns: product_id, category, manufacturer, price, and availability. You frequently run queries to filter products based on their category and manufacturer.
Column Order Matters:
When creating a multi-column index, the order of the columns is crucial. The leftmost column in the index plays a pivotal role. It should align with the most frequently filtered or sorted criteria in your queries.
In our case, since we often filter by category first and then by manufacturer, the optimal index order should have category as the leftmost column.
-- Correct Index Order (category, manufacturer)
CREATE INDEX idx_product_search ON products (category, manufacturer);
Now, when you run queries filtering by category and manufacturer, the index's hierarchy aligns perfectly with your query patterns, leading to efficient data retrieval.
Incorrect Index Order:
Conversely, if you create the index with an incorrect order, say, starting with manufacturer, it might not yield the same performance benefits:
-- Incorrect Index Order (manufacturer, category)
CREATE INDEX idx_incorrect_order ON products (manufacturer, category);
Queries filtering by category first would not benefit from this index as much, as it doesn't match the leftmost prefix of the index.
Querying with the Correct Index
Now, let’s see how this well-ordered index improves query performance:
SELECT * FROM products 
WHERE category = 'Electronics' AND manufacturer = 'ABC Electronics';
This query efficiently utilizes the multi-column index, benefiting from the leftmost category column.
Querying without the Correct Index
Contrast this with a query that doesn’t align with the index order:
SELECT * FROM products 
WHERE manufacturer = 'ABC Electronics' AND category = 'Electronics';
This query might not fully leverage the index’s potential, resulting in potentially slower performance.
When to Avoid Indexing: Situations to Consider

Highly Volatile Tables: Tables frequently changing with new data or updates may not benefit from indexes due to potential write performance impacts.
Small Tables: For very small tables with few rows, adding indexes may not significantly boost performance and could be unnecessary.
Low Selectivity Columns: Columns with limited distinct values might not gain much from indexing; focus on columns with higher variety.
Frequent Full Table Scans: When queries scan the entire table without leveraging indexes, the overhead of maintaining them may not be justified.
Batch Insert Operations: During large data imports, temporarily removing and then rebuilding indexes can expedite the process.
Temporary Tables: For short-lived tables rarely queried, adding indexes might not be worth the effort.
Queries with Low Complexity: Simple queries with minimal filtering may not see significant performance gains from indexes.
Low Latency Tolerance: In real-time applications, even minor indexing delays may not be acceptable, necessitating other optimization methods.

Keep in mind that whether to use or skip indexes should be based on a thorough analysis of your specific database and your performance needs. It can be beneficial to closely examine your queries, both with and without indexes, and employ the EXPLAIN ANALYZE command to determine the actual impact on performance.
Conclusion: Mastering the Art of Indexing
Becoming professional in indexing is a must skill when working with the PostgreSQL database management system. By knowing which columns to index and understanding how indexing really works, you’ll have the tools to make your queries faster and more efficient. Don’t hesitate to experiment with various types of indexes, monitor their performance, and leverage included columns to create efficient covering indexes. Armed with these practical examples, you’ll be well-prepared to enhance the efficiency of your PostgreSQL database, ensuring that your application remains responsive and fast, even as your data continues to evolve and expand.

Mastering PostgreSQL Indexes for Optimal Performance was originally published in Autodesk TLV on Medium, where people are continuing the conversation by highlighting and responding to this story.

Mastering PostgreSQL Indexes for Optimal Performance

Developing Games for Android and iOS with Kotlin in Jetpack Compose
Jetpack Compose is Android’s recommended modern toolkit for writing and building native UI. Using compose we can bring our app to life using less code, and very quickly, but what about games ?
Recently, Jetbrains announced that compose Multiplatform will be able to target iOS for the first time (Desktop had already been supported for a while) which great news, since now we share the UI between our Android and iOS, which means that we can try to create our game and share the whole code between two platforms, and write it all using Compose.
Let’s see how this can be achieved.
Our first step will be to create new KMP (KMM name is deprecated) and run it to make sure we have a good starting point for running an Android and iOS app.
Our second step will be defining compose Multiplatform libraries support for the KMP, project since they aren’t a part of the basic template, and we need to manually add these libraries into our Gradle settings.
Also we will create a shared composable function that will be shared for Android and iOS.
Finally in the third step we will create a very simple game engine in compose in Kotlin(which is based on the wonderful tutorial of Sebastian Aigner almost two years ago — creating Asteroid game ! Check it out for more info)
First step — Creating KMP Project
Download latest Android Studio and open a new project
Select Kotlin Multiplatform App
Select Kotlin Multiplatform App and this template will generate all the needed files in order to run our app on Android and iOS.
Write your app’s name and package name
Write your app and package names and select the Minimum SDK in order to target your audience. I choose Android 8.1 since it targets most of the devices. Finally leave the build configuration as is, and click Next.0
Write your Android and iOS project names
In the next screen choose the Android and iOS project names and click Finish.
Once finished is clicked, AS will sync all the needed files (which can take a while, since on the first time it needs to download all the packages for KMP)
When finished, you can test and run that everything works OK, in AS click Play and for iOS — open the iOS folder, click on the iosBallApp.xcodeproj and open it using Xcode.
Open with Xcode
Inside Xcode, click Play and see the results :
Android and iOS apps running with KMP support
Second step — Define Jetpack Compose Multiplatform support
Next steps are needed in order to use the compose libraries inside the shared code, this will require manual settings inside the settings and Gradle files. Let’s jump into it.
Open gradle.properies file and add these lines :
kotlin.version=1.8.20
agp.version=8.0.1
compose.version=1.4.0
org.jetbrains.compose.experimental.uikit.enabled=true
kotlin.native.cacheKind=true
Next, open Project build.gradle.kts and replace the lines the template created with the following lines :
 kotlin("multiplatform").apply(false)
 id("com.android.application").apply(false)
 id("com.android.library").apply(false)
 id("org.jetbrains.compose").apply(false)
We just removed the constant versions and we added compose library plugin.
For android and shared build.gradle.kts , add also the plugin of compose as one of the plugins.
id("org.jetbrains.compose")
Inside the shared build.gradle.kts scroll down to the code where there are list of iOS and add isStatic = true so your code will look like this :
listOf(
 iosX64(),
 iosArm64(),
 iosSimulatorArm64()
 ).forEach {
 it.binaries.framework {
 baseName = "shared"
 isStatic = true
 }
 }
Next, we will add the compose dependencies to the common main module. Make sure your commonMain variable will have these dependenices :
val commonMain by getting {
 dependencies {
 implementation(compose.runtime)
 implementation(compose.foundation)
 implementation(compose.material)
 @OptIn(org.jetbrains.compose.ExperimentalComposeLibrary::class)
 implementation(compose.components.resources)
 }
 }
it’s ok that they are still marked in red color, since we didn’t sync the project yet. Let’s wait with the sync for a little bit.
Finally, let’s open settings.gradle.kts and add compose repository so all the dependencies can be resolved :
Add this inside Plugin management repositories, as well as inside the Resolution management :
maven("https://maven.pkg.jetbrains.space/public/p/compose/dev")
Then, inside the Plugin management code, add this block of code:
 plugins {
 val kotlinVersion = extra["kotlin.version"] as String
 val agpVersion = extra["agp.version"] as String
 val composeVersion = extra["compose.version"] as String
 kotlin("jvm").version(kotlinVersion)
 kotlin("multiplatform").version(kotlinVersion)
 kotlin("android").version(kotlinVersion)
 id("com.android.application").version(agpVersion)
 id("com.android.library").version(agpVersion)
 id("org.jetbrains.compose").version(composeVersion)
 }
This code takes the configuration we defined and applies the version to the plugins, so in the future we can easily change the versions.
Now we can click the sync Gradle with project files and hope that everything will sync correctly.
Now we will add shared composable functions that will be in use both for Android and for iOS.
Open commonMain package and add inside Kotlin a new file called App
Add App file tha will contain shared composable code
Add some composable content into that file, for example:
@Composable
fun App() {
 var count by remember { mutableStateOf(0) }
 Box(
 Modifier.fillMaxSize(),
 contentAlignment = Alignment.Center
 ) {
 Button(
 onClick = { count++ }
 ) {
 Text("Count: $count")
 }
 }
}
Next, we will need to use this composable function in Android and in iOS.
For android, let’s open our MainActivity and add the new composable function instead of the current code
class MainActivity : ComponentActivity() {
 override fun onCreate(savedInstanceState: Bundle?) {
 super.onCreate(savedInstanceState)
 setContent {
 MyApplicationTheme {
 App()
 }
 }
 }
}
For iOS we need to do some additional steps.
First, let’s open our iosMain package inside AS and add a new file called App and add this function inside the file :
fun MainViewController() = ComposeUIViewController {
 App()
}
This function creates an iOS style view controller that will be a special composable view controller since we are providing our shared composable function — App()
Second, we need to create a new file
Creating a new Composable view for iOS
Lets call it ComposableView swift file and add this content inside the file
import Foundation
import SwiftUI
import shared
struct ComposeView: UIViewControllerRepresentable {
 func updateUIViewController(_ uiViewController: UIViewControllerType, context: Context) {
 }
 
 func makeUIViewController(context: Context) -> some UIViewController {
 AppKt.MainViewController()
 }
 
}
We can see that we are statically calling our previous method MainViewController (from Kotlin) that will hold our composable shared code.
By running the code after the changes, we will see a simple composable views both on Android and on iOS written from same shared code.
Android and iOS are running the same composable code written once in compose.
This step is described very well by Philipp Lackner in his great tutorial video, you can check it out here
Third step — writing a small game engine.
Inside a commonMain package let’s create a Game class and MainGame file.
enum class GameState {
 STOPPED, RUNNING
}
class Game {
 var prevTime = 0L
 var width by mutableStateOf(0.dp)
 var height by mutableStateOf(0.dp)
 var gameState by mutableStateOf(GameState.STOPPED)
 var totalTime by mutableStateOf(0L)

 fun startGame() {
 gameState = GameState.RUNNING
 totalTime = 0L
 }
 fun endGame() {
 gameState = GameState.STOPPED
 }
 fun update(time: Long) {
 val delta = time - prevTime
 prevTime = time
 if (gameState == GameState.STOPPED) return
 totalTime += delta
 }
}
and MainGame composable with separate file.
@Composable
fun MainGame() {
 val game = remember { Game() }
 val density = LocalDensity.current
 LaunchedEffect(Unit) {
 while (true) {
 withFrameNanos {
 game.update(it)
 }
 }
 }
 Column(modifier = Modifier.background(Color(51, 153, 255)).fillMaxHeight().fillMaxWidth()) {
 Row(modifier = Modifier.align(Alignment.CenterHorizontally).fillMaxWidth()) {
 Button({
 if (game.gameState == GameState.STOPPED)
 game.startGame()
 else
 game.endGame()
 }) {
 Text(if (game.gameState == GameState.STOPPED) "Play" else "Stop")
 }
 Text(
 "${(game.totalTime / 1E8).roundToInt() / 10f} seconds.",
 modifier = Modifier.align(Alignment.CenterVertically).padding(horizontal = 16.dp),
 color = Color.White
 )
 }
 Box(modifier = Modifier
 .background(Color.Black)
 .fillMaxWidth()
 .fillMaxHeight()
 .clipToBounds()
 .onSizeChanged {
 with(density) {
 game.width = it.width.toDp()
 game.height = it.height.toDp()
 }
 }) {
 }
 }
}
We can see that we create our Game class and every time there is an update we call game.update(it) This is the heart of the engine, where update called with some times, and we can know how much time took to draw last frame.
if we compile and play our code, we will see a running time.
Running compose engine code — shows the running time
This maybe isn’t much but it’s actually a template for a very basic game, we just don’t have any game objects, and math and nothing but that’s can be easily added as well.
Let’s add some math library so we can use some basic math vectors.
Add this dependency to the commonMain dependencies, this allow us to use vectors with Float2 (by RomainGuy)
implementation ("dev.romainguy:kotlin-math:1.5.3")
Now let’s create some basic GameObject and add a basic functionality to it :
abstract class GameObject(
 speed: Float = 0.0F,
 angle: Float = 0.0F,
 position: Float2 = Float2()
) {
 companion object {
 val UNIT_X = Float2(1.0f, 0.0f)
 }
 var speed by mutableStateOf(speed)
 var angle by mutableStateOf(angle)
 var position by mutableStateOf(position)
 var movementVector
 get() = (UNIT_X.times(speed)).rotate(angle)
 set(value) {
 speed = length(value)
 angle = value.angle()
 }
 abstract val size: Float // Diameter
 open fun update(realDelta: Float, game: Game) {
 val obj = this
 val velocity = movementVector.times(realDelta)
 obj.position = obj.position.plus(velocity)
 }
}
Then let’s create a BallData class that will be inherited from this game object :
class BallData(
 ballSize: Float = 20f,
 val color: Color = Color.Red,
 var isEnabled: Boolean = true
) :
 GameObject() {
 override var size: Float = ballSize
 override fun update(realDelta: Float, game: Game) {
 if (!isEnabled) return
 super.update(realDelta, game)
 if (xOffset > game.width - size.dp || xOffset < 0.dp) {
 movementVector = movementVector.times(Float2(-1f, 1f))
 if (xOffset < 0.dp) position.x = 0f
 if (xOffset > game.width - size.dp) position.x = game.width.value - size
 } else if (yOffset > game.height - size.dp || yOffset < 0.dp) {
 movementVector = movementVector.times(Float2(1f, -1f))
 if (yOffset < 0.dp) position.y = 0f
 if (yOffset > game.height - size.dp) position.y = game.height.value - size
 }
 }
}
We handle the logic of the ball inside the update method, once the ball hits the walls, we change the vector direction.
Let’s add some code to our Game class that will handle the balls in the game.
class Game {
 var prevTime = 0L
 var gameObjects = mutableStateListOf<GameObject>()
 var gameState by mutableStateOf(GameState.STOPPED)
 var gameStatus by mutableStateOf("Let's play!")
 var totalTime by mutableStateOf(0L)

 fun startGame() {
 gameObjects.clear()
 repeat(10) {
 val ball = BallData(
 ballSize = random(25, 45),
 color = Color(
 red = Random.nextFloat(),
 green = Random.nextFloat(),
 blue = Random.nextFloat()
 )
 )
 ball.position = Float2()//Float2(width.value / 2.0F, height.value / 2.0F)
 ball.movementVector = Float2(1f, 0f)
 ball.speed = random(0, 8) + 16f
 ball.angle = random(0, 15) + 30f
 gameObjects.add(ball)
 }
 gameState = GameState.RUNNING
 gameStatus = "Good luck!"
 totalTime = 0L
 }
 fun update(time: Long) {
 val delta = time - prevTime
 val floatDelta = (delta / 1E8).toFloat()
 prevTime = time
 if (gameState == GameState.STOPPED) return
 for (gameObject in gameObjects) {
 gameObject.update(floatDelta, this)
 }
 val allDisabled = gameObjects.filterIsInstance<BallData>().all {
 !it.isEnabled
 }
 if (allDisabled && gameState == GameState.RUNNING) {
 winGame()
 }
 totalTime += delta
 }
 fun endGame() {
 gameObjects.clear()
 gameState = GameState.STOPPED
 gameStatus = "Better luck next time!"
 }
 fun winGame() {
 gameState = GameState.STOPPED
 gameStatus = "Congratulations!"
 }
 var width by mutableStateOf(0.dp)
 var height by mutableStateOf(0.dp)
}
We are creating 10 random balls and add them to game objects array, when game starts. Then for every update of the game, we call to the update for each ball, so each ball can move.
Once game ended, we clear all the objects. 
This is the main game loop.
In order for code to work we are using some extension methods, create file called GameExtensions.kt and add this code
val GameObject.xOffset: Dp get() = position.x.dp
val GameObject.yOffset: Dp get() = position.y.dp
inline val Float.asRadians: Float get() = this * 0.017453292f
inline val Float.asDegrees: Float get() = this * 57.29578f
fun Float2.angle(): Float {
 val rawAngle = atan2(y = this.y, x = this.x)
 return ((rawAngle / PI) * 180F).toFloat()
}
fun Float2.rotate(degrees: Float, origin: Float2 = Float2()): Float2 {
 val p = this - origin
 val a = degrees.asRadians
 val w = Float2(
 p.x * cos(a) - p.y * sin(a),
 p.y * cos(a) + p.x * sin(a)
 )
 return w + origin
}
fun random(min: Int, max: Int): Float {
 require(min < max) { "Invalid range [$min, $max]" }
 return min + Random.nextFloat() * (max - min)
}
Now let’s create a representation of a ball in compose :
@Composable
fun Ball(ballData: BallData) {
 val ballSize = ballData.size.dp
 Box(
 Modifier
 .offset(ballData.xOffset, ballData.yOffset)
 .size(ballSize)
 .clip(CircleShape)
 .background(ballData.color)
 .clickable { ballData.isEnabled = !ballData.isEnabled }
 )
}
and finally let’s use this inside our main game composable :
@Composable
fun MainGame() {
 val game = remember { Game() }
 val density = LocalDensity.current
 LaunchedEffect(Unit) {
 while (true) {
 withFrameNanos {
 game.update(it)
 }
 }
 }
 Column(modifier = Modifier.background(Color(51, 153, 255)).fillMaxHeight().fillMaxWidth()) {
 Row(modifier = Modifier.align(Alignment.CenterHorizontally).fillMaxWidth()) {
 Button({
 if (game.gameState == GameState.STOPPED)
 game.startGame()
 else
 game.endGame()
 }) {
 Text(if(game.gameState == GameState.STOPPED) "Play" else "Stop")
 }
 Text(
 game.gameStatus,
 modifier = Modifier.align(Alignment.CenterVertically).padding(horizontal = 16.dp),
 color = Color.White
 )
 Text(
 "${(game.totalTime / 1E8).roundToInt() / 10f} seconds.",
 modifier = Modifier.align(Alignment.CenterVertically).padding(horizontal = 16.dp),
 color = Color.White
 )
 }

 Box(modifier = Modifier
 .background(Color.DarkGray)
 .padding(50.dp)
 .border(BorderStroke(2.dp, Color.Red))
 .fillMaxWidth()
 .fillMaxHeight()
 .clipToBounds()
 ) {
 Box(modifier = Modifier
 .background(Color.Black)
 .fillMaxWidth()
 .fillMaxHeight()
 .clipToBounds()
 .onSizeChanged {
 with(density) {
 game.width = it.width.toDp()
 game.height = it.height.toDp()
 }
 }) {
 game.gameObjects.forEach {
 when (it) {
 is BallData -> Ball(it)
 }
 }
 }
 }
 }
}
These lines
game.gameObjects.forEach {
 when (it) {
 is BallData -> Ball(it)
 }
}
means that we are “drawing” the composable ball, and each ball will move by itself (once it’s position will change)
We also enable / disable the ball once it’s clicked, so for our game to end we count the number of disabled balls and when all balls are disabled, we win.
val allDisabled = gameObjects.filterIsInstance<BallData>().all {
 !it.isEnabled
}
if (allDisabled && gameState == GameState.RUNNING) {
 winGame()
 }
Let’s run the games and we will get :
Balls compose game in Android & iOS
I hope that these examples can help you get started with developing your own game using Jetpack Compose Multiplatform with Kotlin.
Please don’t hesitate to contact me with any questions.
Full source code :
GitHub - jazzyjester/BallsComposeKMP: Balls compose game for Android and iOS
Happy Koding !

How to write games for Android and iOS with Kotlin in Jetpack Compose ? was originally published in Autodesk TLV on Medium, where people are continuing the conversation by highlighting and responding to this story.

How to write games for Android and iOS with Kotlin in Jetpack Compose ?

<h4>The case for learning from traditional industries</h4>What does software product delivery have to do with Manufacturing or Visual arts? Well, they are all in the business of creation. And therefore, they all share a high-level fundamental process of taking a vague idea and turning it into reality. We call it the Fundamental Creation Flow, and as product managers, we are essentially doing one thing — moving ideas through the Fundamental Creation Flow.It doesn’t matter what your product is and how your team is structured. You start with a vague need that needs a solution, you push it one step forward to become a schematic solution and one more to become a detailed solution. And then you harness all your energies and team members to move one more step toward execution and make it a reality. You are literally pushing up an idea through the creation cycle.<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*NgFtP4ruFm6O84Oa7xUPwA.png" /><figcaption>Fundamental creation flow</figcaption></figure>And it&#39;s not just you. Everyone who gets up in the morning and attempts to create a reality in this world goes through the same high-level fundamental cycle. Architects, Writers, Artists, Construction contractors, Manufacturers, etc. As product managers, we can, and should, learn from creators in other industries. They encounter similar problems and solve them in wildly different ways from us.<h4>What we learned</h4>Can we leverage construction methodologies to solve the most effort-intensive part of the creation cycle — Execution? Can we plan more confidently and manage the execution with fewer communication breakdowns? We decided to try.At Autodesk, we build software for construction professionals. While conducting research for our Schedule tool, the product we built from scratch and released a few months ago, we were exposed to many techniques that innovative construction companies use to plan and execute some of the biggest projects humanity is building.It made us think.Construction entrepreneurs need to balance end-user needs alongside time-to-market and execution costs continually. Just like us. Construction site managers have dozens of subcontractors to keep synced and sequenced while making sure they can provide clarity on when things will be completed. Just like we need to manage three teams working on the same feature. Construction projects keep changing even when construction is underway and have numerous dependencies and clarifications that need to be resolved to make them tick. Just like every feature we ever built.We methodically embedded three construction management techniques based on<a href="https://leanconstruction.org/"> lean construction</a> methodology. We tweaked them a bit and polished them so they will work for software development. We packed them into an easy-to-embed framework that we call SWORD™.Its stands for — Syncs; WORk planning; Decision log And if parts of it sound like something you’re already doing, that’s great. But the real value lies with all of these parts working together to build a clear, collaborative execution engine.The results were clear from day one. We dramatically improved our ability to plan and track complex projects while minimizing open-ended questions to literally zero. Developers on our team report that they have more confidence in the processes and feel much more ownership over what they build. We call that a success.<h3>So, what is SWORD™ all about?</h3>Let’s get to the details.<h4>Work planning :</h4><figure><img alt="" src="https://cdn-images-1.medium.com/max/640/0*R8AbLAge6rnzp5Wv.jpg" /><figcaption>Construction work planning session; source: <a href="https://theleanbuilder.com/">https://theleanbuilder.com/</a></figcaption></figure>Work planning is a collaborative process that creates more accurate, efficient, and, most importantly — higher team commitment to plans. It is also an artifact that allows full transparency and readability of the execution for all stakeholders. Before every feature or initiative, we have a dedicated work planning meeting. All relevant stakeholders are there. Developers who build the feature, Designers, Products, QA, and others that we feel have experience building similar initiatives. It&#39;s not a kickoff meeting. We actually hold it after the kickoff, and everyone is already familiar with the feature. It is pure planning. We all have a tendency towards under-planning. This meeting, with everyone onboard, ensures you and your team take enough time to plan.The meeting has two parts,1. Work breakdown Each stakeholder with actionable tasks in this feature breakdown his work into tickets. Each ticket gets a working day estimation. Overall guidance is that if a ticket is more than five working days, it should be broken down into two. This is the only noncollaborative part of the process.2. Timing One by one, each team member places their tickets on the timeline. It sounds simple, but this is where the magic happens. The First developer places his tickets, and it usually goes like this:- BE Dev: puts his tickets on the timeline. - Tech lead — “I actually think you should do X before Y. I did something similar a few months ago. - Other BE Dev — “and there’s no way you’ll finish Z in 4 days. It’s at least 7 days work”That&#39;s nice. We just got our BE plan better and more accurate, but that&#39;s not all. Because now all other developers place their tickets as wellFE Dev: puts her tickets on the timeline BE Dev: “You can’t do this; you won’t have the API ready before I finish that ticket” QA: “ I think we better build this BE part before because then when we finish this FE ticket I have a QAable chunk” ( he puts QA ticket in place)The same happens with Designers and Products. Crucial dependencies are revealed, times are communicated and reviewed, and the overall sequence of execution is crystallized a few times and with the people that matter. All parts of the work are planted in the right places with everyone’s agreement and understanding.At the end of the meeting, we have an understandable, collaborative plan committed by the whole team. We pin it to our Slack channels and revisit it regularly (more on that in the Sync part of SWORD)There is no ideal place to handle work planning (yet). We use both Mural and some Construction-specific work planning software. The important thing is to allow color-coding by person and arrange rows by areas of work or vice versa.<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/0*Ude_0qlA5eVW2bJp" /></figure>(small work planning in Mural. Color-coded by team members. Important milestones that might affect all of the execution are marked with green checkboxes)<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/0*e64RFAnZxDhtjCG9" /></figure>(parts of a large work plan in construction work planning software. Color-coded by team members and arranged by area of work )<h4>Decision log:</h4>It doesn’t really matter how good you are in moving vague ideas into a concrete PRD. Once execution begins, you will have a bunch of things coming in from Devs, designers, and QAs that will need clear decisions. Don’t try to fight it by creating more detailed PRDs. You can’t. This is just the way reality works. Taking an idea into a schematic solution (high-level requirements and design wireframes for most of us Products) and then into a detailed Solution (detailed PRD document and design specs) is a process of narrowing it down through decisions. The execution phase isn’t any different. You will need to keep getting those in a tight team context, where everyone must be aligned, and decisions must be clear and discoverable.I used to lose items I should’ve decided on and would find out about them minutes before production. I used to decide things, communicate them in slack, and find out the opposite found its way into the code. Something wasn’t working. Our team came up with the Decision Log. A freestyle interpretation of the Construction projects Constraints Log.<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/0*-HtWLAAqv6-F0HII.jpg" /><figcaption>onsite constraints log; source: <a href="https://theleanbuilder.com/">https://theleanbuilder.com/</a></figcaption></figure>Decision Log is a collaborative table we handle per feature. Everyone has access to it and has the right to add items that need a decision. We try to keep the term “decisions” pretty loose to allow team members to add deliverables that block them or a design that needs a second look. Once a decision is made, it is documented, and its status changes from “To Decide” to “Decided and not synced”. Once requirements are updated, the design is tweaked, and the team is aligned, we change the status into “Decided and synced” Very lightweight. Very efficient.Personally, I also use it to document marketing decisions and high-level value proposition thoughts. This allows all team members to see all aspects of the emerging feature. I also have a filtered view with only open decisions I need to make across all features. For the first time in my career, I can open my day with a clear view of all the decisions I need to make. No multi-channel slack browsing, no going through the list of developers in my mind and thinking about what I owe to whom. Clear, collaborative, transparent decision log.<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/0*qBQmO4UftBNdWl-0" /></figure><figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/0*IRvjMHu7vTdcgWZl" /></figure><h4>Syncs</h4>We all do syncs. But they are not always that efficient. With Workplan and Decision log built into your process the syncs will get a new flavor and will become the place where everything gets connected. In our team, the feature owner — the developer who is responsible for making the feature happen, is the one who runs the syncs. And it has a very clear structure.(1) Go over the decision log — what’s open? What’s been recently decided but hasn’t been communicated? What’s the priority of the decisions? This part makes sure everyone is aligned on the information.(2)Go over the workplan — where are we? What is the next milestone? Who should get involved next? If needed- edits are made, and tasks are moved around to ensure the work plan reflects reality.<h3>Bottom line</h3>We have been working according to the SWORD framework for almost a year. Every feature we kickoff gets its own Workplan, its own Decision Log and dedicated syncs. With all its parts combined, we feel that this new framework provides unrivaled clarity and efficiency.<h3>Acknowledgments</h3>The creation of SWORD framework is a joint effort of Nitzan Sankevitz ; Einav Kivshany and myself. It was piloted, polished and fully adopted by the amazing Schedule team in Autodesk (Odiya Erlichster ; Liron Zluf ; Dor Tchizik ; Vipul Singh ; Gilad Green and Sagi Yemini)<img src="https://medium.com/_/stat?event=post.clientViewed&referrerSource=full_rss&postId=4fb505e0bc7d" width="1" height="1" alt=""><hr><a href="https://medium.com/autodesk-tlv/how-construction-project-management-boosted-our-software-execution-4fb505e0bc7d">How construction project management boosted our software execution</a> was originally published in <a href="https://medium.com/autodesk-tlv">Autodesk TLV</a> on Medium, where people are continuing the conversation by highlighting and responding to this story.

The case for learning from traditional industries
What does software product delivery have to do with Manufacturing or Visual arts?
Well, they are all in the business of creation. And therefore, they all share a high-level fundamental process of taking a vague idea and turning it into reality.
We call it the Fundamental Creation Flow, and as product managers, we are essentially doing one thing — moving ideas through the Fundamental Creation Flow.
It doesn’t matter what your product is and how your team is structured.
You start with a vague need that needs a solution, you push it one step forward to become a schematic solution and one more to become a detailed solution. And then you harness all your energies and team members to move one more step toward execution and make it a reality.
You are literally pushing up an idea through the creation cycle.
Fundamental creation flow
And it's not just you. Everyone who gets up in the morning and attempts to create a reality in this world goes through the same high-level fundamental cycle. Architects, Writers, Artists, Construction contractors, Manufacturers, etc. 
As product managers, we can, and should, learn from creators in other industries. They encounter similar problems and solve them in wildly different ways from us.
What we learned
Can we leverage construction methodologies to solve the most effort-intensive part of the creation cycle — Execution? Can we plan more confidently and manage the execution with fewer communication breakdowns?
We decided to try.
At Autodesk, we build software for construction professionals.
While conducting research for our Schedule tool, the product we built from scratch and released a few months ago, we were exposed to many techniques that innovative construction companies use to plan and execute some of the biggest projects humanity is building.
It made us think.
Construction entrepreneurs need to balance end-user needs alongside time-to-market and execution costs continually. Just like us. 
Construction site managers have dozens of subcontractors to keep synced and sequenced while making sure they can provide clarity on when things will be completed. Just like we need to manage three teams working on the same feature. 
Construction projects keep changing even when construction is underway and have numerous dependencies and clarifications that need to be resolved to make them tick. Just like every feature we ever built.
We methodically embedded three construction management techniques based on lean construction methodology. We tweaked them a bit and polished them so they will work for software development. 
We packed them into an easy-to-embed framework that we call SWORD™.
Its stands for — Syncs; WORk planning; Decision log 
And if parts of it sound like something you’re already doing, that’s great. But the real value lies with all of these parts working together to build a clear, collaborative execution engine.
The results were clear from day one. We dramatically improved our ability to plan and track complex projects while minimizing open-ended questions to literally zero.
Developers on our team report that they have more confidence in the processes and feel much more ownership over what they build.
We call that a success.
So, what is SWORD™ all about?
Let’s get to the details.
Work planning :
Construction work planning session; source: https://theleanbuilder.com/
Work planning is a collaborative process that creates more accurate, efficient, and, most importantly — higher team commitment to plans. It is also an artifact that allows full transparency and readability of the execution for all stakeholders.
Before every feature or initiative, we have a dedicated work planning meeting. All relevant stakeholders are there. Developers who build the feature, Designers, Products, QA, and others that we feel have experience building similar initiatives. 
It's not a kickoff meeting. We actually hold it after the kickoff, and everyone is already familiar with the feature. It is pure planning. 
We all have a tendency towards under-planning. This meeting, with everyone onboard, ensures you and your team take enough time to plan.
The meeting has two parts,
1. Work breakdown 
Each stakeholder with actionable tasks in this feature breakdown his work into tickets. Each ticket gets a working day estimation. Overall guidance is that if a ticket is more than five working days, it should be broken down into two. This is the only noncollaborative part of the process.
2. Timing
One by one, each team member places their tickets on the timeline. It sounds simple, but this is where the magic happens. 
The First developer places his tickets, and it usually goes like this:
- BE Dev: puts his tickets on the timeline.
 - Tech lead — “I actually think you should do X before Y. I did something similar a few months ago. 
- Other BE Dev — “and there’s no way you’ll finish Z in 4 days. It’s at least 7 days work”
That's nice. We just got our BE plan better and more accurate, but that's not all. Because now all other developers place their tickets as well
FE Dev: puts her tickets on the timeline
BE Dev: “You can’t do this; you won’t have the API ready before I finish that ticket”
QA: “ I think we better build this BE part before because then when we finish this FE ticket I have a QAable chunk” ( he puts QA ticket in place)
The same happens with Designers and Products. Crucial dependencies are revealed, times are communicated and reviewed, and the overall sequence of execution is crystallized a few times and with the people that matter.
All parts of the work are planted in the right places with everyone’s agreement and understanding.
At the end of the meeting, we have an understandable, collaborative plan committed by the whole team. We pin it to our Slack channels and revisit it regularly (more on that in the Sync part of SWORD)
There is no ideal place to handle work planning (yet). We use both Mural and some Construction-specific work planning software. The important thing is to allow color-coding by person and arrange rows by areas of work or vice versa.

(small work planning in Mural. Color-coded by team members. Important milestones that might affect all of the execution are marked with green checkboxes)

(parts of a large work plan in construction work planning software. Color-coded by team members and arranged by area of work )
Decision log:
It doesn’t really matter how good you are in moving vague ideas into a concrete PRD. Once execution begins, you will have a bunch of things coming in from Devs, designers, and QAs that will need clear decisions. 
Don’t try to fight it by creating more detailed PRDs. You can’t. This is just the way reality works. Taking an idea into a schematic solution (high-level requirements and design wireframes for most of us Products) and then into a detailed Solution (detailed PRD document and design specs) is a process of narrowing it down through decisions. The execution phase isn’t any different. You will need to keep getting those in a tight team context, where everyone must be aligned, and decisions must be clear and discoverable.
I used to lose items I should’ve decided on and would find out about them minutes before production. I used to decide things, communicate them in slack, and find out the opposite found its way into the code. Something wasn’t working. 
Our team came up with the Decision Log. A freestyle interpretation of the Construction projects Constraints Log.
onsite constraints log; source: https://theleanbuilder.com/
Decision Log is a collaborative table we handle per feature. Everyone has access to it and has the right to add items that need a decision. We try to keep the term “decisions” pretty loose to allow team members to add deliverables that block them or a design that needs a second look. 
Once a decision is made, it is documented, and its status changes from “To Decide” to “Decided and not synced”. Once requirements are updated, the design is tweaked, and the team is aligned, we change the status into “Decided and synced” 
Very lightweight. Very efficient.
Personally, I also use it to document marketing decisions and high-level value proposition thoughts. This allows all team members to see all aspects of the emerging feature. 
I also have a filtered view with only open decisions I need to make across all features. For the first time in my career, I can open my day with a clear view of all the decisions I need to make. No multi-channel slack browsing, no going through the list of developers in my mind and thinking about what I owe to whom. Clear, collaborative, transparent decision log.

Syncs
We all do syncs. But they are not always that efficient. With Workplan and Decision log built into your process the syncs will get a new flavor and will become the place where everything gets connected. 
In our team, the feature owner — the developer who is responsible for making the feature happen, is the one who runs the syncs. And it has a very clear structure.
(1) Go over the decision log — what’s open? What’s been recently decided but hasn’t been communicated? What’s the priority of the decisions? This part makes sure everyone is aligned on the information.
(2)Go over the workplan — where are we? What is the next milestone? Who should get involved next? If needed- edits are made, and tasks are moved around to ensure the work plan reflects reality.
Bottom line
We have been working according to the SWORD framework for almost a year. Every feature we kickoff gets its own Workplan, its own Decision Log and dedicated syncs. With all its parts combined, we feel that this new framework provides unrivaled clarity and efficiency.
Acknowledgments
The creation of SWORD framework is a joint effort of Nitzan Sankevitz ; Einav Kivshany and myself. It was piloted, polished and fully adopted by the amazing Schedule team in Autodesk (Odiya Erlichster ; Liron Zluf ; Dor Tchizik ; Vipul Singh ; Gilad Green and Sagi Yemini)

How construction project management boosted our software execution was originally published in Autodesk TLV on Medium, where people are continuing the conversation by highlighting and responding to this story.

How construction project management boosted our software execution

If you’re a QA Engineer and you’re currently considering your career growth opportunities, Product Management can be a great potential growth path. This might be a win-win situation — you’ll continue dealing with the quality of the product, the user experience as well as the mission of making the life of your customers better. This change also comes with making bigger decisions, having closer communication with customers and customer-facing colleagues.That being said, we all know that career shifts are never easy. They require a lot of hard work, motivation and persistence. Also, they usually take time and they are full of uncertainties and open questions. In this article, I’d like to share with you 14 practical tips I collected during my journey, starting from the point I realized that I want to become a Product Manager and ending up with me stepping into a Product Management role at Autodesk five months ago. In addition, I’ve cherry picked 13 recommendations for courses, books and articles.I started my journey at Autodesk 5 years ago as a manual &amp; automation QA engineer. At that time I was in my last year of the Hebrew University of Jerusalem, pursuing my BSc in Computer Science &amp; Business Management. I quickly realized that I’m passionate about getting to know customers, their pain points and day-to-day workflows. I was curious about the wide vision that Product Managers have, so I set myself a goal to transition to Product Management.I have a goal, cool! Now what?<blockquote>Tip #1: Share your career goals with your manager. Also, continuously reflect to your manager your progress and your achievements.</blockquote><blockquote>Tip #2: Create a formal development plan with clear milestones &amp; dates. Make sure to share it with your Manager.</blockquote>Once I set a goal for myself, I decided to share it with my manager, <a href="https://medium.com/u/eda3db1e314a">Hagai Galai</a>. He was supportive and he agreed that Product Management role is a good fit for me. My homework was to understand this role better and list the responsibilities of a Product Manager. In addition, I needed to list the skills of a Product Manager. After massive reading online, I realized that the definition of Product Manager role varies across different companies. Nonetheless, I summarized my conclusions and I came up with the following:<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*WXHeHVbHOF6rLos-UsR-Ig.png" /></figure><figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*IapET8MzcCYte8_2wAYG_g.png" /></figure>Now I have a goal and I know what skillset is required. Also, I (think that) I understand better the Product Manager role and I still think that it can be a good fit for me.It seems that everything is ready and we’re good to go. Wait, go where…? I’m at point A and I really (really) want to get to point B. Point B seems very far but I still want to get there. So… What do I do? Should I focus on theoretical learning or practical learning? The answer is both, preferably in parallel.Learning the theoretics gives a good basis.<blockquote>Tip #3: Read Product Management related articles &amp; books.</blockquote>Reading books / articles won’t make you a Product Manager. However, it gives you the ability to learn from the experience of other people (and from their mistakes). It also gives you a variety of point of views as well as basic knowledge.Article recommendations:<ol><li><a href="https://blog.hubspot.com/service/become-product-manager">“How to become a Product Manager?”</a> Written by Scott Judson</li></ol>2.<a href="https://medium.com/free-code-camp/how-to-break-into-product-management-d354944308c0">“So you want to be a Product Manager? Here is how I started”</a> by <a href="https://medium.com/free-code-camp/how-to-break-into-product-management-d354944308c0">Melanie Lei</a>3. “<a href="https://naomi.com/naomi-isms-10558c20144b">Naomi-isms</a>” by <a href="https://naomi.com/?source=post_page-----10558c20144b--------------------------------">Naomi Gleit</a> (Meta head of Product)4. “<a href="https://roadmunk.com/guides/product-management-articles-product-manager-content/">25 must-read product management articles</a>” by LatifBook recommendations:<ol><li>The Lean Product Playbook by Dan Olsen (4.7 stars in Amazon — 795 reviews).</li><li>Product Leadership by Martin Eriksson, Nate Walkingshaw and Richard Banfield (4.3 stars in Amazon — 257 ratings).</li><li>Hooked by Nir Eyal (4.6 stars in Amazon — 4784 ratings).</li><li>Inspired by Marty Cagan (4.6 stars in Amazon — 3206 ratings).</li><li>The Design of Everyday Things by Don Norman (4.6 stars in Amazon — 4713 ratings).</li><li>The MOM test by Rob Fitzpatrick (4.7 stars in Amazon — 1306 ratings).</li></ol><blockquote>Tip #4: Don’t invest too much time reading articles &amp; books. Go get your hands dirty!</blockquote>The problem with theoretical learning is that, well, it’s theoretical. Not surprisingly, things in the real world slightly differ from the way they’re described in theory. Therefore, it’s important to not overload yourself with theoretical information.Constantly seek opportunities to get hands-on experience.<blockquote>Tip #5: Get a mentor in the company who can teach you and give you Product Management tasks, providing constant feedback on your work.</blockquote><blockquote>Tip #6: Be proactive.</blockquote>Product Management is a wide profession. There are A LOT of things to learn and get experience in. Since I wasn’t sure where to start, I went with the obvious cliché and I found myself a mentor in the company.When you want to transition to any role, you might benefit from working closely with the person who fulfills this role in your team. If you’re lucky, you’ll find amazing people who are willing to mentor you. These people believe in you and they’ll probably become your advocates in the company. After all, they know you best.I was mentored by two Product Managers (<a href="https://medium.com/u/b3a732105655">Dror Ogen</a> and <a href="https://medium.com/u/f859c6da7c25">Roei Oved</a>) for around three years. The mentorship with the first Product Manager (Dror) was a tricky one. Being a single manual &amp; automation QA engineer for two products, I struggled with finding the correct balance between Product Management tasks and my day to day work. Later on, I became QA owner of a single product and Roei became the Product Manager in my team. This was an opportunity to create a healthier balance and to get “official” time for Product Management tasks.While working with Roei I got experience in the following areas:<ol><li>Performing competitive analysis.</li><li>Formulating customer needs / pain points and translating them to problems (and later on — solutions).</li><li>Brainstorming for possible solutions for customers’ problems.</li><li>Leading the development of several features, from brainstorming solutions, writing detailed requirements, accompanying dev team during development, testing the feature (I’m the QA, remember?😉) and gathering Analytics in Production.</li></ol><blockquote>Tip #7: If you’re doing Product Management tasks in addition to fulfilling a different role, don’t be shy to say NO when it becomes too stressful or doesn’t advance your goals.</blockquote>Roei and I agreed that if there is something I’m interested to work on, I can say it. The second agreement we had is that if I feel too stressed with my tasks, I can say “I don’t have time for X, Y and Z. Can you please take these tasks?”. The constant feedback from my mentor(s) helped me in enriching my Product Management skill sets and improving myself. I’m very grateful for this.Balance is everything in life.It took time to find the correct balance for me. I had weeks where 20% of my time was invested in Product related tasks and I had weeks where 60% percent of my time was invested in it. I also had weeks with 0% time for product related tasks. Having clear priorities helped me a lot. Also, I took product related tasks with enough buffer, meaning I could work on them in parallel with my regular day to day tasks. In addition, I learned to use my time in a more effective way and temporary cancelled my nap time in the weekends. Also, I didn’t have more than one “hands on” task in parallel with my other duties. I knew that by keeping my original responsibilities, no one has a reason to push me back.Make no mistake — it was challenging to make this work. However, it’s not impossible. It requires a successful combination of my will, my hard work, the support of the people around me and a company that supports my career development goals.Leveraging your current position for your career development is effective. It’s not surprising that people shift to Product Management from various roles and professions, such as Customer Support, Customer Success, Development, QA, etc. The challenge is to find the benefits in your current role and leverage them for your long term plans by taking active actions. What are the benefits of QA Engineers?Similar to Product Managers, QA Engineers have a deep understanding of the product. They have wide vision and they’re very familiar with all the flows, including the smallest details. In most cases, they know the product as well as the Product Manager.<blockquote>Tip #8: Use your deep technical knowledge and try to “transform” it into a more business and customer oriented thinking.</blockquote>When testing a feature, make sure that you understand the value for the customer and that you know how it serves the business. When working with a product requirements document, I always asked myself how would a customer feel when using the new feature? Will the flow be clear to them? Will they notice the new feature? Is there a way we can improve it?<blockquote>Tip #9: Try to get as close as you can to customers.</blockquote>Knowing your customers, their day to day workflows, and their pain points is the responsibility of every Product Manager. In order to obtain this knowledge, you need to learn their world. Since we develop software for construction companies, I decided to read a book related to construction.Also, I joined as many zoom meetings with the customers as I could. Watching how customers use our product is priceless. It changed the way I test things and it often affected the prioritization of bugs in our backlog. Customers like to talk (a lot) about their day to day, their experience and things they’re struggling with. This way you get “real” information about their life, as opposed to “theoretical” information you get when reading a book. I also took these meetings as a good opportunity to practice my note taking skills, to learn how other Product Managers interact with customers and how they ask questions.Another good way to understand the customers is to visit them and meet them in person. I was lucky to join a few team members and visit our customers in New York. We met with customers in construction sites and in their office. I learned A LOT in a few days. I had the opportunity to watch “live” how customers use our product and to understand better their day to day as well as their struggles.<blockquote>Tip #10: Integrate Product Management practices into your day to day QA work</blockquote>I saw many times how Roei used data in order to make decisions. He often asked the developers to query Production or he extracted data by himself using (frontend) Analytics. I thought that I can base my decisions / requests on data as well. For example, if I want a certain bug to be fixed, I can look for the relevant analytics to “prove” that it’s an important bug to fix.Surrounding yourself with people who have a similar goal is strongly recommended.<blockquote>Tip #11: Talk to as many Product Managers as you can.</blockquote>When you’re going abroad, (most of the time) you read ahead about the destination and you consult with your acquaintances who have already visited this destination. You’ll probably also join related facebooks groups in order to find recommendations and tips.Same here. I joined several facebook groups of people who want to become Product Managers. Also, I talked to as many Product Managers as I could, both inside and outside of Autodesk. In addition, there is a large variety of meetups to attend and other related events.<blockquote>Tip #12: Join facebook groups related to Product Management.</blockquote>Facebook group recommendations:<ol><li><a href="https://www.facebook.com/becoming.product.managers">Becoming Product Managers</a>.</li><li><a href="https://www.facebook.com/groups/688697767972955">Product Queens</a>.</li><li><a href="https://www.facebook.com/groups/604877569659870">Product Tank TLV.</a></li></ol><blockquote>Tip #13: Take Product Management related courses.</blockquote>Similarly to reading books and articles, Product Management courses won’t make you a Product Manager. However, there are many available courses that can enrich your knowledge and provide you with valuable additions to your skills set.Course recommendations:<ol><li><a href="https://giveandtech.org.il/product-management-101-april2022/">101 Product Management</a> (I took this course).</li><li><a href="https://www.productexperts.co.il/">Product Experts</a></li><li><a href="https://www.linkedin.com/learning/topics/product-management?u=67553434\">Product Management courses</a> in LinkedIn Learning.</li></ol><blockquote>Tip #14: Networking is priceless!</blockquote>Around nine months ago I completed a 12 weeks Product Management course called <a href="https://giveandtech.org.il/product-management-101-april2022/">101 Product Management</a>. It gave me various practical tools in a variety of product related areas. In addition, I had the opportunity to expand my network of connections. I strongly recommend this course.<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/0*lEibyQWOqBWQvUBu" /></figure>A pause.Almost two years ago I gave birth to my son and I was on maternity leave for one year. During that time I practiced my Product Management skills from another angle. I had to learn how to manage in stressful situations, how to address unexpected changes and how to handle a “customer” with frequently changing requirements.Timing &amp; Opportunity is the best combination.One month after I returned from maternity leave, an opportunity came up. I applied for a PM position in Autodesk. I went through several interviews with multiple people, technical product interview and I worked on a home assignment that I later presented to 8 people (PMs, UX leads and Engineering Managers). The benefit with these internal transitions is that the home assignment was related to the product and a world I’m (very) familiar with.Well, mission accomplished! I got from point A to point B! I got my first position as a Product Manager. Moreover, I transitioned from QA to PM position in the same team! This was a huge benefit for me. When you transition to a new position in a new company, you need to learn both a new world &amp; a new role. When you make the transition inside the same team, you can be more focused on learning Product Management. Thank you, <a href="https://medium.com/u/7733b3ba802">Tomer Rosenthal</a>, for believing in me and giving me this opportunity. Also, I appreciate the help with onboarding to this new role and the fact that you are not surprised anymore when I ask you “Hi, I have a question. Are you available for a zoom?”.Five months have passed since I officially became a Product Manager. I must admit that everything looked a bit scary and overwhelming in the beginning. However, it got better pretty quickly. I’ve learned a lot so far and I have so much more to learn.Remember how I wanted to get from point A to point B? Now I need to define point C and get there. I’m very excited to begin a new journey with new goals and new challenges!To summarize, there is no precise recipe for creating big career shifts. Everybody has their own path and their own pace. I think that it’s important to stay focused on your goal, to define clear milestones, to get a mentor, to be patient and understand that this is a process, it takes time and it requires a combination of opportunity &amp; timing.<img src="https://medium.com/_/stat?event=post.clientViewed&referrerSource=full_rss&postId=f514db5bb476" width="1" height="1" alt=""><hr><a href="https://medium.com/autodesk-tlv/14-tips-on-transitioning-to-product-management-from-qa-engineer-position-f514db5bb476">14 tips on transitioning to Product Management from QA Engineer position</a> was originally published in <a href="https://medium.com/autodesk-tlv">Autodesk TLV</a> on Medium, where people are continuing the conversation by highlighting and responding to this story.

If you’re a QA Engineer and you’re currently considering your career growth opportunities, Product Management can be a great potential growth path. This might be a win-win situation — you’ll continue dealing with the quality of the product, the user experience as well as the mission of making the life of your customers better. This change also comes with making bigger decisions, having closer communication with customers and customer-facing colleagues.
That being said, we all know that career shifts are never easy. They require a lot of hard work, motivation and persistence. Also, they usually take time and they are full of uncertainties and open questions. In this article, I’d like to share with you 14 practical tips I collected during my journey, starting from the point I realized that I want to become a Product Manager and ending up with me stepping into a Product Management role at Autodesk five months ago. In addition, I’ve cherry picked 13 recommendations for courses, books and articles.
I started my journey at Autodesk 5 years ago as a manual & automation QA engineer. At that time I was in my last year of the Hebrew University of Jerusalem, pursuing my BSc in Computer Science & Business Management. I quickly realized that I’m passionate about getting to know customers, their pain points and day-to-day workflows. I was curious about the wide vision that Product Managers have, so I set myself a goal to transition to Product Management.
I have a goal, cool! Now what?
Tip #1: Share your career goals with your manager. Also, continuously reflect to your manager your progress and your achievements.
Tip #2: Create a formal development plan with clear milestones & dates. Make sure to share it with your Manager.
Once I set a goal for myself, I decided to share it with my manager, Hagai Galai. He was supportive and he agreed that Product Management role is a good fit for me. My homework was to understand this role better and list the responsibilities of a Product Manager. In addition, I needed to list the skills of a Product Manager. After massive reading online, I realized that the definition of Product Manager role varies across different companies. Nonetheless, I summarized my conclusions and I came up with the following:

Now I have a goal and I know what skillset is required. Also, I (think that) I understand better the Product Manager role and I still think that it can be a good fit for me.
It seems that everything is ready and we’re good to go. Wait, go where…? I’m at point A and I really (really) want to get to point B. Point B seems very far but I still want to get there. So… What do I do? Should I focus on theoretical learning or practical learning? The answer is both, preferably in parallel.
Learning the theoretics gives a good basis.
Tip #3: Read Product Management related articles & books.
Reading books / articles won’t make you a Product Manager. However, it gives you the ability to learn from the experience of other people (and from their mistakes). It also gives you a variety of point of views as well as basic knowledge.
Article recommendations:

“How to become a Product Manager?” Written by Scott Judson

2.“So you want to be a Product Manager? Here is how I started” by Melanie Lei
3. “Naomi-isms” by Naomi Gleit (Meta head of Product)
4. “25 must-read product management articles” by Latif
Book recommendations:

The Lean Product Playbook by Dan Olsen
(4.7 stars in Amazon — 795 reviews).
Product Leadership by Martin Eriksson, Nate Walkingshaw and Richard Banfield
(4.3 stars in Amazon — 257 ratings).
Hooked by Nir Eyal
(4.6 stars in Amazon — 4784 ratings).
Inspired by Marty Cagan
(4.6 stars in Amazon — 3206 ratings).
The Design of Everyday Things by Don Norman
(4.6 stars in Amazon — 4713 ratings).
The MOM test by Rob Fitzpatrick
(4.7 stars in Amazon — 1306 ratings).

Tip #4: Don’t invest too much time reading articles & books. Go get your hands dirty!
The problem with theoretical learning is that, well, it’s theoretical. Not surprisingly, things in the real world slightly differ from the way they’re described in theory. Therefore, it’s important to not overload yourself with theoretical information.
Constantly seek opportunities to get hands-on experience.
Tip #5: Get a mentor in the company who can teach you and give you Product Management tasks, providing constant feedback on your work.
Tip #6: Be proactive.
Product Management is a wide profession. There are A LOT of things to learn and get experience in. Since I wasn’t sure where to start, I went with the obvious cliché and I found myself a mentor in the company.
When you want to transition to any role, you might benefit from working closely with the person who fulfills this role in your team. If you’re lucky, you’ll find amazing people who are willing to mentor you. These people believe in you and they’ll probably become your advocates in the company. After all, they know you best.
I was mentored by two Product Managers (Dror Ogen and Roei Oved) for around three years. The mentorship with the first Product Manager (Dror) was a tricky one. Being a single manual & automation QA engineer for two products, I struggled with finding the correct balance between Product Management tasks and my day to day work. Later on, I became QA owner of a single product and Roei became the Product Manager in my team. This was an opportunity to create a healthier balance and to get “official” time for Product Management tasks.
While working with Roei I got experience in the following areas:

Performing competitive analysis.
Formulating customer needs / pain points and translating them to problems (and later on — solutions).
Brainstorming for possible solutions for customers’ problems.
Leading the development of several features, from brainstorming solutions, writing detailed requirements, accompanying dev team during development, testing the feature (I’m the QA, remember?😉) and gathering Analytics in Production.

Tip #7: If you’re doing Product Management tasks in addition to fulfilling a different role, don’t be shy to say NO when it becomes too stressful or doesn’t advance your goals.
Roei and I agreed that if there is something I’m interested to work on, I can say it. The second agreement we had is that if I feel too stressed with my tasks, I can say “I don’t have time for X, Y and Z. Can you please take these tasks?”. The constant feedback from my mentor(s) helped me in enriching my Product Management skill sets and improving myself. I’m very grateful for this.
Balance is everything in life.
It took time to find the correct balance for me. I had weeks where 20% of my time was invested in Product related tasks and I had weeks where 60% percent of my time was invested in it. I also had weeks with 0% time for product related tasks. Having clear priorities helped me a lot. Also, I took product related tasks with enough buffer, meaning I could work on them in parallel with my regular day to day tasks. In addition, I learned to use my time in a more effective way and temporary cancelled my nap time in the weekends. Also, I didn’t have more than one “hands on” task in parallel with my other duties. I knew that by keeping my original responsibilities, no one has a reason to push me back.
Make no mistake — it was challenging to make this work. However, it’s not impossible. It requires a successful combination of my will, my hard work, the support of the people around me and a company that supports my career development goals.
Leveraging your current position for your career development is effective.
It’s not surprising that people shift to Product Management from various roles and professions, such as Customer Support, Customer Success, Development, QA, etc. The challenge is to find the benefits in your current role and leverage them for your long term plans by taking active actions. What are the benefits of QA Engineers?
Similar to Product Managers, QA Engineers have a deep understanding of the product. They have wide vision and they’re very familiar with all the flows, including the smallest details. In most cases, they know the product as well as the Product Manager.
Tip #8: Use your deep technical knowledge and try to “transform” it into a more business and customer oriented thinking.
When testing a feature, make sure that you understand the value for the customer and that you know how it serves the business. When working with a product requirements document, I always asked myself how would a customer feel when using the new feature? Will the flow be clear to them? Will they notice the new feature? Is there a way we can improve it?
Tip #9: Try to get as close as you can to customers.
Knowing your customers, their day to day workflows, and their pain points is the responsibility of every Product Manager. In order to obtain this knowledge, you need to learn their world. Since we develop software for construction companies, I decided to read a book related to construction.
Also, I joined as many zoom meetings with the customers as I could. Watching how customers use our product is priceless. It changed the way I test things and it often affected the prioritization of bugs in our backlog. Customers like to talk (a lot) about their day to day, their experience and things they’re struggling with. This way you get “real” information about their life, as opposed to “theoretical” information you get when reading a book. I also took these meetings as a good opportunity to practice my note taking skills, to learn how other Product Managers interact with customers and how they ask questions.
Another good way to understand the customers is to visit them and meet them in person. I was lucky to join a few team members and visit our customers in New York. We met with customers in construction sites and in their office. I learned A LOT in a few days. I had the opportunity to watch “live” how customers use our product and to understand better their day to day as well as their struggles.
Tip #10: Integrate Product Management practices into your day to day QA work
I saw many times how Roei used data in order to make decisions. He often asked the developers to query Production or he extracted data by himself using (frontend) Analytics. I thought that I can base my decisions / requests on data as well. For example, if I want a certain bug to be fixed, I can look for the relevant analytics to “prove” that it’s an important bug to fix.
Surrounding yourself with people who have a similar goal is strongly recommended.
Tip #11: Talk to as many Product Managers as you can.
When you’re going abroad, (most of the time) you read ahead about the destination and you consult with your acquaintances who have already visited this destination. You’ll probably also join related facebooks groups in order to find recommendations and tips.
Same here. I joined several facebook groups of people who want to become Product Managers. Also, I talked to as many Product Managers as I could, both inside and outside of Autodesk. In addition, there is a large variety of meetups to attend and other related events.
Tip #12: Join facebook groups related to Product Management.
Facebook group recommendations:

Becoming Product Managers.
Product Queens.
Product Tank TLV.

Tip #13: Take Product Management related courses.
Similarly to reading books and articles, Product Management courses won’t make you a Product Manager. However, there are many available courses that can enrich your knowledge and provide you with valuable additions to your skills set.
Course recommendations:

101 Product Management (I took this course).
Product Experts
Product Management courses in LinkedIn Learning.

Tip #14: Networking is priceless!
Around nine months ago I completed a 12 weeks Product Management course called 101 Product Management. It gave me various practical tools in a variety of product related areas. In addition, I had the opportunity to expand my network of connections. I strongly recommend this course.

A pause.
Almost two years ago I gave birth to my son and I was on maternity leave for one year. During that time I practiced my Product Management skills from another angle. I had to learn how to manage in stressful situations, how to address unexpected changes and how to handle a “customer” with frequently changing requirements.
Timing & Opportunity is the best combination.
One month after I returned from maternity leave, an opportunity came up. I applied for a PM position in Autodesk. I went through several interviews with multiple people, technical product interview and I worked on a home assignment that I later presented to 8 people (PMs, UX leads and Engineering Managers). The benefit with these internal transitions is that the home assignment was related to the product and a world I’m (very) familiar with.
Well, mission accomplished! I got from point A to point B! I got my first position as a Product Manager. Moreover, I transitioned from QA to PM position in the same team! This was a huge benefit for me. When you transition to a new position in a new company, you need to learn both a new world & a new role. When you make the transition inside the same team, you can be more focused on learning Product Management. Thank you, Tomer Rosenthal, for believing in me and giving me this opportunity. Also, I appreciate the help with onboarding to this new role and the fact that you are not surprised anymore when I ask you “Hi, I have a question. Are you available for a zoom?”.
Five months have passed since I officially became a Product Manager. I must admit that everything looked a bit scary and overwhelming in the beginning. However, it got better pretty quickly. I’ve learned a lot so far and I have so much more to learn.
Remember how I wanted to get from point A to point B? Now I need to define point C and get there. I’m very excited to begin a new journey with new goals and new challenges!
To summarize, there is no precise recipe for creating big career shifts. Everybody has their own path and their own pace. I think that it’s important to stay focused on your goal, to define clear milestones, to get a mentor, to be patient and understand that this is a process, it takes time and it requires a combination of opportunity & timing.

14 tips on transitioning to Product Management from QA Engineer position was originally published in Autodesk TLV on Medium, where people are continuing the conversation by highlighting and responding to this story.

14 tips on transitioning to Product Management from QA Engineer position

<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*ge_We9o3DN8KvVsYT3KkFA.jpeg" /></figure>We’ve all been there, from emails to spam “@here” in Slack. When we have a change in our tools that needs to be updated by another team, this process can become a frustrating task.This example and many more are day-to-day issues that big companies face.If you have created tools or integrations that other teams use, you probably had to make an update or a change, and sometimes these changes cannot wait. The usual play is to send an email requesting teams update their dependencies to a wide distribution list.At best, it goes to their backlog, and at worst, it’s ignored. At Autodesk, we understood this process needs to be automated if we want to make sure these updates happen as fast as possible.Our story started with a simple package named “ProjectPageLayout”. All Autodesk ACS teams (20+) used this package, and once we wanted to make a change, we had to request every team update it to get a consistent experience in our application.When we retroed this process, an idea came up, why can’t we just test their “project” and make sure they use the latest version? And if it’s not the latest version, we can enforce it.This is how the idea for “ProjectLinter” came to life.Our inspiration is ESLint. ESLint statically analyzes your code and gives you diagnostics. We statically analyze your whole project. It can fit all project types, and you can run it as part of your continuous integration pipeline and send notifications asynchronously.Sometimes it can also automatically fix your problems.Every team can create a rule (like in ESLint) to enforce it in other projects. To make it simple for the project owners, they do not have to be familiar with the rules and specificities because when creating a rule, it is deployed and automatically executed alongside the other rules seamlessly.In other words, it is seamless to the users of the linter and simple to create a rule for the enforcing team.But wait, why should we limit ourselves to updating the teams’ dependencies and business logic rules if we can also ensure their projects possess the best standards and quality in the industry?We also create rules that ensure performance, minimal bundle sizes, scan security vulnerabilities, high testing coverage, and minimal package duplication.Another massive win from this process is that it can give us a way to measure infrastructure tools success. We can define KPIs according to rules, for example, “Performance” (Web vitals).We can see changes over time for this rule and therefore understand whether there is a wide problem across teams that requires infrastructural assistance and whether this assistance is successful.A problem was raised that sometimes teams maintain code bases that do not change frequently, and if we wait for a code change to trigger the linter, it could be too late.The solution is not just to run the linter when the codebase is changed but also over time, for example, daily and asynchronously.Another issue is that with all due respect to the importance of the rules, you can not break the team’s process out of nowhere.Therefore we created a gradual diagnostics system.You can configure it so that ProjectLinter would simply warn teams and send notifications, but after a specified amount of time, e.g. two months of no response, it would take more extreme measures.Let me close by saying: I genuinely believe this is another step toward a simpler future with more automation. The best part of this whole thing is that my team and I had the opportunity to work on this project as part of a week-long hack week at Autodesk TLV. Focusing on an idea that we love and are passionate about.<img src="https://medium.com/_/stat?event=post.clientViewed&referrerSource=full_rss&postId=3d425ec74a73" width="1" height="1" alt=""><hr><a href="https://medium.com/autodesk-tlv/the-problem-with-maintaining-code-quality-in-a-large-technology-company-and-the-solution-3d425ec74a73">The problem with maintaining code quality in a large technology company; and the solution.</a> was originally published in <a href="https://medium.com/autodesk-tlv">Autodesk TLV</a> on Medium, where people are continuing the conversation by highlighting and responding to this story.

We’ve all been there, from emails to spam “@here” in Slack. When we have a change in our tools that needs to be updated by another team, this process can become a frustrating task.
This example and many more are day-to-day issues that big companies face.
If you have created tools or integrations that other teams use, you probably had to make an update or a change, and sometimes these changes cannot wait. The usual play is to send an email requesting teams update their dependencies to a wide distribution list.
At best, it goes to their backlog, and at worst, it’s ignored. At Autodesk, we understood this process needs to be automated if we want to make sure these updates happen as fast as possible.
Our story started with a simple package named “ProjectPageLayout”. All Autodesk ACS teams (20+) used this package, and once we wanted to make a change, we had to request every team update it to get a consistent experience in our application.
When we retroed this process, an idea came up, why can’t we just test their “project” and make sure they use the latest version? And if it’s not the latest version, we can enforce it.
This is how the idea for “ProjectLinter” came to life.
Our inspiration is ESLint. ESLint statically analyzes your code and gives you diagnostics. We statically analyze your whole project. It can fit all project types, and you can run it as part of your continuous integration pipeline and send notifications asynchronously.
Sometimes it can also automatically fix your problems.
Every team can create a rule (like in ESLint) to enforce it in other projects. To make it simple for the project owners, they do not have to be familiar with the rules and specificities because when creating a rule, it is deployed and automatically executed alongside the other rules seamlessly.
In other words, it is seamless to the users of the linter and simple to create a rule for the enforcing team.
But wait, why should we limit ourselves to updating the teams’ dependencies and business logic rules if we can also ensure their projects possess the best standards and quality in the industry?
We also create rules that ensure performance, minimal bundle sizes, scan security vulnerabilities, high testing coverage, and minimal package duplication.
Another massive win from this process is that it can give us a way to measure infrastructure tools success. We can define KPIs according to rules, for example, “Performance” (Web vitals).
We can see changes over time for this rule and therefore understand whether there is a wide problem across teams that requires infrastructural assistance and whether this assistance is successful.
A problem was raised that sometimes teams maintain code bases that do not change frequently, and if we wait for a code change to trigger the linter, it could be too late.
The solution is not just to run the linter when the codebase is changed but also over time, for example, daily and asynchronously.
Another issue is that with all due respect to the importance of the rules, you can not break the team’s process out of nowhere.
Therefore we created a gradual diagnostics system.
You can configure it so that ProjectLinter would simply warn teams and send notifications, but after a specified amount of time, e.g. two months of no response, it would take more extreme measures.
Let me close by saying: I genuinely believe this is another step toward a simpler future with more automation. The best part of this whole thing is that my team and I had the opportunity to work on this project as part of a week-long hack week at Autodesk TLV. Focusing on an idea that we love and are passionate about.

The problem with maintaining code quality in a large technology company; and the solution. was originally published in Autodesk TLV on Medium, where people are continuing the conversation by highlighting and responding to this story.

The problem with maintaining code quality in a large technology company; and the solution.

Assuming a manager position for the first time can be daunting, and your day-to-day can get shrouded in uncertainty. I have learned the hard way some of the following advice, which would have definitely made my life easier had someone explicitly went over it with me. There are certainly more, but I chose to focus on these seven tips.Note: These tips are written from the experience and vantage point of an Engineering Manager, but perhaps could prove useful for other managers in other types of industries.<h3>1. You are no longer an engineer.</h3>Well, maybe you are, but this is no longer your focus. Your new focus is your employees, who will execute the main engineering work. They matter more than you, and they should be your first priority. This point is often missed.When I first started as a manager, I thought my job mainly consisted of assigning Jira tickets and overseeing the work, while still continuing to hack away at code. That’s not very fruitful, though. There’s a reason this position is called “People Manager”. Your thoughts should always revolve around your team members, ensuring they have whatever they require to perform their work, that they’re happy, and that they know you have their back. (and much much more).My management positions were 0% hands-on. Not all companies would approve of this, and some require a small-to-medium capacity of hands-on work from the manager. I have no experience in such companies, but in any case, I would argue that such hands-on work should always come second on the agenda, after you’re sure your team is covered, functional, and high performing.<h3>2. Get to know your team members.</h3>Being a manager requires that you get to know your team members on a personal level. Much more so, probably, if you were their colleague. I’d say that being a manager is spending about 50% of your time listening. Yes, that might feel like being a shrink. That’s the job! When people feel that you care about them, they’ll feel more connected to you, to the job, and are much more likely to stay motivated and engaged in the work. They will want to listen to you because they appreciate you, not just because they have to. “People Manager”, have I mentioned that already?Remember - people often leave managers, not companies.<h3>3. You can’t, and shouldn’t, do everything.</h3>You need to delegate. Whether it is to an IC (Individual Contributor), or to another people manager, you can’t own everything. That’s not productive, and definitely not scalable.“But what if they get it wrong? I have owned this domain for over three years now!” Yeah, they can and probably will, get that wrong. But how will they learn otherwise? There’s wisdom in identifying a great mistake (little harm, lots of learning) from a catastrophic mistake (well, you probably know these).You will also find that people feel empowered when they know you believe in them. Your team members need to know you trust them. For the more dedicated to this effort among you, <a href="https://www.amazon.com/Extreme-Ownership-U-S-Navy-SEALs/dp/1250067057">Extreme Ownership: How U.S. Navy SEALs Lead and Win</a> 📒 is a great book. The name of the book might be misleading, but rest assured it’s anything but “you should own everything yourself”.<h3>4. Provide feedback.</h3>It’s just a matter of time until one of your employees does something wrong. It might be something technical, and it might be something between team members. It’s your job to provide feedback to that employee. The feedback should be direct, unambiguous, and accompanied by examples. Depending on the nature of the event, you might not even want to wait for your weekly 1–1s (which I hope you have scheduled). If it’s urgent, catch them for a quick chat.Some feedback might feel very difficult to provide. That’s fine, it probably means you’re doing your job right. It’s OK to rehearse a bit before and make sure you know exactly what message you want to convey.If you don’t tell your employees of their mistakes, they won’t learn and they’ll believe such mistakes are acceptable. This can lead to having other employees, both old and new, “learning these mistakes” and continuing the tradition. Nip it in the bud!Beyond that, let’s not forget that positive feedback is also very important. Your employees need to hear they’re doing well, that you see what they’re doing and are satisfied, and it will drive them to keep going. Try to have at least one good thing to say in your weekly 1–1 as an anchor.A great book on that is the famous <a href="https://www.radicalcandor.com/">Radical Candor</a> 📒.<h3>5. Ask questions, don’t give out answers.</h3>A major part of your role is to grow your team members. Remember the famous proverb “Give a man a fish and you feed him for a day. Teach a man to fish and you feed him for a lifetime”? This applies to you as well.It can be very tempting when employees ask you questions to simply give them the answer and let them continue with their work. Time is ever pressing and we need to make it to the release on time, right? Wrong. Don’t neglect the long-term benefits in favor of the short-term ones. The next time a team member comes to you with a question, instead of giving the answer right away, consider asking them back: “What do you think are the pros and cons of such an approach?”, “What are the risks with this solution and how can they be mitigated?”, “Have you tried talking to David about this problem and working it out together?”, etc. Remember, you want to cultivate independence within your team.<h3>6. Focus on building a great team and culture.</h3>A good manager ensures her team achieves good results. A great manager ensures her team remains highly functional in her absence.A good team is more than a sum of individual employees’ capabilities. To achieve good synergy, you need to have a composition of team members that like each other, and that would want to help each other and collaborate. It’s also a good idea to have some combination of seniors and juniors on the team, to allow for mentoring opportunities. Don’t always aim for the strongest and most experienced engineer for every position.You might also want to think about what values you care about. For example, if Quality is topmost in your priorities and you can de-prioritize velocity, you would probably go for the more thorough, balanced type of engineers that would output a better result at a slower pace. On the other hand, if your team is measured by getting those features in for repeating tight deadlines, you might want to aim for better MVPing, pace and creative-thinking. It all depends on the team.Others have masterfully depicted it in books like <a href="https://www.amazon.com/Five-Dysfunctions-Team-Leadership-Fable/dp/0787960756">The Five Dysfunctions of a Team: A Leadership Fable</a> 📒. Do yourself a favor a read that. The Audible version is terrific, and also pretty short.Another great book is <a href="https://www.amazon.com/Peopleware-Productive-Projects-Tom-DeMarco/dp/0932633439">Peopleware: Productive Projects and Teams</a> 📒.<h3>7. It can get lonely, but it doesn’t have to be.</h3>Managers don’t have team members (in the classical sense). They provide feedback to their team members, often hard feedback, and they usually don’t have anyone to confide in with the difficulties of the position themselves. You might choose to confide in your manager, you might choose your spouse, or even your friends. But remember there are other managers in your company. It might be a good idea to form a manager forum and discuss your challenges and brainstorm creative ideas together. If done right, it can feel like a team.<h4>In Summary</h4>This is a new job definition, not (only) a promotion.A paradigm shift is required — your employees are first, you’re last. Get to know them, but for real — don’t pretend.Ask insightful questions. Delegate, mentor, and grow your employees.Provide feedback. Both good and bad, your team members need both. Teach them to provide it to each other.Ensure the road ahead is clear. Remove critical barriers and obstacles (e.g. insufficient staffing, missing PRDs/designs, handshake with collaborating teams, etc). If you don’t do it, your team will get stuck instead of working.You are not alone.<img src="https://medium.com/_/stat?event=post.clientViewed&referrerSource=full_rss&postId=df7326d22ff8" width="1" height="1" alt=""><hr><a href="https://medium.com/autodesk-tlv/7-tips-for-a-first-time-engineering-manager-df7326d22ff8">7 Tips for a First Time Engineering Manager</a> was originally published in <a href="https://medium.com/autodesk-tlv">Autodesk TLV</a> on Medium, where people are continuing the conversation by highlighting and responding to this story.

Assuming a manager position for the first time can be daunting, and your day-to-day can get shrouded in uncertainty. I have learned the hard way some of the following advice, which would have definitely made my life easier had someone explicitly went over it with me. There are certainly more, but I chose to focus on these seven tips.
Note: These tips are written from the experience and vantage point of an Engineering Manager, but perhaps could prove useful for other managers in other types of industries.
1. You are no longer an engineer.
Well, maybe you are, but this is no longer your focus. Your new focus is your employees, who will execute the main engineering work. They matter more than you, and they should be your first priority. This point is often missed.
When I first started as a manager, I thought my job mainly consisted of assigning Jira tickets and overseeing the work, while still continuing to hack away at code. That’s not very fruitful, though. There’s a reason this position is called “People Manager”. Your thoughts should always revolve around your team members, ensuring they have whatever they require to perform their work, that they’re happy, and that they know you have their back. (and much much more).
My management positions were 0% hands-on. Not all companies would approve of this, and some require a small-to-medium capacity of hands-on work from the manager. I have no experience in such companies, but in any case, I would argue that such hands-on work should always come second on the agenda, after you’re sure your team is covered, functional, and high performing.
2. Get to know your team members.
Being a manager requires that you get to know your team members on a personal level. Much more so, probably, if you were their colleague. I’d say that being a manager is spending about 50% of your time listening. Yes, that might feel like being a shrink. That’s the job! When people feel that you care about them, they’ll feel more connected to you, to the job, and are much more likely to stay motivated and engaged in the work. They will want to listen to you because they appreciate you, not just because they have to. “People Manager”, have I mentioned that already?
Remember - people often leave managers, not companies.
3. You can’t, and shouldn’t, do everything.
You need to delegate. Whether it is to an IC (Individual Contributor), or to another people manager, you can’t own everything. That’s not productive, and definitely not scalable.
“But what if they get it wrong? I have owned this domain for over three years now!” Yeah, they can and probably will, get that wrong. But how will they learn otherwise? There’s wisdom in identifying a great mistake (little harm, lots of learning) from a catastrophic mistake (well, you probably know these).
You will also find that people feel empowered when they know you believe in them. Your team members need to know you trust them. For the more dedicated to this effort among you, Extreme Ownership: How U.S. Navy SEALs Lead and Win 📒 is a great book. The name of the book might be misleading, but rest assured it’s anything but “you should own everything yourself”.
4. Provide feedback.
It’s just a matter of time until one of your employees does something wrong. It might be something technical, and it might be something between team members. It’s your job to provide feedback to that employee. The feedback should be direct, unambiguous, and accompanied by examples. Depending on the nature of the event, you might not even want to wait for your weekly 1–1s (which I hope you have scheduled). If it’s urgent, catch them for a quick chat.
Some feedback might feel very difficult to provide. That’s fine, it probably means you’re doing your job right. It’s OK to rehearse a bit before and make sure you know exactly what message you want to convey.
If you don’t tell your employees of their mistakes, they won’t learn and they’ll believe such mistakes are acceptable. This can lead to having other employees, both old and new, “learning these mistakes” and continuing the tradition. Nip it in the bud!
Beyond that, let’s not forget that positive feedback is also very important. Your employees need to hear they’re doing well, that you see what they’re doing and are satisfied, and it will drive them to keep going. Try to have at least one good thing to say in your weekly 1–1 as an anchor.
A great book on that is the famous Radical Candor 📒.
5. Ask questions, don’t give out answers.
A major part of your role is to grow your team members. Remember the famous proverb “Give a man a fish and you feed him for a day. Teach a man to fish and you feed him for a lifetime”? This applies to you as well.
It can be very tempting when employees ask you questions to simply give them the answer and let them continue with their work. Time is ever pressing and we need to make it to the release on time, right? Wrong. Don’t neglect the long-term benefits in favor of the short-term ones. The next time a team member comes to you with a question, instead of giving the answer right away, consider asking them back: “What do you think are the pros and cons of such an approach?”, “What are the risks with this solution and how can they be mitigated?”, “Have you tried talking to David about this problem and working it out together?”, etc. Remember, you want to cultivate independence within your team.
6. Focus on building a great team and culture.
A good manager ensures her team achieves good results. A great manager ensures her team remains highly functional in her absence.
A good team is more than a sum of individual employees’ capabilities. To achieve good synergy, you need to have a composition of team members that like each other, and that would want to help each other and collaborate. It’s also a good idea to have some combination of seniors and juniors on the team, to allow for mentoring opportunities. Don’t always aim for the strongest and most experienced engineer for every position.
You might also want to think about what values you care about. For example, if Quality is topmost in your priorities and you can de-prioritize velocity, you would probably go for the more thorough, balanced type of engineers that would output a better result at a slower pace. On the other hand, if your team is measured by getting those features in for repeating tight deadlines, you might want to aim for better MVPing, pace and creative-thinking. It all depends on the team.
Others have masterfully depicted it in books like The Five Dysfunctions of a Team: A Leadership Fable 📒. Do yourself a favor a read that. The Audible version is terrific, and also pretty short.
Another great book is Peopleware: Productive Projects and Teams 📒.
7. It can get lonely, but it doesn’t have to be.
Managers don’t have team members (in the classical sense). They provide feedback to their team members, often hard feedback, and they usually don’t have anyone to confide in with the difficulties of the position themselves. You might choose to confide in your manager, you might choose your spouse, or even your friends. But remember there are other managers in your company. It might be a good idea to form a manager forum and discuss your challenges and brainstorm creative ideas together. If done right, it can feel like a team.
In Summary
This is a new job definition, not (only) a promotion.
A paradigm shift is required — your employees are first, you’re last. Get to know them, but for real — don’t pretend.
Ask insightful questions. Delegate, mentor, and grow your employees.
Provide feedback. Both good and bad, your team members need both. Teach them to provide it to each other.
Ensure the road ahead is clear. Remove critical barriers and obstacles (e.g. insufficient staffing, missing PRDs/designs, handshake with collaborating teams, etc). If you don’t do it, your team will get stuck instead of working.
You are not alone.

7 Tips for a First Time Engineering Manager was originally published in Autodesk TLV on Medium, where people are continuing the conversation by highlighting and responding to this story.

7 Tips for a First Time Engineering Manager

Which Monorepo is right for a Node.js BACKEND now?

Introduction
Streams are one of the fundamental concepts in programming in general, and in Node.js in particular. It is likely that you are using it without knowing that you are using it (but you’ll discover it after you’ll finish reading that post).
If you would like to read about the way we are using it in our service, you are invited to read my blog post: https://medium.com/@sitvanitm/how-can-you-increase-i-o-performance-with-streams-cc85704db108
Streams are objects that let you move data from a source to its destination, without waiting for the entire data to be ready for its journey, because it will be sent asynchronously by chunks.
Hence, using streams will improve your time and space efficiency significantly, because if you are using chunks, you don’t have to wait until the whole file will be read before you write it.
The chunks wait before they are consumed in the waiting area, that called buffer, and placed in the RAM.
Every stream has its own internal buffer. The amount of the data in each buffer depends in its size (which we can define in its constructor or use the default).
Stream Object Illustration
In Node.js we have ‘stream’ core module, and according to its documentation:
“A stream is an abstract interface for working with streaming data in Node.js. The stream module provides a base API that makes it easy to build objects that implement the stream interface… Streams can be readable, writable, or both… All streams are instances of EventEmitter.”
Abstract Interface
In order to use that API we should implement that interface for ours needs.
Node.js provides us many stream objects that have already implemented that interface, for common uses.
Usually developers do not use the ‘stream’ module directly, because there is no reason to implement a stream object that is already implemented. So, it’s likely that you’ll consume the ‘module’ indirectly (e.g. ‘fs’ implements the stream interface in createReadStream function).
You will use the stream module directly just if you have to implement a custom stream, for your own specific needs.
Stream Types — Readable, Writable, or Both
There are a few types of streams, readable, writable, or both.
Readable streams are an abstraction for a source from which data is consumed.
Writable streams are an abstraction for a destination to which data is written.
And there are also streams that can be both, that kind of stream is called duplex stream. Duplex streams are streams that implement both the Readable and Writable interfaces.
EventEmitter
Stream object can emit events and listen to events, and that is their way to communicate with each other. We’ll discover some of the important events later, in order to understand how streams work.
Before we’ll implement some custom streams by ourselves, let’s see how we can use the already existing stream objects.
I recommend to run the following code snippets. you can write it from scratch, or use my Github repository: https://github.com/sitvanit/snippets/tree/master/streams
Read and Write File
As we saw before, we can use the ‘fs’ module in order to read and write file with stream objects.
const readStream = fs.createReadStream(‘file’, { highWaterMark: 1024 });
const writeStream = fs.createWriteStream(‘file-copy’);
 
readStream.on(‘data’, chunk => {
writeStream.write(`\n\nnew chunk has been received: \n\n${chunk}`);
});
fs.createReadStream constructs a readable stream object, its first argument is the path of the file that we’d like to read, and its second argument is the options object that the constructor uses in order to create the stream object.
In that example, I decided to define highWaterMark option. We are going to understand what is the highWaterMark later. For now let’s say that it determines the size of the chunk in KB (It’s not necessarily that the highWaterMark is the size of chunk, it depends on the implementation of the stream object, but it is like that in ‘fs’). The default of the highWaterMark in ‘fs’ is 64KB.
In the next line I construct the writableStream with the path of the destination which I like to write to.
As we saw in the previous example we can connect the streams with pipe. But I decided to listen to the ‘data’ event (that event emits each time the stream is abandoned ownership of a chunk of data), in order to write the file with the title “new chunk has been received” to prove that the file has been consumed in chunks.
If you’ll run that script in your project, you’ll find that ‘file-copy’ has been created, and if you’ll open it, you’ll find our custom title before each 1024 chars (our chunk).
So now we can actually believe, we saw it with our eyes — streams read and write data in chunks — how amazing is that!
Receive Request and Send Response
Now, I’m going to shake your world. Did you know that request and response, those objects that you use on daily basis, are stream objects as well?
request is a readable stream and response is a writable stream.
const server = http.createServer((req, res) => {
    const rs = fs.createReadStream('file', { highWaterMark: 1024 });
    rs.on('data', chunk => {
        res.write(`\n\nnew chunk has been received: \n\n${chunk}`);
    });
});
const port = 3000
server.listen(port, 'localhost');
console.log(`server is listening on port ${port}`);
In that snippet I created a http server, inside of it I created a readable stream and the server listens to the ‘data’ event, as in the previous snippet. But this time, instead of writing the data to a file, we are going to send it by chunks on the response.
If you’ll run that server on your computer, and try to browse to ‘localhost:3000’ — you’ll find out that the response was sent in chunks.
I think now we are ready to go to the pool of the big ones. Let’s try to implement some custom streams on our own.
Custom Readable Stream
const { Readable } = require('stream');
class MyReadable extends Readable {
    constructor(data, options) {
        super(options);
        this.data = data;
    }
    
    _read(size) {
        if (this.data.length) {
            const chunk = this.data.slice(0, size);
            this.data = this.data.slice(size, this.data.length);               
            this.push(chunk);        
        } else {
            this.push(null); // 'end'
        }
    }
}
module.exports = MyReadable;
As I mentioned before, the Readable class is an interface that we must implement in order to use it.
And when we implement it, we have to implement the _read method. _read is a private method, that only the Readable class can use. We have to implement it, but we cannot use it. This method may get ‘size’ parameter, the size is determined by the highWaterMark that we sent in the stream constructor, or by the default (in stream module the default is 16 KB).
We can implement the _read, as the chunk will be in the ‘size’ that has been sent to the function (as I did above). But if we’ll ignore it, the data will be pushed to the buffer the moment it will arrive, and not wait for accumulating data in the size of the chunk and then send it.
After I created the chunk of data, I have to push that chunk to the stream. The push will fill the buffer with the data and will trigger the readable stream to emit a ‘readable’ event, in order to let its listeners know that there is data that they can read.
When we finish reading all of the data we need to push ‘null’ to the buffer, and then an ‘end’ event will be emitted, and the listeners will get it, and stop listening.
Now, we would like to consume that custom readable stream that we just implemented.
const data = [{ a: 1 }, { b: 2 }, { c: 3 }, { d: 4 }, { e: 5 }];
const readable = new MyReadable(data, { objectMode: true, highWaterMark: 2 });
console.log(readable.readableFlowing); // null
readable.on('data', chunk => {
    console.log(chunk);
});
console.log(readable.readableFlowing); // true
readable.on('readable', () => {
    readable.read(); 
});
console.log(readable.readableFlowing); // false
readable.on('end', () => console.log('No more data!'));
first, you should know, that stream can consume only data that is string, buffer or objects. in that example I chose objects. If we choose objects, we have to set objectMode to true. You can see that I limit the highWaterMark to 2. If you followed me, I mentioned before that the units of the highWaterMark property is KB — but not here, if we set the objectMode to true, then the units of the highWaterMark will be the number of the objects.
Readable stream has three states and two modes.
We can get the current state by calling the readableFlowing property of the stream.
All Readable streams begin in paused mode. At the beginning, in the init state, the readableFlowing will always be null, because no mechanism for consuming the stream’s data is provided. Then after it started to be consumed, the state will change to flowing mode or stay in paused mode .
In flowing mode, data is read from the underlying system automatically and provided to an application as quickly as possible using events via the EventEmitter interface.
The mode will be changed to flowing mode if one of the following will occur:
1. Attaching a listener for the ‘data’ event
2. Calling the readable.pipe() method
3. Calling the readable.resume()
In paused mode, the stream.read() method must be called explicitly to read chunks of data from the stream.
The mode will be changed to paused mode if one of those will occur:
1. Calling readable.pause()
2. Calling readable.unpipe()
3. Receiving backpressure (we are going to delve deeper into this later)
It’s important to remember that Readable will not generate data until a mechanism for consuming or ignoring the data is provided.
If a Readable is switched into flowing mode and it’s not consumed by anyone, the data will be lost.
Adding a ‘readable’ event handler automatically makes the stream stop flowing, and the data can be consumed with readable.read() function. And if the ‘readable’ event handler will be removed, the stream will change to flowing mode again if there will be a ‘data’ event handler.
Calling readable.read() flushes the buffer and emits ‘data’ event.
In the snippet above I chose listening both ‘readable’ event and ‘data’ event’, just in order to demonstrate the change of the flowingMode.
If you’ll consume a readable stream (and not with pipe), you should choose whether you want to consume the data in flowing mode and listen to ‘data’ event, or in paused mode, and listen to ‘readable’ event.
At the end, don’t forget to listen to ‘end’ event (that emits by readable.push(null), remember?).
Custom Writable Stream
const { Writable } = require('stream');
class MyWritable extends Writable {
    constructor(options) {
        super(options);
    }
_write(chunk, encoding, callback) {
        const formattedChunk  = this._writableState.objectMode === true ? JSON.stringify(chunk) : chunk;
        console.log(`Writing to stream: ${formattedChunk}`);
        callback(); // flushes the buffer and emits 'drain' event
    }
}
module.exports = MyWritable;
Here again we should implement the specific stream, by extending Writable interface.
We must implement the _write method. _write gets three parameters:
1. Chunk — the chunk of data, the may be string, buffer or object (if we are in objectMode).
2. Encoding — If the data is string from a specific encoding
3. Callback — that will be called at the end of the method, will flush the buffer, and will emit ‘drain’ event.
_write is internal, and we cannot use it outside of the Writable class.
Now, If we’d like to consume that class:
const data = ['first element', 'second element', 'last element'];
const writable = new MyWritable({ highWaterMark: data[0].length });
const written = writable.write(data[0]);
writable.write(data[1]);
writable.end(data[2]);
console.log(written);
In that snippet the data is an array of strings, and when I created the instance of MyWritable, I set the highWaterMark to the length of the first string.
In our example the highWaterMark determines the size of the chunk and the buffer.
We consume the writable stream with writable.write(). That function returns a Boolean — true if there is a place for more data in the buffer, and false if not.
So now, what do you think, Is ‘written’ is going to be true or false? Because I set the size of the buffer to the length of the first word, ‘written’ is going to be false.
Does it mean that we are going to lose the rest of the data because the buffer is full?
Not really, you can try it and see that the data is still consuming even though the buffer is full.
What does it mean? It means that the buffer can exceed the limitations we set for it. And we have to implement a mechanism that will regulate the data flow. And if we won’t, we are taking a risk to block the RAM even though we used streams, and cause a backpressure.
Backpressure
A backpressure is a situation when the receiving end of the transfer has complex operations, or is slower for whatever reason, there is a tendency for data from the incoming source to accumulate.
In that case the pipe has to control the data flow.
Luckily, Node.js already implemented that pipe for us, and if we’ll use pipe function, we will receive that regulation mechanism out of the box, and we shouldn’t take care of it.
Pipe
Unless you have a really good reason, always use pipe in order to connect streams.
const data = [{ a: 1 }, { b: 2 }, { c: 3 }, { d: 4 }, { e: 5 }];
const readable = new MyReadable(data, { objectMode:true, highWaterMark: 2 });
const writable = new MyWritable({ objectMode:true });
readable.pipe(writable);
Now we are in the safe zone!
Duplex Stream
We have implemented readable and writable streams, but we mentioned at the beginning that there are streams that are both readable and writable — duplex stream.
We can simulate it to a phone, you can talk to your friend, and listen to him, and in the same time he can talk to you and listen to you.
This magic can happen, thanks to the fact that each duplex stream has two internal buffers, one for the readable and one for the writable, and that enables it to read and write data concurrently.
A simple example for a duplex stream is a socket server of ‘net’ module:
net.createServer(socket => {
    socket.pipe(socket)
}).listen(8001);
here I implemented a simple echo server. Socket is a duplex stream. You can see I piped socket to itself. The socket of the pipe is readable stream and the second one is the writable.
If we’ll run the server, and will try to send some data to it with netcat from another terminal (nc localhost 8001). We’ll see that the server will read our data and write it as is right after.
Transform Stream
Transform stream is a kind of a duplex stream. Those streams transformed the data they get before they transfer it to the next stream.
If you’d like to implement a custom transform stream, you should implement the transform interface and the _transform method (as we did before with _read and _write).
A trivial example for that is to zip a file:
const readableStream = fs.createReadStream('file');
const transformStream = zlib.createGzip();
const writableStream = fs.createWriteStream('file.gz');
readableStream.pipe(transformStream).pipe(writableStream);
Pipeline
If you pipe a few custom streams (not streams that are implemented by Node.js) to each other, and one of them has thrown an error and crashed the app, that stream will be closed automatically, but the other streams won’t be closed, and you should take care of it.
Node.js ‘stream’ core module, has a ‘pipeline’ function. ‘pipeline’ allows you to pipe as many streams that you like to each other, and to define an error handling in the last parameter.
const { pipeline } = require('stream');
const fs = require('fs');
const zlib = require('zlib');
pipeline(
    fs.createReadStream('file'),
    zlib.createGzip(),
    fs.createWriteStream('file.gz'),
    (err) => {
        if (err) {
            console.error('Pipeline failed.', err);
        } else {
            console.log('Pipeline succeeded.');
        }
    }
);
When Should You Use Streams?
I believe some of you have dealt I/O operations until now, without using streams, and everything was just fine. You might ask yourself why and when should I use it now?
I’ read an interesting article by Duncan Grant — https://medium.com/@dalaidunc/fs-readfile-vs-streams-to-read-text-files-in-node-js-5dd0710c80ea
Grant did a benchmark and compared regular read file and read file by a stream. His benchmark found that you always can use streams, but if you read a file that larger than 16 MB, it’s better for you to choose the stream approach.
TL;DR
If you need to produce or consume a big amount of data, streams will enable you to do it by chunks and therefore to increase your performance.
References:
https://nodejs.org/api/stream.html

Streams In Depth In Node.js was originally published in Autodesk TLV on Medium, where people are continuing the conversation by highlighting and responding to this story.

Streams In Depth In Node.js

<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*0947p0KUP0Tzcb7lochjZQ.jpeg" /></figure>As backend developers, we face read/write data challenges all the time. More data means more challenges.In this blogpost I will introduce a method that I found as the most optimal way to read/write big amounts of data, and this method will help you increase your apps’ I/O performance.I will explain the stream concept in general, and how you should use it in Node.js in particular.<h3>The Offline Challenge From The Backend Side — A True Story</h3>Any app that respects itself, must provide offline services to its users. Especially if its users might be using the app in a location without wifi, such as construction engineers in the construction area.When the user is offline, he cannot get his relevant data from the server. Therefore, that user has to have all of his data on his device (e.g. cell phone, tablet, etc.).The app developers challenge is to provide that entire data, in advance, in the most efficient performance way.The most trivial solution for that challenge is to provide a simple GET collection endpoint. The client will call that endpoint every now and then, in order to have all of the data on the user device. That endpoint will return all of the data with pagination. The more information the user will have, the more requests he will send in order to get all the pages of data.The cons of that solution are that the client will send requests as the number of pages, and it may drain the user battery or his internet package, and can overload our servers.That solution may fit to small services with a small amount of data. But we have to take into account that the users’ data enlarges every day. Hence, if you would like to preserve resiliency and scalability, you should not use it.So, you might be asking, what should we do then?There are a lot of possible solutions to that challenge, and I’m going to share with you one of them using streams.The challenge was sending a big amount of data to the clients without using a simple CRUD (Get collection with a pagination).Each time the user logs in, the client will send a POST request, that request will trigger in the backend an async operation, that will retrieve the user data from the database and will create compressed files from it (with Brotli — a data format specification for data streams compressed). Each compressed file is a chunk of data, that will be sent on a request (request is a stream) to a file server.Now the client can poll the server with GET requests. The polling response will be the status of the upload files (IN_PROCESS/COMPLETED), and the identifiers of the files that already uploaded.The client doesn’t need to wait until the server will finish the uploading, it can start downloading the files with the identifiers that it got from fileserver.And now we are not wasting the client and the server resources.Now, let’s understand the stream magic!<h3>A Brief History</h3>Streams were introduced in Unix, decades ago.I believe you all use that kind of commands in that terminal:<pre>history | grep something</pre>And that without even knowing that you are actually using streams. Actually, The pipe command takes the output (STDOUT) of each process and transfer it as an input (STDIN) to the next process. The STDOUT and the STDIN are both streams, and the pipe connects those streams.<h3>Files I/O Chalenges</h3>If you want to read and write a file you have a few ways of doing it in node.js.We can do it synchronously:<pre>const data = fs.readFileSync(&#39;file&#39;); fs.writeFileSync(&#39;file-copy&#39;, data);</pre>But if you don’t want to wait for those operations to be finished, in order to move on with the script, you will choose the asynchronous way:<pre>fs.readFile(&#39;file&#39;, (err, data) =&gt; { fs.writeFile(&#39;file-copy&#39;, data, () =&gt; { console.log(&#39;file saved&#39;); } }</pre>Allegedly, everything works now and performance as well.But have you ever asked yourself where the file is been saved until it’s written? In both cases, synchronously and asynchronously the file is saved in your RAM. Before your RAM limitations, you have node memory limit, that is around ~1.4 GB. That means, that if you’ll try reading a very big file, you might decrease your system performance, or even disrupt your program and crash it.<h3>Streams To The Rescue</h3>Luckily, node has a way to read and write that file in chunks, and not as a whole unit.<pre>fs.createReadStream(&#39;file&#39;) .pipe(fs.createWriteStream(&#39;file-copy&#39;));</pre>OK, so we found a way, you can copy-paste it, now we may finish this post and continue with your life. But if you won’t understand what happened behind the scenes, you might miss some important things.<h3>TL;DR</h3>Streams are a very strong tool of transferring data if you know how to use them and understand how they work.You will find all you should know about streams in Node.js in my blogpost:<a href="https://medium.com/autodesk-tlv/streams-in-depth-in-node-js-c8cc7f1eb0d6">https://medium.com/autodesk-tlv/streams-in-depth-in-node-js-c8cc7f1eb0d6</a><img src="https://medium.com/_/stat?event=post.clientViewed&referrerSource=full_rss&postId=cc85704db108" width="1" height="1" alt=""><hr><a href="https://medium.com/autodesk-tlv/how-can-you-increase-i-o-performance-with-streams-cc85704db108">How Can You Increase I/O Performance With Streams?</a> was originally published in <a href="https://medium.com/autodesk-tlv">Autodesk TLV</a> on Medium, where people are continuing the conversation by highlighting and responding to this story.

As backend developers, we face read/write data challenges all the time. More data means more challenges.
In this blogpost I will introduce a method that I found as the most optimal way to read/write big amounts of data, and this method will help you increase your apps’ I/O performance.
I will explain the stream concept in general, and how you should use it in Node.js in particular.
The Offline Challenge From The Backend Side — A True Story
Any app that respects itself, must provide offline services to its users. Especially if its users might be using the app in a location without wifi, such as construction engineers in the construction area.
When the user is offline, he cannot get his relevant data from the server. Therefore, that user has to have all of his data on his device (e.g. cell phone, tablet, etc.).
The app developers challenge is to provide that entire data, in advance, in the most efficient performance way.
The most trivial solution for that challenge is to provide a simple GET collection endpoint. The client will call that endpoint every now and then, in order to have all of the data on the user device. That endpoint will return all of the data with pagination. The more information the user will have, the more requests he will send in order to get all the pages of data.
The cons of that solution are that the client will send requests as the number of pages, and it may drain the user battery or his internet package, and can overload our servers.
That solution may fit to small services with a small amount of data. But we have to take into account that the users’ data enlarges every day. Hence, if you would like to preserve resiliency and scalability, you should not use it.
So, you might be asking, what should we do then?
There are a lot of possible solutions to that challenge, and I’m going to share with you one of them using streams.
The challenge was sending a big amount of data to the clients without using a simple CRUD (Get collection with a pagination).
Each time the user logs in, the client will send a POST request, that request will trigger in the backend an async operation, that will retrieve the user data from the database and will create compressed files from it (with Brotli — a data format specification for data streams compressed). Each compressed file is a chunk of data, that will be sent on a request (request is a stream) to a file server.
Now the client can poll the server with GET requests. The polling response will be the status of the upload files (IN_PROCESS/COMPLETED), and the identifiers of the files that already uploaded.
The client doesn’t need to wait until the server will finish the uploading, it can start downloading the files with the identifiers that it got from fileserver.
And now we are not wasting the client and the server resources.
Now, let’s understand the stream magic!
A Brief History
Streams were introduced in Unix, decades ago.
I believe you all use that kind of commands in that terminal:
history | grep something
And that without even knowing that you are actually using streams. Actually, The pipe command takes the output (STDOUT) of each process and transfer it as an input (STDIN) to the next process. The STDOUT and the STDIN are both streams, and the pipe connects those streams.
Files I/O Chalenges
If you want to read and write a file you have a few ways of doing it in node.js.
We can do it synchronously:
const data = fs.readFileSync('file');
fs.writeFileSync('file-copy', data);
But if you don’t want to wait for those operations to be finished, in order to move on with the script, you will choose the asynchronous way:
fs.readFile('file', (err, data) => {
    fs.writeFile('file-copy', data, () => {
        console.log('file saved');
    }
}
Allegedly, everything works now and performance as well.
But have you ever asked yourself where the file is been saved until it’s written? In both cases, synchronously and asynchronously the file is saved in your RAM. Before your RAM limitations, you have node memory limit, that is around ~1.4 GB. That means, that if you’ll try reading a very big file, you might decrease your system performance, or even disrupt your program and crash it.
Streams To The Rescue
Luckily, node has a way to read and write that file in chunks, and not as a whole unit.
fs.createReadStream('file')
    .pipe(fs.createWriteStream('file-copy'));
OK, so we found a way, you can copy-paste it, now we may finish this post and continue with your life. But if you won’t understand what happened behind the scenes, you might miss some important things.
TL;DR
Streams are a very strong tool of transferring data if you know how to use them and understand how they work.
You will find all you should know about streams in Node.js in my blogpost:
https://medium.com/autodesk-tlv/streams-in-depth-in-node-js-c8cc7f1eb0d6

How Can You Increase I/O Performance With Streams? was originally published in Autodesk TLV on Medium, where people are continuing the conversation by highlighting and responding to this story.

How Can You Increase I/O Performance With Streams?

Is <a href="https://redux.js.org/">Redux</a> giving you a headache? Do you feel frustrated navigating Redux’s code base? In this article, we will implement the core functionality of Redux in approximately 30 lines of code!TL;DR — here’s our implementation of createStore and combineReducers, which cover the most common APIs of Redux.createStore<iframe src="" width="0" height="0" frameborder="0" scrolling="no"><a href="https://medium.com/media/acb142e033b6d46638e27fac5e870f5f/href">https://medium.com/media/acb142e033b6d46638e27fac5e870f5f/href</a></iframe>combineReducers<iframe src="" width="0" height="0" frameborder="0" scrolling="no"><a href="https://medium.com/media/06bebdd558c04fa8feb13403fda16251/href">https://medium.com/media/06bebdd558c04fa8feb13403fda16251/href</a></iframe>Let’s look at the <a href="https://redux.js.org/api/api-reference">API reference</a> for Redux. The first item on the list there is <a href="https://redux.js.org/api/createstore">createStore</a>, which we’re going to implement right now!<h4>createStore receives 3 parameters:</h4><ol><li>reducer</li><li>initial state</li><li>enhancers (for simplicity we will use only middlewares)</li></ol><h4>createStore returns an object with the following functions:</h4><ol><li>getState</li><li>dispatch</li><li>subscribe</li></ol>First, we’ll create the wireframe for createStore:<iframe src="" width="0" height="0" frameborder="0" scrolling="no"><a href="https://medium.com/media/47ffad823c0343953aa0600adafc3f01/href">https://medium.com/media/47ffad823c0343953aa0600adafc3f01/href</a></iframe>OK, now that we have the wireframe, we can start implementing it step by step.First of all, we need to add a local variable named state that is initialized with the initialState passed to the createStore function. Since getState just returns the state we can easily implement it:<pre>let state = initialState; return { getState: () =&gt; state, ... }</pre>Another simple implementation is subscribe:subscribe is a function that receives a listener and returns an unsubscribe function which will remove the listener so that it is no longer called on store changes.<pre>const listeners = []; return { subscribe: (listener) =&gt; { listeners.push(listener); return () =&gt; { listeners.splice(listeners.indexOf(listener), 1);} } }, ... }</pre>Before we proceed to dispatch let’s implement the last step of our Redux implementation, which is evaluating the reducer, calling the listeners, and returning the new state:<pre>let state = initialState; const listeners = [];</pre><pre>let dispatchAction = (action) =&gt; { state = reducer(state, action); listeners.forEach(listener =&gt; listener()); return state; }</pre>Now, dispatch is a function that receives an action and triggers state changes to the store. Basically, it calls the last step with the action it receives:<pre>return { dispatch: (action) =&gt; dispatchAction(action), ... }</pre>In the above implementation we used only the reducer to trigger state changes to the store, but what about our middlewares? What about all the side effects we want to execute before Redux changes the state? Before we do that let’s explore the structure of the middleware:<pre>/* A */ (middlewareAPI) =&gt; /* B */ (next) =&gt; /* C */ (action) =&gt; { .... return next(action); }</pre>A middleware is a function that returns another function that returns another function, and so on… But what’s interesting is that function B of the current middleware, receives a reference to function C of the next middleware in the array. This composition enables us to call the next middleware from the current middleware and so on until we cover all of them. Only then we can continue to the reducer evaluation. What we have here is actually a chain of middlewares!Let’s dive into the most interesting part of our implementation:<pre>let state = initialState; const listeners = [];</pre><pre>let finalMiddleware = (action) =&gt; { state = reducer(state, action); listeners.forEach(listener =&gt; listener()); return state; }</pre><pre>const middlewareAPI = { getState: () =&gt; state, dispatch: (action) =&gt; finalMiddleware(action) }</pre><pre>const newMiddleWares = middlewares.map(middleware =&gt; middleware(middlewareAPI));</pre><pre>for(let i = newMiddleWares.length - 1; i &gt;= 0; i--) { finalMiddleware = newMiddleWares[i](finalMiddleware); }</pre>Note that we changed dispatchAction to finalMiddleware. Don’t worry, it will all make sense when we finish everything!First, we evaluate each middleware by calling it with the middleware API. Now newMiddleWares is a collection of functions with the following structure:<pre>(next) =&gt; (action) =&gt; { .... return next(action); }</pre>At the last step, we go over the new middlewares in reverse where we evaluate each middleware with the previously executed value. This part is a little bit confusing so let’s start with the last middleware.The last middleware receives the first value of finalMiddleware, which is to evaluate the reducer, and it returns the last function in the middleware’s structure. finalMiddleware is now updated with that function.The middleware before it will receive that function and return its last function in the structure. We repeat this process until we reach the first middleware.At the end, the finalMiddleware will be the first middleware in the collection, so when we invoke dispatch it will call the first middleware.<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*Id_JStBQSGCLlAIzWgNhPA.png" /></figure>In the above diagram, we can see that the next parameter in each middleware is a reference to the function getting the action in the next middleware in the array.Let’s review our final implementation of createStore:<iframe src="" width="0" height="0" frameborder="0" scrolling="no"><a href="https://medium.com/media/acb142e033b6d46638e27fac5e870f5f/href">https://medium.com/media/acb142e033b6d46638e27fac5e870f5f/href</a></iframe>Now, we can move on to the next part in the API reference which is — <a href="https://redux.js.org/api/combinereducers">combineReducers</a>:<h4>combineReducers receives 1 parameter:</h4><ol><li>reducers (object)</li></ol><h4>combineReducers returns:</h4><ol><li>a function that receives a state and an action and returns a state</li></ol>The wireframe is pretty simple:<iframe src="" width="0" height="0" frameborder="0" scrolling="no"><a href="https://medium.com/media/fb3d1cc12e25de41555e5c5feea66bf8/href">https://medium.com/media/fb3d1cc12e25de41555e5c5feea66bf8/href</a></iframe>The function that combineReducers returns is actually a reducer itself! And what does a reducer do? It takes a state and an action and returns a new state!So all we need to do is go over all the reducers and evaluate each of them with their corresponding state. After the iteration completes we return the new state!<iframe src="" width="0" height="0" frameborder="0" scrolling="no"><a href="https://medium.com/media/06bebdd558c04fa8feb13403fda16251/href">https://medium.com/media/06bebdd558c04fa8feb13403fda16251/href</a></iframe>Notice hasChanged that we haven’t talked about. A core part of Redux is structural sharing, which means that if a certain part of the state tree wasn’t changed, we don’t change its reference. Let’s look at an example:<pre>state |-- part-a |-- part-b | |-- part-b-1 | |-- part-b-2 |-- part-c</pre>So, if we change part-b-1 in our state, we don’t want part-a or part-c or part-b-2 to lose their original reference since they weren’t changed. The ones that do need to change are part-b-1 part-b and state. That’s why we have hasChanged, in order to return the newly created state if some parts of the tree that did in fact change.I encourage you to go and try to implement it by yourself! Don’t look at the implementation, just take a look at the APIs, understand what they actually do and dive in. You will see it’s not as difficult as you might think:<ol><li>createStore - <a href="https://redux.js.org/api/createstore">https://redux.js.org/api/createstore</a></li><li>combineReducers - <a href="https://redux.js.org/api/combinereducers">https://redux.js.org/api/combinereducers</a></li><li>store - <a href="https://redux.js.org/api/store">https://redux.js.org/api/store</a></li></ol>As an exercise, see how hard it is to add replaceReducer and bindActionCreators to your implementation!That’s it! hope you enjoyed it!<img src="https://medium.com/_/stat?event=post.clientViewed&referrerSource=full_rss&postId=f795b9d28c60" width="1" height="1" alt=""><hr><a href="https://medium.com/autodesk-tlv/simplifying-redux-f795b9d28c60">Simplifying Redux</a> was originally published in <a href="https://medium.com/autodesk-tlv">Autodesk TLV</a> on Medium, where people are continuing the conversation by highlighting and responding to this story.

Is Redux giving you a headache? Do you feel frustrated navigating Redux’s code base? In this article, we will implement the core functionality of Redux in approximately 30 lines of code!
TL;DR — here’s our implementation of createStore and combineReducers, which cover the most common APIs of Redux.
createStore
https://medium.com/media/acb142e033b6d46638e27fac5e870f5f/href
combineReducers
https://medium.com/media/06bebdd558c04fa8feb13403fda16251/href
Let’s look at the API reference for Redux. The first item on the list there is createStore, which we’re going to implement right now!
createStore receives 3 parameters:

reducer
initial state
enhancers (for simplicity we will use only middlewares)

createStore returns an object with the following functions:

getState
dispatch
subscribe

First, we’ll create the wireframe for createStore:
https://medium.com/media/47ffad823c0343953aa0600adafc3f01/href
OK, now that we have the wireframe, we can start implementing it step by step.
First of all, we need to add a local variable named state that is initialized with the initialState passed to the createStore function. Since getState just returns the state we can easily implement it:
let state = initialState;
return {
  getState: () => state,
  ...
}
Another simple implementation is subscribe:
subscribe is a function that receives a listener and returns an unsubscribe function which will remove the listener so that it is no longer called on store changes.
const listeners = [];
return {
  subscribe: (listener) => {
    listeners.push(listener);
    return () => {
      listeners.splice(listeners.indexOf(listener), 1);}
    }
  },
  ...
}
Before we proceed to dispatch let’s implement the last step of our Redux implementation, which is evaluating the reducer, calling the listeners, and returning the new state:
let state = initialState;
const listeners = [];
let dispatchAction = (action) => {
  state = reducer(state, action);
  listeners.forEach(listener => listener());
  return state;
}
Now, dispatch is a function that receives an action and triggers state changes to the store. Basically, it calls the last step with the action it receives:
return {
  dispatch: (action) => dispatchAction(action),
  ...
}
In the above implementation we used only the reducer to trigger state changes to the store, but what about our middlewares? What about all the side effects we want to execute before Redux changes the state? Before we do that let’s explore the structure of the middleware:
/* A */ (middlewareAPI) => /* B */ (next) => /* C */ (action) => { 
  ....
  return next(action);
}
A middleware is a function that returns another function that returns another function, and so on… But what’s interesting is that function B of the current middleware, receives a reference to function C of the next middleware in the array. This composition enables us to call the next middleware from the current middleware and so on until we cover all of them. Only then we can continue to the reducer evaluation. What we have here is actually a chain of middlewares!
Let’s dive into the most interesting part of our implementation:
let state = initialState;
const listeners = [];
let finalMiddleware = (action) => {
  state = reducer(state, action);
  listeners.forEach(listener => listener());
  return state;
}
const middlewareAPI = {
  getState: () => state,
  dispatch: (action) => finalMiddleware(action)
}
const newMiddleWares = middlewares.map(middleware => middleware(middlewareAPI));
for(let i = newMiddleWares.length - 1; i >= 0; i--) { 
  finalMiddleware = newMiddleWares[i](finalMiddleware);
}
Note that we changed dispatchAction to finalMiddleware. Don’t worry, it will all make sense when we finish everything!
First, we evaluate each middleware by calling it with the middleware API. Now newMiddleWares is a collection of functions with the following structure:
(next) => (action) => { 
  ....
  return next(action);
}
At the last step, we go over the new middlewares in reverse where we evaluate each middleware with the previously executed value. This part is a little bit confusing so let’s start with the last middleware.
The last middleware receives the first value of finalMiddleware, which is to evaluate the reducer, and it returns the last function in the middleware’s structure. finalMiddleware is now updated with that function.
The middleware before it will receive that function and return its last function in the structure. We repeat this process until we reach the first middleware.
At the end, the finalMiddleware will be the first middleware in the collection, so when we invoke dispatch it will call the first middleware.

In the above diagram, we can see that the next parameter in each middleware is a reference to the function getting the action in the next middleware in the array.
Let’s review our final implementation of createStore:
https://medium.com/media/acb142e033b6d46638e27fac5e870f5f/href
Now, we can move on to the next part in the API reference which is — combineReducers:
combineReducers receives 1 parameter:

reducers (object)

combineReducers returns:

a function that receives a state and an action and returns a state

The wireframe is pretty simple:
https://medium.com/media/fb3d1cc12e25de41555e5c5feea66bf8/href
The function that combineReducers returns is actually a reducer itself! 
And what does a reducer do? It takes a state and an action and returns a new state!
So all we need to do is go over all the reducers and evaluate each of them with their corresponding state. After the iteration completes we return the new state!
https://medium.com/media/06bebdd558c04fa8feb13403fda16251/href
Notice hasChanged that we haven’t talked about. A core part of Redux is structural sharing, which means that if a certain part of the state tree wasn’t changed, we don’t change its reference. Let’s look at an example:
state
 |-- part-a
 |-- part-b
 |    |-- part-b-1
 |    |-- part-b-2
 |-- part-c
So, if we change part-b-1 in our state, we don’t want part-a or part-c or part-b-2 to lose their original reference since they weren’t changed. The ones that do need to change are part-b-1 part-b and state. That’s why we have hasChanged, in order to return the newly created state if some parts of the tree that did in fact change.
I encourage you to go and try to implement it by yourself! Don’t look at the implementation, just take a look at the APIs, understand what they actually do and dive in. You will see it’s not as difficult as you might think:

createStore - https://redux.js.org/api/createstore
combineReducers - https://redux.js.org/api/combinereducers
store - https://redux.js.org/api/store

As an exercise, see how hard it is to add replaceReducer and bindActionCreators to your implementation!
That’s it! hope you enjoyed it!

Simplifying Redux was originally published in Autodesk TLV on Medium, where people are continuing the conversation by highlighting and responding to this story.

Blog

Autodesk handles software design and development that affects the lives of hundreds of millions of people around the world on a daily basis. Autodesk Israel supports the creation of a varied work environment for the development of innovative technologies, alongside an original and creative design.

Links