Tag: Ownership

The Lies We Tell Ourselves

The Lies We Tell Ourselves

By | | Comments 0 Comment

I’ve written before about the importance of writing documentation. Like anything else it’s a skill that takes both training and practice. The latter only takes time, but there’s not a lot of material out there on the former. Therefore it made me happy to discover Write The Docs, a global community of people who care about documentation.

The recommendations in their Beginner’s Guide To Writing Documentation I found quite helpful. And loved this quote, which is only tangentially related to docs:

Fear is what happens when you’re doing something important. If you are doing work that isn’t scary, it isn’t improving you or the world.

The article argues that writing documentation for yourself and others is one way to alleviate fear, and I agree. So go forth and write!

Slacker Part Deux

Slacker Part Deux

By | | Comments 0 Comment

The advice in Five Nonobvious Remote Work Techniques is broader than just Slack, but given my prior post on best practices, I thought I’d mention it for further reading.

Technique number three from that article made me think of an additional helpful hint for Slack conversation. If you initiate a conversation via at-mention, you should be prepared to dialogue in real-time. There’s a cost to causing an interruption to another person, and one should try to minimize the duration of said interruption by treating the interaction as if it was an in-person conversation.

Also, No Hello. Get to the point.

The Name Of Things

The Name Of Things

By | | Comments 0 Comment

If you cannot say the words, you cannot solve the problem.

This is true of many subjects in the world right now, a crippling inability to call things what they are. But it is also true of software development. I’ve written before about the importance of accepting blame when something goes wrong. The first step of that process is being willing to say what went wrong, to name it with precision. Shortly thereafter the people responsible for ensuring that particular thing doesn’t go wrong should be named, not to shame them or make them feel bad, but so they can be given the opportunity to improve in the future.

While it might be easier to “not point fingers”, such an approach rarely helps an organization get better.

Dirty Work

Dirty Work

By | | Comments 0 Comment

Developers like to write code, that’s what they do. But being a software professional means working on a number of other tasks, some of which are decidedly un-fun. The wise developer recognizes the importance of these tasks and approaches them with no less effort than their more enjoyable work. Grooming a task list. Writing documentation. Cleaning up repositories. Slogging through a naming refactor to improve consistency. She knows that these will all pay off in the long run.

Yesterday I spent nearly 10 hours working in JIRA, getting my head around nearly 150 tasks that need to get done in the next 3 weeks. Circumstances had forced me to be pretty heads-down in dev-world the past couple months, and my planning responsibilities had fallen by the wayside. I owe the team more than haphazard and vague requirements, and this is the first step to doing better. Here’s to a full July!

Tyranny Of The Urgent

Tyranny Of The Urgent

By | | Comments 0 Comment

A wide variety of tasks face the developer each day. Some can be accomplished quickly, like responding to emails, and some need much time, such as implementing a new product feature. Some require little thought, like cranking out a refactoring across several components, and some take a lot of mental energy. Some have immediate near-term deadlines, and others are not due for some time.

It’s particularly easy to focus only on the tasks that must be done soon (so-called “urgent” work) but the responsible developer must fight this tendency. Urgent and important are not synonyms.

Ain’t No User Here

Ain’t No User Here

By | | Comments 0 Comment

Here’s a new one. I was debugging a problem with a web server that hadn’t been used in a while that was allowing users to log in, but failing to perform a number of other functions (gotta love an API that happily returns a 200 OK even though it’s clearly not working because there’s no data in the response). No one could think of anything that had changed, but clearly something had.

After some spelunking through logs, I found some DB permissions errors. Obviously some DB calls were working, so that was odd, as I knew credentials were only specified in one place.

Another hour of research later, I discovered that MySQL views run as the user who created them, not the user who queries them. This actually makes sense for use cases where you want to give controlled read access to parts of the DB to a less-privileged user. Logically then, if that user is deleted, the view fails to run. And in this situation that’s exactly what happened.

There’s a number of lessons to be learned from this situation:

  1. A user probably should fail to delete if it owns other objects in the database. Otherwise unexpected side-effects occur.
  2. Accurate error messaging is essential to debugging. When trying to run the view, I got a simple “user does not have permission” error, which told me nothing about the underlying problem, which meant another hour or two of research. This goes for APIs especially. Please know when to use a 4XX vs. 5XX error especially, and even better learn the subtle differences between 502, 503, and 504, and when each should be used.
  3. Don’t try to diagnose problems on Friday afternoons before holiday weekends. You’re asking for trouble.
Docker Fail

Docker Fail

By | | Comments 0 Comment

One of my favorite truisms in software development is the following:

“When two things aren’t the same, then they’re different.”

I don’t care how hard you work to make development and production environments the same, I don’t care how portable you think your programming language is across operating systems, and I especially don’t care about claims made on a product’s marketing material. Case in point:

[Docker] makes for efficient, lightweight, self-contained systems and guarantees that software will always run the same, regardless of where it’s deployed.

No doubt the Docker team has worked incredibly hard to make the above statement true, but nothing in life is guaranteed with 100% certainty. Last week I discovered that the cron utility will not execute any crontab or script that has more than one hard link pointed at it (don’t ask me why not, it just doesn’t). And due to the way Docker’s overlay filesystem works, the operating system can report a regular file as having multiple links. At least it does when the container is running under Kubernetes. But not always! When running with docker-compose on my Mac the crontab only reported one hard link, and thus cron worked great.

Took me nearly a day of fiddling to determine why the container worked great locally but failed in Kubernetes. Argh.

Share In The Blame

Share In The Blame

By | | Comments 0 Comment

In 2007 I spent most of the summer in the desert flight testing a sensor system in the back of a C-130 (incidentally, our test aircraft was used a few years later in the filming of the opening scene of The Dark Knight Rises). During my off-hours there wasn’t much to do in town, so I listened to quite a bit of music, including this particular album:

The message of this song is one I believe applies to many areas of life, software development not the least. As I said yesterday, in any situation where a mistake is made, no matter who committed the error, it’s a worthwhile effort for everyone involved to consider what they could have done differently. The way I figure, to admit absolutely no responsibility is to relinquish the one bit of control I do have over a situation, namely myself. And that’s a power I’m unwilling to give up.

It can be scary to live in a state of constant self-evaluation, but I find it freeing. It’s the mark of deep-seeded insecurity when one is unable to admit his own faults.

Covfefe

Covfefe

By | | Comments 0 Comment

Even the smartest and most experienced developers make bone-headed mistakes, the kind that require hours of painful debugging only to find a comma was misplaced, or a one should have been a zero. While a good amount of effort should go into avoiding these errors, the energy required to prevent them completely would be astronomical. A better approach is to balance prevention and detection, hence the importance of good peer review and solid automated testing.