I remember one day in college, a friend came into the commons area of the dorm
where I lived and asked me and some other friends if his purple velour shirt
made him seem less masculine. A couple of guys gave him a hard time, making fun
of him for wearing such a shirt. I don’t think they actually cared about his
shirt; it was more the asking, and the insecurity that suggested, that they were
teasing him about.
We often think of pride as a good thing. It certainly has its benefits. The
notion of having pride in one’s work leads many people to do better than they
would if they didn’t care. But my mother always said, “Pride cometh before a
fall.” Even as we celebrate pride, in the backs of our minds we know that it can
be a weakness too.
To clarify: by “pride” I am referring to the psychological need to be
recognized. I believe it is an overloaded term, so I know that when we speak of
pride that isn’t necessarily what we’re always talking about. But this is what
was on display when my...
Whenever I see someone talk down to someone else, I think, “What was the point of that?”
Don’t get me wrong: I do it too. But even when I’m the one doing it, I still ask myself that question, usually a few minutes later after the buzz has worn off. What was I trying to accomplish there?
Being talked down to has never caused anyone to think critically about a position. It’s never prompted earnest soul-searching or opened anyone’s eyes to anything. Talking down to people just makes them furious, as well it should, because the only real reason to talk down to someone is to make them feel bad, while making yourself feel better.
It’s basically stealing: you’re taking from someone else and giving to yourself. It’s just that instead of taking someone’s money you’re hurting them emotionally. Instead of profiting financially you’re getting a temporary emotional high at the other person’s expense.
I kind of think talking down to each other is an epidemic in this country. I say this as someone...
In school, we learned about series and parallel circuits. In a series or “daisy chain” circuit, the
same electrical current flows through each component (say, a light bulb) in series, such that a
single failed component brings down the whole chain. A parallel circuit, on the other hand, isn’t
really a single circuit; it’s many circuits, all wired up in parallel so that one component can
fail without affecting all the others.
Series circuits have at least two serious problems:
They’re fragile: all it takes is one failed component to break everything. Moreover, the
bigger the circuit (i.e. the more components it has), the worse this effect is. The odds of any
one bulb failing are much greater when you’ve got 100 bulbs vs. just a few.
Once they do break, they’re difficult to fix. I’ve heard harrowing tales1
of my parents' generation dealing with strings of Christmas lights that went out, having to check
potentially hundreds of bulbs one by one in...
I have a feeling anyone reading this is likely to feel that the answer to the question Should we write our own tests? is obvious. But obviously what? Yes or no?
Let me first make a confession, which will probably (and understandably) be offensive to anyone reading this who identifies as a QA, test engineer, or something along those lines.1 For some time now I’ve held the belief that we as software developers should definitely be writing our own tests, and so the role of software QA is one that shouldn’t have to exist.
To be clear, I have met plenty of very smart and capable QAs and I have never questioned the value of their work. I guess you could say I thought of software QA teams as sort of a necessary evil, a hack to provide better quality assurance given that many devs simply don’t write tests, or write crappy tests. But if devs would just do their job right, I thought, QAs wouldn’t be necessary.
I also thought of QA folks in the context of big waterfall environments where software...
We actually used this strategy—my teammates and I, under Pete’s leadership—on a project while I was at ThoughtWorks called EMB. It worked well, and I do think it’s a sensible approach. My feelings on the subject don’t end there, though. My opinion is a little more complicated than a simple thumbs up or thumbs down. So I thought I’d take a minute to write out my thoughts.
Real constraints and artificial constraints
In any line of work, there are going to be constraints. Some are real—by which I mean, there is no avoiding them—while others are artificial, constraints we impose on ourselves.
A grammar example would be “Never end a sentence with a preposition.” This isn’t an actual rule of English grammar that you’ll find in any grammar book.1 It...
You’re building a forest. You have big plans for this forest; it’s going to be big, and green, and
beautiful. A swath of trees will sweep over the rolling hills here, there’ll be a tranquil little
clearing there. It’s breathtaking in your head. It will be glorious.
Naturally for a forest, you need trees. And you want beautiful, elegant trees. So you recruit the
top treebuilders from the best treebuilding academies. You’re going for the top talent.
These guys get to work, and right away you’re pleased. They know trees; that much is obvious. Left
and right they’re constructing trees of every kind: from simple, lovely little cherry and birch
trees up to towering, majestic redwoods. Every one is gorgeous, and you couldn’t be happier.
Months go by, and you survey your project from the top of a hill. Over time you begin to grow
concerned. Whenever you visit the treebuilders below, you can see that they are busy doing very
impressive work. But when you return to the hilltop, the developing...
Here’s an observation I find myself making pretty frequently. While it’s probably obvious to some, I think a lot of developers don’t think about it. So my intention is simply to plant the idea in your head, in case it wasn’t already there.
Two kinds of developersment
There isn’t just one kind of developer. Broadly speaking, there are at least two kinds: library developers and application developers.1 That isn’t to say that each of us falls 100% cleanly into one category or the other. I consider myself both. But when I’m wearing my “library developer” hat, my work looks very different from when I’m wearing my “app developer” hat.
It’s tempting to view us all the same: we all tackle the same problems, so the same rules and principles apply to all of us the same. But that simply isn’t reality. A lot of heated debates flare up on the internet between developers about the “right” way to build software, or what “matters” and what doesn’t; and what I think is often really happening is that...
I find myself growing more and more passionate about the idea that we’ve barely scratched the surface when it comes to building intelligent tools that can and should amplify our capacity as human beings. If a person can figure something out, then it should be possible for a machine to figure it out. It just takes a human brain with the insight and determination to program that machine with the right rules.
The itch of asm.js
I think the seed was planted when I read Vyacheslav Egorov’s thoughts on asm.js. Something had rubbed me the wrong way about asm.js1 for a while but I couldn’t quite put my finger on it. If I had to pick an excerpt from Egorov’s post that best sums it up for me, I suppose it would be this:
This might sound weird and hyperbolic, but for me pattern matching a statically typed subset
I feel a related itch whenever the topic of software performance...
I used to be a bit of a perfectionist. I suppose I still am in many respects1. But an interesting trend I’ve noticed about myself is that the more expertise I develop in an area, the less of a perfectionist I become.
I think this is a necessary adaptation. When you’re new to a field, you tend not to notice things that are wrong. You don’t even know what “wrong” is, a lot of the time. But as you develop a clearer, deeper understanding of a subject, your ability to see flaws is sharpened. Gradually, everything seems wrong for one reason or another.
In this predicament—having a heightened perception of flaws—a perfectionist has two choices: try to fix them, or look past them. To fix them is sort of like taking the high road, in my mind; and it can be a noble choice. Often, the only ones who can fix something are expert perfectionists, with the knowledge to understand the job and the determination to actually do it.
Personally, I often choose the low road. And I believe that’s the right...
Here’s a mistake people often make: thinking that the absence of any obvious disproof is the same thing as proof.
I took a class in college called Gender and Language. It was sort of a sociology-meets-linguistics course. One of the first points our professor made was a theory about the concept of feminism and why it is, compared to what you might expect, a relatively controversial issue. (I think most of us have met people with a negative reaction to the word “feminist”; or anyway, I certainly have.)
The professor asserted that this perception issue could be explained by the word feminist itself: “All other -ist and -ism words are negative in their connotations,” she told us. “Racist, sexist, anarchist, fascism, communism, nihilism, antisemitism”—and she went on for a bit. Then she briefly challenged us to think of any exceptions; and when none sprang to anyone’s mind right away, we moved on.
Of course, later that day some very obvious exceptions starting popping into my head: idealist