Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?

share|improve this question

closed as not constructive by Mark Trapp Oct 25 '11 at 21:01

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.If this question can be reworded to fit the rules in the help center, please edit the question.

25  
what's with the stereotyping of Indian programmers? There are 1.5 billion people on the subcontinent and the subset you've encountered is a statistically insignificant sample. The "Indian background" comment is so irrelevant as to distract from the point you were trying to make in that paragraph. Going to vote this question down for that reason. And no, I am not Indian. –  les2 Oct 25 '10 at 1:00
1  
It seems that I don't have enough rep. to vote down. Oh well ... –  les2 Oct 25 '10 at 1:02
1  
@LES2: I would downvote for you, but I'm not in the business of downvoting. I do agree that that part of the post is irrelevant, regardless of how Indian programmers may actually behave. –  Jon Purdy Oct 25 '10 at 4:44
5  
@FinnNk - I'm Indian, based in India, and I interview people for my team. I've come across the kind of person you're referring to, but they are not representative of Indian programmers as a whole. I do come across a larger number of such specimens than is normal, but I think that's because of the sheer number of people who work in the software industry in India. Sadly, quantity trumps over quality here. –  talonx Oct 25 '10 at 8:08
4  
Look - I guess you missed the part where I wrote "Often these are excellent developers". In fact they are often some of the best developers. However, in my experience (and from what other people in similar roles tell me), there are a minority who have been drilled in giving canned answers. Don't get me wrong I see equally bad (and worse) programmers from different backgrounds - just not in the same way that's all. And I fully accept that my experience in this area is limited - to make the text a bit clearer I'll remove the country reference. –  FinnNk Oct 25 '10 at 8:16
show 4 more comments

41 Answers 41

  • "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)
share|improve this answer
show 1 more comment

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.

share|improve this answer
9  
The appropriate response to this problem is to have a QA department with access to an accurate simulation of a production environment, and a requirement that every build be tested thoroughly by them before it ships. –  Mason Wheeler Oct 24 '10 at 23:51
1  
Please enlighten me. How can a developer make doubly sure that his/her fix is correct if he/she can't reproduce the bug? –  Jim G. Oct 25 '10 at 0:14
3  
@Jim: Sometimes the production environment is difficult or impossible to fully replicate. –  Bobby Tables Oct 25 '10 at 0:36
4  
Testing can only prove the presence of bugs - not their absence. -- Dijkstra –  les2 Oct 25 '10 at 1:03
2  
There's stuff I can't test, or can't test at all cheaply. (Working on code that will ultimately run on factory floor machines is like that sometimes.) What I really like then is code reviews. (Not that those catch everything, of course, but sometimes it's better to take a minimized risk.) –  David Thornley Oct 25 '10 at 16:14
show 3 more comments

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.

share|improve this answer
1  
I had this at my last job. All they had to do was take the time and it could have been automated. –  Terry Oct 25 '10 at 0:55
2  
The Turing-Church thesis states that everything can be automated. A programmer who disagrees with the Turing-Church thesis should probably find another job! –  Tom Anderson Oct 26 '10 at 16:36
2  
@Tom that is only true if you believe everything is computable; this however is provably false. I agree that surely the build in question must have been though. –  kasterma Oct 27 '10 at 13:18
5  
@kasterma: If you can make the build without serious creative activity, you can automate it. If the build has rules about "when it gets into an infinite loop", well, there's more problems than the lack of automation. –  David Thornley Oct 29 '10 at 15:01
show 3 more comments

Oh that is a magic number, it maps the <foo> to <baz>

share|improve this answer
add comment

Let's rebuild this from scratch.

share|improve this answer
14  
Tentative +1, depends on the application. –  Josh K Oct 25 '10 at 1:07
6  
Actually if it was the code you wrote this might not be such a bad idea –  Daniel Little Oct 25 '10 at 6:53
6  
Another tentative +1 Depends on 1. the application 2. who says it 3. what the plan is. If the new guy on the project instantly wants to rewrite; that's an alarm. If someone wants to re-write your Python app in Python, that's an alarm. Re-writing your legacy COBOL code in X (especially if you're down to one COBOL guy and have a team of X guys/gals) sounds like a good idea. Not "rewrite" in the sense of "drop everything and port" but in the sense of "no new COBOL development, transition features over piece by piece if possible, keep the old one running as long as we can". –  Inaimathi Oct 25 '10 at 13:21
2  
@ScottE - I was greatly amused by the line "One project I worked on actually had a data type called a FuckedString", thanks for that laugh! –  Rachel Oct 25 '10 at 14:52
show 6 more comments

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.

share|improve this answer
add comment

"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."

share|improve this answer
6  
This made me gasp. Geek campfire stories, eh? –  Jon Purdy Oct 25 '10 at 4:45
1  
It depends, but yeah mostly it's alarm bells. I used to work at a Java shop that pulled this kind of crap sometimes, and it always meant overtime for the other devs (I was the lowly front-end guy, so I rarely got pulled in for it). A PHP project did the same, except since their emergency deployment process was literally "copy the two/three offending files up", it was easily reversible and "Jimming" (I'll let you figure that one out) files onto the live server was more acceptable in these circumstances. It also very rarely caused overtime. –  Inaimathi Oct 25 '10 at 13:14
1  
@Anonymous Type: Because we don't stick to our guns and make everything follow the same process. We have to be better about educating them and showing them why the process is good so that they will internalize it and want to stick with it like we do. –  Beth Whitezel Oct 29 '10 at 5:11
1  
I once got into trouble that way. I was instructed to promote a certain change according to the standard process. As it happened, somebody had modified the production code without checking anything in, and without intentionally keeping a backup. Therefore, when I overwrote the production code as per SOP, I caused a problem and was blamed for it. I've rarely been as happy to leave a place. –  David Thornley Oct 29 '10 at 15:05
1  
@Anonymous Type - And because too many developers are happy to cut the same corners when it suits them. –  Jon Hopkins Nov 18 '10 at 8:29
show 3 more comments

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

share|improve this answer
add comment

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

share|improve this answer
10  
-1. TDD isn't the only right way to write code. –  dsimcha Nov 6 '10 at 21:51
show 1 more comment

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...

share|improve this answer
1  
Yea, +1 for #2... "We dont have time to write tests" –  Fredrik Oct 25 '10 at 12:11
3  
I hear #3 fairly regularly. Usually it's the age-old superstitious fear of garbage collection. Full disclosure, I don't do unit tests either, but that's more to do with my tools and my average project size. It has nothing to do with slowing me down. 1 and 4 still make me shudder though. –  Inaimathi Oct 25 '10 at 13:25
1  
Back up a couple decades, and my wife was asked why her code jumped around like that? The correct answer was top-down design and procedural programming, rather than writing everything in one big sequence. Apparently, that was too esoteric for that shop. –  David Thornley Oct 29 '10 at 15:07
1  
Yeah hear 'em all whats funny is if you heard 1,2,4 from the same programmer as 3. Because the first lot are supposedly slowing down their coding speed, but #3 will slow down their programming speed in order to speed up their program's speed. –  Anonymous Type Oct 31 '10 at 21:32
2  
#3 is true 100%, and stop finally arguing about it, gosh. It's the same as arguing that laws of physics don't apply to you. –  Coder Mar 14 '12 at 5:36
show 4 more comments

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.

share|improve this answer
9  
+1 for server and client side, this happens all the time! I do blame some of the frameworks for attempting the 'hide' the difference. .NET being one –  billy.bob Oct 25 '10 at 9:24
show 4 more comments

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?

share|improve this answer
1  
Wait, people fix compiler warnings? :) –  Tony Oct 25 '10 at 12:31
4  
@Tony: Of course! What did you think @SuppressWarnings was for? –  Tom Anderson Oct 26 '10 at 16:48
add comment

"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.

share|improve this answer
1  
Even if you have the source, this can be a productive approach - to debugging. But once you've found some pairs of inputs that get interestingly different behaviour, you can follow the code downriver to the point where the flows of execution diverge, and then you start hunting around for the bug. Of itself, as you say, it's not a fixing technique. –  Tom Anderson Oct 26 '10 at 16:42
show 3 more comments

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

share|improve this answer
5  
They use normally doesn't know what they "need". However they do know what they want. Sometimes they are the same thing. Other times they are not. A good developer can figure this out. :) If we (collective we) made what the user wanted, there would be millions of facebook clones. –  Tony Oct 25 '10 at 12:24
show 3 more comments

Senior programmer who asks how to make a text file with a "non keyboard" character. Basically not understanding ASCII encoding or how to write a file in binary mode.

share|improve this answer
13  
If you have a "Senior program" that asks questions, that's pretty advanced AI, even if they're dumb questions. –  Yar Oct 25 '10 at 6:36
1  
har har ... ok fixed it ;-p –  Casey Oct 27 '10 at 1:10
add comment

"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.

share|improve this answer
13  
Oh yes, the classic "that code looks complex, did you write that?" "no, I got that code from googling" "so how does it work?" "I don't know" "do you understand it?" "no" "where did you get it from?" "I can't remember" conversation... –  FinnNk Oct 25 '10 at 8:38
6  
Seems you never maintained a big project someone else wrote. –  back2dos Oct 25 '10 at 11:43
6  
+1 because I have had to utter that phrase before... In my defense, I did dig through tons of code to try to figure out why... However the depth and complexity of the .net framework bested me. I will agree that this will set off alarms because it normally means the developer did not look into the problem deep enough to fully understand it. –  Tony Oct 25 '10 at 12:34
2  
That statement alone would bug me, but most of the times I've heard it it's been followed by some recognition that this isn't a Good Thing. –  David Thornley Oct 25 '10 at 16:12
show 4 more comments

Due to time pressure we did not write any tests.

share|improve this answer
2  
"There's never time to do it right, and always time to do it over." –  David Thornley Oct 25 '10 at 16:17
show 1 more comment

“This is best practice.”

share|improve this answer
11  
Sometimes it is! –  Eric Oct 25 '10 at 16:53
16  
Blind, unthinking application of cargo-cult best practices is DEFINITELY a red flag. –  Dan Ray Oct 26 '10 at 12:19
2  
@Dan: exactly. This phrase makes me worry that the developer in question isn’t really thinking about what they’re doing. It’s argument from authority, without even identifying a specific authority. –  Paul D. Waite Oct 26 '10 at 12:40
2  
@Eric, doesn't mean they shouldn't explain why it is. It's when they refuse to explain why that it's a process smell. –  finnw Jan 21 '11 at 23:04
show 3 more comments

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.

share|improve this answer
6  
We've got a few guys like that on one of our teams. They are very smart guys; when they focus on getting things done, they're truly wonderful. But they are prone to wandering off on flights of creative genius that turn the codebase into some kind of mad Ballardian sculpture park full of incomprehensible, useless, beauty. –  Tom Anderson Oct 26 '10 at 16:45
2  
And to quote Steve Jobs, "real artists ship". –  Tom Anderson Oct 26 '10 at 16:47
show 3 more comments

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.

share|improve this answer
show 2 more comments
  • "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.
share|improve this answer
add comment

We'll fix it in the next version.

share|improve this answer
2  
I've got five year old "we should do this in 2.0" comments in the codebase I inherited. –  Tim Williscroft Oct 26 '10 at 0:13
add comment

"It works on my machine."

share|improve this answer
3  
A timeless classic! –  FinnNk Oct 25 '10 at 14:51
12  
...which is why I only ever put code into production that doesn't work on my machine :-) –  Kramii Oct 26 '10 at 12:29
show 3 more comments

I shouldn't need to understand the database structure.

It was an urgent fix, so we fixed it directly on production. (Oh so glad, devs no longer have prod rights at our company anymore.)

share|improve this answer
4  
@Matt: Our database is part of our app. I need to understand its structure just as much as i need to understand the code, config files, and HTML. –  Tom Anderson Oct 26 '10 at 16:51
show 1 more comment

I'll just whip something up. I don't need requirements. It should be ready for production in an hour.

share|improve this answer
7  
Sometimes the best way to get requirements is to whip something up and see why people hate it. Anybody who thinks it will be production ready has a weird sense of "production". –  Mark Ransom Oct 27 '10 at 3:07
add comment

"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.

share|improve this answer
2  
On some very embedded systems, this can be close to true. Things can be very difficult, time consuming or expensive to test. Usually that means - try and test a different way, or even (shudder) test as part of a larger accumulation of units rather than at the single unit level. There's always a creative way to test. –  quickly_now Oct 30 '10 at 3:47
2  
It was a web app! –  Henry Oct 31 '10 at 7:44
add comment

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.

share|improve this answer
add comment

"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?

share|improve this answer
3  
that is smart programming, recently I saw example of that. Some WebService should never return null, so app threw nullpointer when it did. in next version it checks for null. –  IAdapter Oct 26 '10 at 15:08
2  
I call this "rubber chicken" programming e.g. Oh, that? We shake the rubber chicken at the build server every Tuesday morning, it tends to crash otherwise. Wait! Why are you running away? –  Binary Worrier Aug 12 '11 at 12:55
show 5 more comments

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.

share|improve this answer
add comment

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

share|improve this answer
3  
I had somebody like that. Oh boy. What an adventure that bug-free code was. –  quickly_now Oct 30 '10 at 3:49
1  
and I've been a tester for one. Ugh. –  StevenV Aug 16 '11 at 17:00
add comment

Not the answer you're looking for? Browse other questions tagged or ask your own question.