Tag: Ownership

Putting Pen To Paper

Putting Pen To Paper

By | | Comments 0 Comment

I spent some time today chatting with an early career colleague who’s looking towards a future career in the dark arts software development. Being the kind of person that enjoys the sound of my own voice, I enjoy these opportunities to pontificate. One piece of advice I routinely give is that good engineers write well, and developing this skill will pay itself back with copious dividends.

However, that shouldn’t be read to mean that quantity trumps quality. Far from it, keeping things brief is usually more difficult than not (I know I’m bad at rambling, kinda like I am now). Which is why I found this little article on the value of the humble readme such valuable advice.

The other day I published a blockchain solution on Github, and while I’m pretty proud of the code, the readme is in bad shape (as of today at least). For my next project (a refactoring of the core of this solution into a reusable CDK construct) I think I’m going to write the readme first, as the above article suggests. We’ll see how it goes!

Takin’ Care Of Business

Takin’ Care Of Business

By | | Comments 1 comment

Love them or hate them, ticketing systems like Jira or Asana are an essential part of modern software engineering. Misuse is rampant, but wielded well, ticketing systems align teams around common goals, unburden them from pointless status meetings, and unlock accelerated development with better accountability and fewer defects.

What are some ticketing best practices, you ask? I have thoughts:

  • Work of any significance should be captured in a ticket. My rule of thumb is anything that takes longer than a few hours.
  • Tickets are not a substitute for good requirements and design documentation. Instead they should capture specific tasks to be accomplished, including links to other docs as needed.
  • Writing tickets is not only the responsibility of the team lead or product manager; a team should own its ticket board. If the current set of tickets does not match the reality of what is being worked on, make it so be rewriting, breaking up, and deleting tickets as appropriate.
  • Being assigned a ticket is a form of promise. It says to the team “I will accomplish this task in this amount of time.” Each engineer should thoroughly understand all of the tickets assigned to them, proactively seeking out guidance if they don’t, and making clarifying edits as needed.
  • Know how metrics such as velocity and completion dates are computed. Their value is only as good as the ticket data used to calculate them (garbage in, garbage out), so ensure values like story points are accurately tracked.
  • Avoid Bricklin’s Law by embracing healthy use of a ticket system, and others won’t feel the need to add more status tracking. Done perfectly, it renders other status checkpoints redundant, maybe even those daily standups you dread.
  • Finally, tickets are a means, not an end. Don’t lose sight of your ultimate goals. If your ticketing process isn’t helping you achieve those goals, change it.

The above list is far from exhaustive. Any other suggestions out there?

Be Kind, Not Right

Be Kind, Not Right

By | | Comments 0 Comment

Several months back I read The Phoenix Project, a tale about how one company changed its IT culture to great success. I found the advice mostly good, and the idea of dishing it out in narrative form kept things interesting, though I’d hardly call it a page-turner.

However, one aspect really bugged me about it: the “guru” character Erik is a real piece of work. Talking down to his colleagues. Deliberately getting names wrong. Assuming his own body odor smells of perfume, as the Amazon leadership principle warns against. In the actual world, without kindness, it doesn’t matter if you’re right all the time, no one will listen to you. This is just as true in the realm of technology work: ever been told to RTFM and felt like an idiot? You’re not alone. I have to fight being that kind of jerk, but it’s a fight worth having.

And of course it really shouldn’t be that hard of a fight. Just do the little things: be on time, be responsive, be quick to listen and slow to criticize. Be patient. Treat others as they wish to be treated.

Oh, and learn your colleagues names, both spelling and pronunciation. It’s a basic gesture of respect that goes a long way.

Word Salad

Word Salad

By | | Comments 0 Comment

Yesterday I was notified via email that some of my personal information had been compromised by the ParkMobile app. Besides the obvious question of why it took them two months to contact users proactively (vs a post on their website), I found this paragraph a blend of confusing and concerning:

Encrypted passwords were accessed, but not the encryption keys required to read them. We protect user passwords by encrypting them with advanced hashing and salting technologies.

So many things wrong with the above. First, passwords should not typically be encrypted, and certainly not in a way that would allow a company to read them. The better approach is to hash them, which ParkMobile mentions later, but encryption and hashing are not the same thing. It’s hard to trust an organization that doesn’t know the difference.

Additionally, the adjective “advanced” gives me pause. It’s not communicating anything of value. Why not instead tell me the exact algorithm used, such as bcrypt, Argon2, or PBKDF2? Most likely the person writing the response doesn’t really understand the technologies used to protect passwords. And claiming something is advanced when one has no ability to know if such a claim is true screams Dunning-Kruger effect.

Ironically in an attempt to express competence, ParkMobile has done the opposite.

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.