pouët.net

they are very, very common.
being on the job now for more than 5 years I came to the conclusion that surviving for them is easy as long as software quality does neither matter for customers nor for (your own) management.

Writing and maintaining(!) complex, usually decades old software, with 1000s of files, dozens of sub systems and way too many dependencies is hard. And eventually complexity will eat all progress and motivation. People in general are not good dealing with complexity and all the sandboxing, unit testing and QA still produces software that sucks and has a million security holes. That's why in 100 years no one will deploy software written by humans anymore. Humans suck writing software, period.

And then, there's open source and a whole different can of worms that comes with that. ;)

well, the point is: no. I studied computer science with focus on embedded systems and microrobotics and i could have gotten through it w/o writing the single line of code (though I would have had to be an asshole and the let other do it). It depends on the focus. If I only did the bare minimum and working in the focussed area i could by now develop protocols, develop fault tolerant systems and calculate the probability of their failure, develop CPU scheduling systems, bus systems, and so on.

A degree in CS doesn't necessarily mean coding. If you want do do system design or something, you don't actually need to code for that, you need to design systems.

Dunno what other universities are like, but when i did it, it was basically a mix of 'core stuff' (a big part of which was 'software engineering', not coding as such but understanding how software gets build and how to do it on a high level) and optional modules. I could have chosen lots of coding modules, or i could have chosen lots of planning/management type stuff.

Guess it comes down to what direction you want to go in at the end, if you want to be a manager or something, not much point learning to be an elite coder. Then again, not much point getting a job coding at the end if that's the route you take :D

That's it :D

BAD CODERS! STAY OUT OF CODING AND GO INTO MANAGEMENT!

BAD MANAGERS! STAY OUT OF MANAGEMENT AND GO INTO CODING !

i reckon tigrou's nailed it. Coders don't want these muppets working with them, neither do management. Management are more powerful. They end up coding.

Hopefully, my actual managers are great coders too :D

What never ceases to amaze me is the number of people who are otherwise quite talented programmers who have very little understanding how their code runs, and therefore don't know why their code runs slow, or uses too much memory, or runs an expensive SAN way hotter than it should be.

Yo, interesting topic. I think what was covered quite well is the fact that ppl with a degree not necessarily are good programmers or have to be that.

However, there was a nice thing on page 1, lemme quote it:



That's actually quite nice. If he's around the company for 20 years he probably dropped out of university before the 1.0.0 standard was released. He also probably stayed up to date for a few years until he started to build his fucking house and became a dad. (insert other random reallife stuff here)

What i'm saying is that we (esp. programmers) all have some kind of half life and i believe it's pretty short. Things evolve so fast, and with the time you grow older you get hooked into projects and loose focus on new things. There are some guys here complaining they still have to use v70 at work. Now wait, there's already some alumni waiting in line who is using v120 since months and knows all the C++11 kungfu.

I think all of this applies more to the standard programmer than to self educated autodidactic freaks that simply love that shit (->demo coders e.g.), though i see a lot of truth in here.

A quick way to recognize a bad programmer is to ask him to bend is little finger!

baah: let me guess, and they fail to link an image? :)

Theres also more than one type. I've known very competent programmers who just couldnt code under pressure (deadlines). I knew one really great coder, knew every trick and abstraction in the book, who advised all other programmers, but simply couldnt deliver his own code because it was never 'good enough' (it was, I checked it but he could always see improvements and so wouldnt finish). I know one programmer who cant take criticism so badly that they cant even accept help when they are struggling as they think its criticism. Or the arrgoant programmer who knows _for sure_ they are the best in the world and nobody can work with them as nobody is good enough. Even once worked with a programmer who was excellent but smelt so badly nobody would work with him :-) but thats getting silly. It all adds up to a broken engineer even if the coding skills are up to scratch.

What about the dba? Or the man who make webservice and let the plain SQL error message arrive to you and it clearly indicate that you can try to do some injection (instead of an error code? anyway the error code will not be present in the docs, lol).

Despite the fact you can sometime have the wish to punch them because you have the feeling to type pure asm code instead of clear rest/xml request, these guys are funny too, but they should not survive ^^

Yeah, that guy does not write the worst code, actually he codes pretty good stuff, but he tends to be resistant to different ideas. Even after telling him that his idea is flawed, he still wanted to do it that way. And I'm sure he fully understood what I was saying, he is not stupid, just ignorant.

That's something that happens quite often over here. There is much bad code in the codebase that i call it a big hairy ball of mud. But instead of cleaning out a class every now and then ppl say "it has been written by someone else" or "yeah, the codebase has grown". Man, there even is code from a guy who completely misunderstood object oriented programming apparently. There is something like "object communicate by sending messages to each other" in the original idea. Well, that translates to calling methods, a call is a message. Well, what that guy did was implementing a sendMessage and a receiveMessage method in every class and then have a 300 line if else cascade on the parameter of receiveMessage. Later he claimed that he wanted to model events like that, but events are a built-in concept of the language and he also uses them, so that's prolly a lame explanation. But when it comes to discussion he is still feeling right about this code and I'm having a damn hard time tearing it apart. I took over a large code base from him and guess what, I cannot even see any references between classes coz all there is is sending and receiving messages.

@psonice: did i? o_O
I hope it was not that easy to unmask me! ;p

Peter principle:
* a competent employee is promoted to a superior hierarchical level, where he might not be as competent.
* an incompetent employee is normally neither promoted neither demoted, so he might well stay incompetent.

Thus everybody reaches a hierarchical level where he is incompetent.

Not necessarily, you can always say no to a promotion.

@skomp: that is hilarious :)

unless you have to work with it!

@baah: Actually that's not always true. I've heard of enough cases where some "random" ppl get promoted because the actual competent guy shouldn't be, as otherwise the complicated stuff wouldn't get done by anybody competent anymore. ;)

baah: "remote linking forbidden, please upgrade your account"

Yeah, i do think being competent can stop you getting promoted. Your boss looks at the team and says "Hey, I should promote this guy! But who would do all the work if he wasn't in that job?"

That only applies if you're very competent though. So very competent people can't get a promotion, everybody else reaches a level where they're incompetent.

One very annoying thing is the need to BE RIGHT, even if other people have to wait while you don't do the things that were agreed upon, or if the agreed product features never get finished.

So just out of curiosity and drive the discussion in a more productive direction: What exactly is a "bad programmer"? In the thread so far, we have seen various examples of "bad code" which exhibit unawareness of actual syntax of a programming language. My point being: besides stuff like that, can a "bad programmer" (or "bad code") be qualified in a more specific way than the obvious but blurry "I recognize it when I" see it?

Well it doesn't always take bad code. Sometimes just the assumption of it is enough, which is made obvious by them just opening their mouth.

There's some phrase that goes sort of like "It is better to keep your mouth shut and let people assume intelligence than to open it and prove otherwise." Some people just really make it obvious from what they say (or type) that they haven't a single clue.

Of those, however, I'd say there's a few shades. Those willing to learn and pick up the proper way to do things are going to (in theory) fastly move away from being a "bad" programmer. It's not by choice, but lack of experience.

Others write bad code and don't learn from any help, but are oblivious to this fact. Then finally, there are those who fit the previous group but are completely aware they're doing it. Willful ignorance. Those are the detestable ones.

a bad programmer? well... hard to define. somebody who doesn't know what his/her code does. those syntactical errors are some serious bad things, missing some core elements of a language one should know. but it usually doesn't compile. i know my if-loop wasn't great either.

bad code is easy to define. as long as it works it's code. the things that could be said are bad are unoptimized stuff, waste of memory in a big scale and crashing behaviour.

this thread kind of encourages me to become a programmer, sorry ;p