Does bad code lead to poor motivation?
I am dont want anyone to feel that i am boasting, but i just want to discuss my case. Please advise me constructively. Thanks!
I was among the smartest programmers in my old company. I was the pride of my CEO's eye. In college, my professor used to tell in meetings to other students to code like me and work like me. He told me that i was one of the best students he has had. I had published more technical papers than anyone else in my college. I would consider myself above average.
All that changed once i moved into my new company. Why?. Because i am in charge of a code that is horribly written. Its so horrible that there are tables/variables with fields named 1212,3424,42354,646456 and so on. Each application has hundreds of forms, thousands of functions and almost every variable is named as 33233 or 232134. Meaningless names. To know what it stands for, you need to look in a table!. There are tens of thousands of such variables.
The people i work with are really kind and good people. But they are simply not bothered to change the code. So users have a lot of complaints. Earlier, i used to be extremely
meticulous in my code. I used to write 3-5 paragraphs as comments and people used to be astonished why i took so much pain. I guess i was being conscentious. Now, i too code like them. Why?. Beause most of my work involves adding something in the middle or patching up something.
I dont know why it has happenned. I spend my in the company surfing or lazing around. I cant bring myself to look at the code. I dont want to change it because if something goes wrong, i will be blamed (almost certainly). Usually, i just cut paste their code and do a shoddy job. I have lost all interest in programming or developing.
I originally thought that i would take some initiative and solve it. But i am not interested, my managers wont be interested even if i am.
Of course, i am to be blamed for it too. I dont see how i can be motivated again to work with this kind of thing.
I realize that this kind of attitude can hurt me in the long run.
Withheld
Wednesday, February 4, 2004
Bad code and poor motivation are both symptoms of a poor work environment and/or bad management.
Philo
Philo
Wednesday, February 4, 2004
Sounds like you're the victim of someones attempt at garnering job security.
Wednesday, February 4, 2004
Sounds like someone had a code generator going at one point??
Either way, it pays the same. Meaningful variable names would just take the fun out of the challenge.
enlightened one
Wednesday, February 4, 2004
It sounds like a poor work environment took the fun out of it.
www.MarkTAW.com
Wednesday, February 4, 2004
A soul sucking environment leads to poor motivation.
If you really like the company except for the codebase, maybe you can do something else there. Otherwise, get out.
If you just keep doing what you've been doing, where are you gonna be two years from now? Happy you stayed?
Matt Conrad
Wednesday, February 4, 2004
Just out of curiosity, what language are you working in that allows numbers for variable names?
Also, Philo is right (as usual).
Joe Blandy
Wednesday, February 4, 2004
Using numbers as variable names isn't such a bad idea.
If you name the variable after the value it holds, you don't have to look "inside" the variable to find out!
23887
Wednesday, February 4, 2004
First there was "Worst Ever: 7350 Line Function, 55 local vars" thread and now this.
Made me think because most of the stories are so scary and
almost unbelievable. Why would anyone program like that?
Is there some correlation with ones abilities and his coding practices?
Starting from myself, I think that I am better than average as
a programmer and that I produce code that is easy to read
and maintain.
At the same time I'm having trouble remembering other people's
names and names in general. I think that I know less than 10 names
of cafes/clubs in my town. Same with street names.
(Obviously, I don't live in NY).
On the other side, I really have a good feeling for finding
places - I can arrange a meeting with someone in another
city and in another country and I'll just be there without
any trouble.
What I am getting at is this: Somehow I think that my
shortcomings forced me to produce well-organized code, give
meaningful names to variables and functions and always try
to do it in as little as possible lines of code so I don't have
to remember much.
Many years ago, I had to write one program in BASICA
of DOS 3.x. at some computer users workshop.
Program had around 20 pages of code and I had lot of GOTOs and
I tried to read some code on top. There was a GOTO to somewhere
in the middle. I would try to go there, but it took me some
time to find that line and by then I forgot what exactly am I looking for.
Is it variable x1 or x2 and what about it?
Scroll down. Scroll up. Scroll down... After several millions of scrolls I
just gave up and said to myself that I am no good as a programmer.
I just can't remember anything.
Then I discovered Pascal that didn't have line numbers but had
constants, procedures and functions and later I found C. I realized that
if I could stop using global variables and GOTOs and if I could find
IDE that can remember lots of stuff for me, I would become one
hell of a programmer.
Maybe some programmers apply good coding practices because
without them they would produce nothing at all. And others could
get acceptable results without actually trying, so they slap some code
here and there and since it works most of the time why bother.
VPC
Wednesday, February 4, 2004
The problem is VPC, that every programmer thinks highly of their code, until someone else reads it and trys to maintain it. Said maintenance coder will curse the original programmer to no end, no matter how well written the original programmer thinks they wrote the code.
To say, "I write good, clean code." is a fallacy and you are only fooling yourself because everyone around you will disagree with you.
pj
Wednesday, February 4, 2004
> until someone else reads it and trys to maintain it.
OK, in absolute terms you are right. But in real world
terms, there is code that at least the author is comforable
with and if lot of other guys tell you that they could use
youre code for themselves, then you can start thinking
that you are "better than most".
VPC
Wednesday, February 4, 2004
> until someone else reads it and trys to maintain it.
It's clearly a spectrum.
Most projects simply do not have the time to make the code as good as it could be, and it's always been easier to write code than to read it; but even so there are definite variations in quality, and you *can* rank both code and the programmers who write it.
Portabella
Wednesday, February 4, 2004
I'm working on a project like this. And I used to be really anal about code too. As a matter of survival, I've had to adapt and just hack it up because that is the fastest way to get things done.
The only things you can really do is: 1) learn to code in these bizarre styles, or 2) create an interface between the new good code and the old digusting code, but even that is not always the best idea because it can obscure the program for the next guy who comes along. If everyone did that it would get kind of ridiculous.
Software is hard -- I think this is the norm rather than the exception.
Roose
Wednesday, February 4, 2004
Poor you... is this a product company or an internal IT shop ?
As a side question: why don't you get out of there ?
Look at some open source projects, code can be quite clean... it may be giving you :
- some motivation back
- some contacts through which you can get another job
Phil
Thursday, February 5, 2004
"Does bad code lead to poor motivation?"
As people have pointed out, bad code is a sign of a bad work environment. A bad work enviroment will drag any high performer down. Never underestimate the ability of those around you to affect you.
In our Western culture, a lot of emphasis is placed on individual performance. This makes us think our abilities are solely based on us, in isolation from everyone. But we're social creatures, and a lot of our motivation (and hence performance) comes from gaining the silent praise of others. If the people around you could give a rat's ass whether you write good code, guess what, you're not going to bother. If you're surrounded by short-term thinkers, then that's what you will become.
Successful people don't use their will power or intellegence to shape themselves directly. Rather they use their efforts to place themselves in the right environment. Surround yourself with those you wish to become. Work for people who can recognize and value your strengths. Great people are never great by themselves.
If you have the opportunity to find a job in a better place, then do so. You might feel guilty for leaving, especially if the people are nice and friendly, but if you're miserable, you're not going to be a very friendly person to those around you.
You'll also feel guilty about "not having tried enough to improve your company," but don't fall for that trap. People will resent you for making them change their lazy habits. Instead of praising you as their savior, they'll resent you and make jokes behind your back. Unless you have a lot of charisma, have a lot of company power, and those around you have decent potential, I wouldn't bother.
But before you jump ship, make sure you don't repeat the same mistake you've just made. You took your current job, for whatever reason, without carefully investigating how it's run. Don't settle for the PR speech the hiring manager gives you. Don't be blinded by their high stock price. Don't let them shuffle you quickly through the company tour. Find out who you'll be working directly with and talk to them. Start with a bit of friendly chit chat, but then move into shop talk. You'll quickly get a feel for whether people are on the ball or not. (Just try not to sound superior or a know it all).
Of course you can't simple ask, "Is this a good work enviroment? Are you people professionals?" Instead ask them, "Can I look at a non-sensitive piece of code? Can I see code written by another person too?" Do you see consistently good code among different coders? Do they have a coding standard? Do they even use revision control or does company's entire intellectual capital reside only on individual developer's computers? You can learn a lot without asking direct questions.
Life's way to short to spend someplace where your talents are wasted or unappreciated. I've wasted 6 years of my life doing that, and I don't plan on doing it any more.
Best of luck,
VP
P.S. To some people, this might sound like arrogance or a superiority complex. This is far from the truth. I have a TON of failings and shortcomings that I care not to think about, but I DO have a few strengths. I can either chose to place myself where my strengths aren't valued and my weaknesses are criticized, or I can place myself where my weaknesses are insignificant and my strengths are appreciated and reinforced by others. Arrogance is ignorance, and you can't be ignorant if you truely know yourself.
VP
Thursday, February 5, 2004
Thank you everyone. Someone asked me which language it was. Actually the variables are called v00001,v3342434 and things like that. There must be atleast 100,000 of these damned variables. Functios are called f3131235 and f4525435.
Actually, there is some damned "logic" that actually goes on here. If t435435 is a table name, then all variable names are called 435435xxx or something like that. Its a nightmare. They have some other code like if a variable name ends in 001, then it is the name of a city !. Is this not madness?. They developed this system over a period of several years.
I work in an internal IT shop.
I am feeling much better after reading your detailed advise. This is a great place!. I will seriously consider all of them.
Withheld
Thursday, February 5, 2004
In "The Pragmatic Programmer", one of their first suggestions is "no broken windows". The authors show studies that demonstrated when a building in an urban area gets a single broken window, the building goes into a complete state of disrepair quickly. Just a single broken window can have a large detrimental impact on a neighborhood.
They reason the same applies to code. One bad routine that you know is written poorly that nags at you will eventually suck your motiviation away and cause you to write worse code.
Whether one agrees or not, it is an interesting analogy.
Mark Hoffman
Thursday, February 5, 2004
Withheld, why do you spend so much time "surfing or lazing around"?
Whilst I sympathize with your predicament, I can only really suggest you stop whining, get off your lazy fat arse and do something about it.
There's probably a good reason the code is this way. Try and find out what it is.
I can see that your activities are really symptoms of poor motivation, but you might use the time constructively.
Whilst you're surfing, go and look at "Refactoring" and tools that will do this. Hint: you probably won't find a tool that works for you; you'll need to write one. Analyze the existing code and the language and write some routines that will automatically refactor the code for you, e.g. Transforming variable names, for a start. You can use the stuff in the database to help provide meaningful names.
Whatever you do, take a copy of the source and work on it, not the production code.
Worst case: you won't get anywhere with it, but it'll be a good learning experience and will bolster your resume. It will also be more interesting than (God forbid) actually doing the work you are paid to do.
Best case: you'll improve the quality of life and save your company thousands of dollars.
Also, go and read "who moved my cheese".
Justin
Thursday, February 5, 2004
> no broken windows
This was essentially the theory the head of the MTA (New York City Metropolitan Transit Authority) took in the early 80's. He started cracking down on the little things like fare beating and grafitti. He was criticized for not going after the important stuff - the muggings and general lawlessness of the subway system.
But this strategy worked for a few reasons. 1, most of the muggers were fare beaters so you caught them right there. 2, it sent a clear message that they weren't going to let their system slip, not even for grafitti.
I agree that commitment to a project has to be 100%, and you get 100% by being organized and consistent, and if you can't get this from the team, it may be time to move on, or see what you can do to change attitudes around your workplace.
Once you allow 99% to slip in, 98% isn't that far behind.
www.MarkTAW.com
Thursday, February 5, 2004
Why did you accept a job dealing with crap code?
The best developers can generally determine what a place and a job will be like from external factors, and they then refuse to work at mediocre places.
Good programmer
Thursday, February 5, 2004
Personally, I love being in this situation. Nothing motivates me more than facing a pile of someone else's crap with a big shovel. Why ? Because this is an *opportunity situation*. There is no excuse for letting your colleagues erode your natural talent. Just one suggestion: write a tool that looks in the database, matches the calls to their real functions and replaces all the names. It's not as easy as it sounds, sure, and don't change the live source until someone buys in. Start with a few examples and say to your boss/colleagues 'look, we can make this stuff so much easier to maintain'. You will save the company a fortune, save your own skills from being soiled by mediocrity, you have a big improvement project for your CV and all you have to loose is a few burned out colleagues which the company doesn't need anymore.
There are only two problems with this, but they are a big factor in poor quality organisations.
1) If you are the guy clearing up the crap, Corporate Idiot will assume that you created the crap in the first place. Unfortunately this is part of the burden of taking ownership. The upside is that Corporate Idiot has the memory of a goldfish. When the problem is gone, you will be the hero. For about 10 minutes.
2) When you start clearing up the crap, Bunker Man will be threatened. Bunker Man wrote this code and is The Expert. When threatened Bunker Man will start a campaign to discredit you. He will wine and dine colleages, probably open up a scathing website, let down your car tyres, lobby like an politics intern on a presidential campaign. The upside here is that at some point Bunker Man starts to look stupid if your stuff works, and all that energy that he has generated comes to you. Think of it as a kind of quickening.
Ian Sanders
Thursday, February 5, 2004
Good Programmer - *bad* companies don't show you the code before you sign the contract. In fact, I don't recall ever being shown real source in an interview unless it's a test.
Ian Sanders
Thursday, February 5, 2004
The question is like asking "Does getting hit in the head with blunt objects give you headaches?"
I would be seriously worried about any programmer that prefers working with bad code. Since it's well known that people are happier when doing tasks they like, and hence more motivated to complete them well, the answer should be obvious.
On the other hand, bad code can be fixed, bad (or non-existant) design is a hell of a lot harder. In my experience a lack of design (usually caused by a lack of a clear product direction) is a hell of a lot more demotivating than anything to do with the code.
Sum Dum Gai
Thursday, February 5, 2004
Hey, if the software is due for a new release, you could lobby for a code revamp and refactor the whole thing. Something like: We need to do x and y to meet specifications a and b. You'll need management backing to justify the kind of time you'll be spending on that. If this is a critical system, you may get some attention (of the good type).
Dude, truth be told people don't change. That can of worms was left to rot for so many years. I'm guessing this is not a company where IT is its main core biz. Be prepared to do most of the work yourself... I've seen that happen. Not a pretty sight. Even if you are a great developer, it would cost you both time and effort. Is it worth it?
anonymous2
Thursday, February 5, 2004
Oh, now I remember the other story I was gonna tell. Well, it's long and I'm not in the mood to type so I'll just Google it.
http://www.stsc.hill.af.mil/crosstalk/2000/02/backtalk.html
My friend told me this one in the context of corporate life, of course.
www.MarkTAW.com
Thursday, February 5, 2004
Are you sure you aren't looking at the output of a code generator?
Just me (Sir to you)
Thursday, February 5, 2004
No, what you do is use all that free time and energy to start your own company and develop your own software products - let these idiots subsidize your start up. Become a renegade entrepreneur.
Thursday, February 5, 2004
Ian,
There are a lot of bunker men who created it. But my main problem is i dont want to be blamed and lose my job if something goes wrong. Secondly, no one understands the whole system except the ones who wrote it - the bunkermen.
If someone wants to rewrite or change it, it will take years and a committeed management. It cannot be done by ordinary persons in spare time.
Withheld
Thursday, February 5, 2004
Hi Just me (Sir to you)
No, its not a code generator. Plain stupidity. Once they write forms, they copy them to the next one. So all forms look the same. Except that each one is a cut-paste job.
Example of the coding is
If w1223434 Then
SqlDoSomething(sSql,SqlHandle)
Else (if w213213 and w423424) or (w321233213 and w23123213) Then
SqlDoSomethingElse(sSql,SqlHandle)
There must be hundreds of thousands of lines of such code, developed by an army of men over several years.
Withheld
Thursday, February 5, 2004
I have not come across a **Single** comment in the entire code so far.
Withheld
Thursday, February 5, 2004
They must have run everything through a code obfuscator, then lost the original source code. So you're stuck with the obfuscated version.
NoName
Thursday, February 5, 2004
"i dont want to be blamed and lose my job if something goes wrong"
Wimp. Something WILL go wrong. Accept this future, and do something about it.
T.J.
Thursday, February 5, 2004
Quit now before you get blamed and fired for the mess.
T. Norman
Thursday, February 5, 2004
Withheld,
Be glad there are no comments in that mess. If there were comments, you'd be tempted to believe them, but they'd probably be wrong.
Chris Tavares
Thursday, February 5, 2004
Chris,
LOL :_D
I agree, no comments are better than mistaken ones.
"I don't know why it doesn't work. According to the documentation..."
VP
Thursday, February 5, 2004
Withheld,
I know what you mean. I have a similar background - outstanding academic results in an IT degree, nothing but praise and promotions from managers etc. And yet now I find myself in a situation that is incredibly demotivating. Like you, I spend far too much of my working day surfing the net etc, which is most unlike me.
I have a 3-fold plan. First, try to find another job. (Which can be easier said than done in the current job market in my city). If that fails, I'll try to persuade management to let me write a new piece of software to target an offshoot of our main market. It's a chance to do things "right" (on a smaller scale than our other products) and it should benefit both me and my employer. My backup plan, if all else fails, is to become self-employed and develop a few ideas that I've had over the years.
It's tough, but hopefully one of the above will work out.
I wish you well with your own situation, and hope you can find a way to improve it.
Regards,
Anon
Anon
Tuesday, February 10, 2004
Justin:
>>> There's probably a good reason the code is this way. Try and find out what it is.
Based on my experience, I think you're being way too optimistic. There's no excuse for the code being as described, and when code is bad it is usually just bad. And a lot of it is bad...
If I was OP, I'd probably go to them and say "This code is so bad I can't work with it. If you want stuff done to it, I can fix it; it will take x man-hours of work before I can start doing enhancements." Of course, you have to be willing to get fired for it, and let some other poor sap have to deal with the, uh, stuff.
There are worse things than getting fired for stating the truth. Getting fired after trying to do the impossible for a year, and getting blamed for the problems, is definitely one of them.
Adrian L. Flanagan
Wednesday, June 9, 2004
Recent Topics
Fog Creek Home
|