What to do, what to do, around this larger topic i’ve been banging against recently: the extraordinary thinness of culture in geekery. I should say at the outset, I don’t have the answer. I don’t think there maybe even is a "the answer". And I don’t have an answer. I think there are several possible ones, but nothing in my mind at this time feels complete or well-worked out. Still, fools rush in . . . So I would at […]
Thick And Thin Culture See Full Post
I wanna muse about roughly 17 things. But i’m gonna try to relate them to a single message. The additional challenge, some of u may be in a place where this message will sound like an attack. Please please believe it is not meant to be that. The message: you gotta get past this impostor syndrome bullshit. It is a nasty trick that you and geek culture are pulling, together, on yourself. Far from being "honest" and "healthy", it is
Getting Past Impostor Syndrome See Full Post
My five TDD premises stuff has been well-received over the months since I put it out, but one of them seems still very underplayed, even by many died-in-the-wool TDD’ers: the correlation premise. The correlation premise says that the internal quality of our code correlates directly with our productivity. When the internal quality goes up, productivity goes up. When it goes down, productivity goes down. All of the premises were formulated in part to undercut dangerous misunderstandings about what TDD is
The Correlation Premise: Redux See Full Post
TDD Pro-Tip: Prevent complex test data from spiraling out of control by going to builder & custom comparator early on. The push-to-small, coupled with SOLID, coupled with things like third normal form, all lead us to a place of wanting to compose domain objects into potentially very rich dependency graphs. A card in a address-tracking subsystem sounds at first blush like a class with about 5 simple strings in it, and we certainly start there when we first approach it.
TDD Pro-Tip: Start Builders & Partial Comparators Early See Full Post
I’ve mentioned "acculturation" a couple of times lately. Let’s dig in a little deeper on that. In our trade, we make much of "education", training and learning and skills inventories and such-like. I say we make much of it, well. That’s an overstatement, of course. Companies talk about it a great deal. But i’m often struck by fabulously wealthy companies who are utterly dependent on and desperately needful of geek skills and won’t pay a dime to improve them. But
Acculturation: A Little Deeper See Full Post
TDD Pro-Tip: "No, smaller." In TDD, almost without exception, we want everything: a test, a method, a class, a step, a file, really, almost everything, to be as small as it can be and still add value to what we’re doing. This is the most common gaping hole in the practice of the noob, and it’s a constant obsession for the olb. But it’s not just an old-timer’s tic, like the way my lips purse when someone uses the word
TDD Pro-Tip: ‘No, Smaller. See Full Post
So, I’m out there slinging advice about how to change the world of being a professional programmer. Maybe y’all need to hear some things about that, that might not have occurred to you. I am just some schmoe. I am having a successful life in the world of geekery. There are a host of causes for that, among them my dumb luck, and also among them the way I approach and enact the work. I like to talk about this,
Slinging Advice and Where I Come From With It See Full Post
TDD Pro-Tip: TDD and refactoring are permanently intertwined activities, neither of which can be grasped all at once, so start learning how to write tests at the same time you’re learning how to change code w/o adding bugs to it. Some activities are what I think of as "life games". The better you get at it, the more there is to learn. I call them games, cuz my first two noticed experiences of this were in the games of pool
TDD Pro-Tip: TDD & Refactoring Are Intertwined Life-Game See Full Post
TDD Pro-Tip: remember who works for who, and shape your tools to your hand, not your hand to your tools. (Btw, these tips are in no particular order. If you want to know the truth, i’m musing them as I do them. People always know more than they can say, and i’m no exception, but i’m digging at what I do over and over, and sharing it.) One difference I see over and over between noobs and olbs is the
TDD Pro-Tip: They Work For You, Not You For Them See Full Post
TDD pro-tip: demeter chains are anti-microtestable. What is a demeter chain? It’s code where we talk to a collaborator’s collaborator. U can look up the origins of the name in your copious free time, but in regular code, it looks like this: x = a.b.c.d.e.f; each one of those dots is a link in a demeter chain out of whatever the object is that contains that assignment. A is our direct collaborator. We might have been passed her, or given
TDD Pro-Tip: Suspect Demeter Chains See Full Post
