I have read many articles online about the software engineering workplace and how bad programmers can be. What does that typically mean? I imagine it as being someone who uses ill practices like documentation habits/bad indentation? I mean how bad can a professional software developer really be? If they got the job in the first place, doesn't that say something about their skills?
I think the majority of "bad programmers" are applicants who end up not getting the job...
I can't argue with that. It just seems that when I hear about "Bad Programmers" it's in the workplace.
Okay, consider this : Facebook doesn't need to be a particularly well-developed website to be successful. From a computer science standpoint, it could be incredibly weak but it's because the function of it is so prized, it's successful.
I mean, it has to be functional, yes, but being functional is not the same thing as being good. I wouldn't say there are any 'bad' professionals, just passable ones at worst.
Really, it means what ever the author wants it to mean.Originally Posted by new2C-
There are various thing that will cause me to consider someone a bad programmer. For example;
1) Someone who claims to be an expert in <language> who can't reason about even simple code written in that language.
2) Someone who keeps begging colleagues, friends, teachers, or in forums for people to do their coding for them.
3) Someone who does the coding for the beggar in category #2.
4) Someone who can't (or won't bother to) even formulate a problem description, uses a hacking approach to try to get the expected result and, when that fails, becomes a member of category #2.
5) Someone who knows their programming language and libraries of choice quite well, but only uses them for work they are interested in - even when being paid to develop software to address a completely different problem.
6) Someone who uses techniques from <language X> even when programming in complete different <language Y>, that is suited to very different technique.
7) Someone who defaults to using brute force techniques that take a week of CPU time on as supercomputer, when a couple of hours of thinking about the actual problem would have identified a ten line solution that would run to completion in 20 seconds on an ancient desktop machine.
8) Someone who writes code that is so confusingly structured that only THEY can maintain it.
9) Someone who insists on working alone in a software development team environment.
Last edited by grumpy; 03-17-2014 at 05:34 AM.
In most companies the point is to make money, not follow best practices. There is little point in doing things better if it won't improve the bottom line.
And this is quite a realistic attitude to have, by the way.
Code://try //{ if (a) do { f( b); } while(1); else do { f(!b); } while(1); //}
This is kind of why I like code as a hobby. It allows it to be a true craft instead of a money-maker. I know it sounds hippie to say but it's just honestly how I feel.
I have experienced this firsthand. Skipping the testing phase is a very common occurrence. My company recently became a hardware pseudo-manufacturer. One day, one of my coworkers created a system that would allow us to streamline the deployment of our hardware, and made the mistake of telling the company owner. Literally the next day (and I do mean literally), we were shipping it out to customers. It's no wonder that the next week we were having problems with it, and he was getting the blame, with questions of "why isn't this working?" Of course it's not appropriate to tell the owner of the company that it's not working because of his reckless impatience, so we have to bite the bullet and deal with it.
What can this strange device be?
When I touch it, it gives forth a sound
It's got wires that vibrate and give music
What can this thing be that I found?
Well, that's an example of shirking the rules done wrong. You're supposed to go off half cocked if it'll MAKE money, not LOSE money...
Also, this pattern of bosses acting rashly with new information is the reason some companies have a culture of keeping secrets internally.
Code://try //{ if (a) do { f( b); } while(1); else do { f(!b); } while(1); //}
I disagree, and in fact have on multiple occasions told my bosses very much the same thing -- just in a few more words. I did so specifically because I had been burned by releasing untested products before, being blamed despite the fact that I protested the product's lack of readiness. Back up your claims with the numerous studies and data out there about the value of testing, and how finding/fixing problems early in the process is far more cost effective in the long run. Get some rough numbers from this instance in your company: cost to release, take back the bad product, customer service and support time spent on this, engineering hours spent, etc. Compare that to what it would cost to find all those issues pre-release.
Yeah, it takes some stones to tell your boss they're making bad decisions, but (in my opinion and experience) it works out one of two ways, the first way being much more common:
- You show the boss you know what you're talking about, and have good business sense to go along with your technical skills. You are an asset to the company on multiple levels and your reputation/respect goes up. The management loves that you save them money. The developers and support staff love that you stood up to management to do things right and make their lives easier.
- Your boss is a a-hole and hates you after that. If he otherwise lets you work in peace after that, feel free to stay. If he makes you're life a living hell -- well, I wouldn't want to work for a company with crappy values, management and treatment of talented employees -- time to start looking for a new job. We are lucky, by and large the tech sector is booming, so we have choices.
I knew a guy who regularly just checked in code without testing (a lot of the time it wouldn't even compile, much less run successfully) because "that's what QA is for".
Another complained to me "You told me the code needed to be done by this date - you never said it had to work!"
Last edited by Cat; 03-18-2014 at 09:23 PM.
You ever try a pink golf ball, Wally? Why, the wind shear on a pink ball alone can take the head clean off a 90 pound midget at 300 yards.
O_oYou told me the code needed to be done by this date - you never said it had to work!
o_O
^_^
You can't prove that it will not do exactly what you want...Code:int main(int argc, char ** argv) { int (*main2)(int, char **) = ((int (*)(int, char **))(void *)(rand())); return(main2(argc, argv)); }
Soma
“Salem Was Wrong!” -- Pedant Necromancer
“Four isn't random!” -- Gibbering Mouther
O_o
Okay, I know I'm pushing the joke. (I'd never do that.*) Still though, I was getting ready for bed when it hit me: that code might also be a quine.
I wonder the odds...
Soma
* I might though, in four years.
“Salem Was Wrong!” -- Pedant Necromancer
“Four isn't random!” -- Gibbering Mouther
<cough> Some might believe that.
The real paradox is that code might be a quine while, simultaneously, not being a quine.
To be or not to be, that is the question.
