Reading Material

Leadership

How to run 1:1 meetings that work for 2

A comprehensive how-to in scheduling, planning, executing, and following up with productive 1:1s with your direct reports.

Senior Engineers Reduce Risk

This is a really great article about what a senior engineer is and how they add value to companies of different sizes. It also covers culture and interviewing.

Reaching Peak Meeting Efficiency

Unlike almost everyone I know, I appreciate meetings and find them valuable. Most people just rant against meeting and constantly delete them from their calendars. This post helps identify the true purpose for a wide range of meeting types, and most importantly when/where they should be applied. This helps you schedule, manage, and run meetings more effectivly, and give you the reasons for removing meetings that aren’t working.

Personal Development

How to Feel Progress

Feeling like you’ve made progress towards a worthy goal at the end of a day or week is critically important to moral and motivation. Understanding that context and learning some tools to break large tasks into small bite-sized ones are the first steps in feeling your progress.

A journey from Junior Developer to Technical Lead

You own your career, and each phase of your career has different challenges. Understanding your trajectory and what you need to succeed at each step is critical in personal and professional growth.

Maker’s Schedule, Manager’s Schedule

The classic 2009 article used to defend an engineer’s time against meetings and pointless interruptions.

Programming

No Longer An Inspiration

My good friend Gina Maini’s comments on the current state of women in the hacking community trended #1 on Hacker News and inspired me to write my first post Why We Hack.

Ship Small Diffs

Why continuous deployment is important, how continuous integration affects your deployment process, and why it’s important to help your reviewers with small changes.

Unlearning Toxic Behaviors in a Code Review Culture

What can you do to become a better code reviewer? There are certain toxic behaviors common in our industry when it comes to code reviews, but there is a simple checklist you can follow to make your reviews more positive, productive, and collaborative.

Run Less Software

Engineering and Product teams need to focus on their core value prop in order to stay competitive. This means teams need to spend less time on technologies and tools that have a high overhead cost, but provide little direct value to the business. Knowing when to outsourcing these tools is a key indicator of a successful engineering team.

SOLID Principles

  1. Single responsibility principle - a class should have only a single responsibility (i.e. changes to only one part of the software’s specification should be able to affect the specification of the class).
  2. Open/closed principle - “software entities … should be open for extension, but closed for modification.”
  3. Liskov substitution principle - “objects in a program should be replaceable with instances of their subtypes without altering the correctness of that program.” See also design by contract.
  4. Interface segregation principle - “many client-specific interfaces are better than one general-purpose interface.”
  5. Dependency inversion principle - one should “depend upon abstractions, not concretions.”

How to Get Buy-in for Reducing Technical Debt

So important for every engineer to master this “soft skill” of communication. The only way you’ll make an impact is if the stakeholders understand the impact in terms that prove valuable to the business and the mission.

Architecture

Presentational and Container Components

A great React design pattern which separates presentational view-only React components and stateful Redux connectors. This affords reusability of React components, easy testing, and clear separation of concerns for simple maintainence.

React + Redux Architecture : Separation of Concerns

Take an intermediary dive into arctitecting your client applications with React and Redux by applying separation of concerns. Both tools are unidirectional and promote immutability, configuring them correctly will create resiliant applications.

Five Things Every Developer Should Know About Software Architecture

  1. Software architecture isn’t about big design up front
  2. Every software team needs to consider software architecture
  3. The software architecture role is about coding, coaching and collaboration
  4. You don’t need to use UML
  5. A good software architecture enables agility

Redux for Transactional Apps

At minute 36, Netflix engineer Jeff Shi talks about designing SPAs where the application and business data is maintained in Redux, so that the rest of the application is a lightweight UI reacting to state changes.

Don’t Rewrite, React!

At React-Europe 2015, Ryan Florence describes an easy bottom-up approach to refactoring large applications with React. Very handy when you’re staring down a large refactor and want to approach it with as little risk as possible.

Learning Architectural Design Patterns

1. Ports and Adaptors by Alistair Cockburn

Allow an application to equally be driven by users, programs, automated test or batch scripts, and to be developed and tested in isolation from its eventual run-time devices and databases.

2. Onion Architecture by Jeffrey Palermo

It emphasizes the use of interfaces for behavior contracts, and it forces the externalization of infrastructure.

Key Tenents

  1. The application is built around an independent object model
  2. Inner layers define interfaces. Outer layers implement interfaces
  3. Direction of coupling is toward the center
  4. All application core code can be compiled and run separate from infrastructure

3. Clean Architecture by Bob Martin

An evolution of the Onion Architecture that emphasizes higher trust and truth in the center of your architecture, fanning out into layers of higher rates of change, connected together leveraging dependency inversion. It redefines the Onion Architecture in terms of Entities, Use Cases, Interface Adaptors, and Frameworks & Drivers.

Testing

Five Factor Testing

Five reasons why testing is important. Good tests can:

  1. Verify the code is working correctly
  2. Prevent future regressions
  3. Document the code’s behavior
  4. Provide design guidance
  5. Support refactoring

Please don’t mock me: and other test double advice

A break down of some code smells when mocking and other testing tools are misused and mislead issues. A big takeaway is that functions should do or delegate, but never both.

Performance

Jank Free

This site is a collection of articles, presentations, and tutorials which outline UX and technical issues with perceived performance, and how to address them.

JavaScript

Function Declarations vs. Function Expressions

A good write up about variable and function hoisting, functional expressions and declarations, and the benefits of named functions.

CSS

The Specificity Graph

Harry Robert’s CSS Specificity Graph for managing the ordering of CSS rules to better compliment the cascade.

Side Effects In CSS

Highlighting pitfalls in CSS, identifying side effects in CSS and how to minimize them, along with reasons for architecting CSS.

Extending In Sass Without Creating A Mess

@extend in Sass is often misrepresented and underappreciated. Smashing Magazine answers the questions “what is @extend?” and “how do I use it efficiently?”

Classy CSS: a Programmatic Approach to Sass Stylesheets

Most people don’t realize or acknowledge that CSS requires programmatic approaches with tools like Sass. Variables, DRY code, functional CSS. Make sure you check out links in the article including Atomic OOBEMITSCSS.