1 of 54

INTRODUCING THE PAMSTACK

A NEW FRAMEWORK FOR CREATING SUSTAINABLE DEVELOPMENT TEAMS

INCLUSIVE ARCHITECTURE

2 of 54

WHAT IS THE PAMSTACK?

PROCESS

MENTORSHIP

ABSTRACTIONS

3 of 54

WHY DO WE WANT TO BE INCLUSIVE OF JUNIORS?

Less project maintenance
Less overall stress
Lower cost of developers
Lower cost of project
Greater diversity

(TRACY)

We’re going to talk a lot about how inclusive architectures enable junior developers, but really, this talk is focused on what the entirety of an Inclusive architectures enables

Less maintenance for all - a codebase that allows for more people to contribute and is again, not reliant on only a handful of senior devs
Less stress on your team = more retention = saving $. It should help enable easy conflict resolution, more team buy in and cooperation internally.
Lower cost over time on developers - a more approachable codebase means you don’t have to spend top dollar on every headcount.
Lower cost of the project - using tools that we’ll recommend here take some of the strain off of your developers to hand roll all the things
More inclusion - the ability to hire juniors, which will allow for a more diverse set of candidates

4 of 54

ROB OCEL

@robocell

Senior Software Engineer at This Dot Labs

Host, Modern Web Podcast

Host, This Dot Labs Podcast

Speaker, PAMstack, Frameworks, Mentorship

5 of 54

TRACY LEE

@ladyleet

Lead, This Dot Labs, JS consulting (Angular, React, Vue, Node, Polymer)

RxJS Core Team

Google Developer Expert, Angular

Microsoft MVP

Community Rel, Node.js @ OpenJS Foundation

Women Techmakers, GDG Silicon Valley & Triangle

Modern Web Podcast

6 of 54

WHY AREN’T JUNIORS SUCCESSFUL ON OUR TEAMS?

7 of 54

People believe that the reason juniors don’t succeed is due to a deficiency of the juniors.

They don’t realize it may be a fault of the team.

8 of 54

How non-inclusive projects hurt juniors:

Poor onboarding documentation

Rely on individual excellence

Unnecessarily complex codebase

No review or mentorship

ROB

Here are some great examples of why juniors fail on teams

Poor onboarding documentation -> Juniors always have to ask about everything. There’s nothing they can reference on their own.

individual excellence -> Seniors have to micromanage juniors to make sure they don't mistakes.

If they don't, then the mistakes juniors make directly affect users negatively.

Basically if you rely on individual excellence, then you can't really afford juniors, because they need to be babysat.

Unnecessarily complex codebase - why overcomplicate development and design problems that do not need to be complex? Are you using abstractions that could help juniors and the rest of your team be more successful and productive?

When you have teams where everyone assumes that everyone is “on their own” and should do learning themselves, teams and individuals become stagnant

9 of 54

How non-inclusivity actually hurts everyone

Harder to onboard and hire

“Hit by a bus” fears

Productivity delays

Lack of advancement & stagnant careers

TRACY

Here’s how it hurts everyone:

Poor onboarding docs mean it’s Hard to onboard and hire new people -

spend more time explaining the same things to every new person and knowledge is inconsistent;
every person needs to be senior and have the ability to jump in and learn how to swim

Individual excellence runs teams

You get the “Hit by a bus” fears - People silo their experience and soon are the only person that knows a certain system.
If you lose them, you could lose months or years of effort to reverse engineer it.

Complex codebases make teams unproductive

When your codebase deviates from industry standards, or things are more “hand rolled”, it’s much more difficult for anyone to get productive immediately.
On the other hand, relying on standards and best practices can help someone be productive from day 1.

Lack of advancement -

Without mentorship, you are not creating your next senior developers or architects, meaning you end up hiring to fill higher level vacancies instead of promoting people from within.

10 of 54

Individuals succeed and are enabled by teamwork and collaboration

Decrease unnecessary complexity and focus on important features

More innovation, more excitement, more learning

A wider and more diverse set of engineers and skills on your team

THE INCLUSIVE VISION

11 of 54

WHAT IS THE PAMSTACK?

PROCESS

MENTORSHIP

ABSTRACTIONS

12 of 54

WHAT IS THE PAMSTACK?

PROCESS

MENTORSHIP

ABSTRACTIONS

13 of 54

“Processes are usually ad hoc and chaotic. The organization usually does not provide a stable environment to support processes...”

14 of 54

“... Success in these organizations depends on the competence and heroics of the people in the organization and not on the use of proven processes...”

15 of 54

“...These organizations are characterized by a tendency to overcommit, abandon their processes in a time of crisis, and be unable to repeat their successes.”

16 of 54

Process doesn’t have to be...

17 of 54

Process doesn’t have to be...

18 of 54

Clear expectations
Greater team engagement and cooperation
No single-points-of-failure
Less stress during the crazy
Reduced conflicts and fewer power struggles

THE BENEFITS OF PROCESS DONE RIGHT

19 of 54

TRAIN

PLAN

EXECUTE

REVIEW

MEASURE

PROCESS

TRACY

There are many different process methodologies. No single one is “best”.
However, all the different methodologies generally have the same format:

Define Expectations - When times are calm, write down what you expect people to do in various situations! Write actual plans!
Describe How To Meet Expectations - Explain how to enact the plan! Checklists! Step-by-step directions! Training!
Verify Expectations Are Met - Review all the things! Not just code! Review requirements, designs, meeting notes, process plans, documentation and client-facing documents! Have people in charge of running processes and ensuring compliance!
Record Results - Find meaningful metrics and keep them (ex: type of defects, code estimates planned vs actual, churn per sprint/release, etc.)
Review Accomplishments Against Expectations - Evaluate your plans and your execution with the data you collected. Can you improve your execution? Your plans? Your metrics?

20 of 54

What needs to be done?
Who will do those things?
How should it be done?
When should it be done?

HOW TO CREATE PLANS

21 of 54

The purpose of code peer review is to ensure that changes to source code Verification Items are correct, appropriate and follow style guidelines.

The goal of the code peer review process is to discover and correct defects in code before they can be observed by testers or customers.

Once all Peer Reviewers have completed the review, the author responds to comments and corrects defects.

CODE PEER REVIEW

If there is a disagreement about how to resolve an issue, the parties involved should work together to reach compromise. If an agreement is not reached, the Development Manager will arbitrate the dispute.

If a review defect cannot be resolved in the scope of the peer review, it will be marked as Track Externally and a defect will be created in the Quality Center for the issue and the defect number is added on the peer review for traceability.

22 of 54

AUTHOR

PEER REVIEWERS

OBSERVERS

DEVELOPERS

The person who makes the initial changes to the code, makes the review in CodeCollaborator and revises the Verification Items based on the results of the peer review.

Responsible for reviewing Verification Items. Can be any developer except the author. At least one Peer Reviewer is required.

Responsible for reviewing code. Can be any team member. Unlike Peer Reviewers, they are not required to approve a review before it concludes. Having an observer is not required either.

They take the role of Authors, Peer Reviewers or Observers.

ROLES AND RESPONSIBILITIES

23 of 54

Minimize errors
Teach new team members
Reduce cognitive load

CREATE CHECKLISTS

24 of 54

EFFECTS OF REVIEWS

Improved Quality
Cross-Pollination of Ideas
Redundant Learning
Reduced Stress
Eliminating the Fear of Making Mistakes

(ROB)

Reviews have so many positive effects:

Improved Quality - Catch issues before they make it to future parts of the overall development lifecycle. Issues are cheapest to fix just as they are first introduced.
Cross-Pollination Of Ideas - Your team members learn from each other both by reading code and by asking questions during a reviews
Redundant Learning - People share knowledge about different parts of the code base. This reduces siloing.
Reducing Stress and Fear Of Making Mistakes - Without review, everyone has to deal with the stress that any mistake they make would make it into the hands of customers. When everything is reviewed, people can be more comfortable and confident in their work, because they can trust that others will catch the minor mistakes that fall through the cracks.

25 of 54

TYPES OF REVIEWS

Meeting Notes
Designs
Requirements
Tests

Code
Plans
Email to Clients

26 of 54

How did we do?
Can we improve our execution?
Can we improve our processes?
Is the data we captured useful? �Should it change?

REVIEW, REVISE, ITERATE

ROB

After a while, pause and introspect.
Allow process owners time to evaluate the data they’ve collected and write up some observations pertaining to their process areas (or others)
Bring everyone together to discuss recent results, positives, issues, and ideas about how to improve.
Ask the following questions:

How did we do?
Can we improve our execution?
Can we improve our processes?
Is the data we captured useful? Should we capture different data in the future?

(ROB)

As an example, one team member kept track of our various software estimates and how long we spent doing code review vs code implementation. They discovered that we spent about 25-33% of the time it took to implement code to review it. This realization helped us sanity check our estimates in the future (making our estimates better!), and reduced the time it took to put together estimates in the first place. Win-win!
Taking time to stop and reflect is important for building team camaraderie and making juniors feel like they are a part of the team
Because everyone owns a piece of the process, everyone gets to be an authority during the discussion.

27 of 54

WHAT IS THE PAMSTACK?

PROCESS

MENTORSHIP

ABSTRACTIONS

28 of 54

WHAT IS THE PAMSTACK?

PROCESS

MENTORSHIP

ABSTRACTIONS

29 of 54

WEB DEVELOPMENT IS HARD

Performance

Security

Accessibility

Responsive Design

Progressive Enhancement

Browser Compatibility

Progressive Web Apps

30 of 54

WEB DEVELOPMENT IS HARD

Performance

Security

Accessibility

Responsive Design

Progressive Enhancement

Browser Compatibility

Progressive Web Apps

31 of 54

COMPLEXITY IS A BARRIER TO ENTRY IN OUR INDUSTRY

32 of 54

33 of 54

FRAMEWORKS CAN HELP!

THEY MAKE IT EASY TO DO THE RIGHT THING

34 of 54

AMP provides all this for <amp-img>

Image resize based on the size of the user’s viewport
Images efficiently loaded or pre-loaded
Automatically calculate reasonable values for the sizes attribute
Content can be displayed as a placeholder while the image loads
Content can be shown as a fallback if the image fails to load
Images can be automatically converted to more efficient image formats like WebP in the AMP cache
Images in the cache might also be resized and automatically built into a srcset in your document

(ROB)

To explain how frameworks can be useful for helping juniors be successful, let’s look at AMP’s replacement for the HTML image tag: <amp-img>. <amp-img> takes a similar set of attributes to the traditional image tag.

However, when your site is rendered, AMP is doing the following automatic performance optimizations:

image resize based on the size of the user’s viewport
Images efficiently loaded or pre-loaded based on: location on page (above or below the fold), bandwidth and/or system resources, and other factors (“load resources as late as possible, but prefetch resources as early as possible”)
Automatically calculate reasonable values for the sizes attribute if multiple images are made available using the srcset attribute
Content can be displayed as a placeholder while the image loads, or content can be shown as a fallback if the image fails to load
If using the AMP cache, images might be automatically converted to more efficient image formats like WebP, reducing size and improving load times
Images in the cache might also be resized and automatically built into a srcset in your document

All of this for an image tag!

35 of 54

Scaffolding a new project
Zero-config environment
Smart defaults
Out of the box performance using automatic differential serving, lazy loading, tree shaking, AoT compilation
Actively maintained and kept up-to-date with core libraries

ANGULAR CLI

Reduce the risk of defects due to out-of-date or misconfigured technologies
Easy migration between major versions of libraries
Documentation readily available
Low risk - ejecting always a possibility

TRACY

CLI tools are an excellent way to avoid the pitfalls that can occur when scaffolding a project from scratch.
They can provide a zero-config environment of smart defaults that work for generalized applications people are building
Out of the box performance using automatic differential serving, lazy loading, tree shaking, and/or ahead of time compilation
All of the major frameworks already have them (Angular CLI, create-react-app, Vue-CLI)
All of these tools are actively maintained and regularly kept up-to-date with the core libraries (reduce the risk of defects due to out-of-date or misconfigued technologies)
These tools help you migrate between major versions of libraries
The general advice is avoid “rolling your own solutions”
There is a large amount of documentation explaining how to build solutions of all types using these CLI tools. Usually better than teaching a team about a proprietary tech stack.
Low risk because ejecting is always a possibility if you have unique needs that are not well served by the CLI tool

36 of 54

STATE MANAGEMENT

(ROB)

Another great abstraction for building junior-friendly software is in the realm of state management with libraries like Redux or NgRx
These libraries allow us to split up our application into state (information about our application), actions (intents to perform actions in response to user input), and effects/reducers (how the actions are handled)
Senior developers or architects make sure that the domain is properly broken up into meaningful actions and well-designed effects

… next slide ...

The redux actions are like Amazon buttons. You don’t have to know what happens when you press the button. All you need to know is that you press the button, and then a new bottle of detergent arrives!
This allows you to be more productive because you don’t need to worry about breaking the logic of the page because you’re being given these functions which cause things to occur.

37 of 54

Strongly typed methods, variables, services
Easier to understand functionality
Stricter rules come with less bugs and growing need to understand the purpose of each method
Know what to expect and plan accordingly
Better error handling, spotting the root of the problem

TYPESCRIPT

TRACY

TypeScript - the great part is that it is strongly typed. With JS, you can get carried away and end up with confusing bits of code.

With TypeScript you are forced to have strongly typed methods, variables, services

This Makes it Easier to understand the functionality - and purpose - of each part of the code

Because it has Stricter rules that means it comes with less bugs - and less need to try and infer what each part of the app does -

instead of trying to figure out what method will return and how to treat each new thing, you know what to expect and plan accordingly because TypeScript tells you.

This leads to Better error handling, spotting the root of the problem

Also in your console you have more descriptive errors to figure out what is wrong.

This helps juniors a lot because a junior learning with a strongly typed language will make them more careful when designing new things - and it will also teach them best practices

38 of 54

DESIGN AND USER EXPERIENCE

39 of 54

40 of 54

Shared visual language for your team
Focus and constrain the set of options when building interfaces
Contain:

Design purpose and guidelines
Designer resources (ex: Sketch files)
Content guidelines
Patterns
CSS Classes

DESIGN SYSTEMS

41 of 54

Set of basic reusable components�
Implement the requirements of a design system�
Help tackle accessibility, responsiveness, etc.�
API is usually more complete and thoughtful

COMPONENT LIBRARIES

42 of 54

STATE MACHINES

43 of 54

44 of 54

(ROB)

David Piano’s library xstate - a state management library - allows you to easily visualize state machines because it has a built in GUI
Here is an example of a complex state machine tracking a purchase process from Ryan Florence.
This controls his entire purchasing flow. Architects can provide this for companies - and because he can lay it out as a state machine, he knows it will work and all the edge cases are accounted for. It makes it a logic problem not a tech problem, which means it’s easier for juniors to visualize and are not responsible for critical business logic thinking.
If you think this is complex, think about this logic scattered across multiple methods in several files!
Here we can validate the logic and flow independent of our framework. Then we just need to faithfully bind the UI to this flow!

45 of 54

WHAT IS THE PAMSTACK?

PROCESS

MENTORSHIP

ABSTRACTIONS

46 of 54

WHAT IS THE PAMSTACK?

PROCESS

MENTORSHIP

ABSTRACTIONS

47 of 54

48 of 54

Accelerates learning & growth
Increases confidence
Decreases fear of contribution/collaboration/idea sharing
Increases communication skills
Mentees feel more invested-in and valued
Improves upward mobility (5x more likely to be promoted)
Mentees become mentors and pass all these benefits on

WHAT’S IN IT FOR MENTEES

Eric Elliott https://medium.com/javascript-scene/struggling-to-find-great-senior-javascript-developers-mentorship-is-the-answer-d352ea3574eb

49 of 54

Great perk for recruiting
Increases developer productivity & retention (~70% more likely)
Reduces knowledge silos
Improves the bus factor — reduces succession risks
Creates a more positive, helpful, collaborative team culture
Increases loyalty
Increases employee engagement and motivation
Improves leader identification and promotion pipeline — mentors are 6 times more likely to be promoted (Sun Microsystems)

WHAT’S IN IT FOR OTHERS

Eric Elliott https://medium.com/javascript-scene/struggling-to-find-great-senior-javascript-developers-mentorship-is-the-answer-d352ea3574eb

50 of 54

MENTORSHIP INCLUDES

Technical Challenges

Professional Instruction

Non Technical Skills

Career Development

Radical Candor Feedback

(ROB)

So what are the topics of discussion in good mentorship sessions?
Good mentorship relationships include:

Technical Challenges - Focused conversations about technical topics

What is state management? Functional reactive programming? Unidirectional data flow?
How do you write unit tests?
How do you read YAML?
What is a microservice?

Professional Instruction - Important information about development that is often not taught in depth at universities or in boot camps

What is a “good” requirement?
What are the roles on a software team?
How do you participate in a code review?
How do you produce a useful software design?
How to fix defects and what makes something a defect vs a new feature.

Non-Technical Skills - Keys to being a good employee, team member, and person

How to manage office politics
How to be a good follower
How to be a good leader
Emotional intelligence
How to speak to clients, other developers, and bosses

Career Development - Where does your mentee want to go?

What areas of development to focus on
What technologies to study
How to work towards the next promotion
What opportunities are worth pursuing

Radical Candor Feedback - Useful and actionable feedback to drive improvement

Radical Candor is from a book by Kim Scott
The concept differentiates the different ways that we provide feedback to others.
We split the quality of our feedback into four quadrants based on 2 different qualities:

Whether we care personally about the mentee, AND
Whether we are challenging them directly

With mentorship we usually are on the side of caring personally for the person
However, a lot of mentors fall into the trap of giving solely positive feedback to their mentees

The effect is what Kim calls “Ruinous Empathy”
This is a corrosive effect that can actually hamper a person’s ability to adjust and grow.
This can be really damaging to juniors who might go a long time before realizing they’ve basically been lied to by their mentor.

51 of 54

Fostering a culture of teaching and sharing
Formal 1:1 Sessions
Code Reviews
Pair Programming
“Tech Talks”
Chat Channels

SHIFTING THE ROLE

OF THE SENIOR DEV

TRACY

You might be saying, “OK, we get it. We agree. Mentorship is good. But, how do I add this to my team? What does it look like?”

A general hunger to learn and share that learning with others is indicative of a mentorship culture.
Great mentorship activities include:

Formal 1:1 Sessions

The first thing people think about when they think of mentorship
A senior and a junior (or mid) go into a room and talk about development topics

Code Reviews

Authors learn from the comments of their reviewers
Reviewers learn new patterns and important information about the system from the authors code

Pair Programming

Pair juniors with seniors. Let the seniors dictate and the juniors drive. The two can ask each other questions and implement code together.
This approach was incredibly useful to my early career

“Tech Talks”

Tech talks are where developers prepare a conference talk-like presentation and deliver it to their peers
The peers learn new information from the talks themselves
This can also help improve communication skills and introduce people to the potential joys of public speaking

Chat Channels

Promote a place where developers can share links, discuss problems and solutions, and have conversations about development

52 of 54

WHAT IS THE PAMSTACK?

PROCESS

MENTORSHIP

ABSTRACTIONS

53 of 54

HOW JUNIORS CAN HELP THEIR TEAM USE THE PAMSTACK

Bootstrap process by writing things down, sharing with the team
Mentor and help your peers who are being onboarded
Ask questions about the project, code, or process. Document the answers and share with others.
Do and ask for code reviews proactively as a way to understand, get feedback, and create a culture of mentorship.
If team loves your process or ideas, ask for it to be formally incorporated into process

54 of 54

hi@thisdot.co

THANK YOU!