Forem: Horace Nelson

Latency is the Growth Killer

Horace Nelson — Fri, 25 Jul 2025 16:35:58 +0000

The most overlooked growth bottleneck across marketing, product, and engineering teams is latency. It’s not a theoretical issue or a vanity metric. It’s a direct, measurable drag on performance at every stage of the user journey.

Most teams focus their growth efforts on messaging — copy, creative, onboarding flows. But the speed at which users access that message is usually treated as a technical afterthought, dealt with reactively, relegated to the bottom of backlogs instead of acted upon proactively as a first principle and a first class requirement. That’s the real problem. How fast someone can engage with what you’ve built isn’t just an engineering detail. It’s a core business lever that drives conversion, engagement, and trust.

Latency is one of the few factors that improves performance across the entire funnel. It lowers bounce rates, increases engagement, and lifts conversions without needing to guess at intent or segment audiences, which are guesses, whereas latency is precisely quantifiable.

Start with real-world metrics like Time to First Byte, Largest Contentful Paint, and Time to Interactive. Then layer that data against funnel performance analytics to see where latency is quietly eroding outcomes.

Most fixes are straightforward: tune the backend, preload key assets, optimize edge caching, and load scripts and styles intelligently. These improvements aren’t just technical wins — they multiply the impact of everything else you’re already doing. They are outcome multipliers.

The truth is, that speed accelerates everything, and treating it as just technical debt leaves free (if not guaranteed and compounding) growth on the table.

TypeScript =/= SOLID

Horace Nelson — Sun, 18 May 2025 17:26:50 +0000

“Design is about managing change. The cost of change increases with the number of reasons code has to change.” — Sandi Metz, Practical Object-Oriented Design

The Single Responsibility Principle (SRP, or the “S” in “SOLID”) is often cited but poorly understood. It doesn’t say “do one thing.” It says: a module should have one reason to change. That phrase is precise. It reframes SRP not as a matter of functional scope, but of change triggers.

This applies not just to runtime behavior, but to source code. SRP is about scope of responsibility. A change is only appropriate if it falls within what the module is meant to handle. When a module must change to satisfy both domain logic and tooling rules, that’s a sign those concerns are improperly coupled. That’s a violation.

“When you write a software module, you want to make sure that when changes are requested, those changes can only originate from one person, or rather, one tightly-coupled group of stakeholders.” — Robert C. Martin, Clean Architecture

TypeScript introduces a second reason to change

TypeScript is a static type system. It doesn’t add behavior. It doesn’t affect runtime. Its value is entirely in compile-time enforcement. And yet, satisfying the TypeScript compiler requires changes to application code. Inline annotations, type declarations, structural rewrites, complex generic definitions, and rigid configuration constraints — all of this modifies source files that would otherwise work perfectly in JavaScript. This is application code authored for the type system, not for the application’s purpose.

This introduces a second reason to change the module: compliance with a compile-time validator. That validator doesn’t exist in production. It doesn’t add safety at runtime. It isn’t required for the application to function. So why are we modifying the application logic to satisfy it?

Some will argue that TypeScript isn’t adding external syntax at all, that it’s the base language, and JavaScript is just a subset of it. But this reframing is a gaslight. Developers use TypeScript to build JavaScript applications. The runtime target is JavaScript. The logic is JavaScript. The type system is the addition. Anders Hejlsberg, the lead architect of TypeScript, has said himself that it’s “a tool to make JavaScript development safer.” That makes it extrinsic by design. So whether or not TypeScript is technically a superset, the reality is that developers are forced to modify their application syntax and logic to satisfy a tool that exists purely outside the runtime.

The cost in real code

This isn’t an abstract nitpick. In a large codebase, the amount of code written purely to appease the type system is staggering. This added weight bears real costs in both maintenance time spent and levels of effort, and those translate to real $$$. Entire hierarchies of types, overloads, inferred utilities, and workaround constructs exist solely to satisfy the compiler. It’s not auxiliary code. It’s embedded in the modules themselves.

That’s the tell. As touched on earlier:

When business logic must be rewritten, rearranged, or wrapped only to make the tooling happy, the application code now serves two masters. One of them is the domain. The other is the infrastructure.

Intrusion vs Observation

To be clear, this isn’t an argument against type safety. It’s a critique of how TypeScript intrudes on domain logic. They offer feedback or enforce constraints, but they don’t require you to embed their rules into your logic. TypeScript does. They surround the logic. TypeScript infiltrates it.

How is this different from Test-Driven Development?

Some will claim this is no different than test-driven development. In both cases, you write code to pass a test. But that comparison falls apart quickly:

Tests live outside the module. Tests don’t alter your application logic just to pass. They test it from the outside.
Tests prove what your code does. TypeScript only guesses. Tests run your code and confirm its behavior. TypeScript checks types. That’s prediction, not proof.
Tests can be deleted. The app still runs. If you remove TypeScript, your code will likely no longer build.
Tests help you explore. TypeScript forces conformance. TDD helps evolve design through feedback. TypeScript enforces constraints by static rules.

Test-driven development guides design through optional, external tests. TypeScript demands conformance inside your application logic. They are not the same.

But while TypeScript isn't TDD, it is testing...

Isn’t syntax checking the same thing?

Some will compare this to syntax validation. That’s a dodge at best. Syntax rules are intrinsic to the language. They validate that code can execute. They care nothing about safety, intent, or correctness. TypeScript, by contrast, is not validation. It is static testing, an assertion framework for types. It forces you to write extra application code not to make the application work, but to make the type system agree that it will.

I already know what some of you are thinking: something like “TypeScript isn’t testing!” or even “type-checking isn’t testing!” That point is pedantic when, functionally, TypeScript enforces a static test suite via annotations injected directly into source code. As Anders Hejlsberg, himself, said: “The [TypeScript] compiler is just another test.” That’s unassailable testimony against any claim that TypeScript isn’t a testing framework. I rest my case.

Bringing it back to SRP

If a module must be rewritten for both behavioral requirements and tooling compliance, it has two reasons to change. It no longer has a single, clean responsibility. The logic is entangled with infrastructure.

Any tool that forces change in core application code without adding runtime capability breaks that principle. It’s not a stylistic debate. It’s an architectural cost, and a high one.

And SRP has something to say about that.

Understanding the CSS Box Model: content-box vs border-box, inline vs. block elements

Horace Nelson — Sun, 18 Aug 2024 00:50:09 +0000

As a frontend developer, understanding the CSS box model is make-or-break for being able to deliver pixel-perfect layouts. Let's dive right in and discuss how both inline and block elements behave differently in the context of the two box model types—content-box and border-box.

The Basics: What’s in the Box?

Before we go into the details, it's worth it to recap what the box model even is. Every single element on your page is a box (yes, even the ones that don't actually seem boxy in shape). Boxes may be within, containing, and/or alongside other boxes.

The box model applies to all of them and consists of:

Content Box: An HTML element or CSS pseudo-element in which your actual content lives—text, images, what-have-you.
Padding: The space between your content and the border.
Border: The line wrapping around the padding and content.
Margin: The space outside the border that pushes other elements away.

So nearly every HTML element within and including the <body>, and every CSS pseudo-element, is a box. The "walls" of that box are your border, and can be given a thickness (or width. Between the that content and the walls of that box you have padding. Between those walls and other boxes, you have margin.

Key Differences Between Inline and Block Elements

It's crucial to understand the key differences in how the box model impacts inline versus block elements:

Width: Block elements expand to fill their container by default. Inline elements? They take up just enough space for their content.
Height: For block elements, padding, border, and margin will all increase the height. Inline elements stay within the line height, regardless of vertical padding or borders.
Layout Impact: Block elements influence both horizontal and vertical layout. Inline elements are all about horizontal flow, with minimal impact on vertical spacing.
Margin Collapsing: Margin collapsing is a behavior specific to block elements, where adjacent vertical margins can merge (so a margin-bottom:20px on one element can collapse into a margin-top:20px on a following element, creating one 20px margin). Inline elements don’t play this game.

Now that we know the components of the box model and the difference between inline and block elements, let’s see how content boxes are affected by the box-sizing property according to whether they're an inline or block element.

Box-Sizing: `content-box` vs. `border-box`

The box-sizing property controls how the width and height of an element are calculated, and it can significantly impact the layout.

1. `content-box` with Inline Elements

When box-sizing: content-box is applied to an inline element:

Width and Height: The width is determined solely by the content. Padding, border, and margin are added on top of this width.
Layout Impact: Since inline elements don't break the flow of text, the element’s width is only as wide as the content. Vertical padding and borders are visually present but don’t affect the height of the surrounding line.

2. `content-box` with Block Elements

When box-sizing: content-box is applied to a block element:

Width and Height: The specified width or height applies only to the content area. Padding and border are added outside of this, increasing the overall size of the element.
Layout Impact: Block elements expand to the full width of their container by default unless otherwise specified. Padding and borders increase the element’s size, pushing adjacent elements further away.

3. `border-box` with Inline Elements

When box-sizing: border-box is applied to an inline element:

Width and Height: The width includes the content, padding, and border. The content area shrinks to accommodate padding and borders within the specified width.
Layout Impact: The element’s width is still determined by the content, but now padding and borders are included within this width. Vertical padding and borders remain visually present but don’t alter the line height.

4. `border-box` with Block Elements

When box-sizing: border-box is applied to a block element:

Width and Height: The specified width and height include the content, padding, and border. This means the element's total size stays consistent with the specified dimensions, no matter how much padding or border you add.
Layout Impact: The block element’s size is more predictable because padding and border are contained within the specified width. This makes layout design easier to manage, especially when aligning elements side by side.

It's worth calling out that while content-box is the default, border-box is widely considered to be more intuitive and provide the greatest degree of control.

The CSS box model isn’t just a powerful concept—it’s a foundational tool in your frontend dev arsenal. By understanding how box-sizing affects inline and block elements differently, you can begin to create flawless layouts that are both sharp and functional without the annoyance of troubleshooting misbehaving layouts.

If you enjoyed this download on the Box Model, then hover over that heart-shaped box at the top-left and show this post all the love!

Building Better Devs: Assessing software developer language proficiency

Horace Nelson — Tue, 13 Aug 2024 18:28:01 +0000

I've been coding professionally for 26 years across several languages, including C, Perl, ASP v1-3 in JScript, JavaScript since way back in the Before Time when it was LiveScript, CSS from its alpha, PHP and Node (its JavaScript runtime) from their betas, and more recently, Python, Dart, and lately a little Go. If you asked, I’d tell you with boundless confidence that I'm an expert developer, but how do I really know that? It’s easy to spot a bad engineer over time, but how do we qualify a good one? More importantly, how do we build one? What are the qualities or skills that we must not only identify in hiring, but actively cultivate in our teams and ourselves?

The following is an organically-developed model I’ve used in which developers descend deeper through a progression in a "Language Proficiency" skill set: how much they understand the core skills within a specific language. These skills are the same for all languages:

Syntax and Grammar: Basic rules and structure of the language, as well as foundational programming concepts as implemented by the language (e.g., inheritance, abstraction, polymorphism, encapsulation).
Idiomatic Coding: Writing code in a way that is natural and considered best practice within the language community, leveraging language-specific features and idioms.
Patterns and Standards: Utilizing approaches deemed best practice by the language community, adhering to regulatory compliance, and being aware of relevant standards.
Internals and Ecosystem (which I like to call the “Ins and Outs”): A deep understanding of applicable translators (e.g., compilers, interpreters, etc.), engines, runtimes, debugging techniques, and the intent and configuration of supporting technologies like IDEs, bundling, test runners, linters, and frameworks.

The levels of progression through these skills might be:

novel familiarity: low proficiency (< 15%)
actively learning: low-medium proficiency (15-50%)
proficient: medium-to-high proficiency (50-85%)
mastery: high proficiency (> 85%)

The naming here is not as important as the expertise each implies, nor are their exact values for proficiency percentages as important as the fact that the different levels exist.

This is the progression from intern to expert:

Here's a work-in-progress rubric for determining mastery level:

Achieving a level of mastery in a software language isn’t about ticking off boxes. It's about evolving as craftspersons through progressively deeper and broader understanding of the technologies we use. As we advance, each skill informs and reinforces the next, empowering us to craft code with an ever-growing appreciation for quality and maintainability, ultimately delivering more value to our products and to the developers with whom we collaborate to create that value.

Frontend Challenge: I have had it with these motherfriggin' crickets on this motherfriggin' field!

Horace Nelson — Wed, 31 Jul 2024 04:21:32 +0000

This is a submission for Frontend Challenge v24.07.24, Glam Up My Markup: Recreation

What I Built

A page for the fictional New York Recreational Cricket League! I wanted to build something whimsical and satirical that [intentionally] misinterprets the theme (since I know nothing about any sport).

Demo

Here's an embed, but no one designs for that form factor, so go ahead and view the full-page version on Codepen.

Journey

Using the provided markup, I drafted a one-page website in vertical slideshow format, with CSS snap points, sticky headers, and weird parallax imagery.

TBH, I wanted to do this as fast as possible using only skills I could pull from memory. The HTML is unmodified, albeit gently and minimally manipulated via JavaScript (to make all linkable things linkable, like email, phone, and dates). Gratuitous use of flexbox ensued, but it's all pretty standard, if not basic.

The units are a little sloppy (px instead of rem), but I'm feeling okay about it.

Images are courtesy of the genders at OpenAI and ChatGPT 4o.

Stay Compliant, Mitigate Risks: Understanding AML and KYC as a technologist

Horace Nelson — Fri, 19 Jul 2024 02:16:54 +0000

Effective Anti-Money Laundering (AML) and Know Your Customer (KYC) strategies and processes are essential for financial institutions and other regulated entities. The regulatory landscape is rich with laws and enforcing agencies and organizations. As a software engineer, understanding these laws and requirements is crucial for implementing effectively compliant systems, safeguarding your organization from excessive regulatory auditing and penalization (including potentially steep fines).

Key Activities

Customer Due Diligence

Intended to verify customer identities and assess their risk profiles, Customer Due Diligence (CDD) is critical to effective AML strategies. CDD employs systems and software providing for (1) identity verification and (2) risk assessment, collecting and verifying detailed customer information—ranging from personally identifying details to financial behaviors—to accurately assess risk. Utilizing advanced identity verification techniques like biometric authentication, document verification, and behavioral analytics can ensure with high confidence that a customer is who they claim to be. Then using risk assessment methodologies and algorithms, institutions can categorize clients based on their potential for suspicious activities, allowing high-risk customers to be flagged for further review. Implementing a rigorous CDD practice not only fortifies the trust between institutions and their clients by guaranteeing transparent and secure financial operations, but it also protects against audits by regulatory bodies.

Transaction Monitoring

Systems involved in Transaction Monitoring can sift through veritable torrents of financial data in real-time to detect and flag suspicious activities. Beyond just spotting the overt red flags, the right processes enhanced by modern tools can also expose the subtle anomalies that hint at illicit behavior. By leveraging tools that enable and monitor streaming data we can build systems that process massive volumes of data with increasingly greater precision. Implementing sophisticated algorithms and machine learning models accelerates our ability to detect and respond to threats swiftly and effectively.

Record-Keeping

Maintain detailed records of transactions and report suspicious activities to authorities. Effective reporting leverages purpose-built providers like Actimize or NASDAQ’s Verafin, more general logging tools like Splunk or Loggly, or proprietary systems built on technologies like ELK stacks (Elasticsearch, Logstash, and Kibana) or SQL and NoSQL databases with standard visualization tools like Tableau, to facilitate the identification of unusual patterns and ensure compliance with legal requirements, thereby playing a crucial role in the overall AML/KYC framework.

Reporting

Reporting in AML/KYC involves the timely and accurate submission of regulatory filings, such as Suspicious Activity Reports (SARs) and Currency Transaction Reports (CTRs), to relevant authorities. The former (SARS) involves detailing and reporting any illicit or even suspicious activity, including customer information and a narrative explanation. The latter (CTRs) must be filed in response to particularly large transactions (over $10,000 in the U.S.) to assist in detecting and preventing potential money laundering or other financial crimes.

Technologies Enhancing AML and KYC

Machine Learning and AI

Machine learning techniques empower automated systems to detect and learn patterns and anomalies across enormous datasets, optimizing the accuracy of fraud detection. Libraries like TensorFlow or PyTorch are extensively used to build predictive models that can identify suspicious transaction patterns, enhancing the effectiveness of your AML/KYC processes. You can find publicly available models on sites like Hugging Face Model Hub and Kaggle.

Blockchain

Blockchain technology allows for indelible public ledgers that ensure the transparency and traceability of transactions, making it harder to disguise illicit activities. Leverage blockchain platforms like Ethereum or Stellar smart contracts to enforce immutable transaction records. Smart contracts can even automate compliance checks and reporting, ensuring transactions are in-line with AML/KYC regulations.

Data Analytics

Data analytics tools are essential for assessing customer risk and monitoring transactions. While you can build your own stack using data visualization tools like Tableau or Power BI to create dashboards displaying real-time risk assessments and transaction monitoring results, there are a number of SaaS tools that provide easier to implement reporting, like Actimize, SAS Anti-Money Laundering, or Oracle Financial Services Analytical Applications. These dashboards will empower compliance officers to quickly identify and respond to suspicious activities.

Global and Local Regulatory Bodies

United States:

FinCEN (Financial Crimes Enforcement Network): A bureau of the U.S. Department of the Treasury that collects and analyzes information about financial transactions to combat money laundering, terrorist financing, and other financial crimes.
OCC (Office of the Comptroller of the Currency): Regulates and supervises national banks and federal savings associations to ensure they operate in a safe and sound manner and comply with applicable laws and regulations.
FDIC (Federal Deposit Insurance Corporation): Insures deposits at banks and savings associations and examines and supervises financial institutions for safety, soundness, and consumer protection.
Federal Reserve: Provides central banking services and supervises and regulates banking institutions to ensure safety, soundness, and compliance with applicable laws and regulations.
SEC (Securities and Exchange Commission): Enforces laws against market manipulation and oversees securities exchanges, brokerage firms, and investment advisors.

International:

FATF (Financial Action Task Force): An intergovernmental organization that develops policies to combat money laundering and terrorist financing. FATF sets international standards and promotes the effective implementation of legal, regulatory, and operational measures.
EU AMLD (European Union Anti-Money Laundering Directives): A series of directives issued by the European Union to prevent money laundering and terrorist financing. These directives require member states to implement comprehensive AML/CFT measures.
FINMA (Swiss Financial Market Supervisory Authority): Switzerland's regulatory body responsible for financial regulation, including AML/CFT compliance.
APRA (Australian Prudential Regulation Authority): Regulates and supervises financial institutions in Australia to ensure financial stability and compliance with AML/CFT regulations.

Data Privacy

Data privacy laws govern the collection, use, and protection of personal data, especially Personally Identifiable Information (PII). Compliance with these laws ensures that financial institutions handle sensitive customer information securely and transparently while conducting core AML/KYC activities. Balancing AML/KYC requirements with data privacy regulations helps protect individual rights and maintain trust while meeting legal obligations. The laws regarding data privacy may change according to the geographic location in which business is being conducted. Key data privacy laws include:

United States:

CCPA (California Consumer Privacy Act): Grants California residents rights regarding their personal data, including the right to know what data is collected, the right to delete personal data, and the right to opt-out of data sale.
CPRA (California Privacy Rights Act): Expands the CCPA by adding new privacy rights for California residents and creating the California Privacy Protection Agency for enforcement.
NY SHIELD Act (New York Stop Hacks and Improve Electronic Data Security Act): Imposes data security requirements on businesses to protect New York residents' private information and mandates breach notification procedures.
Virginia CDPA (Consumer Data Protection Act): Provides Virginia residents with rights over their personal data and imposes obligations on businesses to ensure data protection and privacy.
Colorado Privacy Act (CPA): Grants Colorado residents similar data rights as those in CCPA and imposes requirements on businesses regarding data handling and protection.
Utah Consumer Privacy Act (UCPA): Provides Utah residents with data rights and imposes obligations on businesses to handle personal data responsibly.

International:

GDPR (General Data Protection Regulation): An EU regulation that mandates strict data protection and privacy measures for individuals within the European Union. It grants individuals rights over their personal data and imposes significant obligations on organizations to ensure data protection and privacy.
LGPD (Lei Geral de Proteção de Dados): Brazil's data protection law that regulates the processing of personal data and grants individuals rights over their data.
PIPEDA (Personal Information Protection and Electronic Documents Act): Canada's federal privacy law that sets rules for how businesses must handle personal information during commercial activities.

Integrating AML and KYC Solutions

System Integration

Seamless integration of AML and KYC solutions with existing systems is critical for effective automation. Use middleware platforms like MuleSoft (commercial) or Apache Camel (open source) to facilitate data exchange or deeper integrations between many disparate systems. Integration testing to ensure faithful and ongoing interoperability between both proprietary and 3rd-party systems should be rigorous and will ensure that a misconfiguration, a poorly architected subsystem, or a bit of rogue code doesn’t threaten your compliance and expose you or your customer to risk.

APIs and Interoperability

APIs are often the key to enabling interoperability between AML/KYC solutions and other systems. Design APIs following RESTful principles—using libraries like ExpressJs (JavaScript), Flask (Python), or Actix Web (Rust)—ensuring they are stateless and support the JSON/XML formats expected by most systems. Use Swagger to generate detailed documentation for RESTful APIs to facilitate integration and ensure your APIs are easily consumable by other systems. If you’re building GraphQL APIs, using tools like Apollo Server, Prisma, or Graphene will allow for self-documenting APIs (through GraphQL introspection).

Scalability and Performance

Ensure that the processing and throughput requirements of your AML/KYC solutions can handle appropriately sized volumes of data and transactions for your organization’s needs efficiently. A microservices architecture using tools like Docker or Kubernetes for proprietary systems can help to ensure scalability, allowing you to scale individual components as needed. Exploit load balancing and caching mechanisms to improve performance and ensure your system can handle peak loads without degradation in service. Taking it a step further, serverless technologies like AWS Lambda and Google Cloud Functions can provide an architecture that scales automatically, and the pay-only-for-what-you-use fee structures are optimally cost effective.

Continuous Optimization

Regularly update AML/KYC processes to incorporate advancements in technology and changes in regulations. Set up a feedback loop involving compliance officers, software engineers, and auditors to review and improve AML/KYC systems continuously. Stay informed about regulatory changes and emerging technologies to keep your systems up-to-date and effective.

It’s a deep topic

As a software engineer, mastering the specifics of AML and KYC is essential for developing compliant and efficient systems. By focusing on key principles, leveraging advanced technologies, and ensuring seamless integration, you can contribute significantly to the regulatory performance of your organization’s financial systems. Stay informed about regulatory changes and continuously seek to aggressively improve your AML/KYC posture to stay ahead in the ever-evolving landscape of financial compliance.

The Secret to Getting Ahead: the Right Things in the Right Proportions

Horace Nelson — Wed, 17 Jul 2024 16:37:00 +0000

Success isn't just about doing more and moving faster. Providing optimal value in your role is about focusing your time and effort on the right things in the right amounts for that role. This means operating effectively within different contexts. I like to visualize these contexts as "altitudes'' that we need to shift between throughout our day. From lowest-level to highest: the technical, the tactical, the strategic, and the political. These altitudes are not skill sets, but contexts to which we allocate our time and effort, and understanding the proportions in which we should focus on each one is key to:

Providing the exact right value at your organizational or career level.
Understanding the exact right value to expect from subordinates, and to coach them to achieve it.
Understanding how to show that you’re ready for a promotion, and how your role changes when you do.

The Technical

At the lowest level, the Technical, we are performing hands-on tasks. This should not be confused with “tech” or “technology,” but rather should be associated with working to generate some sort of deliverable, whether it be a project requirements document (PRD) for a Product Manager, an organization roadmap for a Program Manager, or a Software Developer coding a new feature. All disciplines have a “technical” level. This altitude is about output, or creating something of value to the delivery process.

The Tactical

The next higher level, the Tactical, concerns itself with the orchestration of one or more work streams (e.g., one or more people working on an effort) and their dependencies. In software development, this will involve everything from refining a backlog, planning and executing a sprint, various levels of quality testing, all the way to deploying a new release to the user. In book publishing, this might involve editing a manuscript, typesetting, cover design, all the way to distribution. This altitude is about delivery, or coordinating collective processes and resources to optimally deliver value.

The Strategic

At the penultimate level, the Strategic, we systematically determine goals and develop comprehensive plans aligned with those goals. While the lower two levels are about how and the “why of the how,” the Strategic is about what and the “why of the what.” That “why” will usually include business analytics, marketing research, user experience research, and the well-informed assumptions born of deep experience. This altitude is about achievement, or determining the optimal path to achieving business objectives.

The Political

It's a professionally immature attitude to "hate corporate politics," associating it only with its worst expression: some selfish and underhanded games we apparently must play in order to get ahead. Intention is important, and at its best, the Political is about an appreciation that we all have our own goals and we all interpret corporate goals according to our own biases, and it behooves us to align our goals with those of others in a way that benefits us all, especially within an organization. This altitude is about synergy, or building relationships through respect, establishing common ground, and working toward greater benefit.

Changing Altitudes

The different organizational levels (or ranks) within the same discipline should allocate their time across these four altitudes according to their responsibilities and expertise. For instance, a senior software developer might spend most of their time on technical tasks while contributing a finite amount of time to tactical planning (typically through Scrum events), but will engage in strategic planning and political networking minimally. Conversely, a CTO will primarily operate at the strategic and political levels, rarely (if ever in an enterprise environment) dropping into the tactical or technical.

Now, not everyone will agree with the distributions here. All maps are generalizations of the terrain, most are subjective, and by their very nature none are perfect. As with recipes, you should salt and pepper to taste. What's important is that there are distributions. Different roles need to operate more or less in different contexts. Leaders, in particular, typically have to learn to adeptly change altitudes in order to “face the fight where it happens,” context switching as needed. This is particularly true in smaller companies or startups where senior leadership might need to be more hands-on, or in enterprises in which a leader might need to cover for the lack of competence of more junior leaders. A leader might have to dive into the tactical and even technical details just to get sh… things done. For instance, a startup’s technical founder/co-founder might distribute her time initially with focus primarily on the technical and strategic altitudes. Or a VP with an underperforming Director might need to descend into the Tactical a bit more often to mitigate missing competencies and coach the Director and his direct reports in proper delivery.

You’re the pilot.

Mastering the art of operating at different altitudes and understanding the degree to which you dedicate your time and energies to each is key to maximizing your value to your superiors, your organization, and your users, customers, or clients. By understanding when and how to shift between technical, tactical, strategic, and political levels, you can optimize your performance and lead your team more effectively. Embrace the fluidity required to navigate these altitudes, and you can not only elevate your own career but also contribute to the overall success of your organization, especially those you lead. Pull up when you can, dive when you need, and don’t forget to "kick the tires and light the fires".

The Power of Intentional (and Aggressive) Optimization

Horace Nelson — Fri, 10 May 2024 21:46:07 +0000

If you're not using analytics to maximize user acquisition, engagement, and technical performance, your progress is haphazard. Web analytics aren't just data points that peak interest without inspiring action; they must drive intentional product improvements in each SDLC iteration. The focus is not only on expanding your featureset but also on aggressively optimizing your product, because continually introducing new features without strengthening implemented ones just constructs a house of cards. Define meaningful KPIs, establish benchmarks, and schedule regular analyses. Use insights from each change to prescribe change in the next iteration. Treating analytics as essential to iterative and aggressive optimization ensures your web applications are robust and aligned with maximal business success.

Scrum was a revolution. Is it time for another?

Horace Nelson — Tue, 07 May 2024 14:29:32 +0000

Scrum was an indisputable game-changer in the world of software product development. Its iterative approach has long empowered teams to attack projects in manageable, time-boxed chunks, adapting on the fly and improving the process as they go. And yet, industry lore is littered with anecdotes of dysfunctional Scrum teams. Scrum’s prized “agility” and self-organized teams generally require a prohibitively high caliber of discipline and communication across team members and organizations to truly access its many storied benefits. In an industry in which such skills and qualities vary wildly across individuals, are Scrum’s promises too often just too hard to collect on?

Scrum just cares about one thing.

Scrum isn’t trying to solve all problems, just one: maximizing productivity (a.k.a., velocity). There are plenty of other considerations that Scrum intentionally leaves up to the implementer. Such activities can occur during the Sprint (while not being defined by Scrum) — like quality assurance — or can occur entirely outside of the Scrum workflow — like business metrics analysis. Scrum is, by design, single-minded.

The issue lies in how Scrum prescribes distinct roles tailored specifically for its single-minded mission. Over time, these Scrum-specific roles have been adopted as standardized organizational positions, despite not being designed for such broad application. We’ve adopted a one-size-fits-all solution with defined roles that are, by their very definitions, primarily focused on delivery — ignoring other crucial aspects like engagement, correctness, performance, and financial KPIs. Consequently, our organizational structures are often built around these roles, which is problematic. The official definitions of Scrum roles are insufficient for broader organizational purposes, often leaving individuals in these roles unsure of how to bridge the gaps in a Scrum-compatible way. Perhaps what’s important is not the Scrum roles themselves, but the activities for which they’re accountable.

A cacophony of collaboration.

Additionally, Scrum’s emphasis on self-organizing teams is often highlighted as a major advantage, suggesting that teams who have their decision making power more distributed will operate more effectively. However, the effectiveness of this approach is highly debatable. It can be argued that without the clarity and direction provided by traditional leadership roles (most of which still exist anyway, causing even more confusion), self-organizing teams can struggle. One experienced leader can make faster, better decisions than “decisioning by committee,” and such leaders are ready to go on-hire, having already gone through their learning curve. Most importantly, if I learned anything from my time in the military it’s that delegation is more efficient and effective than collaboration (and consciously valuing delegation does not preclude abundant collaboration). While collaboration gives people the warm fuzzies, it requires deliberation and buy-in. Delegation gets shit done.

Not to mention that, in practice, self-organization is so dramatically difficult an ideal to achieve that many teams tend to just iteratively fumble their commitments and/or the quality of their deliverables. Self-organization for a team requires a lot of a very particular level of knowledge, self-discipline, and the assertiveness necessary to hold each other accountable. Either that or an enormous amount of specially trained staff (Scrum Masters and Coaches) to train teams on and reinforce the virtues of self-organization.

A strong tool might not be the best tool.

It has been more than three decades since Scrum was first introduced. Yet, despite the array of organizations and committees involved, its core definition has remained largely in the hands of the same select few. For an industry that openly lauds innovation, we can be absurdly dogmatic. Even the most successful and historically useful solution isn’t necessarily right for every team or project.

Scrum was a revolution. Should it now, itself, be overthrown? Of course not. It’s a heavy weight champ, and as of now there are still no real contenders. But perhaps now is the time to critically evaluate whether its once-revolutionary principles still merit their unchallenged standing, or if we are ready to develop new paradigms of productivity and leadership.

The First 30 Days: A short primer for engineering leaders joining a new org

Horace Nelson — Mon, 29 Apr 2024 23:59:47 +0000

An incoming leader needs to quickly gain an intimate understanding of how effectively people are producing and being developed, the efficacy and adoption of the processes being employed, and the attention to true quality that is being paid to the projects (performance, maintainability, stability, etc.).

Joining a new engineering organization as their leader will generally involve the challenge (and ultimate goal) of elevating variably performing teams to become consistently high-performing units that effectively meet both technical and business objectives through mindful yet aggressive realignment and optimization. However, one must first figure out what's working, what isn’t, and what should be done about it. The answer to these questions will feed the development of a comprehensive Transformation Plan that delineates a holistic approach to achieve peak optimization across the team’s people, processes, and projects.

The First 30 Days

Validate what the Team is doing right: Assess and affirm the strengths of the current engineering practices, codifying the team’s effective strategies, tactics, and achievements.
Identify opportunities for optimization: Pinpoint areas where technical, operational, or organizational changes can lead to enhanced performance and alignment within and across your teams. These adjustments may range from significant overhauls to minute refinements but each will contribute incrementally to overall effectiveness.
Develop a Transformation Plan to optimize people, processes, and projects: Include recommendations to reorganize the team or greater organization, coaching plans for individuals, and process corrections or improvements, all of which will foster a robust product engineering culture. Ensure the plan includes clear milestones aligned with the organization’s broader business goals.

This approach ensures a comprehensive understanding of the entire state of the software development lifecycle (SDLC) being inherited by conducting 1:1 meetings, assessing performance reviews, observing Scrum ceremonies and supporting meetings, inspecting the team’s artifacts (like code repositories, Scrum boards, product requirements, design specifications, documentation, DevOps pipelines, automation scripts, and supporting organizational policies), and if available, analyzing metrics from tools like Pluralsight Flow, which analyze IC behavior in Git, Github, and Jira to provide actionable insights.

The aim is to create a plan in which targeted and tailored transformations lead to significant, sustainable enhancements in time to market, product quality, and personal agency across the team(s).

Some Prerequisites

The ability to correctly observe and analyze existing behaviors and artifacts, and then develop a plan for positive transformation involves several skills that you’ll need to acquire or strengthen as an engineering leader. These include knowing and understanding:

How to identify broken processes within your project management workflow (likely Agile Scrum these days) and how to fix them.
How to select the appropriate technical solutions to build your stack, including the right tooling.
DevOps principles like CI/CD strategies, serverless vs containerization, and infrastructure-as-code.
How to evaluate talent, identify opportunities for growth, and draft and follow a coaching plan.
Other skills, like balancing (A) engineering skill sets, (B) perceived career paths, and even (C) personal dynamics within the team.

How do I do any of that?

That's a question the answer to which could fill a book. Follow me for upcoming posts in which I’ll detail many one of these key skills for engineering leaders, as well as what goes into developing a Comprehensive Transformation Plan.

Generalized Software Engineering Ranks and Progression Tracks

Horace Nelson — Mon, 29 Apr 2024 16:17:00 +0000

I get A LOT of messages from recruiters for roles that are too junior. Understanding the career progression in software engineering can help you make more informed decisions about which job opportunities align with candidates' goals and aspirations. I threw together this [hopefully] helpful reference diagram of ranks and promotion tracks in the industry. It may be extremely generalized--and convention is completely ignored in the banking industry, where you'll find roles like "Senior Software Engineer, VP"--but it serves as a a fairly standard and useful starting point for anyone navigating the world of software engineering career paths.

Here’s a PDF version: https://drive.google.com/file/d/16k9hz_sY7ZJ1DKE3LPEWzSuw60Y2v4BQ/view?usp=drive_link.

A Simple Hack to Supercharge Your Skills and Your Portfolio

Horace Nelson — Thu, 15 Jul 2021 16:49:19 +0000

Yes, that title is totally click bait, but it's also totally true. I'm about to drop the absolute most effective way to both acquire and showcase developer skills. No other method or methodology even comes close. Here's my secret:

Stop attempting big, personal projects. Do a ton of micro-projects.

Not convinced? Here are 3 simple facts:

Big projects waste your time
It sucks to admit, but you'll probably never finish that big personal software project. While it's certainly possible and some devs certainly do it, statistically that probably ain't you. Life is rather distracting, and we devs always seem to run out of steam on such things. I have about 30 or so private Github repos of big ideas that only made it 5-50% of the way. Many of them from years ago, and some over a decade old. Let's be realistic and honest with ourselves. Smaller projects—those that take a few hours to a few weeks—are easy to follow through on, and as a bonus can more often give you that gratification of having created (and finished) something.
Big projects are worse for your portfolio
You don't need a portfolio of big projects in order to show off your skills. In fact, they are really terrible for that. Other people (like prospective employers) might have to really dig into the code of big projects to reverse engineer what skills are demonstrated, and they'll never discover all of the ones you really want to showcase. Smaller projects are easier for others to consume and comprehend, and allow you to demonstrate specific skills very clearly.
Big projects make you learn slower
Big projects bog you down in boiler plate and stuff you already know. That stuff is time consuming and tedious, and trying to plug-in new tech that you don't quite understand can result in too many moving pieces to really grok those new concepts. Smaller projects let you focus on specific technologies and techniques that you want to acquire or better understand.

Micro-projects

Micro-projects allow you to acquire skills and build a showcase of those skills very quickly. The key here—and maybe, yeah, the secret—is to pick tiny, manageable projects that focus on a discrete feature scope. A video carousel in React. A page scraping service in Go. A CSS demo of box shadows. Choose projects that you can easily complete in a week, a few days, or even a few hours.

In fact, I'd recommend trying mini, micro, and nano projects. What tf is the difference here? In the software world, examples are always useful. Here are some such projects I've worked on recently that illustrate this difference while also allowing me to shamelessly plug some of my own micro-projects:

Doubly-Linked List

size: nano
time to complete: < 1 hour

No one should ever need a Linked or Doubly-Linked List in JavaScript, but it's the kind of exercise that always comes up in job interviews. I decided to whip up proof that I know what these things are, which took all of 40 minutes, tops.
Side Scroller w/ Sticky Headers + Snap Points

size: nano
time to complete: 2 hours

An example "widget" in HTML and CSS (no JS) that scrolls horizontally through slides with sticky vertical headers and snap points. I know... what? Click the link to find out.
React Stopwatch

size: micro
time to complete: 3 days

After completing a coding challenge to create a clock in vanilla JS and CSS—which I did in record time (ha, pun!)—I was inspired to try an interactive stopwatch in React and SCSS.
Particle Soup

size: micro
time to complete: 3-4 days

Having trouble coming up with a project idea? Find someone else's project that inspires you, fork it, and make it better. That's what I did when I took this vanilla JS project on Codepen and made it into a streamlined micro React app.
Image Flex

size: mini
time to complete: 1 week

A robust, secure, and easily deployable image resizing service that resizes, optimizes, and caches images on "the edge," on the fly, built on AWS Serverless technologies.

Very few of us have the actual time to do anything substantial on the side. What we can do is reduce the size and scope of a project down to something manageable—micro—while still creating something of value, and even worthy of acclaim. I'll play myself out with a list of free "code playgrounds" (mostly front-end and Node.js) to create and run your mini, micro, and nano projects:

Of course, for open source, share your code (and follow me) on Github!

Forem: Horace Nelson

Latency is the Growth Killer

TypeScript =/= SOLID

TypeScript introduces a second reason to change

The cost in real code

Intrusion vs Observation

How is this different from Test-Driven Development?

Isn’t syntax checking the same thing?

Bringing it back to SRP

Understanding the CSS Box Model: content-box vs border-box, inline vs. block elements

The Basics: What’s in the Box?

Key Differences Between Inline and Block Elements

Box-Sizing: content-box vs. border-box

1. content-box with Inline Elements

2. content-box with Block Elements

3. border-box with Inline Elements

4. border-box with Block Elements

Building Better Devs: Assessing software developer language proficiency

Frontend Challenge: I have *had* it with these motherfriggin' *crickets* on this motherfriggin' *field*!

What I Built

Demo

Journey

Stay Compliant, Mitigate Risks: Understanding AML and KYC as a technologist

Key Activities

Customer Due Diligence

Transaction Monitoring

Record-Keeping

Reporting

Technologies Enhancing AML and KYC

Machine Learning and AI

Blockchain

Data Analytics

Global and Local Regulatory Bodies

United States:

International:

Data Privacy

United States:

International:

Integrating AML and KYC Solutions

System Integration

APIs and Interoperability

Scalability and Performance

Continuous Optimization

It’s a deep topic

The Secret to Getting Ahead: the Right Things in the Right Proportions

The Technical

The Tactical

The Strategic

The Political

Changing Altitudes

You’re the pilot.

The Power of Intentional (and Aggressive) Optimization

Scrum was a revolution. Is it time for another?

Scrum just cares about one thing.

A cacophony of collaboration.

A strong tool might not be the best tool.

The First 30 Days: A short primer for engineering leaders joining a new org

The First 30 Days

Some Prerequisites

How do I do any of that?

Generalized Software Engineering Ranks and Progression Tracks

A Simple Hack to Supercharge Your Skills and Your Portfolio

Stop attempting big, personal projects. Do a ton of micro-projects.

Micro-projects

Doubly-Linked List

Side Scroller w/ Sticky Headers + Snap Points

React Stopwatch

Particle Soup

Image Flex

Box-Sizing: `content-box` vs. `border-box`

1. `content-box` with Inline Elements

2. `content-box` with Block Elements

3. `border-box` with Inline Elements

4. `border-box` with Block Elements

Frontend Challenge: I have had it with these motherfriggin' crickets on this motherfriggin' field!