9 ms·

Some lesser-known truths about programming

118 points by AndrewDucker 16y ago

wccrawford 16y ago
The first few, I don't fully agree with. I think the numbers are exagerated. But these 2 have more truth: "Although most software is made by teams, it is not a democratic activity. Usually, just one person is responsible for the design, and the rest of the team fills in the details." When things are designed by 1 person (IME) they work better and have a more flowing work flow. Designing in a committee has been a freaking nightmare. "Programming is hard work. It’s an intense mental activity. Good programmers think about their work 24/7. They write their most important code in the shower and in their dreams. Because the most important work is done away from a keyboard, software projects cannot be accelerated by spending more time in the office or adding more people to a project." While I don't 'code in the shower', I do think about my projects constantly. An 'ah hah!' moment can come at any time. Just the other day I left for lunch and in the car on the way I thought of a possible reason for an issue we were experiencing. I was getting nothing while staring at it.
- kranner 16y ago
  I agree with you - I believe that, in most cases, the whole industry suffers from too many cooks spoiling the broth.
- cagey 16y ago
  "When things are designed by 1 person (IME) they work better and have a more flowing work flow. Designing in a committee has been a freaking nightmare." I completely agree. Yet in industry, being that one person (like I am) leads to great management consternation to the tune of "what if you're hit by the proverbial bus?" which leads to "you need an understudy", which leads to expending 2x the resources to achieve <2x results (the time spent selecting, training and guiding an understudy is definitely nowhere near 0, even when the choice of understudy turns out to have been a good one), and there can't help but be some feeling of "training your replacement". Industry loves interchangeable parts (people), and a one-man-band (domain expert or similar) grates against that ethos.
  - mseebach 16y ago
    I hate the proverbial bus. It seems to assume that central employees should be completely dispensible. If a key employee, being the architect or even the CEO, is hit by a bus, the company will take a hit. If employees are a central, strategic assets, you can't go around killing them off and expecting no impact on your business. Deal with it. The important metric is whether the company/project can recover, if it is resilient. Just because one guy drives the decisions, it doesn't mean that the team filling in the details don't know the code and the motivations behind it, and there can't be a guy from that team who could take a promotion, or that the team couldn't be reasonably productive for a while, while a new architect is brought on.
    - noblethrasher 16y ago
      In short, stakeholders should always be concerned with the potential discontinuity of (especially high) performance. But it's rather like technical debt (or any other kind); something that should be managed rather than avoided at all cost.
  - skybrian 16y ago
    That's a bad way to think about it. You probably don't want to work on the same project forever anyway, and if you're so smart, teaching other people what you know is the most important thing you should be doing. The bottleneck on many projects (especially those that are either poorly defined or particularly novel) is not coding speed, but rather learning speed. The faster the team learns about the problem it's really solving, the environment the solution has to live in, the people who will have to use the software, and what the possible solutions are, the faster you're done.
- hga 16y ago
  Apropos of the 1 person design thesis, the Antipatterns book said that only 1 in 5 programmers "get" abstraction. That's why democratic design processes tend to fail: the ones who get it are outvoted by the ones who don't. And that certainly matched my quarter century experience in the field, and boy was it frustrating to watch teams try to build frankly impossible systems. Heck, I'd be happy if more people got and could use big O notation. In one particularly unhappy case my peers just couldn't grok that the design would vastly outstrip the database's maximum transaction rate in normal customer configurations (number of client workstations).
  - makmanalp 16y ago
    That's like saying only 1 in n people have food, shelter and education. The ones that do have this property are likely to be with their peers (or close), as are the ones that don't.
dimitar 16y ago
What makes programming so unique? Why cannot we generalize? I think most of the same conclusions apply to teachers, lawyers, salesmen, marketers, architects, physicians, nurses, engineers and scientists, whatever. Wherever knowledge is valued in a job and there are intricacies lots of research, smart planning and thoughtful execution with a great commitment is going to make the worker a lot more productive.
- j_baker 16y ago
  "What makes programming so unique?" Programming isn't necessarily unique any more than any of the fields you mention are unique. "Why cannot we generalize?" ... but here's where you're stretching it a bit. I agree with you that programming isn't as unique as a lot of these blog posts make it out to be. But there's no ignoring the fact that different fields have different requirements. For example, I don't think that a good programmer necessarily has the skills to be a good teacher (unless it's a computer science teacher, and even then it's debatable). Computer science involves translating logic into code. Teaching requires you to make logic suitable for people less educated than yourself to understand. That's not to say that a good programmer couldn't learn to teach or vice versa. It's just that they're orthogonal skill sets.
  - jamesbritt 16y ago
    "That's not to say that a good programmer couldn't learn to teach or vice versa. It's just that they're orthogonal skill sets." In college (for my CS degree) I had to take a technical writing class. I loved it. I knew next to nothing about the field when I started, but soon found the idea of translating complex ideas and concepts into more easily understood formats quite intriguing. It was, in some ways, much like programming. I came to appreciate how hard it is for some people to understand some ideas (a point later reinforced when I started tutoring), and learned ways to improve descriptions and presentation. It seemed to me that if you are involved in some geeky tech field it behooves you to learn how to communicate with Earthlings. Bizarrely, when it came time to pick a minor, my counselor made a comment to the effect that with a CS major I should be looking at, oh, a EE or ME minor sort of thing. Not something out in left field, such as tech writing. I hadn't yet told him that in fact that was the minor I was going to pursue. :) Well worth the time and effort; if you have great ideas but cannot adequately express them, you're losing.
palish 16y ago
It’s easier to throw away bad code and start over than to change it. You had me nodding along until I came across this. This single sentence is not just wrong, it's so wrong that it unfortunately calls the rest of the article into question.
- hnal943 16y ago
  It is easier. Whether it's better or faster is another question.
  - palish 16y ago
    The whole reason to even list any programming truths is because they would make you a better and faster programmer.
    - bconway 16y ago
      The whole reason to even list any programming truths is because they would make you a better and faster programmer. Says who? Truths are not always good things. That doesn't make them any less factual.
      - palish 16y ago
        I'd say having a firm grip on reality can only make you a better programmer.
        loup-vaillant 16y ago
        You. Not others. If you stop writing bad code, that doesn't stop others to write bad code. That doesn't mean you won't maintain bad code.
- deleted 16y ago
  [deleted]
- mcantor 16y ago
deleted 16y ago
[deleted]
j_baker 16y ago
You know, I'm always skeptical about any article that refers to "truths". Why is it that we are so intent on there being just one "true" way to be a good programmer? Can't we accept that there are multiple paths to becoming good?
- stingraycharles 16y ago
  Not only are there multiple paths to becoming good, but "good" depends entirely on the requirements. In a start-up, a good programmer often is a programmer that has the ability to complete requirements as fast as possible. You don't want a start-up developer writing 10 lines of code a day on average while being on the hunt for the "best" solution, if there even exists such a thing. It all totally depends on context, and these articles always use the context from which the author is biased.
Juha 16y ago
I somewhat disagree with the point that good programmers think about the problems 24/7. Even good programmers loose motivation if there is bad company culture or some other de-motivating factors. I find that true motivation and true interest for the project are very important in software development but so many companies neglect it.
- thingie 16y ago
  Well, 24/7. That's simply too much. I had (well, still have) real-life problems that I not even closely think about 24 hours a day, all the week, for the last half year, and I don't get better in solving it. No. I'm slowly getting mad.
alexkearns 16y ago
Not so much lesser-known truths as absolute bullshit. The author describes developers who spend much of their time writing code as "lazy, ignorant and arrogant". I think it is the author who is being lazy, ignorant and arrogant in thinking that he knows the truth about programming. And the idea that a developer will only write a handful of lines of code each day that will end up in the final product might be true for a developer working on an established piece of software but anyone who has worked for a start-up or on their own software will just laugh at the idea of writing just 12 useful lines of code a day. A good developer can easily do hundreds, if not low thousands of lines of code in a day if pushed, and this code does often end up in the final product. Plus, he seems to think that a great programmer is someone who connects together bits of code created by others, rather than writing his own code. That's ridiculous - is someone who uses another person's code a better programmer than the person who wrote the code he is using, in which case I am a much better programmer than John Resig, say, because I simply use jQuery rather than having written it myself. I think this article is a perfect demonstration of the Dunning-Kruger effect. Sorry for being so blunt but the article bloody annoyed me.
- Retric 16y ago
  This is looking at the average day of the average programmer over the lifetime of the average product. Working on a 6 month old project it's vary easy to produce negative lines of code as you refractor. But, when you look at the average there is little reason to count time spent creating code that was soon replaced as useful. It's also easy to think you are vary produce when you produce 10k lines of code in the first six weeks of a project, but the reality is over time most of that is going away. And writing more than 10 lines of code a day that sticks around for more than 2 years without making people wanting to replace it is hard. PS: Google, for example, often scraps the source code of any company it acquires so the real metric of lines of code produced per day over the first six months is often zero in a successful project. Many a startup has failed and nothing of value was lost.
  - alexkearns 16y ago
    I think maybe you work in a completely different field of programming to me. Most lines of code I have written in my career have ended up in the final product. The same is true of most the developers I know.
tomlin 16y ago
Something funny about the subject and this site giving me a "Error establishing a database connection" error.
- deleted 16y ago
  [deleted]
Typhon 16y ago
There's nothing wrong with this article in my opinion, except for the title. « Some lesser-known truths about programming » sounds better than « A few things that those of you who never read Dilbert don't know about programming with a team for a big company », i guess, but the latter is much more accurate.
diego_moita 16y ago
Actually, most of these truths should be very well known; I've seen them thoroughly explained and documented in books like 'Code Complete', 'Peopleware', 'The Mythical Man-Month', 'Refactoring', etc. If there are people thinking they're bullshit, then the author is twice right.
ww520 16y ago
A dentist friend once asked me why is software development so difficult and cost so much. I told him that's because a competent developer has to become an expert in the domain of the application in addition being an expert in programming. It's like learning a new field every time you develop a new application.
- vog 16y ago
  This is so true. Often, people try to circumvent that problem by providing complete specs upfront. But those are doomed if they lack the old problem, i.e. if they were written by people who are missing expertise in either programming or in the domain. Another way to circumvent the problem is to establish a good communication flow between the domain experts and the software developers. However, that only works when this intense communication eventually makes at least one programmer a domain expert. So that strategy is more a way to reach this state rather than to circumvent it. Whenever a software project works really well, there'll bee another interesting phenomenon: The developers acquire a deeper, more abstract knowledge about the work practices than the workers themselves.
extension 16y ago
One that always seems to surprise non-programmers: there is no authoritative certification or regulation of programmers, the companies they work for, or the programs they produce. Being a software engineer requires no more credentials than playing the accordion on a street corner.
vog 16y ago
> Bad programmers write code which lacks conceptual integrity, non-redundancy, hierarchy, and patterns, and so is very difficult to refactor. It’s easier to throw away bad code and start over than to change it. Note that there's an interesting way in between. That is, refactoring code with the explicit goal of eventually replacing everything. There are several strategies to achieve that. Those techniques proved to be less expensive and especially less risky than rewriting everything from scratch. They work because although the old code has an ugly design, it still has a property that is worth keeping: It is working and (mostly) debugged code. Undervaluing that property is the root cause of the many failed attempts to rewrite big software systems.

118 points by AndrewDucker 16y ago

The first few, I don't fully agree with. I think the numbers are exagerated. But these 2 have more truth: "Although most software is made by teams, it is not a democratic activity. Usually, just one person is responsible for the design, and the rest of the team fills in the details." When things are designed by 1 person (IME) they work better and have a more flowing work flow. Designing in a committee has been a freaking nightmare. "Programming is hard work. It’s an intense mental activity. Good programmers think about their work 24/7. They write their most important code in the shower and in their dreams. Because the most important work is done away from a keyboard, software projects cannot be accelerated by spending more time in the office or adding more people to a project." While I don't 'code in the shower', I do think about my projects constantly. An 'ah hah!' moment can come at any time. Just the other day I left for lunch and in the car on the way I thought of a possible reason for an issue we were experiencing. I was getting nothing while staring at it.

kranner 16y ago
I agree with you - I believe that, in most cases, the whole industry suffers from too many cooks spoiling the broth.
cagey 16y ago
"When things are designed by 1 person (IME) they work better and have a more flowing work flow. Designing in a committee has been a freaking nightmare." I completely agree. Yet in industry, being that one person (like I am) leads to great management consternation to the tune of "what if you're hit by the proverbial bus?" which leads to "you need an understudy", which leads to expending 2x the resources to achieve <2x results (the time spent selecting, training and guiding an understudy is definitely nowhere near 0, even when the choice of understudy turns out to have been a good one), and there can't help but be some feeling of "training your replacement". Industry loves interchangeable parts (people), and a one-man-band (domain expert or similar) grates against that ethos.
- mseebach 16y ago
  I hate the proverbial bus. It seems to assume that central employees should be completely dispensible. If a key employee, being the architect or even the CEO, is hit by a bus, the company will take a hit. If employees are a central, strategic assets, you can't go around killing them off and expecting no impact on your business. Deal with it. The important metric is whether the company/project can recover, if it is resilient. Just because one guy drives the decisions, it doesn't mean that the team filling in the details don't know the code and the motivations behind it, and there can't be a guy from that team who could take a promotion, or that the team couldn't be reasonably productive for a while, while a new architect is brought on.
  - noblethrasher 16y ago
    In short, stakeholders should always be concerned with the potential discontinuity of (especially high) performance. But it's rather like technical debt (or any other kind); something that should be managed rather than avoided at all cost.
- skybrian 16y ago
  That's a bad way to think about it. You probably don't want to work on the same project forever anyway, and if you're so smart, teaching other people what you know is the most important thing you should be doing. The bottleneck on many projects (especially those that are either poorly defined or particularly novel) is not coding speed, but rather learning speed. The faster the team learns about the problem it's really solving, the environment the solution has to live in, the people who will have to use the software, and what the possible solutions are, the faster you're done.
hga 16y ago
Apropos of the 1 person design thesis, the Antipatterns book said that only 1 in 5 programmers "get" abstraction. That's why democratic design processes tend to fail: the ones who get it are outvoted by the ones who don't. And that certainly matched my quarter century experience in the field, and boy was it frustrating to watch teams try to build frankly impossible systems. Heck, I'd be happy if more people got and could use big O notation. In one particularly unhappy case my peers just couldn't grok that the design would vastly outstrip the database's maximum transaction rate in normal customer configurations (number of client workstations).
- makmanalp 16y ago
  That's like saying only 1 in n people have food, shelter and education. The ones that do have this property are likely to be with their peers (or close), as are the ones that don't.

dimitar 16y ago

What makes programming so unique? Why cannot we generalize? I think most of the same conclusions apply to teachers, lawyers, salesmen, marketers, architects, physicians, nurses, engineers and scientists, whatever. Wherever knowledge is valued in a job and there are intricacies lots of research, smart planning and thoughtful execution with a great commitment is going to make the worker a lot more productive.

j_baker 16y ago
"What makes programming so unique?" Programming isn't necessarily unique any more than any of the fields you mention are unique. "Why cannot we generalize?" ... but here's where you're stretching it a bit. I agree with you that programming isn't as unique as a lot of these blog posts make it out to be. But there's no ignoring the fact that different fields have different requirements. For example, I don't think that a good programmer necessarily has the skills to be a good teacher (unless it's a computer science teacher, and even then it's debatable). Computer science involves translating logic into code. Teaching requires you to make logic suitable for people less educated than yourself to understand. That's not to say that a good programmer couldn't learn to teach or vice versa. It's just that they're orthogonal skill sets.
- jamesbritt 16y ago
  "That's not to say that a good programmer couldn't learn to teach or vice versa. It's just that they're orthogonal skill sets." In college (for my CS degree) I had to take a technical writing class. I loved it. I knew next to nothing about the field when I started, but soon found the idea of translating complex ideas and concepts into more easily understood formats quite intriguing. It was, in some ways, much like programming. I came to appreciate how hard it is for some people to understand some ideas (a point later reinforced when I started tutoring), and learned ways to improve descriptions and presentation. It seemed to me that if you are involved in some geeky tech field it behooves you to learn how to communicate with Earthlings. Bizarrely, when it came time to pick a minor, my counselor made a comment to the effect that with a CS major I should be looking at, oh, a EE or ME minor sort of thing. Not something out in left field, such as tech writing. I hadn't yet told him that in fact that was the minor I was going to pursue. :) Well worth the time and effort; if you have great ideas but cannot adequately express them, you're losing.

palish 16y ago

It’s easier to throw away bad code and start over than to change it. You had me nodding along until I came across this. This single sentence is not just wrong, it's so wrong that it unfortunately calls the rest of the article into question.

hnal943 16y ago
It is easier. Whether it's better or faster is another question.
- palish 16y ago
  The whole reason to even list any programming truths is because they would make you a better and faster programmer.
  - bconway 16y ago
    The whole reason to even list any programming truths is because they would make you a better and faster programmer. Says who? Truths are not always good things. That doesn't make them any less factual.
    - palish 16y ago
      I'd say having a firm grip on reality can only make you a better programmer.
      - loup-vaillant 16y ago
        You. Not others. If you stop writing bad code, that doesn't stop others to write bad code. That doesn't mean you won't maintain bad code.
deleted 16y ago
[deleted]
mcantor 16y ago

deleted 16y ago

[deleted]

j_baker 16y ago

You know, I'm always skeptical about any article that refers to "truths". Why is it that we are so intent on there being just one "true" way to be a good programmer? Can't we accept that there are multiple paths to becoming good?

stingraycharles 16y ago
Not only are there multiple paths to becoming good, but "good" depends entirely on the requirements. In a start-up, a good programmer often is a programmer that has the ability to complete requirements as fast as possible. You don't want a start-up developer writing 10 lines of code a day on average while being on the hunt for the "best" solution, if there even exists such a thing. It all totally depends on context, and these articles always use the context from which the author is biased.

Juha 16y ago

I somewhat disagree with the point that good programmers think about the problems 24/7. Even good programmers loose motivation if there is bad company culture or some other de-motivating factors. I find that true motivation and true interest for the project are very important in software development but so many companies neglect it.

thingie 16y ago
Well, 24/7. That's simply too much. I had (well, still have) real-life problems that I not even closely think about 24 hours a day, all the week, for the last half year, and I don't get better in solving it. No. I'm slowly getting mad.

alexkearns 16y ago

Not so much lesser-known truths as absolute bullshit. The author describes developers who spend much of their time writing code as "lazy, ignorant and arrogant". I think it is the author who is being lazy, ignorant and arrogant in thinking that he knows the truth about programming. And the idea that a developer will only write a handful of lines of code each day that will end up in the final product might be true for a developer working on an established piece of software but anyone who has worked for a start-up or on their own software will just laugh at the idea of writing just 12 useful lines of code a day. A good developer can easily do hundreds, if not low thousands of lines of code in a day if pushed, and this code does often end up in the final product. Plus, he seems to think that a great programmer is someone who connects together bits of code created by others, rather than writing his own code. That's ridiculous - is someone who uses another person's code a better programmer than the person who wrote the code he is using, in which case I am a much better programmer than John Resig, say, because I simply use jQuery rather than having written it myself. I think this article is a perfect demonstration of the Dunning-Kruger effect. Sorry for being so blunt but the article bloody annoyed me.

Retric 16y ago
This is looking at the average day of the average programmer over the lifetime of the average product. Working on a 6 month old project it's vary easy to produce negative lines of code as you refractor. But, when you look at the average there is little reason to count time spent creating code that was soon replaced as useful. It's also easy to think you are vary produce when you produce 10k lines of code in the first six weeks of a project, but the reality is over time most of that is going away. And writing more than 10 lines of code a day that sticks around for more than 2 years without making people wanting to replace it is hard. PS: Google, for example, often scraps the source code of any company it acquires so the real metric of lines of code produced per day over the first six months is often zero in a successful project. Many a startup has failed and nothing of value was lost.
- alexkearns 16y ago
  I think maybe you work in a completely different field of programming to me. Most lines of code I have written in my career have ended up in the final product. The same is true of most the developers I know.

tomlin 16y ago

Something funny about the subject and this site giving me a "Error establishing a database connection" error.

deleted 16y ago
[deleted]

Typhon 16y ago

There's nothing wrong with this article in my opinion, except for the title. « Some lesser-known truths about programming » sounds better than « A few things that those of you who never read Dilbert don't know about programming with a team for a big company », i guess, but the latter is much more accurate.

diego_moita 16y ago

Actually, most of these truths should be very well known; I've seen them thoroughly explained and documented in books like 'Code Complete', 'Peopleware', 'The Mythical Man-Month', 'Refactoring', etc. If there are people thinking they're bullshit, then the author is twice right.

ww520 16y ago

A dentist friend once asked me why is software development so difficult and cost so much. I told him that's because a competent developer has to become an expert in the domain of the application in addition being an expert in programming. It's like learning a new field every time you develop a new application.

vog 16y ago
This is so true. Often, people try to circumvent that problem by providing complete specs upfront. But those are doomed if they lack the old problem, i.e. if they were written by people who are missing expertise in either programming or in the domain. Another way to circumvent the problem is to establish a good communication flow between the domain experts and the software developers. However, that only works when this intense communication eventually makes at least one programmer a domain expert. So that strategy is more a way to reach this state rather than to circumvent it. Whenever a software project works really well, there'll bee another interesting phenomenon: The developers acquire a deeper, more abstract knowledge about the work practices than the workers themselves.

extension 16y ago

One that always seems to surprise non-programmers: there is no authoritative certification or regulation of programmers, the companies they work for, or the programs they produce. Being a software engineer requires no more credentials than playing the accordion on a street corner.

vog 16y ago

> Bad programmers write code which lacks conceptual integrity, non-redundancy, hierarchy, and patterns, and so is very difficult to refactor. It’s easier to throw away bad code and start over than to change it. Note that there's an interesting way in between. That is, refactoring code with the explicit goal of eventually replacing everything. There are several strategies to achieve that. Those techniques proved to be less expensive and especially less risky than rewriting everything from scratch. They work because although the old code has an ugly design, it still has a property that is worth keeping: It is working and (mostly) debugged code. Undervaluing that property is the root cause of the many failed attempts to rewrite big software systems.