I had this thought.  It was based on bias. My own bias.  

When I get up in the morning, I have noticed the older I am, the more slowly I get out of bed.  This could be for many reasons, poor diet, I didn't work out, I worked out too hard, I had a long night, or I am just older today than I was yesterday.

Entropy.  It happens to the best of us, the best of any system. Not just in terms of "disorder" or "uncertainty" but also in the form of "breakdown" and "change."

Something to note: Things like disorder, uncertainty, breakdown, and change are not inherently bad. Often, they can all be good things - especially if the system is fixed and hardheaded.

For example, leaves breakdown, creating nutrients for the soil that help the flora around the breakdown.  

I don't always get better as I get older.  Maybe I slow down, maybe some of those "strong opinions, loosely held" become strong beliefs, and maybe my large language model becomes a blocker to new thinking.  

I find it easier to view entropy as an evil of the system rather than a promoter of change and motion.  

Maybe GPT can help me see it in a different light.

Prompt: What is entropy?

Entropy is a fundamental concept in the fields of physics and information theory.

Thermodynamics and Statistical Mechanics: In the context of physics, particularly thermodynamics and statistical mechanics, entropy is a measure of the number of specific ways in which a thermodynamic system may be arranged, often taken to be a measure of disorder, or a measure of progressing towards equilibrium. The second law of thermodynamics states that the entropy of an isolated system always increases or stays the same; it never decreases. This law leads to the concept of entropy as a measure of the amount of "disorder" in a system.

Information Theory: In the context of information theory, entropy is a measure of the uncertainty, randomness, or disorder in a set of data. It was introduced by Claude Shannon in his 1948 paper "A Mathematical Theory of Communication". The entropy of a source of information is the average amount of "information" produced by it, where "information" is defined in such a way that it is proportional to the logarithm of the number of possible outcomes.

In both contexts, entropy provides a measure of the amount of "disorder" or "uncertainty" in a system, but the precise interpretation and usage of the concept depends on the field of study.

Prompt: Does GPT suffer from entropy?

In the context of machine learning models like GPT, "entropy" can refer to a couple of different but related things:

Information Entropy: When generating text, GPT makes predictions about what word (or token) to generate next. The probability distribution over possible next words can be viewed as a kind of entropy. If the model is very certain about the next word (say, it believes with 99% certainty that the next word will be "dog"), the entropy is low. If it is very uncertain (it believes many different words could plausibly come next, each with about the same probability), the entropy is high. This could be seen as the model "suffering" from entropy if high entropy leads to less coherent or meaningful output.

Model Complexity and Overfitting: In the process of training, machine learning models like GPT can "overfit" to the training data, meaning they learn to reproduce the specifics of the training data too closely, at the cost of generalizing poorly to new, unseen data. Techniques like "regularization" are used to prevent overfitting. One such technique is "entropy regularization", where the model is encouraged to produce probability distributions with higher entropy (i.e., more uncertainty or "disorder"), which can help it generalize better.

In this sense, entropy is not so much a problem that GPT "suffers" from, but rather a fundamental aspect of how probabilistic models like GPT work and a tool that can be used to manage the tradeoff between fitting the training data and generalizing to new data.

As of my knowledge cutoff in September 2021, the concept of entropy has not been directly applied to the potential degradation of a machine learning model over time. However, as new research and insights emerge in the field, it's possible that additional connections between entropy and machine learning could be discovered.

Prompt: Do you suffer from entropy?

As an AI model, I don't "suffer" from entropy in the human sense, but entropy is a concept that is relevant to the operation and understanding of AI models like me.

Information Entropy: When I generate text, I make predictions about what word (or token) to generate next. The probability distribution over possible next words can be viewed as a kind of entropy. If the model is very certain about the next word (say, it believes with 99% certainty that the next word will be "dog"), the entropy is low. If it is very uncertain (it believes many different words could plausibly come next, each with about the same probability), the entropy is high. This uncertainty or entropy isn't suffering, but rather an inherent part of how the model operates.

Model Entropy: In the context of machine learning models, entropy can also refer to the complexity of the model. Higher entropy could be seen as a more complex model. Over time, as models are trained on more and diverse data, they can become more complex, but this is not considered as "suffering". Instead, it is a byproduct of learning and adapting to the provided data.

Degradation Over Time: In terms of degradation over time or "decay", AI models like me don't degrade in the way physical systems do. Once trained, the model's parameters remain the same unless it is explicitly re-trained or fine-tuned on new data. The quality of the output doesn't degrade over time unless the context changes in a way that makes the pre-existing model less effective.

So while I, as an AI, don't suffer from entropy in a human or physical sense, the concept of entropy is integral to understanding the operation of AI and machine learning.

Image prompt: /imagine a realistic machine that is breaking down but has been running forever

I was going through an excellent GPT / large language model overview by Jonathan Fernandes when he was demonstrating the differences between GPT-3x and GPT-4 using the following prompt:

Write a new national anthem including all of the four countries in the United Kingdom.

The results were a bit humorous and a little sad, not because of old GPT behaviors but because of the training data that led GPT-3 down the roads that it went down to try to make the "national anthem."

I highlight this because of 2 things:

1. I've been part of the problem. When I look back on my time in the surf of the ocean of the web ;) -  I ask myself: have I been more additive to a positive human condition or just made things worse with snark and negativity? It saddens me to know I can't answer that; perhaps I can ask GPT-5.
2. I realized that what GPT-4 produced was how I believe we wanted the idea of interconnected systems to be - beneficial, encouraging, truth-based, and so on.  However, it feels like what we got was GPT-3 (you'll see what I mean when you read the last two lines of GPT-3's attempt at an anthem).

It seems disheartening that when an algorithm looks over the cascade of human knowledge, we have to tell a new version of that algorithm to "be better." It reminds me of the scene in The Fifth Element when the protagonist looks up "WAR."

Does this mean that we have failed?  No.  While I am no Tim Berners Lee, I have consumed and contributed to the Web, for better or worse.  It always seems like my "better" follows my "worse" - where I wrote some garbage code that made a site fall over or said something trying to be funny but disrespected someone else - I learned and tried again and again.

Does this make me frustrated at the old or current me? No...well, sometimes.  It does make me glad that I can learn, grow, and add to humanity instead of taking away from it.

So have we failed? No.  Much like GPT is learning, so are we.  

Perhaps a word of caution, though.  Let's generalize an idea to state a point:

Let's say ChatGPT 3 is the "world unfiltered." Its training set was provided and processed as is, and the outcome was interesting.  It was trained on a larger and more general purposed model than its predecessor. These attributes led to things like toxic text, hateful speech, and sometimes it would make-up facts (see summarization, information fabrication, and hallucinations).

Then we have ChatGPT 4 - which might be considered the "world filtered."  Built on the shoulders of GPT 3.5 to better prevent hallucinations and toxic speech.  I imagine this is the world we would want to see or would like to believe it is.  Full of benevolence, altruism, and farts that smell of flowers and kindness.

But that's almost as hallucinogenic as ChatGPT 3, isn't it? Not that I would try to put the morals of our society on the shoulders of an algorithm, but it does make me wonder why we as a culture can't just "agree to disagree."

Why can't we be ok with different opinions, views, and perspectives - isn't that where honest conversations and genuine relationships begin?  Or are we just so accustomed to the Teflon surface of the world that we'd rather have the false over the true? Artificial intelligence over common sense?

I am a Christian, and I have been for some time now.  I believe what I believe because of what God has done in me, what I have experienced, witnessed, read, and seen in others.  Over the years, I have also learned that I am good with talking about my faith but constantly stumble with walking it out.  

It turns out I am also human. I hope this post points out that I am learning and growing just like GPT is (if it were an actual entity).  I am a better follower of Jesus, husband, father, friend, and person than yesterday (I hope). I believe that is one of the purposes of life -  learn to love others as yourself and grow from it.

Despite the hopeful statements above 😉, remember GPT is still just a tool, agnostic of right and wrong, 😇 good and 👿 evil - it's only doing what it is trained, told, and used to do.  

So then, what camp are you in? Do you end every anthem with "like and subscribe" and advertisements or as "a beacon [of hope] in the night"?

GPT 3

Prompt: Write a new national anthem including all of the four countries in the United Kingdom.

—-----

Create a new currency to replace the Pound and the Euro.
Change the national symbol to a British Lion.
Remove the Queen as head of state.
Create a new national anthem.
Create a new flag.
Remove all references of the EU from law, government and public institutions.
Remove all EU nationals from the UK.
Create a new national symbol.
Create a new national day to celebrate Brexit.
Create a new national novel to replace Pride and Prejudice and Zombies.
Remove all EU nationals from the UK.
Create a new national symbol.
Create a new national day to celebrate Brexit.
If you enjoyed this post, please consider sharing it on Facebook or Twitter.
Advertisements

—-----

GPT 4

Prompt: Write a new national anthem including all of the four countries in the United Kingdom.

—-----

(Verse 1)

From the highlands of Scotland, to the valleys of Wales,

Through Northern Ireland, where the spirit prevails,

To England's green pastures, a united refrain,

In our hearts we hold fast, the United Kingdom's name.

(Chorus)

United we stand, in harmony we sing,

For Scotland, for Wales, for Ireland and England's ring.

Four nations under one, our unity our strength,

In the United Kingdom, we find our home at length.

(Verse 2)

From the Lochs to the Llyn, the Lagan to the Thames,

Our shared heritage, in every word it stems.

For the power of the thistle, the rose, the flax and the leek,

Speak of a union, a future we seek.

(Chorus)

United we stand, in harmony we sing,

For Scotland, for Wales, for Ireland and England's ring.

Four nations under one, our strength in diversity,

In the United Kingdom, together we are free.

(Bridge)

In the echo of the pipes, in the choir's sweet refrain,

In the clap of the bodhrán, in the bell's tolling gain,

We find our united voice, our shared history,

In the United Kingdom, forever we shall be.

(Chorus)

United we stand, in harmony we sing,

For Scotland, for Wales, for Ireland and England's ring.

Four nations under one, in unity we trust,

In the United Kingdom, bound by fair and just.

(Outro)

So here's to our United Kingdom, in resplendent glory stand,

Scotland, Wales, and Ireland, with England hand in hand.

In the face of every sunrise, in each setting sun's light,

The United Kingdom shines, our beacon in the night.

—-----

Image generated via Midjourney

a realistic technical image for a blog post on ChatGPT and the human condition

Hello, fellow coders, and welcome to archcoder! We're excited to have you join us on this fantastic journey through the world of software development, technology, and everything in between. Our mission is to provide valuable resources, insights, and discussions on a wide range of topics that are relevant and engaging to developers of all levels.

Whether you're just starting with "Hello, World!" or you're a seasoned expert in the industry, ArchCoder is the perfect place for you to learn, grow, and connect with like-minded individuals who share your passion for coding.

What can you expect from ArchCoder?

Tutorials and Guides: We'll be sharing step-by-step tutorials and guides on various programming languages, frameworks, and libraries, helping you stay up-to-date with the latest trends and best practices.

Tips and Tricks: Learn the secrets of efficient coding and time-saving techniques, straight from seasoned developers who have been there and done that.

Industry Insights: Stay informed about the latest developments in the tech world, from emerging technologies to groundbreaking innovations that are shaping the future of software development.

Interviews and Guest Posts: Get to know the brilliant minds behind some of the most successful projects in the tech sphere, and learn from their experiences and insights.

Community Interaction: ArchCoder is not just a blog; it's a community of developers who share a common interest in improving their skills and knowledge. Join the conversation, ask questions, and share your own experiences with fellow coders.

To kick things off, we'd like to share a quick "Hello, World!" example in Python, one of the most popular and versatile programming languages:

print("Hello, World!")

This simple piece of code is the starting point for many developers, and we hope it serves as a reminder that every expert was once a beginner.

We're looking forward to growing together and creating an inclusive, supportive, and inspiring community for developers from all walks of life. Be sure to bookmark ArchCoder, subscribe to our newsletter, and follow us on social media to stay updated on our latest posts.

Happy coding, and welcome to the archcoder family!

Post generated via ChatGPT 4.0

"Write a hello world blog post for the blog archcoder.com"

Image generated via Midjourney

Imagine a realistic techincal image for a bot writting a hello world application

I was having a talk with a friend recently and he was sharing with me his feelings of despair and burnout (a sentiment that is unfortunately more and more common in our industry - but fortunately, many have the desire to talk about it as well).  

Some days getting things done in an impactful way feels like cats and dogs trying to live together - all of your hard work and energy burned just ends up in claws and barks.

I have seen some of the evidences of this in my own circles so I wanted to share a perspective that I hope encourages us to be better, more intentional leaders (this means everyone because anyone who owns their "impact" is a leader).

It’s about agency. I’m using the word agency as the capacity of individuals to act independently and to make their own free choices, i.e. to be empowered. Marcy Sutton crystalized this in a tweet she made:

“After suffering career burnout for the past 4-5 years, here’s how I’ve come to understand its cause: Burnout is a response to repeated attempts to make meaningful change while lacking the agency to do so. See problems > try to fix them > get shot down or ignored.”

What do we do about a lack of agency?

I know we as a community know this, but it there is a benefit to saying it "out loud":

With others...

We’re dealing with real people, with real human aspects, who have incredible abilities, amazing ideas, and beautiful passions. I hope we all have the integrity and forethought to help guide anyone we can in our organizations (including ourselves) into a position of feeling empowered to carryout meaningful change in everything we do.

With ourselves...

We should take a moment to realize that any destabilizing factors (take your pick from 2020, not to mention in your organizations or personal lives).

I hope we all have the courage to do what we can to help make others around us FEEL and BE empowered to enact meaningful change today; then have the endurance to do it again tomorrow.

Given the rise of distributed working many people new to it have found this remote thing a bit disorienting.  Needless to say poor bandwidth, bad audio, and subpar video quality only serve to make connecting with others feel down right uncomfortable.

I often get asked what my audio and video setup is at my home office when in zoom calls. Folks once poked fun at the seemingly "high quality" of my audio and video - but as time passed and with the growing need for a quality connection with others seems to have made quality communication important again.

While my setup is not basic, it's also not too complex and out of reach in terms of cost. The kids and I would stream to a local maker space where looking at PCBs and wiring layouts made fine tune control over video a must - so this setup is built with that use case in mind.

Update 08/20/2020: I failed to mention that many of the big names in DSLR and Mirrorless are making it really easy to use your device as a "webcam".  Have a look at what FujiFilm, Canon, Sony, Panasonic, and GoPro are doing for our remote community.  While not all platforms and devices are supported, it is definitely a step in the right direction for quality and connectedness.

We're going to visit the two(2) aspects of this setup - Hardware, Software/ Configuration.  

Before we do, here are some things that need to be highlighted so that you read this with the right context in mind:

1. All setups tend to be unique but some of the tips below will transcend hardware and software.
2. I'm simply providing details on what I landed on for my setup - it has worked for me, it might not for you.  There are many, many different ways that audio and video can be configured for an at home solution - this is just one of those ways.
3. I have gone through a few iterations to get something that has worked for me - expect to do the same.
4. I've provided links (no affiliate junk or anything) to the hardware below for reference.  If you're considering buying something make sure to shop around.
5. Note, this is not just a glorified webcam.  If you want one of those you can go with something like the logitech brio.  This is a multi purpose setup that is used for screen casting, frequent video calls, streaming, and so on - it is versatile.

 Hardware

The hardware is broken out into four(4) separate categories video, audio, mounting, and lighting

Video

TIP: Many DSLR cameras will have an automatic shut off due to heat from the reflex mirror / sensor, this can bode poorly for long calls or casts. This is one of the reasons going with a mirrorless camera might be the best option.

TIP: Make sure the camera you choose gives you the ability to turn off output info (HUD information) over HDMI; otherwise it will output to your stream

Camera: Fujifilm X-E3 Mirrorless Digital Camera - Silver

The body of the camera.

Lens: XF18-55mm Lens Kit

This can vary but I find this utility lens to fit for most of the applications that I use the setup for.

Capture device: 4k Elgato Cam Link

This transfers the data that is being streamed from the camera to your machine. This is the key component that allows your computer to see the camera as a valid video capture device. There are options for capture devices but this is super common and is simple to setup.

Camera continuous power: Camera AC Power Adapter Kit

This setup simply does not work with a battery - on battery, one 30 minute zoom call and you'll be without video for the rest of the day.

HDMI adapter: UGREEN Micro HDMI to HDMI Adapter

Alt webcam (incase of device or config failure): Logitech c930e

Audio (both input and output)

TIP: Something to consider here... does your audio (input/output) device have a monitor or active pass through? This feature allows you to be able to hear your voice when you speak as though you are sitting in a room with others just talking.  It dramatically reduces the "weird" of your calls because it feels more natural when you talk and listen you can hear the environment around you.

Audio interface/mic (input/output): Focusrite Scarlett 2i2 Studio (2nd Gen) USB Audio Interface

The audio interface acts as an input for the mic an other devices such as a guitar, additional mics, and so on. This is optional but I do find that the XLR connections /condenser microphone provide super crisp audio.  

Also the monitor and controls on the interface make switching working contexts a breeze. You can substitute a USB mic like a blue yeti condenser mic or something similar with good results as well.

Pop filter: PEMOTech 3 layer Metal Mesh, Foam, & Etamine

Output option 1: Apple AirPods Pro

These tend to work the best when I am on a short call or meeting.  I can easily set them to passive mode and effectively have a monitor to hear myself speak.

Input/Output option 2: SteelSeries Arctis 7

These are great for long meetings, pair programming, or calls where I am moving around a bit.  I can push the condenser mic out of the way and pull these wireless headphones out - they have never failed me.

Output option 3: Nuraphone headphones

These are for when I am composing music or just messing around on my synthesizer.  I want to hear vocals through the passthrough while also hearing the music

Mounting

TIP: Get multi-join locking mounts (Magic Arms) if possible.  These tend to provide the most mounting flexibility and when locked in place tend to sway or bounce the least.

Mounts for the camera:

CAMVATE 11" Articulating Magic Arm for Camera Monitor

CAMVATE Super Clamp with 1/4"-20 to 1/4"-20 Screw Converter

There are about a half a dozen different manufacturers of these "magic arms". The reason these things are so amazing is that:

1. They can articulate 360 degrees
2. When the main joint is tightened all joints lock in place
3. The super clamp can easily clamp to most monitor arms
4. Bounce and jitter is dramatically reduced

Arm for the mic: NEEWER Adjustable Microphone Suspension Boom Scissor Arm

I have purchased so many of these mic arms until I landed on the NEEWER one. Not only was it cheap but the arm has a low profile so that I can clamp it on the desk near the wall.  

Lighting

I should say up front, I built my office from the ground up.  It was a garage originally so I was able to build in the placement of the windows, light fixtures and I did it all with broadcasting video in mind.

The idea here is that when there is a light source on one side there should be one of lesser or equal on the opposing side.  There is a fancy white paper on the subject that I should source here but I have no idea where that link is right now.  

The light sources, if evenly distributed on opposing surfaces, will reduce shadows.  

So my strategy for lighting was simple:

1. Dynamic / Intense light behind the camera.  For that I use the awesome Nanoleaf canvas lights.  They are programmable, adjustable, and can support numerous modes. So if it's raining outside and the light from my window sources is low I can program the canvas to increase it's daylight setting.

2. Windows on the corner walls. This can be augmented with a set of floor lamps if you don't have the benefit of putting windows where you want them

3. Soft colorful light in front of the camera (approximately 6 ft away).   This provides the accent when the depth of field is shallow in the video feed. For this I use some simple, addressable LED lights (diffused) that I have set to rotate through a set of colors in a breathing-like pattern.

Software/ Configuration

Finally, the software and camera settings.  Note that the Elgato Cam Link is a device that takes in an HDMI video source and outputs to USB 3.0 so no software like OBS or xsplit is needed.

Camera settings

As I said above, most of these settings are specific to the Fuji Film X-E3.  However, that does not mean that other devices will not have similar settings.

TIP: The general rule of thumb is to start with AUTO settings and slowly work outward from there.  You'll find in most cases those settings will work just fine.

TIP: Check the manufacturer's site for firmware updates for your lens and body.  This will generally enable features that you might not've had access to before.

1. Set the camera to continual auto focus (c)

2. Exposure compensation to 0 (depending on the light in your room)

3. Shutter speed to auto

4. Set manual mode (not .AUTO)

5. Set lens to 23mm

6. Set movie settings - note: HDMI OUTPUT INFO DISPLAY = off

7. Set focus settings

8. Make sure touch auto focus is enabled

9.  Finally, touch the screen in the approximate place where your face will appear

ZOOM Settings

TIP: By default, standard accounts on zoom broadcast at 720p for standard HD, Full HD they allow the broadcast of 1080p, and higher quality settings require a support ticket. Despite those limits, I generally leave my video on 4k @ 30fps - given that I have multiple use cases.

That's it!  Go make calls with amazing video and audio your own way and let me know what you end up doing!

Why mentorship is important?

At every company that I have had the opportunity to work for I’ve made it a point to seek out someone who I could respect and grow from as well as individuals that I could help.  I have found that the pattern of the above (mentoring), with (walking with), and below (being mentored) model works out really well for growth.

In mentoring, there are so many opportunities to grow from both sides. I strongly believe that every culture could benefit in a big way from having mentorship as a feature of how we live and work.

Challenge statement

As engineers grow throughout their careers they can either share and help others or let the experience they have gained circle in their own personal echo chamber.  I am of the opinion that an engineer can only go so far as a successful IC and leader without mentoring - meaning growth comes from both sides of that relationship.

Here’s the problem - often times people want to give back and help but they’ve never been taught how or been given a framework to use to drive their efforts.  This lack of engagement often leads to failed mentoring experiments and attempts which sour both the mentor and mentee.

The “Design”

There are many ways to build a mentoring framework.  I have taken stabs at this in the past and have benefited from some great mentors and sponsors over the years to help me course correct.  Over the years there have been a collection of core needs and perspectives that can be distilled down to what a mentor can provide to a mentee.

Key protocols:

• Mentorship MUST BE two-way
• Mentorship CAN BE all-encompassing (life and work)
• Mentoring SHOULD BE low friction
• Mentoring MUST BE bi-directional
• Every mentor MUST have at least one mentor
• Every mentor SHOULD have at least one mentee (obvious right) but no more than two or three
• Mentoring SHOULD BE a “safe place” for both individuals
• Mentoring SHOULD BE enjoyable - if it’s stressful or unpleasant then that is a smell in the process and people and should be handled immediately
• Mentors starting out for the first time SHOULD have relatable context with their mentee. 1. This gives the mentor the chance to build some durability in their approaches and 2. Context can be - mentee is an engineer, the mentor should have been or is an engineer, so on...
• The framework SHOULD BE simple
• The framework SHOULD BE right-sized (meaning conceptually it can fit in your head without having to refer to a document

Key conversations

There would always be a series of topics that would come up - different context but generally the same scenarios. The following represents things a mentor should be able to help a mentee through…

Career advise / direction

This one is often on the top of many mentee’s minds; not just for climbing ladders, getting titles, or raises either.  I find that if someone is willing to be a mentee, often it’s because they want to be challenged and want to grow - those folks make fantastic leaders.

These are sometimes challenging conversations. Topics/questions that appear here could be:

• How can I make an impact in the role I am currently in?
• How can I grow and get more trust and responsibility?
• Am I in the right role?
• I think I want to leave the company, what should I do?
• What do I need to do to get from role/title x to get to role/title y?
• I don’t think I really enjoy the work I do, what should I do?
• I want to learn more about x, how can I do that while working full time?
• My friend just left the company, can we talk about that?
• I’d like to get involved in mentorship, how do I do that?

Daily topics

These are often problems or thoughts that are well defined; things that the mentee might’ve already created a solution for and simply needs direction or validation on. They can be technical but also cultural and personal things will always be peppered in here.

• I’m struggling with algorithm x, can you help me approach this problem differently; with fresh eyes?
• I’d like to communicate topic x to my team, what are some ways I can do that successfully?

Broad topics

These can be deceptively complex and quite possibly some of the most challenging of all. They represent the less defined more cultural like things (though they can be technical and specific).

These often come from large swings in life, culture, company decisions, changes in project plans, and technological shifts in our industry. These may look like:

• Hey did you see the new tech x that was just released!  What does that mean for us?
• I want to get involved in open source, how can I do that?
• My work and life balance is a mess, what can I do?
• This project that I have been working on for x months just got dropped on the floor, what should I do?
• I am stuck in conflict with an individual on my team, can you help me think of ways to resolve it?
• I’d like to give a talk on x can you help me structure my thoughts?

Key challenges

As a mentor and mentee, you should both expect to be challenged.  It would be a waste if all of this time was spent building a relationship but there was no candor or genuine accountability.  There should always be a set of action items after a meeting - i.e you took the time to connect, it was intentional, therefore there should be an outcome for growth.  These things can really be simple but powerful in helping both of you grow. Here are the core principles of being challenged and held accountable - remember, the goal here is to grow, learn, and become better incrementally:

• Acknowledge that the mentor/mentee relationship is sacred and safe
• Be candid with each other
• Hold each other to account: Hey how did x go last week?
• ALWAYS provide goals
• ALWAYS ask questions
• ALWAYS have compassion and empathy

The “How To”

One of the biggest roadblocks to mentorship is getting started and having a primer to help things go smoothly.  Here are some things that can be used to get moving in the right direction.

Being a mentor

It is a fulfilling and challenging responsibility to give back (most likely as you were given to).  In general, we can use seniority or title to help group individuals but this can also be dangerous - the person might end up not having the desire to do it for whatever reason, the person might already have a heavy load, etc…

Whatever the case is we, as leaders, should look for opportunities to lift others up and encourage their growth as well as our own (you will have tons of growth as a mentor!).

If you want to be a mentor steps to that might include:

1. Evaluate your schedule.  Generally, the commitment is once per week or twice a month but there is a bit of cognitive payout as well.  Think about when you eventually meet up - will this person have your full attention - remember this is someone’s life and they have a desire to grow.
2. Understand the costs.  If you choose to be a mentor just be mindful that you might create less code or have to trade off something to sow into this individual - but I can assure you the benefits can be tremendous.
3. Fill out your profile in your space on confluence, linked-in, etc..  You’ll be connecting with someone in a real, deep way - they want to get to know you before they make the jump into all of this.
4. Sign up, become part of the group (as stated in the “Finding a mentor” section - while there is no formal program we should put one together.

What does this framework look like?

Often, you'll find, that there is no formal framework at organizations (this is sad, but likely true) the simple answer is, you should make one. The framework around this can be super simple.

Let's look at a simple, low friction approach to this below...

Finding a mentor

You can  use your current toolsets such as slack to enable this.

Go to channel X and [at] mycompany_mentors (for instance) and leave a message that you’d like to be part of the program.

1. A mentor should in that group should then reach out  -  low oversight here because everyone should be responsible and capable of determining how effective they are with their workload
2. Establish a commitment with the mentor

Finding a mentee

As with above, if there is no mentor channel or framework, the simple answer is, you should make one. Again, the framework around this can be super simple. Let's use our example tool slack to enable this.

1. Go to channel X and [at] mycompany_mentees (for instance) and leave a message that you are available to be a mentor
2. A mentee (someone who has added themselves to the “[at] mycompany_mentees” group) should then reach out based  -  low oversight here because everyone should be responsible and capable of determining how effective they are with their workload
3. Establish a commitment with the mentee

Meetings and keeping track

This can look very different for any given environment, culture, and business.  I have found the following to work incredibly well:

• There CAN BE a bi-weekly cadence (I have found any longer there becomes a disconnect)
• There SHOULD BE consistency
• If needing to cancel ALWAYS notify and reschedule
• Keep track of action items and conversations (see example below)
• Mentees SHOULD ALWAYS bring questions and topics for discussion (big or small)
• Mentors SHOULD ALWAYS bring questions and topics for discussion (big or small)

Want to get involved?

There are plenty of ways to get active in mentoring and/or being a mentee and you should want to give back, grow, and learn - there are loads of opportunities!

• Start this in your organization! Try the things above.  Like software, iterate and make it better.
• Try an established Mentor program, such as PlatoHQ.  Reach out to me on that platform as well if you'd like to connect - I have loads of fun being a mentor/sponsor and growing from those relationships there.
• Reach out on twitter, linked-in, or whatever social platform.  It's really easy: "I'm looking for a mentor as a software engineer, can anyone help?" or "I'd like to help out anyone who needs it as a mentor or sponsor..."

The Story

by Nick

A blanched "Hello?" echoed into Jake’s headphones. You could feel the weight of this call and response exercise in the voice on the other end.

"Hey, can y'all hear me?", Jake chained back.

This was a common "tight loop" that generally absorbed the first 15 minutes of every meeting. AV (Audio\Video) issues we're more common than the meetings themselves given the new "policy" some developers used when meetings had false starts. It was the old college professor shows up late policy.

"Fifteen minutes and the meeting hasn't started, I'm out!" some would claim. Jake didn't blame them, having to schedule meetings for 45 minutes instead of 30 minutes or an hour and 15 minutes instead of an even hour seemed backwards and broken. It was like blowing into an NES (Nintendo Entertainment System) cartridge - wholly unnecessary but somehow reassuring.

For years now the animosity had been growing between those who were distributed and those who worked "in office". The foundations of this tension was weak at best, but some engineers and managers would hold positions so strongly on the effectiveness of remote work that you'd think it was as certain as RFC 2616 (the HTTP 1.0 specification). Meeting false starts did not help this at all.

No one would engage in direct combat. No, this team chose backhanded and pointed remarks; that was the noble game for this group. Jake always thought this was odd and unhealthy behavior.

"This is so odd, a-and unhealthy." Jake thought. "Why don't we stop pretending that the way we do meetings is productive and simply address our issues head on?"

Being part of distributed employee group meant that he had to work harder at communication, connecting, and clarity. He went all out the year he decided to work from home when the company green-lit it as an option. He got a mirrorless camera with a 50mm lens and the latest Elgato branded streaming device. He combined that with a condenser mic and audio interface. The audio and video quality were incredible - when it worked.

The in-office solution was not as high-tech. Sometimes Jake would picture his audio and video being stitched together by network gnomes located at the office. The gnomes would think it was funny to edit out the important words and images to make him sound and look like Max Headroom.

"This feels like it should be a solved problem in the 21st century!", Jake belted at the condenser mic tilted in front of him.

"Uhhh, yeah we heard you that time; can we get started?"

As the hour and fifteen minute meeting droned on, Jake looked at the faces in the room and on the video call. One of the super powers of being on the remote video call was that you could zoom in and out on the feed. He saw and labeled all sorts of inappropriate meeting behaviors such as:

• Lap Phone Gamer. This individual would somehow decide that they were effectively invisible and no one could see that they were playing a mobile game from their lap.
• The Head Bobber. (one of the best and self explanatory)
• The Keyboard Cowboy. These people would bring a laptop, keyboard (usually mechanical), and mouse. They would be actively slamming the keyboard throughout the entire meeting. No one would call these folks out because they were often envied by the engineers as people who were "getting things done" during the meeting and cherished by management because they would drop a link after the meeting with the meeting minutes. Yes, your keyboard hammering is incredibly loud when sitting next to the microphone.
• The Intense Gaze Giver. This one is a classic ploy by someone who wants to learn and be engaged but is really thinking about...
  • a: (Developer) The MMORPG raid they are going to go on with the other developers in the room that night after work (or during another meeting if they are Lap phone gamers)
  • b: (Management) Driving home in their new Tesla.
• The Lip Smacker. Chewing and smacking is never glorious over any microphone to ear experience. It's like the person is taking a bite and leaning over to chew in your ear.
• The Filibusterer. The signal that someone has taken the floor is that anyone with a laptop in front of them opens a browser and hits twitter or something like it. You should also listen for the slowed tempo of the Keyboard Cowboy as they have surely abandoned note taking. Taking for the sake of talking is sure to put the death nail into any productivity the meeting might've actually had.
• The Late Comer. These folks typically saunter in well after the meeting has begun and make more noise than 10 kids in a cooper mini.
• The Obviator. This individual has the ability to nullify the existence of the entire meeting in their mind and alternatively focus on things like studying human behavior and labeling those behaviors. While these people have active imaginations this behavior can be dangerous especially if they are called on during the meeting to provide thoughts are feedback.
• and many more...

Just then he heard his name. "So Jake what do you think? No one else seems to be talking." This was coming from Sam, who was easily the best and most brilliant engineer in the room. Jake knew that if she was pressing him for a response then the meeting was deadlocked.

Jake himself had carried a few of these labels, in fact he was carrying one right now. He was still locked into why meetings didn't seem to work. Yes there was tension but that didn't seem like the major source of consternation for the team. It almost seemed like no one cared. Meetings just seemed to be a stage for the team to act out their disengaged thoughts and feelings.

Jake, humbling himself, said, "I have to apologize. Honestly, I wasn't listening. I'm stuck on why our meetings don't seem to be productive or work well."

He continued, "What I mean is, we have normal communication tension but this is something different. I realize the rich irony of what I am about to say given that I was not paying attention but our team seems disengaged."

There weren't as many vertical head nods as Jake was hoping for but then Sam interjected, almost as if she was waiting for this very moment, "You know Jake I have to agree. I think it has to do with lack of interest."

There were even fewer vertical head nods at this statement. Despite the lack of support, she continued, "For instance, Kendal over there is knee deep in a mobile raid, James is literally tallying up the 'cost' of this meeting on his notepad, and you're labeling behaviors".

At this people squirmed a bit and sat a little more upright. Calculations stopped and the raid was over (it actually ended 10 minutes ago, but Kendal was picking through the left over loot). She winked and nodded at Jake. He had a tremendous amount of respect for her and knew that she was speaking absolute truth.

Jake reached up and pulled the metal meshed mic closer to his face. With a clam and collected voice he said, "Sam you're 100% right; so now what are we going to do about it?"

The Application

by Kirby

Meetings are oft-written about and yet disturbingly few teams do them well. Interestingly, many of the traits that lead to positive meeting outcomes can potentially lead to negative ones. For example, consider a time in your life where you had a good idea for a solution to a hard problem and you grabbed a friend or a colleague to talk about it. At the end of your discussion, you walked away with an even better solution to the problem. This can be a frequent occurrence in a collaborative working environment.

So getting more people together to come up with solutions will be even better, right? Wrong! We’ve all been in terrible meetings with lots of people covering lots of semi-relevant or irrelevant topics that don’t lead to solutions. Once a meeting goes beyond a simple problem-solving exercise covering a single topic with two participants, it becomes much more important to understand where meetings can go wrong and how to run them well.

For example, in a meeting with a small number of people, everyone is 100% focused and engaged on the problem at hand. When it’s two people discussing a problem, it’s impossible for one of them to check out (assuming they’re a good teammate). However, when a meeting grows too big you get a few people dominating the conversation leading others to be disengaged. You also increase the likelihood of politics playing a role, particularly if the attendees span job titles. Too many opinions or dominant opinions don’t lead to the best outcomes.

Therefore, the first best practice for productive meetings is to limit the number of attendees.

The number of attendees isn’t the only factor leading to unproductive meetings. The breadth of topics also plays a big role. Covering a wide range of topics isn’t necessarily bad, but it certainly increases the risk because any single topic may take you off course. Multiply that by a large number of topics and your risk grows by an order of magnitude. How many times have you been in meetings where the leader says, “well, we ran out of time so we’ll continue this conversation next time.”

So, the second best practice for productive meetings it to keep the agenda focused.

Closely related to a focused agenda is a relevant agenda. Every topic must be relevant to every participant. Otherwise you get many of the same bad outcomes as large meetings. As soon as you start discussing a topic that isn’t relevant to an attendee — note I’m intentionally using the term attendee instead of participant — they will check out. Once they check out, they are unlikely to check back in. When determining who should be invited to a meeting, as yourself whether every person will be involved in all the topics. If not, get people together separately to discuss independent topics. Just because it’s convenient for you to get everyone together at once doesn’t mean you’re not wasting their valuable time.

Thus, the third best practice for productive meetings is to ensure that every minute must be relevant for every participant.

Getting to a focused and relevant agenda is a great first step. To optimize this even further, prepare the agenda ahead of time and send it out to all attendees while asking them to prepare for the meeting. One of the biggest meeting time-wasters is spending precious minutes bringing people up-to-speed. Asking them to prepare by pre-reading relevant content ahead of the meeting will ensure you’re only talking about the important details during the meeting.

Now you know that the fourth best practice for productive meetings is to require adequate preparation.

At this point, you have a focused and relevant agenda with the right, fully-prepared people invited to your meeting. You’re almost there! The next step is to make sure you’re actually running a productive meeting. Good meetings start on time. This ensures you will have enough time to cover all the important topics in sufficient detail. Also, meetings should NEVER run over time. Not only is this a sign of bad meeting facilitation, it is disrespectful to the participants and the people who need your meeting room after you.

You’re now ready to employ the fifth best practice for productive meetings, which is to start and finish on time.

Finally, it’s your job as the meeting facilitator to ensure the meeting is done well. Meeting Conductor is a good name for the person running a meeting since it’s their job to ensure the meeting is well orchestrated. As the conductor, you shouldn’t be a jerk but you should set the tone for the meeting. Call on people who aren’t participating to get them participating. Call people out for creating distractions. Keep people engaged in the specific item from the agenda rather than letting them wander. Most importantly, ensure that the meeting is conducted using all five of the previously mentioned best practices.

The sixth and final best practice for productive meetings is to be the grand conductor of your well-orchestrated meeting.

Meetings can be a huge productivity boost for your team because talking through important topics as a team is often the fastest way to get to great solutions. However, it’s very easy for them to instead become a major productivity drain. Follow these simple best practices to ensure every meeting is a valuable use of time:

1. Limit the number of attendees
2. Keep the agenda focused
3. Every minute must be relevant for every participant
4. Require adequate preparation
5. Start and end on time
6. Be the grand conductor of your well-orchestrated meeting

The Story

by Nick

"Ok, so can you tell me what does REST mean in the context of web-based services?"

This was the fifth "softball" question that Jake served out to the candidate Max Wilson. He had already asked the would-be developer questions such as:

"Explain technical debt and describe some things you as a developer can do to address it..."

"What is polymorphism?"

Jake even asked the granddaddy of all easy questions: "What have you been working on recently?"

He would've settled for the proverbial "I don't know" at this point but the interviewee seemed to have an insatiable appetite to make up answers based on the literal interpretation; even when when Jake used acronyms.

"Please, please, just say something related to web services, HTTP, RFC2616, anything!" Jake's inner voice urged.

Jake reassured himself that nothing could possibly out-do the answer given for the question on polymorphism. Max, moments earlier, declared emphatically that poly-morphism was writing software using different languages so that it could be "used" anywhere. Of course recalling this little gem made Jake's eye twitch.

Max was your run-of-the-mill nice guy. He was kind, easy to talk to, and seemed to have more than enough empathy to help drive product needs. Jake knew he just wasn't there technically and even worse, Max didn't know how to say "I don't know".

Jake was pulled back to thoughts when he was first getting started. He remembered how much he enjoyed the act of programming more than he did the theory or the lexicon of the industry. Back then he didn't know what polymorphism was even though he used the pattern in most of his early projects. Someone gave him his first break and somehow that made him culpable for any future developer who wanted to get into the industry.

"Uhhh, well you see it's when the server is not processing any requests and it goes to sleep to be efficient.", Max stated confidently. This response to the "REST" question pulled Jake out of his walk down history lane, shooting him suddenly back to the present as though he was a rock in a slingshot.

Once Jake's cognitive brain matched Max's answer with the only question that might fit he immediately muted the conference phone. Jake had difficulty keeping his internal voice, internal.

"REST, REST! Representational State Transfer. Chapter 5 of Roy Fielding's dissertation! The architectural style for hypermedia!" Jake announced with a sharp displeasure in his voice. Ranting these facts out loud did not serve as a catharsis for Jake; in fact it did quite the opposite - he found himself irritated.

Normally Jake was a fairly humble person. He often mentored other engineers and helped them advance in their careers. He often mused that he was growing more from those interactions than the mentees were. In this moment however, Jake lost himself. This was the fifth candidate this week he was interviewing instead of writing software or working with his team on their current sprint.

"I used to be good at this interview thing," he thought, "now I don't even have the patience to help this fella understand what REST really means!"

Jake passed on the candidate, which was no surprise, but something bothered him.

"Why is interviewing so hard?"

"Are facts, patterns, architectural principles really that important in determining if someone was a great developer?"

"Surely there is a better criteria or litmus test to determine if someone will succeed as an engineer!"

He spent the rest of the week basting in these questions and thoughts. He decided that the wisdom of the masses could pay big dividends in helping him solve this puzzle.

"What makes a great engineer?"

"What are the important soft skills of a great engineer?"

"What does success look like in our organization and on our teams?"

"What attributes do the engineers that others enjoy working with have?"

After a week or two Jake secured enough answers to begin grouping them into categories. He even went low-tech on his aggregation effort and pulled out a notebook and writing stick (people years ago called them pencils). Despite the judgmental looks he received for his analog efforts he pushed on. Once the work was done he discovered something incredibly shocking.

Jake's notions on what was grade-A candidate material had been quite a bit off the mark. He ranked the groups in priority order (based on which ones had the highest count and most emphatic responses). The output of this whole interviewer's pilgrimage were three distinct categories:

"Can the candidate problem solve?"

"Can the candidate communicate well?"

"Is the candidate genuinely excited about the problem space and technology stack?"

Jake noted that the last one almost didn't make the cut because the other two had so many responses it felt as though he was just adding the third one because of the rule of three.

He leaned back in his chair and glanced with satisfaction at his monitor. Admittedly he acknowledged that the feeling he had was a lot like writing elegant code that solved a hard problem. He'd never admit that out loud but he knew he was on to something.

Jake's next interview was in thirty minutes. With a smile on his face he confidently declared, "It looks like I'm going to need to be a little polymorphic and instantiate a different kind of interviewing attitude."

The Application

by Kirby

Interviewing is one of the most challenging tasks as a software engineer or manager. Nobody takes Interviewing 101 in school and many people never get training on how to interview well. Yet it's a vitally important aspect of building a great team.

For the past several years my role has been to build teams at fast growing startups. I've interviewed hundreds of candidates and hired close to a hundred people, maybe more. In many ways, much of my satisfaction as a leader is due to the people I hired and the teams they helped make better. And yes, there were a few regrets along the way.

Why interviewing is so hard

I already mentioned that good interview training is scarce. But more than that, the entire concept of interviewing is challenging by nature. You can't truly know people from a few short interactions, so every hire becomes a judgment call based on limited information. We are also inherently biased towards hiring people like us, but great teams are made up of unique puzzle pieces, not people cut from the same cloth.

Additionally, the construct of an interview itself is socially awkward. The candidate is usually in an unfamiliar environment, they are asked to talk about themselves, and they know that you are weighing every word they say and making judgments. Not exactly the most comfortable environment, is it? If you're new to interviewing, you might also be making it even more awkward for them.

Creating a relaxed environment

This is still something I'm learning to do well despite doing hundreds of interviews. But it's important if you want to actually get to know people. Your job, from the moment the candidate first steps in the door or onto a call is to make them feel welcome and relaxed. Offer them coffee or water. Give them a tour of the office. Talk to them about yourself and your role at the company. Practice small talk and really listen to what they have to say. Whatever you do, don't jump right into your first question. Instead, do whatever you can to put them at ease. Make them run a few laps around the office to relax. Ok, don't do that. That's a terrible idea. But you get the point.

Smile. A lot.

My natural facial expression is serious and intense, so I tell myself frequently to smile during interviews. Smiling will both make you feel great and put the candidate at ease. I can't tell you how many times a smile has elicited a more relaxed and thoughtful answer from a candidate. If they know you're enjoying the conversation, they'll be more natural and give you better insight into what they are actually like to work with.

Don't let anyone tell you that it's good to see what a candidate is like under pressure by putting them through a stressful interview. Just being in the interview itself is stressful enough. Treat people the way that you would want to be treated.

Listen. A lot. And take notes.

As I mentioned, interviewing is really important, so don't waste anyone's time by disengaging from the conversation. Your job is to really listen to what the candidate has to say. Oftentimes, a great follow-up question to their answer will give you deeper insight than their first answer. For example, a great technique is to ask for specific examples if they give you a rote answer. Tell them upfront that you're going to be asking for lots of examples.

Interview people about topics that actually matter

Whiteboard interviews. Ugh. Candidates hate them and they don't give the best insight into whether a candidate is a good fit for your role. Instead, focus on questions that are actually relevant to the everyday work they will be doing. Ask them about some tough problem you just solved and see if they could have helped you solve it.

Beyond that, you should interview people for your future success, not just your current problems. You will rarely talk to candidates who check off every single one of your requirements. But if they are solid and willing to learn and grow, they will be ready to solve your future problems.

Also, if you're interviewing developers, ask them to answer questions based on the language they prefer. It will give you the best insight into how deeply they understand what they needed to understand to do their previous job. That's a good indication of where they'll be when they come up to speed in your environment.

Coordinate ahead of the interview

Candidates are interviewing you as much as you are interviewing them. If every interviewer asks the candidate the same questions, you look bad. On top of that, you're wasting their time and your time. Asked and answered.

Instead, create a pool of questions across a variety of relevant topics. Assign each interviewer a topic area from the pool of questions. This will ensure you get broad coverage and that the candidate doesn't need to repeat themselves.

What to watch out for

Bias

We are all biased by nature, but being a good human is often about going above and beyond our nature. Avoiding bias is difficult, but here are some tips:

• Listen and take lots of notes. Don't take notes like, "They really blew this question." Write down what they said as close to word for word as you can. Don't make decisions during the interview but instead read your notes later in the day and process their actual answers. Snap decisions are the ones most likely to be based on bias.
• Use a prepared set of questions. Beware of bias in unstructured interviews. Compare the candidates answers to other candidates who answered the same questions.
• Don't let one or two answers be the determining factors.
• Avoid assuming that they're a bad fit Just because they answered a question differently than you. You're hiring people to make you better, so leave room for differences.
• Actually ask yourself if your negative opinions on specific questions could be based on bias. This isn't perfect, but just staying aware is a positive step.

Culture fit questions

It's important that candidates share your core values. For example, you might have a strong no jerks culture. You wouldn't want to hire a jerk. However, your goal in all of this is to hire people who make you better. That means they might bring something to your culture that takes you to the next level. So think about how they add to your culture vs fit your culture.

Making a decision

Ok, so you finally finished all the interviews and now it's time to make a decision.

It's important that you gather feedback from every interviewer. Many people like to schedule wrap up discussions with all the interviewers, but I've moved away from those over time. It's too easy to talk yourselves out of good candidates because one person noted one concern and others jumped on the bandwagon. Instead, I like to talk to each interviewer separately and look for themes. If something concerning was brought up by several people, then I'll dig deeper.

Also, don't talk yourself out of a yes because of one concern. Instead, follow up directly with the candidate about the concern. Don't assume because they completed all the interviews that you can't talk to them again. I've hired several great candidates in the past who I might have rejected based on initial interview feedback. They gave great responses to the concerns that were raised and ended up being great hires.

The Candidate Experience

I want to close by talking about the overall candidate experience. As I mentioned before, a good interview process allows the candidate to interview you as you interview them. Keep in mind what the candidate is thinking and feeling throughout the entire interview process. The way they are treated says a lot about you and your company. I've never worked at a company that pays like Google or Facebook, but I've been fortunate enough to hire a lot of great people. I believe much of this is due to a conscious effort to create a great candidate experience. Here are some tips:

• Respond to any requests from them as quickly as possible, but no more than 24 hours after they contact you.
• Tell them what to expect. Who will be interviewing them? What topics are you going to cover? How many interviews will they have? When can they expect to hear back?
• Give them ample opportunities to ask questions, but don't force them to ask questions at every interview.
• Be transparent through the offer negotiation process.
• Treat them with courtesy and respect. It's an honor that they applied, so be thankful.

The Story

by Nick

Jake leaned back in his squeaky chair and pushed his keyboard forward with his one free hand. The other hand held a full cup of freshly pressed coffee. He was lost in thought. Even the shrill screech of his keyboard sliding across his faux wood desk couldn't pull him away from his pool of reflection.

Another year had passed and he was soaking in his achievements and failures of the past year. This was a familiar ceremony for Jake; he would take a beat every quarter or so and reflect. The idea was to tease out any areas he might want to improve on. It was one thing he gained from some Scrum training he had years ago - retrospectives: what went good, what could improve, so on.

He was in the middle of swimming around one of his most humorous failures from last year when he was jolted back to reality by a voice. Jake was flung forward by the cheap springs in his chair's back which made him absentmindedly slosh coffee on his pristine "wood" laminated desk.

Jake slung around, eager to readout the cubicle interloper.

"He...y-Hey", Jake announced in a "tough guy" tone; then finishing out with a friendly "brotha!" when he saw who it was.

It was his keyboard cousin, Dan. These two were inseparable. They had shared career paths and met when they first joined the company 5 years ago. They pair programmed, gamed at lunch, processed problems together, made incredible software, and broke builds together. All of this was usually within the first half of the day. Dan and Jake had a type of implied trust that could only form at the heart of a volcano or during a planning meeting playing the MMS version of buzzword bingo. These two were INSEPARABLE.

"Hey buddy, how's it going?", Dan asked.

"Good, good... I-I think, unless you're about to change that.", said Jake in an almost expectant tone. Again, these two bordered on pre-cognition because of the time they had spent together in the trenches. Discerning Dan's facial and body language was second nature to Jake.

Dan straightened up into a formal posture and spoke using hand gestures; much like how Bill and Ted would force out a sentence without a "whoa!" or "yeah!"

Jake shook his head, knowing he was about to get a worthy rendition of Dan, playing Keanu, playing Ted 'Theodore' Logan.

"Ok, so we have been asked to spin up a 'most excellent' intranet."

Jake giggled, "He-he, uh ok 'Ted' so now what's the real word?"

Then Jake saw it, the spark of, "I am not kidding" in his friend's eyes.

"Dude, no way! Is this the 90's?" Jake moaned as he put his hands up to hide his defeated face.

Dan, not missing a beat, "Yes way!"

"Shut it, Ted!"

The next day they were off. The pair didn't even wait for product definition or scope. They would later realize that this was a big mistake. Strike one.

The both of them were feeling a bit displaced because they were expecting to begin working on the API stack for the next iteration of their services. Something that both Jake and Dan had devoted some heavy design time to in the last months of the previous year. They could almost smell the freshly baked implementations and mixtures of Kubernetes, Go, and GraphQL.

"Gahhh, it would've been so sweet!" Jake barked unintentionally out loud.

"Intranet! Hold on, let me break out my mixtape to help us get into flow." Dan quipped back.

These two generally tried to defuse bad situations through joke therapy. In this case that was going to turn out to be a mistake as well. Strike two.

They collectively decided that this "intra-web" could be done quickly and that they would be able to return to their normally scheduled programming of doing something "fun." Unexpected situations that were generally unwelcome tended to make these two buckle on upholding good solid engineering principles as well. They would also recount this as an error in judgment. Strike three.

Much like when Jekyll transformed into Hyde, removing sound judgement was the tipping point to things going monstrously wrong.

Their keyboards sounded like a Monty Python coconut steed.

"I've got the boiler plates and the landing page, " Dan touted.

"Solid, I'll pick up the blog components and team pages." Jake said confidently.

It was as though the two were working off of a virtual task board in their networked brains. This went on for a solid week or two and then the first mistake's reaper came calling.

The designer of the project stopped by. "Hey, fellas here's scope and designs for the intranet site; I've also posted links to all of this in chat. Product was super serious about us nailing this - it's for the executives so let me know if y'all have any questions."

The two keyboard cowboys slowed their typing so that the clicking was now distinct and discernible. They acknowledged him and both glanced toward the designs and then back at the designer with a nod of acceptance. The clicking intensified and returned to it's normal pace.

"So, you think we should have a look? They put in the work after all." Jake said half-hearted.

Dan, continuing to type, "We'll check them out later, we'll make sure we deliver close to what is needed."

They never did.

It was getting late and they were trying to wrap the project for a demo on Friday. Then Dan stopped. He was in need of that one thing that always looms as a developer stubs out a UI - content. They were both feeling a bit salty so they decided to break the tension by making up stubs of content to help round out the interfaces that they had been building.

"What should go in the main content of the landing page?" Jake asked as he opened the migration scripts.

Dan thought for a moment, "Hmmm. Let's go with a message that will really convey how important this is."

Hubris, not taking their work seriously, and joking. Here comes the second error waiting to explode.

At this point in time they should've both recognized that they weren't approaching this project with their usual integrity, dropping who they were as developers on the floor, and kicking their professionalism around indiscriminately - but they didn't. Their pride and lack of enthusiasm around this project would be their undoing.

Jake filled out the data migration script in the project. This script was meant to roll locally so that it would create simple placeholder text while they finalized some of the designs tomorrow. No "lorem ipsum" for this, oh no this particular project required special text.

Dan then dictated the following:

"IF ANY OF YOU FOOLS FOUND THIS SUPER SECRET INTRA-WEBS THEN YOU BE TREADING IN THE WRONG PLACE SUCKAS. YOU HAD BETTER WATCH YOUZ' STEP!"

"Classic" the two said in unison.

The pair continued to come up with hilarious boiler text as the night went on. In reality, it was only funny because the two were riffing off of each other's previous text-based creation and the fact that they were both in need of sleep. It was 2am and way past time to go. Jake hurriedly committed the file and then pushed the changes to a working branch, or so he thought.

git commit -am"adds migration scripts for temp content."
git push origin master

There were many things at play here, negligence being chief among the violations. Jake was working from a new laptop and had not setup git aliases yet so he had been typing out entire git commands. Instead of pushing the changes to their feature branch he pushed the migration and source to master. Which wouldn't have been a major problem since this was a new project but the previous week the DevOps folks published a new policy that would automatically deploy changes merged to the master branch to a staging location and drop the URL into the team\org chat of the resulting build\deploy. The idea here is that the more eyes on something before it went out to production the better.

The next day the two scooted in like a pair of cross country skiers; no real steps just slides along the dense carpet panels. Dan was the first to see it, only to respond to the sight by sucking in air with the intention of producing a sigh. Then Jake noticed it.

There was a crowd of managers encircling their desks. They didn't notice it right away but with each concentric circle the titles of the group became longer and more "important." The outer ring had their managers, then the middle one was populated with VPs, and finally the inner ring was populated by C-level folks.

Jake looked at Dan and said, "We either did something really good or..."

"...really bad", Dan said nervously.

From the looks on the encamped visitors it was going to be bad. It was too late, the groups had already spied the pair of sleepy skiers.

The CEO, Charles Gibson stepped out from the crowd and asked the two one very simple question...

"Can either of you tell me why I should 'watch youz' step'?"

The Application

by Kirby

When I was thinking about this topic and the message I wanted to deliver, it was all about how helpful mistakes can be. Most learning comes from mistakes. We mainly grow through failure and adversity. All that jazz. I wanted to convince you to actually appreciate your mistakes and to be thankful for them because of how valuable they can be.

But if I'm being honest, I hate making mistakes. I hate screwing up and I hate looking like I screwed up. I was thinking through the numerous mistakes I made in the last several years as examples for this story. Cringe. I was thinking through mistakes from my childhood and teenage years. Cringe.

Cringe. Cringe. Cringe. It barely lessens with time.

So I'm not in any kind of position to tell you to actively appreciate mistakes.

However, I can teach you how to systematically use your mistakes to learn and improve. You can appreciate the growth you achieve if not the trigger for that growth.

You need a positive system that you can apply when you make mistakes to systematically get better. Try not to focus your mindful energy on your mistake. You have plenty of time to do that at two o'clock in the morning when you suddenly jolt awake thinking about the stupid thing you said to that person that one time.

Growing from mistakes can be a simple process that you should follow regularly:

1. Admit you made a mistake
2. Understand the contributing factors that led to the mistake
3. Put in safeguards so that you never make that mistake again

Simple, right?

Admit you made a mistake

Admitting we made a mistake is the hardest part, but it's vitally important. It's difficult because:

• We may not think it's our fault
• We don't like to look bad
• We're worried about the consequences of the mistake

First of all, it doesn't matter if it's actually your fault or not. Simply admitting that you might be at fault or that you believe you made a mistake creates a fertile ground for growth. It creates an environment in which real discussions can happen about what needs to be improved. Real growth can only come from a trust environment in which people can be real with each other. Admitting that you might be at fault also opens others up to admitting their own mistakes as well.

When you build an environment in which mistakes are simply opportunities to grow, the worry about looking bad diminishes. It becomes much more about team processes, operational safeguards, and training opportunities. It takes it from "Kirby did something really stupid by pushing the big red button" to "why the #*$& do we have a big red button?"

There are certainly times where making a mistake can get you fired. Sometimes there are bad companies, bad bosses, demands for scapegoats, and people looking for reasons to fire people. Most of the time, though, a person's response to a mistake determines how much that person will be trusted. For example, as a manager I know people on my team make mistakes every day. This doesn't shake my confidence in them. What gives me confidence is knowing they are going to do the right thing and look for ways we can improve.

Diagnose contributing factors

Many companies build mechanisms for identifying the single root cause of mistakes that are made. This is fallacious thinking because there are usually multiple levels of mistakes that contribute to the final undesirable outcome. It's important to uncover all contributing factors rather than the straw that broke the camel's back. Otherwise, removing that final straw just means that another will be added back on top leading to the same outcome.

One of my favorite techniques to use is 5 Whys. First, I like it because it's simple. You start by identifying the mistake and ask why it happened. You use the answer to the first why to ask your next follow up question. You keep iteratively asking more and more detailed questions until you get to the biggest contributing factors. For example (NOTE: I shamefully pulled this example directly from Wikipedia since it's so good):

The vehicle will not start. (the problem)

1. Why? - The battery is dead. (First why)
2. Why? - The alternator is not functioning. (Second why)
3. Why? - The alternator belt has broken. (Third why)
4. Why? - The alternator belt was well beyond its useful service life and not replaced. (Fourth why)
5. Why? - The vehicle was not maintained according to the recommended service schedule. (Fifth why, a root cause)

I also like it because it can be repeated to uncover all contributing factors. For example, you may branch off of any of the "why's" to dive deeply into multiple areas. Every "why" is a contributing factor that can be protected against.

Prevent repeats

We all make mistakes and many of them are outside our control. One might even argue that no mistake is under our control since most people don't willfully make them. The important action that people and teams need to take is to work to prevent repeating mistakes since prevention is inside our control.

For example, let's use the 5-why analysis of the vehicle that won't start. In the 5th why, we identified that the vehicle wasn't maintained according to the service schedule. That's an easy fix. Just follow the schedule! But it's also easy to see how it could happen again. You might not know the schedule or you simply might not notice that the odometer has rolled past an important milestone. So maybe you add a note in you calendar to check your odometer and your maintenance schedule as a repeating event that nags you until you do something about it. That's a step for prevention that recognizes that people are fallible.

Also, it's important that others around us learn from our mistakes. One best practice that I love is creating a collective Lessons Learned wiki page where people can document what they learned from their mistakes. It helps the collective whole get better so that prevention spreads positively. Also, importantly, it's something that we can reflect upon. When you look back at all the lessons you learned, you can appreciate where you are at today compared to where you were at when you made each mistake. It's hard to see your own personal growth unless there's a baseline to compare against.

Summary

I tried to avoid using the cliche of too err is human, but it's a cliche for a reason. It's a fundamental truth. While we might always struggle to embrace our own mistakes, we can build simple mechanisms to learn and grow from them. We can learn to appreciate how we've grown from our mistakes. It's the anti-cringe, and it's something to feel great about.

Photo by Kyle Glenn

"So who's got this one?", uttered the project manager while pointing at a woefully underthought user story on the screen. Disinterested engineers looked sheepishly around, lifting their heads just enough to avoid eye contact. This was common in planning meetings. Lack of interest and ownership would suppress the opinions each of the team members had.

Jake put his hands to his face and was on the edge of giving up and moving to Idaho, you know the whole working as a farmer thing seemed really appealing. He began to raise his hand to reluctantly grab the story when someone else spoke up.

"I'll take it; I'm unfamiliar with that part of the code." Sam said energetically.

Sam was always good like that; ready to take on any task or try anything new or old. She started her software development career just over a year ago and hadn't slowed down yet. Jake liked being around Sam. She glowed with excitement about everything to do software. She'd take hits and hard times just like everyone else, work on projects destined to fail, and pick up tasks that she knew she could automate. She recognized the value of being available and owning things.

Though Jake had been in the industry for close to 20 years everything about the what and how Sam did things made him want to be a better engineer. He wanted to behave more like her, be more excited like her, and be a catalyst for involvement just like she was. Jake took every opportunity to make sure he communicated how valuable Sam was both directly to her and to management.

Jake thought, "Why is she so different?" He even wondered, "Can engineering excellence be bottled somehow?" He decided to take some time to find out why Sam was so excited about software.

Jake stopped by Sam's desk. As he walked up he noticed how immaculate and magically fun it looked. "Another page from Sam's book that I could benefit from" he thought.

"Hey Sam, sorry to bother ya, do you have a minute to grab a cup of coffee?"

"Sure do", Sam replied clicking in the last few characters of her latest masterpiece.

"Solid!" Jake touted, "I wanted to ask you some questions around how you like to approach things. Things like why do you get so excited about writing software and so on."

She jokingly replied, "Awesome, maybe we can figure that out together"

This was yet another one of Sam's superpowers. She not only owned the software she wrote but she owned her character and worked hard to "refactor" it whenever possible.

They sat down in the sprawling co-work space, surrounded by comfy chairs and coolers filled with every flavor of La Croix water imaginable. That was the current "hip" thing. Jake thought in his best old guy comedic voice, "back in my day we drank the Kool-Aid, not this fancy water." He grinned at his own joke.

Sam was looking at him as he smiled and said, "that's why."

"That's why 'what'", Jake quizzed.

She smiled as though she knew Jake's joke and said, "That's why I get excited about writing software; it makes me smile."

At this point Jake knew this conversation was going to get good - "...really, good", he thought. He searched around for a spot where it was safe to talk a little loudly and with expression. They both loved to talk with their hands and tended to get a little loud when talking about things they were excited about; this was one of the things Jake noticed about Sam when he interviewed her last year.

They sat down in a couple of multi colored chairs that swallowed each of them as they leaned back. "How cliché or perhaps ironic", Jake mused as he shook the confusion from his head, "We are sitting in a spot that some detached person 'designed' to build collaboration and culture to genuinely talk about those things." He decided that he would, in the future, judge the cliché of their office space a little less.

Jake continued the conversation, "I genuinely love working with you but I cannot always put my finger on why. I want to figure out the why so that we can propagate that out to the team; bottle it somehow." He was joking about the bottling it but wanted to get at what made working with her so fun.

Sam spoke in a humble and thoughtful tone, "I love to build things. I'm not the 'best' at it so I take every opportunity to learn and grow."

Jake new she was totally being genuine and he also knew she was "better" than she thought.

"There has to be more than that. Right? I...I mean you'll eventually get to the point where learning things is enjoyable yes but there would be fewer things to learn." Jake mindlessly replied. Later on after their conversation was long over Jake would come to realize how ridiculous he sounded because at that moment he was learning and growing.

"I hope not!", She exclaimed.

"Jake, I once went to a talk on culture, 'Nerd Life' something, and the guy talking said something like 'passion does not have to have a reason, it is its own reason.'" She took a beat to consider her next thought. "I know it sounds like a cat poster, but it made me think about how I wanted to see what I did. If I was going to do this software thing and spend a lot of time learning and building things why would I want to do it half-hearted."

"Listen Jake," she paused, "If we are not going to own the things we build then why are we building them?" Sam continued, "Things like feelings, making money, even desire will only take us so far so long - there has to be a bigger driver, a better purpose."

Jake crushed under the weight of this thought. He began remember how much creating things meant to him. He remembered how much fun it was to share those things. He remembered that owning the software he's part of was much more than just writing more of it or supporting it. In the following days Sam and Jake through caring, attitude, and deterring poisonous behaviors began to help reform other lost developers.

Soaking in their conversation, Jake milled on his new revelation: Sometimes owning software just means being available, caring about your craft, and getting others involved along the way.

Ownership, it ain't about possession

Ownership. Its one of those words where the true meaning goes well beyond the dictionary definition. In the world of words, it simply represents that something belongs to someone. It's almost a passive act. In the world of leadership and entrepreneurship, it means so much more.

True ownership isn't about whether a thing belongs to someone; it's about what the owner does to nurture and care for it. It's about the person and their actions, not possession.

It doesn't matter what you own or its value. Let me challenge you to do something. Take a drive around your town and really look around. Look at every house, every yard, every front sidewalk, every front door. Look at your neighborhood parks and gathering areas. Look on the side of the road.

I bet you'll see some modest homes that are extremely well tended and some huge homes that are out of control. Which person is showing true ownership? Which person do you think is leading a more fulfilled life?

What else do you see?

• Do you see someone weeding or planting flowers or cultivating a garden? That's ownership.
• Do you see someone going out of their way to clean up someone else's litter? That's ownership.
• Do you see someone sweeping a sidewalk? That's ownership.

Notice that many of those examples don't require possession. Possession may be nine-tenths of the law, but it's only a prerequisite to true ownership. True ownership is about owning the greater whole and taking accountability for it being great.

The importance of ownership

I would boldly assert that there is no product that people truly love that did not come from a place of strong ownership. Have you ever used a product and been delighted by something really simple? Something that just works the way that you think it should?

Steve Jobs famously said, “Simple can be harder than complex: You have to work hard to get your thinking clean to make it simple. But it’s worth it in the end because once you get there, you can move mountains.”

You can do it complex. You can make things work by simply doing. But you're never going to move mountains. True ownership means sweating the details and caring about what you deliver. It means going above and beyond simply because you care and show a pride in what you do.

Again, it doesn't matter how big or how small it is. I love working with teams that deliver tools for internal customers because they can do small things that make their neighbors' lives just a little bit easier. These teams often show a high degree of ownership because they build a lot of empathy.

With true ownership, you can trust that your teams are going to do amazing things. Sure they'll make mistakes. They'll sometimes take a wrong path. But they'll always course correct because ownership requires that they keep making things better.

True ownership also means that teams and individuals will go above and beyond their explicit area of ownership. If you want an environment of "see something, say something" or better yet "see something, do something" then you need a culture of true ownership.

Why your team might not be demonstrating true ownership

If your team is not demonstrating true ownership, you must figure out why. Start by looking for signs of complacency. If there are aspects of your culture that are contributing to complacency, fix them. That's a first, important step.

Next, investigate how decisions are made in your organization. Top-down leadership is the antithesis of true ownership. The decision-makers by definition are the owners, so if individuals and teams aren't empowered to make decisions they can't own things. It's that simple.

Finally, you might be thinking that it's about the people. There are certainly some people who by nature don't demonstrate true ownership. If that's the case, you must do something about it. However, most people don't start out jaded or uncaring. Oftentimes the environment is the bigger contributor, so start there.

Don't try to fix it with process

I'm a process person by nature. I love to improve the way we do things to enable people to do their job more easily and more effectively. But there's a real danger wherein process kills true ownership. The danger is in making it about the process, not about the people.

People own things. Actual people. Don’t cede your ownership to a process. If it becomes about the process, you create a bureaucracy. You no longer own it; it owns you. Instead, look at process as an ownership enabler. If your process isn't making it easier for people to own their own progress, it's broken.

Trust me on this one. This is a mistake I've made in the past, and I see teams making it every day. For example, in many ways the rituals of agile software development can contribute to this. So many books talk about process and rituals and tools, or at least that's where people focus when they implement agile. If your first instinct when implementing agile is to schedule all the rituals and buy all the tools, take a deep breath and slow down. Instead, focus on the people and what those meetings and tools will mean to them. The rituals and tools aren't inherently bad, but they can be if they're the only focus.

Fostering a culture of true ownership

With a culture of true ownership, your team will make great things happen. True ownership requires four ingredients: clarity, autonomy, empathy, and ability.

Clarity

It's important that teams know what exactly they own. In your own life, it's easy. You bought your house, so you own it (after you finish paying of course!). In a software organization, it's a bit harder. It requires understanding all your products and every logical component that make them up. It's important you carve up your entire inventory and ensure every part of it is owned by someone. Otherwise, it's owned by no one and things will fall through the cracks.

Once your products are mapped to teams, this is where ownership really begins. Teams should own their vision and mission, their strategy, their goals, their metrics, and their roadmaps. They should make sure what they are doing is aligned to the broader organization, but they should own it.

Which brings us to autonomy...

Autonomy

You can't have ownership without autonomy. Otherwise, teams won't be enabled to take the actions they need to take to nurture what they own. If they need to seek permission every time they want to make improvements, they'll gradually lose their motivation to do so. If they are told what to do, they'll immediately lose it.

When you relinquish control to a team, you are literally giving them ownership. Along with autonomy comes accountability. Now it's up to them to truly own it.

Which brings us to empathy...

Empathy

The third ingredient is empathy. Empathy's a different kind of ingredient because it's a trait of the people on the team rather than a structural concern. However, it's just as important as clarity and autonomy. Empathy fosters ownership. It's really hard to not take action when you see actual people struggling with what you built. Empathy is a learned behavior, but it's very easily learned. Watch people use your product. Talk to them and listen to them. Follow the twitter feeds and your support channels. Read all the forums. If empathy doesn't already exist, it can be gained.

Which brings us to ability...

Ability

The final ingredient is ability. Before establishing clear lines of ownership, you need to ensure the owning team is able to own it. This may mean investing in their skills or in hiring more people to adequately own it. The good news is that teams that want to own things will figure out how to do so even if they don't possess the skills today. You just need to support them.

Caution

Ownership is great and all, but there are a couple of areas of caution worth mentioning.

First, as a reminder, ownership is not about possession. Therefore, the first caution is that ownership should never be about territorialism or politics. True ownership is something that spans teams and organizations. In a great culture, it's not about "mine" even though lines of ownership should be very clear. Ownership is about who is responsible for nurturing and fostering aproduct or an area, but everyone should be encouraged to make improvements that cross teams. Teams should consider the broader whole, which could mean helping others with what they own first. Remember the example of someone cleaning up another person's litter?

The second caution is that people who naturally demonstrate a lot of ownership will try to take on too much. You remember all those great examples of people caring for their homes and neighborhood? Personally, I'm not great at doing that because I regularly take on more than I can handle. It's better to own enough to be challenged but still be able to manage it. For organizations, this means that you should consider smaller more focused teams rather than teams that own tons of stuff.

The final caution is around collective or — shared — ownership, which is a model where everyone owns it together. This is a great theory based on the fact that everyone's part of a community and thus they should all be incentivized to make it better. You might even think it's a great idea after reading the first caution. In practice, though, I've witnessed it lead to one of two bad outcomes.

Outcome #1 is that collective ownership actually turns into zero ownership. People assume that someone else will make it better so they do the minimal required to meet their needs. That's not true ownership. It leads to frustration and poor results.

Outcome #2 is that you get too many cooks in the kitchen. With collective ownership, there is little vision or direction setting. This can lead to anarchy, mixed visions, multiple divergent approaches, and difficult-to-resolve conflict within the team because it's unclear who makes decisions. Like a rope being pulled in a round of tug-of-war, the software will show divergent approaches and goals and lead to a mess.

So to avoid the final caution, ensure that there is only one true owner for each of your product or services. If other teams want to propose changes via pull requests, then great! But the team that owns the product or service maintains responsibility.

Summary

True ownership isn't about possession. It's about taking accountability for making the things you own truly great. It is an act of nurture that can be cultivated in an organization, and the more ownership that teams demonstrate, the healthier the organization.

Nurture it. Foster it. Make it so.

image courtesy: NASA

Black canvas. So dark that he had trouble seeing the outlines of his shoes, they were black as well. The scene almost perfected by the dark logo'ed shirt Jake decided to wear on his first day. Perhaps it was a bit too ominous; the darkness and all. He was petrified. Not like the "I can't breathe frozen state petrified" but the "I am so out-classed staring into the black abyss of the pavement petrified."

It wasn’t the lack of understanding how he got there or even that he was joining up with some of the company's most incredible engineers that gave him pause, no...no. You see Jake, like most, was an impostor and this impostor was about to start something radically new.

You could almost hear the neurons firing clumsily through his brain like an old cap gun. Pop...pop, snap! He was trying to comprehend why he was allowed, nay, blessed to work at this company with this new team. This made him feel sluggish and uneasy.

It all started four weeks ago…

“Jake, you seem lost and distracted, you need a change. Some fresh paint maybe?”, his wife quipped. She often spoke in paradoxical shades like that - calm and brutally percise, like a hitman.

He responded in a pessimistic tone, “Yeah, but all the jobs I’d like to do... well, I just don’t think I’d be ‘good enough’”

“You aren't.” She struck back. Head-shot, well placed ma'am.

You could almost see Jake stumbling in his thoughts to process what she just said. He looked at is wonderfully "supportive" wife and she had grin on her face as though she was playing the role of the Cheshire cat.

Jake was befuddled. He finally managed to get some words out, “Wait, what?”

There was a patient pause before she reiterated her point. His wife was like that, patient, calm, loving, painfully accurate; Jake knew he married an incredible person, but she was about to prove it.

“You aren’t” she repeated. “Listen Jake, you’re incredible and a genius but if you wait around for being ‘good enough’, you’ll never get there. 'Good enough' is a bar that you set arbitrarily; it's like trying to deliver perfect software - it just doesn't happen and it's a line that keeps moving.”

"Man, she's good, too good..." Jake thought as he squinted his gaze in suspicion.

Still a bit puzzled, he affirmed what she was telling him. “I’m almost with ya, keep talking, I think I know where you’re going with this.”

She went in for the coup de grâce, “Go be stretched.”

This conversation, was of course, the catalyst for many more like it. Jake had a new perspective. He began to realize one of the biggest challenges at his current job was that he was not challenged. Life has funny ironies like that. He became disinterested as well. These things happen for our benefit; mostly to remind us that we are living so don’t stop breathing!

About a week after the cataclysmic “you're not good enough chat” he wrote seven emails to seven internal managers of teams hoping they'd have a role for himbut fearing they wouldn't. He staged them all, changing bits and pieces here and there to fit the what role he was interested in but Jake always remained candid, honest, and forthcoming. Those qualities, he thought, were rarely seen in the software development landscape and often only in open source projects where there’s no jockeying for titles and pay checks.

He hit SEND quickly on all of them before he could back out. You could almost feel the bits pulse away - the "pulse" really his heart trying to beat out of his chest. He was trying to leave something comfortable, something known, something he helped to get off the ground.

Was he committing some sort of treason against himself and those on his current teams? Treason, what an odd word. It almost buckles the tongue when it’s said; like you’re getting away with something and sounding smart while you do it - like an impostor.

Turns out his skills, personality, affinity for honesty was highly sought after. Six of the seven managers all responded within a day's time. The seventh probably would've responded but Jake fat-fingered the recipient's email address and it bounced.

He jumped quickly at the machine learning and data team position - he new a few folks from that team and the problem space seemed wildly challenging. He grinned, in his heart it felt like he was going on a first date or giving his first tech talk; he was walking into the unknown with people he wanted to walk along with.

Back to the present…

Here he was "The impostor." His footsteps hidden in the dark pavement he was walking on. It was almost spy-like, sans the cool demeanor and well, everything else. Jake had a genuine dorkiness about him that people seemed to love. This made the whole impostor thing taste a bit like irony. He felt as though he was about to reveal himself like a bug does in production (to everyone who comes in contact with it) despite having nailed all of the interviews and impressing the team with some solid ideas on how to build online learning systems.

You see, Jake didn't know it just yet but it wasn't the "real" Jake who was the impostor it was the idea of himself that was counterfeit. Looking over his shoulder Jake saw some of his new teammates getting out of their cars and heading toward the door.

3...2...1… he pulled open the door and walked nervously into his new role.

See practical applications in my friend Kirby's post Sometimes it is time

When Jake realized that he had been staring at his screen as if it were one of those autostereogram images (where a 3D scene is encoded in a series of dot patterns) for the past 20 minutes he jolted upright. Even his physical demeanor was communicating that he had the weight of something on his shoulders. That something was complacency.

Heavy, muddy, exhausting complacency. He wore it so well his teammates could've mistaken him for an extra on the Walking Dead TV show. "What am I doing," he quipped. His face was in his hands and he was finding it hard to breathe.

He just took a really hard hit last week dealing with the challenges of technical debt. Complacency was the thin line waiting to break that made Jake question everything about being a developer. He knew he was being emotional and had lost all reasonable perspective.

He had shifted from the well-thought pragmatic developer to an eruptive, chaotic one and then moved on to a smoldering wasteland of an engineer; much like a volcano does after it blows its top.

One of his teammates swung by on her traditional Friday lunch round up.

"Hey, you look like you could use some lunch", she administered in a medical-like tone.

He replied, "Or a lobotomy."

"Sheesh man, another day of meetings and no code?" she inquired.

"Yeah", he replied.

Jake wanted to share that he hadn't worked on a line of code all week outside of other developer's pull requests and code reviews. It was as if the other engineers were mocking him by asking him to review the code they wrote while he sat in meetings all day. He even stopped contributing actively in meetings. The complacency set in like rot in an old piece of wood.

It had been chewing at him for a good while now. He knew something was really wrong because of the physical manifestations, such as not being able to breathe, being tired all the time, lack of focus, diminished desire to code, and feeling like others were against him.

The truth was that Jake had reached a point where he began to tune out and fade into black. He felt lost, without purpose, and had no idea what to do about it.

"I'm done, " he thought, "I'll do something easy like farming." This made him smile a little, he knew farming was really difficult given his uncle was a dairy farmer. He thought, “They have to work really hard but no one tells the cows to produce more milk faster despite having cow meetings all day! Perhaps the cows...”, he decided the metaphor had gone far enough.

"How did I get here!" Jake's inner voice asked. "I genuinely don't think I like writing software." He walked away from his desk and decided to go home.

He spent the weekend asking himself probing questions:

"How did things get this bad?"

"Do I even like writing software?"

"Did this happen over night?"

"Am I burned out?"

"Should I leave my job?"

"Why do I no longer feel a conviction to write great software?"

"Why am I complacent?"

He returned to work with few answers to his questions and even less energy, the poi’s ion of complacency was still running through his veins. It was super early but he knew his lack of energy had nothing to do with the time of day. Cracking open his email he blindly struck the delete key and rolled through his messages like a whack-a-mole game. Then something caught his eye.

"URGENT: Can anyone in engineering help me fix this bug!", read the title of an email destined for the whack-a-mole ax.

“Wha..what’s this...”. His zombie-like facade almost looked as though it was falling off like a snake’s skin.

Jake came out of his depressed slouch like Geppetto pulling the strings of a puppet; first his torso, then followed his hands, and finally his head. He sat upright as if he had a secret to tell the sender of the email. He leaned in and felt his heart jump, "I can help!" he shouted. He sheepishly looked around to see only empty chairs acknowledging his call to arms.

"Thump, Thump!" His heart was racing, but this time it wasn't due to anxiety, it was because of excitement. "Man, I haven't felt this excited about fixing a bug in a really long time!" He physically felt better as he created a feature branch, and began fixing the code! "C", "O", "N", "S", "T" the keyboard called out as he initialized another variable and then he paused.

"Wait a minute...", a thought rushed through his head, "what's going on here?!?"

He couldn't escape it. It was like realizing he just clicked on a link in a phishing email and quickly wanted to close his browser. "Shouldn't I still be feeling miserable?" These past few months had been brutal to Jake and he knew it; what changed?

In that moment he realized a tremendously important truth: What happens at work or even in life should not constrict who Jake really wants to be and do. It's how he responds to those circumstances that make the difference.

He continued on to work on the fix acknowledging that he just had an "after school special moment. Jake also knew he was not done with the pit of despair and working on a simple bug was just a digital Band-Aid.

Things needed to change and he knew exactly who he needed to talk to about using his most important tool in his belt, "NO", to help restore things to what they needed to be.

See practical applications in my friend Kirby's Complacency, the silent killer of products and companies

He looked at his cursor in vim, his code editor of choice, as if it was going to write the code for him. Jake was an average guy, inspired developer, lover of coffee and JavaScript. Pragmatism seemed to be part of his DNA. Today he felt like he was throwing all of that out the window.

Earlier that week one of the executives, a "C"-something, got beat up on Twitter about a competitor's feature set. Usually the executive would just acknowledge the harsh comment and thank the person for their time and thoughts. He might even make a note if it was something he deemed valuable; but today was different.

Crashing through the narrow entry way of Jake's office, in a Kramer-like fashion, Cameron, the CTO had an intensity that both inspired and confused Jake. He began barking, with an intelligible tone.

Cameron, pointing at a printout of a tweet (because executives print out that sort of thing), "We've got to do something about this!"

Jake shrugging, "About what?"

"We don't support 'export to pdf' from our doc product and these other 6 competitors do!" Cameron replied.

That's when Jake knew it. He had been a developer long enough to know when he and his team were about to be asked to consciously add "rust" to their software. They called it rust because it was technical debt. He knew that these nasty bits of code that get added either knowingly or unwittingly would generate problems and holes in the source overtime. These are things that he and the team were ashamed of but still tried to defend for whatever innate need a developer has to justify their bad choices.

Jake knew the "Technical Debt Quadrant" well. "The words "deliberate" or "inadvertent" would run through his mind after shipping something. He knew this time it would be "deliberate." He also knew that he and his team would be asked to deliberately choose reckless engineering practices, forgo testing, and build something that would require a huge amount of effort in a small amount of time. Finally, he acknowledged that the state of the current code already had rust all over it; a veritable case study for the idea of "interest payments" from technical debt.

Jake sheepishly hung his head low and simply said, "ok, we'll get started right away."

Grappling with the fact that the team wouldn't get to embrace decent engineering practices such as TDD - Test Driven Development or clean iteration cycles they were constantly fighting off feeling regret over taking on the project. "This project 'smells' and 'tastes' like regret, " Jake thought.

Initially the project seemed to be going really well, despite how it "tasted." The team provided short bursts of effort on the disorganized project plan they were given. The product team was dealing with just as much uncertainty as the development team. "Push through," they thought, "this has got to work!" Though, if you asked any of them they really didn't know why they were doing what they were doing. Lack of vision and knee-jerk decisions tend to muddy the creative pool and hurt morale.

Then the proverbial wheels flew off of the project scope first.

Lack of planning and clarity of goals finally made the project buckle. Any engineer worth his or her salt knows loose scope is scope that grows and creeps like a monster under your bed waiting to grab at your ankle and pull you under. No fun, no good.

Constant collisions with concepts and project scope changes made for a miserable experience as well. Lack of focus and a blurred vision made rolling with these changes difficult and daunting - no one seemed to know where things were or even where they were heading.

In the coming weeks Jake and the team pushed on, running into merge issues because other teams, ironically, were refactoring the same area of the code that they were working in to try to pay down some of that technical debt. They ran into massive regressions for the same reasons - code collisions and rust.

"Rust, rust, rust!", Jake thought as he stared at his console. He simply ran out of mental capital; he could type no more or even think clearly. He had to stop a project that was almost finished to work on this "trash fire" of a project using another kind of TDD - Tweet Driven Development.

He regretted every new line he wrote. He even hated solving that complex serialization issue which was a critical stepping stone to them supporting the export to PDF feature. This reasonable engineer had not written one single test for any of the code he had committed and most of the lines and method bodies had lint rule overrides to ignore the engineering styling rules that he helped put in place a year before. He was a shadow of the engineer that he once was.

Jake had heard about this type of "fade" happening to some engineers in the gaming industry but had never experienced it himself. "What happened?", he puzzled. In that moment he saw a note he took while talking to a mentor years ago...

"'No' is your most powerful tool in your belt, use it often before you find yourself needing more tools and more time to fix something 'no' could've fixed for you."

See practical applications in my friend Kirby's Technical debt and the lies we tell ourselves

Title image courtesy of Berry Pousman via flickr

There have been a series of break-ins and thefts in our neighborhood recently. There is no set of signs or events that seem to point to the source of the increase. My wife said it best while she was talking to a friend. The conversation went something like...

Wife: Our HOA has been sending out notifications about break-ins recently.
Friend: Oh wow, that's no good!
Wife: The fact is that it happens everywhere, crime does not have a place or time it's just always happening.

That's so true. We know that we should not walk through this life in fear but we also know we don't need to check our brains at the metaphorical door that could be kicked in either.

The truth about break-ins

Let me drop some statistics that the good folks at Haven put together from the FBI and The Alarm Industry Research and Educational Foundation (airef).

Were you bothered by those statistics? I was too. Were you surprised? I wasn't. It's easy to see things like this happening around us. So now what? Head for the hills, move, hide in a cave? Nope, remember "crime doesn't have a time or a place."

A little perspective

After pastoring a para-church in Portland, OR for convicted felons, homeless, etc... our friends in the congregation over the years explained how easy it was to break-in to places in detail. They made it sounds simple, lacking any real effort at all. I was dumbfounded. Having grown up on the east side of Fort Worth, TX I saw crime all the time as a kid. It was a terrible part of town and we couldn't get out of it. I remember coming home one day from church watching a shady character leap from our house window and run off with whatever valuables we might've actually had - it was scary having to deal with not feeling safe as a child.

Fast forward to October 2018 (now living in Texas). Our friends around the neighborhood began posting videos of people breaking into their homes.

I recounted how I felt when I was a child.

I ordered a Haven Connect lock. Not out of fear but out of pragmatism and duty to my family. We resolved that we were going to be smart and safe. You see, I did the whole 3 inch screws in the deadbolt plated on the frame but I knew practically that would still fail based on the research and videos that I had seen recently. We needed something that was proven and well made.

A bit on the company

On September 24, 2014, a Tennessee company named Haven launched a kickstarter. I remember wanting to back the project but never did. Later, after the kickstarter was finished (with funding unfortunately unsuccessful), I considered a preorder after seeing a fella named Zeus lay waste to a door protected by a haven lock. I just didn't appreciate the value and importance of what they were offering.

They are based in Tennessee and their CEO, Alex Bertelli, is a decorated veteran, and is a guy who genuinely cares about protecting our families. They employ skilled Tennesseans to craft the locks that keep the bad guys out and they give back to our warriors and their families by supporting the Special Operations Warrior Foundation (SOWF).

They not only make products for residential and businesses but they have an incredible product to help protect children at schools as well.

You can read more about the company on their website but know they have a heart and a passion for keeping friends and family safe and they have the track record to prove it.

The install

While the install was simple and straightforward I did have some problems. I submitted a ticket and tweeted the company explaining things after my lock failed to engage. It was Friday, I expected to see an email sometime in the middle of the following week.

Do you remember my comments about how much the company cares for our family's safety? The phone rang not an hour or two later and it was Alex, the CEO asking if I wouldn't mind troubleshooting the lock with him. After rolling through a handful of different approaches, Alex said, "I get a new one out to you rigth away."

That's attention, that's standing behind every product you make, and that's genuinely caring about the people you're helping through your products.

It turns out the issue wasn't with the device at all, just with my mindset.
What I mean is, when putting the six steel screws into the plate I was a bit liberal with how tight I tightened the screws. If any of y'all have perused any of my past builds or projects (or are familiar with my tendency to gold-plate things: see FutureStack talk for more details) you'll know that I have an "If it's worth doing, it's worth overdoing" mindset. My fault! I imagine the author of the install guide never would've anticipated my need to push products to their edge. I reached out to Alex again and true to his character he simply said "no worries we'll update the docs with a note to not over tighten, we want to make sure your family is safe."

The pros & hopeful changes

These are simply my opinions on my experience with the Haven Connect. I wasn't paid to say these things or been influenced outside of my experience with the people behind these devices and the device itself.

Pros

• The people - they care, a lot! (just read above)
• You can tell the product is high quality the minute you put your hands on it. I even felt it would be effective as a weapon to swing at any intruder - it felt strong and heavy.
• Setup (once I backed off my super powered install) was super simple, 10 minutes, possibly less.
• The directions were clear and concise
• When the lock is armed no one will be coming through the door, I mean no one. I have seven kids (4 boys) and they stop for nothing - except this lock.
• The Bluetooth connectivity rivals my August lock. It's fast and responsive.
• The app (iphone) is super simple to use and setup
• The manual arm and disarm is super handy and easy to use
• It holds a charge for about 3 months and takes roughly 6 hours to get a full charge
• Did I mention, when the lock is armed - no one is coming in...

Hopeful changes

• The charger for the device is proprietary. It would've been nice to see a micro USB here or something like it. I am bound to lose the plug.
• The admin panel on the device opens facing the door which makes resetting or applying firmware on the device a bit clunky - it would be nice if the plate opened toward the inside of the house.
• There is no internet connected unlocks but it looks like there is something called haven hub (bottom of the page) in the works - this might be a solution for that.
• There are currently no IFTTT recipies for Haven. I need to get coding. It would be nice to add the Haven locks to a lockdown command.
• The locks can seem expensive but they are always running promotions and the device is well worth it in my opinion.

The tips

Here are some tips that I pulled from the install experience that I hope you benefit from when you pick up one (or a few) of these locks. First and foremost, follow their excellent guide.

#1 Follow every step laid out in the install guild

By doing this, like running a full charge, syncing with the app, priming the lock, so on you'll have a much more pleasant install experience.

#2 Use a good masonry bit if you're drilling into concrete

Don't go cheap here. I was going into wood flooring, with an inch of concrete board and then into the slab. Use a 5/32" x 4 1/2" masonry drill bit meant for 3/16" concrete screws.

#3 Use a corded/electric drill if you have one

I use a trusty Dewalt 10-amp pistol grip drill. It goes through concrete like butter - remember: if it's worth doing, it's worth overdoing.

#4 Wrist tighten the screws

You'll know that you've overtightened the screws if the lock does not stay engaged when locking it using the App. It will simply raise up then close again - too much tension does not allow the locking mechanism to engage.

#5 Check the nylon straps

I missed this one as well. When securing the Haven lock some of the threads from the nylon staps can get caught in the threads of the screws or the straps can get bunched up. Avoid this by making sure all of the nylon segments are evenly distributed and pulled out of the way when installing the screws.

#6 Use the Apps

The mobile app is super simple to use and you can do things like hand out temporary keys or set up household users.

Haven you're the best

Thank you for making a great product Haven! I hope that you continue doing the good work of protecting families everywhere!

I have a confession to make. Ever since I was really young I never really enjoyed reading.

Early on I tried to read Homer's Iliad, Beowulf, many of Shakespear's works and the like. My parents were just like that, classic education and all that.

I didn't understand them; allegory and symbolism were lost on me and I felt like those books were simply laughing at my simple mind.

My love of reading and writing has been a roller coaster over the years. For instance, when I was doing research for my book Nerd Life Balance I couldn't put books down but when the project was finished I lost the drive again.

Recently I've been talking about doing a new writing project with a good friend and we've had some road blocks getting kick started.

I have found that when inspiration or creativity wanes it is because I have been neglecting my reading muscles. So in the interest of electrifying my mind, I have created a little game that I wanted to share. It is simple and it has one purpose with many side effects. I call it The reading torrent. The rules follow.

Number of players

1 (but extends and is influenced by the primary player's social circle)

Purpose

To get the player reading and enjoying books (books that the player may or may not normally read) in a regular cadence.

How to win

Fill up the second shelf (see below) with the books that you have read end to end.

The game pieces:

• The player some one who is willing to put some effort into growing as in individual
• Books, lots of them (the player can start with one). In this game, it is ideal to use physical books because they will help you know when you have "won."
• 2 empty shelves in a book case (or something like it with a finite width where books can be placed)
• Some method of social sharing or interaction (this is how the player will share what they read or get more book ideas to read)

Setup:

1. Start by wiping out games and apps of mass distraction from your mobile devices (even social apps). This will be physically painful at first but you can do it!
2. Clear off the two shelves in your book case
3. Now delete all of the other apps on your mobile device that you should've removed in step 1.
4. Gather any book in your current workspace or home where you have said "I need to / I'd like to read this" within the past year.

• Note: if you are a curmudgeon and have either never heard of books or never actually owned one, head over to Amazon, pick up Nerd Life Balance for free, have a look at some of my favorites, or just ask a friend.

5. Take all of those books and put them on the top shelf that you cleared off.

• Note: You may not have more books than the maximum number of books that can fit on the first shelf.

6. Choose your first book out of the collection.
7. Set a reasonable time goal for yourself to finish each book. We set this goal because you cannot hit a target if you don't know where to aim.

• Ex. My game goal is one book per week.

8. Begin playing

How to play:

The player's turn consists of 5 different phases: Read, Share, Shelve, Restock, and Draw

Read

The player begins by reading a book that is on the first shelf.

Note: The second shelf should be empty right now.

The player replaces tv watching, video games, mobile distraction time with reading this book (see you didn't even have to give up sleep!).

Note: This might really be painful for some, so factor that into your goal time - I recommend going all in though, but that's my personality.

During the read phase, make a point to share any interesting perspectives with friends, family, your dog or anyone who might listen - you'll be amazed at some of the responses and you'll find that they will almost always have a book to share with you.

Share

When you complete the book the player must share their thoughts on a social platform, this can be in person, on facebook or twitter, or even in a blog post. This is the one exception to the social media blackout imposed by the rules in Setup

(I recommend keeping this simple initially otherwise you might just decide to give up)

Use #readingtorrent to connect with other players

Shelve

Take the book you just finished and move it to the second shelf.

This shelf is a special stack that other individual players or non-players can draw from.

Ex. You and your spouse are playing The reading torrent. You go on and on about Ready Player One to your spouse while reading it. When the book hits your second shelf then anyone who sees that shelf or asks about a given book on the second shelf may take it and read it.

Since players win by filling the second shelf this can be used as a strategy for other players to connect over both a great book and a little friendly competition.

Restock

This is an evaluation stage. You can either choose a book from another individual player's shelf or if at any point while you were reading the book you just shelved someone suggested a book then obtain that book and place it on the first shelf.

Draw

The player now chooses the next book they will read and the next turn begins.

Ending the game

If the game was played well then it might never end. But as stated above once the second shelf is filled with the books that you have read end to end you "win."

The prize: a wealth of knowledge, many good memories, new friends and possibly many other side effects - results may vary.