Dark Politics for Engineers: Part 1
“Put your sword back into its place. For all who take the sword will perish by the sword.”
— Jesus of Nazareth, 1st century Jewish Rabbi, Lord and Savior
Corporate Politics Corporate politics: The human behaviors of exercising power and authority in the workplace.
To double-down on this: politics is always the exercise of power and authority. Not sometimes. Always.
Politics is neither good nor evil; but it can achieve both.
Node vs Bun and The Innovator's Dilemma
If you haven’t heard (touching too much grass?), Bun has been making some waves in JS-land with it’s big 1.0 announcement.
It’s been fun to watch the reactions.
Jessie Frazelle had a tweet that went tech-twitter viral, describing a feeling that many were thinking. How did such massive change come, seemingly, out of nowhere (relatively speaking of course; Bun was public about it’s work for the last year).
I’ve been thinking about it a lot, and tweeted a thread/diatribe about “The Innovator’s Dilemma” and how it applies to the current Bun vs.
Leading Effective Software Teams
Introduction What does it mean for a Software Engineering team to be effective? Productive? Happy? Impactful? This has been on my mind a lot as I’ve stepped into management in this part of my career. I’ve begun to collect my thoughts into this post. Many of the ideas apply to projects of any kind, but some of the advice I’ll give will be tailored specifically to software projects projects and teams.
Good Software: The Engineer's Perspective
What does it mean for a software application to be good? Here’s my ranked ordered list of “good software” attributes:
Solution: Provides a service or solves a problem, and does it well Design: Cohesive, intuitive interface Quality: Minimal bugs and defects; good performance Delivery: Continual, helpful updates Solution and Design: What we don’t control The Solution and Design are the most visible and obvious parts of “good software”, and when the chips are down, they can make up for tons of issues to a shocking degree.
Is there a Generic "Doom Principle" of Programming Patterns?
As the software world is reeling over the log4j exploit (aka Log4Shell, aka CVE-2021-44228), I can’t help but feel a little tinge of unhealthy schadenfreude over the Java ecosystem. As I see it, Java’s infatuation with remote object directories and service providers directly led to this whack-a-mole-security-vulnerability reality that Java has been stuck in for decades.
Java Naming and Directory Interface - JNDI Common Object Request Broker Architecture - CORBA Remote Method Invocation - RMI It brings to mind Moxie Marlinspike’s 2011 article “The Cryptographic Doom Principle” where he laid out the following:
Tommy's Dope React (TDR) Project Layout
Introduction A few upsides come with adopting an opinionated framework like Ruby on Rails. One of them is having a clear pattern to the layout of a project’s source code directories and guidance on where specific code should live. This reduces the friction of creating new code modules and provides guideposts for navigating the code base. Human brains like patterns, and organizing your code into clear patterns helps developers find their way; both the newly onboarding devs and the grisled veteran devs.
Russia and the NATO Expansion
UPDATED Feb 2022 for additional links and text updates for clarity.
A little story I want to tell about the Russian Federation and the expansion of NATO under the direction of the US Government.
NOTE: Conversational quotes are paraphases of actual statements.
1991:
the Soviet Union dissolution was largely complete. All the former members of the Union were now their own nation states and several of the more radically evolving nations (like Poland) were already being approached by NATO and Europe (who was in proto-EU stages) for membership in their treaties.
React Context for Dependency Injection Not State Management
Originally published on the Test Double blog here
In discussions of React application architecture, React Context is often brought up as a way to implement “State Management” yourself. Some really great blog posts exist that provide techniques for implementing that exact thing like “Application State Management with React” by Kent C. Dodds. This technique can be useful for specific, one-off cases but less so for an entire application architecture. An article by Mark Erikson, maintainer of Redux, titled “Why React Context is Not a “State Management” Tool (and Why It Doesn’t Replace Redux)" provides some excellent arguments and marshalls other great articles as reference.
Reduce State Management Footprint with React Query
Originally posted on the Test Double blog here
As a consultant who has worked with React since 2014, I have been fortunate to see and work with many dozens of production React codebases. In that time, I’ve noticed many patterns of use (and pain) that crop up even between very different applications. I also, regularly, get asked about the React ecosystem more generally and what things I’m excited for (or dreading).
Conditional Rendering Tactics for React Components
Originally posted on the Test Double blog here
Introduction A common situation when writing React components is needing to render a particular component only under certain conditions. There are many ways to accomplish this, but the route you take often has nuanced implications or differing utility based on the current state of the code/component/system.
Let us consider the case of a component that requires some prop data to render. The following are two, general tactics for handling missing prop data: