Havoc's Blog

this blog contains blog posts

It’s not new

If you’ve ever written a technical article, or announced some software you created, chances are someone commented “this isn’t new, it’s just like _____.”

Commenters of the world, slow down. Think about why you would say that. Readers, ask why you would think it, even if you don’t comment.

Do you mean:

  • I have already heard of this, and the article was written only for me, so you wasted your time.”
  • This is not suitable for publication in an academic journal.”
  • This could not be patented due to prior art.”
  • There was another article about this once, so we need never mention it again.”
  • I don’t know why you wrote this software, the only reason to write software is to demo a novel idea.”

I guess all of those are pretty silly.

So here is my theory. There’s an old, in no way new, cliché question: “Do you want to be right, or do you want to be effective?”

Most of us software people, at some point, had our self-esteem tied up in the idea of being “smart.” (Try to get over it.)

When we don’t watch ourselves, we would rather be right than effective. And we would rather think about a shiny new idea than learn, practice, refine, and teach a tried-and-true idea.

There are lots of old, endlessly-repeated ideas out there which you are not applying. I’m sure you can find some thousand-year-old ones in the world’s religious and philosophical heritage, unless you have your shit together a lot more than I do. And I’m sure you can find some 5– and 30– and 50-year-old ones related to software, which you should be using, and are not. I know I could.

So when someone writes an article about one of those ideas, or brings together some well-known ideas in a new piece of software, it is not because OH MY GOD I JUST THOUGHT OF THIS. Effective people do not ignore old ideas, nor do they consider “knowing” an idea to be the purpose of ideas. Ideas are for applying, not for cataloging.

Commenters, I’d ask you to work harder. Link to related articles and software; compare and contrast; discuss how you’ve used the idea; add to the discussion.

Here’s the thing: if you click on something on the Internet, and it’s not news to you and you learned nothing, the rest of us don’t need to be told that. We don’t plan to launch an initiative to remove all information you already know from the net. So close the browser tab, and move on.

Thanks for listening to this rant, and I welcome your pointers to prior art.

P.S. I drafted this post some time ago, but was just reminded to post it by a comment on an article about racial (re)segregation. Someone said “this is not new” and cited a previous academic research paper! The comment seems to be gone now (perhaps they came to their senses).

Fedora 20 Beta on Thinkpad T440s Report

Before buying a T440s I kept asking people on Twitter to tell me how it works with Linux, so I figure I should write down the answer.

Note: this is a beta distribution on a brand-new laptop model.

Punchline: Lenovo’s new clickpad is worse than the old physical buttons for me with the trackpoint, but I find it usable. YMMV. If you’re a touchpad user then the clickpad is probably an upgrade from older Thinkpads. The rest of the laptop is mostly solid, but has a couple of bugs, not suprising for brand-new hardware and a Fedora beta. I like the hardware a lot, other than wanting my trackpoint buttons back.

Details:

Clickpad

  • The clickpad is not configured to have middle/right click out of the box, fortunately the installer only needs left click. Bug report
  • To configure the middle/right button areas with synclient you need to use undocumented options. Bug report
  • Disabling touchpad in the BIOS seems to be useless (also turns off clicking so trackpoint has no buttons).
  • I also set PalmDetect, HorizHysteresis, VertHysteresis to prevent accidental mouse motion.
  • With the trackpoint, the issue is that you will occasionally click the wrong mouse button.
  • It may be my imagination, but I think the line between the soft buttons may move depending on whether you last touched the pad on the right or left side of the line, or something. I am mostly used to it now but I think it could be a showstopper for people who are picky. It makes it very hard to configure the soft buttons to match the physical affordances on the touchpad. Whatever is going on, there could be something the synaptics driver could do to reduce clicking on the wrong button, because I can’t seem to configure the soft buttons to always be where I expect them to be. (Update: maybe the confusing thing when trying to experimentally configure the button areas is that it tries to ignore motion once the click begins so looks at where your finger first touched down? But this would also make it hard to feel around for the middle button bumps and then click. Anyway, with a ruler, the middle button affordance is from 40% to 60% on the physical touchpad, so I’m going to try Option "SoftButtonAreas" "60% 0 0 0 40% 60% 0 0".)
  • I want a mode where the touchpad has clickpad-clicking and two-finger scroll (or other gestures) but NO pointer motion and NO tap to click. Synaptics doesn’t seem to have a way to have scrolling without pointer motion.
  • At one point my touchpad got into a mode where it had one-finger scrolling and no pointer motion, but it went away on reboot and I don’t know how to reproduce it.
  • Despite the issues it’s still better than having to use a touchpad. Trackpoint forever!

Network

  • I ordered with the Intel wifi card (strongly recommended for Linux) and it works great. I installed over wifi in fact.
  • The ethernet card picks 10 mb/s instead of 1000 on my network. Since my wifi is fast this isn’t bothering me much but if I needed ethernet it would be pretty bad. Bug report
  • Not sure if it’s the card or something more general, but wired autoconnect was disabled by default. Bug report

Docking

  • All screens blank when you dock with a monitor connected to the dock. This would be a showstopper if I needed to use an external monitor. Bug report (anyone know which module the logic to adjust xrandr on monitor plug/unplug lives in?)
  • Dock ethernet works the same as non-dock ethernet (i.e. broken, but in the same way).
  • Dock power seems to work fine.

Physical

  • Nice size and weight. Power brick is smaller than pre-Haswell Thinkpads too.
  • Screen is pretty (I got the 1080p one). Pixels are small, text is tiny without tweaking.
  • I think the new keyboard is fine or even better than the old Thinkpad style. Probably less prone to getting gooped up too.
  • Home/End/PgUp/PgDn moved again but I think they’ve moved every time I bought a new Thinkpad so I’m used to it.
  • I don’t care about lack of dedicated volume buttons and lack of status LEDs but some people don’t like that in the new Thinkpads.
  • Battery life (with the internal 3-cell and a removable 3-cell) seems to be 4–6 hours depending on what you are doing, and how many powertop tunables you toggle. I haven’t rigorously tested.
  • I opened the laptop to swap out the hard drive. This was pretty difficult (it requires a spudger or thin blade, I used a plastic scraper). Maybe the price of a thin laptop that feels solid.
  • The factory drive had a protective sheet wrapped around it to separate it from the case, so a little worried my replacement drive might short out against the case or something. But seems to be working so far.

Other

  • Minor cosmetic artifact in gnome-shell, not something you’ll care about. Bug report
  • It comes with a 16G SSD designed to be a cache for the main HD. This shows up in Linux but I’m not using it. I was thinking of using it as a boot disk but just didn’t bother yet. Linux only has experimental support for the caching trick. I might rather put a larger SSD in the slot and use it as a non-cache, but SSDs in this form factor aren’t widely available yet.
  • Default fonts are too small on the high-DPI screen and GNOME has the configuration for this only in tweak tool. OS X puts this config in their tweak tool too, but my guess is that they have better defaults on all of their hardware.
  • Adjusting fonts upward doesn’t affect web sites. Firefox has no “just automatically zoom all pages by N steps” setting that I can figure out. Text is too small on most sites.
  • Powertop doesn’t have the obvious “make all these tunings persistent” button (or more importantly, the tunables are not properly tuned by default).
  • Switching wifi networks involves 3 more clicks than it used to. I have an upstairs and a downstairs one so I do this a lot.
  • GNOME 3.10 feels extremely solid and smooth. Fedora install was seamless with no troubles. Overall it was an easy upgrade and I was back to productivity after a day; most of the time was spent copying over my data.

Thanks to all the developers involved! Great hardware and software upgrade from my T510/F17, overall.

Don’t screw up your next presentation

Have you ever screwed up a talk or high-stakes presentation? You thought it would be fine, had a plan, did well in practice runs, but under pressure you fell apart and fell flat. In short: you choked.

There’s almost a binary switch: sometimes you can tell a few minutes into an hour-long talk whether it’s going to be confident or lackluster. Graphing the quality of many talks from the same person, I bet it would distribute like this:

Rather than a normal distribution:

Performance has two parts:

  1. Your on-a-good-day peak ability. Most public speaking advice intends to help you with this.
  2. Your consistency. Avoid choking!

Even if it’s tough to boost your peak performance, limiting your chokes can bring the average up quite a bit. It might be the quickest way to boost your average performance.

It turns out there’s some research on the subject and some tactics to avoid collapsing under pressure. I should have read about it years ago, since I choke all the time.

What makes us choke?

According to Wikipedia, there are two popular theories:

  • Explicit monitoring or “thinking too hard.”
  • Distraction or split attention.

To understand “explicit monitoring” intuitively, try to walk by carefully and consciously monitoring the process to be sure you get it right: now I’m picking up my left foot while balancing on my right, now I’m moving my leg forward flexing the knee just so, etc. Imagine learning to walk by reading a book. This is the difference between knowing “what” (words you can articulate) and knowing “how” (being able to do it without thinking).

The “distraction” theory is just what it sounds like: worry and anxiety give you something to think about besides the task at hand, compromising your working memory with clutter and lowering performance.

(If Wikipedia doesn’t do it for you, here’s a pretty readable paper that happens to have a summary of other research.)

Strategies to be more consistent

Here are some approaches. By writing them down, I’m hoping to remember them in the future; I hope some of them work for you as well.

  1. Practice more. Almost too obvious, but here’s the key: don’t stop when you can do the task well in practice. You have to go past that and make it automatic, because your goal under pressure is to be on autopilot.
  2. Focus on making your first words confident. I learned this one in a public speaking class run by Second City. Don’t think about the whole talk you’re about to give, just think about the tone of the first sentence or two, starting with a confident “Hi, my name is … ”
  3. Banish tips, advice, and content from your mind. When practicing, maybe you were coached or self-coached with things to remember, advice about what to say, mannerisms, etc. Never repeat this stuff in your mind just before a talk. Write it down in slide notes, or have it memorized cold, but don’t stand up on stage repeating it in your mind. You know it or you don’t at that point. Use advice when practicing but not in live performance.
  4. If something throws you off, press reset before you start talking. It’s easy to get flustered by travel troubles or a flaky projector or an unexpected audience size. Techniques such as meditation or going for a walk might help. Or try tactical breathing (it even has an iPhone app from the federal government).
  5. If you start off badly, take a pause. You may notice mid-performance that you’re choking. Consider inventing some excuse, perhaps in between slides: maybe have a drink of water. Take a deep breath. People may find the pause a little long, but it beats them suffering through a flat talk.
  6. Try to avoid and forget praise. Believing you’re “good at” something can be poison. In that Second City course I mentioned, we had to give two practice speeches. They loved my first one and said so; not coincidentally, my second one was a horrible choke in an attempt to live up to the first.
  7. Pep rally. Psych yourself up in whatever way might work for you: music, mantra, remembering “why you do it.“
  8. The basics. Get enough sleep. Arrive early. Drink water, and caffeine if you’re accustomed. Once I gave a talk by flying to Europe arriving in the morning, talking almost immediately, then going straight back to the airport. It did not go well.

The common factor is that it’s about emotional state, not details. Once you’re about to start speaking or on your way to that big meeting, you want to be focused on feeling confident, rested, and calm; your brain shouldn’t be spending cycles on what you’re going to say or how you’ll say it, only on feeling good.

If you have your own tips, please share in the comments!

What Matters In Software Development

Lots of traffic on Twitter about Steve Yegge’s post defining a “software ideology” spectrum. Myles Recny made a survey to help you place yourself along said spectrum.

Thinking about it over the weekend, I can’t identify with this framing of software development. Those survey questions don’t seem to cover what I think about most in my own software work; in fact I’d be a little worried if I saw colleagues focused on some of these.

Here’s what I do think about, that could be called an ideology.

Ideological View 1: Risk = Getting Worse On Average

Whether we’re talking about dieting, finance, or software, flows matter more than stocks.

The risk I worry about is: are you adding bugs faster than you’re fixing them? Is your technical debt going up? Is this code getting worse, on average?

If the average direction is “worse” then sooner or later your code will be an incomprehensible, hopeless disaster that nobody will want to touch. The risk is descent into unmaintainable chaos where everyone involved hates their life and the software stops improving. I’ve been there on the death march.

Bugs vs. Features: Contextual Question!

In Steve’s post, he says conservatives are focused on safety (bugs in production) while liberals are focused on features. I don’t have an ideological view on “bugs in production risk”; it’s contextual.

For example: Red Hat maintains both Fedora and Enterprise Linux, two branches of the same software project with mostly the same team but with distinct “bugs in production” risk profiles and distinct processes to match. Red Hat uses the same code and the same people to support different tradeoffs in different contexts. Maybe they’re a post-partisan company?

If I were working on software for the Mars rover, I’d strenuously object to continuous deployment. (Maybe we should test that software update before we push it to Mars?) If I were working on I Can Has Cheezburger, bugs in production wouldn’t bother me much, so I’d be happy to keep the process lightweight.

But in both cases I don’t want to see the code getting worse on average, because in both cases I’d want to keep that code alive over a period of years. That’s the ideology that stays constant.

A project that’s getting worse on average will achieve neither safety nor features. A healthy project might have both (though not in the same release stream).

How to Avoid Getting Worse

To avoid risk of steadily getting worse, a couple issues come up every time.

Ideological View 2: Clarity and Simplicity Are Good

Can the team understand it?

This is relative to the team. If your team doesn’t know language XYZ you can’t write code in that language. If your API is intended for mainstream, general programmers, it can’t be full of niche jargon. If your team doesn’t speak German you can’t write your comments in German. Etc.

Software developers learn to make judgment calls about complexity and over– vs. under-engineering. These calls are countless, contextual, and always about tradeoffs. Experience matters.

A definition of “competent software developer” surely includes:

  • they worry about complexity and can make judgments about when it’s worth it
  • they can write both prose and code such that the rest of the team understands it

Not all teams have the same complexity capacity, but they all have some limit, and good ones use it wisely.

Ideological View 3: Process: Have One

I’ve seen many different methodologies and processes work. They optimize for different team skills, or different levels of “bugs in production” risk. My belief is that you need some method to your madness; something other than free-for-all. Examples:

  • Good unit test coverage with mandatory coverage for new code.
  • OR hardass code review. (Hardass = reviewer spends a lot of time and most patches get heavily revised at least once. Most reviews will not be “looks good to me.”)
  • OR just one developer on a codebase small enough to keep in one head.
  • OR Joel’s approach.

You don’t need all of those, but you need at least one thing like that. There has to be some daily habit or structural setup that fights entropy, no matter how smart the individual team members are.

Companies may have rule-based or trust-based cultures, and pick different processes. Lots of different approaches can work.

Summary

Ideological lines in the sand framing my thinking about software development:

  • Risk = the project becomes intractable.
  • Prerequisite to avoid this risk: you have to be understandable and understood.
  • Process to avoid this risk: have one and stick to it.

If you can write clear, maintainable code, and keep it that way, using your OS, text editor, dynamic language, static language, XML-configured framework, agile process, or whatever, then I’m open to your approach.

If you’re creating complexity that doesn’t pay its way, not making any sense to the rest of the team, don’t have a working process, etc. then I’m against it.

How many bugs in production are OK,” “static vs. dynamic languages,” “do we need a spec for this,” “do we need a schema here”, “what do I name this function”: these are pragmatic, context-dependent issues. I like to consider them case-by-case.

Postscript: Me me me

A lot of these example “liberal/conservative” statements feel ego-driven. I’d look bad if we shipped a bug, I’m smart and can learn stuff, I never write slow code, I always write small code, blah blah.

It’s not about you.

When you agree or disagree with “programmers are only newbies for a little while” — are you thinking of software creation as an IQ test for developers? The goal is not to “dumb down” the code or to prove that for you, it need not be.

Let me suggest a better framing: is this complexity worth it (in the context of our customers and our team). If we’re trying to maximize how useful our software can be given a certain level of complexity our team can cope with, should we use our brain cycles in this corner of the code or some other corner?

When you agree or disagree with “software should aim to be bug free before it launches” — do you have the same opinion about both the Mars lander and icanhascheezburger? If you do, you might need to refocus on the outside world our software’s supposed to be serving.

Better framing: it has to work.

You get the point I guess…

This article is translated to Serbo-Croatian by Jovana Milutinovich from Webhostinggeeks.com.

Developers: request for complaints

I’m looking for a new personal weekend project that would be useful to others. Maybe there’s a useful book or useful piece of software I could create for fellow developers, tech leads, project managers, etc. Doesn’t have to be anything related to any of my current or past work (Linux, C, GTK+, Scala, etc.), but it could be.

Here’s how you can help: complain in the comments (or in private email or on Twitter), about an aggravation, anxiety, ignorance, or unsolved problem that you encounter as part of your work. Where are you wasting time or being kept up nights?

+1″ comments are awesome because if something annoys a bunch of people that makes it more worthwhile to try to solve.

This is once-in-a-lifetime: I’m going to appreciate hearing you complain, and also appreciate “+1″ comments! Nobody else is going to do that for you.

I’m not asking for project ideas directly (though if you have them great), I’m just looking for crap you put up with that you wish someone would do something about, problems you had that you couldn’t find a solution to, topics you wanted to learn about that appeared to be undocumented, whatever.

No need to be original; obvious problems are great, as long as it’s still an unsolved problem for you, I don’t care whether it’s obvious, or how many people have already tried to solve it.

No need to have a solution, some of the most important problems are hard to solve, I’m just wondering what’s at the top of your list of sure wish someone would figure out this problem.

Some examples to get you started, if these resonate you could “+1″, but just as good is to come up with more:

  • Wish you knew more about <some topic>? Tell me which and maybe I could research it for everyone and report back.
  • Anything about your bug tracking, sprint planning, etc. that is tedious, ineffective, or broken?
  • Baffled by how to handle trademarks, copyrights, and patents in your projects?
  • Unhappy with how your team communicates?
  • Are there any software tools you’ve looked for only to say “all the choices suck”?
  • Wish you could write your own window manager, if only you had esoteric and rapidly-obsoleting X11 skills? (j/k … right?)

I don’t promise to solve everyone’s problems, but maybe I can solve one real-world actual problem and that would be cool.

Who knows — if we gather enough data someone other than me might run with some of these problems too. Or your fellow commenters might point you to a good existing solution. So let us know what you’re having trouble with.

Thanks!

New blog hosting

I’m trying out WPEngine instead of self-managed EC2 since my self-managed uptime stats were pretty bad.

Let me know if anything about the blog is more broken than it was before.

Desktop Task Switching Could Be Improved

In honor of GUADEC 2012, a post about desktop UI. (On Linux, though I think some of these points could apply to Windows and OS X.)

When I’m working, I have to stop and think when I flip between two tabs or windows. If I don’t stop and think, I flip to the wrong destination a high percentage of the time. I see this clunkiness every minute or two.

For me to do the most common action (flip between documents/terminals/websites) I may need to use my workspace switch hotkey (Alt+number), app switch (Alt+`), window switch (Alt+Tab), tab switch (Alt+PgUp, Alt+PgDn, C-x-b), or possibly a sequence of these (like change workspace then change window or change window then change tab).

I believe it could be reduced to ONE key which always works.

The key means “back to what I was doing last” and it works whether you were last on a tab, a window, or another workspace. There’s a big drop-off in goodness between:

  • one key that always works
  • two keys to choose from

Once you have two, you have the potential to get it wrong and you have to slow down to think.

Adding more than two (such as the current half-dozen, including sequences) makes it worse. But the big cliff is from one to two.

User model vs. implementation model

Can’t speak for others, but I may have two layers of hierarchy in my head:

  • A project: some real-world task like “file expense report” or “write blog post” or “develop feature xyz”
  • A screen: a window/tab/buffer within the project, representing some document I need to refer to or document I’m creating

The most common action for me is to switch windows/tabs/buffers within a project, for example between the document I’m copying from and the one I’m pasting to, or the docs I’m referring to and the code I’m writing, or whatever it is.

The second most common action for me is to move among projects or start a new project.

Desktop environments give me all sorts of hierarchy unrelated to the model in my head:

  • Workspace
  • Application
  • Window
  • Tab (including idiosyncratic “tabs” like Emacs buffers)
  • Monitor (multihead)

None of these correspond to “projects” or “screens.” You can kind of build a “projects” concept from these building blocks, but I’m not sure the desktop is helping me do so. There’s no way to get a unified view of “screens.”

I don’t know what model other people have in their head, but I doubt it’s as complex as the one the desktop implements.

Not a new problem

I’m using GNOME 3 on Fedora 17 today, but this is a long-standing issue. Back when I was working on Metacity for GNOME 2, we tried to get somewhere on this, but we accepted the existing setup as a constraint (apps, windows, workspaces, etc.) and therefore failed. At litl we spent a long time wrestling with the answer and found something pretty good though perhaps not directly applicable to a regular desktop. I wish I had a good video or link to show for litl’s solution (essentially a zoomable grid of maximized windows, but lots of details matter).

iPhone has simplified things here as well. They combine windows and applications into one. But part of the simplification on iPhone is that it’s difficult to do things that involve more than one “screen” at a time. On a desktop, it wouldn’t be OK to make that difficult.

In GNOME 3, I also use the Windows key to open the overview and pick a window by thumbnail. Some issues with this:

  • It does not include tabs, only windows.
  • In practice, I have to scan all the thumbnails every time to find the one I want.

These were addressed in the litl design:

  • Tabs and windows were the same thing.
  • Windows remained in a stable, predictable location in the overview.
  • The overview was spatially related to the window, that is you were actually zooming in and out, which meant during the animation you got an indication of where you were.
  • I believe you could even click on a window before the zoom in/out animation was complete, though I could be wrong. In any case you could be moving toward it while it was coming onto the screen.

As a result, the litl design was much faster for task switching via overview key plus mouse. If you were repeatedly flipping between two tasks, you could memorize their location in space and find them quickly based on that. If other windows were opened and closed, the remaining ones might slide over, but they’d never reshuffle entirely.

I think GNOME tries to “shrink the windows in their current location” rather than “zoom out”, so it’s trying to have a spatial relationship. A problem is that I have everything maximized (or halfscreen-maximized). “Shrink to current location” ends up as “appears random” when windows don’t have any meaningful relationships on the x/y axes (they’re just in a z-axis stack). (Direction for thought: is there some way maximized windows could be presented as adjacent rather than stacked?)

Overall I vastly prefer Fedora 17 to my previous GNOME 2 setup and I think it’s a step on the path to cleaning this up for good. In the short term, a couple things seem to make the problem worse:

  • The “application” layer of hierarchy (Alt+Tab vs. Alt+`) adds one more way to switch “screens,” though for me this just made an existing problem slightly worse (the bulk of the problem is longstanding and we were already far from one key).
  • The window list on the panel had a fixed order and was always onscreen, so it was faster than the thumbnail overview. I believe the thumbnail overview approach could be fixed; on the litl, for me zoom-out-to-thumbnails was as fast as the window list. The old window list was an ugly kluge (it creates an abstraction/indirection where you have to match up two objects, a button and a window — direct manipulation would be so much better). But its fixed spatial layout made it fast.

GNOME 3 opens the door to improving matters; GNOME 2’s technology (e.g. without animation and compositing) made it hard to implement ideas that might help. GNOME 3 directions like encouraging maximized apps, automatic workspace management, the overview button, etc. may be on the path to the solution.

Can it be improved?

I’ll limit this post to framing the problem and hinting at a couple of directions. I don’t know the right design answer. I’m definitely going to omit speculation on how to implement (for example, getting tabs into the rotation would be possible, but require some implementation heroics).

I know everything is the way it is now for good historical reasons, valid technical and practical constraints, and so on. But I bet there’s a way to get past those with enough effort.

ACA constitutionality doesn’t hinge on what you call it

TL;DR I got it right, you may now send me your offers for lucrative legal consulting work. Note: I am not a lawyer.

I’ve had a little series of posts, first and second, arguing that the tax code already punishes you for failure to purchase health insurance and health care. (Because any tax credit can be framed as an equivalent tax increase + tax penalty.) Thus, the individual mandate should be constitutional in the same way that existing credits are, because practically and economically speaking, it’s the same thing as many credits already in the tax code, including health insurance and health care credits.

I’ve only read the syllabus of the Supreme Court decision so far, but it looks like John Roberts bought the argument that something can’t be unconstitutional just because it’s named the wrong thing:

4. CHIEF JUSTICE ROBERTS delivered the opinion of the Court with
respect to Part III–C, concluding that the individual mandate may be
upheld as within Congress’s power under the Taxing Clause. Pp. 33–
44.
(a) The Affordable Care Act describes the “[s]hared responsibility
payment” as a “penalty,” not a “tax.” That label is fatal to the appli–
cation of the Anti-Injunction Act. It does not, however, control
whether an exaction is within Congress’s power to tax. In answering
that constitutional question, this Court follows a functional approach,
“[d]isregarding the designation of the exaction, and viewing its sub–
stance and application.” United States v. Constantine, 296 U. S. 287,
294. Pp. 33–35.
(b) Such an analysis suggests that the shared responsibility
payment may for constitutional purposes be considered a tax. The
payment is not so high that there is really no choice but to buy health
insurance; the payment is not limited to willful violations, as penal–
ties for unlawful acts often are; and the payment is collected solely by
the IRS through the normal means of taxation. Cf. Bailey v. Drexel
Furniture Co., 259 U. S. 20, 36–37. None of this is to say that pay–
ment is not intended to induce the purchase of health insurance. But
the mandate need not be read to declare that failing to do so is un–
lawful. Neither the Affordable Care Act nor any other law attaches
negative legal consequences to not buying health insurance, beyond
requiring a payment to the IRS. And Congress’s choice of language—
stating that individuals “shall” obtain insurance or pay a “penalty”—
does not require reading §5000A as punishing unlawful conduct. It
may also be read as imposing a tax on those who go without insur–
ance. See New York v. United States, 505 U. S. 144, 169–174.
Pp. 35–40.
(c) Even if the mandate may reasonably be characterized as a
tax, it must still comply with the Direct Tax Clause, which provides:
“No Capitation, or other direct, Tax shall be laid, unless in Proportion
to the Census or Enumeration herein before directed to be taken.”
Art. I, §9, cl. 4. A tax on going without health insurance is not like a
capitation or other direct tax under this Court’s precedents. It there–
fore need not be apportioned so that each State pays in proportion to
its population. Pp. 40–41.

On a more serious note, this law will have huge positive consequences for my family, and I’m grateful that it held up in court.
I was going to be particularly upset to suffer giant practical problems in my own life just because someone failed to open their search-and-replace function in a word processor and change “penalty” to “tax.” I’m very happy we weren’t screwed on that technicality.

While I haven’t read the whole decision yet, it looks like those looking for limitations on federal power will be happy with the discussion of commerce powers and the precedents established in that area.

The best answer requires some aggravation

Once you think you have a good answer to an important problem, it’s time to drive everyone crazy looking for an even better answer.

Here’s a scenario I’ve been through more times than I can count:

  • I thought I had a pretty good approach, or didn’t think anything better was possible, and wasn’t looking to spend more time on the problem.
  • Someone had the passion to keep pushing, and we either stayed in the room or kept the email thread going beyond a “reasonable” amount of effort.
  • We came up with a much better approach, often reframing the problem to eliminate the tradeoff we were arguing about at first.

Steve Jobs was legendarily cruel about pushing for more. But in my experience good results come from more mundane aggravation; there’s no need to make people cry, but there probably is a need to make them annoyed. Annoyed about spending three extra hours in the meeting room, annoyed about the length of the email thread, annoyed about compromising their artistic vision… if the human mind thinks it already has an answer, it will fight hard not to look for a new answer.

That might be the key: people have to be in so much pain from the long meeting or thread or harsh debate or Jobsian tongue-lashing that they’re willing to explore new ideas and even commit to one.

It shows just how much we hate to change our mind. I often need to be well past dinnertime or half a novel into an email thread before my brain gives up: “I’ll set aside my answer and look for a new one, because that’s the fastest way out of here.”

The feeling that you know the answer already is a misleading feeling, not a fact.

Some people use brainstorming rules, like the improv-inspired “yes, and…” rule, trying to separate generative thinking from critical thinking. First find and explore lots of alternatives, then separately critique them and select one. Avoid sticking on an answer prematurely (before there’s been enough effort generating options). Taking someone else’s idea and saying “I like this part, what about this twist…” can be great mental exercise.

To know you’ve truly found the best decision possible, your team might need to get fed up twice:

  • Brainstorm: stay in the room finding more ideas, long after everyone thinks they’re tapped out.
  • Decide: stay in the room debating, refining, and arguing until everyone thinks a decision should have been made hours ago.

A feeling of harmony or efficiency probably means you’re making a boring, routine decision. Which is fine, for routine stuff. But if you have an important decision to make, work on it until the whole team wants to kill each other. Grinding out a great decision will feel emotional, difficult, and time-consuming.

Binding an implicit to a Scala instance

In several real-world cases I’ve had a pair of types like this:

An implicit often leaves a policy decision undecided. At some layer of your code, though, you want to make the decision and stick to it.

Passing around a tuple with an object and the implicit needed to invoke its methods can be awkward. If you want to work with two such tuples in the same scope, you can’t import their associated implicits, so it’s verbose too.

It would be nice to have bind[A,I](a: A, asImplicit: I), where bind(cache, cacheContext) would return the equivalent of BoundCache.

I guess this could be done with macro types someday, but probably not with the macro support in Scala 2.10.

If implemented in the language itself, it’s possible BoundCache wouldn’t need any Java-visible methods (the delegations to Cache could be generated inline).

However, one use of “bound” classes could be to adapt Scala APIs to Java. In Java you could bind one time, instead of explicitly passing implicit parameters all over the place.

Has anyone else run into this?