Forem: Henry Poydar

How Does Your Framework Make You Feel?

Henry Poydar — Fri, 16 Jul 2021 19:12:31 +0000

Over the years, I've been a part of many decisions (and lively debates) around the choice of software development libraries, tools, and frameworks.

Many variables feed into these decisions, but more often than not, they are all quantifiable: integration costs, licensing costs, training costs, support options, maintenance needs, the availability of developers with relevant experience, and more.

But many of these quantifiable variables are ranges or flat-out guesses because any software development estimate is challenging at best, wildly inaccurate at worse.

That's where subjectivity and emotion come into play. As I've written before, I don't think it's entirely possible to require a "strictly business" approach to anything humans do in collaboration and earnest, like participate in a software development team. We're not robots. We bring our emotions to work whether we want to or not. And our work will be affected.

So when it comes to choosing a framework, in my experience, the way a framework makes an advocate or detractor feel will undoubtedly affect the way they tabulate the objective variables that drive the decision.

That's why "shiny new" frameworks are often introduced as choices where perhaps they shouldn't be. Learning new stuff is fun. It will feel better than the same old thing. (At least at first.)

As a developer myself, I can report that different frameworks do indeed have unique feels. Using statically typed languages gives me a feeling of solidity, speed, and accuracy. But working with repetitive boilerplate code and rigid rules feels heavy and bureaucratic. And though I haven't found a way to measure it, I think the products I've coded against are better when I feel enabled by the framework rather than feeling burdened by it.

Ruby on Rails is the first web development framework to openly acknowledge the importance of the vague notion of "developer happiness." Many teams choose Rails specifically for that, while other teams, unfortunately, discount it for prioritizing happiness over things like scaling and flexibility.

The "happiness," in my opinion, is derived from the close connection Rails lets a developer have with the end product. Sure, it's not statically typed and fast, but I'd argue that a close (and happy) connection between a builder and a product generally yields a better product. On many occasions I have reached for Rails over other frameworks because of this, despite other objective factors.

So when you're gathered around a whiteboard (or Zoom call), charged with choosing between framework A and B, don't be afraid to ask how each choice makes everyone feel. Because subjectivity and emotion will undoubtedly make their way into the decision matrix, and working with a framework that feels wrong to your team can lead to building something substandard.

Serving a static blog from a subdirectory with Cloudflare Workers

Henry Poydar — Fri, 12 Oct 2018 16:22:40 +0000

When we first published our blog a couple of years back, we decided to use Jekyll. It's simple, Ruby-based, established, and it does this one job really well. We've stuck with it.

According to the experts, there's an SEO edge to hosting your blog in a subdirectory (statushero.com/blog) rather than a subdomain (blog.statushero.com). Some claim (including Google) that it's a negligible difference when you're just starting your blog, but it seemed easy enough at the the time to implement, so why not.

Quick and Dirty

Since our main app and landing page is a Rails app deployed many times a week, we just published the static output from Jekyll to public/blog with some git submodule trickery. The blog files are almost immediately cached in the Cloudflare CDN and almost never incur a Rails request.

Hax

As you may have guessed, this coupling is cumbersome and bit of a hack for a variety of reasons. It would be much easier to host the blog on GitHub pages--a piece of cake with Jekyll--publish minor changes quickly, and open up the blog publishing step to those without prod access.

An nginx reverse proxy would do the job, but we're serving the Rails app from Heroku with Puma app servers, so to do that we'd have to insert an extra bit of infrastructure somewhere in the stack. (Perhaps by switching to Phusion.) The trade-off didn't seem worth it.

Enter Cloudflare Workers

We were just about to setup the redirects and switch back to blog.statushero.com when we stumbled across Cloudflare Workers. Have a look - it's a powerful offering. With a few of lines of Javascript, our problem was solved:

addEventListener('fetch', event => {
  var url = new URL(event.request.url);
  if (url.pathname.startsWith('/blog/') || url.pathname === '/blog') {
    handleBlog(event, url);
  } else {
    event.respondWith(fetch(event.request));
  }
})

async function handleBlog(event, url) {
  var originUrl = url.toString().replace(
    'https://statushero.com/blog',
   'https://8012labs.github.io/statushero-blog');
  event.respondWith(fetch(originUrl)); 
}

Cloudflare even gives you a nice little browser-based UI to preview and test your Worker code.

Now we have the best of both worlds - a subdirectory for the blog with convenience of the Jekyll/GitHub pages combo.

On Meetings and Wasting Time

Henry Poydar — Mon, 04 Jun 2018 17:21:29 +0000

I'm a software developer, and I hate meetings. All software developers hate meetings. Stop scheduling them, and stop inviting us to them.

Dons giant headphones and swivels back around to the soft glow of multiple monitors.

But that's not quite true, is it? Humans build things by collaborating and working together. Breakthroughs and progress are a group effort, and it takes all kinds of meetings for that to work.

My favorite theatrical example of this is from the movie Apollo 13, where the engineers on the ground in Houston have to figure out a way to make a square cartridge compatible with a round one in order for the astronauts in space to survive.

Now that’s a meeting.

Realistically of course, more mundane meetings are needed. Work needs to be estimated and prioritized, designs need to be hammered out, and retrospectives are necessary for finding avenues for team improvement. (You are doing retros, right?)

Since teams need to work together and therefore have meetings, the things to solve for are necessity and scheduling.

Because it’s not really meetings that everyone hates; it’s having their time wasted. And wasting someone’s time on this earth is a disrespectful and selfish thing to do.

Necessity

I have a not-so-fond memory of working at a bigger company where the meeting rooms were at a premium. Because of this, the PM felt we needed to stay in the room for the entire time we booked it whenever we had a team meeting, even if we flew through the agenda.

“Well we have the room, so what else do we need to go over?” Um, nothing. Meeting over. Let’s go work on building stuff.

There are loads of strategies for determining whether a meeting is necessary or not, and every team is different. (Let me Google the flowcharts for you.) The important thing is to set some threshold for meeting necessity, share it with your team, and refine it as needed. That way, when the meeting invite pops up in the developer’s inbox, they can assume that their time is not going to be wasted. It turns out that people are a LOT more helpful and engaged when they know that you respect their time.

Most of all, if you hit the goals for the meeting, end it.

Scheduling

If you have software developers on your team, the worst thing you can do is plop a meeting into the middle of the morning or the afternoon. “Getting into the zone” is indeed a thing for me and most developers I’ve come across, and a meeting at 10 or 11am interrupts that flow in a big way. Same with a 3pm meeting.

I recommend setting necessary meetings up at the beginning of the day or the end of the day, depending on the make-up of your team. Got a bunch of “morning people”? Then hold the conceptual or creative meetings at the beginning of the day, and do the logistical stuff at the end.

Either way, find ways to leave your developers alone for long, uninterrupted stretches in between collaborative meetings. That is when real work gets done.

TL;DR

Human progress comes from collaboration. People don’t hate meetings necessarily, they just hate having their time wasted. Set team standards for meeting necessity and scheduling to mitigate the anti-meeting sentiment.

How and Why to Keep Your Team Out of Communication Debt

Henry Poydar — Thu, 19 Apr 2018 20:42:52 +0000

tl;dr - You need to actively manage the barrage of incoming notifications and messages your team is subject to in order to keep them happy and focused.

You’re probably familiar with the notion of technical debt and how it affects your team and the software you’re building. It’s a list of shortcuts in the codebase that you know you’ll need to address eventually, like functionality that won’t scale up, a known bug, or the reliance on an old dependency. Technical debt is easy to track but not always easy to pay down. Competing priorities are the difficulty there.

There’s usually an organizational process for acknowledging and cataloging technical debt.

Communication debt is a different beast: it’s all of the knowledge-sharing, messages, and notifications that need your attention, and in some cases, a response. You’re accumulating communication debt right now as you read this. Emails are hitting your inbox, texts are dinging your phone, shared documents are being edited, and discussions are happening in chat rooms you belong to.

Communication debt is self-cataloging in some form of a queue. Acknowledgement and processing it is generally a personal matter rather than a team process.

Unlike technical debt, there is no realistic way to avoid communication debt. Perhaps you’re managing it using a deliberate tactic, like “inbox zero,” or maybe you just respond to or ignore messages as they arrive. But that’s you.

What about your team? How are you helping them manage their communication debt?

If you haven’t thought about it, then the implied policy is that everyone triages on their own and possibly responds to everything in every communications queue.

That’s not going to work.

Obviously collaboration and progress require communication, but too much of it in the form of accumulated communication debt will absolutely kill team morale and productivity. There’s simply no way to keep up with all of the messages flying around. In a modern, collaborative software development environment, a glut of systems, dependencies, and other people generate tons of messages across a myriad of channels.

Without deliberate management of communications, your team either gives up and ignores potentially critical stuff (even ignoring stuff takes mindshare, by the way), or tries to deal with it all, leaving little energy leftover to build things.

How Communication Debt is Created

The Never Zero Inbox

When a person joins your company and team, they are usually added, by default, to a bunch of distribution lists. Generally, the bigger the company, the greater the number of lists. Your IT department might have an automated process to add all new developers in your office to DL:Engineers, DL:Boston, DL:Northeast, and of course the highly abused DL:All. Over time, this list never shrinks; it only grows as developers contribute to different projects or functional areas in the organization.

DLs are often a good way to share knowledge, but just as often they fill your inbox with distracting stuff your team can ignore. Things get really noisy when DLs are hooked up to Ops/Devops systems. On the surface, sure, it’s a great idea for all of engineering to know when response times are abnormally high, but the reality is that all of engineering will not be addressing the issue, and each of these messages are just one more bit of debt to manage.

Meeting requests are a subset of the email problem, especially when they are also hooked up to DLs. Meeting culture varies from organization to organization, but asking for an hour or two out of someone’s life span is not a process to be left without guidelines, especially with new hires who don’t yet have a good sense of which ones they need to attend.

Furthermore, the developers on your team known to have unique areas of expertise are especially vulnerable to unsolicited meeting requests, likely without your knowledge, right from day one on the job.

So new hires are deep in communication debt almost immediately. The IT person hands them their laptop, and the notifications from your various build and monitoring systems start to pour in, along with the meeting requests, HR process stuff, and other organizational rabble.

The Endless Chat Scroll

Team chat apps (Yammer, HipChat, MS Teams, Spark, but mostly Slack these days) are where communication debt gets completely out of hand.

If you’re lucky, your company has a deliberate approach to setting up and managing channels/rooms, and has enacted some sane defaults for notifications. Or maybe you’re smart enough to tweak the notification knobs into something manageable. But straight out of the box, you’re going to get a messaging mess.

As Jason Fried aptly put it, “Group chat is like being in an all-day meeting with random participants and no agenda.” Imagine how much worse that “meeting” gets at a large company with hundreds of participants.

Not only that, but now you can hook up pretty much any tool your team uses into your chat app. Bot and app notifications can double or triple the volume of messages. The “meeting” just became a riot.

Chat has been around for decades, but company-wide adoption as a business communication tool is still pretty new relative to traditional channels like email and phone calls. The consequence is that there is still no established etiquette for chat, so unless you’ve some clear guidelines in place, it’s an engine for generating communication debt, firing away 24/7. (The bots never sleep.)

Your team members will have to scroll through and parse everything to separate signal from noise.

Two big problems surface pretty much immediately: 1) It takes a lot of time and energy to scan all of these messages, and 2) The person or bot that creates the highest volume of messages will also occupy the most mindshare among your team.

Limiting Communication Debt with Force Fields and Protocols

It’s the modern manager’s job to shield the team from all of this distraction and noise. No one is going to be productive and happy when their communication debt is overwhelming.

There are two main ways you can help your team with this issue: 1) Filtering the noise before it hits them, and 2) Making sure there are explicit expectations for what and when they need to respond to communications. Call these tools force fields and protocols.

Force Fields

Start by making sure your team’s default setups are as distraction-free as possible. That means interfacing with functional organizations in your company at both the source of the messages and with whomever configures the communication tools.

Other team managers: Set expectations with other managers that they need to go through you to set up meetings with your team members or invite them to chat channels. Let them know you are guarding your team’s time and energy. Reciprocate and do the same for their teams. Be open to making reasonable exceptions, but set a precedent for this if you can.

HR: Get a rough idea of all of the necessary communications from HR to your team members. Document it all and put it in your team runbook (more on that below.) Offer to disseminate HR information to the team yourself if possible. Get involved with the process behind company-wide educational programs and team-building -- it’s the best way to ensure your team members don’t have their time wasted with this stuff.

IT: Curate and ruthlessly cull the list of email distribution lists each team member is on. Put yourself on any questionable lists instead, and then decide if your team needs the emails or you can filter for them. Offer to administer some of the lists yourself, which is usually appreciated and a good way to get this process started with the folks who manage this stuff. If your IT folks also run your chat app, cull and curate the list of channels/rooms your team is invited to. If possible, default all notifications in your chat app to “off”, and turn on only the critical ones. (You may have to do this on behalf of your team members instead of tweaking a global setting, depending on your chat app.) For paid plans in Slack, you can also set up default “do not disturb” hours. Get that turned on and configured, and align it with what you’ve got in the runbook.

Marketing/PR/Sales: Sure, all hands on deck to get the word out and make a sale! That’s what keeps the lights on. Just stick yourself into the process before overtures to help are made to your team. After all, you’re the person who best understands who from your team would be a fit for these kind of things.

You: Watch out what you email to the whole team and post to a team chat room, and make it count. You, the team lead, posted it, so everyone is likely going to think they need to pay attention to it, and that means their attention will be diverted from something else. For relevant articles or videos that you want the team to see, use email, not chat. (Chat apps tend to unfurl articles into big, distracting messages with an image.)

Protocols

In the Ops/IT world, a “runbook” is a living document used to outline the steps a system administrator needs to take to deal with certain scenarios. Need to add a new user? See page 4. Want to swap out an app server in the load balancer? See page 10. And so on.

Something like this can work for communication debt as well. The idea is to categorize and list out scenarios team members will encounter when it comes to responding to communications, and to document how you expect them to be handled.

Bigger companies will probably have some kind of HR-furnished employee handbook; this is different. It’s customized for your team and shouldn’t have much overlap with the handbook

A wiki of some sort is best, because you’ll want to update it as you continue to encounter scenarios where your team members are distracted by messages. (We store ours as a bunch of markdown files in a git repo.)

Ultimately, your runbook boils down to this:

Hey valuable team member, I realize you are going to be subject to more messages and notifications than it is humanly possible to deal with. I’m always going to do my best to stem the tide, but here are the reasonable expectations we have set up for the team to respond to it all.

Final Thoughts

Context switching is costly for software developers, particularly when it comes to complicated features and defects. In other words, little notification pings interrupt the flow of your team and ultimately reduce both the quality and velocity of their work. Take time to set up force fields and protocols to limit these interruptions. It’s going to take some effort, and possibly some politicking within your company to do so, but the investment on your part is well worth it.

Most importantly, an effort to stem communication debt conveys a powerful message to your team: your time and focus is valuable.

This post was originally published on the Status Hero Blog