If you can read this, either the style sheet didn't load or you have an older browser that doesn't support style sheets. Try clearing your browser cache and refreshing the page.

(BusinessWeek)   The only man with a "dislike" button on Facebook also has a bar next to his desk, full of booze from programmers trying to bribe him to include their code in the site   (businessweek.com) divider line 43
    More: Cool, Facebook, earthlings, ranking system, vmware  
•       •       •

10679 clicks; posted to Geek » on 09 Oct 2012 at 5:46 PM (1 year ago)   |  Favorite    |   share:  Share on Twitter share via Email Share on Facebook   more»



43 Comments   (+0 »)
   
View Voting Results: Smartest and Funniest

Archived thread
 
2012-10-09 05:47:14 PM
I like this guy already
 
2012-10-09 05:53:42 PM
I just vote this farking thread down. fark all of you.

Yeah, give me more of that thumbs down action! HAHAHA!
 
2012-10-09 05:55:38 PM
Back in my day we did not need no fancy release engineers, nor did we need any gold star. Freaking Mellinials and their inability to code, document, test, and release all by their lonesome, their need for constant feed back and gold stars, makes me want to vomit.

Real programmers work in places that are understaffed and end up overworked, but still get the job done with out anyone looking over their shoulders.
 
2012-10-09 05:56:00 PM
img.photobucket.com
 
2012-10-09 05:57:21 PM
img.fark.netimg.fark.netimg.fark.netimg.fark.netimg.fark.netimg.fark.netimg.fark.netimg.fark.netimg.fark.netimg.fark.netimg.fark.netimg.fark.netimg.fark.netimg.fark.netimg.fark.netimg.fark.netimg.fark.netimg.fark.netimg.fark.netimg.fark.netimg.fark.netimg.fark.netimg.fark.netimg.fark.netimg.fark.netimg.fark.netimg.fark.net
 
2012-10-09 06:01:24 PM

Slaves2Darkness: Back in my day we did not need no fancy release engineers, nor did we need any gold star. Freaking Mellinials and their inability to code, document, test, and release all by their lonesome, their need for constant feed back and gold stars, makes me want to vomit.

Real programmers work in places that are understaffed and end up overworked, but still get the job done with out anyone looking over their shoulders.


Semper Fi, eh.
 
2012-10-09 06:06:21 PM
Yet all the booze in the world will not get this guy laid. That's the real story here.
 
2012-10-09 06:09:45 PM
As a programmer, that star system sounds awful.
 
2012-10-09 06:12:43 PM
... So what's the argument FB has for having no "Dislike" button? It seems a common enough request.
 
2012-10-09 06:17:17 PM
I wish I had more hands, so I could give Business Week's interstitial ad 4 thumbs down.

25.media.tumblr.com
 
2012-10-09 06:18:01 PM

elchupacabra: ... So what's the argument FB has for having no "Dislike" button? It seems a common enough request.


I...hahaha.....read in an interview once that....heh heh...Mark Zuckerberg didn't want a dislike button because he wanted....ha....Facebook to be....*snicker........a fun and positive place! Bwahahahaha!
 
2012-10-09 06:19:15 PM
Wow. As a former senior project manager, asking people to work for you with a gold star rewards program is seriously crummy. Nope, no, I don't think of you being able to stand on your own merits, nor do I trust you to get the job done. Bribes are great, and hey, if I think highly of you, I won't demote your public rating.

Wanker.

And to second Slaves2Darkness, real programmers have their shiat together in such a way that 'push' goons are not needed.
 
2012-10-09 06:19:37 PM
I engineered a release into a tube sock last night.
 
2012-10-09 06:19:42 PM

CanuckInCA: As a programmer, that star system sounds awful.


That whole process just sounds dumb to me. Don't they have product people to figure out what needs to be in the application first, then have coders code it?
 
2012-10-09 06:23:16 PM

elchupacabra: ... So what's the argument FB has for having no "Dislike" button? It seems a common enough request.


It would end up like reddit and fark.
 
2012-10-09 06:24:38 PM

dallylamma: I engineered a release into a tube sock last night.


That's nothing, try an old tootsie roll wrapper. The best part is when you look at it afterwards and you realize that's probably the mixture you'd find when you cum in a chick's ass.
 
2012-10-09 06:28:35 PM

Slaves2Darkness: Back in my day we did not need no fancy release engineers, nor did we need any gold star. Freaking Mellinials and their inability to code, document, test, and release all by their lonesome, their need for constant feed back and gold stars, makes me want to vomit.

Real programmers work in places that are understaffed and end up overworked, but still get the job done with out anyone looking over their shoulders.


I've yet to run into ANYONE, young or old (I work with programmers that are anywhere from 2 months from retiring and 6 months out of grad school) that religiously documents their code changes unless forced to by a boss constantly making sure it happens, and even then some of the more stubborn coders only comment their code, and never document check ins or bug fixes beyond a "Fixed it". TFS checkin rules help enforce this a bit more at least. The guy retiring soon is on autopilot at the moment, but he deserves a light load his last few months. He's farking earned it over the last 30 years here.

//I do document things, but that's so I can remember what I did 2 weeks ago. I've been burnt by not documenting what the hell I did before.
 
2012-10-09 06:30:32 PM

Znuh: Wow. As a former senior project manager, asking people to work for you with a gold star rewards program is seriously crummy. Nope, no, I don't think of you being able to stand on your own merits, nor do I trust you to get the job done. Bribes are great, and hey, if I think highly of you, I won't demote your public rating.

Wanker.

And to second Slaves2Darkness, real programmers have their shiat together in such a way that 'push' goons are not needed.


last job i worked we had a couple guys in firmware who felt as you do.

their code was crap, constantly undoing fixes on prior bugs, breaking functionality, and sometimes just simply not up to snuff.

my boss and i basically called a 4-4 showstopper(in the system we used, this was the 'break glass and pull in event of catastrophe' level of 'ohshi-'), and explained to the project lead(who oversaw us in characterization as well as the C-apes in firmware) why we were burning a million dollars a day doing NOTHING at the moment.

within a day we had a push-man, a goon, an enforcer.

firmware started releasing that worked without needing to be regressed or sent back.

Obbi: CanuckInCA: As a programmer, that star system sounds awful.

That whole process just sounds dumb to me. Don't they have product people to figure out what needs to be in the application first, then have coders code it?


see prior remarks about breaking previous fixes and destroying working code. when you have something as systemic as facebook has become(where the upstream side probably looks as convoulted as a full-blown OS or worse), you have to verify it against the system and its APIs looking for the little bit that can break something totally unrelated, potentially through one or more marginally associated applications. it's not easy. there's a reason the Goons like this guy are so important.
 
2012-10-09 06:39:05 PM

buttery_shame_cave: it's not easy. there's a reason the Goons like this guy are so important.


IMHO, if you have to rely on using a sledgehammer to chop down a tree, yep, it'll work. All that says to me, in my professional opinion, is you couldn't do a thorough job without resorting to crap tactics.

If they're not working, chances are the problem's staring you in the face in the morning when you look in the mirror. Forcing things and using brute tactics isn't really full of win.

/Never had shiat work by those in my team
//Ever.
 
2012-10-09 06:41:37 PM
I already hate the prick. He's the (indirect) reason FB apps are always breaking. Little change here, little change there ... shiat on third party developers, no problem!
 
2012-10-09 06:42:13 PM

meat0918: Slaves2Darkness: Back in my day we did not need no fancy release engineers, nor did we need any gold star. Freaking Mellinials and their inability to code, document, test, and release all by their lonesome, their need for constant feed back and gold stars, makes me want to vomit.

Real programmers work in places that are understaffed and end up overworked, but still get the job done with out anyone looking over their shoulders.

I've yet to run into ANYONE, young or old (I work with programmers that are anywhere from 2 months from retiring and 6 months out of grad school) that religiously documents their code changes unless forced to by a boss constantly making sure it happens, and even then some of the more stubborn coders only comment their code, and never document check ins or bug fixes beyond a "Fixed it". TFS checkin rules help enforce this a bit more at least. The guy retiring soon is on autopilot at the moment, but he deserves a light load his last few months. He's farking earned it over the last 30 years here.

//I do document things, but that's so I can remember what I did 2 weeks ago. I've been burnt by not documenting what the hell I did before.


you and me both. i'm the only person at my current job even writing any code at all, and i'm paranoid about documentation. i've got a short digression and todo in comments at the start of the code, a separate documentation explaining how it works, AND a separate changelist for each program. all of them backed up doubly in physical media as well as clouded both to my GDrive as well as the company dropbox.

nevermind that my code often includes commenting that is quite entertaining to other folks that go in and look at my work, but is also very thorough in breaking down certain functions.
 
2012-10-09 06:44:33 PM
It's never a bad idea to have a third party review any code changes that have been submitted before they are deployed, even if they've already passed the usual array of QA tests.

I don't think it's a good idea to have just one guy responsible for release-engineering the entire codebase for a system the size of Facebook, though. It's more than a single brain can keep track of.

It disappoints me to learn that Facebook employs developers who think they can bribe a release engineer into deploying their code prematurely by buying him booze. And that he rewards those who "heroically" jump in and fix problems at the last minute; that's a system ripe for abuse.
 
2012-10-09 06:47:53 PM

CanuckInCA: As a programmer, that star system sounds awful.


No shiat. One place I worked, breaking the build or other shenanigans just meant you just had to fund the tab for the next release party. It's an incentive for clean builds, but if you do break things nobody gets that ticked off at you 'cause they know it means free beer. :D
 
2012-10-09 06:50:32 PM

Znuh: buttery_shame_cave: it's not easy. there's a reason the Goons like this guy are so important.

IMHO, if you have to rely on using a sledgehammer to chop down a tree, yep, it'll work. All that says to me, in my professional opinion, is you couldn't do a thorough job without resorting to crap tactics.

If they're not working, chances are the problem's staring you in the face in the morning when you look in the mirror. Forcing things and using brute tactics isn't really full of win.

/Never had shiat work by those in my team
//Ever.


it was, ultimately the classic problem of lots of handwaving and 'oh it should work' from firmware guys who rarely played with the systems, on top of a brand new technology that had never been properly characterized, compounded with management that believed the hype about the specs, in a system that had never been just TESTED. guess who had to sit down and test the dang thing at every possible(functional, thank god, shrunk the settings to 10% of what they could have been) permutation of the primary drive settings? yeah. me. not fun but the money was good.

embedded systems like what we were working on are awfully finicky when it comes to tweaking settings willy-nilly like these guys were doing. it was a case of 'throw it at the wall till it sticks' and it was, frankly, wasting money like crazy.

part of it is complexity. when your project isn't massively interconnected, it's easy to not have the need for a guy like this. but for something as massive as facebook? especially when various coders primarily know about their little slice of it but not the entire picture?
 
2012-10-09 06:54:23 PM

BumpInTheNight: elchupacabra: ... So what's the argument FB has for having no "Dislike" button? It seems a common enough request.

It would end up like reddit and fark.


You say that like it's a bad thing. Exactly where do your loyalties lie BumpInTheNight?

/Farkers are model Internet citizens.
 
2012-10-09 07:03:59 PM

buttery_shame_cave: Part of it is complexity. when your project isn't massively interconnected, it's easy to not have the need for a guy like this. but for something as massive as facebook? especially when various coders primarily know about their little slice of it but not the entire picture?


Sounds like it was poorly structured from the beginning. The product is only as good as the team assembled, and doubly so for how well things have been bolted together from the start. I can understand how easy it is for quagmires to build up and begin; it's again up to the PM to ensure that the bullshiat is reduced to the point that people can do their job, and do so with minimal interference from Management, and quite likely, the Customer.

If there's not a system of checks and balances put in place, or if the project is allowed to balloon in scope and go wildly out of control, then everyone loses. Having to use abusive tactics to steer something back on course usually means everyone's been flying by the seat of their pants, and now it's more of a crucible.

Crucibles burn people out. Working for (or under) a crucible-focused manager doubly so. There's a time and a place for drastic action; but if the end result is because of my screwups, then I take the blame and the heat.

It's very easy for people to forget the food chain; without the Customer, none of us get to work. There are those who think the sledgehammer works better for motivation rather than creating a project that encourages those to put their best foot forward.

In the end, if you build a car with no steering then yell at the driver to go left, no matter how much you beat him silly, the car still won't turn. 90% of proper PM is keeping on top of the project, and structuring it in such a way that it doesn't go into left field from the start.
 
2012-10-09 07:19:55 PM
Why would facebook have a dislike button? Nobody's going to buy something that's disliked.
 
2012-10-09 07:20:02 PM

Znuh:
If there's not a system of checks and balances put in place, or if the project is allowed to balloon in scope and go wildly out of control, then everyone loses.


i do believe you just managed to describe facebook's business model...

and mojang's but that's for a different thread... 

part of what you're talking is project management, which is a vastly different beast than programming, at its core. a lot of folks that can do one cannot do the other, or can only do so much.

in the beginning facebook(like mojang, or 3DRealms) was run by the engineers so to speak. engineers are notoriously bad at that. exceptions to the rule aside, i think that's where the core of the problem was, originally.

i recall hearing on NPR that facebook has almost a 'coding by mass consensus' approach to a lot of applications, where they gather a mess of people together and they consume a lot of caffiene/sugar and just sort of... fart out an application. that sort of approach might be part of the problem too.
 
2012-10-09 07:29:30 PM

buttery_shame_cave: Znuh:
If there's not a system of checks and balances put in place, or if the project is allowed to balloon in scope and go wildly out of control, then everyone loses.

i do believe you just managed to describe facebook's business model...

and mojang's but that's for a different thread... 

part of what you're talking is project management, which is a vastly different beast than programming, at its core. a lot of folks that can do one cannot do the other, or can only do so much.

in the beginning facebook(like mojang, or 3DRealms) was run by the engineers so to speak. engineers are notoriously bad at that. exceptions to the rule aside, i think that's where the core of the problem was, originally.

i recall hearing on NPR that facebook has almost a 'coding by mass consensus' approach to a lot of applications, where they gather a mess of people together and they consume a lot of caffiene/sugar and just sort of... fart out an application. that sort of approach might be part of the problem too.


See, that sort of team exercise might be good once in a while, just to see what new stuff they can come up with, but you need a goal besides "What neat stuff can we do next?".
 
2012-10-09 09:14:21 PM

Znuh: Wow. As a former senior project manager, asking people to work for you with a gold star rewards program is seriously crummy. Nope, no, I don't think of you being able to stand on your own merits, nor do I trust you to get the job done. Bribes are great, and hey, if I think highly of you, I won't demote your public rating.

Wanker.

And to second Slaves2Darkness, real programmers have their shiat together in such a way that 'push' goons are not needed.


You sound like you need your code reviewed.
 
2012-10-09 09:55:43 PM

elchupacabra: ... So what's the argument FB has for having no "Dislike" button? It seems a common enough request.


Because they don't want people getting killed more often over something posted on Facebook. You know how the crazies are, and people obsessed with Facebook are the full blown crazy usually reserved for Evangelists, Scientologists, and people who watch Jersey Shore. Can you imagine the trouble a person could get into with their family or friends if they lacked a mental filter and went wild with the Dislike button? I can. I'd have people hating me for no reason other than the fact they're simpletons who lack the ability to handle someone being honest.
 
2012-10-09 10:43:55 PM

Dear Jerk: Why would facebook have a dislike button? Nobody's going to buy something that's disliked.


Can you imagine how many Dislikes the Facebook page would get the instant it was deployed?
 
2012-10-09 10:49:40 PM

Cymbal: dallylamma: I engineered a release into a tube sock last night.

That's nothing, try an old tootsie roll wrapper. The best part is when you look at it afterwards and you realize that's probably the mixture you'd find when you cum in a chick's ass.


I think we've taken this relationship as far as it can go, you farking sicko.
 
2012-10-09 10:58:15 PM
Dislike? I'd rather have this:

dissociatedpress.com
 
2012-10-09 11:10:42 PM

buttery_shame_cave: see prior remarks about breaking previous fixes and destroying working code. when you have something as systemic as facebook has become(where the upstream side probably looks as convoulted as a full-blown OS or worse), you have to verify it against the system and its APIs looking for the little bit that can break something totally unrelated, potentially through one or more marginally associated applications. it's not easy. there's a reason the Goons like this guy are so important.


CSB: I work with release engineers daily, for a large website.

These guys are vital, not just for the reasons stated above, but to write the tools needed to coordinate the updating of code images on tens of thousands of machines, and restarting the services in a way that ensures the site doesn't take a dump during the push. (FYI I've heard that Facebook uses the BitTorrent protocol to load the code to all their servers).

Basically, you need the process to run as fast as possible, but you have to make sure that enough machines are alive at any given time to handle site load. You also need to figure out how to "bleed" traffic off of machines before you restart the app, so that currently-loading sessions don't get killed.

And, you need to develop instrumentation that can tell the slight dip in site success rate you always see when you do a push, and distinguish that from bigger signs of alarm so that if bad code does go out, it can be rolled back before too much of the farm is running it for the problem to be noticeable.
 
2012-10-10 03:16:38 AM

rekoil: FYI I've heard that Facebook uses the BitTorrent protocol to load the code to all their servers).


Huh, that's clever.
 
2012-10-10 04:38:49 PM

LikeALeafOnTheWind: Znuh: Wow. As a former senior project manager, asking people to work for you with a gold star rewards program is seriously crummy. Nope, no, I don't think of you being able to stand on your own merits, nor do I trust you to get the job done. Bribes are great, and hey, if I think highly of you, I won't demote your public rating.

Wanker.

And to second Slaves2Darkness, real programmers have their shiat together in such a way that 'push' goons are not needed.

You sound like you need your code reviewed.


I am not a programmer so I may be missing something, but why would having one team (I assume the guy has a team and isn't the only one personally reviewing every line of code that Facebook pushes out on a daily basis) making sure that nothing new breaks the existing system be a bad thing? I get the goofy star rating and being open to bribery by alcohol smells kinda douchey, but he sounds more like a final QA rather than an insult. Unless you are saying that "real programmers" don't make mistakes.
 
2012-10-10 05:20:36 PM

roc6783: I am not a programmer so I may be missing something, but why would having one team (I assume the guy has a team and isn't the only one personally reviewing every line of code that Facebook pushes out on a daily basis) making sure that nothing new breaks the existing system be a bad thing? I get the goofy star rating and being open to bribery by alcohol smells kinda douchey, but he sounds more like a final QA rather than an insult. Unless you are saying that "real programmers" don't make mistakes.


There is nothing at all wrong with it (although, yeah, this implementation sounds horrid). I have a feeling the folks complaining have never worked on a large, complex, or high-quality-requirement program before. Peer reviews and change coordination are pretty basic elements of a mature software organization.

/nothing makes a peer review drag like an over-inflated ego
 
2012-10-10 05:31:48 PM

Fish in a Barrel: roc6783: ***snip***
/nothing makes a peer review work drag like an over-inflated ego


FTFY. Because what I said was better, now you know for next time.

//My current boss told me that once about 2 words she changed in a client presentation, but without the humorous sarcasm. She really meant it. My job sucks.
 
2012-10-10 06:01:47 PM

roc6783: Fish in a Barrel: roc6783: ***snip***
/nothing makes a peer review work drag like an over-inflated ego

FTFY. Because what I said was better, now you know for next time.

//My current boss told me that once about 2 words she changed in a client presentation, but without the humorous sarcasm. She really meant it. My job sucks.


[insert five-minute long explanation about the history of that sentence and how what I wrote wasn't really wrong, but I'll magnanimously agree to the change anyhow]
 
2012-10-10 06:14:11 PM

Fish in a Barrel: roc6783: Fish in a Barrel: roc6783: ***snip***
/nothing makes a peer review work drag like an over-inflated ego

FTFY. Because what I said was better, now you know for next time.

//My current boss told me that once about 2 words she changed in a client presentation, but without the humorous sarcasm. She really meant it. My job sucks.

[insert five-minute long explanation about the history of that sentence and how what I wrote wasn't really wrong, but I'll magnanimously agree to the change anyhow]


I've just stopped doing that. Fun fact, we changed a billing procedure when my current boss took over (shockingly the new procedure was actually better and made more sense). Fast forward 5 months of using the process when my boss calls me into her office and goes on a 10 minute biatchfest about how I am SUPPOSED to be doing it, throwing in nuggets like "I cannot micromanage all of these numbers, I have to trust that when you give them to me, they are accurate". When she finally winds down, I simply point out that we are in fact using the procedure that she just explained, and had been doing so for the previous 5 months.

We have had the SAME discussion for the last 4 months now, including one where she blew up on our team during a meeting about how we can't be following the "old" process anymore. I stopped her mid-sentence, once again, to explain to her patiently that we were not following the "old" process anymore and how she was misinterpreting the data. This was the day after we had the exact conversation just the 2 of us for the 3rd month in a row.

//FML
 
2012-10-10 10:59:18 PM
Our RE is a pained and spiteful man. Too many customized client solutions being hedged across our products means that occasionally routine migrations have unintended consequences.

Fun days.
 
2012-10-11 08:41:40 AM
If you need to document your code, you're not a very good programmer, or at least you're misguided yet have good intentions.

Write clean, readable code. There's no reason to write in a programming language, then go back and write everything you just did again in another language, then have to keep both of those in sync.

One function of your code should fit on my screen and be self-descriptive. That behaviour should be tested, and I should be able to read the tests easily, too.

That doesn't mitigate the need for an integration specialist (thought it should be heavily automated, and if you use branching by abstraction and a good amount of composition you don't have the kind of merge conflicts that this person is needed to resolve) or for a requirements specification.

People who document their code are afraid people won't understand it, or that it might not work if a subtle change is made. The first is solved by using sensible names for functions and variables, and not using large methods with a bunch of conditional statements. The second is solved by ensuring that your code is well tested (which has nothing to do with code coverage, that's another uselsess "oh we just have to do [x] and our code will be better!" prayer hinged on a metric) because any change will break the test. The test satisfies that urge you have to document your code with a blob of stream-of-consciousness by giving a context around the behaviour, in the established "given, when, then" manner. Then, if you think the test is wrong, you can go back to the spec to see how the behaviour ought to be.

But nothing is worse than this:

// the customers name
private String _cname;

/* get the customers name
* @returns customers name
*/
public String getCName() {
return _cname;
}

That's not documentation. That's noise. Just call the damn variable customerName and the function getCustomerName. I see this every day. Every. Single. Day. - someone on our team of 6 people checks in code with a bunch of obscure variable names. I can even understand typing it out with something shorter, while it is fresh in your brain, but then use the goddamn IDE to refactor it to a descriptive name!

And

/* okay, let me explain how this works:
* ...
* ...
* ...
* ...
* ...
* and so you should NEVER do that
*/
int x;
int y;
String foo;

/bunch of ridiculous logic


NO ONE is going to read that. Even if someone does (meaning they're new/junior), they won't understand it, and EVEN IF they do, it's likely out of date compared to the actual code. They can't be sure, so then they have to go and read the code anyway
 
Displayed 43 of 43 comments

View Voting Results: Smartest and Funniest


This thread is archived, and closed to new comments.

Continue Farking
Submit a Link »






Report