Slashdot Mirror

I had an aunt that regularly tried to get me to come to her firm to code in MUMPS.

I wonder why I never did it.

Haven't you heard? Frames are the solution to every technical problem that you will have in the future. After all, frames securely mediate, by design. Secure multi-mediation is the future of all webbing.

> Culling 80% of programmers would leave us better off, assuming there was a magical way to sort good and bad.

How about FizzBuzz?

Let's see.. things that won't be digitized anytime soon: - gym card

Thumbprint, perhaps?

I've heard of this before... Ah ha! It was The Daily WTF

"Making an employee happy, improving the efficiency of a company these are hard problems that affect corporations"

Bullshit. This will be used to preemptively fire employees, and deny them unemployment claims based on "they were going to quit anyhow."

The worst part is that it is a fact of life for companies. Happy or not, people quit jobs. Sometimes its out of everyone's hands. Sometimes a person does not want to quit, but due to economics there is no upward mobility for the employee, forcing them to seek another job. Having proper succession plans and not alienating past employees is the key here. The companies gain nothing by being dicks here, but shitty managers will try to screw over outgoing employees, even when the company policy is to do nothing.

My favorite is the promise of "lots lots more money" when I put in my notice. Hey, if you wanted me to stick around, you should have either paid me more before i was quitting, or at least treated me like a human being. Both would be better, but lets not be unrealistic.

Alex Papadimoulis at The Daily WTF summed it up nicely in an article about having alumni instead of ex-employees. Perfectly succinct analysis from someone that has been in the industry. And the mentality change it would take will never happen in a company bigger than a few dozen people.

What on earth could you possibly have against M??? A Case of the MUMPS

Here is a great mumps tutorial for those of you that aren't familiar & for those of you who only know "modern" languages, it's a timely Halloween horror show...

The Daily WTF features a few MUMPs, uh... code. A shorthand overview and a collection of MUMPS articles. If it wasn't so specialized and used in so few areas, they'd probably have to institute a "no MUMPS stories" policy to avoid being flooded.

What keeps someone at a job that might pay less than he could get for hopping?

1. Individual job satisfaction? (Yeah, laugh! That's a big part of the industry's problem! Proof: http://thedailywtf.com/ :-)
2. Co-workers, the company, the location
3. Benefits and incentives to remain

I guess as a Boomer, these might be old fart attitudes. But at least for many of the people I've worked with, they're significant considerations. Salary alone has rarely been the primary reason engineers change jobs. That's well-documented, here's one reference that tries to summarize the research: http://blogs.hbr.org/2013/04/d...

http://forums.thedailywtf.com/...

http://thedailywtf.com/Article...

http://forums.thedailywtf.com/...

http://thedailywtf.com/Article...

http://www.thedailywtf.com/ - Curious perversions in information technology

The original definition from The Daily WTF

The Inner-Platform Effect is a result of designing a system to be so customizable that it ends becoming a poor replica of the platform it was designed with. This "customization" of this dynamic inner-platform becomes so complicated that only a programmer (and not the end user) is able to modify it.

Clearly this is NOT an inner platform for creating a browser. It's an IDE for making websites or an "app".

I've never listened to anyone who's attempted to teach me anything in this industry.

Wow! I'd hire you on the spot if I could. I'm off to check out some of your code.

If open source is so great, this flaw couldn't have been around this long, would it?

Are you just trolling, or have you never worked on a large closed source codebase? Believe me, there's a lot worse than this out there, in both open and closed source. Read the daily wtf to learn what it's like in the real world of corporate IT.

Regardless of the "openness" of the sources, the real differences in software quality rest in the organizations that build code; the typical US corporation is pretty much guaranteed to produce far worse software than the typical hobbyist group. Unmotivated wage slaves ruled by a technologically incompetent hereditary elite .vs. geeky people who are doing something purely for the love of it? Pfft. Not much of a contest! The biggest change successful tech companies like 3com and Apple brought was a new generation of leaders, who came from outside the traditional boardroom social class. Jobs was a phreak, Metcalfe was a hacker. Today the communities that exist outside the corporate closed-source programming culture have created all the most powerful software tools we have - including Microsoft Windows, which uses tons of Berkeley code, and the NSA's tools, which are often based on linux or openBSD, and all your communications technologies like smart phones and wireless mesh networks etc.

Anyway, let me paraphrase your own complaint: If closed source is so great, why doesn't it come with a free pony? Ponies are cool.

Clickers who clicked your link also liked clicking this link.

Real world business software developers just don't talk that way.

"Real world business software developers" are those whose code ends up on The Daily WTF.

But seriously, welcome to the future. In the 1960s, "real world business software developers" thought that all this "object" stuff was a bunch of academic gobbeldygook at worst, or niche tool for people doing scientific simulations at best, rather than anything that would be useful with their hard-nosed COBOL. And in a sense, they were right. How would it help you speed up the overnight bank transaction updates? It probably wouldn't.

This "academic rambling" probably won't help you write your business software today, but it just might help you avoid becoming obsolete tomorrow. Thankfully, you probably won't need to learn it until tomorrow.

Or, you could just continue doing what people do today: tape it back on. Total expense, tenth of a cent. Total time spent, 15 seconds.

That sounds familiar...

You're supposed to have both "Developers who do Ops" and "Ops guys who develop" in one team to do "DevOps"

Si the idea is to take good (hopefully) programmers and make then into mediocre (at best) operation guys, and take the operation guys and make them into mediocre (at best) developers?

Somehow that doesn't really sound like a good idea to me. Wouldn't it be better if you have good developers doing development, and good operation guys doing operation stuff?

I don't know about operations, but we all seen what happens when mediocre developers are let loose on a code-base.

The WTF part of this (the kind that thedailywtf.com lives on) is that the RFC, which he co-authored, has this strong and specific warning:

If the payload_length of a received HeartbeatMessage is too large, the received HeartbeatMessage MUST be discarded silently.

He knew about the risk. He documented the risk. But come coding time, he forgot the risk.

Ya gotta feel for that. How many times have I gotten up bleeding and dazed and said to myself "I knew that was a bad idea."

Exactly. See this site for more information on enterprise-level quality :-)

this site exists for a reason

Have you ever tried to actually visualize a data model that is from a real-world application, where you soon find that you need to draw hundreds of arrows all across the model? The technique that works well and gives you a really nice view for, say, a simple blog application or whatever the current tutorial app beyond "hello world" is, breaks down horrible when you're dealing with real-world complexity.

Here's a link to a few nice real world examples.

The only way to get this rolled back will be to elevate this outside of comments in Slashdot, which obviously do not have visibility to Dice. Try submitting it as a story to The Daily WTF. I would suggest framing it as an example of how a community-driven website can be killed by (a) not listening to community feedback and (b) mishandling a rollout.

Maybe if we can get some outside coverage, Dice will reconsider.

Seems like an insightful analysis. No real surprise, given the ever present desire corporations have to increase profits. And increasing *profit* from slashdot while maintaining or increasing quality for the current user base would be hard. I would like to see it - the quality around here could really use a boost. But I think a Dilbertesque attempt at sacking the name for short term gains is more likely, possibly followed by a sale of the mangled corpse. Maybe we will read about it on The Daily WTF, assuming they don't suffer the same fate.

... Their current base will migrate away to more geek-friendly websites ...

So, any recommendations? I am yet to find anything that does a good job filling the gap of what slashdot should be.

Some non-replacements, but still worthwhile sites I have found:

* Electoral Vote is a great source for what is happening in US national campaigns. At least, it is when he has something to say (And I don't blame him for not always having something to say - his page must be a tough hobby as is)

* Tikalon is a cool science blog. I recently found it linked from a slashdot comment, and need to read more of it.

* Politico looks like it is worth a look if you want more US politics, but lacks the tech focus of slashdot.

So, where should the lifeboats head as they flee like rats from a sinking slashdot?

I'm getting cynical in my age I guess, but the majority of the claims people make are simply fluff to try and make a buck or name. Claiming that we need a new language for a special case is silly. Develop and release a library(or libraries) for your needs so that people can use it. Otherwise we end up with all these little tufts of crap that 3 people in the world use, and have to listen to them complain about why adoption is so low.

I can say this because your cynicism plays directly into my game. The new paradigm is Meta Programming. With my new Meta Programming tools I can write code in one single language and compile it into any other language that has an open source parser. My style guide language ensures the output code is consistent with whatever project I need produce code for. You are both the perfect candidate for, and also most likely not to learn such a language / platform.

That is why the creation of new languages and paradigms are needed for optimal competition. You see, the more divided they are, the more easily I can conquer them with my one language to rule them all. Yes, the little used obscure or languages can be leveraged. I can add that specialization to my capability feature-set with ease. As my library of meta code has grown I can now tackle even very large projects with very few programmers on the job, deployment is a bigger concern than (re)programming now. I can undercut nearly any bid with a far higher quality of output than my competitors -- And do it again and again on virtually any platform.

I once thought as you, and then I realized I could not stem the flood of wheel reinvention without reinventing the wheel myself. You wouldn't put a wagon wheel on a sports car... I sought to end this madness once and for all, but soon I would realize that I must not for fear of even greater madness. Humanity is not ready for this powerful technology. It will wait to be released until after I retire from the competitive market. You may think me greedy, but I am not. You just haven't seen the horror of a library including all manner of design patterns as utilized in Java or C/C++ compiled into SQL triggers with a single external main() function interfacing the DB query. I recoiled in horror at my first glimpse of at this Thing-that-Should-Not-Be, even as I allowed the birth of ever more monstrous abominations: An entire Trouble Ticket system running atop Apple Script. Excel spreadsheets hosting systems diagnostic tools. JavaScript crashing browsers running AI meant for Prolog.

I sat in perverse fascination as Ruby on Rails destroyed an entire Intranet to produce a glacial slide show of spinning tetrahedron via distributed 3D software rasterizer. No! Cluster fscks of epic proportions flashed before my eyes, and it was soon clear that you do not have the technology to defend against such terrible beasts. I mused, "Well, surely none would do such things in real world applications", but I knew I was wrong before my search began. Do you understand the Danger that approaches?! Have you seen ASM.js?!

With great power comes great responsibility. For once someone will decide that just because we can doesn't mean we should. If true Meta Programming is unleashed before the world is ready the blood won't be on my hands. For a queer little project an aged experienced dev can learn a new language or methodology in a matter of days, then it's only the API ref you'll require, as always. Before you thumb your nose at domain specific special-case languages consider the alternative approach and be grateful it does not yet have you in its clutches.

One Final Word: Debugger.

Paula Bean?

http://thedailywtf.com/Articles/The_Brillant_Paula_Bean.aspx

The Neural Network that creates prose!

The pig go.
Go is to the fountain.
The pig put foot. Grunt.
Foot in what? ketchup.

The dove fly.
Fly is in sky.
The dove drop something.
The something on the pig.

The pig disgusting. The pig rattle.
Rattle with dove.
The dove angry.
The pig leave.

The dove produce.
Produce is chicken wing.
With wing bark.
No Quack.

1) Maintain consistency with your peers when writing the same software together.
2) Communicating with peers
3) Not making assumptions
4) Not telling me about ad-hoc design/schema changes
5) Estimates
6) Consistency in quality assurance procedures

However it appears that with oversight, training and having the work delegated into manageable quanta, all these problems go away.
A lot of it was caused by the heroic one programmer/one product/no design or requirements model.
Or "FAD": http://thedailywtf.com/Articles/FrontAhead-Design.aspx :)

If I had to choose one word as What's Hardest and Most Important?

"Consistency"

sort of. .NET is good simply because of Visual Studio and intellisense and all the other "make it easy" features they have - features I'm sure they could have added to other languages.

But .NET is missing loads of stuff, the last one I found was the lack of a graph or tree container, a dictionary just doesn't cut it. Oh, and I keep using Single() in my EF LINQ calls.. which doesn't support it, even though its a method on IEnumerable... lovely that, an interface that supports some methods some of the time.

So no, the API is not a good thing as it constrains you into using it and the bigger the API the more people think they have to use it, and only it. Other languages do much better in this regard, by letting you add in libraries for various functionality as you need it, so if I needed a tree container, there would be one, or more, standard libs available for me to fetch and pull in. Then my library of libraries would be filled with whatever was needed today - not what was hot 5 years ago when that API was thought up.

The Daily WTF.

Their Error'd series is chock full'o this kind of failage.

The only risk is that someone's already submitted a screenie of any given inappopriate BSOD, but the only way to know is to try. Or read it through first.

The Daily WTF.

Their Error'd series is chock full'o this kind of failage.

The only risk is that someone's already submitted a screenie of any given inappopriate BSOD, but the only way to know is to try. Or read it through first.

... still think SVN is where it is at.

SVN is needlessly complicated. I favor the Source Control Shingle.

You are missing the third category, the "Brillant" people. http://thedailywtf.com/Articles/The_Brillant_Paula_Bean.aspx ...they are in a category of their own.

I'm sure plenty of device drivers written in brightly lit offices by people with smart haircuts and shiny shoes have some absolutely horrific code too.

Indeed.

The problem isn't doing it, the problem is in getting the "random needs effort" message though thick developer's skulls.

You think that, but you have no idea the depths of perversity developers will go to to avoid learning the simple facts that you have internalised.

This developer clearly believed that random numbers do indeed need effort:

http://thedailywtf.com/Articles/Random-Stupidity.aspx

Fortunately, you can get the computer to handle thousands of different sizes!

Do you mean this story, written by Jake Vinson?

Here's an edited version of the text for those too lazy to click on the link (used without permission, but go visit the site anyway as it has lots of amusing - if not entirely truthful - anecdotes)

As time passed, a proprietary gateway server to communicate with credit processing agencies would crash more and more frequently. And these were bad crashes, too — the kind of crashes where the server wouldn't respond to ping and would have to be restarted manually. It wasn't really a big deal for the admin, Erik, to hit the restart button on the server when he was there, but that was only 40 hours a week. The credit union needed it to be active 24/7, but was unwilling to hire 24 hour staff in the datacenter.

Erik had a script running that would ping the server every few minutes and alert him if it didn't respond so he could halfway proactively keep things running. It had to be restarted manually whenever it crashed, so there was no easy way to fix it remotely.

It was then that Erik idly looked at his computer, which had just ejected a disk image DVD he'd burned. It sparked an idea, but it was too absurd to say out loud. Still, he couldn't help but chuckle at the thought. "A CD ROM drive in an old system could eject and hit the reset button. I'd have to position the servers just right, somehow get the heights and alignment correct, and update the polling script to eject the CD ROM drive any time it didn't respond to ping." It was a ridiculous idea.

Yet that was exactly what Erik found himself spending the rest of the afternoon setting up. He found an old PC, updated his script to ping the server every two minutes and eject if there was no response, and with the help of a few phone books found the perfect height and position on the floor. Finally, Erik stood up, and ashamedly admired his work. He slapped a label on it that read "ITAPPMONROBOT," and another below with big underlined letters that read "DO NOT MOVE."

Somebody else did a similar hack to open a security door, and yet another to reset a wireless network.

Do you mean this story, written by Jake Vinson?

Here's an edited version of the text for those too lazy to click on the link (used without permission, but go visit the site anyway as it has lots of amusing - if not entirely truthful - anecdotes)

As time passed, a proprietary gateway server to communicate with credit processing agencies would crash more and more frequently. And these were bad crashes, too — the kind of crashes where the server wouldn't respond to ping and would have to be restarted manually. It wasn't really a big deal for the admin, Erik, to hit the restart button on the server when he was there, but that was only 40 hours a week. The credit union needed it to be active 24/7, but was unwilling to hire 24 hour staff in the datacenter.

Erik had a script running that would ping the server every few minutes and alert him if it didn't respond so he could halfway proactively keep things running. It had to be restarted manually whenever it crashed, so there was no easy way to fix it remotely.

It was then that Erik idly looked at his computer, which had just ejected a disk image DVD he'd burned. It sparked an idea, but it was too absurd to say out loud. Still, he couldn't help but chuckle at the thought. "A CD ROM drive in an old system could eject and hit the reset button. I'd have to position the servers just right, somehow get the heights and alignment correct, and update the polling script to eject the CD ROM drive any time it didn't respond to ping." It was a ridiculous idea.

Yet that was exactly what Erik found himself spending the rest of the afternoon setting up. He found an old PC, updated his script to ping the server every two minutes and eject if there was no response, and with the help of a few phone books found the perfect height and position on the floor. Finally, Erik stood up, and ashamedly admired his work. He slapped a label on it that read "ITAPPMONROBOT," and another below with big underlined letters that read "DO NOT MOVE."

Somebody else did a similar hack to open a security door, and yet another to reset a wireless network.

Do you mean this story, written by Jake Vinson?

Here's an edited version of the text for those too lazy to click on the link (used without permission, but go visit the site anyway as it has lots of amusing - if not entirely truthful - anecdotes)

As time passed, a proprietary gateway server to communicate with credit processing agencies would crash more and more frequently. And these were bad crashes, too — the kind of crashes where the server wouldn't respond to ping and would have to be restarted manually. It wasn't really a big deal for the admin, Erik, to hit the restart button on the server when he was there, but that was only 40 hours a week. The credit union needed it to be active 24/7, but was unwilling to hire 24 hour staff in the datacenter.

Erik had a script running that would ping the server every few minutes and alert him if it didn't respond so he could halfway proactively keep things running. It had to be restarted manually whenever it crashed, so there was no easy way to fix it remotely.

It was then that Erik idly looked at his computer, which had just ejected a disk image DVD he'd burned. It sparked an idea, but it was too absurd to say out loud. Still, he couldn't help but chuckle at the thought. "A CD ROM drive in an old system could eject and hit the reset button. I'd have to position the servers just right, somehow get the heights and alignment correct, and update the polling script to eject the CD ROM drive any time it didn't respond to ping." It was a ridiculous idea.

Yet that was exactly what Erik found himself spending the rest of the afternoon setting up. He found an old PC, updated his script to ping the server every two minutes and eject if there was no response, and with the help of a few phone books found the perfect height and position on the floor. Finally, Erik stood up, and ashamedly admired his work. He slapped a label on it that read "ITAPPMONROBOT," and another below with big underlined letters that read "DO NOT MOVE."

Somebody else did a similar hack to open a security door, and yet another to reset a wireless network.

Do you mean this story, written by Jake Vinson?

Here's an edited version of the text for those too lazy to click on the link (used without permission, but go visit the site anyway as it has lots of amusing - if not entirely truthful - anecdotes)

As time passed, a proprietary gateway server to communicate with credit processing agencies would crash more and more frequently. And these were bad crashes, too — the kind of crashes where the server wouldn't respond to ping and would have to be restarted manually. It wasn't really a big deal for the admin, Erik, to hit the restart button on the server when he was there, but that was only 40 hours a week. The credit union needed it to be active 24/7, but was unwilling to hire 24 hour staff in the datacenter.

Erik had a script running that would ping the server every few minutes and alert him if it didn't respond so he could halfway proactively keep things running. It had to be restarted manually whenever it crashed, so there was no easy way to fix it remotely.

It was then that Erik idly looked at his computer, which had just ejected a disk image DVD he'd burned. It sparked an idea, but it was too absurd to say out loud. Still, he couldn't help but chuckle at the thought. "A CD ROM drive in an old system could eject and hit the reset button. I'd have to position the servers just right, somehow get the heights and alignment correct, and update the polling script to eject the CD ROM drive any time it didn't respond to ping." It was a ridiculous idea.

Yet that was exactly what Erik found himself spending the rest of the afternoon setting up. He found an old PC, updated his script to ping the server every two minutes and eject if there was no response, and with the help of a few phone books found the perfect height and position on the floor. Finally, Erik stood up, and ashamedly admired his work. He slapped a label on it that read "ITAPPMONROBOT," and another below with big underlined letters that read "DO NOT MOVE."

Somebody else did a similar hack to open a security door, and yet another to reset a wireless network.

And remember, never send any military surplus drones to Mars!

Why not? they very safe. Just be sure to set the 'KILL' switch to 'false'... And hope the programmers read the DailyWTF site. Hope real hard.

My oppinion is that Javascript is not bad as a scripting language, but we are abusing it and twisting it beyond its original purpose.

I disagree with that sentiment. Like PHP it gets used a lot and for that reason plenty people think it must be good for something, right?

Well, uhm, no. Wide availability and popularity do not a good language make. You have a point about the stretching but I disagree that it was any good to start with. Merely really, really widely available. And apparently well-suited for the kind of non-thinking that abounds in its niche. Which makes it enterprise-y, in a sense.

... on the TheDailyWTF

Q: What's wrong with complexity?

A: It hides bugs!!

Notwithstanding that some tasks are inherently complicated and there's just no simple way to express it I would posit that the problem with unnecessary complexity is that it hides bugs.

Bugs hide in the edges. They swarm in corners. They positively thrive in interfaces.

Simple (i.e. clean) code helps make the bugs stick out.

There is some business case or need behind each programming effort. That case/need has an underlying language, a grammar, that embodies what needs to be done and when and how. The challenge in software development is to find programming constructs which, inasmuch as is possible, clearly expresses the problem's solution.

Through hard-won experience we've discovered things that suggest where bugs like to hide; what are sometimes called "Code Smells." Massive, nested IF statements. GOTO statements. Global variables. Side effects.

But, these are only symptomatic. There are times when some of these ARE necessary to achieve maximum performance. In other words, not all cases are bad, but they suggest a long, hard look to ensure they are necessary.

Consider programming languages. We started with machine code. Then we wrote assemblers to make it easier to express what we wanted to do. Then came macros and functions. Still later we developed higher level languages. All of these steps allowed us to more easily express what we were trying to do.

Consider this continuum. Case 1: A single program with thousands of lines of code and no functions or subroutines. Case 2: The same application implemented with thousands of functions, each of which contain at most 5 lines of code.

There's probably a sweet spot in between those extremes. A point where the abstractions of what needs to be done closely mimics the problem domain. Where the inputs and outputs are clearly delineated and checked. Where each function is the "right size". As the lowest level functions are implemented and tested, they provide a framework, a language in which one can more easily express what is being done. It is clear what is attempted and how. And it is clear when things are amiss. It makes the bugs "stick out."

When we fail to do this, when we unnecessarily complicate the code, then problems arise. We struggle to grok the code. In this struggle, overwhelmed in trying to follow the "good" paths, we fail to see all its shortcomings. We provide hiding places for bugs. They blend in. They avoid observation. Or, when detected, resist eradication. For some samples, take a look here.

tl;dr. Given: Some problems are just plain complicated and defy any further simplification. Fine. Other problems are amenable to consistent abstractions. When we fail to do that, we introduce unnecessary complexity. We breed bugs.

From thedailywtf.com no less.

'Nuff said?

How about we have 3 boxes on the forms. Male, Female, Other. So simple, problem solved.

The third option for boolean values should, of course, be FileNotFound :)

Joking aside, I'm not convinced that people who've had so severe issues with their gender idendity that they actually changed it would be happy to be "Other".

Something like the OMG OCR Calculator?

Yes, but why should Microsoft care about such a poorly developed application? They're not accessing sensitive information in the HEAD request. If a HEAD or GET performs an action that changes data or causes physical action, then that's not Microsoft's problem. It doesn't matter that the RFC allows it - it's very poor practice and that's been proven time and again in the real world.

This is protecting consumers from compromised consumers. There's nothing malicious about it. And there's really no reason to complain.

Related:
http://thedailywtf.com/Articles/WellIntentioned-Destruction.aspx

The customer may be non-technical and not know how to describe the problem accurately. The customer may have requested something impossible. The customer may have conflicting demands. The customer may be unaware of an existing approach that has no drawbacks over their suggested solution. The customer may not have thought the problem through fully and fail to realise the ramifications of what they are proposing. The Daily WTF is full of examples of these kinds of errors.

This is true of any commissioned work process, from software engineering to graphic design. Customers can only be trusted to be aware of their problems, not solutions, and even then it's never perfect. Ideally during the specification process you work closely with the customer to establish a consensus about what will actually be written, but that's still a distinct thing.

How much could it possibly save the company to take away maternity leave? Certainly not anywhere near the disparity in salaries. And women complain about being underpaid because they are underpaid. In our day and age it's not (usually) a conscious decision by management to pay women less. Often it's actually women themselves simply not being as assertive looking for raises and accepting the disparity as unchangeable. The few voices complaining about the disparity are simply trying to get everyone involved to take a look at their own situations and figure out if women are being paid less at their workplace and if those women actually deserve to be paid less.

Maternity leave (and paternity leave) is a benefit like package health insurance, company cars, paid vacation, etc. It's offered by employers trying either to create a happy workplace and attract the best employees or to satisfy the demands of a labor union. I think that most people would agree that more maternity AND paternity leave would be good for everyone. But men have fewer opportunities to be involved with their children because there's still a prevalent idea in America that the women are responsible for giving up their lives to become primary caregivers. Most men are happy with that and so will not fight for paternity leave, and enough women have accepted it that they do fight for maternity leave.

As for "changing diapers or cleaning up code," yes both are messy, but I'd leave these smells for somebody else to clean up any day.