Patrick McKenzie wrote a post titled “Don’t Call Yourself A Programmer” and argues engineers (let’s call them McEngineers) are hired to generate revenues or reduce costs, not to program, per se. Yossi Kreinin rebutts some of McKenzie’s points points out that he would be skeptical of engineers that applied for a programming position, but did not consider themselves a programmer. So, should a programmer call themselves a programmer (or developer or whatever term is in vogue)?
The distinction is not trivial as “programmers” are responsible for writing readable, testable, code and McEngineers are supposed to maximize profits (by increasing revenues or decreasing costs). A McEngineer can do their job by selling branded cereal if that will maximize profits for the firm. A programmer can only satisfy their job title by churning out code.
McKenzie is obviously worried about the engineers that Paul Graham describes as “techno-weenies who are obsessed with solving interesting technical problems, instead of making users happy“. Yossi probably doesn’t like techno-weenies either, but he doesn’t think we need to throw out the word “programmer” as a professional title.
The non-techno-weenie programmer writes code all day, but is practically minded, and continuously strives to maximize his/her value to the firm by collaborating, writing good software, and always trying to solve business problems without writing any code at all. These programmers are highly technical, but will not go on an intellectual tangent when the expected return on investment is not positive. Programmer’s contributions to the bottom line are difficult to measure, but some have an instinctual sense to allocate time to projects that are expected to add value to the company (via increased revenues or decreased costs) and I think McKenzie and Yossi can agree that these non-techno weenie programmers are most desirable.