Log in

No account? Create an account

How to make statistics lie

A coworker looked at number of Pivotal Tracker points, plus looked at GitHub commits in our current product, and purely based on those numbers it looks like our junior dev is twice as productive as me, and the slacker that we let go is, too.

Since I knew that was false, I took a closer look. If you go purely by the graph for our current product, I didn't commit anything from September of 2013 to midsummer, 2014. However, this was far from the only product that I've been working on.

First, there are FIVE other source trees that I contributed code to.

Second, I had 133 commits in our one product, starting in May of last year (which itself isn't true; I think I might have been accidentally committing under a different login), but those 133 commits consisted of >25k lines added... and >24k lines removed.

I do a lot of refactoring, and I've also made architecture changes. Our junior dev made 380 commits totaling >19k lines added and >12k lines removed over the entire period from September 2013 to now. Looking at our comparative commits over the same time period is more meaningful. I'm actually significantly more productive than the other two engineers, and my commits tend to be larger than theirs.

Third, I realized that I tend to find bugs or make improvements that lie outside the scope of the story I'm working on. This is a bad habit which I intend to break; for one thing, change sets should be isolated as much as possible for a given story in order to minimize the effects in other areas. For another, it hides extra time I am spending fixing things, and that's bad - it can make me look bad, and it doesn't help with estimating our effort.

Last, number of lines added does not necessarily add up to good code or productivity. The slacker dev liked to copy and paste, a lot, and wrote a lot of seriously spaghetti code. I find myself still going over his changes and simplifying.

It's important to understand what lies behind numbers before you use them.

Why you should still write tests.

Today on our staging server, one of my coworkers found a problem saving due to a change I'd made. The reason was that I'd added some validation to the parameter and SimpleForm was adding a hidden, blank input to set of checkboxes, which automatically invalidated that field. I was surprised that our feature tests had not caught this. It turned out that we didn't even have a feature test for it. The response from my coworker was, "another reason why unit tests are overrated - and can lull us into a false sense of security but more on that later"

This is an ongoing argument between the two of us. I don't entirely disagree with that statement, but we are coming at it from two opposite directions, and the way he is using it is as a straw man: feature tests are not unit tests; they're integration tests. "Unit tests are overrated" is a broad generalization that is nearly impossible to prove. Lastly, I've observed that he uses this as a reason not to write tests, whereas I simply acknowledge that writing tests won't catch everything, and write them anyway.
Read more...Collapse )

config.assets.compile = true # DON'T.

A year after the fact we (well, I) finally upgraded to Rails 4. One of the things that I had to do a little digging about was how to get our assets properly compiling again on Heroku. Here is one thing you should NOT do:

config.assets.compile = true

The answer to this Stack Overflow question explains why this is to be avoided, in great detail. It's easy to miss this post if you aren't looking for it. It's also tempting to turn compilation on, because if your assets are not being found, this will probably fix it, and there are other answers in Stack Overflow which recommend it. Don't.
Just wanted to point out something I've observed in the workplace. If you've spent a lot of time around dogs, you know that when you get a new dog, the dog is relatively shy and reserved for awhile. After a couple of months, the dog starts pushing the boundaries a bit, but generally speaking, between three and six months in the new home, the dog's "real" personality starts to come out. This is somewhat true for cats, too, but it is definitely true for people.
Read more...Collapse )
So in short, people don't show their full selves for months, learn how to see through this, and keep in mind that if you hire the wrong person, you'll likely be stuck with them for at least six months.


Quantum computing and security.

There have been a lot of articles recently (I wish I could find the one that prompted this) about how quantum computing will completely neutralize cryptography and/or computer security.

I am hardly a security expert, but I've been keeping an eye on the progress of quantum computing. My physics background also gives me a greater understanding of the technology (and any associated math) than most. the article I read rightly pointed out that quantum computers are still many years off, even if the NSA is actually building one. In my opinion you should count on that; they'd be foolish not to. However consider the many, many millions of dollars required for the R&D and then to even build a production-level quantum computer. Only technology-minded, well-funded governments with the ability to attract world-class researchers and build or have world-class research facilities could afford to do this. In my opinion the most likely candidates besides the USA are Qatar, Israel, China, Germany, Japan, South Korea, and possibly Russia and India. Regardless, if usable quantum computers are many years off, quantum computers that are affordable to even well-funded criminal organizations are even further off. This means there is some time to prepare left.
Read more...Collapse )

Off-topic: On managing your ego

Our Rails Lead quit today. I'm not surprised at all; when he first came on board in January of this year, after working with him a few days, I gave him 6 months, so he lasted about 4 months longer than I predicted. Now this guy is very, very knowledgeable, and he's contributed a lot of that expertise for good, but because of his personality, I'd say he detracted from that contribution by about 30%.
Read more...Collapse )
One of the best ways I heard it put was, about half of your job is to be able to work with others. If you can't do that then you've earned at best 50%, which is not a passing grade. If you see yourself being described here (or perhaps even if you don't), the salient points here are, no matter how "good" you think you are:

  • You're not necessarily the smartest one in the room; even if you are, you're probably so close that it doesn't matter.

  • Intelligence, for the tech industry, is a requirement, so everyone has that one. You need to be more than that.

  • Knowledge without wisdom is nearly useless. Wisdom is something you only get with experience. Remember that when you're talking to the oldies.

  • A company's success depends on the combined and coordinated efforts of many people, of whom you are only one, and anyone can be substituted. I mean that; literally anyone, and if a company goes down because one person is gone, it never deserved to go anywhere. If you're too much of a PITA, even if you aren't asked to leave, you'll definitely never be invited to work with them at a different company. There are many former coworkers on my personal blacklist, who I will aggressively advise against their being hired at a company where I'm working, should they come up as a candidate.

  • Be nice. I don't mean suck up, I don't mean be phony, I don't mean be a doormat. I mean: don't yell at people, don't belittle or be insulting, do solicit their feedback, do let them talk. Be polite and pleasant. Studies show that nice, less competent people are more effective than assholes because everybody wants to help them and work with them. Just think how far a nice, extremely competent smart person will go. (See "Competent Jerks, Lovable Fools, and the Formation of Social Networks")

  • Company success is your success.** Help make it happen. Try "is there anything I can do to help?" on for size.

** If it's not, that is, if you're not benefiting from company (or organization) success, time to leave; it's probably being run by assholes.
We have all of our repositories on @GitHub and we initially tried a pure Git flow model, however, that was too clunky and involved for our needs. We have recently switched to a process where we use git flow to create a feature branch, push it and when we're ready to merge with develop, we create a pull request. Once merged we do releases directly from develop (the nature of our web application allows this). Pull requests are not merged until at least one person gives it the go-ahead. We've been using our own judgment on this; for simple changes one other person's okay is enough, but for more complicated ones we generally wait for more team members to comment.

What we've found is that this results in cleaner, less buggy code once merged to develop. Bugs, misunderstandings and inefficiencies are usually caught very early on, because this process not only requires code review, but makes it easy. Github's pull request UX is great; discussion and diffs are simply tabs in the pull request page. Comments have some limited markup, and can include screenshots, which is awesome for illustrating any issues with the pull request. If the merge has to be done by hand it's shown right there and you can do your rebase and push again.

Additionally, I'm very satisified with GitHub's @TravisCI integration. The pull request shows right away whether the tests have all passed and it's "safe" to merge.

Here's a gist of some of the Bash functions and aliases I use to make things even easier:
This has bitten me twice now so I'm posting it here.

We had a jasmine test failure that failed only on Firefox and not in Chrome. We had significantly changed our forms UX so it was not surprising that weird failures would occur.

It turns out that, jQuery("select")[0].value returns the value of the selected option in Chrome, but only the value of the first option in Firefox. I had overlooked the selector we were using and that is how I discovered this. Note this is not about jQuery behavior but JavaScript.

To observe this failure, construct a jasmine test that chooses an option from a select tag like the following gist:

Now open console (Chrome) and Firebug (Firefox), and run the test in each.
In Chrome, the outputs will both be "baz."
In Firefox, the outputs will be "foo" and "baz."

In short, you shouldn't be asking for the value of a select anyway; you should always get the value out of the selected option.

We did not properly migrate our UI changes in our specs and so I was fooled into thinking the jasmine tests were passing (because I was running them under Chrome), when they would fail on our CI (which runs jasmine under Firefox). It happened again, for similar reasons in our Backbone form View, too.

Heroku boot-crash loop

Once again, haven't really seen this posted elsewhere, but if you deploy to heroku something that you know works (especially on staging), and there are no other indicators as to why it is happening, a heroku app stuck in a boot-crash loop may be fixed by:

heroku restart

Yes, that's it. If it's stuck in a boot-crash loop, try restarting. Go figure.

My javascript-goes-at-the-end trick

I don't think I've ever seen this solution anywhere else (perhaps because it's obvious), but it seems to work well for us. You want to speed up your page loading by putting all the javascript at the end, no? However you don't always know ahead of time, in Rails, when you need to call certain functions, etc. So this is what we do:

In my partial template that is included in every layout, views/shared/_footer.html.haml, we have the following, last:
    = yield :extra_javascript

In any template where we want to call some specific function in my numerous javascripts, we do as in the following example:
- content_for :extra_javascript do

===> Be sure to restrict this tactic to main page templates, and avoid putting it in partial templates unless you absolutely have to, where you know for a fact it won't be included multiple times on the page.

===> Also note that this code will NEVER be executed in an AJAX response, because it always comes with the footer, i.e. only with a full page load.

NB: this post triggered a code review where I realized we had way too much of this in partial templates.

Latest Month

January 2015


RSS Atom
Powered by LiveJournal.com
Designed by Terri McAllister