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.
Objectives and Key Results are a common way for large software teams to align their priorities in order to be most effective as a whole. It’s difficult to wordsmith objectives which yield measurable and specific key results, but it starts with understanding what a good objective and a good key result look like.
In order to create clarity about the level of Product Ownership in your organization, we distinguish five types of Product Owners:
- The Scribe
- The Proxy
- The Business Representative
- The Sponsor
- The Entrepreneur
The Cynefin Framework is a conceptual framework used to aid decision-making. It’s a great way to model both decision making, but also system design:
- Simple systems are known, cause-effect relationships are perceivable, predicable, and repeatable
- Complicated systems are knowable, cause-effect relationships are separated in time and space
- Complex systems are retrospectively coherent, cause-effect relationships are not repeatable
- Chaotic systems are incoherent, cause-effect relationships are not perceivable
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.
The business fable of The Chicken and the Pig explains breakfast pigs and chickens in the Scrum process. It’s a way to differentiate between roles in the Scrum/Agile world. Roles are key in Agile. They are constant and form the basis of every decision and define the very basic human relationships in Scrum. Pigs are committed whereas chickens are involved.
This is a short activity to measure participants’ engagement for the meeting at hand.
Why continuous deployment is important, how continuous integration affects your deployment process, and why it’s important to help your reviewers with small changes.
- Make clean, single-purpose commits
- Write meaningful commit messages
- Commit early, commit often
- Don’t alter published history
- Don’t commit generated files
A few best practices for managing history in feature branches to keep your master branches semantic.
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. Domain Driven Design by Eric Evans
Understanding that software is an implimentation of a conceptual design, or Domain Model, of how a system works, and that Domain Model is described in a Ubiquitous Language out of a collaboration of all members of the team. By modeling the domain of the system, requirements and changes can be described to engineers without a loss in translation, and important domain logic is no longer hidden in the code.
4. 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. You can read more in his book Clean Architecture: A Craftsman’s Guide to Software Structure and Design.
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.