Hacker News Reader

Comment by breakingcups | Hacker News Reader

Apparently a lazy programmer does not spellcheck.

Also, this does not seem lazy to me at all: > A lazy programmer writes a lot of tests, so QA junks do not waste their time. > A lazy programmer documents their code, so thar [sic] coworkers do not waste their time.

View on HN

> A lazy programmer documents their code, so thar [sic] coworkers do not waste their time.

I have been compelled to write detailed documentation specifically because I was getting tired of being asked questions about it[1]. Though I would say the issue isn’t really laziness so much as general asociability and a need to focus...

[1] It does nothing to stop the flow of questions but it does mean I’m more likely to give an answer that’s actually correct :)

Did anyone ever read the documentation?

Serious question. I've spent a lot of effort writing internal and external documentation for various systems over the years, and I'm not sure anybody ever read any of it.

I think that clean code is more useful than documentation. However in some cases it's not clear why some code was written that way, more than how it was written. In that case a couple of lines of documentation helps IMO.

Also, if you write relatively small and short functions and you document the goal, the inputs and the result, then the code is quite self explanatory.

It really depends on the domain. I think your comment is generally true for “most code,” since most code involves relatively simple concepts familiar to most programmers, and is performing a fairly clear task.

But there are many functions where it is reasonable to have even hundreds of words worth of comments:

- anything that heavily uses intrinsics and requires the programmer to have a detailed mental model of the CPU in order to analyze (e.g. making an ASCII table of the register state at each major step of the program). Likewise with assembly programming, though obviously that’s a special case.

- a particularly sophisticated graph-theoretic algorithm, for which the “comment” might be essentially a short CS paper explaining how the algorithm works, giving its time/space complexity, and proving correctness

- the “main function” for simulating a physical or financial system, which might required detailed descriptions of the equations, parameters, and various options

I am working on some compiler stuff and have taken to literate programming for basically everything that’s not a simple utility.

Yes - often a question would be answered just by pointing to the documentation or relevant comments in the code and I am sure my coworkers read the docs independently as needed. Though especially at my last job the domain logic was especially tricky (health research informatics / HIPAA stuff / etc) so that might mean documentation was unusually valuable in that particular job.

I read it, and I read its absence as well. If there is no (insert interface commenting format that your IDE can parse), that's a code smell. Too often the preceding devs didn't explain themselves because they couldn't.

No, but you can answer their question by linking to the doc or telling them the title of the doc to google it themselves.

Agreed.

Would rather say:

A lazy programmer documents their code so they do not have to waste time explaining it in person.

A lazy programmer writes thorough automated tests so they do not have to waste time on repetitive manual testing.

Do we have the same definition of lazy? A truly lazy programmer does neither. If they still have their job it’s because if stuff blows other people know that it’s easier to fix by themselves rather than chase the lazy programmer to fix their shit.

A lazy programmer writes a bunch of tests, writes just enough code that they pass, then creates a PR and lets someone else find all the corner cases they didn't bother to think about.

There’s an old programming meme about laziness being invoked here: http://threevirtues.com/

This virtue should always be accompanied by knowledge of this table though: https://xkcd.com/1205/

I know that I am guilty of automating stuff for way too long :)

I've been moving a large codebase to use unit and integration tests lately, and it's definitely saved me a lot of time compared to what I would spend on manual testing.

And also, as a programmer I enjoy the process of writing and debugging tests much more than manual testing, so even if it wasn't a time saver, it would still make my job more enjoyable.

I'm guessing the typos were a trap, considering their proximity to "silly and tiring things".

I started documenting my code so future me doesn't need to spend a lot of time figuring it out...

Reply on news.ycombinator.com