This post now lives here: Cheap and Bad versus Expensive and Good

This post can now be found here: Four Considerations of “Urgent” Work.

This post has been moved to: And Then What Happens?

Progress-Making Forces and Progress-Hindering Forces are in competition for the attention of your users. Those forces either push your users to a new behavior, or leave them stuck with the existing behavior.

(source)

IT may push a situation forward - to eliminate old technologies and legacy code. But too often that push is the only lever used. The user resists because of their allegiance to the existing behavior and fear of the new solution. They aren't shown the benefits of a new solution, so there is no pull toward the new idea. We're stuck with a Lift and Shift.

Manager READMEs have been an on-again, off-again thing over the last few years. The negatives are mostly because the author can't see their own weaknesses and over-value their strengths. Many readmes are long and rambling. Mike Crittenden suggests, instead, writing a 50-word personal readme:

You get 50 words, that’s it. It’s a forcing function to kill the fluff and decide what people must know about you.

What might I write? How about:

• Written over verbal
• Long-term over short-term
• I offer trust first
• Don't lie to me
• Bad news doesn't age well
• Team over individual
• Remote-first
• We're professionals and adults

This post has moved to: Bad News Does Not Age Well.

Marcus Blankenship recently sent an email on the stories leaders tell to “illustrate [their] values, pass on (usually painful) lessons, or communicate key points”:

Have you ever thought of your stories like this? Your winning stories, losing stories, and the stories of how you overcame adversity? Stories that inspire, or act as a warning to others?

I feel like I tell long rambling stories to my team, primarily to entertain. I like to think they inspire, but probably not. Marcus suggests a way to make better use of our stories:

You might sit down and make a list of some of the stories you’ve found yourself telling as you lead your team. Creating a written story inventory is a great way to see them with fresh eyes, and you might find new, fresh perspectives on them.

This article now lives at Being Glue.

Here are some of my favorite podcasts:

Company

Leadership

• Effective Engineering Manager
• The Important Thing with Michael Lopp (aka Rands in Repose)
• Level-up Engineering. A deep look into engineering leadership.
• Manager Tools and Career Tools.
• Soft Skills Engineering. A humorous look at the non-technical skills of software engineers. The hosts always have the great advice of "quit your job".

An idea: Give your documents an expiration date.

It's somewhat common to include a "written on" date in documents. But what about an expiration date?

If you're reading a document and it has expired, it is your responsibility to determine if its contents are still correct and valid.

Correct means the contents are still an accurate representation of a system, and valid means the document still applies to the current business environment.

This post has been moved: One-Off Apps.

This article now lives at Map of the Universe.

This article now lives at The Three Perspectives.

There are four areas of authority in a project:

• Budget Authority
• Requirements Authority
• Design Authority
• Technical Authority

We reduce frustration and confusion when we understand who has the authority in each area.

(source: The Art of Project Management (pp 42-43))

The company I work for took its strategic goals and wrapped them around the five core areas we focus on to create a strategic bullseye. This visualization helps everyone in the company understand what our mission is.

I use a modified version of the strategic bullseye to help my team understand where a specific project fits into the grand vision for our company. It can be hard to see how tech projects help the company as a software engineering team.

In the project charter, I highlight the strategic initiatives this project impacts.

When we're trying to rathet down the scope of a project to meet a budget, we're often prone to talk about "Phase 2" or "Phase Next" where "next" is whatever incremental number we're at.

But how often is it really "Phase Never"?

Is there already a planned budget for Phase Next? Have we already added Phase Next to our Capex budget? If not, it's Phase Never.

Honestly, Phase Next is just an excuse for the consultants we've hired to skip the hard work we can't afford right now. We all know we always pay full price, regardless of what phase the features we need are in.

Be careful your project status doesn't become a watermelon:

From the outside, the project status is green, but once you dig into it, it's red, red, red.

When someone offers you coffee, ask for it "black."

There's no search for flavored creamers or special blue packets of sweetener. You're making things easier.

In what ways can you simplify work for your team, your peers, and your customers?

Your willingness to accommodate their work is empathy, and they will notice your desire to keep moving forward. You're not people-pleasing; you're a "no fuss, no muss" sort of person.

I worry—more than I should—about uncontrolled documents getting sent through corporate email. Documents should be like the immortals from Highlander:

Whenever possible, I put my documents on a shared drive and share the link. This is especially true when there is the expectation of collaboration. We don't need to spend time reconciling four different versions of a spreadsheet. Should I need to attach a document for someone without access to the shared resource, I'll send a .pdf: it's read-only.

It is easy—at the optimism of a potential flawless deployment—to forget to let the support team know you're deploying new software. However, that's the team will be the first to hear about the weird new bug you've introduced. Make sure the help desk is part of your deployment communication.

The User Experience designer's corollary to technical debt is experience rot. Over time, a poorly designed user experience gets worse and worse, especially if there isn't concentrated effort to improve it.

Experience rot happens when features are launched with half-assed user interfaces and then abandoned. It’s created by launching feature after feature until they pile up like crappy plastic merchandise in a dollar store.

Source

Like technical debt, you need to refactor the experience every time you're in the code. Every user story should create a visual change.

There are no shortcuts in software development. Software development costs money, and eventually, you pay full price.

Full price comes in many forms:

• Throwing something together to meet an unrealistic timeline and supporting a rickety solution for years.

• Underpaying your team and then begging them to consult for you at double their former salary after they leave for better pay.

• Choosing an "easy" solution that you can't make changes to later.

• Recreating your software from scratch because no one knows how the old system works.

Or you can bite the bullet and pay full price upfront:

This article now lives at Decomposing Projects.

When we work on our own personal projects, we espouse the ideals of the agile manifesto:

Individuals and interactions over processes and tools

Processes go right out the window when you're working on a project by yourself. There's no need to do sprint planning or other team ceremonies. Code doesn't need to go through a UAT because you're testing things as you go along.

Working software over comprehensive documentation

It's always important to notify your userbase when a system outage is going to occur. For corporate IT departments, the best method is usually email. Here is a template that does a great job covering the bases:

Summary

What? {one sentence summary}

When? {date and time}

Who? {applicable parties}

Details

{Give a detailed and friendly description of what's occuring. Explain why this downtime is happening, when it is happening and how long the outage is expected to last.}

Services impacted: {List the services or systems impacted.}

What is not impacted? {List adjacent services one might concude may be affected but should not. This gives your users a rubric for systems that should not go down. Should those systems go down, it is a different issue, and the user can submit a support ticket.}

Impact: {Tell the user what to expect during the downtime. Again, this is a rubric to guide the users in determining if they are experiencing the expected outage, or a different issue. Reiterate the expect length of downtime.}

Questions? For more information, please contact {the support team name} by submitting a support ticket via {help desk ticketing link}, by emailing {support team email address}, or by calling {support phone number}.

Emergency issues: In the case of extreme emergencies directly related to this change, you can email: {emergency support email address} or call {emergency hotline number}.

This article now lives here: Confusing process with goals

This article now lives here: Investment, Not Debt

This article now lives here: Six Challenges for Working in Corporate IT

This article now lives at Data is for Decision Making

As an individual contributor in software development, the job is sometimes stressful. Bugs can be hard to find and elude you for hours. It's a matter of logic because a computer will only do what you tell it to. With a bug in your code, your assumptions are wrong. You change your premise and then the code to match.

As a manager, the job is sometimes stressful. Leading people is about debugging humans, and people aren't logical. Correct assumptions don't lead to desired outcomes because people don't do what they know is logical. The beliefs and premises are not yours alone, and it's nearly impossible to change the code in someone else's head.

Unless you were born before 1985, you don't remember a not-always-available internet.

I had a dream last night; I was in Cloud 9 - our college apartment - and the phone rang. It was one of my roommate's mom. In the dream I couldn't remember how to write down the message that she had called - did it go on a whiteboard (we didn't have one, it was actually a corkboard), or on a post-it, or did we just tell each other when we were both at home again. That thought led to a semi-lucid consideration of what it was like in 1994 - when I had email but had to go to a computer and use a floppy disk to store it. Going to the library meant true studying because no one had a smartphone. Listening to music meant a Walkman with a mixtape or a Discman with CDs, whichever tunes you remembered to grab before you left. There were no other distractions. No one knew where you were and no one could get ahold of you.

I considered what a drastic cleaning of my phone might look like: not only getting rid of social media apps but even email. I realized the folly of that though... there are still distractions in choosing the infinite amount of music on Spotify and the interruptions that are spam calls and text messages. This morning I even found myself distracted when I "had" to check the temperature of the coffee in my smart mug. Via an app on my phone, of course.

Lest you consider me nothing but a curmudgeon at this point, I love having the collective knowledge of civilization in my pocket. I love technology. But there was something to the monk-like lives we lived before technology permeated everything.

In September (of 2020) I started timeboxing. Timeboxing is the process of assigning a period of time to work on a task, adding it to your calendar, and sticking to it. And I timebox EVERYTHING from the time I wake up in the morning until I go to sleep.

It's the top productivity tip on Filtered's The Definitive 100 Most Useful Productivity Tips because it allows you to focus and prioritize the work which needs to be done.

Some benefits of timeboxing:

1. It removes the paradox of choice. You already decided what to do because you planned ahead.

2. You strategically prioritize the important but not urgent.

3. It's easier to say "no" to new projects because you need to fit them into the calendar.

4. You learn how bad you are at estimating and have to keep adding blocks to finish the work. It makes you better over time.

Transparency makes work more efficient for others. That's why I keep my calendar events public by default.

Anyone can see what meetings I'm attending, and should they need to double book a time slot, they have more context about my schedule than "Busy".

Some events are more flexible than others for rescheduling. One-on-ones can be easily rescheduled (never canceled!). The same is true for standups or other meetings with my directs. Availability becomes trickier the higher up the org chart the attendee list is.

What about confidential events? I'm skilled enough to maintain my own calendar and will make those meetings "private" on a case-by-case basis.

One of the biggest struggles for teams with a legacy codebase and a large user base is the "Lift and Shift". This is when a legacy system has been flagged for refactoring on a new technology platform, but no one has the courage to really change the system. Users are comfortable with the legacy system and don't want to change. Business leaders don't see how to change things because they've "always done it that way". So IT is stuck moving a bad, outdated system to new technology.

Tl;dr is the new executive summary, except it's for everyone. It's no longer the domain of the executive to be too busy to read the whole document.

I still like BLUF - Bottom Line Up Front - because most of the time your proposal is a bunch of bull you're trying to sneak past an executive who will sponsor it.

I'm not a fan of the "lunch and learn".

It feels like a cheap attempt to steal from your team. That free time in the middle of the day gives them a chance to think about something besides the code they've struggled with all morning. Lunch is a time to step away, to refresh.

A meeting to "learn" about work-related topics should be done during work time. It's a knowledge transfer meeting and a cost of doing business.

Don't get me started about companies that make you attend a lunch and learn *and* bring your own food.

Lullaby Language are words used to lull you into a sense of complacency when requirements aren't clear. Gerald M. Weinberg coined the phrase.

• Anything

• Just

• Only

• Simply

• Should

• Soon

• Very

Ultimately these words gloss over an assumption or minimize the complexity of a solution.

We must seek clarification when we see them.

I started a new habit the other day:

When in doubt, write.

If I'm unsure what to do next, I write. The thoughts come and the next task becomes apparent.

If I'm struggling to start, I write. The letters on the screen are the motivation that gets me moving.

In software engineering, there’s the idea that you should never memorize anything you can look up. That’s led to the StackOverflow method of development, where any bit of code can be found on that site with a few keystrokes. Eventually, a dependence on SO becomes a grinding slowdown of your productivity. You need to know some things, and it isn’t better to look up the basics.

Last year I started going through Wes Bos’s React for Beginners course. More accurately, I started going through it for the second time because I remembered almost nothing from the course. I did the lessons, but I didn’t have a project on which to practice what I learned. I forgot it all.

I discovered something between my two attempts: matters. Remembering things is a function of relearning them. It’s not a linear path of relearning information, though. The goal is to relearn right before you forget it again.

Here are 5 quick things I came across in the last week or so:

1. Want to learn JavaScript? One way to learn is to study the 100 most asked JavaScript Interview Questions, Part 1. (Bonus: Part 2)
2. I worked on a project that needed to use SVG as a clip path for an image. I wish I had this CSS clip-path maker, my job would have been a whole lot easier. It lets you define a path in CSS and clip an element (like a background image) to that shape.
3. Shapecatcher lets you draw a character and uses shape contexts (maths!) to figure out the unicode character you meant. For when you can't remember how to spell "umlaut".
4. Mike Crittenden's blog is a goldmine of technical leadership.
5. To-Do Lists Are Not the Answer to Getting Things Done makes the case that your todo list should really be a calendar. I tried it out this week and I can't argue with the logic.

Have a great weekend!

The Agile Manifesto suggests making decisions as late as possible. Agile favors:

• Customer collaboration over contract negotiations

What is the purpose of software engineering (and software engineers)?

My golden rule of software engineering: our job as engineers is not to turn product specs into code. Our job is to deliver the maximum value for the company at the lowest cost.

Rod Begbie,

This Kit Kat ad pretty much sums up people's workdays. When we worked in offices, there was a limit because only so many conference rooms were available. Virtual meetings get scheduled with abandon.

Here are a few tips on how to make meetings better.

Speedy Meetings

User scenarios describe the changes in the system’s state:

• A “given” statement is a precondition. It describes the past state.
• A “when” statement is the current event. It is what is happening now.

Believe it or not, this is issue 50 of Known Unknowns. If you’d like, you can check out the archive.

My request of you, dear reader, is to reply to this email and let me know what you think of this experiment.

Test-Driven Development (TDD) aims to test small bits of code using the Red-Green-Refactor pattern. First, write a test that fails (Red), then write the most straightforward test that passes (Green), finally refactoring until the code is as clean as possible.

Behavior-Driven Development (BDD) inherits the spirit of TDD while using artifacts provided by project stakeholders, such as user stories. BDD uses plain-text scenarios to bridge the gap between technical teams and regular teams.

Using a tool like Cucumber, developers create tests that match these plain-text scenarios written in a simple domain language called Gherkin.

Scenario: [a scenario starting with "should"]

Given [some preconditions]
When [an action happens]
Then [a result]

Today I built a User Persona (of me).

Alan Cooper first described User Personas in his 1998 book "The Inmates Are Running the Asylum". Cooper created these personas based on interviews with seven or eight users.

"Personas are not real people, but they represent them throughout the design process. They are hypothetical archetypes of actual users. [...] Personas are defined by their goals." - Alan Cooper, The Inmates Are Running the Asylum

Kent Beck originally suggested the idea of User Stories to help define requirements with a politically neutral balance between the business folks and developers.

"Use cases as I have seen them used are complex and formal enough that business doesn't want to touch them. This leads to development asking all the questions and writing down all the answers and taking responsibility for the resulting corpus. Business is reduced to sitting on the other side of the table and pointing."

According to Kent, the goal was to imagine an artifact simple enough for non-technical teams to create and own. They would feel comfortable adding new requirements and appropriately prioritizing them.

Dan North suggested the standard User Story Template we use to express user stories:

Getting up to speed is a challenge, particularly when starting a new role with a company working in a domain in which you are unfamiliar.

Collective learning can get bogged down while you are catching up. Here are four ways to get a head start in your learning:

Do Some Research

Given a domain with an existing history, learn who the “thought leaders” are. Consume their content, whether books, blogs, or videos. They have thought about the challenging problems in the domain and may have already provided solutions. Their knowledge gives yours a quick boost.

Previously, I wrote about how Software Engineering is a Learning Process where we aim to understand the business domain for which we design software. But why is it important? There are several benefits to understanding the business domain.

User Empathy

When we understand the terminology and rules in the space, we can better understand the users of our software. Conversations are smoother, and it becomes easier to determine user needs.