Skip to content

Commit

Permalink
Some updates
Browse files Browse the repository at this point in the history
  • Loading branch information
richardm committed Mar 3, 2024
1 parent 45f68db commit 0d9fdca
Show file tree
Hide file tree
Showing 16 changed files with 167 additions and 68 deletions.
10 changes: 6 additions & 4 deletions book-summaries.md
Original file line number Diff line number Diff line change
Expand Up @@ -3,12 +3,14 @@
# To modify the layout, see https://jekyllrb.com/docs/themes/#overriding-theme-defaults

layout: page
title: Summaries
title: Book Notes
permalink: /summaries/
has_children: true
---

# Book, Article, and Podcast Summaries
# Books, Articles, and Podcast Notes

## Reading Quotes

> “Not all readers are leaders, but all leaders are readers.” - President Harry Truman
Expand Down Expand Up @@ -41,9 +43,9 @@ No summaries in this section. Just links to articles I recommend:

1. [Fun, Fear, Focus: Recipe for Peak Performance](/summaries/fun-fear-focus-recipe-for-peak-performance)

## Book Summaries
## Book Notes

I have over 200 books on my to-read list. As a result, I generally start by reading book summaries and then read the full book if I find the summary useful. I am a slow reader because I generally take the time to capture notes for each chapter as I read. My goal is to never have to read the same book twice; however, I read some of my book notes dozens of times. By sharing my summaries below, I hope these will introduce you to useful concepts and encourage you to read the full book.
I have over 200 books on my to-read list. As a result, I generally start by reading book summaries and then read the full book if I find the summary useful. I read slowly because I generally make notes as I read. My goal is to never have to read the same book twice; however, I read some of my book notes dozens of times. By sharing my notes below, I hope these will introduce you to useful concepts and encourage you to read the full book.

Here is an incomplete list of the books I've read in recent years. While I haven't finished them all, I have extensive book notes for _most_ of these, although they need cleanup before sharing. Over time, I plan to share my book notes here as a resource for others. If you would like me to escalate a particular book, please open a [GitHub issue](https://github.com/richardm/richardm.github.io/issues){:target="\_blank"}.

Expand Down
10 changes: 6 additions & 4 deletions docs/engineering-best-practices.md
Original file line number Diff line number Diff line change
Expand Up @@ -15,20 +15,22 @@ permalink: /software-engineering-best-practices/

- **Prioritize the stability of your test suite over the quantity of tests.** A failing test suite should be a critical or blocker level priority for at least one team. Flaky tests introduce noise and undermine trust.
- **Require BDD tests for critical-path user stories.**
- Adopt black box testing for unit tests so that internal refactoring does not break unit tests. Unit tests should only assert that a given set of inputs produces the expected outputs.
- The point of manual testing is to catch bugs before they reach customers, and the point of automated testing is to catch bugs before they reach manual testers.
- It is generally fastest and easiest to fix bugs at the time they are introduced, so invest in catching regressions early. A unit test that fails locally within seconds is far superior to an end to end test that fails on a build pipeline hours later, and that end to end test is far superior to a manually tester finding the bug days later.
- It is generally fastest and easiest to fix bugs at the time they are introduced, so invest in catching regressions early. A unit test that fails locally within seconds is far superior to an end to end test that fails on a build pipeline hours later, and that end to end test is far superior to a manual tester or customer finding the bug days later.
- **_Everyone_ is responsible for quality.**
- **_Developers_--not testers--are responsible for writing code that works.**
- **Write tests at the lowest layer possible**: unit tests, then integration tests, then e2e/API tests. Recognize that BDD tests can be written in any layer, but most of them will live in higher layers (e.g. e2e). This is more important than the pyramid vs trophy debate, but IMO leads to a pyramid shape.
- Static analysis and compile time eliminates a whole class of runtime bugs and unit tests.
- Unit tests are highest ROI at preventing regressions because they're cheapest to write and maintain and execute fastest, but they are limited in scope and won't prevent most regressions.
- The point of integration tests is to catch bugs before e2e tests. The point of unit tests is to catch bugs before integration tests.
- If you can't reliably ship without introducing regressions, prioritize writing e2e tests for your critical path.
- **Make deployments a non-event.** Automate them. Make them frequent. Rely on automated tests (including performance tests) to inform the team of regressions. It's generally less risky to ship one change than many.
- **Make deployments a non-event.** Automate them. Make them frequent. Rely on automated tests (including performance tests) to inform the team of regressions. A small change is easier to test, easier to review, easier to revert, and is less likely to break the system than a large change, so get in the habit of making many small changes.
- Apply TDD's red-green-refactor to bugs: Where possible, write a failing automated test before fixing the bug. The best way to know whether a test will fail when the code is broken and pass when the code works is to write the test and see it fail before fixing the bug and seeing it pass.
- If the team cannot keep prod stable, requiring root cause analysis of all production bugs can uncover the common pattern (and provide some incentive!)

## On Architecture

- Architecture is the stuff that's hard to change.
- Architecture is the stuff that's hard to change (see One Way vs Two Way Decisions).
- Minimize the number of things that are hard to change.
- When it comes to software, gardener is a better term than architect. A building architect creates elaborate blueprints and then builds exactly that. A software architect is continually refining like a gardener: pulling weeds here, planting new plants there.
- When it comes to software, gardener is a better term than architect. A building architect creates elaborate blueprints and then builds exactly that. A software architect is continually refining like a gardener: pulling weeds here, planting new plants there. (Source: A YouTube video from a speaker at some tech conference...)
41 changes: 32 additions & 9 deletions docs/me/about.markdown
Original file line number Diff line number Diff line change
Expand Up @@ -7,28 +7,51 @@ has_children: true

# About Richard Morgan

_I make software engineers and organizations better._
_Software Engineering Director with a proven record of improving software engineering organizations._

<!-- ![Richard Morgan](/images/richard-morgan-medium.jpeg){: .mr-1 .d-inline } -->

<img src="/images/richard-morgan-medium.jpeg" alt="Richard Morgan" width="200" align="left" style="margin-right: 20px;" />

I currently live in Miami, FL, with my wife Hannah. While we are from North Texas, we both love to travel. I have been to nearly 50 countries, and she is catching up at 20!
Richard currently lives in Miami, FL with his wife, Hannah, who is also a software engineer. They are prepared to move to the San Francisco Bay Area immediately to pursue professional goals as soon as the right opportunity arises.

In 2002, I began my software engineering career as an intern at Electronic Clearing House (now Intuit). Over the following two decades, I worked as a backend engineer, a frontend engineer, and now as an engineering manager, where I lead culture and architecture for an organization of 70+ engineers.
Richard's childhood experiences of living in Amman, Jordan and South Korea instilled a love of travel and diverse cultures that has taken him to nearly 50 countries.

**Short-Term Goals:** Optimize for learning and continue developing my leadership and management strengths without losing technical skills.
Richard's software engineering career began in 2002 as an intern at the Electronic Clearing House, Inc. (now Intuit). Over the following two decades, Richard has worked as a backend engineer, a frontend engineer, and now as Director of Software Engineering.

**Long-Term Goal:** Co-found my own software company building a B2C SaaS product and grow it to millions of active users. I enjoy working in mid-sized teams of 20-200.
Outside of work, Richard enjoys photography, music, travel, and investing. He also created a monthly wine club in Dallas. In 2016, he ran for the Dallas County Community College Board of Trustees and [placed second with 30% of the vote](https://results.enr.clarityelections.com/TX/Dallas/61322/168577/Web01/en/summary.html).

**Short-Term Goals:** Optimize for learning and continue developing leadership and management strengths without losing technical skills.

**Long-Term Goal:** Co-found a software company building a B2C SaaS product and grow it to millions of active users.

## Professional Background

As a software engineer and engineering manager with over 20 years of software engineering experience, I am comfortable wearing either hat; however, I prefer not to wear both hats on the same team in order to coach and empower my team without micromanaging.
As a software engineer and engineering manager with over 20 years of software engineering experience, Richard is comfortable wearing a variety of hats. In new leadership roles, Richard initially takes a hands-on approach to understand business needs and engineering challenges. His North Star objective is to empower the team by ensuring they understand business objectives and are equipped to fully own engineering decisions so he can focus on culture, strategy, and communication. For additional information, see Richard's [software engineering leadership principles](https://richardmorgan.com/principles/).

In my current role as Director of Software Engineering, I primarily help my department head support an organization of over 70 engineers. Over the past two decades, I've specialized--at various times--in backend development (PHP and Node.js), frontend development (Angular, React, Backbone.js, ExtJS, and TypeScript), web performance, and security.
Richard's current responsibilities and recent accomplishments include:

In recent years, I’ve transitioned from actively leading software development and architecture as Lead Software Engineer, to managing software development teams and guiding our transition to microservices, to investing in people and developing engineering leaders.
- Managing up to 30 engineers across 12 teams in a matrix model; overseeing technical practices for four engineering teams
- Improving engineer satisfaction and retention by establishing and leading the Engineering Culture & Engagement guild for past two years to proactively identify and address engineers' pain points.
- Leading 3 strategic working groups to improve employee engagement at parent company, improve collaboration across leadership, and define engineering practices for over 400 software engineers
- Acting as right-hand for Associate VP of Engineering, leading key initiatives and supporting an organization of 70+ engineers.
- Oversaw the implementation of monitoring and observability and an ongoing migration to a microservice architecture
- Defining and overseeing the the aptitude LLC engineering roadmap
- Coaching, supporting, and developing engineers into leaders
- Led team in redesigning a core data model and migrating CPU-bound calculations from realtime APIs to nightly batch jobs, improving API response times by 80%, enabling new business capabilities which led to the acquisition of key customers

Before transitioning to management, Richard spent nearly a decade as a backend developer specialized in PHP, followed by a decade as a frontend developer specialized in Angular, React, and TypeScript. He has extensive experience with automated testing, web performance optimization, and application security.

Work-related interests include leadership, test automation, machine learning, application performance and security, functional programming, microservices and micro-frontends, automation, CI/CD and DevOps.

Outside of work, I enjoy photography, music, travel, and investing. I've spent several years abroad cumulatively and have traveled to nearly 50 countries and most US states. As a teenager, I played classical piano, and in high school, I was the drummer for a metal band. I also made multiple forays into politics, including running for Congress in TX-21, working as a software engineer for a major party presidential candidate during the 2012 general election, and running for the Dallas County Community College Board of Trustees in 2016.
## References

> "Richard Morgan is a dedicated professional that knows how to work together with people to accomplish goals. He has a firm grasp of many technologies and is willing to share that knowledge with others." - David Pennington (software engineer at Amazon)
> "Richard isn't just a good developer, he is always pulling the team towards new architectural and process improvements. Richard makes whatever he is working on into something better." - Mike Lee (coworker at aptitude, LLC)
> "Richard is one of the brightest and most talented web developers I have ever encountered. He is a problem solver and system thinker in every sense of the word. It has been a true pleasure working with someone of his caliber. Would highly recommend!" - Dr. Grey Hoff, Jr.
> "Richard has the unique ability to bring value to every project he is engaged in. He has good ideas, looks at tasks in light of the desired end result and is focused on delivering quality to his assignments... I would not hesitiate to provide the highest recommendation for Richard to any potential employer." - Georga Kopa, VP of IT, Project Management at Heritage Auctions
> "I have known Richard for a while now, both in a personal and political capacity, and admire his passion for making a difference in the community. He knows the issues that matter, and works to communicate with the people in order to find creative and fiscally responsible solutions to problems faced by our communities (which most politicians either create or ignore). He is an extremely hard worker, understands how to work and deal with people/constituents, and maintains a compassion and sense of humbleness so often lost in the world of politics." - Brian Oley, Las Aguilas Real Estate
24 changes: 10 additions & 14 deletions docs/me/my-strengths-and-weaknesses.md
Original file line number Diff line number Diff line change
Expand Up @@ -38,20 +38,16 @@ Leaders with great Strategic Thinking strengths are the ones who keep us all foc

## Perceived Strengths:

- **Researching**: Especially new ways of doing things in the context of pain points
- **Learning how things work**: I have an innate desire to understand how things work. I need to feel I understand enough context before I feel prepared to solution.
- **Improving Processes**: Creating, retiring, and refining processes to help teams be more effective.
- I cherish constructive feedback when delivered appropriately.
- **Perceptive.**
- **Detail-Oriented.**
- **Methodical & Thoughtful.**
- **Researching, Problem Solving, and Ideation**: These activities excite me, and I generally add value to teams when doing these activities. As a software developer, I read at least one hour a day consistently for over a decade, and reading and writing was typically my fastest path to entering a flow state.
- **Continuous Learning & Self-Improvement**: My innate desire to understand how things work has been a significant asset in my career, as it has lead me to developing hands-on mastery of many new technologies and methodologies. As a leader, this has enabled me to lead my teams more effectively. I cherish constructive feedback.
- **Improving Processes**: I take a balanced approach to advocating for policies that prevent issues, while challenging and removing policies that hinder progress. For example, defending an unpopular policy that required mandatory root cause analysis for all production bugs forced the team to acknowledge steps we could take to improve our accountability. By contrast, I fought and successfully overturned a policy that required developers to provide written daily scrum notes, as it undermined team autonomy and encouraged micromanagement from senior leadership.
- **Perceptive & Detail-Oriented:** My attention to detail has been instrumental to foreseeing and mitigating risks early in the project lifecycle.
- **Methodical & Thoughtful:** My deliberate and hands-on approach has been key to achieving successful outcomes.

## Known Weaknesses
## Areas of Active Improvement

I'm working on them and welcome any constructive advice:

- **Perfectionism.** To overcome this, I do well when paired with someone who is action-oriented. I also do well when I have a little too much on my plate so that I’m forced to take action. I also have to remind myself that [Done is better than Perfect](/docs/principles/done-is-better-than-perfect.md).
- **Perfectionism:** Because I value quality, I have a tendency to spend longer than necessary on certain tasks, leading to diminishing returns. To overcome this, I do well when paired with someone who is action-oriented or when facing deadlines where I have no option but to finish the task. I remind myself often that for most tasks, [done is better than perfect](/docs/principles/progress-over-perfection.md).
- **Analysis paralysis**: Sometimes I can get stuck when I see too many paths forward and no clear best option. In these times, being paired with someone action-oriented helps me focus and pick one of the least bad approaches.
- **Procrastinating**: Sometimes I procrastinate tasks when I have incomplete information or don't know how to complete a task.
- **Conflict avoidance**: As a manager, I’ve had to learn to become more direct, especially when providing negative feedback. I don’t enjoy it, but I’m getting more comfortable with it. This has led me to [Be kind, not nice](/principles/be-kind-not-nice).
- **Impatient at times.** e.g. When it takes minutes to say what could be said in seconds; when people waste time rehashing what’s already known; when people don’t invest in their personal growth; when people obstruct. Don’t tell me why something is not possible; help me find a way to do it anyway. I have to remind myself that [people are not their behaviors](/docs/principles/people-are-not-their-behaviors).
- **Procrastinating**: I have noticed that when I avoid important tasks, it tends to be due to conflict avoidance, having incomplete information, or not knowing how to complete the task. I have also been surprised to observe that many tasks can be avoided procrastinated indefinitely as a form of prioritization, without negative consequencess.
- **Conflict avoidance**: As a new manager, I struggled to give direct feedback, especially when it was negative. I feared that negative reactions could lead to ireversible escalations. I learned the hard way that it is not kind to the individual or to the team to withhold necessary feedback. This has led me to [Be kind, not nice](/principles/be-kind-not-nice). Through this transformation, I have seen firsthand how direct feedback fosters a culture of excellence and accountability that attracts high performers.
- **Navigating Impatience with Empathy** As an action-oriented leader, I am naturally inclined to push for efficiency and progress. This sometimes causes me frustration, especially when encountering repeated discussions over established facts, resistance to positive change, or a focus on obstacles rather than solutions. My leadership journey has deepened my empathy and commitment to creating an inclusive environment that supports the diverse needs of team members. When leading change, I've recognized the importance of acknowledging and validating the spectrum from resistance to eagenerness without pressing for immediate consensus or action. I've learned that leadership is a balance of pushing for progress while ensuring every team member feels heard, valued, and included. My human-centric leadership philosophy reflects my belief that true success is not merely about achieving outcomes but about supporting and developing the people who make those achievements possible.
Loading

0 comments on commit 0d9fdca

Please sign in to comment.