Live data from Hacker News

The worst program I ever worked on

jacquesmattheij.com

91–100 of 136 posts

Re: The worst program I ever worked on

#91

Call me Captain Obvious, but I feel like quite often the time spent in obfuscating code in many cases might be a major component of why programmers that do this sort of thing get fired in the first place. What goes on in someone's mind that says: "Maybe if I spend some time making my source code hard to understand I can better preserve my job." ? In reality all it does is slow them down, waste their time and lead to…

While this is true, there's a lot of space in between a model developer and a purposely-obfuscating twit. There's definitely a line that lazy developers can walk where they contribute just enough to make firing them more of a pain than putting up with them. I suppose the lesson for businesses is: be very careful about who you hire in the first place, because you may end up stuck with the person whether you like it or…

And there are a lot of subtle little ways in which a developer can drift into this state. For example, not bothering to document how systems work, or opting to make band-aid patches to brittle systems rather than refactoring. After a while of doing the easy/lazy thing, you're eventually lording over a complex black box that only you understand.

Some may find that a comfortable place to be. You become an expert; you have opportunities to be the hero. And it doesn't necessarily even happen via malicious intent. Sometimes you just don't have time to document or refactor anything, and you find yourself in a suboptimal local minimum. (Speaking from experience.)

Re: The worst program I ever worked on

#92
post #61

code from a 150 line long method which is part of a 6000 line class. Obviously I can't post the actual code on here (but what it is doing isn't important in this context). private XXXXXXXXXXX XXXXXXXXXXX(final XXXXXXXXXXX[] XXXXXXXXXXX, final int XXXXXXXXXXX, final Long XXXXXXXXXXX, final Long XXXXXXXXXXX, final int XXXXXXXXXXX, final Long XXXXXXXXXXX, final XXXXXXXXXXX XXXXXXXXXXX, final int XXXXXXXXXXX, final int X…

that code almost looks like it was generated by a wizard ( not the pointy hat/white beard kind) or some other nefarious RAD tool.

Re: The worst program I ever worked on

#93
post #61

code from a 150 line long method which is part of a 6000 line class. Obviously I can't post the actual code on here (but what it is doing isn't important in this context). private XXXXXXXXXXX XXXXXXXXXXX(final XXXXXXXXXXX[] XXXXXXXXXXX, final int XXXXXXXXXXX, final Long XXXXXXXXXXX, final Long XXXXXXXXXXX, final int XXXXXXXXXXX, final Long XXXXXXXXXXX, final XXXXXXXXXXX XXXXXXXXXXX, final int XXXXXXXXXXX, final int X…

For a second I thought you meant that all variable names were a varying number of X's, and I almost crapped myself.

Re: The worst program I ever worked on

#94
post #61

code from a 150 line long method which is part of a 6000 line class. Obviously I can't post the actual code on here (but what it is doing isn't important in this context). private XXXXXXXXXXX XXXXXXXXXXX(final XXXXXXXXXXX[] XXXXXXXXXXX, final int XXXXXXXXXXX, final Long XXXXXXXXXXX, final Long XXXXXXXXXXX, final int XXXXXXXXXXX, final Long XXXXXXXXXXX, final XXXXXXXXXXX XXXXXXXXXXX, final int XXXXXXXXXXX, final int X…

that code almost looks like it was generated by a wizard ( not the pointy hat/white beard kind) or some other nefarious RAD tool.

It wasn't!

Re: The worst program I ever worked on

#95
post #40

Earlier quoted context omitted.

Yes, i remember working for a company (java devs) where at some point we ended up having wrappers around wrappers around wrappers delegating stuff around, factories of factories ... It made your head spin.

Yes. APIDelegatorInvocationHandler and APIAbstractFactoryFactoryProvider. (actual Java class names)

When you said 'actual Java class name' I thought for a moment that those were actually classes in one of Java's libraries. I googled the names, though, and fortunately, they're not...

Re: The worst program I ever worked on

#96
post #80
post #40

Earlier quoted context omitted.

Yes, i remember working for a company (java devs) where at some point we ended up having wrappers around wrappers around wrappers delegating stuff around, factories of factories ... It made your head spin.

I mean this dead seriously: People complain about the abstractions like "Monad" in Haskell, but I'm yet to see anything as abstract and difficult to reason about as a decorator around a facade delegating to an implementation of a factory factory of something probably producing a concrete instance of some other pattern monstrosity.

Definitely, but a point should be made that design patterns themselves are not a bad thing, quite the contrary, actually. It's overuse of design patterns that should be a crime. I came across some pretty difficult to understand abstractions, but fortunately nothing like the monstrosity that you described.

Re: The worst program I ever worked on

#98
post #11

I worked with a guy (I won't name the company) who wrote Java code in one, huge, static class as much as possible. In fact, everything was largely in one function too. He decided to name his fields alphabetically. static int a static int b static String c static float d static int e... What, I wondered, would happen when he ran out of letters? Scrolling down further I saw this: static int aa static float ab static St…

That was actually standard Fortran practice, back in the day when variables were case-insensitive and could only have four characters. You haven't lived until you've ported some of the Fortran code aerospace companies have been running since the '50's.

Re: The worst program I ever worked on

#99
I worked with a guy a couple years ago who used the planets and nearby stars as a version numbering scheme. For example, the first revision of a file might be "Jupiter" and the second revision might have been called "Mars." (Of course, he didn't use the planets in their natural order)

He also refused to use real version control or even any kind of on network backup and insisted on using a Zip drive to back up all of the code he was working on. Needless to say, we had an intervention that involved hiding the Zip drive, and he quit in disgust shortly after.

Re: The worst program I ever worked on

#100

The only place where the names made any immediate sense was 'main' and any C stdlib calls. Any job worth doing is worth doing right. Contrariwise, any job worth fucking up is worth fucking up stupendously. He didn't go all the way. #define monkeymeat printf #define turtlescrotum malloc #define wolfnipplechips gets #define chipotlaway exit ...

I've seen

#define true false

Think they do it just for fun sake. Evil.

Post reply on HN