After wasting most of the last few days on stupid little configuration issues, I have come to the conclusion that programmers in general are either lazy ("it worked for me"), or just too damn clever for their own good ("this is the most perfect solution"). Not to say I have not fallen into one of these traps myself, but you would think a peer reviewed, group designed software project would manage to have one member who was not pumping out the same shit as everyone else.
Is a little documentation so hard? And no, your random-ass 'clever' code is not self documenting if it takes me an hour to puzzle out how you are using some edge condition of a register to accomplish your smug programming challenge.
Gah.
Quoteyou would think a peer reviewed, group designed software project would manage to have one member who was not pumping out the same shit as everyone else.
I took tech support calls from Microsoft's programmers when i was with them. It is *worse* not better in big organizations.
Quote from: cavehamster on January 20, 2010, 05:22:01 AM
Is a little documentation so hard? And no, your random-ass 'clever' code is not self documenting if it takes me an hour to puzzle out how you are using some edge condition of a register to accomplish your smug programming challenge.
Gah.
Lack of documentation is the new job security. If you're the only one who understands how your code works, they can't fire you, can they?
Remington,
Hoarding knowledge in case he ever needs it.
Quote from: Remington on January 20, 2010, 06:02:47 AM
Quote from: cavehamster on January 20, 2010, 05:22:01 AM
Is a little documentation so hard? And no, your random-ass 'clever' code is not self documenting if it takes me an hour to puzzle out how you are using some edge condition of a register to accomplish your smug programming challenge.
Gah.
Lack of documentation is the new job security. If you're the only one who understands how your code works, they can't fire you, can they?
Remington,
Hoarding knowledge in case he ever needs it.
This is true. I've made money by being the only one knowing what is going on before. But it still makes me angry when I'm on the other side of it, trying to support some braindead design.
Quote from: cavehamster on January 20, 2010, 06:28:10 AM
Quote from: Remington on January 20, 2010, 06:02:47 AM
Quote from: cavehamster on January 20, 2010, 05:22:01 AM
Is a little documentation so hard? And no, your random-ass 'clever' code is not self documenting if it takes me an hour to puzzle out how you are using some edge condition of a register to accomplish your smug programming challenge.
Gah.
Lack of documentation is the new job security. If you're the only one who understands how your code works, they can't fire you, can they?
Remington,
Hoarding knowledge in case he ever needs it.
This is true. I've made money by being the only one knowing what is going on before. But it still makes me angry when I'm on the other side of it, trying to support some braindead design.
I guarantee you that that programmer has a fully commented, extensively documented version of the source code on his home computer. For his own personal reference, of course.
Rather than try to crack the 512-bit AES encryption it's no doubt secured with, I suggest taking a metal pipe and dragging him into a switching closet when no-one's looking.
He will talk.
Quote from: Remington on January 20, 2010, 06:45:10 AM
Quote from: cavehamster on January 20, 2010, 06:28:10 AM
Quote from: Remington on January 20, 2010, 06:02:47 AM
Quote from: cavehamster on January 20, 2010, 05:22:01 AM
Is a little documentation so hard? And no, your random-ass 'clever' code is not self documenting if it takes me an hour to puzzle out how you are using some edge condition of a register to accomplish your smug programming challenge.
Gah.
Lack of documentation is the new job security. If you're the only one who understands how your code works, they can't fire you, can they?
Remington,
Hoarding knowledge in case he ever needs it.
This is true. I've made money by being the only one knowing what is going on before. But it still makes me angry when I'm on the other side of it, trying to support some braindead design.
I guarantee you that that programmer has a fully commented, extensively documented version of the source code on his home computer. For his own personal reference, of course.
Rather than try to crack the 512-bit AES encryption it's no doubt secured with, I suggest taking a metal pipe and dragging him into a switching closet when no-one's looking.
He will talk.
Hawt! I like where this is going.
Yeah, I thought I'd try my hand at learning how to crack crypto, then I learned about rubber hose cryptography.
(http://www.cgisecurity.com/images/security.png)
Quote from: Remington on January 20, 2010, 06:52:54 AM
(http://www.cgisecurity.com/images/security.png)
I'm sure this is pretty close to the truth.
Are you a bit drunk?
Quote from: Horrendous Foreign Love Stoat on January 20, 2010, 08:10:44 AM
do better yourself then.
or stop fucking bitching init.
have you progged a better and more working interface than they have? no have you fuck. so stfu. have you decided to take time out to write a better and more worthy faw/design notes? no have you fuck. stfu again.
either:
a. program a better version than your companies paied proggers and make it good and STFU
or b
STFU
yeah?
altho its better to patheticaly moan about something that you could not for a fact do better at yeah? amirite?
I dunno, I kinda liked the short version better before you edited it and added the rest. It was short and to the point, unlike the temper tantrum you've crafted here.
Bonus points for the effort, though!
Quote from: Horrendous Foreign Love Stoat on January 20, 2010, 08:27:32 AM
also., this just in:
WOOOOOOOOOOOOOOooooooooooooOOOOOOOOOOOoooooooooooooOOOOOOOOOOOOooooooooooooooo.
Whatcha been drinking?
Quote from: Horrendous Foreign Love Stoat on January 20, 2010, 08:31:30 AM
brandy cannabis tincture and coke. and larger. also WOOOOOOOOooooooooooooooooooooooooooooooooooooooooooooooo :D
A nice way to chase a Tuesday out, I think. Looks like you could use a refill...
Quote from: Remington on January 20, 2010, 06:02:47 AM
Quote from: cavehamster on January 20, 2010, 05:22:01 AM
Is a little documentation so hard? And no, your random-ass 'clever' code is not self documenting if it takes me an hour to puzzle out how you are using some edge condition of a register to accomplish your smug programming challenge.
Gah.
Lack of documentation is the new job security. If you're the only one who understands how your code works, they can't fire you, can they?
Remington,
Hoarding knowledge in case he ever needs it.
There is nothing new about this. AT&T basically STARTED their computer business with a million lines of undocumented spaghetti code.
Spaghetti is the only way to code. Start off with only a very basic outline of what you want to do and then try to write it, no diagrams, nothing. By the time you get to version 3 you'll have the neatest, most well documented source the world has ever seen. V1 & 2 will beat that shit into you. :D
Cavehamster, five bucks says the original programmer doesn't know how it works either.
The Enki school of programming: write the thing off the top of your head in an all-nighter without checking the reference manual. In a week, try to compile it and start debugging. By the end of the month, you should have something that you can understand -- or something that looks like the output of /dev/urandom.
Quote from: Enki v. 2.0 on January 20, 2010, 08:01:32 PM
Cavehamster, five bucks says the original programmer doesn't know how it works either.
The Enki school of programming: write the thing off the top of your head in an all-nighter without checking the reference manual. In a week, try to compile it and start debugging. By the end of the month, you should have something that you can understand -- or something that looks like the output of /dev/urandom.
Mostly, I have been working on integrating some systems. I plan on having data reside on a iSCSI server. I've setup the server, the client, setup redundant links, setup multipathing, and everything is humming along.
However, what no one posts about, is what happens when all the redundant links fail. I lost a day testing and verifying until I resolved what happens and how to handle it gracefully.
And then I discovered the damn boot scripts try to connect to the iSCSI server everytime a network interface comes up, and it's not until the last one comes up that it actually connects, so... 7 minute wait time to get the system ready. I finally poked around long enough to resolve that.
Only to hit another issue... and another... and... gah. I have the subsystem up and running now, and am getting closer to actually getting work done, but it still irks me that it's been this annoying.
Quote from: cavehamster on January 20, 2010, 08:10:31 PM
Quote from: Enki v. 2.0 on January 20, 2010, 08:01:32 PM
Cavehamster, five bucks says the original programmer doesn't know how it works either.
The Enki school of programming: write the thing off the top of your head in an all-nighter without checking the reference manual. In a week, try to compile it and start debugging. By the end of the month, you should have something that you can understand -- or something that looks like the output of /dev/urandom.
Mostly, I have been working on integrating some systems. I plan on having data reside on a iSCSI server. I've setup the server, the client, setup redundant links, setup multipathing, and everything is humming along.
However, what no one posts about, is what happens when all the redundant links fail. I lost a day testing and verifying until I resolved what happens and how to handle it gracefully.
And then I discovered the damn boot scripts try to connect to the iSCSI server everytime a network interface comes up, and it's not until the last one comes up that it actually connects, so... 7 minute wait time to get the system ready. I finally poked around long enough to resolve that.
Only to hit another issue... and another... and... gah. I have the subsystem up and running now, and am getting closer to actually getting work done, but it still irks me that it's been this annoying.
Have you gotten the debugging boner yet? Because, if this doesn't do it, you might want to try something a bit harder -- like OS dev, or writing a C compiler without using BNF.
Quote from: Enki v. 2.0 on January 20, 2010, 08:13:14 PM
Quote from: cavehamster on January 20, 2010, 08:10:31 PM
Quote from: Enki v. 2.0 on January 20, 2010, 08:01:32 PM
Cavehamster, five bucks says the original programmer doesn't know how it works either.
The Enki school of programming: write the thing off the top of your head in an all-nighter without checking the reference manual. In a week, try to compile it and start debugging. By the end of the month, you should have something that you can understand -- or something that looks like the output of /dev/urandom.
Mostly, I have been working on integrating some systems. I plan on having data reside on a iSCSI server. I've setup the server, the client, setup redundant links, setup multipathing, and everything is humming along.
However, what no one posts about, is what happens when all the redundant links fail. I lost a day testing and verifying until I resolved what happens and how to handle it gracefully.
And then I discovered the damn boot scripts try to connect to the iSCSI server everytime a network interface comes up, and it's not until the last one comes up that it actually connects, so... 7 minute wait time to get the system ready. I finally poked around long enough to resolve that.
Only to hit another issue... and another... and... gah. I have the subsystem up and running now, and am getting closer to actually getting work done, but it still irks me that it's been this annoying.
Have you gotten the debugging boner yet? Because, if this doesn't do it, you might want to try something a bit harder -- like OS dev, or writing a C compiler without using BNF.
I develop for microcontrollers a lot. That does it for me, debugging on a device that might have a LED connected to tell you if things are working right or not...
Ooh, so you eschew emulators and binary debuggers like a real man? Nice :fap:
Quote from: cavehamster on January 20, 2010, 07:55:11 AM
Quote from: Remington on January 20, 2010, 06:52:54 AM
(http://www.cgisecurity.com/images/security.png)
I'm sure this is pretty close to the truth.
Trucrypt has come up with a solution for this which involves hidden encrypted partitions on the disk (the primary one protected by Password A, the secret one hidden by Password B). So you give the attacker password A and it unlocks the drive with the "data"... which is not the same as the data you actually care about (hidden behind B). Since there's no way to verify or determine if there is one or two partitions, the arttacker will not know that you have a second password.
Of course, I never use this and if anyone beats me with a wrench I will give them the right password... I promise....
Mmm, wrenches... :fap:
Well, personal preferences aside, there are far more irritating ways to be fucked over by undocumented code. I was the first person to write a working OS in D (the digitalmars D, not the various other languages with that name). It required excising about half the standard library, and rewriting 3/4ths of the remainder from scratch. That was about 80% of the project (which, by the way, had a file system, a curseslike gui, support for ram disks/hard drives/hard drive partitions, and its own executable format).
Quote from: Enki v. 2.0 on January 20, 2010, 08:51:28 PM
Mmm, wrenches... :fap:
Well, personal preferences aside, there are far more irritating ways to be fucked over by undocumented code. I was the first person to write a working OS in D (the digitalmars D, not the various other languages with that name). It required excising about half the standard library, and rewriting 3/4ths of the remainder from scratch. That was about 80% of the project (which, by the way, had a file system, a curseslike gui, support for ram disks/hard drives/hard drive partitions, and its own executable format).
You know you are having a bad day when you start hitting compiler bugs. I had o e a few weeks ago, turned out to be a lighty fried CPU that would segfault when compiling, but not when running the OS, go figure.
Alternatively, hire a bunch of Asian programmers.
Quote from: NotPublished on January 20, 2010, 09:20:18 PM
Alternatively, hire a bunch of Asian programmers.
Or use rentacoder. It's the same thing, except that they are mostly Indian and it's cheaper.
Quote from: Enki v. 2.0 on January 21, 2010, 12:45:55 AM
Quote from: NotPublished on January 20, 2010, 09:20:18 PM
Alternatively, hire a bunch of Asian programmers.
Or use rentacoder. It's the same thing, except that they are mostly Indian and it's cheaper.
When I was freelancing, I looked at rentacoder. Holy cow, how does anyone make any money at all as a coder there?
I've still yet to see any quality code coming out of India. I'm sure those guys are just as bright, but the constant hammer of doing it cheaper, faster is not helping anything. It seems like to me if you send a project to India, you can be expected to take twice the time to fix it when it comes back. Kind of like if you send stuff to be built in China, you can expect them to go ahead and build a run of knock-offs while they are at it to sell on the black market.
Out of curiosity, just how much was an Indian rentacoder?
Quote from: Requia ☣ on January 21, 2010, 01:17:40 AM
Out of curiosity, just how much was an Indian rentacoder?
It's been so long I don't have numbers, but over and over I saw jobs that would take me a solid 20-30 hours of work, someone would be bidding less than $100 for.
ugh, my boss hired some programmers in China to make a Crawler, worst choice ever; it was definantly something - and it crawled. He didn't want to burden me though, I thought it was nice.
Quote from: cavehamster on January 21, 2010, 01:21:05 AM
Quote from: Requia ☣ on January 21, 2010, 01:17:40 AM
Out of curiosity, just how much was an Indian rentacoder?
It's been so long I don't have numbers, but over and over I saw jobs that would take me a solid 20-30 hours of work, someone would be bidding less than $100 for.
Hrm, I suppose it depends on how much of that they get, and how hard it is to be full time. Median wage in India is only 1200-1600 (depending on city) so 3-4 dollars an hour would be pretty significant.