A comprehensive how-to in scheduling, planning, executing, and following up with productive 1:1s with your direct reports.
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.
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.
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.
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.
The classic 2009 article used to defend an engineer’s time against meetings and pointless interruptions.
Why continuous deployment is important, how continuous integration affects your deployment process, and why it’s important to help your reviewers with small changes.
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.
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.
- 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).
- Open/closed principle - “software entities … should be open for extension, but closed for modification.”
- 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.
- Interface segregation principle - “many client-specific interfaces are better than one general-purpose interface.”
- Dependency inversion principle - one should “depend upon abstractions, not concretions.”
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.
The Arrow Anti Pattern is a particular pet peeve of mine. Inverting nested conditionals not only reduces reading complexity, as it no longer requires the reader to mentally keep track of the chained conditionals that has lead to this point, but in my experience it also sometimes maps better to the indended business rules. Unnesting conditionals and exiting early often lead to cleaner code.
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.
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.
- Software architecture isn’t about big design up front
- Every software team needs to consider software architecture
- The software architecture role is about coding, coaching and collaboration
- You don’t need to use UML
- A good software architecture enables agility
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.
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.
- The application is built around an independent object model
- Inner layers define interfaces. Outer layers implement interfaces
- Direction of coupling is toward the center
- 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.
Five reasons why testing is important. Good tests can:
- Verify the code is working correctly
- Prevent future regressions
- Document the code’s behavior
- Provide design guidance
- Support refactoring
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.
This site is a collection of articles, presentations, and tutorials which outline UX and technical issues with perceived performance, and how to address them.
A good write up about variable and function hoisting, functional expressions and declarations, and the benefits of named functions.
Harry Robert’s CSS Specificity Graph for managing the ordering of CSS rules to better compliment the cascade.
Highlighting pitfalls in CSS, identifying side effects in CSS and how to minimize them, along with reasons for architecting CSS.
@extend in Sass is often misrepresented and underappreciated. Smashing Magazine answers the questions “what is
@extend?” and “how do I use it efficiently?”
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.