4 ms·

I hope I never have to work with someone like him. He sounds awful.

by billpg 4y ago

dcminter 4y ago
There is a saying "autres temps, autres moeurs" In a way I agree - someone programming like this right now without very good cause would be a bit of a nightmare if you ever had to tangle with their code. But it really was another world back then. They were so resource constrained [1]. That "drum" wasn't the hard disk, it was the memory! Think about waiting for the rotation of a drum for each instruction read. Then the actual capacity of it was only 4K. The laptop I am typing this on has about 32 million times more memory and I don't like to think how much faster it is. You either used clever tricks, or you wrote very limited programs. There was no room for any overhead. The author of that story wasn't astonished by clever tricks, just the degree of cleverness. [1] https://en.wikipedia.org/wiki/LGP-30#Specifications https://en.wikipedia.org/wiki/LGP-30#Specifications
- Suzuran 4y ago
  When adding 256 kilowords of memory to your PDP-10 cost $230,000 (2022 dollars) you were either clever or unemployed. If your programs couldn't run on the machine you had, they were no good. Nobody was going to spend a quarter million dollars on equipment for the sake of source code beautification.
- bstpierre 4y ago
  In 1998 I was bringing up a new MIPS-based board that had been designed in-house The CPU booted from an EEPROM and started running code. There was an FPGA on the board that controlled the memory. The FPGA needed to be loaded with a bit-stream that was also on the EEPROM. The trick was that I had to write a program to load the FPGA without referencing any memory -- I only had ROM and the CPU registers. Fortunately the MIPS had quite a few registers, but I had to abuse all the register-use conventions and the code jumped through some hoops in order to be able to get the FPGA loaded so we could start running from RAM. There was all kinds of crazy stuff that was weird with that hardware that we had to fix in software... I didn't realize until switching jobs exactly how weird things were, I just thought it was normal.
billpg 4y ago
Some things never change. One of my first HN comments got me four down-votes for much the same comment. https://news.ycombinator.com/item?id=679208 https://news.ycombinator.com/item?id=679208 Back then, I was so new it bumped me down into negative score. I almost made a new account but decided to keep it and try and rebuild my damaged rep. Nowadays, my score in the thousands, but Mel still sounds awful.
- Suzuran 4y ago
  I'd be interested to know exactly why; Is it because he doesn't obey his bosses when told to make the program cheat, or just the way it's framed as some kind of testosterone caveman thing?
  - metabagel 4y ago
    Obviously difficult to work with and unprofessional. Utilized programming side effects which obscured the intent of the code to such an extent that he unintentionally reversed the logic of the test he was supposed to implement.
    - Suzuran 4y ago
      Abuse of side effects to save code is just a reality of working in limited or embedded systems once you have run into their limits. On one of my current projects, the target has only 8K of program memory. I had to do some things I'm not proud of to get the required functionality to fit because the alternative was to say "It can't be done, scrap everything." The target is an embedded hard-realtime processor core, so there's no way to add more memory to it. It's a component integrated into a larger system so I can't demand a larger or more capable device without incurring significant redesign costs. Quite frankly, I won't be considered worth those costs. Nobody's doing to take on the expense and effort simply because I can't hack it. I'd have a hard time blaming someone for doing the painful to keep a project alive, considering I'm doing exactly that. We can always agitate for better conditions next time around, but this time we must go to war with the army we have, and sometimes that necessitates fighting dirty. The rest of the stuff is entirely valid though. A programmer that cannot be managed is worthless, and someone who is unwilling to accept correction is a liability. I wouldn't refuse to work with him because unless I'm his superior I don't get to make that call, but I would probably go out of my way to avoid interaction. (And if I were his superior, unless he's got political juice or something, I'd have him shown to the door if he won't work with the team instead of against it.)
toss1 4y ago
EDIT: OP made a response indicating that his objection to Mel was that he left zero documentation. To this, I agree 100% !! Leaving no documentation is doing your future self a huge disservice (even a few weeks from now it'll be helpful if you've left yourself some good breadcrumbs to follow), and is pretty much a hostile act towards the team. ----- initial comment ----- Sure, if he's doing that kind of highly idiosyncratic stuff in the modern software & hardware environment, he'd be a hindrance to any team. But this was not that situation, and sadly, this comment reveals a deep cluelessness about the technology underlying the computing industry. The article shows a real genius at work, fully understanding that what he is doing is programming a computing machine, and using every available advantage to get to to yield a program that performs well. Sadly, software now is optimized entirely for the convenience of the developer, and with literally billions to trillions of multiples of the computing power available to Mel, most software today is utter crap, taking tens of seconds to even load because it barely floats in an ocean of bloated abstraction and 'frameworks'. The fact that you cannot at even recognize the obvious genius in that story indicates that you should really learn a lot more and seriously rethink your approach to computing. Learn how the hardware and software actually work. Work hard to strip out unnecessary dependencies, middleware, frameworks, etc., and make your applications snappy. With today's hardware, there is literally no excuse for software that does not respond faster than any human perception. But sadly, today, if you can make it work that way, you'll be the exception — so be that exception.
- Suzuran 4y ago
  Please read his response of about 30 minutes ago, it's a few replies up. It's not what you think.
  - toss1 4y ago
    Oh, thanks for the alert! Indeed not at all what it first seemed. edited (original had sat in writing for a while then submitted later w/o reacing new context comments)
MatthiasPortzel 4y ago
Obviously, not documenting things and writing the most clever code possible makes it difficult for other people to read your code, there’s no doubt about that. And the story acknowledges that. It’s clear that Mel is a very clever programmer but probably a pain to work with. But your comment is just so dismissive of the point of the story, Mel’s cleverness. It comes across like you saying “This person sounds awful because they’re smarter than me.” I can assume that’s not what you’re trying to say, but that’s what it sounds like. If you wrote a more nuanced comment acknowledging that, e.g. ‘while I would love the opportunity to learn from someone like that, I’m glad I don’t have to work with them or maintain their code.’ I would be more inclined to see your comment as contributing to the discussion.
- metabagel 4y ago
  “This person sounds awful because they’re smarter than me.” I didn't read the comment that way, but then I share the opinion that Mel seems like a difficult person to work with or to manage. Wrote obscure code and apparently failed to document any of it. Took glee when said code worked the opposite of requested. The guy who took over seems to have had to waste countless hours trying to de-obfuscate the code in order to reverse the logic of the test. I appreciate the cleverness, but there are some red flags here. Also, I got the impression that some of the cleverness was for its own sake, rather than out of necessity.
deleted 4y ago
[deleted]

I hope I never have to work with someone like him. He sounds awful.

by billpg 4y ago

I hope I never have to work with someone like him. He sounds awful.

There is a saying "autres temps, autres moeurs" In a way I agree - someone programming like this right now without very good cause would be a bit of a nightmare if you ever had to tangle with their code. But it really was another world back then. They were so resource constrained [1]. That "drum" wasn't the hard disk, it was the memory! Think about waiting for the rotation of a drum for each instruction read. Then the actual capacity of it was only 4K. The laptop I am typing this on has about 32 million times more memory and I don't like to think how much faster it is. You either used clever tricks, or you wrote very limited programs. There was no room for any overhead. The author of that story wasn't astonished by clever tricks, just the degree of cleverness. [1] https://en.wikipedia.org/wiki/LGP-30#Specifications https://en.wikipedia.org/wiki/LGP-30#Specifications

Suzuran 4y ago
When adding 256 kilowords of memory to your PDP-10 cost $230,000 (2022 dollars) you were either clever or unemployed. If your programs couldn't run on the machine you had, they were no good. Nobody was going to spend a quarter million dollars on equipment for the sake of source code beautification.
bstpierre 4y ago
In 1998 I was bringing up a new MIPS-based board that had been designed in-house The CPU booted from an EEPROM and started running code. There was an FPGA on the board that controlled the memory. The FPGA needed to be loaded with a bit-stream that was also on the EEPROM. The trick was that I had to write a program to load the FPGA without referencing any memory -- I only had ROM and the CPU registers. Fortunately the MIPS had quite a few registers, but I had to abuse all the register-use conventions and the code jumped through some hoops in order to be able to get the FPGA loaded so we could start running from RAM. There was all kinds of crazy stuff that was weird with that hardware that we had to fix in software... I didn't realize until switching jobs exactly how weird things were, I just thought it was normal.

billpg 4y ago

Some things never change. One of my first HN comments got me four down-votes for much the same comment. https://news.ycombinator.com/item?id=679208 https://news.ycombinator.com/item?id=679208 Back then, I was so new it bumped me down into negative score. I almost made a new account but decided to keep it and try and rebuild my damaged rep. Nowadays, my score in the thousands, but Mel still sounds awful.

Suzuran 4y ago
I'd be interested to know exactly why; Is it because he doesn't obey his bosses when told to make the program cheat, or just the way it's framed as some kind of testosterone caveman thing?
- metabagel 4y ago
  Obviously difficult to work with and unprofessional. Utilized programming side effects which obscured the intent of the code to such an extent that he unintentionally reversed the logic of the test he was supposed to implement.
  - Suzuran 4y ago
    Abuse of side effects to save code is just a reality of working in limited or embedded systems once you have run into their limits. On one of my current projects, the target has only 8K of program memory. I had to do some things I'm not proud of to get the required functionality to fit because the alternative was to say "It can't be done, scrap everything." The target is an embedded hard-realtime processor core, so there's no way to add more memory to it. It's a component integrated into a larger system so I can't demand a larger or more capable device without incurring significant redesign costs. Quite frankly, I won't be considered worth those costs. Nobody's doing to take on the expense and effort simply because I can't hack it. I'd have a hard time blaming someone for doing the painful to keep a project alive, considering I'm doing exactly that. We can always agitate for better conditions next time around, but this time we must go to war with the army we have, and sometimes that necessitates fighting dirty. The rest of the stuff is entirely valid though. A programmer that cannot be managed is worthless, and someone who is unwilling to accept correction is a liability. I wouldn't refuse to work with him because unless I'm his superior I don't get to make that call, but I would probably go out of my way to avoid interaction. (And if I were his superior, unless he's got political juice or something, I'd have him shown to the door if he won't work with the team instead of against it.)

toss1 4y ago

EDIT: OP made a response indicating that his objection to Mel was that he left zero documentation. To this, I agree 100% !! Leaving no documentation is doing your future self a huge disservice (even a few weeks from now it'll be helpful if you've left yourself some good breadcrumbs to follow), and is pretty much a hostile act towards the team. ----- initial comment ----- Sure, if he's doing that kind of highly idiosyncratic stuff in the modern software & hardware environment, he'd be a hindrance to any team. But this was not that situation, and sadly, this comment reveals a deep cluelessness about the technology underlying the computing industry. The article shows a real genius at work, fully understanding that what he is doing is programming a computing machine, and using every available advantage to get to to yield a program that performs well. Sadly, software now is optimized entirely for the convenience of the developer, and with literally billions to trillions of multiples of the computing power available to Mel, most software today is utter crap, taking tens of seconds to even load because it barely floats in an ocean of bloated abstraction and 'frameworks'. The fact that you cannot at even recognize the obvious genius in that story indicates that you should really learn a lot more and seriously rethink your approach to computing. Learn how the hardware and software actually work. Work hard to strip out unnecessary dependencies, middleware, frameworks, etc., and make your applications snappy. With today's hardware, there is literally no excuse for software that does not respond faster than any human perception. But sadly, today, if you can make it work that way, you'll be the exception — so be that exception.

Suzuran 4y ago
Please read his response of about 30 minutes ago, it's a few replies up. It's not what you think.
- toss1 4y ago
  Oh, thanks for the alert! Indeed not at all what it first seemed. edited (original had sat in writing for a while then submitted later w/o reacing new context comments)

MatthiasPortzel 4y ago

Obviously, not documenting things and writing the most clever code possible makes it difficult for other people to read your code, there’s no doubt about that. And the story acknowledges that. It’s clear that Mel is a very clever programmer but probably a pain to work with. But your comment is just so dismissive of the point of the story, Mel’s cleverness. It comes across like you saying “This person sounds awful because they’re smarter than me.” I can assume that’s not what you’re trying to say, but that’s what it sounds like. If you wrote a more nuanced comment acknowledging that, e.g. ‘while I would love the opportunity to learn from someone like that, I’m glad I don’t have to work with them or maintain their code.’ I would be more inclined to see your comment as contributing to the discussion.

metabagel 4y ago
“This person sounds awful because they’re smarter than me.” I didn't read the comment that way, but then I share the opinion that Mel seems like a difficult person to work with or to manage. Wrote obscure code and apparently failed to document any of it. Took glee when said code worked the opposite of requested. The guy who took over seems to have had to waste countless hours trying to de-obfuscate the code in order to reverse the logic of the test. I appreciate the cleverness, but there are some red flags here. Also, I got the impression that some of the cleverness was for its own sake, rather than out of necessity.

deleted 4y ago

[deleted]