Recent Posts (page 57 / 65)

Hello vs. NoHello

Hello or NoHello? It's a thing. Some people want the social lubricant, some don't. The first thing to remember is that Slack (or any other asynchronous communications method) is not a face to face, real-time, discussion, so the rules/norms/best practices are different. It's also much more likely to be remote/cross time zone :)

The two biggest things to remember in chat are

1) It's very hard to communicate emotion/expression/intent, which means the failure mode of "clever" is "jerk"

2) Asking if you can interrupt is already an interruption.

John Scalzi handles the first one well enough that I'll leave that to him.

The second is more community driven and we collectively need to figure out what our norm is. Like anything else group based it's a consensus/compromise. It's also situational. Expectations are different in a 1:1 discussion about a new work issue or about last weekend's new movie, or a request in a large group. My position is nohello, or if you feel it's rude/wrong, then preface your question with the salutation of your choice, then immediately ask the question in the same message. Notice that I don't say hello before I send out a post here. So what do we want our norm to be? Share your thoughts in the comments.

Asking For Help

I love helping our customers. As a person on the infra team I get to see my customers every day and I get to see the results of making their lives easier, helping them build self driving cars that drive more than themselves. Asking for help can be a good thing. You save time, you get to learn something, Knowledge is shared. If you do it right you also make it easier for the next person who runs into the same problem. But that's a topic for a future post.

Today's post is about a pet peeve of mine. As much as I loved to help people, sometimes it's hard. The worst is when someone posts a screenshot of some error text in the console. No context, no idea what the command was, not even copyable text. Just an image. And usually a blurry jpeg. Please don't do that. Whether it's email, slack, a bug report, or carrier pigeon, post real text. And post the command that led to the error. The more context you can provide the easier it is to help you and the less back and forth I (or anyone else) needs to do.

There are lots of lists of why this is a bad idea online, but my top few are:

1. I can't copy/paste the text, so it's hard (impossible?) to reproduce
2. Screenshots usually miss something important
3. Images aren't searchable (makes it hard for the next person with the problem to find the answer)
4. Invisible/non-printing/unicode issues are hidden.

Talking To Customers

How do you talk across functions? When engineers talk to other engineers, even across disciplines, there's usually at some shared language/terminology. When you start talking cross-functional, that doesn't always hold true. In fact, many of the assumptions aren't shared, and that can lead to huge misunderstandings. For example, you would expect your customer to know what they want.

And they do. They want it to not suck. They want it to be easier. They want it to be faster. There you go. 3 simple requirements. Go build the thing they want. What's that you said? Those requirements don't mean anything? Maybe not to you, but they do to your customer.

So how do you delight your customer? By understanding them. It's not their job to understand you, it's your job to learn enough about them to understand what they want AND to understand how to communicate what you're doing to them. If you don't know their world find an SME who does, or make sure someone on your team becomes one. Understand how they do their work. Watch them do it. Ask them why they do it that way. Find the business value they're looking for and provide it.

That's how you understand your customer, but how do you make sure they understand you? First and foremost, talk about what they can see. The business value. The workflow. The interface. Don't worry about the features you're building, but talk about the benefits you're delivering.

And a side note. Don't over-rotate on this, but never confuse selling with installing. Whenever you build something for a customer you need to continue to convince them that what you are building is worth the time and money it's going to take. Provide clear deliverables/demos with functionality. Figure out what your MVP is, then add to it. And listen when they provide feedback. That doesn't mean scrap everything you've done, but understand the problem behind the complaint and work to make it better.

The Juice Shop

I didn't get this posted during security awareness month, but it's timely nonetheless. Security is everyone's business, whether you're building a robot, a two sided marketplace, a shared infrastructure, or an online juice shop. Lots of things to keep in mind, and it's more than just "Who has access to what data?". What and how you deny access to something can tell an attacker a lot about your system and the protected data. Then there's the internal side, where good logging and ease of debugging are in direct conflict with keeping the data secure. And don't forget data combining. If you have a enough "innocuous" pieces of data you can put it together into PII.

There are lot's of don'ts when you think about security. At the top of the list is "Don't roll your own encryption". Instead, ask for help. Knowing you don't know is more than half the battle. Other little things like don't trust user input, don't assume good intent, and don't assume your API is only used internally.

There are also things your should do. At the top of that list is "Design security in from the start". Ask for help, Do threat modeling. Make your security model granular enough. Admin and non-admin might be enough, but do you need more? Make sure you maintain and update your systems as vulnerabilities are found (you do have a configuration based, repeatable, verifiable deployment system, right).

One way to play around with security and pen-testing is the OWASP Juice Shop. If you want to try it out and see what vulnerabilities you can find check out the opus link. Just set the User and Job Name fields then hit "Create". Follow the link that will show up in the top right of the screen, go to the details page of task 0 and click on the "http" port in the top right of that page. You should see your own little Juice Shop website to play with. Try it out and see how many vulnerabilities you can find. There's also a CTF version, which might be a fun little exercise for the group at large. If anyone is interested in getting that set up let me know.

What Are You Reading?

There are lots of great books on being a developer, and not just books about how to code (although they are kind of important). Algorithms, design patterns, compilers, all important. But there are also books that aren't directly about writing code. Books like The Cathedral and the Bazaar, In The Beginning Was The Command Line, Debugging the Development Process, or maybe, Zen And The Art Of Motorcycle Maintenance. Books that talk about the bigger picture. About understanding the bigger picture, how things fit together, and why we're doing the things we're doing anyway. I ran across this list that says it's got 7 Essential Books for Programmers. What books have made a difference in your career, both in your field, and in general.

Options

We've got lots of them. Almost always there's not one right answer for a given set of constraints, but there are often wrong ones. One of our jobs as engineers is to balance those constraints and make the right trade-offs for now and what we know about the future. We also need to keep in mind that the constraints can/will change over time, and the "right" answer might shift.

Consider joining two text files and doing some simple analysis on the results. You can do it with everything from an awk one-liner to a giant spark job that uses 10s (hundreds?) of nodes. Which one you chose depends, among other things, on how big your data is, where your data lives, how often you want to do the analysis, and how important it is to ensure that the analysis happens unattended on a schedule. If it's just you working on a few MB of data, and you know awk then that one-liner might be the right answer. If, on the other hand you're dealing w/ TB of data in an overnight pipeline that needs to be done by 6:00 local the next morning then ensuring the data is loaded into Hive on ingestion every day and having a distributed query that runs in a managed workflow system might be a better choice.

Assumptions

You know what happens when you assume. That happens everywhere. Especially with computers. They're logical. They do exactly what you tell them, even if that's not what you want. And of course, they're all the same. Or maybe they're not. Look at this from the 90s.

How many times have you heard the phrase "It works on my machine."? Of course it does. You built a bespoke system in an environment and it works. And our machines are centrally managed, so they're all alike, aren't they? Well I don't know about you, but I know mine is a snowflake. It's been adjusted to make me happy. It has my toolset. In the places I want them. It has my bash setup. My path, my macros. You have the same setup, don't you? What do you mean you're not on a Mac. And you're running tcshell. How are we supposed to interop? Very carefully. Just look at what it takes to decide what OS you're on in a bash shell
And then there's kernel and tool versions. Right now we have a mix of Ubuntu 16 and 18. I think we've gotten rid of the last of the Jessie machines, but I'm not sure. OSx tools are different from the tools on Ubuntu. And not esoteric tools, tools like du, head, ps and netstat have different options and act differently. And the FileSystem is laid out slightly differently, including your home directory. So you need to be aware of those differences when you write tools/scripts/libraries for others to use.

And then there's the general assumptions developers make. Things like address formats, name formats, time is a monotonically increasing function. My personal favorite is assumptions about distributed programming, and we're all involved in distributed programming.

So what's your (least) favorite assumption you've had to fight against? Share it in the thread.

Silos

They're not just places to store your grain. Information gets into silos. Processing gets into silos. And we all know that silos are a bad thing, right?

Duplication of effort. How many configuration management/payment/SWN systems does Uber need anyway? Everyone should be using thrift, and custom thrift over TChannel, not Apache thrift, unless you're working with gRPC, or over Muttley, or with Yarpc, or maybe even hyperbhan.

Working at cross purposes. Ever hear of NetDocs? Microsoft once tried to build an alternative/replacement for the Office suite. Staffed it big. Got some great ideas, then collapsed the team and brought the ideas into Office. Or maybe Kin. At that same time there were folks working on Windows Phone there was a team building the MS Kin, a feature phone for the smartphone era.

On the other hand, there are concepts like separation of concerns, DRY, IDLs, and the core Unix philosophy of do one thing and do it well ( then chain them together into a pipeline). We think of these things as good. And they are. But they're also all silos. So maybe silos aren't all bad. Being able focus on one thing and having clear, well defined boundaries and interfaces with your neighbors makes you more productive.

Like most things, silos, in and of themselves, aren't bad. Focused responsibility is good. To use Dara's term, "Who's got the D?" What is bad is when required information, plans, and goals get stuck in one place and don't make it to where they're needed. And that's the hard part. How do you balance providing enough information without wasting people's time? How do you get enough info to make the decisions you're responsible for without getting buried in the deluge? I've found that the best approach is to make as much info as possible available in a well known place (email group, file memos, architectural decision records, etc) and let those who need it consume it at their pace. On the other hand I like to see lots of information fly by and pick out the relevant nuggets and know where to go for more detail. YMMV. Share your best practices (and anti-patterns) in the comments.

Software As A Service

I think this says it all. 

GOLANG Oddities

Don't get me wrong, I like using go. It's clean, the standard library has almost everything I want/need, it's cross platform, and it's fast. VSCode, IntelliJ (and flavors), Emacs, and Vim have good support. Tabs vs spaces isn't a thing (gofmt has the one true answer). There are lots of people around that I can go to and get good answers. But…

Golang is opinionated about where things go. GOPATH is king, and woe betide any who think they know better. Including your favorite IDE. IntelliJ/VSCode have their own ideas about how to build things and where they should go, and it's NOT bazel's idea. So we have things like setup-gopath and copy-genfiles.

Dependency hell. Golang sort of eliminates that, because there are not dependencies. You just copy everything you need into your GOPATH and build/link. Simple. Works great in a monorepo with no external decencies. But that's not our world. Go modules help, but there's still the version management problem.

Slices. Slices are not arrays. Repeat that a few times. Now do it again. There are lots of good reasons for slices to be what they are, and they let the compiler produce some very fast code. Just don't forget and you'll be OK. If you do forget things start to feel like quantum entanglement. Spooky action at a distance.

Type safety. But use …interface{} since you don't know what's coming and that lets you get anything and figure out what it is latter.

So what's your pet peeve and workaround? Share in the thread.