Am I a bad programmer?
-
So, the company I work for is pretty small, only about 8 developers. The biggest (web) app is very complicated and is chalk full of errors. To compound the issue, there is absolutly ZERO documentation in the code / database. The DB also has no Foriegn Key contraints and is only marginally normalized. I don't work on the app that much, so I'm not as familiar as everyone else is with it. Whenever a problem comes up, they can jump right to the problem, but it sometimes takes me hours.... The question is "Am I a bad programmer, or are they?" Most of us were drilled with the "document your code" as we were learning either by instructors or books, but no one here does that (except me).:mad: As far as new development goes, IMHO I think I am *better* because I grasp the concepts of normalization, documentation, OOD. All new concepts to them. I had to explain normalization and pursuede them to let me do it on some new tables I added!:mad: And this is no hole-in-the-wall company either, they have some BIG clients. Well, thanks for letting me beef!
I think not, simply because you bothered to ask. Bad programmers just pollute their way along oblivious to the stench of their product. Or so I imagine, I've never had to work with one. Just clean up after them.
declassified wrote:
Well, thanks for letting me beef!
That's why we're here, I guess. BDF
-
So, the company I work for is pretty small, only about 8 developers. The biggest (web) app is very complicated and is chalk full of errors. To compound the issue, there is absolutly ZERO documentation in the code / database. The DB also has no Foriegn Key contraints and is only marginally normalized. I don't work on the app that much, so I'm not as familiar as everyone else is with it. Whenever a problem comes up, they can jump right to the problem, but it sometimes takes me hours.... The question is "Am I a bad programmer, or are they?" Most of us were drilled with the "document your code" as we were learning either by instructors or books, but no one here does that (except me).:mad: As far as new development goes, IMHO I think I am *better* because I grasp the concepts of normalization, documentation, OOD. All new concepts to them. I had to explain normalization and pursuede them to let me do it on some new tables I added!:mad: And this is no hole-in-the-wall company either, they have some BIG clients. Well, thanks for letting me beef!
Aside from myself, I've never met a good programmer. And I'm pretty sure they would all say the same thing.
-
So, the company I work for is pretty small, only about 8 developers. The biggest (web) app is very complicated and is chalk full of errors. To compound the issue, there is absolutly ZERO documentation in the code / database. The DB also has no Foriegn Key contraints and is only marginally normalized. I don't work on the app that much, so I'm not as familiar as everyone else is with it. Whenever a problem comes up, they can jump right to the problem, but it sometimes takes me hours.... The question is "Am I a bad programmer, or are they?" Most of us were drilled with the "document your code" as we were learning either by instructors or books, but no one here does that (except me).:mad: As far as new development goes, IMHO I think I am *better* because I grasp the concepts of normalization, documentation, OOD. All new concepts to them. I had to explain normalization and pursuede them to let me do it on some new tables I added!:mad: And this is no hole-in-the-wall company either, they have some BIG clients. Well, thanks for letting me beef!
It is the mark of a professional to recognize that he/she is a bad programer. This is when you learn to... * document your code. So others can understand the logic that could only come out of your head. * use error handling. You want to provide a graceful and informative exit when your code crashes. * ask for peer review, code walkthroughs and structured testing You want others to catch mistakes you will inevitably make before they get to production. * ask for an implementation process. Beacause implementation suprises suck big time. This includes getting the proper signoffs, resources allocated, and backout plans. * instrument you application. You you know the testers are bad testers and won't catch everything. You want real world problems to be visible before they cause serious damage.
-
I know, I know, it's my Achilles heel. In a world where "nite" is increasingly a valid spelling, I don't see why we can't just combine your and you're and call it even. ;)
"I don't want more choice. I just want better things!" - Edina Monsoon
"Nite" is a bad spelling for what? Only joking ( sort of ) I'm so English I had to stop and think what you were talking about.
pseudonym67 My Articles[^] Beginning KDevelop Programming[^]
-
So, the company I work for is pretty small, only about 8 developers. The biggest (web) app is very complicated and is chalk full of errors. To compound the issue, there is absolutly ZERO documentation in the code / database. The DB also has no Foriegn Key contraints and is only marginally normalized. I don't work on the app that much, so I'm not as familiar as everyone else is with it. Whenever a problem comes up, they can jump right to the problem, but it sometimes takes me hours.... The question is "Am I a bad programmer, or are they?" Most of us were drilled with the "document your code" as we were learning either by instructors or books, but no one here does that (except me).:mad: As far as new development goes, IMHO I think I am *better* because I grasp the concepts of normalization, documentation, OOD. All new concepts to them. I had to explain normalization and pursuede them to let me do it on some new tables I added!:mad: And this is no hole-in-the-wall company either, they have some BIG clients. Well, thanks for letting me beef!
-
So, the company I work for is pretty small, only about 8 developers. The biggest (web) app is very complicated and is chalk full of errors. To compound the issue, there is absolutly ZERO documentation in the code / database. The DB also has no Foriegn Key contraints and is only marginally normalized. I don't work on the app that much, so I'm not as familiar as everyone else is with it. Whenever a problem comes up, they can jump right to the problem, but it sometimes takes me hours.... The question is "Am I a bad programmer, or are they?" Most of us were drilled with the "document your code" as we were learning either by instructors or books, but no one here does that (except me).:mad: As far as new development goes, IMHO I think I am *better* because I grasp the concepts of normalization, documentation, OOD. All new concepts to them. I had to explain normalization and pursuede them to let me do it on some new tables I added!:mad: And this is no hole-in-the-wall company either, they have some BIG clients. Well, thanks for letting me beef!
Nearly everyone in this thread has used bad English. You cannot combine your and you're as they have different meanings; the first is used when referring to something that is owned by a person (the possessive form of you), the second is a contraction of 'you are'. Again, the apostrophe in Achilles' is a used to denote possession, as in John's car, we just don't add an s to a word that ends in an s. Its the same thing for Their, There, They're. They all have different meanings. If you use bad English, it makes anything you write harder to read, and the reader might well make judgments about the person who wrote it. IMHO Gramr iS Gr8 :) LoL
-
Nearly everyone in this thread has used bad English. You cannot combine your and you're as they have different meanings; the first is used when referring to something that is owned by a person (the possessive form of you), the second is a contraction of 'you are'. Again, the apostrophe in Achilles' is a used to denote possession, as in John's car, we just don't add an s to a word that ends in an s. Its the same thing for Their, There, They're. They all have different meanings. If you use bad English, it makes anything you write harder to read, and the reader might well make judgments about the person who wrote it. IMHO Gramr iS Gr8 :) LoL
this.drink(beer) wrote:
Its the same thing
Excuse me for interrupting, I just feel like two cents for bringing this up, but.... That should be "it's," the contraction of it is. "Its" is the possessive. Talk about the pot calling the kettle black! ;) BDF
-
this.drink(beer) wrote:
Its the same thing
Excuse me for interrupting, I just feel like two cents for bringing this up, but.... That should be "it's," the contraction of it is. "Its" is the possessive. Talk about the pot calling the kettle black! ;) BDF
Well done. Obviously this was a deliferate mistale. for your cunning, you win the number 547521456988. Had you noticed the deliferate mistale just 3 minutes earlier you would have taken the Ferrari ;)
-
So, the company I work for is pretty small, only about 8 developers. The biggest (web) app is very complicated and is chalk full of errors. To compound the issue, there is absolutly ZERO documentation in the code / database. The DB also has no Foriegn Key contraints and is only marginally normalized. I don't work on the app that much, so I'm not as familiar as everyone else is with it. Whenever a problem comes up, they can jump right to the problem, but it sometimes takes me hours.... The question is "Am I a bad programmer, or are they?" Most of us were drilled with the "document your code" as we were learning either by instructors or books, but no one here does that (except me).:mad: As far as new development goes, IMHO I think I am *better* because I grasp the concepts of normalization, documentation, OOD. All new concepts to them. I had to explain normalization and pursuede them to let me do it on some new tables I added!:mad: And this is no hole-in-the-wall company either, they have some BIG clients. Well, thanks for letting me beef!
Documentation? OOD? Ha! I have been programming C++ for 15 years and the only thing that counts in any company is how long you take to complete the task. Time is money.
-
Well done. Obviously this was a deliferate mistale. for your cunning, you win the number 547521456988. Had you noticed the deliferate mistale just 3 minutes earlier you would have taken the Ferrari ;)
this.drink(beer) wrote:
deliferate mistale
Eye new that.
this.drink(beer) wrote:
just 3 minutes earlier
Darn the luck! BDF
-
this.drink(beer) wrote:
deliferate mistale
Eye new that.
this.drink(beer) wrote:
just 3 minutes earlier
Darn the luck! BDF
Seriously though, the interchanging of its and it's bugs me too. I should hang my head in shame.
-
Living with the U.S. as our next door neighbour puts certain strains and pressures on the English language.
"I don't want more choice. I just want better things!" - Edina Monsoon
-
So, the company I work for is pretty small, only about 8 developers. The biggest (web) app is very complicated and is chalk full of errors. To compound the issue, there is absolutly ZERO documentation in the code / database. The DB also has no Foriegn Key contraints and is only marginally normalized. I don't work on the app that much, so I'm not as familiar as everyone else is with it. Whenever a problem comes up, they can jump right to the problem, but it sometimes takes me hours.... The question is "Am I a bad programmer, or are they?" Most of us were drilled with the "document your code" as we were learning either by instructors or books, but no one here does that (except me).:mad: As far as new development goes, IMHO I think I am *better* because I grasp the concepts of normalization, documentation, OOD. All new concepts to them. I had to explain normalization and pursuede them to let me do it on some new tables I added!:mad: And this is no hole-in-the-wall company either, they have some BIG clients. Well, thanks for letting me beef!
You are the programmer I'd rather hire for my own group. They are not. However, if we needed work done very, very quickly, they are the people I'd need in my group because they keep a model of how the software works in their head -- that's the documentation for it -- and can quickly reference it and jump to where the problem is. This is the way I solve programming problems when I can because there's just no beating it for speed, but I also try to do good OOD and document everything too (more for my own future reference than anything). So.. why would I rather have people like you in my group, even if you are not going to get work done as quickly as they can? For four reasons: 1) they are probably writing spaghetti code (most programmers I've seen that are like that do). 2) (1) means that the code gets exponentially less maintainable over time. The way you've been trained makes it less maintainable over time, but not exponentially, which means changes cost less to make for a lot longer and refactoring piecemeal(!) is possible when things get too bad. 3) they are irreplaceable. If they unexpectedly get hurt and stuck in the hospital for a week, nobody can do their jobs for them. If they get behind schedule, or the changes needed are just too significant for them to handle all alone in time, nobody can help them out. If they choose to leave the company, nobody can pick up where they left off without a very steep, very _long_ learning curve. The project schedule is at risk from their vacations, potentially leaving it stuck until they get back. 4) given time, you'll get as good as they are, but because of (1), (2) & (3), you'll be BETTER than they ever can be. I've seen all of this from multiple sides now, and am blessed to be working in a group consisting all of people like you. They are the best team I've ever worked with in my career.
patbob
-
Living with the U.S. as our next door neighbour puts certain strains and pressures on the English language.
"I don't want more choice. I just want better things!" - Edina Monsoon
-
So, the company I work for is pretty small, only about 8 developers. The biggest (web) app is very complicated and is chalk full of errors. To compound the issue, there is absolutly ZERO documentation in the code / database. The DB also has no Foriegn Key contraints and is only marginally normalized. I don't work on the app that much, so I'm not as familiar as everyone else is with it. Whenever a problem comes up, they can jump right to the problem, but it sometimes takes me hours.... The question is "Am I a bad programmer, or are they?" Most of us were drilled with the "document your code" as we were learning either by instructors or books, but no one here does that (except me).:mad: As far as new development goes, IMHO I think I am *better* because I grasp the concepts of normalization, documentation, OOD. All new concepts to them. I had to explain normalization and pursuede them to let me do it on some new tables I added!:mad: And this is no hole-in-the-wall company either, they have some BIG clients. Well, thanks for letting me beef!
-
Living with the U.S. as our next door neighbour puts certain strains and pressures on the English language.
"I don't want more choice. I just want better things!" - Edina Monsoon
-
Oh yeah, and I've had US customers complain that they talked to someone from India who couldn't speak American. Apparently that is what some of them think they speak. Generalizations don't work though, as almost every culture has their own set of corruptions/slag, eg. bloke, eh, good 'eye', bye etc. IMHO, language isn't communication unless the other person understands you, but if they do it is almost fair game to do whatever you want with it, at least as long as you are obeying the social norms of the region.
-
I live on the West Coast man, we don't speak like that around here, you're thinking of the east coast.
Never trust machinery more complicated than a knife and fork. - Jubal Harshaw in Stranger in a Strange Land
-
So, the company I work for is pretty small, only about 8 developers. The biggest (web) app is very complicated and is chalk full of errors. To compound the issue, there is absolutly ZERO documentation in the code / database. The DB also has no Foriegn Key contraints and is only marginally normalized. I don't work on the app that much, so I'm not as familiar as everyone else is with it. Whenever a problem comes up, they can jump right to the problem, but it sometimes takes me hours.... The question is "Am I a bad programmer, or are they?" Most of us were drilled with the "document your code" as we were learning either by instructors or books, but no one here does that (except me).:mad: As far as new development goes, IMHO I think I am *better* because I grasp the concepts of normalization, documentation, OOD. All new concepts to them. I had to explain normalization and pursuede them to let me do it on some new tables I added!:mad: And this is no hole-in-the-wall company either, they have some BIG clients. Well, thanks for letting me beef!
For once, I'm glad I work alone. When I was 12 and writing blackjack programs on my Vic-20, my older brother told me that it's important to always document my programs as good practice for when I was an adult. He was right then and your right now. The thing is, what if they all died in a horrible car accident tomorrow (don't get any ideas) and other programmers were brought into take over for them. They would be so mad!
Shohom67