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!