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

41 Answers 41

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

Anything that makes me think the developer in question is technically ignorant or doesn't care about quality and craftsmanship.

Some examples:

  • What are unit tests?
  • We don't have time to use any fancy patterns, the boss wants this done now
  • [ORM] is too complicated, DataSets are just easier
  • Don't refactor anything because it might break the app
  • Don't spend too much time making the design good, you'll be fired if you take too long
share|improve this answer

"We're going to skip the [screen design review with the users]. There's no time to fix any issues we might find."

share|improve this answer

These came from a manager, but I'm including them because she claimed to be a programmer.

Shortly after her hire, I asked what development methodologies she was familiar with:

Well I know the Waterfall method, but I've heard about Agile.

When I complained that cramming all of our programmers (13 of them) into a single room with waist-height cubicle walls would create too much noise and distractions:

We'll just have to manage it by using headphones.

(Shortly after I left the firm, I heard from a co-worker that they were now spending $300 per person to buy noise-cancelling headphones for everyone.)

And when I noted that the huge deductible on the company's restructured health plan was causing dissent among the ranks, she said:

You don't know how much better it is here. At my last job, the coffee was awful!

share|improve this answer

"Because Linus Said .... [ statement ] ....."

While yes, Linus is a great programmer, I can't stand people who don't think for themselves. If you know it is broken and can't be convinced otherwise, you should endeavour to fix it. Then, and only then will you know if it is really broken :)

The other one is:

"That's too much of a corner case to even consider"

Then you sit back and watch as someone uses your app as a trampoline for privilege escalation and stand in the very same corner while patching.

share|improve this answer

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.

share|improve this answer

I know Dreamweaver.

Or:

I'm an expert at Microsoft FrontPage.

Usually listed as top selling points by a web developer who really knows their stuff.

share|improve this answer
"I'll just try this"

Usually indicating hasn't a clue but will go and fiddle about and see what happens.

This is a valid technique for learning, in some cases. As a means of fixing reported defects it indicates a lack of willingness to think.

"I don't like the source control system so I am not going to use it.

Oh dear.

share|improve this answer

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!)

share|improve this answer

The bug occurred because [some value] wasn't high enough, so I increased the value.

share|improve this answer

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

share|improve this answer

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

share|improve this answer
1  
This may or may not be a bad thing, depending on the complexity of the request. I've seen issues where this was the correct fix. I've also seen long-running queries where the correct fix was to optimize the SQL or fix the DB table indexing. It all depends on your situation. –  Mason Wheeler Oct 29 '10 at 22:13

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

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

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

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

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

"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

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

"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

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

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

"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

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

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

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

"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

“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

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

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