Comments on: Some lesser-known truths about programming

By: “Priority Inversion” in Software Engineering Management: Misconceptions of Wasted Time | Software Development News, Events, Thoughts from Auriga

Mon, 13 Apr 2015 21:08:05 +0000

[…] Some Lesser-known Truths About Programming (http://automagical.rationalmind.net/2010/08/17/some-lesser-known-truths-about-programming/) […]

By: Michael Meichtry

Michael Meichtry — Sat, 24 May 2014 10:32:34 +0000

@Parker – You are so correct about the number of lines of code. Although in past times, companies such as IBM sometimes measured programmer productivity (and salaries) in terms of “locs” – lines of code, and “klocs” – lines of code x 1,000, in modern coding environments I don’t see where this is relevant. For example, a simple task may require several hundred lines of code to achieve a given result/output for a program. Conversely, a complex problem may involve merely a dozen lines of code, yet each line of code may involve an extremely complicated mathematical calculation, which is also interconnected with the remaining lines of code which may also perform complicated scientific or logical operations in their own right. These operations must be thought-out thoroughly before the actual coding takes place, since even visualizing the effect of the code may be difficult to grasp.
In other areas, the use of IDEs to generate code may also result in a large amount of code being “generated.” For example, when I “drag and drop” a graphical widget onto a design surface, dozens of lines of “code-behind” will be generated as part of the application that defines that given widget. As a result, after a few hours of “dragging and dropping” widgets into my web-page or other GUI-based application, the underlying code may balloon to thousands of lines-of-code, although I may have never actually typed these instructions into the application. In summary, measuring programmer productivity in terms of “lines of code” seems at best a very rough and unreliable estimate at best. A possibly better metric of productivity would be to look at what type of problems/tasks are to be solved, and try to allocate programmer resources based on the complexity and/or time required to arrive at solutions based on those tasks. For example, a labor-intensive programming task could be divided among several generic programmers, while a task requiring a short yet critical/complex calculation could be assigned to a programmer who could find a coding solution for that type of problem. In this way, coders could be optimized/matched to the tasks needing to be solved. Even if a single programmer were responsible for an entire application, at least breaking problems into smaller tasks (divide-and-conquer) would shine a light on individual tasks and their relative requirements. In contrast, strictly measuring productivity in terms of “lines of code” appears to make little sense, except in the most rudimentary situations.

By: Eugene

Eugene — Tue, 18 Feb 2014 19:42:06 +0000

There are two separate skills: 1) programming skill 2) sales/negotiating skills. It is rare that one person has both. That’s why mediocre developers with great sales skills often take credit for work done by great developers and quickly get promoted. Another reason is that corporate culture assigns greater value to manager or team lead then to actual developer. Both reasons hard to fight, that’s why you need to find a place or person that appreciate actual design/programming skills.

By: Ryan

Ryan — Sun, 19 Jan 2014 14:02:24 +0000

…and the most important less-known truth. Good programmers always have more to learn.

By: AverageProgrammer

AverageProgrammer — Sat, 24 Aug 2013 06:52:40 +0000

There are only are two categories of programmers, real and pretenders. Real programmers don’t get sucked into pissing contests, they write code that they themselves are accountable for, they write documentation most of the time, they publish useful code, they don’t have a library full of useless outdated computer books, they are respected by other real programmers, they have written/contributed to something that matters to more than 10,000 people, they are good at something other than programming. Sorry guys, everyone else is just a pretender fighting with insecurities.

By: CodeExpress

CodeExpress — Thu, 25 Apr 2013 22:33:19 +0000

This article was of great help to me, It made me realize that I am good programmer but my boss is messing it up for me. He has the WISCA ( Why Isn’t Sam Coding Anything) syndrome. He measures progress only based on what he can understand (forms, and more forms). He is old , does not understand OOP at all which is how I do things. I can spend days working on classes come time for progress check if there is no new form then to him I have not been doing anything. This guy is turning me into a bad programmer. Bad managers can turn good programmers into bad programmers. I making steady progress towards becoming one.

By: Most interesting links of October ’12 « The Holy Java

Most interesting links of October ’12 « The Holy Java — Wed, 31 Oct 2012 22:45:59 +0000

[…] David Veksler: Some lesser-known truths about programming – things newcomers into the field of IT don’t know and don’t expect, true and an interesting read. Not backed by good data but anyway. F.ex.: “[..] a programmer spends about 10-20% of his time writing code [..] much of the other 90% thinking, researching, and experimenting”. “A good programmer is ten times more productive than an average programmer. A great programmer is 20-100 times more productive than the average [..]” “Bad programmers write code which lacks conceptual integrity, non-redundancy, hierarchy, and patterns, and so is very difficult to refactor.” “Continuous change leads to software rot, which erodes the conceptual integrity of the original design.” “A 2004 study found that most software projects (51%) will fail in a critical aspect, and 15% will fail totally.” […]

By: orlando

orlando — Sat, 13 Oct 2012 10:54:49 +0000

I guess in the discussion I miss the clear definition of ‘average programmer’. I mean, is it true that in bad day the best programmer makes the wrong decision, still he’ll have to correct his failures -provided management gives him the chance. I would say again that productivity statistics used to measure people are very subjective. I’m thinking now that I’m a bad programmer, if I look at the last 6 years of my career. However, if I’m that bad, how comes that I’ve been in the business so long? Something to reflect about. Thanks for the original post.

By: Muskie

Muskie — Thu, 04 Oct 2012 16:29:39 +0000

It appears my comments are still awaiting moderation after several days…

By: Raymond

Raymond — Thu, 04 Oct 2012 15:11:58 +0000

Just a thought: maybe great programmers (would) get tired of being underpaid and go to their own startups (hoping) to get $5,000,000 a year! 😉