Software engineers must be able to budget and plan:

Dr Milan Milanović posted an updated RoadMap for DotNet developers. This roadmap labels topics by “junior”, “medium”, and “senior”.

Dark matter developers, according to Scott Hanselman, are those developers in the industry who get things done, despite running “old” code

Creating goals and plans at the annual level is daunting and difficult. As most New Year’s Resolutions go, they’re abandoned within the first week (at least the fitness industry would tell you so).

This year was the first full year where I used timeblocking for scheduling my days. Not only did I plan out my day, but I updated the calendar to reflect (mostly) what I actually did. Not all numbers are super precise, since I round to the nearest 15 minute increments, but I think there’s valuable things to see here.

From the Manager Tools newsletter:

Okay, I watched a free webinar that was a sales pitch to sign up for a paid course. I know.

A pair of tweets came across my timeline, each containing obsolete things.

This tweet is one I stand by:

In this StackOverflow blog post, Corissa E Haury notes a study of paper versus digital and the retention of the information:

Two tweets showed up in my feed at nearly the same time yesterday. The first was an article about Evernote’s missteps: Ahead of Its Time, Behind the Curve: Why Evernote Failed to Realize Its Potential.

To this point, our (Microsoft) Teams culture has been to have one-to-one conversations. If I have a question about a product, I ask the developer working on it directly.

One tip to avoid some awkward pauses in a video call: Instead of asking, “Can you see my screen?” and waiting for others to unmute and confirm, state, “I’m sharing my screen; let me know if you can’t see it.”

Software product roadmaps provide context to the team and stakeholders about our software projects and where we are headed. The roadmaps is the big picture summary of development tasks.

When we lower friction, we get higher adoption.

The Great Law of the Iriquois takes a future-focused stance in decision making by considering the impact of a decision on future generations. Would this decision benefit our children seven generations in the future?

Previous I wrote about decomposing projects and three methods for breaking down a project:

Software Engineers rarely have time to read books. So when an engineer gets excited about something they are reading, I’m on board. I’ll buy the book and read it too; to build ubiquitous language on our team. It fosters clear communication; I like to call it ubiquitous reading.

Software engineers hate to waste time. That’s why they’re so adverse to meetings - why sit around talking when they could be writing code?

I’m working on getting better at what Cal Newport calls the work shutdown ritual rather than closing my laptop and getting the heck outta Dodge.

Good managers with a P&L always know their numbers. If asked, managers can recite them from memory. But some managers don’t always run off a budget. For Software Engineering Managers, their numbers are project statuses.

Seth Godin suggests blogging every day (including Saturdays and Sundays). At more than 7000 posts, he walks the talk. His writing, podcasting, and thought leadership continues to amaze me.

As the grandmother of Redfin’s VP of Engineering, Sasha Aickin, once said:

When everything is urgent, nothing is. Gergely Orosz (@gergelyorosz on Twitter) provides a list of four considerations when asked to take on “urgent” work:

Seth Godin gives us a similar question to the “5 Whys” intended to clarify a future path:

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.

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

As Colin Powell put it:

Mike Crittenden mentioned a presentation by Tanya Reilly called Being Glue. Teammates who are the “glue” take on the non-technical tasks required for solid teams. Then they are not promoted because they’re “not technical enough.”

Whenever I have a simple repetitive task, I like to create a quick single-page app to automate it.

Understanding your team’s scope of responsibility is made easier with a Map of the Universe. This one-page diagram outlines the high-level applications your team maintains and how data flows between them.

Every project must take into account three perspectives: the business perspective, the technical perspective, and the customer perspective.

[placeholder]

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

In Software Estimation without Guessing, George Dinwiddie outlines three different ways to break down a project to estimate it:

It’s easy to hide in the corner and update task statuses instead of leading the projects you’re responsible for. That’s shuffling deck chairs on the Titanic.

Instead of framing everything wrong with your system as technical debt, call it a technical investment.

I love Tech Twitter. It’s why I’ve stuck with Twitter for more than 15 years. The resources generously shared by my fellow software developers and engineering managers help me learn, grow, and stay current in the industry.

I keep records for all sorts of things: fitness statistics, time tracking for work, and writing word counts, to name a few. It’s data that sits in notebooks and spreadsheets, and it will never be used again.

Welcome to my new site. I’m reposting many of the articles I send out from my newsletter Known Unknowns. This will become the source of truth for these posts.

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 dares to 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.

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

The longer your career goes on, the more difficult it is to remember the things you’ve accomplished. Occasionally it’s a challenge simply remembering what you did last week.

Once a project has already blown its deadline, the activities added to wrangle the project back under control actually make the project even later.

Communication is critical in organizations and on project teams. If I can learn something than improves how a project runs, I’m all for it.

I felt a little lost the other day, holding a pity party about my skills and abilities. My wife encouraged me to take the Clifton Strengthsfinder to better understand my skills. The test is pricey ($50 USD) but worth it!

Bug reports are a minefield of useless comments to passive agressive opinions. They can be as barely detailed as “[thing] doesn’t work” to page-long diatribes that don’t really tell you what’s going wrong.