Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Are You Proud of Your Code?

Zonk posted more than 6 years ago | from the code-poets-speak-up dept.

Programming 682

An anonymous reader writes "I am downright embarrassed by the quality of my code. It is buggy, slow, fragile, and a nightmare to maintain. Do you feel the same way? If so, then what is holding you back from realizing your full potential? More importantly, what if anything are you planning to do about it? I enjoy programming and have from a young age (cut my teeth on BASIC on an Apple IIe). I have worked for companies large and small in a variety of languages and platforms. Sadly the one constant in my career is that I am assigned to projects that drift, seemingly aimlessly, from inception to a point where the client runs out of funding. Have any developers here successfully lobbied their company to stop or cut back on 'cowboy coding' and adopt best practices? Has anyone convinced their superiors that the customer isn't always right and saying no once in awhile is the best course of action?"

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered


Something to note about other people's opinions (5, Insightful)

suso (153703) | more than 6 years ago | (#21640631)

One thing to keep in mind when determining the quality of your code is that other people will most likely criticize the quality of your code. Usually saying that it sucks, when usually its just the person having their own way of doing things. I don't know why this is, I think its just human nature.

I've seen time and time again programmers taking over for other programmers' code and saying that the previous person's code sucks. Its like a right of passage or something.

Re:Something to note about other people's opinions (2)

DeeQ (1194763) | more than 6 years ago | (#21640695)

One thing to keep in mind when determining the quality of your code is that other people will most likely criticize the quality of your code. Usually saying that it sucks, when usually its just the person having their own way of doing things. I don't know why this is, I think its just human nature. I've seen time and time again programmers taking over for other programmers' code and saying that the previous person's code sucks. Its like a right of passage or something.

In most of my experiences its not their coding that sucks its their lack of comments or poor commenting that makes their code suck.

Re:Something to note about other people's opinions (5, Insightful)

JustinKSU (517405) | more than 6 years ago | (#21640705)

Codes is an expression of the programmer's though process. Everyone thinks in a different way. Invariably the last person's code will seem to suck because you have to think differently to understand it. Patterns were developed to create a common ground where people can think about problems in a similar way. Regardless of how pointless and off track a project might be you still should be able to design reusable concise code if you follow the right kind of patterns.

Re:Something to note about other people's opinions (5, Funny)

Anonymous Coward | more than 6 years ago | (#21640761)

I had this problem with a guy that was complaining that my code was full of GOTO statements, used all global variables, and didn't have any comments or subroutines. Bah, it worked so why should he bitch about it?

Re:Something to note about other people's opinions (5, Funny)

CmdrGravy (645153) | more than 6 years ago | (#21640941)

No wonder, that's a really old fashioned way of doing things. You need to get with the times and functional programming. Personally I do all my programming in functions, often I just need 1 or 2 big functions for a program if I make sure the functions all behave entirely differently depending on the values of the 30 or so parameters I pass to them. It's very efficient and yet still people moan !

CalcCallWaitingTime StripIllegalCharacters CreateInterfaceToACD DrawCalendarOutline may well be quite a long title ( often it's easier to acronymise them before I hand the code over ) but it's amazing the number of loops you can reuse if you have enough switches.

Re:Something to note about other people's opinions (5, Funny)

LiquidCoooled (634315) | more than 6 years ago | (#21641055)

I often find passing the function name itself as a parameter helps with loop re-use.
That way you only need to create a single do loop and allow your cx(...) sub (result passed back in the 14th argument unless the 3rd is "E" or above in which case its pushed onto the reference you passed as arg[19 + val(arg4)].

The last guy who tried to use the code was so awestruck with my genius he passed out!

Re:Something to note about other people's opinions (1)

aldousd666 (640240) | more than 6 years ago | (#21641077)

I thought you were funny. Apparently the mods didn't yet agree. I'll point back to the fake interview with Stroustrup about C++ [safe-t.net] in which the author , though not actually Stroustrup, aptly points out with his tongue firmly in cheek that nobody 'REALLY' reuses code. That's not to say they don't reuse patterns of code or anything, but actual non-stock library code is very infrequently re-used, at least in anywhere I've worked == you may get one official 'library' or 'package' that is passed around as 'the corporate API' but I have a feeling that people actually have a lot more than that in mind when they claim to be writing 'reusable code.' Which I'd say, at the end-programmer level, isn't all that common.

Re:Something to note about other people's opinions (5, Insightful)

Chatsubo (807023) | more than 6 years ago | (#21640803)

A lot of the time you find that, while someone is still employed, they do a good job of hiding their mistakes and covering up. It's when they leave that things start to go downhill because now suddenly, someone has to go read and understand their code. Then you realise it's a patchwork of quick fixes and bad design, and decide nice clean rewrite is in order.

At this point you try to justify the change to management, who will "schedule it for sometime next year", since this is not causing them any pain, only you get that priviledge. From that point on, you're stuck with someone else's bugs forever.

Now you're upset and become very vocal about the problems you now have to deal with.

There is a difference between "different" code that works, and bad code that routinely causes problems.

Usually the cracks show about a week or two after the guy leaves. And by cracks, I mean serious, client affecting shit.

Re:Something to note about other people's opinions (1)

morgan_greywolf (835522) | more than 6 years ago | (#21640843)

In addition, I'd have to say that, for me at least, I am my own worst critic. I take a look at code I write sometimes and think "gods, that's awful!" and then show it to another programmer who often thinks it's just fine. On the one hand, I have a tendency to over-comment rather than under-comment, so maybe the comments make my code easier to understand. OTOH, I often code in unorthodox ways. Sometimes it's just to get a little bit of extra performance (like taking advantage of the fact that most languages these days don't always evaluate every expression in a multiple-condition if statement) and sometimes I do it just for the clarity of the code. On the gripping hand, I have to say that sometimes I look at my code and go "wow, that's just lazy and sloppy."

Just because it looks bad to you doesn't mean that it is. It just means you don't feel like it's your best work and maybe it could be better.

Re:Something to note about other people's opinions (1)

CastrTroy (595695) | more than 6 years ago | (#21641135)

That's one thing that makes VB.Net really nice. They have AND/ANDALSO and OR/ORELSE keywords when working with conditionals. Using AND/OR will evaluate both sides of the expression even when not necessary, and ANDALSO/ORELSE will do a short circuit when possible. It makes the code really clear what it's doing, and lets you do interesting things like "if myObj is Nothing OrElse myObj.objProperty Then". You don't have to remember what it's going to do, because the keyword makes it explicit what's going to happen.

Re:Something to note about other people's opinions (4, Interesting)

jacquesm (154384) | more than 6 years ago | (#21640889)

style is one eternal point of contention (except for python programmers, but they're in a straight jacket), I don't think that it is a part of 'are you proud of your code', that has little to do with what other people think of your code, but everything about what you think of your own code.

When I look at my own code it's a mixed bag. The stuff that I earned the most money with is actually programmed quite bad, some of the most elegant stuff I wrote is sitting unused on the shelf.

I find that in a commercial setting I'm far more inclined to 'cut & paste' to keep moving rather than refactoring just to save the time. Sure, it leads to maintenance headaches down the line and I quite often just scrap stuff and rewrite it rather than figuring out what it did and why. Tools evolve at such a tremendous clip that I don't think the lifespan of code is anywhere near the point where it could be justified to spend say an extra week or two to get an algorithm tweaked to perfection if the next release of the tool or framework is going to have it built in anyway.

Faster machines also lead to sloppy code, I'm running a lot of production stuff on uncompiled PHP, whereas in the past I've rolled out code in assembler because I could beat the C compiler by a couple of cycles on most tight loops.

Times are changing, and that is the biggest 'driver' against 'clean' code, it won't be long before the actual code will start to disappear. For some environments that is already happening.

Oh well, old guys like me will find employment writing for embedded systems, which are about a decade behind the curve.

Re:Something to note about other people's opinions (4, Informative)

Atraxen (790188) | more than 6 years ago | (#21641091)

For the sake of the wider conversation, let me remind folks that there are still cases where (nearly) every cycle counts. One that comes to mind is is scientific computing (e.g. molecular modeling, !e.g. most analysis). So, if anyone's still missing "ye good 'ole days", there's still a need for 'Shakespearean' code...

Re:Something to note about other people's opinions (1)

rucs_hack (784150) | more than 6 years ago | (#21641129)

except for python programmers, but they're in a straight jacket

Ok, Python is very strict in terms of layout, but I wouldn't say it put users in a straightjacket. I'm predominantly a C coder, and I think Python is fantastic. I've started embedding it into my C programs so I can script stuff up to prototype it, then convert to C if required.

The freedom that introducing python scripting has provided is without equal in my experience.

Re:Something to note about other people's opinions (5, Interesting)

noidentity (188756) | more than 6 years ago | (#21640893)

Here are some pet peeves of mine involving dealing with other people's code. I don't think many of these are subjective either.

  • Header files you can't #include without getting errors because you didn't #include something it requires (but stupidly doesn't #include itself).
  • Lots of global variables that are read and written by several modules.
  • Header files lacking comments about what functions do.
  • Use of non-standard names for types with a fixed number of bits, instead of those from stdint.h/inttypes.h. So they have u16 or int16 instead of int16_t. Or really stupid stuff like uint instead of unsigned int (or just unsigned, which is equivalent).
  • Lack of const-correctness. Something like void print_string( char* str ); Huh, does it modify the string? No, then why does it take a pointer to non-const?
  • Unnecessary non-portability. Don't use #include unless #include isn't sufficient.
  • Internal things put in header files. If it's only used in the module, keep it in the module's source file only! Same goes for not making internal functions static, opening the possibility of clashes.
  • Files indented with two spaces instead of a tab, or even just one space. Fortunately this can be worked around with tools.
  • Unnecessarily space-taking comments about a function's visible behavior. Things with lines of stars around everything, etc.
  • Lack of structure tags, preventing forward declaration. Don't do typedef struct { ... } foo_t; do struct foo_t { }; and a typedef if necessary.
  • Macros for integral constants (yes, even in C), since enum does the job and obeys scope (yes, C has different scopes, not just C++).
  • Fundamentally, things that aren't highly modular and can be understood and used in isolation. I want to combine modules and have a minimum of complexity increase due to this combination.

Re:Something to note about other people's opinions (1)

FuzzyDaddy (584528) | more than 6 years ago | (#21641087)

That's a great list. I've done #4 myself, before I found out about inttypes.h, but I don't have the heart to go back and fix my old code.

Re:Something to note about other people's opinions (1)

ByOhTek (1181381) | more than 6 years ago | (#21641125)

most aren't subjective, but the first two quoted definetly are. To make the first non-subjective, change it to a combination of n-spaces and tabs... That's VERY annoying. As for the blocks of stars around a comment, certain patters of multi-lined comments (even with color coding in your editor) make them a lot more visible and recognizable as important, as well as make things look cleaner. It's definetly a personal and subjective preference. The third point - is there a good technical reason for that? I use defines (with very good names) a lot in my code. Who cares if it is LIBNAME_VALUE or LIBNAME_ENUM.VALUE?

  • Files indented with two spaces instead of a tab, or even just one space. Fortunately this can be worked around with tools.
  • Unnecessarily space-taking comments about a function's visible behavior. Things with lines of stars around everything, etc.
  • Macros for integral constants (yes, even in C), since enum does the job and obeys scope (yes, C has different scopes, not just C++).

Otherwise, in the following, do you mean things that are highly modular, not things that aren't? The point of high modularity is being able to test, use and even replace the modules independantly. (Note, not trying to be a grammar nazi here, I certainly have no room to talk in that regard, I just want to make sure I'm taking the right meaning out of thise note, or if it has a different meaning that I'm missing).

Fundamentally, things that aren't highly modular and can be understood and used in isolation. I want to combine modules and have a minimum of complexity increase due to this combination.

Re:Something to note about other people's opinions (1)

ByOhTek (1181381) | more than 6 years ago | (#21640911)

Well, it depends. I was helping someone out on an OSS project he had inherited, the original owners wanted to switch programming languages, blaming things on the original language. The guy I was helping had been the new guy on the team, he forked the project, keeping the original language.

Anyway, I could tell the new guys code from the original authors code - there's was messy and hard to follow, for no good reason. I re-wrote a component for him, and he found mine was challanging to follow (I actually wrote a full-fledge parser to handle part of it, and he'd never seen the code for one before), but in the end, he like it because it handled the takes in 1/100th the time of the original authors even less readable code, and 1/10th the time of his code while also being trivially extensible.

Personally, I could have made it faster, but I wanted to keep it flexible, and sensible to read, since others would work on it.

I guess what I'm saying is, part of code quality is personal style, as mentioned in other posts, part of it is the maturity of the person reading the code, and part of it is the quality of the person writing the code.

I've seen code that seems like good quality but doesn't fit my style (gtk, FreeBSD scheduler), good quality and does (qt, pvr250 driver module), and code that just scares me (the original author's code for the project I mentioned above).

My code runs the gamut as well. I have a few things I've put online that I feel are excellent examples of good code, my stuff at work is also good. I have one project that I've been working on at home for a while now, that I sadly need to rewrite because, while not buggy, it is still the slowest, most poorly written code I have ever seen. I'm ashamed that it is attached to my name, but it was certainly a learning experience I hope never sees the CPU of another person's computer.

Re:Something to note about other people's opinions (1)

RandoX (828285) | more than 6 years ago | (#21640933)

Great point. I had a team leader who griped about the quality of my code at my first job out of college. I took it pretty personally until I realized that he was just a pita who complained about the design and execution of everything everyone else wrote. Learned a good lesson that day. Thick skin, in one ear - out the other.

Same here (4, Insightful)

polar red (215081) | more than 6 years ago | (#21640663)

the problem is... the client doesn't always know what he wants, and the continuous changing of the specs (and hence of the code) make it a mess. It gets worse when near release some 'minor' changes have to be included and a lot of code has to be written in a very short time. There's a big difference between the theory of the 'waterfall-model'(and it's derivatives) and reality.

Re:Same here (0)

Anonymous Coward | more than 6 years ago | (#21640755)

sig grammar alert: "as if it were life itself," unless there is some irony / joke this AC is missing ...

Re:Same here (2, Insightful)

ByOhTek (1181381) | more than 6 years ago | (#21640979)

That, and "convincing the boss the customer isn't always right is a dumb and pointless thing for several reasons"

1) The bos probably already knows this is some respects, however...
1.a) Should the boss act on this knowledge, he or she will lose the customer, this is not profitable
1.b) The company could get a bad reputation of not following the customers requests, losing more potential customers
2) The customer, in the end, knows if the product is functional or not in their environment, better than you do. If you think otherwise, you need put your arrogance in check so that you can produce useful quality code.
3) The customer, in the interim, still knows their situations and setups better than you in most cases. While they may need to change requirements for overlooked circumstances and situations, that doesn't mean they don't know what is going on.
3.a) Pointing out that they have missed something isn't necessarily a bad idea though, if you do it in a respectful manner. This can actually improve their perception of the quality of your work.

The waterfall model (1)

Per Abrahamsen (1397) | more than 6 years ago | (#21641011)

Which is why the water-fall model is rarely a good match for software development.

And, incidentally, also while outsourcing (especially off-shore outsourcing) software development is rarely leading to success stories.

Re:Same here (0)

Anonymous Coward | more than 6 years ago | (#21641025)

The problem is, as your project's deadline approaches, then recedes, the "Waterfall Model" often becomes the "Yellow Cascades" model...

Re:Same here (1)

YeeHaW_Jelte (451855) | more than 6 years ago | (#21641127)

If you work with specs (in a hewn-in-stone way) you can expect them to change ... your code should reflect this and as flexible as possible so that it can change to absorb these changes in a decent way.

To achieve this, you should try to work in a modular fashion, splitting as many logical components as possible.

That said, there's always a change around the corner you didn't anticipate.

it keeps us employed... (1)

Dr_Art (937436) | more than 6 years ago | (#21640679)

I think quality in general has gone down over the years. In IT, I've seen that pushing quality is career limiting. There's definitely a lot of people making lots of money with the current state of things. I'd suggest you do what you can to improve your own code quality and soon you'll stand above the others.


This Should Explain It (1, Funny)

explosivejared (1186049) | more than 6 years ago | (#21640683)

If so, then what is holding you back from realizing your full potential?

This post [slashdot.org] should explain it. If you think hiring practices are discriminatory for minorities, try being like me!


Getting better. (4, Informative)

Ihlosi (895663) | more than 6 years ago | (#21640693)

It is buggy, slow, fragile, and a nightmare to maintain.

When looking back at my first project, I feel the same. But I also think that I've learned a lot from it, and all subsequent projects were much, much better.

So, by being "not proud" of your code, you've made the first step towards improving it.

Re:Getting better. (3, Informative)

RandoX (828285) | more than 6 years ago | (#21640837)

If you start coding from the beginning with the best possible methods, then congratulations. If you're like myself, and most of the rest of us, you're learning better ways to do things as you go. I know that I can't help but look back at older projects and think that there are better ways to do what I've done. Now I know better. Now I'll write things in a more efficient and maintainable way. I can only hope that in a few years I'll look back at the code I write this week and have an even better, cleaner, faster, and more maintainable way to do it.

mod parent up (0)

Anonymous Coward | more than 6 years ago | (#21640849)

realizing your old code is crap means you are improving. if you have less than 10 years experience with a language, chances are in 5 years you will think what you write now is crap too.

Re:mod parent up (1)

digitig (1056110) | more than 6 years ago | (#21641229)

realizing your old code is crap means you are improving. if you have less than 10 years experience with a language, chances are in 5 years you will think what you write now is crap too.
Agreed wholeheartedly. Now, there's probably nothing that a junior programmer can do to stop projects drifting (heck, even the gurus struggle with that!) and they probably don't have the influence to change the entire development culture, but they can do the Right Thing with their own code. Always consider in what circumstances it's legitimate for a piece of code to be invoked, and document it. Consider what it should do in other circumstances, and document it. Consider how it should react if it can't do what it's supposed to, and document it. Try to double guess which requirements are stable, and which are likely to change, and design to make likely changes easy. (I'm assuming here that the customer can't tell you anything useful about those things -- if they can then you can do better still). And when you get it wrong, think about why you got it wrong, and see whether you can learn how to do better next time. Just remember that getting it wrong doesn't just mean failing to anticipate changes, it includes over-engineering the code to account for changes that were never likely.

Re:Getting better. (1)

tompatman (936656) | more than 6 years ago | (#21640993)

I agree with this, and I code better now than I did a few years ago. But I still maintain the work I did as a contractor a few years ago and even if some sections are messy it is easy enough to understand and modify without rippling bugs throughout the system.

The code I am supporting now is often "Over organized". Several modules are created to accomplished simple tasks, several layers of functions have to be sifted through to get to the meat of what is going on, many of those functions being only a few lines long and there are MACROS galore, continuously renaming a function to something else.

In comparing the two, there's lessons I've learned about good coding practices, like consistency in naming things. But another thing I've learned is that creating a new function every few lines is not better for readability or maintainability and would gladly take my messy overstuffed functions any day.

My first project (0)

Anonymous Coward | more than 6 years ago | (#21641109)

When looking back at my first project, I feel the same.

When I look back at my first project, all I can say is no comments....

trying to do that were I am (0)

Anonymous Coward | more than 6 years ago | (#21640703)

I'm trying to do that where I am and there's resistance from the technical directory and team leader, though most of the rest of the company, including the managing director wants us to go the way of standards and best practices.

We write and support a financial application, it's poorly designed (which has lost us customers), buggy (which isn't good for any application let alone a financial one), written in several different languages and is slow and almost impossible to extend. Not surprisingly most of the site and supporting software were written by the technical directory and team leader.

It's not like I'm trying to introduce the world either, only good coding conversions, code review, sign off and tickets for faults/ enhancements, migrating things to one language and most importantly when we write something new don't repeat the mistakes of the past. All this seems impossible since there both too stubborn despite what everyone else says, it was a major headache just to get them doing something as simple as putting sensible comments into their checkins.

Obviously posting anon.

More Design (3, Informative)

Loophole64 (871990) | more than 6 years ago | (#21640709)

Often times you can avoid a lot of this headache by spending more time in design. If you can flush the project out in some detail during design, and include the customer, more of those changes will be included in the original design before you ever start to code. Unfortunately, others in your organization will often feel like design time is wasted time. You have to be steadfast in your will to spend time in the design phase.

Re:More Design (1)

Sgt.Modulus (1198753) | more than 6 years ago | (#21640833)

I know a few people who also feel that design is a wasted practice. I feel otherwise. I feel that design is the crucial phase in creating a program. Coding comes second when you put it all together. For me if I design a program I can see the larger picture of how it goes together. I have no job experience coding but thats what I think and I may be wrong. I think the exception to design time may be Creating smaller programs. Am I wrong?

Re:More Design (2, Insightful)

0xdeadbeef (28836) | more than 6 years ago | (#21640939)

Design time is wasted time. People don't know what they want, and they won't make meaningful decisions until they have something running in their hands.

Re:More Design (1)

bunratty (545641) | more than 6 years ago | (#21640969)

There are some projects I'd like to flush out, but in the end I usually concede and flesh them out.

Re:More Design (2, Interesting)

Oligonicella (659917) | more than 6 years ago | (#21641013)

No kidding! For Christ's sake, where have these sloppy writers been for the last forty years? It's not like quality coding techniques are anything new. Client interviews with textual/graphic feedback and an ongoing demonstration combined with clean code written for the next person who will look at it; been doing that since the afore mentioned Apple times as well.

The continuous feedback of easily understood information as to what the design is and where you are goes a long way to keep the client from becoming concerned and thinking it's a waste. It's actually a method for speeding things up towards a positive end.

You have to communicate (4, Insightful)

MosesJones (55544) | more than 6 years ago | (#21640711)

Getting good IT practices is about establishing a business professionalism in IT that is respected. This means that you have to explain to the business what "good" looks like, you have to understand the business drivers so you can put your challenges into that context and you have to talk to the business in terms it understands.

All too often IT folks bitch and moan about coding, testing, requirements, design time or whatever and how its all the fault of the business. This is victim mentality IT, the way to change it is to actually work out what "good" would be for the business and then work with them to deliver it.

This means the most important coding skill in successful IT departments is the ability to communicate.

Customers often WRONG (1)

pjt48108 (321212) | more than 6 years ago | (#21640717)

The customer is not always right.

Otherwise, it would be the other way around, and THEY would be serving YOU.

AS you might guess, I hated retail.

Re:Customers often WRONG (1, Insightful)

Anonymous Coward | more than 6 years ago | (#21641151)

The customer may not always be right but the customer is NEVER wrong - the privlege pf the paymaster

In the process right now. (1)

timmarhy (659436) | more than 6 years ago | (#21640729)

We've established naming conventions and guide lines everyone seems to be sticking to. the real test will be if they stick to it while i'm away on another project.

I think lack of direction and leadership is why projects drift. hence why many OSS projects have woeful code, because they are hobbies and lack a firm direction.

Sounds to me like... (-1, Troll)

Anonymous Coward | more than 6 years ago | (#21640731)

submitter is a loser. Welcome to slashdot buddy, make yourself at home, you're gonna fit right in.

Happy with mine (1, Funny)

Anonymous Coward | more than 6 years ago | (#21640733)

I'm happy with my code. It's beautiful, modular, fast, maintainable, portable and basic tasks take me only a few weeks.

thoughts (0)

Anonymous Coward | more than 6 years ago | (#21640767)

I'm also not particularly proud of my code, but to some extent I feel that I've been limited by the environment I've been placed. Where I've worked for the past few months, I've developed classes to move away from our four-year old database libraries, including database abstraction (instead of continuous reams of SQL), along with simple things like fixing SQL injection bugs (no, not saying who I work for). So while I'm proud of these little bits and pieces, I know that the large majority of the code base is still being developed in a fairly archaic way (and it's embarrassing), because the culture tends to ignore best practices - so I'm mostly developing better systems for myself. I'm leaving the company in a couple of weeks, heading home - and I know for a fact that most everything I've developed will simply slip away into the sands, because no-one has really paid any attention.

It's depressing. I think one of the only ways to keep your code fresh and maintainable is to have complete control over your code base - whether that be on a personal development level, or by having a good IT manger who's actually good at defining your class specs, along with pre and post conditions - and to completely remove customers from the equation, of course (even OSS falls under this banner, because you're not really obliged to keep anyone particularly happy).

The virtue of constraint, and other musings... (5, Insightful)

Max Romantschuk (132276) | more than 6 years ago | (#21640771)

I seem to find that trying to code more slowly than I could helps a lot. I'm not the most efficient coder there is, but I tend to produce less bugs and have more time to make better design decisions when I slow myself down.

I've had several jobs where I've found that although management never seems to approve of a slower process in itself, they do begin to see the values once they notice that my code tends to be less buggy than that of my peer programmers.

As for turning around bad practices... That's always hard. Culture is a tricky thing. But it helps to use analogies, lots of analogies! System grown too large with too many kludges? Compare to building a skyscraper on the foundations of a cottage. Management wants to speed up a project by senselessly adding more people? Compare to: "One woman can make one baby in nine months. Two women can make two babies in nine months, but two women can't make one baby in four and a half months..."

Be creative, be thorough, and be proud of your work. Always try to make the next iteration better, but also remember that sometime meeting the deadline is all that counts.

My two cents, I guess...

Re:The virtue of constraint, and other musings... (1)

envelope (317893) | more than 6 years ago | (#21640919)

meeting the deadline is all that counts.

That's pretty much all that counts where I work.

I have a lot of complaints with my own code, but I don't have time to fix much. There's always another project in the pipeline, and management doesn't understand the need for maintenance. The boss thinks that because he says "we do it right the first time", that that actually happens.

Re:The virtue of constraint, and other musings... (0, Offtopic)

rdrd (1142449) | more than 6 years ago | (#21640999)

You wrote:
"two women can't make one baby in four and a half months..."

Really? Solution: One will do an abortion at 4 1/2 mo, the other carries further the pregnancy.

So mod me down ...

Apples/Oranges (3, Insightful)

ilovegeorgebush (923173) | more than 6 years ago | (#21640773)

In programming, there are a million and one ways to do the same thing. There is no right or wrong, only good & bad. I've seen some damn shocking code over the past few years, and I've written my fair share too. It's swings and roundabouts, it's up to you to learn from your mistakes and push yourself as a programmer to better your code quality. Keep in mind that what you right is what people use, and it's the difference between "computers suck" and "hey, that was cool!".

And as the first reply said, someone will always criticise your code. Decent programmers know this and still do their best.

Worse Than Failure (2, Funny)

Rik Sweeney (471717) | more than 6 years ago | (#21640777)

No matter what I think of my code, I always know (pray) that it'll never be bad enough to be submitted to Worse Than Failure [thedailywtf.com].

That said, I do revisit code that I'd written a few years back and think "WTF were you thinking?!"

creators' planet/population rescue kode nearly... (-1, Offtopic)

Anonymous Coward | more than 6 years ago | (#21640787)

perfected. it only needs yOUR input to become the 'next big thing'.

the creators will prevail. as it has always been.

corepirate nazi execrable costs outweigh benefits
(Score:-)mynuts won, the king is a fink)
by ourselves on everyday 24/7

as there are no benefits, just more&more death/debt & disruption.

fortunately there's an 'army' of light bringers, coming yOUR way

do not be afraid/dismayed, it is the way it was meant to be.

the little ones/innocents must/will be protected.

after the big flash, ALL of yOUR imaginary 'borders' may blur a bit?

for each of the creators' innocents harmed (in any way), there is a debt that must/will be repaid by you/us, as the perpetrators/minions of unprecedented evile, will not be available.

all is not lost/forgotten/forgiven.

no need to fret (unless you're associated/joined at the hype with, unprecedented evile), it's all just a part of the creators' wwwildly popular, newclear powered, planet/population rescue initiative/mandate.

or, is it (literally) ground hog (as in dead meat) day, again? many of US are obviously not interested in/aware of how we appear (which is whoreabull) from the other side of the 'lens', or even from across the oceans.

vote with (what's left in) yOUR wallet. help bring an end to unprecedented evile's manifestation through yOUR owned felonious corepirate nazi glowbull warmongering execrable.

some of US should consider ourselves very fortunate to be among those scheduled to survive after the big flash/implementation of the creators' wwwildly popular planet/population rescue initiative/mandate.

it's right in the manual, 'world without end', etc....

as we all ?know?, change is inevitable, & denying/ignoring gravity, logic, morality, etc..., is only possible, on a temporary basis.

concern about the course of events that will occur should the life0cidal execrable fail to be intervened upon is in order.

'do not be dismayed' (also from the manual). however, it's ok/recommended, to not attempt to live under/accept, fauxking nazi felon greed/fear/ego based pr ?firm? scriptdead mindphuking hypenosys.

consult with/trust in yOUR creators. providing more than enough of everything for everyone (without any distracting/spiritdead personal gain motives), whilst badtolling unprecedented evile, using an unlimited supply of newclear power, since/until forever. see you there?

"If my people, which are called by my name, shall humble themselves, and pray, and seek my face, and turn from their wicked ways; then will I hear from heaven, and will forgive their sin, and will heal their land."

Unreasonable expectations (1)

RandoX (828285) | more than 6 years ago | (#21640789)

At my last job, the standard response to any request was "Sure, we'll do that, when do you need it?" and it "HAD" to be done whenever the arbitrary date given was. There was no reasonable estimations of time or scheduling given. The desired end product was a moving target, changing daily. Sadly, the department that was most frequently shorted on time was QA. It took as long as it took to write, and when we handed our best (rushed) efforts to QA there simply wasn't enough time for any regression testing. After several buggy releases, patches, and fixes, upper management outsourced the new version. They were in for a shock when every minor spec change required several weeks for reevaluation and extended the delivery date, plus added thousands to the price tag. When I left there they were starting to lay the groundwork to get some actual structure and communications in place. Hope that works out for them.

Always be proud of your code. (1)

SolitaryMan (538416) | more than 6 years ago | (#21640793)

I'd say that you should always be proud of your code and always do your best writing it. I don't mean that your code must be perfect -- nobody is perfect, but if under current time constraints, requirements and all other circumstances you can do better, then do it.

When evaluating your old code you should take circumstances into account to: may be you were in a hurry and "fast" was more important than "good" at the moment -- it's OK, it's a part of a job. Go back and refactor later. Besides, you are making progress as a programmer, aren't you? So, of course your old code may seem as "bad" and "dirty" -- it's OK too, It's just a part of being a *good* programmer and making progress.

Management (2, Informative)

Algorithmnast (1105517) | more than 6 years ago | (#21640801)

I know that with my own management, they're quite uninterested in quality - and entirely interested in the "schedule". They have a schedule, and want to meet it with our client (we're consultants) no matter what that does to our quality.

Of course, once the code is accepted by the client then by #definition it is good enough and changes to existing code are only possible if we can prove that the existing code is buggy.

Then there's the bizarre requirement that developers use copy/paste whenever possible. It's not as if we get paid by the line, but it seems that some of the senior architect types think that LOC matters. (no jokes please)

Add in management's desire to see as little change to things as possible, we get a very poor heurestic for Hill Climbing [wikipedia.org] as a model of our software development "practices".

Be proud of the work, not the code (4, Insightful)

PIPBoy3000 (619296) | more than 6 years ago | (#21640805)

I have a lot of applications that are elegant enough. It may not have perfect validation for every field and not all the GUI bells and whistles, but it does what it's supposed to. I know my share of developers that spend a ton of time making their code elegant and beautiful. In one case, the developer spent so much time making their N-tier application with huge numbers of tables that were normalized to the bajillionth degree that they were finally let go. The goal is to meet the need, not to fulfill some inner desire to create art with lines of code.

There is hope! (1, Insightful)

big ben bullet (771673) | more than 6 years ago | (#21640813)

Buzzword alert: Agile!

But seriously: Things like Test-Driven Development (TDD) and even Behavior-Driven Development have proven to be great approaches in software development.

Also, software management methodologies have evolved in a tight interaction between business (customer) and the development team. Take 'Scrum' for example... think 'iterative'.

If your superiors aren't convinced that at least the test driven part is necessary then you should seriously consider getting out of there.

You can still write crap code, but at least that crap code is backed up by a unit test. Otoh, if your test is crap... you _are_ the weakest link: Goodbye!

TIME! (3, Interesting)

microTodd (240390) | more than 6 years ago | (#21640827)

The answer to your question as to what is holding you back is complicated and multi-faceted. I'm sure you'll receive many interesting answers (and I look forward to reading them...hopefully it'll help me become a better coder).

From a pure Computer Sciency standpoint, remember that no code is ever completely bug-free...its mathematically impossible. Testing does not prove the absence of bugs, it only proves the presence of successful use/test cases.

But the number one thing holing me back is time. When I'm coding on the company's dollar, there's only so much time to spend in design, in writing test cases, in having someone peer review your code. And thus, there's just not enough time to spend doing things in the absolute, 100% correct way. There has to be some compromise.

I suspect that even if I had time, I would run out of mental energy first.

Re:TIME! (1)

msuarezalvarez (667058) | more than 6 years ago | (#21640917)

From a pure Computer Sciency standpoint, remember that no code is ever completely bug-free...its mathematically impossible. Testing does not prove the absence of bugs, it only proves the presence of successful use/test cases.

While that is of course true in an absolute way, for quite a few problem areas---including a big part of the standard programming problems an average programmer will encounter---one can produce verifiably bug free code, assuming you have proper specifications (up to bugs in compilers and such things, of course) Of course, that does not come free nor easily... And good luck getting proper specifications.

Re:TIME! (1)

Oligonicella (659917) | more than 6 years ago | (#21641119)

"...remember that no code is ever completely bug-free..."

What? I've seen and written plenty of code that was 100% bug free. Programming is not math. It uses math, but it's the same mistake of thinking math defines the world. Now, if you're talking about a system or large application, I'll buy in. But even there, you have to speak to the relative impact of the bug. I mean, in terms of pedantry, even a friggin' typo in a message is a bug.

Lost out (5, Funny)

gaou (1200987) | more than 6 years ago | (#21640829)

"It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration."
Edsger Dijkstra

Sorry mate, there is no hope :)

"Have any developers here successfully lobbied... (1)

Nursie (632944) | more than 6 years ago | (#21640847)

...their company to stop or cut back on 'cowboy coding' and adopt best practices?"

I didn't need to, I work for a competent company that aren't going to compromise the quality of their product on the whims of a single customer.

I also happen to think my code's great, thankyou very much. I couldn't imagine going through life thinking my code was awful. I'd lose the will to live and find another career.

Not enough time (1)

paranoid.android (71379) | more than 6 years ago | (#21640855)

"If so, then what is holding you back from realizing your full potential?"


I'm swamped with numerous projects. If I had the time, I'd go back and fix the kludgey spaghetti-code nightmares that I've conjured up, but since they work for their intended purposes, other projects that are more important to my management-types get priority.

Work for engineers not software companies (2, Interesting)

Hektor_Troy (262592) | more than 6 years ago | (#21640877)

The best code I've ever had the pleasure of working on, was made when I worked for an actual engineering company. Not software engineering, but engineers that build physical stuff.

They understand the need for excelent documentation, rock solid requirements and that you don't get halfway in a project and change its direction (ie, "sure, the Golden Gate is halfway done, but we'd actually like it to go from Lime Point and meet up with the Bay Bridge around Treasure Island Road"). They understand that some things take half the time to do but are four times as expensive to maintain, and they prefer quality over quantity.

Least the ones I worked with

Do some open-source coding to feel clean again. (4, Interesting)

Dr. Manhattan (29720) | more than 6 years ago | (#21640885)

Eric Raymond wrote, in "The Art of Unix Programming": "The combination of threads, remote-procedure-call interfaces, and heavyweight object-oriented design is especially dangerous... if you are ever invited onto a project that is supposed to feature all three, fleeing in terror might well be an appropriate reaction."

The product I work on at work features all three. It can be 'interesting' to maintain sometimes. That being said, it's frequently possible to rewrite sections and management sometimes listens to the programmer types and has let us restructure things sometimes. For example, we've mostly gotten rid of the RPC stuff.

When I want to satisfy my urge to work on good, clean code, I do some open-source work. Open-source tends to have that, because nothing else tends to work for very long.

Deadlines (1)

Martian_Kyo (1161137) | more than 6 years ago | (#21640891)

usually kill projects

The only thing i can advise, is have a small personal project aside. Yes program on your own (or join an interesting Open source project), when the project will be finished is not as important as using all the proper practices while doing it. That means flexible design, patterns, comments and such. Show yourself at home that given time, you can actually make good code.

Then maybe after a while some of those good habits will seep into your daily work. Very few companies will care about the code, they usually only care about the deadlines.

For me, good code is like good math (1)

AccUser (191555) | more than 6 years ago | (#21640895)

How often have you solved a mathematical problem, and the whole solution has looked and felt right, not just the answer? I have always enjoyed mathematics for this reason, and take the same approach in the way I write code. To me, my code just looks and feels right.

I realise that others don't feel the same about my code. I have often been criticised for not enough code documentation (but then, that usually means that someone can't understand code, rather than just not understanding my code), and I have often been criticised for not using temporary variables, but I am rarely criticised for delivering unmaintainable code that doesn't work.

Re:For me, good code is like good math (0)

Anonymous Coward | more than 6 years ago | (#21641079)

"but then, that usually means that someone can't understand code, rather than just not understanding my code"

Oh that's ok so. If it's been said to you 'often', they're probably right.

All Code Sucks... (2, Interesting)

iBod (534920) | more than 6 years ago | (#21640905)

...to somebody, for some reason.

There is no Holy Grail of code.

What is good coding style to me, may be anathema to you.

Ok, there is utterly shit code (which probably accounts for a fair proportion of all code if my life experience is anything to go by), then there is 'run of the mill' code, then sometimes rare glimpses of 'great' code.

Great code for me is when you see it and understand the programmers intention, and you think: a) I would have done it that way, or more likely b) if I was smarter I would have done it that way. You learn from great code, if you're already a good coder.

I think the greatest obstacle to 'great' code is 'language fascism'. Some languages are better than others, that's true, but they way some people carry on you'd think it was only possible to write 'great' code in their language of choice. This behavior is generally exhibited by those that can code in one (or at most two) languages only.

I'm generally proud of my code and am happy for others to scrutinize it. All that means is that I spent the time to make it as good as I could withing the prevailing time/cost constraints.

I used to write a lot of assembler. Some of my colleagues used to think it was cool to use obscure instructions, in unintended ways, just to show how 'cool' they were at flipping the registers. I never subscribed to this idea and always used 2 or 3 common instructions instead of one 'neat' instruction. Performance never seemed to suffer and maintenance programmers were eternally grateful.

Code is communication (4, Insightful)

Dystopian Rebel (714995) | more than 6 years ago | (#21640915)

After a long time in the software industry, I came to realize that Code Is Communication.

By far the largest part of the lifespan of any code is Maintenance. Code has to be intelligible. Not just through commenting, but in every construct and usage.

Think about effective communication. The effort to be clear will improve what you are doing. It will also make your mistakes evident so you can correct them.

Code is a killer (0)

Anonymous Coward | more than 6 years ago | (#21640925)

Code is the killer. The less if it you have the better off you are. You can reduce code by a good architecture and experience.

Bad code is usually a result of either inexperience or through a lack of time (rushed project timelines = bad hacks).

Recognising that you've produced some bad code is the first step to absolution. Try understand why you produced bad code and improve yourself. Rushed project timelines can force you to code badly however maybe you need to be more skilled/effective at a wider range of frameworks allowing you to do more in the time you are given.

Takes a group to judge an individual (4, Insightful)

eebra82 (907996) | more than 6 years ago | (#21640929)

Gather around me kids, for I am sitting here in my 18th century rocker to tell you a story about a programmer.. A good programmer..

I used to work for a small-sized IT business; a popular community that housed some 130,000 members. It began with the loss of a fellow employee who had basically coded 99% of everything on the site. To that date, everything had worked fine. We had some issues every now and then, but a backup system helped us from getting hammered if anything bad happened.

We never worried too much about him leaving because, for starters, I had some experience with the code/system. In addition, the now departed programmer had left a comprehensive list of features and explanations of his system that would help any programmer (that would replace him) to get around any tricky problems that would/could occur.

Unfortunately, I won't go into what type of business this was, but let's just say that it's not typical programming skills. When I began looking for his replacement, I realized how hard it was to get someone with adequate skills and all the knowhow that was required besides the actual programming. As we were on a tight budget, it was important for us to find that one guy who didn't expect a zillion dollar salary. Typically, that would be someone who shares our interests, a recent graduate who knows his ways around programming.

Eventually I found one guy who claimed to be all that we wanted. After a month, it turned out that the guy was more and more frustrated over how things worked at the company. He disliked about everything about the code and spent most of the time cursing. At this point, I started to believe that our entire code sucked.

Roughly a month later, we decided to rebuild "everything" so that he could have his ways around the code. Since we only had one programmer, I had to comply because it was an important role in the company. My limited coding skills provided no extra help in evaluating our current code, so I trusted this guy since he seemed to be very thorough and experienced. Also, I was promised it would take no longer than one month to do all this.

What a fool I was. If it ain't broken, don't fix it. I should have known, but a company on a tight budget and no one else with good programming skills forced us into this move. Turns out, our super experienced programmer needed not one month, but two, three, four, five, six and seven months to complete his task. By then, he had reprogrammed almost everything and merged some of it with the old code. We waited for the relaunch of our software with great anticipation. Three! Two! One! Go! Oh crap, everything f*cked up.

Following the launch of our new software, we had months and months of trial and error problems. Members were complaining and nothing went in the right direction. Eventually, we were essentially bankrupt and had to let the superb programmer go. The guy who had left us with a huge mess.

When I read this Slashdot story, I had a smile on my face because I learned that a programmer can only know that his code is perfect by the response of many other programmers who can view his code (i.e. open source). Some programmers seem to think their code is perfect and that occurring bugs are caused by impossible-to-foresee problems. The point of my story is that if you truly want to know if you are a good programmer, you must let a lot of programmers decide that for you. Unless your name starts with J and ends with ohn Carmack, of course.

It's not just the client (1)

Dr. Winston O'Boogie (196360) | more than 6 years ago | (#21640945)

If you have management that doesn't really understand what programming and programming personalities are all about, you can get internally inconsistent, half-thought out ideas as well as much pressure to do it 'now' instead of 'right'. If your programming team is more junior and easily swayed by the management's idea of software development, then there are no checks and balances and you get rushed out, low-quality code, with a never-ending cycle of quick patches that is ugly, bug-prone and a nightmare to maintain. And that's assuming you have a quality team of junior programmers. Mix in average or below-average programmers and......I shudder.

Yes, I am (1)

rdrd (1142449) | more than 6 years ago | (#21640947)

I work with/for some French guys. French people tend to have bright ideas in the most unpleasant moments (#include "irony.h"). Nevertheless, I was able to cope with the requests, and as a technical leader I was able to impose some of the solutions. The result is very neat, and I'm really proud of it.
I will say this: I am convinced that some better solutions exist for some specific problems; I do not agree with some of the imposed constraints. But: measure the quality having in mind time and cost.

So yes, there are nice projects outside.

TCO (2, Informative)

devnullkac (223246) | more than 6 years ago | (#21640949)

Saying "no" to the customer is not normally what's called for. Instead, your team must clearly state the total cost of any proposed change. Factoring maintainable quality into cost estimates is an art that an organization must learn if it wants to get asked to do another job after the money for this one runs out (project drift leads to no results leads to unhappy customers, as you well know). When the customer responds with "Well, isn't just as simple as changing X into Y?" then that's when you get to say "no."

Here's a start to better code (2, Insightful)

Man_Holmes (519973) | more than 6 years ago | (#21640959)

My advice would be to read The Pragmatic Programmer book by Hunt and Thomas. It provides the best blue print I have seen to solving the problem for you.

You may not be able to implement all the changes at once but you will find that you've got more authority than you realize.

You may not even agree with all of it, implement what makes sense and your code will improve. I've found with my friends that the longer you've been coding the more sense that the book makes.

Man Holmes

Unfortunately, yes. (1)

squiggleslash (241428) | more than 6 years ago | (#21640961)

Which means that I tend to get married to design decisions I made and have to deal with the inevitable consequences when what looks graceful programmatically is a nightmare when converted to a UI for the end user.

One of the interesting lessons I took from Mac OS X and GNOME, probably the two best mass market UIs on computers these days, is you can't always orientate your applications towards future expandability, because adding modularity and extendability frequently results in a poorer user experience.

Personal Best Prqctices (1)

aunchaki (94514) | more than 6 years ago | (#21640967)

> Have any developers here successfully lobbied their company to stop or cut back
> on 'cowboy coding' and adopt best practices?

For me, it was a matter of defining my own personal set of Best Practices and sticking to them. Something as simple as standardized variable naming, or consistent formatting. As _I_ set standards for myself, I shared them with fellow coders and we'd come up with an unofficial set of Best Practices. None of these things slowed my coding down or cost the client a cent, but they made all of my code more readable TO ME and helped me to cut-and-paste code (reuse, recycle!).

What's more, it made me feel like I was coding better than I did when I was in my anything-goes, cowboy days. And guess what? I _WAS_ coding better!!

Dude (1)

PoetDemise (1199205) | more than 6 years ago | (#21640995)

Guessing from your post, "I enjoy programming and have from a young age (cut my teeth on BASIC on an Apple IIe)." , I am going to assume you are a bit more seasoned as a programmer. Well, one the best things to do is to drop the old code. Java may have been around, but it keep up pretty well. If your code is slow, write cleaner code. Object oriented coding the best way to go. Keep methods short and clean but board and ensure to have overloaders. In today's day in age, code must be very dynamic, static methods are thing of the past. They are still very powerful and good tools but your code should not be based around them. Well I suppose I should get back to code and will do my best to keep my code nice and clean today.

Developers... Developers... Developers... (1)

mynickwastaken (690966) | more than 6 years ago | (#21641027)

It is buggy, slow, fragile, and a nightmare to maintain.

Dude! You work for Microsoft, isn't it?!

The difference - Testing (1)

mach1980 (1114097) | more than 6 years ago | (#21641031)

In our organization we went from spaghetti code to excellent code in under 24 months. The catalyst were the introduction of testers.

They validated our requirement lists and reviewed our system designs. As (us) software coders got the knowledge that their code were in for in-depth testing they started doing proper design work, peer programming and later module testing. Then, with the help of the test team, we started to maintain KPI:s about the process and got better delivery precision of the software.

As the number of bugs dropped we didn't need to patch-and-ship code. Now we release bi-yearly instead of bi-monthly which leaves even more time for QA-work.

Testers doesn't do quality - they are a catalyst to enable quality in each step in the software development process.

That's closed source programming (0)

Anonymous Coward | more than 6 years ago | (#21641053)

in a shoe box for you. Set deadlines. Always too few programmers. People who don't give a shit about anything except you get the product out and sold. That'd be your boss. Crappy code. Nice wrappings. And marketing department spends 4-7 times more funds than the actual programmers. But hey, don't worry, in a month or two, nobody remembers the project you worked on. And the sad code goes the way of all bits.

Code... (1)

CFBMoo1 (157453) | more than 6 years ago | (#21641061)

Two thins I can suggest:

* Keep things small, and by small I mean one procedure or function does one thing small. Don't pack it with extras or this or that. KISS it. Using a language without procedures or functions? Space things out and label blocks of code with comments. If you can break that code up in to seperate files with includes then do so. Test all the peices seperatly.

* Documentation, don't put a one liner up at the top of a block of code and call it a day. Be descriptive, say what happens, what comes from where, whats passed in and whats to be expected in the return. The more you spell it out for someone and yourself down the line the quicker the light bulb will go on when someone or yourself has to review what you did several months or years ago.

Yes, yes and yes (3, Insightful)

YeeHaW_Jelte (451855) | more than 6 years ago | (#21641067)

Yes, I am proud of my code, or maybe not always the code but at least my coding. It's not always possible to create beautiful, well mantainable code. I try to, but sometimes there's just not the time.

Yes, I have convinced my employer to stop allowing cowboy coding practices -- she didn't even realize it was happening. I'm currently head of the programming division of a inhouse IT dept for a large travelagency specialized in cruises ... it's a pretty large department for such a small company, as we write all our inhouse software ourselves and have been for the last 5 years. When I came to work here, the codebase was about that old -- 5 years -- and maybe a two dozen different 'cowboys' had been writing the software resulting in a large heap of steaming shit. They were not centrally coordinated and everyone of them was doing things in his own style either out of laziness of ignorance.

Anyhow, I managed to convince the CEO that there was a problem ... she had no idea that it was a mess, the company being a travel agency and she having very little knowledge of automation herself. I used a difficult coding project (connecting to a GDS, the guys that administer plane reservations, car rental, cruises etc) and a general optimation project ( the application was becoming very slow due to all the bad programming going on ) to build her confidence in me and asked her to put me in charge of code sanity. She did.

I am now trying to reform the bunch of code cowboys that currently works here to a well disciplined programming team ... and I hope I'm succeeding. Gave them code standards to work to, asked them to clean up the code base where they stumbled upon crappy pieces, moved from Visual Source Safe to Subverion (thank god!) and started regular meetings once a week.

The codebase is still very messy at places, but many basics (use of one and only one database class e.g.) have improved very much and I think the people here are happier for it. It's much less frustrating to work on nicely formatted code that doesn't have braindead sections that aren't commented.

To make a long story short, if you're not proud of the code you write, make sure you improve it.

after 8 years of professional coding... (4, Insightful)

w4rl5ck (531459) | more than 6 years ago | (#21641083)

I came to the conclusion that you are the only person who is ultimately responsible for the state of the code you write is YOU. Nothing else, no one else.

Project deadlines, crazy customers, chief engineers, thunderstorms, even a Tsumani. It's just you.


if you write buggy code, whatever the reason may be, it falls back to you. You will have to fix it, you will be MADE responsible for it. EVERY time. No one asks WHY you did it.

And you don't like it yourself, which is a bad thing. One should LOVE his work, not hate it.

If you force yourself to push everything else into a state that enables YOU to write good/nice/beautiful code, you will gain something. If not, you will suffer. That's about it. It has nothing to do with other people, with companies, with unemployment.

So, get up, and write that good code. Whatever it takes.

Good luck :)

Welcome to the real world (0)

Anonymous Coward | more than 6 years ago | (#21641099)

"Has anyone convinced their superiors that the customer isn't always right and saying no once in awhile is the best course of action?"

No. Welcome to the real world. Feature creep is unstoppable.

Yes. (0)

Anonymous Coward | more than 6 years ago | (#21641105)

At my work, we don't do cowboy coding. If we do, people will die. So, yes, we've said 'no' to customers and established best practices - long ago.

Quality Over Quantity (1)

wzinc (612701) | more than 6 years ago | (#21641121)

I've found that, no matter what they say, a customer would rather have a program with five features that work properly, than 50 features that are buggy.

I also agree with the guy that said slow down.

Change your paradigm (1)

mdmkolbe (944892) | more than 6 years ago | (#21641139)

Switch to a langauge like Haskell. It will seriously improve the quality of the code you produce even when you go back to your original language.

Stick It to the man (1)

creeves1982 (880009) | more than 6 years ago | (#21641143)

I find that it's really up to the programmer to come up with the "Best Practices" to coding. I personally hate it when I see code that has 25 nested IF statements. I remember back in High school, one of the other students named is variables X, XX, XXXX, moook, Y, YYY, etc. (it was like reading PERL for the first time.( moook = X + YYY * XX / Y). He was able to read and understand that block of code. Needless to say that I had to stay up late one night to finish the project because he was sick and the project was due the next day. What I learned from that experience is that no matter what every one is going to have there own standards of coding, If you are not happy with the way you coded something, take the time to decide what works for you and clean up the code.

anonymous reader writes (1)

sm62704 (957197) | more than 6 years ago | (#21641157)

An anonymous reader writes "I am downright embarrassed by the quality of my code. It is buggy, slow, fragile, and a nightmare to maintain."

Well look on the bright side, your employer is the largest software manufacurer in the world, whose OSes are installed on nearly every computer made, and they pay well. So what's the problem?

Besides, your sloppy code is doing me a favor. When I'm using your database and something breaks, I can blame you and everyone will agree it's your fault. Don't worry about it, all your fellow employees write bad code too.


Reserved error (-1517); there is no message for this error.

Engineering vs Programming (0)

Anonymous Coward | more than 6 years ago | (#21641165)

There is no incentive for programmers to produce code that they are 'proud' of.

The whole programming industry is based on shipping out mounds of steaming code that 'works' and 'meets the requirements'.

Programmers have no concerns about liability either, they can't be sued, or held accountable. There are 'metrics' used by some companies (# bugs, # lines/code/day), but these are just meaningless numbers. Anyone can produce 'bug-free' code, but will it meet the requirements, will it run fast?

If they don't build it right on the first iteration, simply try again in a service pack, or better yet, build 2.0, and charge users for the priviledge.

Software Engineers on the other hand, have a different problem. They can be sued, they can be held responsible, and more importantly, their whole education is based on the engineering principle of 'if I don't build this right, people could die...".

While the programmers education is based on how many lines of code they can 'produce' in a given timeframe.

another great source for code improvement (1)

ajaxlex (658555) | more than 6 years ago | (#21641185)

Code Complete - Steve McConnell - this highly regarded book discusses the nuts-and-bolts of software construction, and is a pleasure to read. I'm not familliar with another book that discusses software development at this level. Worth picking up (get the second ed).

I am content with most of *my* code (1)

mrjb (547783) | more than 6 years ago | (#21641197)

I'm content with most of the code that I write for myself, whereas code that I write professionally (read: on a deadline) more frequently leaves something to be desired. My own code is documented (manual+comments), usually quite efficient, and if there are bugs in there usually they are not very serious (forgotten null pointer checks). Of course, when dealing with my own code, I can refactor it as needed and as I please. At work, that's not always possible.

Proud of MY code? (-1, Offtopic)

Anonymous Coward | more than 6 years ago | (#21641225)

I'm proud of fixing YOUR code.

Pride fades with time (4, Interesting)

Opportunist (166417) | more than 6 years ago | (#21641227)

Generally, whenever I complete a set of code, it's perfect. It's flawless. It's the stunning pinnacle of coding, and it should go on some kind of display page where everyone can marvel at it, worship it and experience its perfection so they may find true enlightenment.

Usually, when I unearth the code 6 months later I wonder if there's any way to get this horrible piece of hacked crap out of the CVS somehow...

It's just that, well, you learn. You improve. Yes, even after more than a decade of coding, you still learn and improve. You learn new tricks, you learn to use new libraries, and you discover better and more efficient ways to use them by using them. So generally, yes, I'm proud of my code. For a while.
Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account