Which comments instantly ring alarm bells when a programmer says them? [closed]

Question

Similar to my question about easily spotted warning signs in code I think sometimes comments programmers make can tell you quite a lot (of not good things) about them in a short period of time. The scariest I've heard recently (from a senior) is:

I could use source control, but it'd slow me down

Also, although not in the same category when I see something listed at the top of someone's CV and I ask them about it:

Oh, I didn't really use that but I was just in the same room as people using it.

Duh! Then why is it featured prominently on your CV???

Finally I quite often interview people with what looks like an excellent set of skills on paper. Sometimes these are excellent developers, but some of them when asked about a topic will rattle through a dictionary definition like a machine gun (and probably a better definition than I would be able to say if put on the spot like that). Then when asked to explain even really, really simple things to do with that topic are totally unable to (usually coming up with something totally wrong, followed by a repeat of the dictionary definition). I suspect that these are developers who have been in teams where they're not treated well and so have had no opportunity to act independently - which results in their learning being very superficial.

What other things have you heard that tell you that a programmer is, er, let's try and think of a nice way of saying this...still taking the first steps towards being great?

Answer 1

Our build/install is just too complicated. It can't be automated.

I have walked onto way too many projects where the build, development setup, and/or the product installation "process" was a ton of manual operations.

The result was either a poorly documented process with one guy who knew all of the steps that had to be done (and would mess up at least one of the steps and be forced to do it several times, or worse not realize until later that it was done wrong), or a giant Word document with page after page of screenshots and instructions to type something at the command prompt and hit return, which made the process take forever, easy to skip steps, likely to be out-of-date, and just painful.

Answer 2

Let's rebuild this from scratch.

Answer 3

These four things were said to me by the same programmer:

1. "I don't believe in encapsulation. There's really no point. All it does is add boilerplate and slows you down."
2. "I don't do unit tests. That just slows me down."
3. "Java is too slow. I need a fast language like C++."
4. "I should really comment my code but it takes so long. It would just slow me down."

Mr. Speedy's code is a joy to be handed. Every time a piece winds up in my lap, it just slows me down...

Answer 4

"This is an emergency the change needs to go to production now, we don't have time for review, testing, or a roll-back plan."

Answer 5

What sets off the bells for me is whenever I hear a programmer - a professional, not a student - asking a question that demonstrates that they really dont have a basic knowledge of computers or their profession. For example:

• a web developer asking a question that clearly indicates they dont understand the difference between what runs on the server side and what runs on the client.
• a programmer who does not understand that files names are not magical, and that a file's contents can be anything despite the name.
• or my favorite, when I hear questions such as "Can [programming language] be used to create [some routine application]". Yes, thats kinda the point of a programming language.

I dealt with one guy not too long ago, and I kid you not, when I told him to just merge a couple of text files into a single file, he didnt know how to do such a thing. BIG RED FLAG right there.

I dont get particularly perturbed at 'religious' statements. If you want to use methodology X, or dont want to use Y, go nuts, you're an adult, I dont care what you do. But when I see programmers who obviously dont understand the very basics, it drives me nuts.

Answer 6

"I'm not sure why it has to be this way, but it won't work unless it's like this."

While this can sometimes be a problem due to a problematic code base, this usually gets my alarm bells ringing, as it shows a lack of interest in finding out how the code really works and why it does what it does.

Answer 7

"It works on my machine."

Answer 8

“This is best practice.”

Answer 9

Personally, I look out for technically true statements that signal a broken understanding of software development/reality. Some of my favorites so far:

• "I like developing in Joomla because it uses the MVC architecture" (the project in question is an application that will be deployed only on Windows Server and doesn't have any dynamic content)
• "In my professional experience, version control never benefits the developers" (When asked, she clarified that she had only used Visual Source Safe in the past)
• "Well what's the problem with using GPL licensed code? It's just open source, there's no big deal!" (maintained dismissive arrogance even after confronted with the facts of GNU GPL's restrictions, particularly ones that affect proprietary software)
• "Why would you need to track those files? They're just scripts and code."

I'm lucky because my (non-technical) boss trusts me enough that when I call this particular developer out on something, I get the benefit of the doubt, but I know this kind of garbage must work at other companies, and I weep for them.

Answer 10

When a programmer fixes a bug which can't be tested (because it requires an extensive environment which only exists in production) and they say:

"Meh. I'll just check this in and assume it'll work."

Famous last words.

Answer 11

The user ir wrong!!, he/she doesn't have a clue, so I'll do what I KNOW is right. (disregarding user's needs)

Answer 12

"I solved the problem by increasing the request timeout to 1 hour"

Answer 13

My favorite 'Don't walk away. RUN' red flag comment:

"I don't see a problem with a 700 line method."

(usually an event handler where every possible event that can be raised on a window is funneled into a single event handler where the first thing it does is to do a switch on the control that the event originated on. Why have separate event handlers? Those would just clutter up the code!)

Answer 14

Q: "So what is this library about ?"
A: "This library is a DSL"

You can replace this by : "What is this class about ?" -> "It is a Command pattern"

This rings a bell because this developer is more interested in how the code is written than on what it does and what is its final goal.

How can you be good programmer if you put more value on the "beauty of the code" than on client value ?

Note that I don't say that design patterns are useless or that code quality is useless. I just say that what comes first is understanding and meeting customer needs.

Answer 15

"I'm sure I can fix the bug, I just need to try a few more combinations of..." sets my alarm bells ringing as an indicator of a programmer who's approach to fixing an identified bug is simply to guess, and to shuffle parameters or constants (or even code) randomly in the hope of stumbling on a fix. This is particularly dangerous when some superficial improvements may initially be obtained, and the developer presses on assuming that with enough time to continue prodding at the system the fix may be arrived at by chance or intuition. Needless to say, this is absolutely no substitute for a deep understanding of the code and the problem domain, and a more structured analysis of what's going on.

Answer 16

"It's impossible to test this"

Seriously, I managed a whole team who believed this. Fortunately it didn't take long to convince them otherwise.

Answer 17

I don't need to write unit tests as I write bug-free code

Answer 18

When asking another developer to do something:

It's not that hard.
Can't you just...

All too often a developer wants someone on another team to make a change. Dev A doesn't understand how to do it, so he asks Dev B to do it instead. Since it's no longer Dev A's problem, it must be simple right? Sometimes it's not as simple as Dev B likes to believe (and there may be good reasons why it doesn't already do things that way), but he doesn't care because someone else has to do it.

When you don't work in a particular field or on a particular project, it looks very simple from the outside. If I write a client for another developer's server, it looks simple to me - that's how things should be and it's a sign the server's well-written. But I know it's probably not that simple underneath and if I want a change to be done, and the developer comes back and says no, I don't turn around and say "come on, it's not that hard - can't you just do X?" because I know that the developer probably isn't an idiot, knows his own app better than I do, and has already thought of X and dismissed it.

Answer 19

People that want to apply rules without seeing the context.

I know best practices are really good but they are not magical things and you have to know when and how to apply them. Someone who tell me to apply a rules without seeing the context just tell me they don't know what they are doing.

If you want more info on this I suggest to read about the Dreyfus model of competence. Basically they done study to find what differentiate novice from expert and found that the more you go up on the ladder the less you have to blindly apply rules: you know why they are usefull, and, as such, when to apply them and when not to.

This is a key point from the study: context is everything.

Answer 20

We'll fix it in the next version.

Answer 21

"And then I do this, 'just in case'."

You mean... you don't know what your code does? You don't know whether what you want to do would have worked or not had you not done that thing, just in case?

Answer 22

It just works.

Anytime I hear this phrase, I just assume whatever is suppose to just work doesn't. I learned early on that if someone can not explain in detail how code (or anything for that matter) is going to work, it probably doesn't.

Answer 23

• "This thing surely works" / "This module has no bugs" (about his code)
• "I've almost done, this already compiles"
• using the wrong terminology in comments/variable names/function names (and really abusing it)

Answer 24

Here are a few fun ones I've heard...

QA is reporting too many bugs against us, so we don't have time to fix the compiler warnings.

At a company where the technical management wasn't really paying attention:

I know the way I've set up the company's source control system only really works well for me, and works like crap for everybody else, but you'll just have to live with that.

A development lead for a Linux-based product that was dead in the water without snazzy graphics, WebKit, a PDF engine, and highly sophisticated Javascript, all of which lives outside the kernel:

That's all user-space code, so it's all the same, and why should we care about it anyway?

Answer 25

• "Didn't have time for this, fix later" : Usually means it will never work.
• "This is hacky code but it works, based on xyz" : Usually means I stole this code and I have no idea how it really works.

Answer 26

"Yeah, it's fixed. I added a scheduled task to reboot the server every night at 2 am."

... or any other "fix" that just masks the problem instead of actually solving it.

Answer 27

I think we need to use XML...

You don't hear this one so much now. But there was a period some years ago when every developer seemed to want to do something, anything with XML (probably just to tick it on their resume). Result was a bunch of systems with hideously verbose, overcomplicated configuration files, ghastly persistence systems, insane communication protocols and incomprehensible excuses for DSLs, despite the most obvious rational design invariably being a simple flat text file.

Answer 28

All our data is safe since we are using C++ which (unlike C) will automatically take care of all data hiding and abstraction.

Answer 29

"Let's get this code written first; I'll get to the tests later."

Answer 30

Due to time pressure we did not write any tests.