31 replies to this topic

[Gorf]

I like to write my code from scratch. I dont mind using another piece of code to get my head around
something but I tend to write my own code from scratch. It's much more satisfying. In the case of
the Jaguar I do use the start up code they supplied as it works quite well and keeps things safe.
However, outside of recommended hardware set ups, I much rather roll my own. That is not to say I
dont do a bit of cut and paste where necesary or more practical. Then again, there is no GPU main
code RAM execution libraries out ther yet....until I possibly release mine. IF only Jagmod would
finish the 3D renderer or if I got off my lazy arse and wrote one myself.

[DracIsBack]

jaybird3rd, on Mon Oct 5, 2009 6:14 PM, said:

I agree. I tend to be very concerned about elegance and maintainability as well, but too often, other factors make it necessary to compromise in these areas.

I once remembering a very interesting conversation. We were working on a consumer product in a highly competitive space. The development and user experience teams leaned towards "make it elegant, make it beautiful, perfect it in every way." They'd also become gunshy due to a release that hadn't worked out well. The product typically released annually, but the team had come back with a proposal to take five years to write the product. They wanted to add massive amounts of new functionality, rewrite and re-factor into perfection, test to the nth degree, do multiple public betas for feedback etc. etc. They went into a long song and dance about why we needed to go this way from a technical perspective and how nothing less than five years would suffice.

The business guys listened politely and then when they were done, gave one simple response: "that sounds like a great plan, but if we took more than 18 months to release this product, every retailer would drop us, every partner would cease doing business with us, revenue would evaporate, the company will die and we'll all be out of work by year two of five.

I think there have to be compromises in business that someone doing as a labor of love can get away with.


Nothing inspires me more than an engineer who treats their work with the eloquence, creativity, passion and finesse of a famous painter. But there are business constraints that have to be remembered and do sometimes force what is not perfection.

[beoran]

Well said, Herbarius, I agree balance is key!

Though I agree with Joel that C++ should be avoided.

[bfutrel]

I try not to be a duct-tape programmer, hopefully writing my code to make sense and liberally adding comments to explain what things do. There have been instances where I have had to go back through my code 3 or 4 years later to correct something and those comments were a lifesaver!

There have also been moments where I look through code written by someone who used to work with me and my first thought was what the heck!

[Random Terrain]

bfutrel, on Fri Aug 13, 2010 10:04 AM, said:

. . . and liberally adding comments to explain what things do. There have been instances where I have had to go back through my code 3 or 4 years later to correct something and those comments were a lifesaver!

I wish I was better at that. It's hard to explain what I did when I don't know what I did. I have no idea what I'm doing. I just keep messing around until it works. If you don't know how or why it works, how do you explain it?

[theloon]

Random Terrain, on Fri Aug 13, 2010 11:11 AM, said:

bfutrel, on Fri Aug 13, 2010 10:04 AM, said:

. . . and liberally adding comments to explain what things do. There have been instances where I have had to go back through my code 3 or 4 years later to correct something and those comments were a lifesaver!

I wish I was better at that. It's hard to explain what I did when I don't know what I did. I have no idea what I'm doing. I just keep messing around until it works. If you don't know how or why it works, how do you explain it?

You can't I remember coding a 4 way scrolling engine in QuickBASIC as a teen. Plain old MODE 13 in QB didn't have a backbuffer. I changed the palette around so that half the colors were black and then XOR'ed the playable area to the top-left hand side of the screen.
It was slow. It wasted screen real estate. And a month later I had no clue as to how I did it!

Coding, writing and drawing are all things I do as I go. It's been a real challenge to remember comments and detailing how my functions work.

[hex65000]

I'm mostly a "brute force" programmer for the most part. I've worked on some big projects where I realized quickly that there needed to be building blocks to handle the interfacing. You could use them in a stand alone format or roll them into a bigger program. Mind you, that was a high level language. (LabView)

I also have this dichotomy of that I like to work in either Labview or Assembly. As one of my friends would say "Stitch THAT Trebeck!"

When I do Assembly, I try to break it up into reasonable sized modules, at the same time I try to avoid doing anything fancy and try to stick with consolidating where it's obvious I should or where I'm probably wasting more resources in making a subroutine tree too many layers deep and should just do a copy-paste of the offending code chunks. I am not an 'elegant' programmer. I'm more interested in getting the program to work and the hardware to 'talk'. If the time/money/motivation is there, I can always revisit it and try to streamline the process. It makes sense to me, because I'm not a computer science guy.

As for documentation, I tell this to students when they first start programming and it paraphrases from the Church of the SubGenius: "Don't just document your code when you're learning a language, document the HELL out of it!" Because, it's no fun looking at ASM code that you wrote a year ago and you find yourself going: "What the hell does this do and what does it touch?" I still do that, but I've trained myself to be pretty verbose in my comments that it's not horrible to get beck up to speed on what a module is doing. And when you're first learning a language/architecture those comments help reinforce what you are learning by essentially repeating to yourself what it is that your code is doing.

Just my thoughts...

Hex.
[ Dreads his upcoming programming challenge... ]