Different format #
Trying a different approach this week. Some days have stuff happen. Some days don't. I rather appreciate a day that doesn't have a significant occurrence. It doesn't mean I didn't do anything that day, but it also isn't worth tracking that I did a bunch of stuff that may or may not have been what I had hoped to accomplish that day. When I do things because someone else needed something from me, I contributed. Maybe not in the way I had planned, but as a cog in the machine, I didn't gum up the works. That's not nothing!
Even still, I have actually used my previous weeknotes to remind me why I may or may not have done something a particular way. I do a quick check and think, "Oh yeah! That week. I remember that week!" So, I guess that means I'll recap my weeks any damn way I like. I'm going to remain open to doing it however feels right, based on the week's events.
Game of Thrones #
Fuck yeah! It's back and I couldn't have been more excited. Scott and I went to our favorite restaurant to celebrate its return. We're not even ashamed. As soon as the episode ended, I reminded us of our countdown to sorrow: 5 more episodes until it is over for good. Game of Thrones might not be everyone's cup of tea, but it is ours. I will miss how much we looked forward to each episode. I know we can rewatch them whenever we like, but it's not the same as wondering what will come next.
Something I forgot to jot down #
Near the end of the previous week, my lovely coworker, Holly, noted I was overwhelmed because I was struggling to get done what I wanted to do. She invited me to get out of the office with her for lunch because I hadn't done so in awhile. During our conversation, she suggested some alternative strategies to help me get caught up, since she knew that delegating some things to the folks who report to me wasn't an option. They had as much on their plates as they could handle, leaving me feeling like I was the only one left to keep things moving. I had lost sight of other people—my peer level—who were more than willing to chip in. It's not that I didn't realize these people could help. I forgot that I should ask them to help.
Having a tired brain doesn't allow me to think at my best. That's why I am so grateful when someone cares enough to snap me out of it. As a result of Holly's kind intervention, I feel like my week was much more sane and I was able to view things beyond what was just in front of my face. Whew!
Theme of the week: allocation #
Many of the discussions or meetings I was in this week were about this topic: also known as resource allocation.
I've read, "They're people, not resources." The spirit of the statement is to remind managers not to lose sight of the humans for whom we're responsible. That's a point well taken. However, phrasing it as if it is not possible to allocate "resources" while also remembering they are "people" is what I find bothersome.
I'm not only allocating people (a.k.a. headcount) when I'm allocating resources. It is people based on their area of expertise + skill level + available time that I am allocating. It is this very activity that causes me to stop and reflect on the individual. For instance:
- Is this person ready to play a lead role or are they not ready to be stretched in that capacity? Have they asked for more responsibility? Is this the right project to ease them into it?
- What about the volume of work being assigned? Will they be able to give it their best effort or will they feel rushed to get it out the door?
- While I could assign [insert name] to this, does the task require their skill or discipline, or would I just be throwing a warm body at it?
That is a far cry from losing sight of them as contributors or as humans.
If Twitter et al. is feeding people's brains with "they're people, not resources" as if it is a binary choice and someone witnesses me using the term "resource allocation," I fear that a false conclusion gets drawn that I must be a cold-hearted jerk who has lost sight of my team as people.
I much prefer, "The resources are people." It's no longer an either/or proposition and still serves the purpose of reminding team managers that their resources are not inanimate objects.
Stuff I read this week #
-
Well, I actually read this one when it was first published, but it keeps reappearing on Twitter and in my RSS Feed, so I'll not delay linking to it any further. Split, by Jeremy Keith. The reason I delayed linking is because I thought I would have a new post brewing as a result of this. The fact is, I don't. He summed up the thing that weighs heavily on me so perfectly:
But the split that worries the most is this:
- The people who make the web vs. the people who are excluded from making the web.
The reason this worries me, too, is because I was a person who learned how to make the web without any formal training. And now, just over a decade later, the thing that drew me to making the web is not valued quite as much as it was when I moved into making this a career. But it is more than how it impacts me. What about the folks who just want to make things as a hobby? If it looks too complicated to do, they will think they can't do it. The web didn't used to be that way. It used be inviting us to make things, whether we could get paid for doing so or not. I miss that web very, very much.
-
The problem with atomic CSS, by Adam Silver. This is 2 years old but it still strikes a nerve with me today. I especially appreciated this bit:
The most celebrated aspect of atomic CSS is that it results in a small CSS footprint which speeds up the time to first paint. The problem is that this point is always discussed in isolation making this selling point misleading at best.
Firstly, the size of the HTML increases a lot. Remember CSS is cacheable and serves an entire site like the one I mentioned earlier. HTML is unique, dynamic often personalised. It can't be cached.
It's important to remember that every decision we make for building the web involves a series of trade-offs. Such as:
- Is making this CSS file smaller going to make our HTML unreasonably larger?
- Is compressing images this far going to impact performance positively, but negatively impact our brand because it appears we don't value quality?
- Can we build this feature within a project's aggressive timeline without taking shortcuts on privacy and security considerations?
Building for the web is a balancing act. It's why so many answers to questions are, "It depends." It's why so many statements about how someone did their thing ends in, "YMMV" (Your Mileage May Vary).