DEV Community: Rocky Kev

Modern Wordpress for PHP Devs using ACF 6 + block.json (Super post)

Rocky Kev — Sun, 09 Jul 2023 21:32:37 +0000

Advanced Custom Fields(ACF) is a WordPress developer's dream. ACF allows developers to add extra content fields to the WordPress Editor.

With ACF 6, ACF Blocks are now registered using the register_block_type(), which loads a block.json file and allows a PHP developer to tap into the Block API for more flexibility.

Background

Before this change, a developer would need to utilize React to build WP Blocks. [For those curious, here's WordPress's Introduction to Block Development with React].(https://learn.wordpress.org/course/introduction-to-block-development-build-your-first-custom-block/)

The alternative was making Blocks with pure HTML (Check out Carolina Nymark's free course on Full site editing for theme developers) or utilize workarounds.

Much of the WordPress ecosystem is PHP Developers. Making WP Blocks with PHP - you had to rely on Advance Custom Fields, you were not able to tap into the Block API, and you missed out on future development that the WordPress team are pushing forward.

Making WP Blocks with PHP + ACF sort of looked like a halfway point between a relic of the past and the latest Modern WordPress.

For those unfamiliar, it looks like cramming the WordPress Classic Editor into the Modern Editor.🤢🤢🤢

With ACF 6, there's now more synergy between WP Blocks made natively with React, and the PHP alternative!

(Notice the Editor rendering the changes on the fly? That's now possible thanks to ACF 6!)

Example Repository

In this repo: Advanced Custom Fields 6 + Blocks.json, I made a extremely bare-bones Wordpress theme that uses ALL ACF Fields into individual blocks. You can download the theme as a zip file and import it into your WordPress Themes.

This theme uses a CDN of tailwind css ONLY for ease of use. Tailwind is 100% optional. If you plan to fork this theme, set up tailwind properly.

Block.json

To tap into that synergy with ACF 6, register your blocks with a block.json file.

The block.json is a metadata file to help WordPress identify WHAT the block looks like.

.
└── the-theme-name
    ├── blocks
    │   ├── text-block
    │   │   ├── template.php
    │   │   └── block.json <--- here
    │   ├── different-block
    │   │   ├── template.php
    │   │   ├── block.json <--- here
    │   │   └── style.css
    │   └── another-block
    │       ├── template.php
    │       ├── block.json <--- here
    │       ├── style.css
    │       └── script.js
    ├── function.php  
    └── style.css

It looks like this:

Example: block.json

{
    "$schema": "https://schemas.wp.org/trunk/block.json",
    "apiVersion": 3,
    "name": "acf-block-json/text",
    "title": "ACF Block Json Basic: Text",
    "category": "acf-block-json",
    "icon": "welcome-write-blog",
    "version": "1.0.0",
    "acf": {
        "mode": "preview",
        "renderTemplate": "template.php" 
    }
}

Then in your theme, you'll load it with:

    register_block_type(get_template_directory() . '/blocks/text-block/block.json');

    register_block_type(get_template_directory() . '/blocks/different-block/block.json');

    register_block_type(get_template_directory() . '/blocks/another-block/block.json');

Notice that it's following the Block API's recommendation. For all the attributes, visit Metadata in block.json.

In fact, you'll be using that Metadata in block.json like a bible after we're done. :-)

PROTIP: A quick way to verify if your block was properly registered is to check the ACF menu for it.

📝 The ACF metadata

 {
  //...
 "acf": {
        "mode": "preview", // preview, edit, auto
        "renderTemplate": "template.php" 
    }
}

You may notice the acf metadata.

There's a few unique fields. The full list.

Mode is the display.

Preview mode - The ACF field lives on the sidebar. This is the method I will use in this article.
Auto mode - preview is shown but when you click on the block, it goes into "edit" mode.
Edit mode - The ACF Fields exist inside the block. This is similar to how Classic WordPress looks like. (And while it has it's use-cases, it's quite... ugly.)

renderTemplate is the frontend view.
It points to a php file with your business logic and markup.

There's a few other fields, but they're optional and out of the scope of this article.

WP Block Examples with ACF 6

I'll cover some of the more popular WP Blocks.

You can review the repo for working examples of other WP Blocks.

🧱 Basic: Text Field

The easiest field to work with is the Text Field. Direct link to code

The view:

What ever you put in on the sidebar will automatically render to the markup.

The code:

<?php 

// Text Field
// https://www.advancedcustomfields.com/resources/text/

$text = esc_html(get_field('text'));

$additionalClasses = !empty($block['className']) ? $block['className'] : 'no-classes-added';
?>

<div class="outline outline-4 outline-blue-500 py-4 my-4 <?= $additionalClasses; ?>">
    <h1 class="text-4xl underline pb-4">ACF-basic/Text</h1>
    <p>Text: <?= $text; ?></p>
</div>

🧱 Choice: Button Group

Choice features in ACF all work similar to each other. I picked the more complex field group to highlight how to use it show content, as well as a conditional. Direct link to code

In the Edit Field Group:

field label: Button Group
field name: button_group
choices:
🍇 : 🍇 Grapes
🍈 : 🍈 Melon
🍉 : 🍉 Watermelon
🍊 : 🍊 Tangerine
🍋 : 🍋 Lemon
🍌 : 🍌 Banana
🍍 : 🍍 Pineapple
🥭 : 🥭 Mango
🍎 : 🍎 Red Apple
🍏 : 🍏 Green Apple

I also created a text field with a conditional to ONLY SHOW if the choice has apple inside the name. (Pineapple, Red Apple, and Green Apple)

The View

The Code

<?php

// Button Group Field
// https://www.advancedcustomfields.com/resources/button-group/

$buttonGroupData = get_field('button_group');
$buttonValue = $buttonGroupData['value'];
$buttonLabel = $buttonGroupData['label'];

$showAppleText = false;
$addMoreToApples = '';

if (str_contains($buttonLabel, 'Apple')) {
    $showAppleText = true;
    $addMoreToApples = esc_html(get_field('add_more_to_apples'));
}

$additionalClasses = !empty($block['className']) ? $block['className'] : 'no-classes-added';
?>

<div class="outline outline-4 outline-purple-500 py-4 my-4 <?= $additionalClasses; ?>">
    <h1 class="text-4xl underline pb-4">ACF-Choice/Button Group With Text</h1>
    <p>The button selected was: <?= $buttonValue; ?></p>
    <p>If there's more content, it'll show up below:</p>
    <hr />
    <?php if ($showAppleText): ?>
        <p> <?= $addMoreToApples; ?></p>
    <?php endif; ?>
    <hr />
</div>

🧱 Content: WYSIWYG

Direct link to code

The view:
This is one of those moments where rendering the WYSIWYG ACF field into the sidebar is a awful UI experience.

Click on the Pencil Icon and switch it to EDIT mode. (You can also modify the block.json to default it to edit mode.)

The code:

<?php 
// WYSIYWG Field
// https://www.advancedcustomfields.com/resources/wysiwyg-editor/

$wysiwyg = get_field('wysiwyg');

$additionalClasses = !empty($block['className']) ? $block['className'] : 'no-classes-added';
?>

<div class="outline outline-4 outline-blue-500 py-4 my-4 <?= $additionalClasses; ?>">
<h1 class="text-4xl underline pb-4">ACF-content/WYSIWYG</h1>
    <?= $wysiwyg; ?>
</div>

🧱 Choice: True-False

Direct link to code

The view:

The code:

<?php 

// True False Field
// https://www.advancedcustomfields.com/resources/true-false/

$boolean = get_field('true-false');

$booleanAsString = $boolean ? 'true' : 'false';
$content = $boolean ? get_field('text') : 'No content. Content set to false';

$additionalClasses = !empty($block['className']) ? $block['className'] : 'no-classes-added';
?>

<div class="outline outline-4 outline-purple-500 py-4 my-4 <?= $additionalClasses; ?>">
    <h1 class="text-4xl underline pb-4">ACF-Choice/True False With Text</h1>
    <p>Test boolean: <?= $booleanAsString; ?></p>
    <p><?= $content; ?></p>
</div>

🧱 Relational: Link

Direct link to code

The view:
What I like about this ACF field is that it still uses native WordPress features.

The code:

<?php 

// Link Field
// https://www.advancedcustomfields.com/resources/link/

$link = get_field('link');
$fullLink = '';

if ( $link ) {
    $link_url = $link['url'];
    $link_title = $link['title'];
    $link_target = $link['target'] ? $link['target'] : '_self';

    $fullLink = "<a href='$link_url' target='$link_target'>$link_title</a>";
}

$additionalClasses = !empty($block['className']) ? $block['className'] : 'no-classes-added';
?>

<div class="outline outline-4 outline-orange-500 py-4 my-4 <?= $additionalClasses; ?>">
    <h1 class="text-4xl underline pb-4">ACF-relational/Link</h1>
    <p>Test Link: <?= $fullLink; ?></p>
</div>

Hidden Attributes

Tucked away inside all WP Blocks is a $block.

All data within the Editor screen can be accessible from this $block array.

It looks like this:

Array
(
    [render_template] => template.php
    // ... 
    [supports] => Array
        (
            [align] => 1
            [html] => 
            [mode] => 1
            [jsx] => 1
            [anchor] => 1
            [ariaLabel] => 1
            [color] => Array
                (
                    [background] => 1
                    [gradients] => 1
                    [link] => 1
                    [text] => 1
                )

            [position] => Array
                (
                    [sticky] => 1
                )

            [spacing] => Array
                (
                    [margin] => 1
                    [padding] => 1
                    [blockGap] => 1
                )

            [typography] => Array
                (
                    [fontSize] => 1
                    [lineHeight] => 1
                )

        )
    [acf_block_version] => 2
    [api_version] => 3
    [title] => ACF Block Json Basic: Text with Block Supports
    [category] => acf-block-json
    [icon] => welcome-write-blog
    [mode] => preview
    [name] => acf-block-json/text-with-block-supports
    [data] => Array
        (
            [text] => Test Block.
            [_text] => field_64a8ebaf28669
        )
    [align] => 
    [backgroundColor] => vivid-red
    [textColor] => luminous-vivid-amber
    [fontSize] => x-large
    [id] => block_6be9f1b1aa3b7a2d677a19b71715d58c
)

For example, if you wanted to add anchor IDs to your element, you can do:

?> <div id="<?= $block['id']; ?>">

The Supports Documentation

Your block.json may look like this:

{
    "$schema": "https://schemas.wp.org/trunk/block.json",
    "apiVersion": 3,
    "name": "acf-block-json/text-with-block-supports",
    "title": "ACF Block Json Basic: Text with Block Supports",
    "category": "acf-block-json",
    "icon": "welcome-write-blog",
    "version": "1.0.0",
    "acf": {
        "mode": "preview",
        "renderTemplate": "template.php"
    },
    "supports": {
        "anchor": true,
        "align": true,
        "color": {
            "background": true,
            "text": true
        }, 
        "typography": {
            "fontSize": true
        }
    }
}

In the supports, you may notice anchor, align, color, and typography.

This is where the future of WordPress is headed.

Block Supports API documentation

This gives us native Wordpress Block features.

📝 Example of Block Supports

Direct link to code

The view:

The sidebar with Color & Typography? Native Block API! 🏆

The code:

<?php

$text = esc_html(get_field('text'));

// SUPPORT OPTIONS
// == Anchor (anchor: true) ==
//  This gives you a anchor ID. <a id="anchor-id" href="https://example.com">Link</a>
$anchorID = $block['anchor'] ?: $block['id'];

// == Align (align: true) ==
//  This determines alignment. 
//  NOTE: On the WP Editor, it's a bit buggy. 
$alignSupport = "text-align: " . $block['align'] . ";" ?: '';

// == Color [background, text] == 
//  Two types of values. Named values vs custom values.
//  Named values have a class: <div class="has-vivid-green-cyan-background-color"></div>
//  Custom values are style injected: <div style="background-color:#ffffff;"></div>
$backgroundColorNamed = ($block['backgroundColor']) ? "has-" . $block['backgroundColor'] . "-background-color" : '';
$backgroundColorCustom = ($block['style']['color']['background']) ? "background-color:" . $block['style']['color']['background'] . ";": '';

$textColorNamed = ($block['textColor']) ? "has-" . $block['textColor'] . "-color" : '';
$textColorCustom = ($block['style']['color']['text']) ? "color:" . $block['style']['color']['text'] . ";": '';

// == Typography == 
//  Two types of values. Named values vs custom values.
//  Named values have a class: <div class="has-x-large-font-size"></div>
//  Custom values are style injected: <div style="font-size: 1.9em;"></div>

$fontSizeNamed = ($block['fontSize']) ? "has-" . $block['fontSize'] . "-font-size" : '';
$fontSizeCustom = ($block['style']['typography']['fontSize']) ? "font-size:" . $block['style']['typography']['fontSize'] . ";": '';

// == AdditionalClasses (true) == 
// Default is true. This allows you to add classes from the editor side
$additionalClasses .= !empty($block['className']) ? $block['className'] : ' no-classes-added';

// FRONTEND
$additionalStyles .= "$backgroundColorCustom $textColorCustom $fontSizeCustom $alignSupport ";
$additionalClasses .= "$backgroundColorNamed $textColorNamed $fontSizeNamed ";
$addAnchorID = "id=$anchorID";
?>

<div <?= $addAnchorID;?> class="outline outline-4 outline-blue-500 py-4 my-4 <?= $additionalClasses; ?>" style="<?= $additionalStyles; ?>">
    <h1 class="text-4xl underline pb-4">ACF-basic/Text</h1>
    <p>Text: <?= $text; ?></p>
</div>

Native Support vs ACF Versions

You might see some overlapping between native Block API supports like Block API Color Picker for background and text and ACF Fields like ACF Color Picker. Which one do you choose?

Honestly, hard to say. It DEPENDS.

For example:

The Block API Color Picker is much more 'aligned' with Modern Wordpress, versus the ACF version.

Where the Block API Align doesn't seem to work very well with ACF Blocks, and I rather recreate a radio field that does it better.

If possible, I'd personally choose native Block API support as much as I can.

Finally

This was a long post. It's the result of my weekend of experimenting and building WP blocks with ACF 6. Use the Advanced Custom Fields 6 + Blocks.json repo for more code examples.

Huge shoutout to Advanced Custom Fields team for their hard work in getting ACF and the Block API working nicely together. As well as the WordPress team in really improving the Editor experience.

Also a huge shoutout to Register ACF Blocks - joeyfarruggio.com for the inspiration for this post.

Tips for Asking Better Interview Questions - A Summary of "Talk to Me"

Rocky Kev — Mon, 09 Jan 2023 16:41:04 +0000

As a senior developer, it's my responsibility to help the business with hiring. That includes interviews with technically my new boss.

Right now, my job is looking for a Director of Frontend (Weird title since technically we're Full-Stack. But the industry as a whole is torn between what the heck Frontend even means).

I don't have to remind people - Tech interviews are broken. We force an introvert to sit in a room full of strangers and demand they get comfortable - fast. Then force them to answer questions on the spot while 6 other sets of eyes judge them.

There are hundreds of books on how to ACE the tech interview for applicants. But what about the interviewer - the person on the other side of the table?

Why is the applicant required to come up with great stories?

As we look for a Director of Frontend (Again weird title), how do I make this a better experience? How can I elicit the questions that help the business know that this application is an excellent fit? How do I drill through the rote responses and drill into the heart of the person's core? How do I break this cycle of interview abuse? And how do I do this, all within an hour?

I struggled to find a good book to create better tech interviews. There wasn't any.

But - I was recommended the book "Talk to Me" by Dean Nelson.

(image from https://deannelson.net/)

This resource was recommended by the Rands Leadership Slack group.

"Talk to Me" Book Summary

Included are my takeaways from the book.

If you're reading this as a future applicant to the Director of Frontend, congrats on doing your homework on me.

The Goal of an Interview

An interview is a conversation, not an interrogation. It’s about gaining understanding. The interview is not about you, the person. Take your ego out of it. There are no winners or losers.

It's also a job. Doctors, Lawyers, Social Workers, Human Resources all have people they like talking to, and people they don't. Regardless of how you feel, you’re a professional. You have to appear impartial. Let the person speak without your correction or judgment or criticism.

Craft your interview through the prism of “What does Dave need to know here?" Focusing on someone in the audience helps you get your ego out of the way and put the emphasis back on the person you’re talking to.

It's all about gathering information.

The Type of Questions to ask

The best questions are the open-ended ones, where the source has a chance to explain something, and even provide an anecdote to illustrate it.

Lead the conversation with specifics about them. Do your homework. Avoid vagueness.

A prime example of bad questions is during an Olympic event, where an athlete just completed something that they've been obsessing about for the last four years of their lives, and the interviewer asks, “What was it like to be out here?” It's vague. That results in canned answers like "Nothing is like being there".

Instead, get specific. “How you were able to focus after that false start?” Or "How did this victory or loss rank with other wins and losses in your career?"

A question like "What was it like being on the Arctic Circle?" may result in a single-word answer: "Cold". Two better questions would be “What was the most difficult part about being there?” Or, “What was the most fun part about being there?”

Doing your homework allows you to ask questions that begin with “Why” or “How,” which are guaranteed to get you further than “When”, “What”, “Who” or “Where.”

Open-ended Questions for Inspiration

What first got you interested in...”

This is a "legacy"-type of question.

Pointing out their legacy and asking sources how they want to be remembered. This opens up an opportunity for them to tell you what is important.

A great example of a "legacy" question is when President Clinton went on Fox News Sunday with Chris Wallace. Wallace asks Clinton to talk more about what is motivating him in his charitable work.

WALLACE: Mr. President... In a recent issue of the New Yorker you say, quote, “I’m sixty years old and I damn near died, and I’m worried about how many lives I can save before I do die.” Is that what drives you in your effort to help in these developing countries?

"What do you make of..."

This gives you a chance to bring up an issue that your source can expound on.

Using another example of President Clinton and Wallace:

WALLACE: When you look at the $3 billion from Branson, plus the billions that Bill Gates is giving in his own program, and now Warren Buffett, what do you make of this new age of philanthropy?

"Help me understand...”

This puts your source in the role of an expert and they can elaborate on the topic.

You have said...”

This requires you to know your source's background. Within the tech interview context, it could be something in their cover letter or referencing a statement from a prior interview.

"Well is it more like this or is it like this?"

Ira Glass of This American Life uses this prompt to force the interview to go somewhere. They either bat away your theory or go in another direction.

A variant of that is:
“How did you think it was going to work out before it happened? And then how did it really work out?” Glass says that it always yields two stories in response. “You get ’Here’s how I thought it would go,’ which is one story. And then ’Here’s how the reality is different than the dream of that.’

Excuse me?

This is a common shorthand means to ask for more details. It looks unnatural, but you'll see this a lot in talk show interviews.

"What would you take if you..."

The cliché “What would you want with you if you were stranded on a desert island?” or “What would you grab if you had to evacuate your home quickly?”

The Jeopardy! question

It's been typically used in job interviews. It helps identify what topics are important to the source. It’s “If you were a contestant on Jeopardy!, in what category would you excel?”

How would your life have been different... ?”

It makes the source consider alternatives to how his or her life turned out. It reveals a lot about the person’s personality and interests.

What is your favorite unimportant thing to do?”

This gets your source evaluating several things at once, and it often creates something personal and revealing.

Responding with body language

Eye contact matters.
The occasional “Mm-hmms” and “Uh-huh” are encouragements for your source to keep going. Be mindful if they do not come across as 'interruptions'.
If you you don’t understand what is being said, or you think the source has gone on way too long, use your hands. A shoulder-level, non-threatening "Hold on".
Nod to keep the person going.
Look quizzical if you don’t understand or don’t believe what you’re hearing.
Raise your eyebrows if you are surprised or incredulous.
Shake your head if you’re just not buying it, or you’re amazed.

Being flexible

The author shares a story about how he went to a convention where the speaker of the final gathering was Tony Campolo. He didn't show, and the organizers played dumb, not knowing why the switch occurred. Conveniently, his next assignment was to do a separate story on Tony Campolo involving humanitarian efforts for the people of Haiti.

When the author arrived for the interview, before the small talk, Tony said “I’ll bet you’re here to find out from me why I got disinvited from that big convention in Washington, D.C.”

Tough Questions, not Gotchas

The difficult questions are the ones where you are getting to the heart of the matter. Tough questions don’t have to be mean, embarrassing, inappropriate, or invade anyone’s privacy. The goal is to break them out of their rote responses, giving you some fresh insight, and get to the heart of what is going on.

The goal isn’t to have a “gotcha” moment. A phrase used in journalism is "heat for heat’s sake or heat for light’s sake". The former is just to rile people up. The latter is to bring clarity/understanding to a situation.

You can ask them a few ways:

Ease into it. The author recommends putting tough questions about two-thirds of the way into the interview when there's been enough rapport and the person trues you.
They can be gently introduced with a phrase like “Help me understand something.”
“So-and-so said it happened this way, but you say it happened that way. Can you see how this is confusing?”
I apologize if this next question will sound offensive to you,”

Dealing with challenging Interviewers

The goal of a interview is to reveal the truth.

You don’t have to respond positively or negatively. Your obligation is to remain neutral. You can challenge unsavory statements if it feels relevant.

Interviews should not devolve into shouting matches. People often don't change their behavior because they lost an argument with you. It is always better to ask, listen, respond, guide, ask differently, and probe.

Control is a dynamic involved in virtually every interview, and you must be aware of who has it at all times. Strong personalities or "Media savvy" folks may try to wrest control from you.

Silence is one of the ways to retain control. Silence feels uncomfortable. But your source might be thinking. Or they're hoping you would change the subject.

The author shares a story where a reporter sat with a investigator. For a long period of time, nothing was said. After a long time, the investigator opens up on their own. The reporter later recounted, "I judged right away that he was nervous. I didn’t want to spook him, so I figured he would talk when he was ready."

Wrapping up the Interview

Lead the conversation to the finish line. Giving them a “I have just two more questions.” will let the source knows that you're reaching a conclusion. When I’m done I say something along the lines of “Thank you so much for taking the time!”

Final Takeaways

The takeaways shared are focusing on the interview portion. The book covers the full scope of journalism, including researching, note-taking and follow-ups.

The main takeaway is as it's our obligation as a interviewer to help the source navigate, pull on interesting threads and let them speak on it. Ask the tough questions, but frame it with curiosity.

If you have book recommendations to improve the tech interview, I'd love to hear it in the comments!

The 38 Books Recommended to Me in the Past Few Months

Rocky Kev — Mon, 28 Nov 2022 02:39:14 +0000

Half a year ago, I was bumped from a senior developer to managing a team of developers.
Unfamiliar with navigating this world, I asked around about books to help with that next level.

Rather than keep the list private, I elect to share them here.

These are books I have not read yet.
This is not a ranking list. Just the title + Description.
If it's not listed, I may have read it already.

These are the 38 books I was recommended to me in the past few months.

I took the description from Amazon btw.

Technical Books

A Philosophy of Software Design by John Ousterhout
An Elegant Puzzle: Systems of Engineering Management by Will Larson
Architecture of Open Source Applications by Robert Chansler, Russell Bryant & 8 more
Fundamentals of Software Architecture: An Engineering Approach by Mark Richards Neal Ford
Code Complete (Developer Best Practices) by McConnell Steve
Code That Fits in Your Head : Heuristics for Software Engineering by Mark Seemann
Continuous Delivery: Reliable Software Releases Through Build, Test, and Deployment Automation by Jez Humble, David Farley
Domain Driven Design Distilled by Vaughn Vernon
Domain Modeling Made Functional: Tackle Software Complexity with Domain-Driven Design and F# by Scott Wlaschin
Five Lines of Code: How and When to Refactor by Christian Clausen
Software Engineering at Google: Lessons Learned from Programming Over Time by Titus Winters, Tom Manshreck, Hyrum Wright
Implementing Domain Driven Design by Vaughn Vernon
Learning Domain-Driven Design: Aligning Software Architecture and Business Strategy by Vlad Khononov
Modern Software Engineering by David Farley
Operating Systems: Three Easy Pieces by Remzi H Arpaci-Dusseau, Andrea C Arpaci-Dusseau
Site Reliability Engineering: How Google Runs Production Systems by Niall Richard Murphy, Betsy Beyer, Chris Jones, Jennifer Petoff
Systems Performance by Brendan Gregg
The Architecture of Open Source Applications by Amy Brown, Greg Wilson
The Art of Readable Code: Simple and Practical Techniques for Writing Better Code by Dustin Boswell, Trevor Foucher
The Performance of Open Source Applications by Tavish Armstrong
Web Scalability for Startup Engineers by Artur Ejsmont
Working Effectively with Legacy Code by Michael Feathers

500 Lines or Less Paperback by Amy Brown, Michael DiBernardo

As we pointed out in The Architecture of Open Source Applications, architects look at thousands of buildings during their training, and study the critiques of many more. But most software developers only ever get to know a handful of programs well — usually programs they wrote themselves. This book provides you with the chance to study how 26 experienced programmers think when they are building something new. The programs you will read about in this book were all written from scratch to solve difficult problems. A web server, a pedometer, a Python interpreter, a web-based spreadsheet, and many more applications are written, in 500 lines of code or less, and described by their creators so that you can learn from their insights and their mistakes.

A Philosophy of Software Design by John Ousterhout

This book addresses the topic of software design: how to decompose complex software systems into modules (such as classes and methods) that can be implemented relatively independently. The book first introduces the fundamental problem in software design, which is managing complexity. It then discusses philosophical issues about how to approach the software design process and it presents a collection of design principles to apply during software design. The book also introduces a set of red flags that identify design problems. You can apply the ideas in this book to minimize the complexity of large software systems, so that you can write software more quickly and cheaply.

An Elegant Puzzle: Systems of Engineering Management by Will Larson

"There’s a saying that people don’t leave companies, they leave managers. Management is a key part of any organization, yet the discipline is often self-taught and unstructured. Getting to the good solutions for complex management challenges can make the difference between fulfillment and frustration for teams, and, ultimately, between the success and failure of companies.

Will Larson’s An Elegant Puzzle focuses on the particular challenges of engineering management—from sizing teams to handling technical debt to performing succession planning—and provides a path to the good solutions. Drawing from his experience at Digg, Uber, and Stripe, Larson has developed a thoughtful approach to engineering management for leaders of all levels at companies of all sizes. An Elegant Puzzle balances structured principles and human-centric thinking to help any leader create more effective and rewarding organizations for engineers to thrive in."

Architecture of Open Source Applications by Robert Chansler, Russell Bryant & 8 more

Architects look at thousands of buildings during their training, and study critiques of those buildings written by masters. In contrast, most software developers only ever get to know a handful of large programs well — usually programs they wrote themselves — and never study the great programs of history. As a result, they repeat one another’s mistakes rather than building on one another’s successes. This book’s goal is to change that. In it, the authors of twenty-five open source applications explain how their software is structured, and why. What are each program's major components? How do they interact? And what did their builders learn during their development? In answering these questions, the contributors to this book provide unique insights into how they think.

Fundamentals of Software Architecture: An Engineering Approach by Mark Richards Neal Ford

Salary surveys worldwide regularly place software architect in the top 10 best jobs, yet no real guide exists to help developers become architects. Until now. This book provides the first comprehensive overview of software architecture’s many aspects. Aspiring and existing architects alike will examine architectural characteristics, architectural patterns, component determination, diagramming and presenting architecture, evolutionary architecture, and many other topics.

Mark Richards and Neal Ford—hands-on practitioners who have taught software architecture classes professionally for years—focus on architecture principles that apply across all technology stacks. You’ll explore software architecture in a modern light, taking into account all the innovations of the past decade."

Code Complete (Developer Best Practices) by McConnell Steve

"Widely considered one of the best practical guides to programming, Steve McConnell’s original CODE COMPLETE has been helping developers write better software for more than a decade. Now this classic book has been fully updated and revised with leading-edge practices—and hundreds of new code samples—illustrating the art and science of software construction. Capturing the body of knowledge available from research, academia, and everyday commercial practice, McConnell synthesizes the most effective techniques and must-know principles into clear, pragmatic guidance. No matter what your experience level, development environment, or project size, this book will inform and stimulate your thinking—and help you build the highest quality code.

Code That Fits in Your Head : Heuristics for Software Engineering by Mark Seemann

Reflecting decades of experience helping software teams succeed, Mark Seemann guides you from zero (no code) to deployed features and shows how to maintain a good cruising speed as you add functionality, address cross-cutting concerns, troubleshoot, and optimize. You'll find valuable ideas, practices, and processes for key issues ranging from checklists to teamwork, encapsulation to decomposition, API design to unit testing.

Continuous Delivery: Reliable Software Releases Through Build, Test, and Deployment Automation by Jez Humble, David Farley

This groundbreaking new book sets out the principles and technical practices that enable rapid, incremental delivery of high quality, valuable new functionality to users. Through automation of the build, deployment, and testing process, and improved collaboration between developers, testers, and operations, delivery teams can get changes released in a matter of hours― sometimes even minutes–no matter what the size of a project or the complexity of its code base.

Domain Driven Design Distilled by Vaughn Vernon

Domain-Driven Design (DDD) software modeling delivers powerful results in practice, not just in theory, which is why developers worldwide are rapidly moving to adopt it. Now, for the first time, there’s an accessible guide to the basics of DDD: What it is, what problems it solves, how it works, and how to quickly gain value from it.

Concise, readable, and actionable, Domain-Driven Design Distilled never buries you in detail–it focuses on what you need to know to get results. Vaughn Vernon, author of the best-selling Implementing Domain-Driven Design, draws on his twenty years of experience applying DDD principles to real-world situations. He is uniquely well-qualified to demystify its complexities, illuminate its subtleties, and help you solve the problems you might encounter.

Domain Modeling Made Functional: Tackle Software Complexity with Domain-Driven Design and F# by Scott Wlaschin

You want increased customer satisfaction, faster development cycles, and less wasted work. Domain-driven design (DDD) combined with functional programming is the innovative combo that will get you there. In this pragmatic, down-to-earth guide, you'll see how applying the core principles of functional programming can result in software designs that model real-world requirements both elegantly and concisely - often more so than an object-oriented approach. Practical examples in the open-source F# functional language, and examples from familiar business domains, show you how to apply these techniques to build software that is business-focused, flexible, and high quality.

Domain-driven design is a well-established approach to designing software that ensures that domain experts and developers work together effectively to create high-quality software. This book is the first to combine DDD with techniques from statically typed functional programming. This book is perfect for newcomers to DDD or functional programming - all the techniques you need will be introduced and explained.

Model a complex domain accurately using the F# type system, creating compilable code that is also readable documentation---ensuring that the code and design never get out of sync. Encode business rules in the design so that you have "compile-time unit tests," and eliminate many potential bugs by making illegal states unrepresentable. Assemble a series of small, testable functions into a complete use case, and compose these individual scenarios into a large-scale design. Discover why the combination of functional programming and DDD leads naturally to service-oriented and hexagonal architectures. Finally, create a functional domain model that works with traditional databases, NoSQL, and event stores, and safely expose your domain via a website or API.

Five Lines of Code: How and When to Refactor by Christian Clausen

Five Lines of Code teaches refactoring that's focused on concrete rules and getting any method down to five lines or less! There’s no jargon or tricky automated-testing skills required, just easy guidelines and patterns illustrated by detailed code samples.

Software Engineering at Google: Lessons Learned from Programming Over Time by Titus Winters, Tom Manshreck, Hyrum Wright

Today, software engineers need to know not only how to program effectively but also how to develop proper engineering practices to make their codebase sustainable and healthy. This book emphasizes this difference between programming and software engineering.

How can software engineers manage a living codebase that evolves and responds to changing requirements and demands over the length of its life? Based on their experience at Google, software engineers Titus Winters and Hyrum Wright, along with technical writer Tom Manshreck, present a candid and insightful look at how some of the world’s leading practitioners construct and maintain software. This book covers Google’s unique engineering culture, processes, and tools and how these aspects contribute to the effectiveness of an engineering organization.

Implementing Domain Driven Design by Vaughn Vernon

Implementing Domain-Driven Design presents a top-down approach to understanding domain-driven design (DDD) in a way that fluently connects strategic patterns to fundamental tactical programming tools. Vaughn Vernon couples guided approaches to implementation with modern architectures, highlighting the importance and value of focusing on the business domain while balancing technical considerations.

Building on Eric Evans’ seminal book, Domain-Driven Design, the author presents practical DDD techniques through examples from familiar domains. Each principle is backed up by realistic Java examples–all applicable to C# developers–and all content is tied together by a single case study: the delivery of a large-scale Scrum-based SaaS system for a multitenant environment.

The author takes you far beyond “DDD-lite” approaches that embrace DDD solely as a technical toolset, and shows you how to fully leverage DDD’s “strategic design patterns” using Bounded Context, Context Maps, and the Ubiquitous Language. Using these techniques and examples, you can reduce time to market and improve quality, as you build software that is more flexible, more scalable, and more tightly aligned to business goals.

Learning Domain-Driven Design: Aligning Software Architecture and Business Strategy by Vlad Khononov

"Building software is harder than ever. As a developer, you not only have to chase ever-changing technological trends but also need to understand the business domains behind the software. This practical book provides you with a set of core patterns, principles, and practices for analyzing business domains, understanding business strategy, and, most importantly, aligning software design with its business needs.

Author Vlad Khononov shows you how these practices lead to robust implementation of business logic and help to future-proof software design and architecture. You'll examine the relationship between domain-driven design (DDD) and other methodologies to ensure you make architectural decisions that meet business requirements. You'll also explore the real-life story of implementing DDD in a startup company."

Modern Software Engineering by David Farley

"In Modern Software Engineering, continuous delivery pioneer David Farley helps software professionals think about their work more effectively, manage it more successfully, and genuinely improve the quality of their applications, their lives, and the lives of their colleagues.

Writing for programmers, managers, and technical leads at all levels of experience, Farley illuminates durable principles at the heart of effective software development. He distills the discipline into two core exercises: learning and exploration and managing complexity. For each, he defines principles that can help you improve everything from your mindset to the quality of your code, and describes approaches proven to promote success."

Operating Systems: Three Easy Pieces by Remzi H Arpaci-Dusseau, Andrea C Arpaci-Dusseau

OSTEP ("oh step"), or the "the comet book", represents the culmination of years of teaching intro to operating systems to both undergraduates and graduates at the University of Wisconsin-Madison Computer Sciences department for nearly 20 years.The book is organized around three concepts fundamental to OS construction: virtualization (of CPU and memory), concurrency (locks and condition variables), and persistence (disks, RAIDS, and file systems).The material, if combined with serious project work and homeworks, will lead students to a deeper understanding and appreciation of modern OSes.The authors, Remzi and Andrea Arpaci-Dusseau, are both professors of Computer Sciences at the University of Wisconsin-Madison. They have been doing research in computer systems for over 20 years, working together since their first graduate operating systems class at U.C. Berkeley in 1993.Since that time, they have published over 100 papers on the performance and reliability of many aspects of modern computer systems, with a special focus on file and storage systems. Their work has been recognized with numerous best-paper awards, and some of their innovations can be found in the Linux and BSD operating systems today.

Site Reliability Engineering: How Google Runs Production Systems by Niall Richard Murphy, Betsy Beyer, Chris Jones, Jennifer Petoff

At most technology companies, you'll reach Senior software engineer, the career level for software engineers, in five to eight years. At the career level, your company's career ladder won't require that you work towards the next promotion; being promoted further is an exception rather than expected. This is also when many engineers are first given an opportunity to move into engineering management. Over the past few years, we've seen a flurry of books unlocking the engineering management career path, like Camille Fournier's The Manager's Path, Julie Zhuo's The Making of a Manager, Lara Hogan's Resilient Management, and even my own An Elegant Puzzle. The engineering management career isn't an easy one, but there are maps available to help navigate it. What if you want to advance your career without becoming an engineering manager? The technical leadership path remains relatively undocumented, hard to navigate, and inconsistent across companies. Staff Engineer is your guide to building your career towards a Staff engineering role, receiving the title, and succeeding within the role.

Systems Performance by Brendan Gregg

Systems Performance, Second Edition, covers concepts, strategy, tools, and tuning for operating systems and applications, using Linux-based operating systems as the primary example. A deep understanding of these tools and techniques is critical for developers today. Implementing the strategies described in this thoroughly revised and updated edition can lead to a better end-user experience and lower costs, especially for cloud computing environments that charge by the OS instance.

Systems performance expert and best-selling author Brendan Gregg summarizes relevant operating system, hardware, and application theory to quickly get professionals up to speed even if they have never analyzed performance before. Gregg then provides in-depth explanations of the latest tools and techniques, including extended BPF, and shows how to get the most out of cloud, web, and large-scale enterprise systems.

The Architecture of Open Source Applications by Amy Brown, Greg Wilson

Architects look at thousands of buildings during their training, and study critiques of those buildings written by masters. In contrast, most software developers only ever get to know a handful of large programs well — usually programs they wrote themselves — and never study the great programs of history. As a result, they repeat one another’s mistakes rather than building on one another’s successes. This book’s goal is to change that. In it, the authors of twenty-five open source applications explain how their software is structured, and why. What are each program's major components? How do they interact? And what did their builders learn during their development? In answering these questions, the contributors to this book provide unique insights into how they think.

The Art of Readable Code: Simple and Practical Techniques for Writing Better Code by Dustin Boswell, Trevor Foucher

As programmers, we’ve all seen source code that’s so ugly and buggy it makes our brain ache. Over the past five years, authors Dustin Boswell and Trevor Foucher have analyzed hundreds of examples of "bad code" (much of it their own) to determine why they’re bad and how they could be improved. Their conclusion? You need to write code that minimizes the time it would take someone else to understand it—even if that someone else is you.

This book focuses on basic principles and practical techniques you can apply every time you write code. Using easy-to-digest code examples from different languages, each chapter dives into a different aspect of coding, and demonstrates how you can make your code easy to understand.

The Performance of Open Source Applications by Tavish Armstrong

In 1974, Donald Knuth wrote, "We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil." With computers available now that are millions of times faster than those available then, today's programmers have even less reason to worry about shaving cycles and saving bytes than those a generation ago. But "less" isn't "none": every once in a while, squeezing the last ounce of performance out of the machine really does matter.

This book is written by over a dozen developers who have grappled with slow code, memory leaks, or uncontrollable latency in open source software. They share their mistakes and successes, and give the reader an over-the-shoulder view of how they approached their specific challenges. With examples from bioinformatics research code to web browsers, the solutions are as varied as the problems.

This book will help junior and senior developers alike understand how their colleagues think about performance.

Web Scalability for Startup Engineers by Artur Ejsmont

Web Scalability for Startup Engineers shows engineers working at startups and small companies how to plan and implement a comprehensive scalability strategy. It presents broad and holistic view of infrastructure and architecture of a scalable web application. Successful startups often face the challenge of scalability, and the core concepts driving a scalable architecture are language and platform agnostic.

The book covers scalability of HTTP-based systems (websites, REST APIs, SaaS, and mobile application backends), starting with a high-level perspective before taking a deep dive into common challenges and issues. This approach builds a holistic view of the problem, helping you see the big picture, and then introduces different technologies and best practices for solving the problem at hand. The book is enriched with the author's real-world experience and expert advice, saving you precious time and effort by learning from others' mistakes and successes.

Working Effectively with Legacy Code by Michael Feathers

This book provides programmers with the ability to cost effectively handlecommon legacy code problems without having to go through the hugelyexpensive task of rewriting all existing code. It describes a series of practicalstrategies that developers can employ to bring their existing softwareapplications under control. The author provides useful guidance about how touse these strategies when refactoring or making functional changes to codebases. One of the book's key points is that it teaches developers to write teststhat can be used to make sure they are not unintentionally changing theapplication as they optimize it. Examples are provided in Java, C++, and Csharp,and the book assumes that the reader has some knowledge of UMLnotation. Strategies using UML and code in C++ and Java primarily whilelanguage independent advice will be delivered in side bars and appendices forlanguage specific users.

Management Books

Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations by Nicole Forsgren PhD, Jez Humble, Gene Kim
RESILIENT MANAGEMENT by Lara Hogan
Peopleware: Productive Projects and Teams by DeMarco Tom, Lister Tim
Psychology of computer programming Paperback by mr. Gerald m Weinberg
Radical Candor: Be a Kick-Ass Boss Without Losing Your Humanity by Kim Scott
The Software Architect Elevator: Redefining the Architect's Role in the Digital Enterprise by Gregor Hohpe
Staff Engineer: Leadership beyond the management track by Will Larson
Team Topologies: Organizing Business and Technology Teams for Fast Flow by Matthew Skelton, Manuel Pais
The Making of a Manager: What to Do When Everyone Looks to You by Julie Zhuo
The Staff Engineer's Path by Tanya Reilly
Grokking Simplicity: Taming complex software with functional thinking by Eric Normand
Rapid Development: Taming Wild Software Schedules by Steve McConnell
Waltzing With Bears: Managing Risk on Software Projects by Tom DeMarco, Timothy Lister
Release It!: Design and Deploy Production-Ready Software by Michael T. Nygard
The Art of Doing Science and Engineering: Learning to Learn by Richard W. Hamming

Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations by Nicole Forsgren PhD, Jez Humble, Gene Kim

How can we apply technology to drive business value? For years, we've been told that the performance of software delivery teams doesn't matter―that it can't provide a competitive advantage to our companies. Through four years of groundbreaking research to include data collected from the State of DevOps reports conducted with Puppet, Dr. Nicole Forsgren, Jez Humble, and Gene Kim set out to find a way to measure software delivery performance―and what drives it―using rigorous statistical methods. This book presents both the findings and the science behind that research, making the information accessible for readers to apply in their own organizations.
Readers will discover how to measure the performance of their teams, and what capabilities they should invest in to drive higher performance. This book is ideal for management at every level.

RESILIENT MANAGEMENT by Lara Hogan

Finding your bearings as a manager can feel overwhelming—but you don’t have to fake it to make it, and you don’t have to go it alone. Lara Hogan shares her recipe for supporting and leading a tech team—from developing your mentoring and coaching skills, to getting comfortable with having difficult conversations, to boosting trust among teammates—while staying grounded along the way.

Peopleware: Productive Projects and Teams by DeMarco Tom, Lister Tim

Few books in computing have had as profound an influence on software management as Peopleware. The unique insight of this longtime best seller is that the major issues of software development are human, not technical. They’re not easy issues; but solve them, and you’ll maximize your chances of success.

Psychology of computer programming Paperback by mr. Gerald m Weinberg

This book has only one major purpose-to trigger the beginning of a new field of study: computer programming as a human activity, or, in short, the psychology of computer programming. All other goals are subservient to that one. For instance, I have tried to make the book interesting and nontechnical, insofar as is possible, so as to encourage the greatest number of people to read it: not just programmers, but programming managers and others connected with programming in the many ways we are connected with programming these days. What I am trying to accomplish is to have the reader say, upon finishing the book, "Yes, programming is not just a matter of hardware and software. I shall have to look at things in a new way from now on."

Radical Candor: Be a Kick-Ass Boss Without Losing Your Humanity by Kim Scott

Radical Candor has been embraced around the world by leaders of every stripe at companies of all sizes. Now a cultural touchstone, the concept has come to be applied to a wide range of human relationships.

The idea is simple: You don't have to choose between being a pushover and a jerk. Using Radical Candor—avoiding the perils of Obnoxious Aggression, Manipulative Insincerity, and Ruinous Empathy—you can be kind and clear at the same time.

Kim Scott was a highly successful leader at Google before decamping to Apple, where she developed and taught a management class. Since the original publication of Radical Candor in 2017, Scott has earned international fame with her vital approach to effective leadership and co-founded the Radical Candor executive education company, which helps companies put the book's philosophy into practice.

Radical Candor is about caring personally and challenging directly, about soliciting criticism to improve your leadership and also providing guidance that helps others grow. It focuses on praise but doesn't shy away from criticism—to help you love your work and the people you work with."

The Software Architect Elevator: Redefining the Architect's Role in the Digital Enterprise by Gregor Hohpe

As the digital economy changes the rules of the game for enterprises, the role of software and IT architects is also transforming. Rather than focus on technical decisions alone, architects and senior technologists need to combine organizational and technical knowledge to effect change in their company’s structure and processes. To accomplish that, they need to connect the IT engine room to the penthouse, where the business strategy is defined.

In this guide, author Gregor Hohpe shares real-world advice and hard-learned lessons from actual IT transformations. His anecdotes help architects, senior developers, and other IT professionals prepare for a more complex but rewarding role in the enterprise.

Staff Engineer: Leadership beyond the management track by Will Larson

At most technology companies, you'll reach Senior software engineer, the career level for software engineers, in five to eight years. At the career level, your company's career ladder won't require that you work towards the next promotion; being promoted further is an exception rather than expected. This is also when many engineers are first given an opportunity to move into engineering management. Over the past few years, we've seen a flurry of books unlocking the engineering management career path, like Camille Fournier's The Manager's Path, Julie Zhuo's The Making of a Manager, Lara Hogan's Resilient Management, and even my own An Elegant Puzzle. The engineering management career isn't an easy one, but there are maps available to help navigate it. What if you want to advance your career without becoming an engineering manager? The technical leadership path remains relatively undocumented, hard to navigate, and inconsistent across companies. Staff Engineer is your guide to building your career towards a Staff engineering role, receiving the title, and succeeding within the role.

Team Topologies: Organizing Business and Technology Teams for Fast Flow by Matthew Skelton, Manuel Pais

Effective software teams are essential for any organization to deliver value continuously and sustainably. But how do you build the best team organization for your specific goals, culture, and needs?

Team Topologies is a practical, step-by-step, adaptive model for organizational design and team interaction based on four fundamental team types and three team interaction patterns. It is a model that treats teams as the fundamental means of delivery, where team structures and communication pathways are able to evolve with technological and organizational maturity.

In Team Topologies, IT consultants Matthew Skelton and Manuel Pais share secrets of successful team patterns and interactions to help readers choose and evolve the right team patterns for their organization, making sure to keep the software healthy and optimize value streams.

Team Topologies is a major step forward in organizational design for software, presenting a well-defined way for teams to interact and interrelate that helps make the resulting software architecture clearer and more sustainable, turning inter-team problems into valuable signals for the self-steering organization.

The Making of a Manager: What to Do When Everyone Looks to You by Julie Zhuo

Congratulations, you're a manager! After you pop the champagne, accept the shiny new title, and step into this thrilling next chapter of your career, the truth descends like a fog: You don't really know what you're doing.

That's exactly how Julie Zhuo felt when she became a rookie manager at the age of 25. She stared at a long list of logistics - from hiring to firing, from meeting to messaging, from planning to pitching - and faced a thousand questions and uncertainties. How was she supposed to spin teamwork into value? How could she be a good steward of her reports' careers? What was the secret to leading with confidence in new and unexpected situations?

Now, having managed dozens of teams spanning tens to hundreds of people, Julie knows the most important lesson of all: Great managers are made, not born. If you care enough to be reading this, then you care enough to be a great manager. "

The Manager's Path: A Guide for Tech Leaders Navigating Growth and Change by Camille Fournier

Managing people is difficult wherever you work. But in the tech industry, where management is also a technical discipline, the learning curve can be brutal - especially when there are few tools, texts, and frameworks to help you. In this practical guide, author Camille Fournier (tech lead turned CTO) takes you through each stage in the journey from engineer to technical manager.

From mentoring interns to working with senior staff, you'll get actionable advice for approaching various obstacles in your path. This book is ideal whether you're a new manager, a mentor, or a more experienced leader looking for fresh advice. Listen to this audiobook and learn how to become a better manager and leader in your organization.

The Staff Engineer's Path by Tanya Reilly

For years, companies have rewarded their most effective engineers with management positions. But treating management as the default path for an engineer with leadership ability doesn't serve the industry well--or the engineer. The staff engineer's path allows engineers to contribute at a high level as role models, driving big projects, determining technical strategy, and raising everyone's skills.

This in-depth book shows you how to understand your role, manage your time, master strategic thinking, and set the standard for technical work. You'll read about how to be a leader without direct authority, how to plan ahead to make the right technical decisions, and how to make everyone around you better, while still growing as an expert in your domain.

Grokking Simplicity: Taming complex software with functional thinking by Eric Normand

Distributed across servers, difficult to test, and resistant to modification - modern software is complex. Grokking Simplicity is a friendly, practical guide that will change the way you approach software design and development. It introduces a unique approach to functional programming that explains why certain features of software are prone to complexity, and teaches you the functional techniques you can use to simplify these systems so that they’re easier to test and debug.

Rapid Development: Taming Wild Software Schedules by Steve McConnell

Corporate and commercial software-development teams all want solutions for one important problem―how to get their high-pressure development schedules under control. In RAPID DEVELOPMENT, author Steve McConnell addresses that concern head-on with overall strategies, specific best practices, and valuable tips that help shrink and control development schedules and keep projects moving.

Waltzing With Bears: Managing Risk on Software Projects by Tom DeMarco, Timothy Lister

Any software project that's worth starting will be vulnerable to risk. Since greater risks bring greater rewards, a company that runs away from risk will soon find itself lagging behind its more adventurous competition. By ignoring the threat of negative outcomes—in the name of positive thinking or a Can-Do attitude—software managers drive their organizations into the ground.

In Waltzing with Bears, Tom DeMarco and Timothy Lister—the best-selling authors of Peopleware—show readers how to identify and embrace worthwhile risks. Developers are then set free to push the limits.

Release It!: Design and Deploy Production-Ready Software by Michael T. Nygard

A single dramatic software failure can cost a company millions of dollars - but can be avoided with simple changes to design and architecture. This new edition of the best-selling industry standard shows you how to create systems that run longer, with fewer failures, and recover better when bad things happen. New coverage includes DevOps, microservices, and cloud-native architecture. Stability antipatterns have grown to include systemic problems in large-scale systems. This is a must-have pragmatic guide to engineering for production systems.

If you're a software developer, and you don't want to get alerts every night for the rest of your life, help is here. With a combination of case studies about huge losses - lost revenue, lost reputation, lost time, lost opportunity - and practical, down-to-earth advice that was all gained through painful experience, this book helps you avoid the pitfalls that cost companies millions of dollars in downtime and reputation. Eighty percent of project life-cycle cost is in production, yet few books address this topic.

This updated edition deals with the production of today's systems - larger, more complex, and heavily virtualized - and includes information on chaos engineering, the discipline of applying randomness and deliberate stress to reveal systematic problems. Build systems that survive the real world, avoid downtime, implement zero-downtime upgrades and continuous delivery, and make cloud-native applications resilient. Examine ways to architect, design, and build software - particularly distributed systems - that stands up to the typhoon winds of a flash mob, a Slashdotting, or a link on Reddit. Take a hard look at software that failed the test and find ways to make sure your software survives.

The Art of Doing Science and Engineering: Learning to Learn by Richard W. Hamming

What inspires and spurs on a great idea? Can we train ourselves to think in a way that will enable world-changing understandings and insights to emerge?

Richard Hamming said we can. He first inspired a generation of engineers, scientists, and researchers in 1986 with “You and Your Research,” an electrifying sermon on why some scientists do great work, why most don’t, why he did, and why you can—and should—too. The Art of Doing Science and Engineering is the full expression of what “You and Your Research” outlined. It's a book about thinking; more specifically, a style of thinking by which great ideas are conceived.

The book is filled with stories of great people performing mighty deeds—but they are not meant simply to be admired. Instead, they are to be aspired to, learned from, and surpassed. Hamming consistently returns to Shannon’s information theory, Einstein’s theory of relativity, Grace Hopper’s work on high-level programming, Kaiser’s work on digital fillers, and his own work on error-correcting codes. He also recounts a number of his spectacular failures as clear examples of what to avoid.

From Dev to Leading: How I Trained New Hires

Rocky Kev — Sun, 12 Jun 2022 22:47:52 +0000

It's officially been more than a month since new hires joined my team, and I'm proud to say they've been pretty successfully onboarded.

A few months ago, I shifted from Wizbang Codemonkey to Lead Cat Wrangler (non-official titles obviously). My team went from six devs to thirteen in less than a year. And I would be in charge of managing a brand new team, as WELL as all the new hires. The Peter Principle is always a concern. (tl;dr - you get promoted up and up until you fail.)

The business went, "Like your new team? Btw, here are 4 new hires. A junior, 2 mid-levels, and a senior. Okay byeeeeeee!"

How does this feel? Jim Gaffigan said it best.

It took me a while to see this perspective. As a developer, in a nutshell - our job is to solve problems, but with code. We create a set of processes (a system) and run down the list. We pivot as you discover new problems. We keep working until the hit the finish line.

4 new hires at multiple levels of experience? This is just a new problem! Life is defined by the challenges you face. And I got this! 💪

This post will cover the 5 Principles I followed. I hope it's educational. And if 10... 20... 100 devs are thrown at me, this process continues to scale.

What do new hires think about?

Tech interviews are a 💩-show. So no surprise that new hires have a lot of unknowns. For example: Where do I go to get questions answered? Who is this person? What is this tech stack? What is this in-house term? Am I doing this right?

I wrote the full list in my post: What New Hires think about

As a Lead Cat Wrangler and a person in power (I can choose the toppings for the lunch pizza!) - do I continue contributing to the 'Sink-or-Swim' methodology that plagues many companies in the tech industry?

Or do I continue expanding on the dope culture that I want through onboarding, nurturing, and growth?

The Principles of managing new hires successfully

In the book "Principles", the author Ray Dalio, lays down a framework based on the unique company culture he developed while running Bridgewater Associates.

I like the term "Principles". These aren't facts or laws. They're systems that with practice, can lead to success. They might require some rejiggering from company to company. But they can fit into any training system. For example, the burpee is considered one of the best exercises to incorporate. Use it separately, put it in a routine, or remix it into some P90x, and it still works!

This post is a retrospect of the principles I followed to achieve the following:

Train four new hires (junior, 2 mid-level, and a senior dev)
Build up a new team with some new rituals
Manage chaos and new business objectives
Pretend like I'm in control and not secretly wanting to hide under my desk until the pain stops
Avoid hating programming (like what happened 15+ years ago)

Via Sarah Andersen

I'm fortunate enough to have a background in a lot of different companies/onboarding styles, and working in the online education space. So these principles come from theories in higher education, executive coaching, and personal development.

Principle 1: Eliminate Bottlenecks, Including You

As Wizbang Codemonkey, I was thrown into the sun and told to come back with fire. (Call me Prometheus because I bring back the 🔥🔥🔥)

As a new Lead Cat Wrangler, I can't solve problems, manage every new problem, AND teach new hires. The industry is paved with the bones of burned-out developers who think only they can solve everything.

I had to trust people to solve problems without me.

You might say, "But only I can solve that problem!"

Why is that?

To successfully cat wrangle, I need to create processes where I can offload work quickly and trust that the developer in charge has everything they need to close that loop.

Sakichi Toyoda, the founder of Toyota Motor Company and the father of Japanese Industrialization, created the 5 Whys system for Root Cause Analysis. You keep asking 'why' the problem even occurred.

If I'm the only one who can solve a specific problem, then what needs to happen where I'm not the bottleneck?

As a dev example: if you modify one data point, and it creates side effects somewhere else? Your system is too tightly coupled! If I get sick for two days, I should not crash the system.

One solution is to provide enough documentation and code examples to get progress going. (Check out Principle 3 & 4)

Other times, the solution is to isolate the hard parts. Break tickets into pieces - some for new hires, and some for specialists.

Additionally, trust goes both ways. Code may not be how you would have solved it. But then you're being a dependency again, which is a recipe for disaster. Perfect is the enemy of the good. (And you can ALWAYS make refactor tickets to clean things up in the future and make it part of your todos. Check out How to convince your boss to refactor.)

FURTHER READING

Beware the One-person team via EffectiveEngineer
The Reality of Dev Burnout via BetterProgramming
Decouple your code via Mindsers Blog
The Goal and The Phoenix project (Book recommendations)

Principles 2: Organize or Die ☠️

The rules of Maker Time Vs Manager Time are pretty simple. Managers do work by going into meetings. Makers need uninterrupted time to focus. A quick "hey you busy?" can cost a developer 23 minutes and 15 seconds just to get back to where they left off (But whos counting amirite?)

(image via https://blog.doist.com/makers-schedule-remote-work/)

As Wizbang Codemonkey, I can do long uninterrupted periods to focus on solving a technical issue.

As a new Lead Cat Wrangler, I get emails and DMs from project managers, all day ev'ry day.

Looks like Maker Time no longer apply to me. :-(

I approached this by:

1) Still have a maker mindset. I still timebox. Nobody talks to me during these hours.
2) Dedicated times for support. Treat it like college Open Office hours. I don't respond immediately unless I have to.
3) Relying on checklists. Remember when ego-centric surgeons refused to use checklists, but the ones that did reduced death by 40%?
4) Never trusting my memory. Everything becomes a note to review or a to-do to take action on. What gets written gets done.

As new business expectations occurred, I moved my calendar around.

As the new hires needed less support, I decreased my 'helping' time.

As new patterns arose, I updated my checklist.

If I ever dropped the ball, I make a mini-retrospective of why that happened and generate plans to mitigate that, and focus on continuous improvement.

This system isn't perfect. It continues to evolve.

FURTHER READING

How Timeboxing works and Stop Letting email control your workday by Haravard Business Review
How to organize and get things done With Workflowy, with Mindmaps, With Notion
Kaizen Project Management and The Power of 1% gains

Principle 3: Provide many mechanisms for growth

Everyone learns differently. It's why we have so many different teaching styles.

My team of devs are big on being learners. It's why I encourage my team to buy courses and dedicate time to studying at least once a month. For the managers who don't dedicate resources to studying: What if we train them and they leave? What if you don't and they stayed?

Empowerment through learning and growth

The 4 new hires are: a junior, 2 mid-levels, and a senior.

Imagine being in a classroom teaching Lego crafting of different skillsets.

To the Junior -> "Good job! This combination of random blocks does look like a house! Great job!"
To the senior -> "Your Millenial Falcon is supposed to use Round 2x2 Bricks, not Round Corner 2x2s! What do they teach you in Lego school?!"

In other words, skill level affects how you teach new hires. In education, academic boredom or over-complexity can lead to bad learning outcomes. This leads to a Goldilocks principle of "just right". But "just right" doesn't scale!

The added confusion:
In the web dev industry, I have met a lot of devs with a decade in the industry, but 1-year of experience 10 times. You know, the ones who built websites since the late 2000s but still use floats. The ones who never went deep in their architecture and still zip files as source control. The ones who gave my company bad reviews on Glassdoor because they refused to continue their education and Bootcamp students have more modern development skills than they do. And no IM NOT BITTER THANKS FOR ASKING.

Additionally - job titles such as junior, mid-level, and senior are kinda meaningless to training.

In the book Pragmatic Programmers, the authors Andrew Hunt and David Thomas reuse the Dreyfus Model for how developers at different stages of their skillset prefer to learn.

Stage 1 - Novices:

ACTION: Novices need recipes.

Tell them how to do things. Novices are very concerned about succeeding. They don't want to learn everything, they want to accomplish their immediate goal.

Stage 2 - Advanced Beginners:

ACTION: Advanced beginners don't want the big picture.

They have some confidence to do things on their own and can start using the advice in the correct context. But they don't want lengthy theories or be spoon-fed the basics again.

(Via ResearchGate)

Stage 3 - Competents:

ACTION: Competents can troubleshoot.

They can troubleshoot problems on their own, and figure out solutions to modern problems. They are more deliberate about their planning. They're seen as 'having initiative' and 'being resourceful', and can mentor earlier stages without pulling bandwidth from experts.

Stage 4 - Proficients:

ACTION: Proficient practitioners can self-correct.

They need the big picture and will seek out and understand the entire framework. They read case studies/projects/patterns and can learn effectively from history, even if they didn't participate in it firsthand. They are very frustrated by oversimplified information.

They know how to use maxims: "Test everything that can possibly break."

Novices see this as a recipe and go, "What do I test? All the setters/getters? All the return statements?" and test everything. Proficient practitioners know to only test the core components that can cause an issue.

Stage 5 - Expert:

ACTION: Experts work from intuition.

They are the primary source of information. They write articles and books. They can diagram an application and go a mile deep into its architecture. Statistically speaking, roughly 1-5% of the population.

Using that framework, our tasks are written in a way where tickets are grouped into one of those categories. It allows us to provide meaningful work during the different stages of learning.

Collaborative learning and growth

Be mindful. Be empathetic. Remember their learning style. Have an open-door policy to allow them to ask questions, no matter how dumb it sounds.

For learning to scale, my team has these support systems.

Support System 1: We have chat channels specifically for asking questions. Even the more experienced devs ask questions, to facilitate an environment where we're all growing.

Support System 2: We have a collective knowledge base that anyone can edit.

Support System 3: We modify learning based on the needs of the new hire.

Some learn with peer programming/shadowing.
Some learn with pseudocode.
Some learn by giving hints. Give them the boundaries.
Some learn by pointing to documentation & example code.
Some learn by building a separate project using an online course.
Some learn by teaching it to others.

No one-size-fits-all. And there are different modes of learning depending on the task.

For example, using myself:
With design work, pseudocode all the way! But please let me shadow you when we're doing backend database work. And just give me documentation if I'm working on APIs. DIfferent modes for different tasks.

Support System 4: We spend a lot of time course-correcting

At the end of the day -- everything ends up in Code Review.

There's ego in coding. Not everyone takes feedback well at all. New hires are often following the patterns they had in their prior life and in unfamiliar territory, and defend themselves of why they chose that and why you're wrong.

At my company, we have the luxury of time. New hires get used to LONG code review times. Some PRs can sit in code review for a week. It's a point of frustration for new hires who come from website firms where you can quick-and-dirty !important everything and ship that code.

Not here! We will take the time to do it right. And we'll be extra supportive and polite about it. (And if the ticket is time-sensitive, is it a good ticket for new hires?)

FURTHER READING

How to make Good Code Reviews even better
Learning How to Learn (Book Recommendation)
Pragmatic Programmers, The Mythical Man-month, and Peopleware: Productive Projects and Teams (Book Recommendation)

Principle 4: Providing Doable work

One of the fears of new hires is if they're doing something correctly. That paralysis slows down growth and makes PRs take 300% longer.

And if they aren't doing it correctly, the new hire's confidence is shattered! They feel miserable. They feel insecure. Imposter syndrome creeps, and they go into The Valley of Despair.

Image via TBD-stategies

Creating "Doable work" means the following:

Tasks that are within their skillset
Tasks that are meaningful, that feel like real contributions. (I was given 10 'fix the typo' tasks and I wanted to crawl inside a shark.)
Tasks that have a well-defined scope of expectations
Tasks with a history of success

Tagging tasks as "Good First Issue"

One solution that the Open source community created is tagging tickets as Good First Issue. The issue isn't easy. But it's a simple task to allow someone new to be able to learn the system, the culture, and the feedback.

In these specially tagged tickets, the scope is well defined, and there's also a history of success. Included in the task are completed PRs that do the same/something similar to reference for help. A new hire can review the PR and look at the feedback and comments, and attempt to understand how and why.

I also encourage more seasoned developers to LOOK and tag opportunities that can be good for first-timers. Great developers know when to solve a problem themselves vs allowing others to shine!

Overall, these Good First Issue tickets give new hires small wins. And small wins make big wins.

Buffet-style selection for picking tasks

The common methodology at workplaces is to micro-manage your new hires until they ~~conform and become a goopy gray matter~~ meet your definition of success. You let them do some shadowing, force them into meetings and peer coding, and ask them questions like "Do you know how to copy/paste?" to "How can we use prototypical inheritance instead of creating thousands of functions?".

Not wanting to deal with that micro-management noise... my team elected to treat our tickets 'buffet-style'.

Overall, we provide dozens of tickets up for grabs.

Novice tickets that have a clear step-by-step. Do X, then Y, then Z.
Advance Beginner tickets that are a bit vaguer, but a lot of patterns to imitate. I treat these tickets like a puzzle game. Here's the end goal, and here are some hints!
Competent tickets are free-flowing! I rely on the developer to tell ME how they plan to solve it.

If the mid-levels want to tackle novice tickets? Sure! If the junior wants to take complex tickets, I'll back them up, and give them an out if it's too much pressure.

Concerned that the higher role devs will take novice tickets ? You shouldn't be! The goal isn't to complete the ticket -- it's to get comfortable in the company. Just like in Final Fantasy, we need to get to 100% before we can use our Limit Breaks/Overdrives.

New tasks that have never been done before? The solution: Create a safe sandbox, but with restrictions. Maybe the task needs to be broken into multiple tiers (some novice, some competent, some expert-level tickets) and you handle the complex ones. The tickets are still clearly defined, there's a scope to stay within, and define restrictions to avoid going too deep into the rabbit hole.

Note: restrictions do create stress. But stress isn't the root of evil. There's good stress and bad stress. Avoiding stress is a bit like helicopter parenting - it can cause more damage then it saves.

FURTHER READING

Writing SMART goals
Open-Source Good First Issues
How to write a good answer via StackOverflow
Drive: The Surprising Truth About What Motivates Us (Book Recommendation)

Principle 5: Frequent Check-ins

(Note: This is the Principle I personally need the most work on. I'm data-driven, and would prefer to throw technology like 15Five at this. But I can't.)

All developers need to be empowered that we trust their ideas and feel ownership of the code. But developers are also very good at getting into rabbit holes and can't see the forest from the trees.

Checking in too frequently and they won't feel confident in solving problems (Breaking Principle 1). If you let them go on their own too long, they can go into a spiral (breaking Principle 4)

Unfortunately, I don't have a direct answer here.

I have multiple touch-points to see how the new hire is doing.

We work remotely. Which means I can't just hover over their shoulder.

Check-in during Standups: I'm guilty of using standup as a place to practice my comedy bits, very Michael Scott-esque. But new hires do open up and share their blockers!
I reach out asynchronously through chat/email for a quick update.
I do 'temperature checks' by asking others. "Is [X developer] doing okay?"

I constantly test my check-in methods. My check-ins are now a bit focused, with a lot of vagueness (oxymoron!). I ask these basic questions to break the ice:

How is everything? -> Some share their day. Others share their immediate feelings.
What are you blocked by? -> They share what they're working on. Or if they're stuck, they try to explain how.
How can I help? -> This simple powerful phrase empowers the new hire to think through exactly what they need.

FURTHER READING

These Principles aren't just for new hires

Although these principles were geared toward scaling onboarding new hires, I discovered they made me a better developer/leader.

Principle 1: Eliminate bottlenecks, including you has allowed me to identify what's important to me and find as many ways to remove myself from being a dependency.

Principle 2: Organize or die forced me to choose my time wisely. Burnout is a real thing.

Principle 3: Provide many mechanisms for growth made me think about my learning styles. I'm figuring this out as a cat wrangler! I went through my own Valley of Despair, and have climbed out of it.

Principle 4: Providing Doable work forced me to think about clear expectations and scope in words. I messed up a LOT on this task, and my support team continued providing feedback.

Principle 5: Frequent Check-ins elevated me out of a 'thinking about myself' to a 'think about the people who need me'.

As developers, we're here to solve problems using systems and patterns.

And scaling new hires is just another problem to solve.

What New Hires think about

Rocky Kev — Sun, 12 Jun 2022 19:11:27 +0000

This post was originally written in May 2022 on my defunct blog. Moved it here.)

Shoshin.

It's a concept in Zen Buddhism, which means "beginner's mind".

The concept of cycles/returning back to the beginning is prevalent in Eastern Philosophy. In Martial Arts, well-worn black belts sheds back to white. There's the cycle of rebirth. In the dev industry - switching jobs is a new cycle.

That perspective (and that empathy) is important, especially for new hires.

My team grows from 6 devs to more than a dozen! And I hear the chatters of hazing new hires (😡), talking down to them (😡), or not even taking the time to think about their perspective.

New hires come in with a lot of unknowns. They also don't have psychological safety to open up.

As one of the cat wranglers bringing in these new hires, I reflect on Shoshin to help me see things from their perspective. (Heck, it took me 15 years to get here)

This is what I've come up with.

Things new hires thing about:

Not knowing where to go for help. Is it the culture to reach out to the whole team? Should I DM someone privately? Or should I just 'read the documentation'?
Who/what is a [WORD HERE]? Every company has their in-house terms. From Gazorpazorps to chumps. What does any of it mean?
Org Chart A decade ago, I once emailed a CEO to tell them that the bathroom was broken. I wish I knew who the right person was.
Who is responsible for what? Small companies, devs deal with everything. Big companies have clear lines of responsibility. That website footer, is that my team? Is that your team?
Culture and environment. What type of people work here? Can I throw a Parks and Rec reference? Am I in a workspace with casette tapes, or CDs, or Spotify?

Things new hires go through:

The Emotional Cycle of Change. The Emotional Cycle of Change is used to explain learning, and also applies here. When new hires join a company, they're in the Uniformed Optimism stage (a honeymoon phase). That honeymoon phase disappears, and things get harder. Soon, they drop into the Valley of Despair. Everything sucks. All the time. Can we create processes to allow our new hires to cross this bridge quickly?
When 💩 hits the fans - the Unknown unknowns. Every company has a period where chaos reigns. It's inevitable. New hires have to wonder, "When will the other shoe drop? What will happen to me?" Will a weak leader become power hungry and fire everyone who disagrees with them? What culture can we create to mitigate that fear?
Am I doing this right?" This question that will be asked for months. About everything! From little details like code style or formatting, to 'am I allowed to use this library?' It takes months for new hires to gain the confidence to draw outside the lines.
Am I safe to even ask questions? This is the question new hires rarely openly express. "Is everyone a phoney and secretly judging me?" I talk about Psychological Safety in my workplace here.

What do we do with this

Whatever annoyances and frustrations you snagged on during your on-boarding, stamp them out! Can't remember? Adopt the beginner's mindset with Shoshin. Gain some empathy, take a step back, and think about how you can smooth out your onboarding of new hires.

Be better in the world.

Solving a 2002 website issue with web components

Rocky Kev — Tue, 07 Jun 2022 03:53:12 +0000

(This post was originally written in Mid-may 2022 on my defunct blog. Moved it here.)

My team inherited a site that was written in asp.net and vanilla HTML/CSS/JS.

There was roughly 100+ .html files. And the stakeholder wanted the site moved off of an old microsoft server.

I'm sure this site is from like 2002 or something (I don't exactly know).

This was a super quick task. And from the looks of it's age, we just wanted to get it done quickly.

The Problem

These .html files were fascinating!

All 100+ files sort look something like this:

<body>
<!-- asp.net code here for navigation -->

<div class="content"> ... </div>

<!-- asp.net code here for footer -->
</body>

I don't know asp.net. My hypothesis was that the original site used asp.net to pull a navigation file and a footer file for all of their pages.

All I know is that the asp.net code didn't work when we tested it on a new server. So we needed a way to get the nav/footer back.

Honestly, it seems pretty sweet that the snippet of code allowed for DRY-ness.

Different ways to solve it

Idea 1: We can roll up a JS framework.

The snippet of code? What does that remind you of? That's right -- Components!

I can quickly create-react-app or vue-create and build out a header/footer component. Should take like 30 minutes.

Problems with that approach

Issue 1 - It'll leave a trail of dependancies. Like I said, this site is OLD. It's older than my career! Some developer in 2040 will be cursing my name if I used

Issue 2 - The entire payload of this site is like 20kb. According to this gist, all the frameworks would literally double the size of this page. (Except Preact! Wow, look at that file size!)

(This screenshot is 61kb.)

Is there a way to avoid that overhead?

Idea 2: Quick and dirty

Why not just copy the html for the navbar and footer, and paste it where asp.net code was?

<body>
<!-- asp.net code for header is now replaced -->
<nav><ul class="menu">... </ul></nav>

<div class="content"> ... </div>

<!-- asp.net code for footer is now replaced -->
<footer><ul class="copyright">... </ul></footer>
</body>

The extra lines of code doesn't add much weight to the site. And it works?

Problems with that approach
Issue 1 - We'll have to copy/paste that code 50x times. So 50 individual .html changes.

Issue 2 - It feels bad and makes me feel bad.

Winning Idea: Web Components

The more I reflected on it, the more I remembered a thing called 'Web Components'!

Web Components is a suite of different technologies allowing you to create reusable custom elements — with their functionality encapsulated away from the rest of your code — and utilize them in your web apps.

Via MDN

It essentially looks like this:

<body>
<!-- asp.net code for header is now replaced -->
<navbar-section></navbar-section>

<div class="content"> ... </div>

<!-- asp.net code for footer is now replaced -->
<footer-section></footer-section>
</body>

I don't need props or anything, and styling is already handled.

Now we can:

Have a single place to house the navbar and the footer
Keep the payload lightweight.
Have it work for the next million years! (Hello Google Ultron!)

Conclusion

It was a pretty nifty and simple way to finally dip my team's toes into web components!

And we successfully migrated a site that lived when everyone was playing PS2, XBox and Gamecube with a few lines of modern Javascript.

Upon writing this post:
I realized that I didn't do anything special, and I didn't even NEED to use web components. There was nothing stopping me from just using Javascript to shove html into this site like our forefathers have done for the past decade, with something like insertAdjacentHTML.

Also, this post took me an hour to write, which is 5x longer than how long it took us to handle the original request. 🤣🤣🤣

How I became a Developer in about 15-ish or so years

Rocky Kev — Mon, 06 Jun 2022 07:01:26 +0000

(This post was originally written in March 2022 on my defunct blog. Moved it here.)

Follow this roadmap and you too can be a dev in 15 years.

Pre-2006: My road to coding

I bought the book Learn C++ in 24 hours. I went to chapter 2 and got stuck.
I made Starcraft maps and fumbled through the Source Engine.
I wrote really crappy HTML on my xanga site. Tables ftw.
I made movies using RPG Maker. I never saved any of them. 😔
I decided to go to school for video game animation.

2006 - 2010: College years

College. I took coding courses.
I learned Java. I discovered I suck with Java too.
My new life calling - this fart app made $10,000 a day.
I dropped out. My mate and I hacked together mobile apps, trying to score that fart app money.
I am broken. I suck at coding. I suck at college. I owe a lot of money. 💀

2010 - 2013: I hate software developers 😡

Started attending conferences. It was incredibly hostile and exclusive. 🔪 Very 'old guard'.
WordPress development was hot. And community was super nice.
Started WordPress themes/plugins. Now I sucked at both Java AND PHP.
Still in severe debt. Worked with websites (I did SEO and marketing), but never as a bona fide developer.
Wrote scripts to automate things like bots and social media.
Minecraft (Java) was getting popular. Should I dig deeper in Java? Haha no. Java is too traumatic.
Recieved a Raspberry Pi.

2013 - 2015: People give me money... for code?

I hacked Wordpress templates together. Genesis Framework
Someone paid me $200 to build them a WordPress site. Am I a developer? No. I built iPhone apps, games and websites. But I'm no developer.
I fell in love with jQuery, Bootstrap, FontAwesome, and web languages. (ugh to SQL)
People started talking about React, but it didn't make sense.
Still building bots. Still creating scripts.
I automated a huge chunk of my day job. You can Javascript in Google docs, you know?

2015 - 2017: I am developer now?

Job learn I could build websites. They chose to ignore me automating my job. 🤷
Job told me to build websites. Yer a developer, Harry!
Job offloaded me to other people to build websites. I was now doing development for over 50+ hours.
I spoke at conferences about marketing, seo. Now I was speaking about web development.
Started fully understanding Javascript. And jQuery is starting to show it's age.
Data science was getting big. Should I play with Python?
React is getting much bigger. I still don't get it?!?!
I helped on a Angular project. Why are JS frameworks so confusing?
I started working on Laravel projects. I like Laravel.
I returned to conferences/meetups. Much more inclusive now 🏳️‍🌈👨🏿👸! The old guard is dead? ☠️

2018 - 2020: I understand JS frameworks

All my friends were into React, Gatsby, GraphQL. Why is this so hard?!?!
Finally started learning React (through a Bootcamp), while also digging into Vue.
🙌 🙌 🙌 OMG JS FRAMEWORKS MAKES SENSE NOW. 🙌 🙌 🙌
Still relying on smashing libraries together, like a crutch.
Work was all WordPress, so I took freelancing jobs to do more JS framework things.
I lead WordPress meetups, did conf talks, and ran web development workshops. Heck yeah I'm going to make my spaces real ✨safe and inclusive✨. EVERYONE is invited 🏳️‍🌈👨🏿👸! Go suck a 🍋, old guard! (Yes I'm very spiteful.)

2020 - 2022: The age of fundamentals

Really find myself understanding the web fundamentals. Vanilla HTML, CSS, JS... real mastery instead of hacking things.
I learned that the <details> element is magical.
Spent the pandemic focusing on mental health.
Started feeling framework fatigue. I could switch between React and Vue. Played around with Svelte.
Started writing vanilla everything more, or trying to code things directly instead of finding a crutch like a library.
After 4 years, I finally understood testing libraries.
Still not going to touch Java.
Finally found a real use-case for my Raspberry pi. Pi-hole.

These 6 rules created a really dope culture at my job

Rocky Kev — Mon, 06 Jun 2022 05:30:51 +0000

(This post was originally written in February 2022 on my defunct blog. Moved it here.)

We as a industry do a lot of lip service about being inclusive, creating welcoming environments, and making things a 'fun place to be'.

Yet, the industry can be tribal/hostile.

Open source developers get attacked.
Languages get mocked and practioners laughed at... like PHP, which runs 77.5% of the internet, or Javascript, which is 98% of the internet.
Framework tribes bubble up and thousands of bloggers write posts comparing the Reacts, Vues, Sveltes, vanilla (no links because not creating backlinks to THAT noise) and why only one shall reign supreme
Imposter Syndrome is real. With so many routes to becoming a developer (self-taught, to CS degrees, bootcamps), everyone is on extremely different wavelengths.

That toxicity spreads to the person, who brings that into their workplace.

The workplace already has it's own set of problems.

Changing deadlines, bad code/bugs, office politics, time vampires and meeting overload... overwork, stress, and only recently did developers realize mental health is a thing.

And let's not forget remote work, for those fortunate to get it, also has it's own challenges.

It's freakin' tough to be a developer.

The current reality

I'm an introvert.

As a introvert, we're told that "closed mouths don't get fed". So you speak up or you die. What they didn't teach you is, "The loudest person in the room gets what they want."

Have you ever been in a room where you're in a group of incredibly smart people and you're the percieved 'dumb quiet one'? It usually goes like this:

You bring up a concern.
Then the loudest person starts speaking to address your concern.
Everyone starts shaking their head and nobody has any counterpoints.
You don't agree, but the social pressure stops you from talking.

The loudest person wasn't mean or belittling. They just brought more passion to the table. Everyone else, who may share the same concern as you do, shrug from mental exhaustion or not feeling like they want to.

People don't feel psychological safety.

“Psychological safety at work doesn’t mean that everybody is nice all the time. It means that you embrace the conflict and you speak up, knowing that your team has your back, and you have their backs.”

“People need to feel comfortable speaking up, asking naïve questions, and disagreeing with the way things are in order to create ideas that make a real difference,” says Altman.

via https://www.ccl.org/articles/leading-effectively-articles/what-is-psychological-safety-at-work/

For those who prefer code --

Psychological Safety === Better everything

Creating Psychological Safety

Rule 1: Start from a place of positivity

In almost any televised sport, watch the players. Teammates high five. Win or lose, opponents say "good game". Players tend to be good sports. It's rare to seeing players belittle a fellow teammate.

Because at the end of the day, it's just another day. It's just another game. There's a thousand more. And another opportunity to shine.

That's how we see it!

Assume positive intent.

In code reviews, feedback is viewed from the lens of the positive. We identify what they've done right, and give them praise for it.

We also give clear feedback and we explain why.

This is what you see in my team:

Great work on this feature! You really took the time to implement this correctly, and it's going to help us so much in the long run - thank you! I noticed that you missed this. Take a look at this PR and can you try to align it to yours? [PR link]

Rule 2 - Reminders that we're always learning

Web development changes and evolves. Libraries from three years ago might be outdated/insecure today. In web development, the moment you master something, it's already outdated. Welcome to the real world!

Let's accept the big picture: Coding is hard!

And the result? Imposter syndrome is very real.

To create psychological safety, my team is honest with ourselves. Nobody is a expert. We all feel like imposters. And more importantly, we're always learning.

We remind each other by:

Sharing our favorite learning resources, like courses or books. Shoutout to Frontend Masters
Pushing everyone to contribute to the internal knowledge base. Best way to learn is to teach it Learn by Teaching is a method of teaching for eons. 3 - Providing a safe space to asks questions. In my company, we have a channel called 'Riddle Me This'. Everyone asks questions, even the experienced devs.

But more importantly, we're not just yelling into the void.

Someone shares a resource, and suddenly... ❤️❤️❤️ everywhere. Everyone on the team appreciates it. We're all naturally curious and hungry for knowledge. (And if they aren't... they're a bad hire.)

Rule 3: Celebrate as a team

We win as a team. It takes a lot of people to bring a new feature to production. The feature may have been brainstormed by a developer. Another developer took on the task. A bunch of other developers code reviewed it. Another developer may deploy it.

It's never ever just one person.

We go out of our way to remind people of their contribution.

We do that with:

Shoutouts during standup. Someone did something we like, we let the whole team know.
Shoutouts in chat. What better way to make it visible?
Shoutouts in code review description. It's a great feeling to know your code inspired another.
Monthly shoutouts. Emails praising your work.

It takes a village.

Rule 4: Problems aren't personal, it's just another todo.

We win as a team. Which also means, we lose as a team.

Finger pointing is a waste of energy.

Quote that.

When a manager demanded to know who caused a bug, I said it was me. DONE. NEXT QUESTION PLEASE. Doesn't matter that I was no where near the code.

Many industries follow the swiss cheese model, including medical professionals. When there's a medical mishap, there's never a single fault. Typically, a issue went through multiple layers of defense, and we all failed.

It's the same in dev work.

When there's a problem, there's only TWO STEPS.

STEP 1: How we can fix the problem?
STEP 2: How do we mitigate future problems (and we throw more layers of defense)

Everything else is a waste of everyone's time and energy.

In my team, we separate the problem from the person. Then we get to work!

Rule 5: Leading by example

Let's face it. Good leaders lead from the front.

Do you really trust the manager who demands everyone get in the office by 8am, for that manager to waddle in at 9am?

All leaders should be able to do the following:

Give shoutout and appreciation.
Apologize for mistakes.
Say "I don't know".

A leader who is unable to recognize someone's talents is egotistic, and cannot be trusted to support you without a reward.

A leader who is unable to apologize is WEAK and lacks self-realization. In their viewpoint, there's right and wrong, and they're always right.

A leader who is unable to say "I don't know" is insecure and inexperienced. They believe only they can do everything, and may be controlling/difficult.

Everyone on my team inspires to grow and be the best. I push everyone to be leaders, in hopes of forming their own teams one day.

It's important for all of us to show high-quality leadership through example.

Rule 6: Frequent check-ins

"Stand-ups help with blocks", people say.

Maybe. Stand-ups just tell if someone is alive.

Someone needs to FEEL psychologically safe to share what blockers they have. Otherwise, they'll quickly share what they're doing and pass the mic. I know from experience.

Not everyone communicates the same. I communicate using visual aids and writing. My teammate prefers to jump on calls. Another teammate ONLY communicates through PRs and feedback.

We facilitate check-ins by creating many points of touch, until we figure out their mode of communication.

There's no one-size fits all and requires a lot of trial-and-error. But it's worth it.

Good Culture is creating Psychological Safety

The industry can get pretty toxic, which can create toxic cultures and many many horror stories.

With that unknown, new hires have a lot of fears coming in.

Once psychological safety is established, the results is real growth. They'll tackle projects. They'll own code. They'll even start pushing the envelope and make us all level up.

These small details cause major ripple effects for everyone.

It's a little bit of effort for a major gain. And it's totally worth it.

I'm officially done with FontAwesome

Rocky Kev — Mon, 06 Jun 2022 04:42:11 +0000

(This post was originally written in January 2022 on my defunct blog. Moved it here.)

Check out Dan's counter on this post! It's pretty good! :-)

When I first discovered FontAwesome in 2013, I like everyone thought the same thing -- this is a MAJOR game changer.

It is now 2022. As I look back, FontAwesome has become unsustainable.

I'm officially 'done' with FontAwesome.

Credit where credit is due

I know this is a 'complaint'-style post.

(There's a lot of toxicity in software development) [https://jamie.build/dear-javascript.html]. This post is full of emotion (and contributes to that toxicity).

But credit where credit is due.

FontAwesome solved major problems with icons. The team worked really hard over the years.

We stand on the shoulders of giants.

But as we continue moving forward in web development, I'm sending FontAwesome into the 'thank you for your service' graveyard, along with jQuery, Bootstrap, Foundation, Gulp, and Sublime.

Additionally, the bulk of my complaints is the css portion of it. 90% of fontawesome projects I've worked in over the decade of development imported it this way.

Using FontAwesome as single file svgs, which is my current preferred way of importing icons, mitigates all of these problems. (Which then begs the question, "Why even use Font Awesome?")

Problem #1 - version nightmare

If you were building a website in 2018, you may have used FontAwesome 5. Set it and forget it, right?

Let's say you need a gameboy icon. Here is one!

Direct link

<i class="fal fa-game-console-handheld"></i>

But it doesn't work.

Here's all the reasons why.

REASON 1: You're on FontAwesome 5.0. And this is on FontAwesome 5.11.0.

REASON 2: This is a 'pro' font. You're using a free version.

REASON 3: You've been importing solid versions of fonts. You should You need the light versions.

So not only does FontAwesome have minor versions, it also has variants! There's regular versions, light versions, solid versions, duotone versions, brands... all in separate files, with separate markup.

This juggling of version and variant, if it's Free or Pro, and which of the many different files continues in FontAwesome 6.

Problem #2 - Massive font set

FontAwesome's strength is the range of icons.

FontAwesome 3 - 321 icons (https://fontawesome.com/v3/icons/)
FontAwesome 4 - 675 icons (https://fontawesome.com/v4/icons/) FontAwesome 5 - 7,864 icons (https://fontawesome.com/v5/icons/)
FontAwesome 6 - 16,000+ icons (https://fontawesome.com/search)

How many icons are you really using on your site? Maybe 6 or 7?

Most sites (and I'm speaking from my own background) only use a handful of icons, like magnifying-glass or circle-question (https://fontawesome.com/icons/circle-question?s=solid) or social media icons.

If you're importing a fontAwesome's regular.css, you're bringing in hundreds of fonticons you don't need. It's even more nightmare-ish if you're getting a circle-question icon (which lives in regular.css) AND a Facebook icon (which lives in brands.css). Now there's thousands of fonts imported... all eating bandwidth. Yum.

You want to a few icons on your site? Gotta import the massive set of files.

Defenders may say, "Well you can tree-shake it" or "optimize it".

And you're right! So... how many devs even know to do that or have the gumption to set that up?

TailwindCSS includes the entire kitchen sink as well. But they also include helpers to prune it all so you ship the absolute, smallest most performant css you can.

Problem #3 - Fonts first

A major problem with font icons is that you're treating them like fonts first, not icons.

You want a horse icon to be 100px wide.

This won't work:

.fa-horse {
  width: 100px; /* does nothing */
  font-size: 100px;
}

Instead, you have to fiddle with this using font-size.

See the Pen Untitled by rockykev (@rockykev) on CodePen.

codepen

That also means these icons are also affected by other css text modifiers, like line-height.

Are you screaming yet? 😱😱😱

Problem #4 - Changing APIs

Let's use a real example.

You have a feature for visitors to leave a review - a simple leave a 1 to 5 star review.

Here's how to do that, depending on the FontAwesome version.

// FontAwesome 3
<i class="icon-star"></i> 

// FontAwesome 4
<i class="fa fa-star" aria-hidden="true"></i>

// FontAwesome 5
<i class="fas fa-star"></i>

// FontAwesome 6
<i class="fa-solid fa-star"></i>

Starting to see the problem?

If I wanted to upgrade FontAwesome 3 to FontAwesome 6, I'll have to go find all the markup and fix that.

Worst, try juggling multiple projects with multiple different versions of FontAwesome. It's a nightmare.

Problem #5 - Locking you into the model

The last problem is that Pro is yearly.

If I have FontAwesome 5 Pro, which I purchased in 2019, and I wanted a Tiktok logo, I'll have to either:

Option 1: Keep FontAwesome 5 Pro and also include FontAwesome 6 brands
Option 2: Buy FontAwesome 6 Pro.

Just to get a TikTok logo, I now can either fracture my versions or pay $99.

Summary

All of these problems do have workarounds. The thing is -- all these problems are strictly from using FontAwesome!

Instead, switch to SVGs. Boom! All the 5 problems disappeared. (And devs have been [banging their drum (2015 article)]...(https://cloudfour.com/thinks/seriously-dont-use-icon-fonts/) to leaving icon fonts (2021 article) for years...)

There's plenty of sites to score free SVGs or to buy SVGs. And SVGs are performant and AMAZING. (Animated SVGs, wow!)

After years of FontAwesome, I'm done.

Thank you FontAwesome for your service. It's time to go.

Election Week distractions?

Rocky Kev — Mon, 02 Nov 2020 17:08:50 +0000

There's many times in your life where the only thing you can do is wait. Maybe it's a test exam. Maybe it's your partner giving birth. Or maybe it's waiting for your the party to start/end at awkward Family Thanksgivings.

For Americans, this week is going to be a long one.

Because after voting -- all we can do is wait.

So the question I'd love to throw out ---

This week: what are you distracting yourself with?

Building your own Modern CSS Design System

Rocky Kev — Mon, 27 Jul 2020 15:38:14 +0000

There's a lot of ways to tackle CSS. I want to introduce you to Modern CSS Design Systems, which uses CSS variables to declare your key design elements.

Let's jump right into an example. Choose a new theme by clicking on any of the buttons in the top-right.

All those buttons did was change the values of the CSS variables. Rather than writing a completely new theme file, you change a dozen or two lines and boom -- new theme! Very powerful stuff.

I took this course by the amazing Scott Tolinski to understand Modern CSS Design Systems. I always struggled with writing clean CSS, and this methodology gave me a lot of tricks.

What are design systems

Major companies use design systems to create a standard design so their components look consistent across their entire suite of software - typically by loading those values in a JSON file. Using an example: In their design system, Uber may include their brand colors, 8 different logos depending on screen size, what type of icons to use where, and even the ratio of their border-radiuses. More info on Design Systems

This post is only taking the role of the CSS developer.
Building your CSS design in this way will allow you

To switch themes on the fly (like in my example)
Build a strong CSS system that can tolerate changes
Or even use a company-wide design system to programmically change your designs as needed

The free Figma course on design systems will help fill in a lot of blanks.

Starting your CSS Design System

CSS Variables

You should understand how CSS variables work.

It looks like this:

:root {
  --black: #000000;
  --background: var(--black);
}

body {
    background: var(--background);
}

What you did here was:

Declared a variable called --black.
Declared a variable called --background, and passed the --black value to it.
Changed the background color of the body to the --background variable.

If you decide to make the background red, you have to change the --background variable.

Why not pass our black color #000000 directly to our --background variable? We'll cover that in a bit.

Classless CSS

You should also get the concept of classless CSS. Classless CSS is defining the design directly on top of the core css.

BAD

.paragraph {
    font-size: var(--baseFontSize);
}

GOOD

p {
    font-size: var(--baseFontSize);
}

It'll make you write cleaner, smaller, better CSS, instead of declaring a new class for every. single. element.

Check out this whole list of CSS Frameworks, and check out the classless section.

Declaring Design Intentions

You want to identify the intentions of your CSS elements.

What are intentions? They are kind of like this image (minus the colors):

Borrowed from the free Figma course

Some examples of Design Intentions:

::root {
    --siteBackground: var(--lightGrey);
    --siteLines: solid 1px var(--grey);
    --borderRadius: 1.2rem;
    --bodylineHeight: 2.1;

    --headerBackground: var(--darkBlue);
    --footerBackground: var(--headerBackground);
}

These are global variables you can call within your site.
Notice that I called --headerBackground inside the --footerBackground variable, making them the same color.

 ::root {
   --headerBackground: var(--darkBlue);

        --footerBackground: var(--headerBackground);
    --cardBackground: var(--headerBackground);
    --formInputBackground: var(--headerBackground);
    --blockquoteBackground: var(--headerBackground);
}

I can even do this. The footer, cards, form inputs, and blockquotes all match.

How do you declare them?

BAD:

h1, h2, h3, h4, h5, h6 {
    font-family: 'Prata', serif;
    font-weight: 400;
    ...
}

body {
    font-family: 'Preahvihear', sans-serif;
    line-height: 1.65;
    ...
}

You declared your header/body CSS directly, starting off a pretty fragile design pattern. In the future, stakeholders want to switch out all the fonts, across multiple CSS files. It already sounds like a nightmare.

GOOD:

::root {
    --headingFont: 'Prata', serif;
    --headingWeight: 400;
    --bodyFont: 'Preahvihear', sans-serif;
    --bodylineHeight: 1.65;
}  

h1, h2, h3, h4, h5, h6 {
    font-family: var(--headingFont);
    font-weight: var(--headingWeight);
    ...
}

body {
    font-family: var(--bodyFont);
    line-height: var(--bodylineHeight);
    ...
}

Let's go with another example:

BAD

::root {
    --green: #b2c16c;
}

body {
    color: var(--green);
}

a {
    color: var(--green);
}

textarea {
    color: var(--green);
}

In that BAD example, the colors are being called directly.

GOOD

::root {
   /* Define colors as colors */
    --green: #b2c16c;

    /* Define color intentions*/
    --siteBackground: var(--green);
    --linkColor: var(--green);
    --formTextarea: var(--green);
}

body {
    color: var(--siteBackground);
}

a {
    color: var(--linkColor);
}

textarea {
    color: var(--formTextarea);
}

Congrats! You just made your CSS code anti-fragile! If you change the color intentions, you modify the rest of the design!

Stripey.CSS

I built Stripey.css as a learning tool. I also went wild with design intentions, just to see how much I can change.

To make a new theme within stripey.css, you copy the ::root into it's own class (like I did with .theme1 .theme2 .theme3) and swap variable choices on the click event.

It's the absolute easiest way to make a dark mode, oled mode, floral mode, etc.

Questions

** 1. Are you declaring everything as a 'design intention'?**

It's a pick-and-choose battle. I still hardcode a lot of key elements, like padding or alignment. The goal is that you modify only a small subset of CSS variables to create a massive change. Each one of stripey.css' theme is roughly 100 lines of CSS (most is duplicated from the default!

** 2. Classless CSS? I need classes!**

Me too buddy! Classless CSS systems are just templates with another name. Build on top of them.

** 3. Why stripey.css? There's no stripes.**

My cat buddy Stripey died while I was going through the course. It's in honor of that little furball.

Additional resources:

I used this site to pick out header/body fonts: https://type-scale.com/
I used this site to create shades/tints of colors: https://www.cssfontstack.com/oldsites/hexcolortool/
This site was used as inspiration.https://www.happyhues.co/
Finally, I borrowed (really stole) a lot of concepts from Tailwind CSS: https://tailwindcss.com/docs/box-shadow/

Github is replacing the word master to avoid slavery references. Deal with it.

Rocky Kev — Sun, 14 Jun 2020 20:41:08 +0000

First, Github is making some changes.

GitHub is working on replacing the term "master" on its service with a neutral term like "main" to avoid any unnecessary references to slavery, its CEO said on Friday.via zdnet

What the internet is saying

There's some interesting conversations I was having in with my dev friends on Slack. Much is shrugging.

But the vocal parts of the internet?

Twitter is typical Twitter - lots of opinions in 240 characters.

Reddit commenters are pretty negative (as usual to anything).

Heck, within that Zdnet post are some really awful comments.

My personal opinion?

There's no slave model in Git. I personally think it's a stretch to connect the word Master with the whole Master/Slave concept in tech.

Opinions are like butts

Everyone has opinions. You're allowed to have opinions. You also have a butt.

Please avoid putting it in people's faces who don't want it.

I started to really think this through - is changing the word master to main important to me?

Nope!

It doesn't affect me in the slightest.

So my opinion is kinda moot. It doesn't matter. It's a waste of energy to think about. And of all the hills to die on, this is not one of them.

But let's go through the excuses because why not?

Excuses you'll hear why it's a bad idea

Excuse 1: It's just language policing

As a developer, why are you so invested?

You can name anything with anything.

sayHello & i are the same.

const sayHello = 'Hello, there';
const i = 'Hello, there';

Now, i doesn't make sense as a variable name at all. There's no meaning what i represents and it's a terrible practice.

While changing master to main doesn't have any implications.

Excuse 2: It's a slippery slope

As a developer, programming is a slippery slope!

Languages change over time. Tedtalk video That's how languages work. Go ahead - travel back in time with your English speaking skills. You definitely won't be able to speak the same English to another english speaker in the 1200s.

When Python removes the master/slave terminology, Python didn't break. Life moves on.

Excuse 3: It makes the internet/tech nerds mad

So? Remember the opinions == butts part? This guy from 2015 thinks React is bad

People get mad and butthurt about everything.

Excuse 4: Why change it now? It was fine how it was!

This screams 'We've Always Done It This Way', which is one of the most dangerous phrases in business.

'We've Always Done It This Way' is a fundamentally broken concept. If it wasn't, we'd still be using Netscape and writing pure HTML/CSS.

Excuse 5: There's nothing innovative about changing it to `main`

Finally you're getting it! It's a nothing burger.

But at the end of the day, the change is the change and life moves on.

But if you still have very strong opinions and feel like you're fighting against some weird 1984-cult language, I invite you to relax and take a break from the internet, and when you're ready, put your opinions here.