My First Contractor Experience



  • Back when I was a young Padawan training to be a Jedi master (read: roughly two years ago), I was in need for work. In my hometown, there was only one place to find work as a software developer and find work I did. I eventually got onto a mobile pilot project where I got to work with a guy I knew previously and still know to this day and got to help my boss out by bringing her praise (read: I earned, she claimed) while also padding my resume because nowadays experience with mobile development has a huge ROR.

    Where I worked was pretty much a Java shop outside of a few ASP.NET Web services floating around for no good reason and some good ole' RPG developers to extend our powerful backend systems powered by IBM i Series (read: maintain our fossilized but mission-critical AS/400 programs that should have been ran away from long ago). Now, since we were a Java shop naturally the Android port of our internal LOB app came first, but we also had to write the backend Web services. Now we weren't managed by architects or team leads. We did have to listen to what the architects said though, so we used JSON because it is fast SOAP because it was enterprisey. No, seriously, that was the exact reason but that side of the story shall be for another day. Eventually we were wrapping up the coding for the Android version, but we needed an iOS version to gauge what platform was the best. In came Bill.

    Bill (as I will call him) was your fairly average contractor, minus the huge ego for the most part. Setting up Bill so he could work remotely started off painful at best. We never really had a process to set up contractors, so the first couple of weeks were painful at best (not like it got much better). It took two weeks for the company to set up his VPN access, so he had to stay on site so we could get him set up properly. After that was done, we needed to allow him VNC to a Mac on site for security reasons (the company I worked at was two nuts short of wearing tinfoil hats) and after that was done, we noticed something peculiar. When he was connected to the VPN, he could only remote into the Mac on site. See the problem yet? The problem was that VNC is slow and developers tend to need to look up documentation every now and then. Also, doing development over VNC sucks total ass. IT's solution? Browse the Web over VNC. Everyone else's solution? Allow him browse access over VPN. We won because of having strong backing in the business side of the company and the IT side.

    Eventually, Bill got to work remotely. Eventually, the guy I was working with and me got to go back into the Android app and emulate some of the things he did in the iOS version, except for the magically changing store number (read: ha ha uninitialized variable or casting a pointer to an integer). It sucked. Eventually we got everything pretty stable and ready for piloting. That also happened to be the end of Bill's contract with us and the guy I worked with ended up being my new manager (for a week). He left over to the business side of things and I got stuck needing to learn Objective-C to support an app that our CIO wanted to continue forward on even though everyone else wanted to end the project.

    The project continued under the CIO's backing for a grand total of about...three weeks. As it turns out, bringing purchasing of all computer equipment under the IT department tends to send you past your budget quite fast. Because of said budget overruns, the CIO killed the project faster than a beer on Friday. The CIO remains there to this day, and they even brought Bill back! Hopefully he initialized all his variables and remembers his pointer rules...



  • Putting a vacuum cleaner up your pants is way more interesting than this story. Sorry bro.


  • Discourse touched me in a no-no place

    @HuskerFan90 said:

    As it turns out, bringing purchasing of all computer equipment under the IT department tends to send you past your budget quite fast.
    Moving the responsibility for purchasing equipment to one department without bringing the budgets previously used elsewhere for that purpose causes financial problems for that department? Whodathoughtit!?



  • @dkf said:

    @HuskerFan90 said:
    As it turns out, bringing purchasing of all computer equipment under the IT department tends to send you past your budget quite fast.
    Moving the responsibility for purchasing equipment to one department without bringing the budgets previously used elsewhere for that purpose causes financial problems for that department? Whodathoughtit!?

    Apparently our CIO. He was a nice guy, but I don't think he was all too great. He talked about moving to "results-oriented management" in the last group IT meeting before I left. I'm still trying to figure out what that meant because my bonus was already tied to my performance, which was measured by my results.



  •  @rootkit said:

    Putting a vacuum cleaner up your pants is way more interesting than this story. Sorry bro.

    Meh, this is only part 1 of the Pit-o-WTF known as my last place of employment. If I was to tell it all in one post I would get ripped for how long it was.



  • @HuskerFan90 said:

    We did have to listen to what the architects said though, so we used JSON because it is fast SOAP because it was enterprisey. No, seriously, that was the exact reason but that side of the story shall be for another day.

    TRWTF is people like you using the word "enterprisey" out of context. You are contributing to the trivialization of a once powerful label.

    An example of a truly "enterprisey" solution would be to require a SPARQL endpoint for every service or to require that every service should derive from a WS-BPEL template that is part of a library maintained by consensus during the monthly meeting of the Business Architecture Advisory Committee. See the difference with "using SOAP"?

    Also: JSON has many benefits but is not a silver bullet. While there has been some progress in schema validation or discovery it's not as mature or advanced as SOAP in those areas, and those are serious limitations for an organization because it makes systems integration and process automation more challenging. And I seriously doubt that if the decision was left to someone like you the JSON implementation would even include schemas beyond a disconnected (and obsolete) wiki entry that won't help people to maintain your shit two years down the road.



  • @HuskerFan90 said:

     @rootkit said:

    Putting a vacuum cleaner up your pants is way more interesting than this story. Sorry bro.

    Meh, this is only part 1 of the Pit-o-WTF known as my last place of employment. If I was to tell it all in one post I would get ripped for how long it was.

    An interesting WTF is somehow specific and does not read like a diary or a Lifetime movie script. Nobody will remember a long rant from some dude about his former company, but everybody remembers the nightmarish organization where Snoofle used to work because the WTFness was established one story at a time. It's like chinese water torture, not a big bang.



  • @Ronald said:

    @HuskerFan90 said:
    We did have to listen to what the architects said though, so we used JSON because it is fast SOAP because it was enterprisey. No, seriously, that was the exact reason but that side of the story shall be for another day.

    TRWTF is people like you using the word "enterprisey" out of context. You are contributing to the trivialization of a once powerful label.

    An example of a truly "enterprisey" solution would be to require a SPARQL endpoint for every service or to require that every service should derive from a WS-BPEL template that is part of a library maintained by consensus during the monthly meeting of the Business Architecture Advisory Committee. See the difference with "using SOAP"?

    Also: JSON has many benefits but is not a silver bullet. While there has been some progress in schema validation or discovery it's not as mature or advanced as SOAP in those areas, and those are serious limitations for an organization because it makes systems integration and process automation more challenging. And I seriously doubt that if the decision was left to someone like you the JSON implementation would even include schemas beyond a disconnected (and obsolete) wiki entry that won't help people to maintain your shit two years down the road.

    I said that because that's what the Architects told us to use because "it fits well in the enterprise". I do agree that SOAP is more mature and much more powerful than JSON in areas, but when you are working with mobile devices I would rather use JSON for speed because parsing a SOAP message can take a lot of processing power. Besides, I wasn't too fond of having to write a parser for the SOAP protocol for Android (the contractor would've got the iOS portion), but we ended up using a library that did the parsing for us. Besides, it's not like we were returning a lot of complex data or anything. Mostly just items in stock and search results for items, so JSON would've worked fine in this case.

     



  • @Ronald said:

    @HuskerFan90 said:

     @rootkit said:

    Putting a vacuum cleaner up your pants is way more interesting than this story. Sorry bro.

    Meh, this is only part 1 of the Pit-o-WTF known as my last place of employment. If I was to tell it all in one post I would get ripped for how long it was.

    An interesting WTF is somehow specific and does not read like a diary or a Lifetime movie script. Nobody will remember a long rant from some dude about his former company, but everybody remembers the nightmarish organization where Snoofle used to work because the WTFness was established one story at a time. It's like chinese water torture, not a big bang.

    This part of the story wasn't too bad. There is the part where I had to interact with a security system using DOM scraping though.

     



  • @HuskerFan90 said:

    Besides, I wasn't too fond of having to write a parser for the SOAP protocol for Android (the contractor would've got the iOS portion), but we ended up using a library that did the parsing for us.
    Nobody writes their own SOAP parser, that's part of the "Enterpriseyness". JSON grew up around JavaScript, so it's missing many of the features that a dynamic language wouldn't benefit from anyways. If you're writing in Java, there are tons of things that you can take advantage of in SOAP that aren't in JSON like; discoverability, rich tool integration, standardized security mechanisms, and versioning.
    @HuskerFan90 said:
    when you are working with mobile devices I would rather use JSON for speed because parsing a SOAP message can take a lot of processing power.

    I highly doubt that any of the Android devices on the market today will sweat parsing SOAP. My phone has the horsepower to tell what part of the screen my eyes are looking at. You are optimizing for a condition that you are likely to never encounter.


  • Discourse touched me in a no-no place

    @Ronald said:

    An example of a truly "enterprisey" solution would be to require a SPARQL endpoint for every service or to require that every service should derive from a WS-BPEL template that is part of a library maintained by consensus during the monthly meeting of the Business Architecture Advisory Committee.
    You work for us? Except that's not really an “or” there; the BAAC is supposed to define the SPARQL and WS-BPEL by writing a different XML document that is then processed automatically to generate the services and their publications.

    You'd better hope that the one remaining smartass that knows how to make this all work at all doesn't get bored and leave.
    @Ronald said:

    JSON has many benefits but is not a silver bullet. While there has been some progress in schema validation or discovery it's not as mature or advanced as SOAP in those areas, and those are serious limitations for an organization because it makes systems integration and process automation more challenging.
    Formally, I should note that SOAP can use JSON as a serialization format and XMPP as a transport; the result looks rather different to what most people (misguidedly) think of as SOAP.

    Practically, I bet you're comparing JSON/REST with XML/SOAP (they're common technology combinations). IME, there's some key differences, but the big ones are that it is easier to start with JSON/REST from scratch — a good XML/SOAP stack is a lot of work to write — and XML/SOAP now has some pretty decent tooling in a lot of languages (helped by the fact that people know what good tooling for it looks like). I'd use SOAP for inter-server comms, and REST for server/client comms.



  • @dkf: said:

    I'd use SOAP for inter-server comms, and REST for server/client comms.

     

    I tent to use SOAP when I control both ends, REST when the clients and server are owned by different groups...but other than that I largely agree with you.



  • @Ronald said:

    Also: JSON has many benefits but is not a silver bullet. While there has been some progress in schema validation or discovery it's not as mature or advanced as SOAP in those areas...

    But what it does have is actual industry support. Good luck communicating to a javascript frontend via SOAP, or finding SOAP libraries that actually work for the various mobile platforms, or even SOAP libraries that work in other languages and frameworks. There are far more actively used and well maintained JSON schema validators than there are working SOAP implementations.



  • @TheCPUWizard said:

    @dkf: said:

    I'd use SOAP for inter-server comms, and REST for server/client comms.

     

    I tent to use SOAP when I control both ends, REST when the clients and server are owned by different groups...but other than that I largely agree with you.

    That's a little ironic since the whole point of SOAP was so you didn't have to control both ends. Just like any web service or transfer protocol really.



  • @Soviut said:

    @Ronald said:
    Also: JSON has many benefits but is not a silver bullet. While there has been some progress in schema validation or discovery it's not as mature or advanced as SOAP in those areas...

    But what it does have is actual industry support. Good luck communicating to a javascript frontend via SOAP, or finding SOAP libraries that actually work for the various mobile platforms, or even SOAP libraries that work in other languages and frameworks. There are far more actively used and well maintained JSON schema validators than there are working SOAP implementations.

    Industry support? Did you try to use the same javascript frontend to talk with PHP and ASMX web services? You can't. Unless you always check for the fucking "d" to deal with that lovely framework 3.5 security feature.

    As for your well-maintained JSON schema validators, can you provide a link to one that does anything beyond checking the syntax and is not some obscure dude's github?



  • @Soviut said:

    @TheCPUWizard said:

    @dkf: said:

    I'd use SOAP for inter-server comms, and REST for server/client comms.

     

    I tent to use SOAP when I control both ends, REST when the clients and server are owned by different groups...but other than that I largely agree with you.

    That's a little ironic since the whole point of SOAP was so you didn't have to control both ends. Just like any web service or transfer protocol really.

    Wrong. The whole point of SOAP (and web services) is to offer a platform-neutral communication protocol between two nodes; in many organization this allows for a best-of-breed approach and therefore this has nothing to do with controlling or not controlling both ends. If you have a Unix box for your CRM and a Windows box for your ERM you can use SOAP to exchange customer data without having to run both ends on the same platform. Basically JSON should do the same (at some point) but so far it does not offer the same features (built-in schema validation, guaranteed delivery, etc).

    Don't get me wrong. I hate XML and find it immensely more pleasant to deal with JSON but it's not a silver bullet. In the context of an organization where you may end up using extensive automation or orchestration you need something that has a more robust feature set for discovery and validation.



  • @Ronald said:

    @Soviut said:
    @TheCPUWizard said:

    @dkf: said:

    I'd use SOAP for inter-server comms, and REST for server/client comms.

     

    I tent to use SOAP when I control both ends, REST when the clients and server are owned by different groups...but other than that I largely agree with you.

    That's a little ironic since the whole point of SOAP was so you didn't have to control both ends. Just like any web service or transfer protocol really.

    Wrong. The whole point of SOAP (and web services) is to offer a platform-neutral communication protocol between two nodes; in many organization this allows for a best-of-breed approach and therefore this has nothing to do with controlling or not controlling both ends. If you have a Unix box for your CRM and a Windows box for your ERM you can use SOAP to exchange customer data without having to run both ends on the same platform. Basically JSON should do the same (at some point) but so far it does not offer the same features (built-in schema validation, guaranteed delivery, etc).

    Don't get me wrong. I hate XML and find it immensely more pleasant to deal with JSON but it's not a silver bullet. In the context of an organization where you may end up using extensive automation or orchestration you need something that has a more robust feature set for discovery and validation.

    OMG, I may be agreeing with Ronald.... The reason I said "when I control both side" has nothing to do with both sides being the same platform... the "platform-neutral communication protocol" is a key part [for example, I believe I was one of the first to get WCF and IBM WebShere communicating over SOAP iand having the results published in early 2006].

     However, as a system gets more complex, there becomes some decision points (this is not limited to computer fields)...Mainly, How important is it to communicate to other PEOPLE the basics of usage??  Yes, with SOAP, the capabilities (discovery, et. al.) are much better, but (typically) so is the "learning curve" to accomplish even simple communication.  /When one person/team is working on both sides, they already have the necessary knowledge, so this consideration is much less important.

    But when you are going to publish something for a poentially vast audience (number of different endpoints/clients - not number of "users") then making this HUMAN communication as easy as possible can become much more important than any technical element.



  • @TheCPUWizard said:

    making this HUMAN communication as easy as possible can become much more important than any technical element.

    Please note that there is an enterprise technology designed to define and automate human interactions. It's called WS-HumanTask and as you can see in this diagram it's incredibly intuitive.

    There is also this great video to see what it's all about.



  • @Jaime said:

    @HuskerFan90 said:
    Besides, I wasn't too fond of having to write a parser for the SOAP protocol for Android (the contractor would've got the iOS portion), but we ended up using a library that did the parsing for us.
    Nobody writes their own SOAP parser, that's part of the "Enterpriseyness". JSON grew up around JavaScript, so it's missing many of the features that a dynamic language wouldn't benefit from anyways. If you're writing in Java, there are tons of things that you can take advantage of in SOAP that aren't in JSON like; discoverability, rich tool integration, standardized security mechanisms, and versioning. @HuskerFan90 said:
    when you are working with mobile devices I would rather use JSON for speed because parsing a SOAP message can take a lot of processing power.
    I highly doubt that any of the Android devices on the market today will sweat parsing SOAP. My phone has the horsepower to tell what part of the screen my eyes are looking at. You are optimizing for a condition that you are likely to never encounter.

    Yeah, well, if we didn't have a neat library to handle the SOAP processing for us, I would've resorted to using the DOM to parse a SOAP message as it was all I knew at the time which is painfully slow on Android platforms. Not to mention our main backend systems were old AS/400 programs on i Series that should have been killed long ago. Fortunately at my new place of employment, we are wanting to move away from our legacy AS/400 systems, which I for one welcome.



  • @HuskerFan90 said:

    Yeah, well, if we didn't have a neat library to handle the SOAP processing for us, I would've resorted to using the DOM to parse a SOAP message as it was all I knew at the time which is painfully slow on Android platforms.

    Your ignorance of existing SOAP libraries doesn't make JSON a better technology. The biggest selling point of SOAP is the vast number of platforms that have libraries for it. I'm no Android developer, but I did three seconds of Googling and none of the many how-tos I found resorted to DOM parsing. BTW, JSON is mostly fine, but the lack of a native date datatype is a huge weakness.
    @HuskerFan90 said:

    Not to mention our main backend systems were old AS/400 programs on i Series that should have been killed long ago. Fortunately at my new place of employment, we are wanting to move away from our legacy AS/400 systems, which I for one welcome.

    Old AS/400 stuff is old, but it's far from a dead platform. It's very easy to run a Java/WebSphere stack on an iSeries, and it's been possible to run PHP on one for the past seven years.



  • @Jaime said:

    @HuskerFan90 said:

    Yeah, well, if we didn't have a neat library to handle the SOAP processing for us, I would've resorted to using the DOM to parse a SOAP message as it was all I knew at the time which is painfully slow on Android platforms.

    Your ignorance of existing SOAP libraries doesn't make JSON a better technology. The biggest selling point of SOAP is the vast number of platforms that have libraries for it. I'm no Android developer, but I did three seconds of Googling and none of the many how-tos I found resorted to DOM parsing. BTW, JSON is mostly fine, but the lack of a native date datatype is a huge weakness.

    I mentioned that because my old employerwas a fan of the Quick and Dirty If It Works methodology.

    @Jaime said:

    @HuskerFan90 said:

    Not to mention our main backend systems were old AS/400 programs on i Series that should have been killed long ago. Fortunately at my new place of employment, we are wanting to move away from our legacy AS/400 systems, which I for one welcome.

    Old AS/400 stuff is old, but it's far from a dead platform. It's very easy to run a Java/WebSphere stack on an iSeries, and it's been possible to run PHP on one for the past seven years.

     The programs are the things that should be killed off, along with the way to interact with those programs. It's best described as if XML with REST got hit with a shovel while on fire.

     



  • @Ronald said:

    The whole point of SOAP (and web services) is to offer a platform-neutral communication protocol between two nodes; in many organization this allows for a best-of-breed approach and therefore this has nothing to do with controlling or not controlling both ends. If you have a Unix box for your CRM and a Windows box for your ERM you can use SOAP to exchange customer data without having to run both ends on the same platform.
    In theory... yes. In practice... well, the last time I had to try to get a SOAP client written in .NET to be able to access a service written in Java, I had to sacrifice three black chickens during a lunar eclipse just to get them to talk to each other without choking on the ever-so-slight deviations from the supposedly common standard that each implementation had.



  • @Anonymouse said:

    In theory... yes. In practice... well, the last time I had to try to get a SOAP client written in .NET to be able to access a service written in Java, I had to sacrifice three black chickens during a lunar eclipse just to get them to talk to each other without choking on the ever-so-slight deviations from the supposedly common standard that each implementation had.

    PHP to/from .Net isn't any better. The problem seems to be that it's one of those standards where everyone already had an implementation and so they agreed to make 90% of it optional and all implement different subsets.


  • Discourse touched me in a no-no place

    @Ronald said:

    best-of-breed approach
    Gaaaaaaah!

    Sorry. That phrase gives me bad flashbacks.


  • Discourse touched me in a no-no place

    @pjt33 said:

    PHP to/from .Net isn't any better.
    The constant here seems to be .NET, which has its own “special” way of doing certain things, including SOAP. The level of interoperability between other SOAP deployments is usually better. (Things get more complicated if you're using WSDL though, as there's whole extra layers of WTF in the subtle incompatibilities between various generators and parsers there.)

    But it still beats most services' JSON over REST, where there's no concept of even having a stable interface in the first place, let alone a consistent one. “You don't need a stable interface; you can just browse to it and click the links!” seems to be the dominating mindset there.



  • @dkf said:

    @Ronald said:
    best-of-breed approach
    Gaaaaaaah!

    Sorry. That phrase gives me bad flashbacks.

    He meant "best of bread".


     


  • Discourse touched me in a no-no place


  • Discourse touched me in a no-no place

    @El_Heffe said:

    He meant "best of bread".
    I loaf that explanation.


  • Considered Harmful

    @dkf said:

    @El_Heffe said:
    He meant "best of bread".
    I loaf that explanation.

    I think this joke has gone stale.



  • @dkf said:

    @El_Heffe said:
    He meant "best of bread".
    I loaf that explanation.
    Oh, you probably think you're so wheat-y, but you really got to rye harder.



  • Please let's not turn into reddit.


  • Considered Harmful

    @anonymous234 said:

    Please let's not turn into breaddit.

    BTFY



  • @joe.edwards said:

    @anonymous234 said:
    Please let's not turn into breaddit.
    BTFY


    Don't rise to the bait man. No need for anyone to get all fired up over a few puns.



  • @Anonymouse said:

    @dkf said:

    @El_Heffe said:
    He meant "best of bread".
    I loaf that explanation.
    Oh, you probably think you're so wheat-y, but you really got to rye harder.

    It's not a bran new joke, buckwheat all the puns already in this bread, crust me it could have bun worse. You have to look at the bagel picture, even dough it's not that funny at yeast he used naan of the previous jokes.



  • @Ronald said:

    @Anonymouse said:

    @dkf said:

    @El_Heffe said:
    He meant "best of bread".
    I loaf that explanation.
    Oh, you probably think you're so wheat-y, but you really got to rye harder.

    It's not a bran new joke, buckwheat all the puns already in this bread, crust me it could have bun worse. You have to look at the bagel picture, even dough it's not that funny at yeast he used naan of the previous jokes.

    Do they teach puns where you're from as they are not tortilla



  • @RTapeLoadingError said:

    Do they teach puns where you're from as they are not tortilla

    What puns?

    @Definition said:

    A pun differs from a malapropism in that a malapropism uses an incorrect expression that alludes to another (usually correct) expression, but a pun uses a correct expression that alludes to another (sometimes correct but more often absurdly humorous) expression.



  • @Ronald said:

    @RTapeLoadingError said:

    Do they teach puns where you're from as they are not tortilla

    What puns?

    @Definition said:

    A pun differs from a malapropism in that a malapropism uses an incorrect expression that alludes to another (usually correct) expression, but a pun uses a correct expression that alludes to another (sometimes correct but more often absurdly humorous) expression.

    A dictionary defines pun as: "The usually humorous use of a word in such a way as to suggest two or more of its meanings or the meaning of another word similar in sound" (emphasis mine)



  • @RTapeLoadingError said:

    @Ronald said:
    @RTapeLoadingError said:

    Do they teach puns where you're from as they are not tortilla

    What puns?

    @Definition said:

    A pun differs from a malapropism in that a malapropism uses an incorrect expression that alludes to another (usually correct) expression, but a pun uses a correct expression that alludes to another (sometimes correct but more often absurdly humorous) expression.

    A dictionary defines pun as: "The usually humorous use of a word in such a way as to suggest two or more of its meanings or the meaning of another word similar in sound" (emphasis mine)

    Besides the extra space, it's a weird place to put the hyperlink. The psychological meaning of weird hyperlinks placement is slightly creepy, it feels like watching a kid's drawing where people have eyes but no mouth.



  • @Ronald said:

    @RTapeLoadingError said:
    @Ronald said:
    @RTapeLoadingError said:

    Do they teach puns where you're from as they are not tortilla

    What puns?

    @Definition said:

    A pun differs from a malapropism in that a malapropism uses an incorrect expression that alludes to another (usually correct) expression, but a pun uses a correct expression that alludes to another (sometimes correct but more often absurdly humorous) expression.

    A dictionary defines pun as: "The usually humorous use of a word in such a way as to suggest two or more of its meanings or the meaning of another word similar in sound" (emphasis mine)

    Besides the extra space, it's a weird place to put the hyperlink. The psychological meaning of weird hyperlinks placement is slightly creepy, it feels like watching a kid's drawing where people have eyes but no mouth.

    Is my hyperlinking more or less creepy than those figurines with no facial features ?



  • @RTapeLoadingError said:

    @Ronald said:

    The psychological meaning of weird hyperlinks placement is slightly creepy, it feels like watching a kid's drawing where people have eyes but no mouth.

    Is my hyperlinking more or less creepy than those figurines with no facial features ?

    <3 DO YOU THINK I'M PRETTY <3



  • @Ronald said:

    @RTapeLoadingError said:
    @Ronald said:

    The psychological meaning of weird hyperlinks placement is slightly creepy, it feels like watching a kid's drawing where people have eyes but no mouth.

    Is my hyperlinking more or less creepy than those figurines with no facial features ?

    <3 DO YOU THINK I'M PRETTY <3



    This is the appropriate place to insert a joke about the perfect woman having no mouth. Or it would be if I was a sexist asshole. I'm not, so I'll refrain.

     


  • ♿ (Parody)

    @Snooder said:

    @Ronald said:

    <3 DO YOU THINK I'M PRETTY <3



    This is the appropriate place to insert a joke about the perfect woman having no mouth. Or it would be if I was a sexist asshole. I'm not, so I'll refrain.

    Right or wrong, I'd miss the blowjobs.


  • Considered Harmful

    @Snooder said:

    @Ronald said:

    @RTapeLoadingError said:
    @Ronald said:

    The psychological meaning of weird hyperlinks placement is slightly creepy, it feels like watching a kid's drawing where people have eyes but no mouth.

    Is my hyperlinking more or less creepy than those figurines with no facial features ?

    <3 DO YOU THINK I'M PRETTY <3



    This is the appropriate place to insert a joke about the perfect woman having no mouth. Or it would be if I was a sexist asshole. I'm not, so I'll refrain.

     

    That's terrible!

    How would she perform fellatio?



  • @joe.edwards said:

    @Snooder said:

    @Ronald said:

    @RTapeLoadingError said:
    @Ronald said:

    The psychological meaning of weird hyperlinks placement is slightly creepy, it feels like watching a kid's drawing where people have eyes but no mouth.

    Is my hyperlinking more or less creepy than those figurines with no facial features ?

    <3 DO YOU THINK I'M PRETTY <3



    This is the appropriate place to insert a joke about the perfect woman having no mouth. Or it would be if I was a sexist asshole. I'm not, so I'll refrain.

     

    That's terrible!

    How would she perform fellatio?

    You are a perv, a sexist and a dinosaur.

    The real reason why a woman needs a mouth is so she can taste what she cooks for the man and make sure it's not too mild or too spicy.



  • @RTapeLoadingError said:

    figurines with no facial features
    They only remind me of XKCD.


Log in to reply