Posts

• Oct 13, 2019

  Meetings are Broken

  Let me preface this essay by saying that I’m not anti-meeting. I’m against wasting time in meetings. A good meeting is great, but good meetings in the wild are as rare as agile done right.

  Why Meetings are Broken

  No agenda

  No agenda at all is a pretty obvious way a meeting can be broken, but the no agenda meeting can take other forms. A common form I have seen is a standing meeting for a given topic, say Project X. People feel like the meeting has an agenda (“hey, it’s about Project X”), but that’s not an agenda. What if there is nothing to discuss on Project X, then what? How would that be discovered prior to the meeting?

  Off Topic

  Even with an agenda, many times meetings simply veer off topic. People in the meeting use the time to discuss other things that is on the top of their current list. Effectively, they bring their disorganization into the meeting and spread it to every other person in attendance.

  Time Box?

  Time boxing can take a couple forms. There is time boxing the entire meeting and also time boxing each agenda item in the meeting. Ideally time boxing should not be needed. If a meeting is called to make a decision, the meeting should only end when the decision is made. But, time boxing is often used as a way to maintain urgency and keep the meeting from veering off topic.

  Synchronous

  Meetings are by nature synchronous. Every person in the meeting has to be part of that meeting at that moment regardless of what else they could be working on instead. Discussions in a meeting are also in real time. This leads to the topic presenter having an advantage over the other participants during the discussion because the presenter has given more thought to the topic. The other participants then either have to think quickly or can only really offer gut reactions to the topic.

  Late!

  Another obvious one is when people are late. First there is the cost of the meeting itself, but then delaying the meeting even further quickly puts the company in the hole. Five programmers at a fairly low salary can cost the company $40+ for every 10 minutes they are waiting around.

  Lack of Documentation

  This is a big one for me. I take notes in and after the meeting as a way to make sure what was discussed and decided is what happened. Even then, there can still be miscommunication about what was decided by who and why.

  Lack of Intellectual Rigor

  Talk is cheap. It is almost too easy to say something without thinking it through in a meeting. Now, I’m not talking about brain storming sessions to figure something out, but the typical meeting to discuss some agenda item. Writing forces a higher level of intellectual rigor that speaking does not.

  How to Fix the Meeting

  Nothing I’ve stated above is novel, yet companies still continue to have completely wasted meetings. I’m using this series of posts as a way to put some coherence to my thoughts, and will address how to fix meetings in a future post.

• Dec 21, 2018

  Effective Note Taking

  Speaking of Notes

  I learned note taking in college. In class I would write copious notes, and then transfer them to my computer as an outline that I could reference later. At the time there were not many tools that could easily input handwriting into the computer, and also make it useful. There were some tools that could scan pages, but they were cumbersome to use.

  Fast forward many years to now, and I am still searching for the perfect note taking device. I tend to bounce back and forth between a notebook, and some note type app on the computer. Both have advantages and disadvantages inherent in the media.

  A paper notebook is the optimal note taking device. I can easily make lists highlight items, and draw lines connecting ideas. I can also quickly draw diagrams or quick app designs. The problem is that unless I’m writing notes, I’m on my computer. Referencing my handwritten notes is a pain, much less easily sharing them. The most serious problem I run into is finding a note from last week or last month.

  It’s usually around the point when searching for a hand written note that I get frustrated, and vow to only take notes on the computer. After bouncing between many apps, the latest version of the Apple Notes.app is what I have settled on. Picking a note app is its own post, so I don’t want to get too far into that here. The general benefits of a notes app are the same. They are searchable, sync through the cloud, and are easy share with others. The big drawback is that they are not really the best way for me to take notes.

  Enter the 11” iPad Pro + Apple Pencil

  Writing on an iPad Pro with the Apple Pencil has a very nice feel. The Apple Pencil has a little less drag than a typical #2 pencil, and more drag than a smooth ballpoint pen. There is little screen lag that I can notice when writing or drawing.

  In the Notes.app, the written notes are OCRed in the background and made searchable. Even my sometimes questionable handwriting is deciphered fairly well. The notes are also synced across all devices.

  I do have some initial complaints:

  • Mixing typed and hand written notes is more cumbersome than it should be. When a hand written note is synced to the computer it can be awkward to start a typed section above.
  • Sharing from the Notes.app to something like Slack does not work. It processes like it is going to work, but then nothing shows up in Slack. For diagrams I have been using Linea Sketch. It is simple enough for a non-artist like me to get diagrams done. It also shares perfectly.
  • I do not like the noise the Apple Pencil makes when it first hits the screen to start writing or drawing. It might just be me, but I have started training myself to bring the pencil down more lightly when writing.

  Even with the shortcomings above, taking notes on the iPad Pro is a huge step forward for my note taking. Now that I have the iPad Pro and Apple Pencil, I plan to take another pass through note taking apps. I’ll update here if anything changes.

• Dec 15, 2018

  AWS SFTP Transfer with a Custom Identity Provider

  We were excited when AWS finally announced a hosted SFTP transfer service backed directly by S3. We had looked at other solutions that mounted S3 as a drive, but they always seem to have some random issues. What we had settled on was running an ftp server and then periodically sweeping the uploaded files into S3 for processing.

  The announcement made the setup process look simple, which it was for the specific use case where all users will manage their own ssh certificates. In our case though, users had to be able to upload files with just a username and password. And, ideally, it would be the same username and password they use to work in our other systems.

  According to the documentation for Custom Identity Providers, it should be a simple process of setting up a lambda and API Gateway end point. On a successful authentication, the lambda should return this json back to the SFTP Transfer service.

  {
    "Role": "IAM role with configured S3 permissions",
    "PublicKeys": ["ssh-rsa public-key1", "ssh-rsa public-key2"],
    "Policy": "STS Assume role scope down policy",
    "HomeDirectory": "User's home directory"
  }
  

  • We were not using PublicKeys, so they can be omitted.
  • The users home directory really means the full path, including the bucket name. For example, /sftp-bucket/username

  Role and policy were not so simple. First, read this post about IAM Assume role, and how to setup the basic scope-down policy. The writer does a good job explaining both, so there is no need to rehash the same thing here. But, that post only deals with setting up users that are managed by the SFTP Transfer service and not dealing with a custom identity provider.

  Looking back as the require json response, anyone who has experience with AWS IAM would look at the json above and think Role and Policy require ARNs. It turns out we were only half right. Yes, Role does require an ARN. The role must also have full access to the ftp bucket. The policy is given a set of variables by the SFTP Transfer service, and is applied in real time. In order for this to work, the policy must be passed inline. Let me repeat that, the entire policy must be returned inline from the lambda function.

  We could not find this gotcha in the documentation. There were hints in how scope-down policies are used though. Because they are assumed at usage time and passed variables, they cannot be attached to roles ahead of time. We incorrectly thought that the SFTP Transfer service would look up the policy based on its ARN, and do the replacement then. Instead, it treated the ARN as json which obviously failed and gave the final clue to the issue - a CloudWatch error from the SFTP Transfer service that read invalid json when a user logged in.

  Finally, since we like to manage all our IAM policies through an external tool like Terraform or CloudFormation we did not want a random policy sitting in a lambda function. We went ahead and implemented what we thought the SFTP Transfer service was doing and looked up the policy json using the AWS SDK getPolicy() and getPolicyVersion() functions. This way the policy is managed along with all our other policies, and is dynamically loaded in the lambda with the json returned.

subscribe via RSS