Skip to content
February 2, 2010 / zlost

Efficient collaborative resource allocation in software engineering

This post was originally a reply to this fragment of advice to less experienced programmers.

Never say “can’t” and never say “that’s a lot of work”.

Instead, say, “I’ll try” and just give a good effort.

I feel like the poster’s intent is noble, but the resulting advice is quite bad in certain scenarios:

Imagine your manager asks you to perform a task that she considers trivial.

  1. What she doesn’t know is that the task will take quite a few hours to get right.
  2. What you don’t know is that it’s of comparatively little value and your time would be better spent working on a new feature (see below), or perhaps streamlining your codebase instead of complicating it with bells and whistles from which your users will garner precious little benefit.

I believe the ability to collaborate openly on this sort of value judgment is something conspicuously absent from too many corporate cultures. Instead, programmers just throw their hands up as if to say “You’re the boss, so I’ll do whatever you want (as long as I get paid).”

This feedback loop must be especially tight for startups, since a startup must allocate its scarce resources efficiently if it wants to stay lean and agile instead of turning into just another enterprise with a lower number of employees and dollars. High productivity focused in the wrong direction is worse than low productivity in the right direction.

In case you run out of useful features, here are some ideas to get you thinking:

  • Make the user experience as effortless as possible
    • Replace full pages loads with ajax for small changes to the page
    • Don’t make the user click twice when he only need to give feedback once. This isn’t the 90s, try to avoid wizards.
  • Implement better abstractions of data shuffling mechanisms as simple, stateless web services.
  • Improve test coverage. NB: simple, stateless web services are easy to test, which is even better if they’re at the core of your app.
  • Add useful, organized logging. Your future self will tip his debugger’s hat to you.
  • More detailed analytics. It’s like farming useful feedback from your users with no effort on their part.
Advertisements
January 27, 2010 / zlost

How to be a stealth geek

  • Make eye contact.

    I don’t know if there’s an optimal frequency or rhythm to this. I guess it varies.

    • Look at your interlocutor when she speaks to tune in to non-audible channels and to convey your attention.
    • Look at your interlocutor when you speak to give her access to the same non-audible channels and to convey sincerity
  • There’s a boundary between insightful and pedantic.

    • The location of the boundary line is a function of context and audience.
    • It’s hard to guess this location right away, so choose the side you’d prefer to err on1.

Just a couple points for now.

1Pointing out that I ended this sentence in a preposition is a prime example of crossing the insightful → pedantic boundary.

January 26, 2010 / zlost

Limitations of Hashing

Don’t Hash Secrets (via). Informative, accessible article that sketches the limitations of hashing, even with a salt.

I’d like to add a few annotations:

An attacker can build up a huge dictionary of hashed passwords just once, and, when he breaks into your web site, check the hashes against this pre-built dictionary.

This set of pre-computed passwords is often referred to as a rainbow table. As the article stated, salting complicates such an attack.

But it’s going to be darn hard for you to find any other document, big or small, that hashes to the same 30 characters.

[…]

In fact, you can try something that should be easier: rather than find another document that hashes specifically to those 30 characters that represent your baby, you can go looking for any two documents that happen to hash to the same thing (collide). And you won’t find any such pair. Promised. We call that “collision resistance”.

More specifically, the first paragraph refers to weak collision resistance, and the second refers to strong collision resistance. If a hash function has the property of strong collision resistance, this implies that it also has weak collision resistance, but not the other way around. In some (most?) applications, including storing passwords, weak collision resistance is sufficient. So it’s worth thinking twice before throwing out your favorite hash function (SHA1) if (when) someone breaks strong collision resistance on it.

January 22, 2010 / zlost

Python boolean coercion gotchas

In Python, the following two expressions evaluate to True:
False == 0
True == 1

The following two, however, evaluate to False:
False is 0
True is 1

But Python’s in operator behaves like it uses == internally, so the following expressions evaluate to True:
True in [1, 2, 3]
False in [0, 5, 6]

The above result took me by surprise today. Since I consider this behavior a wart, I came up with a workaround.

January 8, 2010 / zlost

Open wireless networks: More dangerous than you think

Unprotected wireless networks can be convenient. But they can also be scary. If you use such a network as your main connection, you’re playing a dangerous game with your usernames and passwords. And profile information from all of the sites you frequent enough to have an account. And browsing habits. And cookies. Emails. Tweets and private messages. Online purchases and accompanying credit card numbers.

Clearly it doesn’t take a grad degree in computer science with a specialization in security to recognize the severity of this risk. So why do so many of us dive carelessly into this snake pit headfirst? Perhaps it’s the oft-underestimated network effect.

You know know, if you have unsafe sex with him, it’s kind of like having unsafe sex with all of his unsafe parters and their unsafe partners and so ad infinitum. Getting scary again, huh? Take heart, we’re just talking about your secrets.

So here’s how this network effect works. If any machine sharing wifi with you has been compromised, it can be used by the attacker for a variety of nefarious purposes. One is to monitor traffic on your local network, like an inside man or double agent. A more direct attack can also be staged, possibly resulting in gaining access to your machine, not just the data it sends over the network.

Is this article another instance of scare tactic propaganda? Actually, no. You and I can eliminate this threat with relative ease. The best part is we won’t even have to take our shoes off and put them through a scanner.

“But my network is protected by WEP encryption with a 128-bit key!”

Sorry, Poindexter, that’s just not good enough. You have to take your shoes off too. WEP is (marginally) better than nothing, but it’s is easily cracked. Even WPA2 has vulnerabilities.

My intent is not to plug a specific product. Do some research and set up a secure network. It can be just a matter of buying and configuring the right router. Let’s remember, high-tech threats require more sophisticated countermeasures than latex wrapping.

January 6, 2010 / zlost

Stupid Keyboard Tricks

  • ctrl + delete = delete to nearest delimiter (including whitespace, _, and camelCase), only works in textmate
  • option + delete = delete to nearest whitespace, works in everything
  • ⌘ + delete = delete to the start of the line from the cursor

Also, ctrl + click is right click on a notebook so it’s convenient to re-bind caps lock to control for carpal tunnel purposes.

    December 15, 2009 / zlost

    Mistakes Smart People Make

    No one knows why people do what they do.

    —Donald Draper

    There’s a Mad Men quote for any white people in the audience, and what a pithy fragment of writing it is. If truth is beauty, then this is an aesthetic experience in nine words. After all, do you always know your own reasons for everything you do?

    When asked to explain a past action of mine, here are my favorite euphemisms for  “I have not a clue”:

    It seemed like a good idea at the time.

    Note the attempt to shift blame to my past self, that idiot.

    Because that’s the way we’ve always done it.

    Note the attempt to shift blame to the other members of the group “we.” Often these members are simply the rest of humanity.

    I guess I just didn’t think about it.

    Translation: I’m so oblivious that not only did I screw up, I wouldn’t have even realized my mistake if those affected by it didn’t point it out explicitly. Read more…