Current Events > Not commenting your code is job security

(+) Yeah! (+)

That way only you can fix it. Don't buy into the myth of commenting

not commenting your code is making life harder for future you

Y'all got secret passwords up in this??

Giant_Aspirin posted...

not commenting your code is making life harder for future you

This, as well as anyone else who comes after you after you leave one way or another.

working for a company with NIH culture is the ultimate job security

Giant_Aspirin posted...

not commenting your code is making life harder for future you

This. This. So much fucking this.

I already have job security, and commenting my code and documenting everything saves me from a lot of future headaches

I've probably annoyed my coworkers by how much I document shit and ask them for details when they figure something out on a project, but it comes in handy. Most recent example was last week when a few people were pinged for some question and guess who had the answer on the very last line of our readme

Giant_Aspirin posted...

not commenting your code is making life harder for future you

this lol

"what the fuck did I do here"

TheMikh posted...

working for a company with NIH culture is the ultimate job security

Lol, what do you mean by this?

Comments are a lie and waste of time

COVxy posted...

Lol, what do you mean by this?

NIH culture refers to companies that rely on software/systems they developed from scratch in-house rather than outsourcing their needs to software built and actively maintained by other shops. the endgame after like a decade or two of doing this is a mountain of legacy code only supported and used in the company and which, in time as old developers leave, nobody in the engineering department really understands and is afraid to touch for fear of breaking mission critical processes.

i took it upon myself to understand and maintain it, and over the years have basically become the lone authority on the entirety of the company's software systems infrastructure.

Lol what theyll just fire you and change the code

Only the arrogance of youth leads someone to write uncommented code.

TheMikh posted...

NIH culture refers to companies that rely on software/systems they developed from scratch in-house rather than outsourcing their needs to software built and actively maintained by other shops. the endgame after like a decade or two of doing this is a mountain of legacy code only supported and used in the company and which, in time as old developers leave, nobody in the engineering department really understands and is afraid to touch for fear of breaking mission critical processes.

i took it upon myself to understand and maintain it, and over the years have basically become the lone authority on the entirety of the company's software systems infrastructure.

Interesting, haven't heard this before. Does NIH refer to National Institutes of Health?

[LFAQs-redacted-quote]

Pull requests should link to a Jira task

COVxy posted...

Interesting, haven't heard this before. Does NIH refer to National Institutes of Health?

Not-in-house

MutantJohn posted...

Not-in-house

Ahhhhhh, makes so much more sense.

Robot2600 posted...

Only the arrogance of youth leads someone to write uncommented code.

in my opinion comprehensive documentation (e.g., in wiki or javadoc style) and variables / functions / classes that are self-explanatory and well-modularized are more important than commenting.

i mostly comment to offer my rationale with code that isn't so intuitive even with the aforementioned best practices, and to summarize functions if they aren't obvious from the names.

COVxy posted...

Interesting, haven't heard this before. Does NIH refer to National Institutes of Health?

"not invented here."

MutantJohn posted...

Not-in-house

i haven't heard not-in-house used before but yeah, it sounds synonymous.

MutantJohn posted...

Pull requests should link to a Jira task

yes, but code should be self documenting. i shouldn't need to go out to an external system to understand why the code does what it does -- that's precisely what comments are for.

Giant_Aspirin posted...

yes, but code should be self documenting. i shouldn't need to go out to an external system to understand why the code does what it does -- that's precisely what comments are for.

That's not what self-documenting means.

My favorite is writing a comment block around a section of code that basically says "I know this looks wrong, but it works. Never change this code"

[LFAQs-redacted-quote]


I'm surprised unit testing hadn't been brought up before now, but I agree that it's especially critical for ensuring that components do exactly what they're supposed to. Long before developers, other departments, and even end users would otherwise detect and report issues, the unit tests will catch them if written properly and comprehensive in the scope they cover. It spares the company a lot of potential man-hour allocation expenses, as well as whatever other costs would have been incurred had the issues surfaced in a production environment.

If the only safety net you have as a coder is that your code is too labyrinthian for anyone else to understand, your job security is not good by definition.

If you're not commenting your code before writing it than you're an amateur and I hope for everyone's sake nothing you do is safety critical.

s0nicfan posted...

If you're not commenting your code before writing it than you're an amateur and I hope for everyone's sake nothing you do is safety critical.

I think you confused this with "writing your tests before writing the code".

Plus, safety-critical has extra components in the workflow added to it.

Again, comments really don't matter. They help, for sure, but they don't imply 1. software quality and 2. what the software actually does.

Comments are all talk whereas code is all walk, baby.

MutantJohn posted...

I think you confused this with "writing your tests before writing the code".

Plus, safety-critical has extra components in the workflow added to it.

Again, comments really don't matter. They help, for sure, but they don't imply 1. software quality and 2. what the software actually does.

Comments are all talk whereas code is all walk, baby.

Both, but I meant commenting. It's incredibly useful to write a function description prior to writing code because you want to document what it SHOULD do so when things go wrong and someone else is trying to debug they undertand what the original intent was. Plus inline commenting prior to writing code is incredible for organization and structure. If you write your block comments before putting the implementation underneath, it also means any TODOs you throw in there are paired with what it eventually has to do. It saves a lot of time in the long run because you've fully thought through the end-to-end functionality of a function prior to starting the process of implementing it which catches any gaps in logic but also means if you have to resume another day its easy to tell where you left off.