TinaCMS content update

content/notes/what-it-means-for-code-to-scale.mdx

@@ -6,54 +6,69 @@ keywords: 'engineering, scalable, code, scale'
 
 This is important for tech leads & engineering management.
 
-(1) lines of code.
-This is the simplest, most easily quantified definition. The more lines of 
-code back a product, the more features it has (well, hopefully). On its 
-own though, this metric doesn't say much, other than accumulation of 
+### (1) lines of code.
+
+
+This is the simplest, most easily quantified definition. The more lines of
+code back a product, the more features it has (well, hopefully). On its
+own though, this metric doesn't say much, other than accumulation of
 code.
 
-(2) performance (speed).
-This means product experience doesn't degrade as it grows: "it" could be 
+### (2) performance (speed).
+
+
+This means product experience doesn't degrade as it grows: "it" could be
 number of active/total users; size of a user's data; number of features;
- … Anti-example: great UX for small customers, 5-10s load times for 
+… Anti-example: great UX for small customers, 5-10s load times for
 medium customers, minute-plus runtimes for larger customers.
 
-(3) development velocity.
+### (3) development velocity.
+
+
 This means product development doesn't slow down as the codebase grows. Anti-example: a spaghetti codebase that's become inscrutable and unchangeable, requiring years of tenure and/or engineering experience to develop.
 
-(4) business operations.
-This means the business doesn't need to add operational teams people 
-linearly with product size (eg number of customers). The anti-example 
-here is needing to add support people, on-call engineering linearly as 
+### (4) business operations.
+
+
+This means the business doesn't need to add operational teams people
+linearly with product size (eg number of customers). The anti-example
+here is needing to add support people, on-call engineering linearly as
 the business grows.
 
-(5) customer base.
+### (5) customer base.
+
+
 The code meets more customers' needs as it grows. (As opposed to a business
- growing, which could mean additional sales/marketing resourcing, to 
-sell to more of the same customers.) The anti-example is 
-over-engineering and/or over-automating the product: solving more 
+growing, which could mean additional sales/marketing resourcing, to
+sell to more of the same customers.) The anti-example is
+over-engineering and/or over-automating the product: solving more
 technical problems rather than solving more customer problems.
 
-(6) security.
-As the code grows, security should scale with it: the system remains 
+### (6) security.
+
+
+As the code grows, security should scale with it: the system remains
 secure despite increased complexity, data volume, user base, and feature set.
 
-(7) time & longevity.
-The code, once written, serves its purpose for a long time, versus needing 
-constant changes, maintenance, etc. An anti-example: lack of automated 
-build systems, making basic KTLO like security updates require manual 
-work. Or, overly minimal-MVP development which fails to address key use 
+### (7) time & longevity.
+
+
+The code, once written, serves its purpose for a long time, versus needing
+constant changes, maintenance, etc. An anti-example: lack of automated
+build systems, making basic KTLO like security updates require manual
+work. Or, overly minimal-MVP development which fails to address key use
 cases.
 
-(8) optionality.
-As the code grows, the business has more options for future product 
-development. Anti-example: a platform component (like payment rails, or 
-compliance logic) is too bundled to its original use case, making it 
+### (8) optionality.
+
+
+As the code grows, the business has more options for future product
+development. Anti-example: a platform component (like payment rails, or
+compliance logic) is too bundled to its original use case, making it
 difficult to package into an independent product (like an API product).
 
-Healthy scale balances all the above. In terms of RoI, the more of 2-8 we can 
-do with the least of 1 (LoC), the more value we're getting out of the 
+Healthy scale balances all the above. In terms of RoI, the more of 2-8 we can
+do with the least of 1 (LoC), the more value we're getting out of the
 software product.
 
 > Source: [https://www.linkedin.com/posts/davidchaley\_i-saw-a-debate-about-what-it-means-for-code-activity-7243839819540226048-uZMi?utm\_source=share\&utm\_medium=member\_desktop](https://www.linkedin.com/posts/davidchaley_i-saw-a-debate-about-what-it-means-for-code-activity-7243839819540226048-uZMi?utm_source=share\&utm_medium=member_desktop)
->