> (A programmer does not primarily write code; rather, he primarily writes to another programmer about his problem solution.)

An obvious concept that can so easily be forgotten at times.

Not so obvious. I have a couple problems with this statement.

The first is that it confuses programmer (as in "coder") and developer (as in "designer"). But maybe that distinction didn't exist yet. To me, a programmer/coder is actually a translator - they translate the solution expressed in the specification of a program into a computer language (which is typically itself translated to machine code by a compiler). In reality, gaps in the specification or impedance mismatches between the specification language and the computer language can "force" a programmer to become a designer. In a way, one can still see this as a translator having to translate an idiomatic expression.

The second problem with this statement is the same as with "readability": it is very subjective. That's why another claim in this text, that incomprehensible code written by bad programmers dies early, has been proven false in practice. Readability and viability are in practice separate concerns. For instance, highly optimized code is often less comprehensible than naive code yet it is more viable because the extra efficiency is required. Furthermore, human to human communication using a computer language is more or less efficient depending on the distance between then computer language and natural language; as an extreme example, it would be terrible to communicate using assembly language. So the H2H communication problem is better solved with documentation. That is, comments if we speak strictly about computer code.

Now the question is: if comments solves the human to human communication problem, why would one has to write more comprehensible/readable code? To me the answer is: you don't write comprehensible code in order to better communicate with your fellow programmers, you write comprehensible code because you write the simplest possible code. It is comprehensible because it is simple, not because of the additional requirement that it has to be understood by someone else.

Is there really 2 roles there? Who wants to design but not code or code but not design? I can't really imagine how you could even do either well without doing the other.

It sort of reminds of mechanical engineering, where engineers sketch out the problem solution, do the calculations, and make sure the solution works. Then, they supervise drafters or technologists to produce the actual final product of engineering, drawings (2D/3D, paper/CAD, whatever).

Of course, that's in larger orgs. Smaller places will typically have an engineer doing everything.

Of course, there is overlap there. Technician->engineer used to be a fairly common career path.

You apparently have not encountered the "architecture astronaut" archetype[1]. Your final sentence stands; usually they can't.

[1] http://www.joelonsoftware.com/articles/fog0000000018.html

The issue with "architecture astronauts" is that most problems in software just aren't complex enough to warrant formal design. The core failing of these people is that they impose unnecessary design complexity in order to force the design to be complex enough to warrant formal design.

If the problem is inherently complex enough, particularly if it is multidisciplined, than it is the correct approach.

High-assurance sub-fields have many examples where the code is easiest part as it's just implementing a verified spec. Others have plenty of work on both sides. Altran (formerly Praxis) is a nice example with many commercial successes:

http://sdg.csail.mit.edu/6.894/dnjPapers/hall-correctness-by...

So called software architects seem to tend towards design only.

It's a "turtles all the way down" issue, though.

Software architects do the macro design, but they need to do that from an understanding of how it will be implemented, and the various lower level tradeoffs like consideration of the memory constraints of the target platforms.

In order to implement that design the non-architect programmers need to micro-design their bits that they build, too. And those smaller bits also often need abstractions/mini-architectures that aren't part of the macro architecture.

See proper engineering and the distinction between an engineer, a technician, and an assembler. There is overlap, of course, but designing and producing the product is a collaboration between all three. The engineer is primarily responsible for designing the system, the technician for helping the engineer translate the design into a realized system, and the assembler for actually realizing the system.

Well, but it's a bit weird with software. The "realized system" typically comes out of a compiler. When designing the system, the computer can often take your design and turn it into a realized thing.

In fact, we even have software called an assembler :)

Of course, it all depends on what level you're doing design at, and what level your language(s) work at. But the point is that those 3 roles aren't necessarily are fulfilled by humans when working with software.

I didn't say they necessarily were all fulfilled by humans. My point is that they are not necessarily all fulfilled by one human. Apropos of the comment I made in response to the "architecture astronauts", the complexity of most software projects is such that the design, from a technical standpoint, is a pretty small portion of the total effort required. In that case it makes sense for the technician to be the designer as well, which is something that often happens in the trades on simple jobs.

That does not mean that there can't or shouldn't be a distinction between the engineer and the technician on sufficiently complex projects. That is, they don't need to be filled by people who could perform either role, as the original comment I was replying to implied. That point was either miscommunicated in my original post or rubbed some people the wrong way.

The thing is that engineers produce and maintain documents. Specifically they produce source documents from which the end product has been derived.

That's exactly what a coder does.

There are some fields (draftsman, typist, others?) of people who created fine documents based on vague documents from engineers, architects etc. So in principle you could have a similar distinction between software archtects and coders. But it is exactly those document-gruntwork fields which have been transformed most by computers.

Are organizations still trying to move in that direction when engineering software products? I know it's been tried for decades now. But my limited experiences in organizations that tried it have not been very good. I'm curious if any organizations have made it work.

At the risk of drawing accusations of using the "No True Scotsman" fallacy, I'd say that most attempts have been trying to force-fit that type of style on projects that don't warrant it. That happens in all areas of engineering, though. The specific problem in software, IMO, is that too many projects are considered software "engineering" that shouldn't be, because they just aren't complex enough.

> To me the answer is: you don't write comprehensible code in order to better communicate with your fellow programmers, you write comprehensible code because you write the simplest possible code.

This is covered in the essay.

> It would appear all good programmers attempt to do this, whether they recognize it or not.

By writing the simplest code possible you are working on communicating with other programmers (including your future self).

> By writing the simplest code possible you are working on communicating with other programmers (including your future self).

Yes, the computer really doesn't care if your code is simple.

"Now the question is: if comments solves the human to human communication problem, why would one has to write more comprehensible/readable code? To me the answer is: you don't write comprehensible code in order to better communicate with your fellow programmers"

I strongly disagree with that statement. coders spend more time reading code than coding it. being fast & bug free is important, but its not the only reason to write readable code, and simple is only one proxy for readable code. also important is following standards, easy to follow flow, choosing good variable names, etc.

sometimes a day for me is spending 6 hours reading code, and then maybe adding or changing one line.

> simple is only one proxy for readable code

No, simple isn't a proxy for readable code. One can write in a readable manner a complex solution to a problem, but it isn't always right (using other "proxies" isn't, either).

It isn't always right because it's "a complex solution to a problem", not "a complex solution to a complex problem". What you made readable might even be "an overly complex solution to an actually simple problem"; meaning - to put it bluntly - that you have inadvertently spent your precious time on putting lipstick on a pig.

I didnt say simple was the only proxy, just that it is one. if you are at odds with that, then take it up with pretty much all the greatest minds in computer science.

Anybody know whose handwritten note appears at the top? The URL includes "Knuth" and "Baker" and the initials at the top look like "CLB".

(Also, we changed the URL from http://videlalvaro.github.io/2014/09/a-programmers-role.html to the original source, in keeping with the HN guidelines, which call for original sources. In this case the submitted article does add glosses, but not enough to be more substantive than the original. Historical material is particularly welcome on HN, especially when it hasn't appeared before, and this piece doesn't seem to have.)

Chuck Baker [0], according to the index [1], which also has a link to the cover letter [2] from when he sent this and some other papers to Knuth.

[0] http://history.computer.org/pioneers/baker.html

[1] http://archive.computerhistory.org/resources/text/Knuth_Don_...

[2] http://archive.computerhistory.org/resources/text/Knuth_Don_...

Thanks!

Oh, I had to google what dybbuk is. I first thought it's debug, but it didn't make sense.

"In Jewish mythology, a dybbuk (Yiddish: דיבוק‎, from the Hebrew verb דָּבַק dāḇaq meaning "adhere" or "cling") is a malicious possessing spirit believed to be the dislocated soul of a dead person."

It seems HN has a vintage computing day. Two articles are besides each other on the front page :)

https://news.ycombinator.com/item?id=12568829

I am kind of dissapointed that posts about "good practices" dumbly enumerating those like SRP and DRY without adding any value get here a lot of upvotes. Where this paper stating why we should use best practices has like 10 points. You can also infer from it why you somethimes should not use "good practices".

That aerospace corporation job advertised there sounds might fine. Even if they are a little sexist!

Still very much a going concern [1] (and a fair few open positions listed on their website...). They're an interesting organization -- basically, set up to provide long-term oversight over the ballistic missile program.

[1] - http://www.aerospace.org/

The job ad on the bottom mentions the following:

> These are excellent opportunities for men who have two to six years experience with [some computer]. We prefer college graduates but will carefully consider all applicants.

Uh, graduates with work experience? Am I missing something or is that a contradiction?

No, they mean that all applicants must have years of work experience. Some applicants might be considered if they never got a college degree, but they prefer applicants who got a college degree before they got their six years of job experience.

Ah that makes sense. Graduates sounds to me like people who just graduated, but of course that's not what it technically means.

There's no contradiction; it's just not an entry-level job. (Someone could get work experience then a degree, or a degree then work experience, or both simultaneously.)

Your quotation doesn't says work experience. It says experiences with [some computer] -- you could get that at a university.

Seems odd though, two to six years. If you used it in a few classes during 3 years, I'm not sure I'd even call that 3 years of work experience. And asking for six years is really weird in this context.

I like the font in the PDF

looks like Futura.

great look

It's the font on the Supreme logo (𝙎𝙪𝙥𝙧𝙚𝙢𝙚)

Please stop posting like this. We ban accounts that continue to do so.

https://news.ycombinator.com/newsguidelines.html

We detached this subthread from https://news.ycombinator.com/item?id=12570396 and marked it off-topic.

I don't agree!

I know many programmers, that just write the code.

For example: what problem is solved by the developer when he/she coding the login page?

It just like any other profession, only a few people in the group are able to solve problems

Have you even read the article?

TLDR; You are not only writing instructions for the compiler but for your future self and your fellow programmers. How can you disagree with that?

There is throw away code, one offs, and solutions that have immediate but not lasting values. Programming has been overloaded to mean a wide range of activities, from casual data analysis tasks to avionics engineering.

yes, I have red and I don't agree. I do not like such a generalization.

a summary of the entire article is:

"a programer does not primarily write code; rather, he primarily writes to another programer about his problem solution."

I agree with one: there are good programers and there are bad programers. I don't agree, that bad programers die young ;) Today there are more bad than good programmers.

Summary is: communication is more important than writing syntactically correct programs.

No offense, but you have some trouble understanding the language. If you re-read it, it say that young programmer'S code die young, not the programmers themselves :)

no offence taken.

I agree with this: "communication is more important than writing syntactically correct programs" but article is titled: "what a programmer does" not "what is the most important in a programer job"

To me, that's equivalent :)*

* that's highly subjective