Understanding Tax Brackets Takes an Engineer

I've talked to dozens of people who have a dramatic misunderstanding of tax brackets (or tax rate schedules). In fact, I think I've run into more people who misunderstand how taxes work than who understand. So, I thought I'd demystify one small part of the American income tax system — brackets.

Many people believe that shifting from one tax bracket to another yields a major leap in income tax. This is incorrect. When you move from the 15% tax bracket to the 25% bracket for example, you're not suddenly paying an additional 10% in taxes. That is to say that if you make $33,950.00 per year (the highest salary for the 15% bracket) and you get a 1 cent raise bumping you up to the next tax bracket, that your change in income tax will actually be zero dollars.

Here's how that works. If you're in the 15% bracket, you pay 15% on income above $8,350.00 and you add $835 to that. The next bracket up is for people who earn more than $33,950.00 and less than $82,250.00. They pay 25% on income above $33,950.00 plus $4,675.00. Now, here's an interesting observation. If you take 15% of $33,950.00 - $8,350.00 (the maximum for the 15% bracket) and add $850, you get $4,675.00. That means that the maximum for the 15% bracket is the same as the minimum for the 25% bracket.

Thus, there's not a major leap between brackets. So, what are brackets for? Well, basically, the tax bracket just defines the rate of change between the minimum and the maximum incomes in the bracket. If you remember taking algebra back in the old days, you're just talking about slope. Basically, your tax bracket defines the slope of the line on which your tax is determined from your income.

Consider the slope-intercept form for a line: y = mx + b where b is the y intercept and m is the slope. If you look at the graph at the top of this blog (created with a free iPhone app called grafunc by Fabio Policarp), you'll see a blue and an orange line. The blue line represents the 15% bracket using the equation y = .15 (x - 8350) + 835 and the orange line represents the 25% bracket with the equation y = .25 (x - 33950) + 4675. Where those two lines intersect is where you switch brackets.

That's about all there is to understanding tax brackets. There's much more to understand about taxes, but that's another blog post altogether.

Programming is a Gas

Programming is a gas. I don't mean programming is entertaining and exciting (even though sometimes it really is); I mean more along the lines of the physical state of matter. Programming is a gas. You see, a gas having perfect mobility and infinite expansion will take the size and shape of the container you put it in.

Parkinson's Law states that "work expands so as to fill the time available for its completion." I'm taking this one step forward and saying that "software development expands so as to take the size and shape of the constraints placed upon it."

I've worked with tens (if not hundreds) of software engineers and I can tell you one thing with certainty: ceteris paribus, the more the engineer charges for services, the better the result. Now, obviously, some engineers misrepresent their skill level intentionally or unintentionally, but . . . on average . . .

So, if this is the case, you can put several of these programmers together and derive that the more you pay a software consultancy, the better the result as well. I know to some, this probably just sounds obtuse. You might be saying to yourself, "well, some companies just have higher profit margins than others." 'tis true; some programmers have higher profit margins.

If you've been at the top of the game for 10 years, you deserve more than someone who just started programming (or someone who has stagnated for 10 years) because you can apply all of your experience to each new project. Similarly, a software consultancy with premium engineers (no matter how old the organization) can earn a higher margin because its engineers produce such valuable results.

Understanding this stipulation (whether you agree or not) is pivotal to the rest of this post, so I'll very briefly summarize what I'm saying: you get what you pay for!

So, why do so many projects turn sour? If you're a software engineer, think of the last 10 projects you worked on. If you're not an engineer, think of the last 10 projects your company had someone else work on. What's the first step of all of these projects? Almost uniformly, it's an RFP and if not an RFP per se, it's some kind of competitive bidding process.

That's where the situation starts going south — before the project even gets kicked off! Have you ever had a project where the vendor wasn't selected almost exclusively based on cost? When was the last time someone said, "whichever vendor comes back with the best feature ideas will get the contract" or "whichever vendor has the lowest turnover rate and the highest employee satisfaction will get the contract?" In fact, in a perfect world, I believe you could select a vendor based on its mission statement and core values (and perhaps a brief summary of its gestalt experience).

Almost every project I've been on has had two constraints . . . money and time. Before a pen ever touches the signature line on the contract, the project is doomed. The shape of the project is defined by money and time, not by desired features.

Thus, when a developer looks at the project, it is going to take the shape of money and time; however, to the customer, the project is expected to be shaped by the desired features. More often than not, the money x time shape fits quite neatly inside the feature shape.

So, what exactly am I proposing? I'm proposing that the team (whether it is internal or external) should be chosen based on values and trustworthiness. A team you can trust is much more valuable than a team which is cheap. Take the team you can trust and then define the shape of your project based on the features you want to see. When you ask the team for an estimate, it's not to compete for the project; rather, the estimate is so that you'll know if you have the budget for the project in the first place.

If you do it this way, you'll get an honest estimate. Many software companies will low-ball estimates because they know that once you're committed to the project, you'll dedicate whatever additional resources are necessary to complete it. Ultimately, it'll end up costing more in the long run because of the way each "phase" will build on the "phase" before it compared to a solution that was well architected from the get-go.

iPhone Bookmarklet Installer Source

A few hours ago, I posted my iPhone Bookmarklet Installer Bookmarklet and several people have asked how it works.

Well, it's pretty basic. The effort is to loop through all the links on the page, identify the bookmarklets, and modify them so that the bookmarklet is appended to the URL somehow. The first time I tried, I used the '?' character making the bookmarklet look like a query string. This proved problematic though as a number of bookmarklets failed to convert cleanly. I didn't really investigate but I'd imagine it has something to do with the '&' character and/or '=' signs.

In any event, it's pretty easy to fix that by using the '#' character instead of ? because then it just looks like an anchor. It also keeps the page from having to reload. So, all you have to do is run the bookmarklet on your iPhone, click the bookmarklet you want to install, save the bookmark and remove everything up to and including the #.

Now, the actual bookmarklet code has been scrubbed a little to give it something of a smaller footprint like this:

(function(){
  var s,i,l=document.links;
  for(i=0;i<l.length;i++)
  {
    if(l[i].href.indexOf('javascript:')!=0)
      continue;

    l[i].href='#'+l[i].href;
  }
})();

But, that's a little hard to read, so here's the pre-scrubbed version. There's also an additional section I added later to make it easier to identify which links have been transformed (i.e., which are identified as bookmarklets). Here's the code:

// anonymous function
(function(){

  // put the link array somewhere
  var links = document.links;

  // loop through all the links
  for (var i = 0; i < links.length; i++)
  {

    // if the link does not start with javascript:
    // it isn't a bookmarklet and we can exit this
    // itteration and continue the loop
    if(links[i].href.indexOf('javascript:') != 0)
      continue;

    // update the href of the link prepending the
    // '#' character to make it look like an anchor
    links[i].href = '#' + links[i].href;

    // add some styling information to identify the
    // modified links
    var style = links[i].style;
    style.backgroundColor = '#eee';
    style.color = '#333';
    style.border = '1px solid #333';
    style.textDecoration = 'none';
    style.padding = '2px';
    style.fontWeight = 'normal';
  }
})();

iPhone Bookmarklet to Install iPhone Bookmarklets

As a software engineer and a web developer, I have really grown to love the bookmarklet. I have a Regex Search Bookmarklet, my favorite javascript shell bookmarklet from Jesse's Bookmarklets, and of course, you've seen my blog post on Tabulate from the clever folks at Inventive Labs. However, installing bookmarklets on the iPhone without help from a computer is a royal PITA.

That's why I wrote the iPhone Bookmarklet Installer.

If you're interested in how it works, you can find details on my iPhone Installer Bookmarklet blog post. But, the short version is that I use Javascript to loop through all of the links on the page and make them look like anchor tags so you can just bookmark them on the iPhone and remove everything before the anchor tag character '#'.

With that out of the way, here's how you use it:

1. Run the bookmarklet on this page by clicking the iPhone Bookmarklet Installer. You should see all of the bookmarklets on this page change styles (They'll look something like this).
2. Click the bookmarklet you wish to install (n.b., the page won't reload).
3. Bookmark the page.
4. Edit the bookmark and remove everything up to and including the # character.
5. Name the bookmarklet appropriately.
6. Save and enjoy.