When in doubt, ask!

I have seen more problems tolerated for extended periods simply because no one spoke up about it.

The first instance that comes to mind is a 9 month project that I joined in the middle. The first thing I discovered is that deployments took several minutes. I also noticed that the the development environment would frequently lock up for extended periods. This had a serious impact on my productivity. I set up the environment on my home computer that night and everything ran perfectly. What had happened is that the project with the first with a new version of a platform our company had been working with for a couple of years. The new version was much more resource intensive. The team had been struggling with this impact to productivity for months, which was why they were adding someone to the project mid-way through. I immediately brought it up to management, but because no one had said anything about it before, they assumed it was just me. So I told management that I would work from home until they provided the team with updated development hardware. It took 6 weeks of my not coming to the office and out-producing the rest of the time by a huge margin for them to release that 1) I was not kidding about it being intolerable and 2) the increase in productivity would more than pay for the hardware.

The folks that were struggling all that time just assumed that management was aware of their problem. It made their lives unpleasant for months and cost the company 10’s of thousands of dollars because no one asked.

I get that sometimes people don’t want to ask because they don’t want the attention, or don’t want to appear ignorant. If you are concerned about that, just don’t ask in a meeting. Pull the person that can do something about it aside and ask them one on one. They will either have a good answer for you, or will do something to help you. And if they don’t do either of those, you might want to look for a place where they will.

© Scott S. Nelson

#TIL: How to Present PowerPoint Slide Show in a Resizable Window

Full screen is great if you don’t need notes. Until today, if I need notes I just minimized the tools and gutter while presenting. And then I discovered this:


Slide Show > Set Up Slide Show > Browsed by an individual (window)


© Scott S. Nelson

My Pinned Wiki Post Template

If you use this, please link to this blog post.

This is our Wiki

There are many like it, but this one is ours.

Our wiki is our guide. We support our wiki through comments and additions.

Without updates, our wiki will become outdated. Team members will become frustrated when information is missing or no longer correct. Being a good team member includes being a contributor to the wiki.

That cool reference you found that you will always remember? One day, when you need it most, you will forget it.

That awesome solution to a code or design issue that is perfectly clear and understandable now will look like a foreign language in 2 years (months, weeks, sometimes even hours). Add an explanation to the wiki.

When in doubt if something should be added to the wiki, add it. It can always be deleted later.

This is your wiki. Keep it clean but not too lean.

The Architect
(A serious parody of The Rifleman’s Creed )

(“Obligatory WIki Photo” by cogdogblog is marked with CC0 1.0. To view the terms, visit https://creativecommons.org/publicdomain/zero/1.0/?ref=openverse.)

© Scott S. Nelson

Be Prepared for Meetings

The concept seems like a no-brainer, and maybe it is just my personal experience, but anytime a poll of the meeting attendees is run asking if they reviewed the material sent prior to the meeting, the overwhelming majority response is “no”.

I was reminded of the importance of being prepared while listening to an episode of one my favorite podcasts, “Think Fast, Talk Smart” (please see my YouTube channel for a link to the podcast playlist and subscribe to my channel while you are there so I can finally get a vanity URL). The episode was titled Communicating Our Mistakes: How to Avoid Common Flaws and Make Better Decisions, which I admit was not one of my favorite episodes, but it did spend some time on this topic of preparation, which triggered a confirmation bias response from me. It started with a learning approach where the teacher asked students to complete the lessons before the lecture so that lecture time was spent building on top of that, then moved on to how meetings are more effective if people review the material in advance and discuss in the meeting…

[sounds of wood scraping across the floor as the author pulls his soap box out]

There are corporate cultures where materials are not provided in advance, probably because of the tendency for people not to review them. This makes the problem worse. These same cultures also frequently have meetings schedule with no agenda. I had someone on one of my teams who refused to attend meetings without an agenda. It was difficult for me to fault him, as I agreed with his reasoning.

People hate meetings because they are often inefficient and inclusive. My approach is to go the opposite direction of those who stop sending the material in advance and including agendas: I avoid reviewing the material in the meeting and instead advise those who didn’t to take notes and review it after the meeting. Depending on the purpose of the meeting, I may just reschedule it and advise everyone to come to the next meeting prepared. This may seem anti-[your pet sentiment here], but my experience has been that people become much more productive when they come prepared as a result of the meeting being more productive and few meetings because things were accomplished  the first time.

[author returns his soap box to easily-accessible storage location]

© Scott S. Nelson

Things to Determine before Projects Begin

This post is a perpetual Work-in-Progress. As of now, it is only starting (stalling would be more accurate, I’ve been playing with it in various forms for over a year now).

Here’s what we have so far (please add your additions in the comments):

Project Type Artifact
All Release schedule
All Release process
All Coding standards
All Other StakeHolders that may be impacted
All Where and how architecture decisions are logged
© Scott S. Nelson