When the reviewer doesn't understand my Javascript it's his fault

@Zenith said in When the reviewer doesn't understand my Javascript it's his fault:

@gleemonk I was responding more to people suggesting tools to force everybody ~~else~~ to do things ~~their~~in a standard way way.

FTFY

My style looks very different from AirBnB style. But people don't accept my style. So I accept AirBnB over any other style. Keeps the diffs readable.

Except it's not standard by literal definition. That's my point. If Amberlamps dictates Hungarian to Rick , and then only uses it on Thursdays, Hungarian isn't the standard. It's not standard for Amberlamps. It's not standard for the team they're members of. It's not standard for the product they're working on. In fact, it's the opposite: it's arbitrary.

Arbitrary is "based on random choice or personal_whim, rather than any reason or system." See? That's where it becomes about forcing others to do stuff your way. If it weren't, a change with a plausible reason behind it would carry some weight, instead of always being brushed away by "because I said so" or its cargo-cult variant "because IBM or Twitter said so."

I, on the other hand, have an extremely consistent style with reasoning that I'd be happy to explain to anybody that asked. So, yeah, I take offense to being told an actual standard is "unreadable" compared to a hodge-podge cobbled together on one person's whims.

Maybe consider that you have your own collaboration "issues" that prevent you from working with pragmatic people

It's subtle, that's for sure. When you have a non-standard "standard" foisted on you, it's a display of power dynamics. Rules for me, not for thee. You WILL do as you're told and ONLY what you're told. And so on.

That's why I say a code "standard," especially the unwillingness to share it at interview time, says alot about an organization's priorities. Sometimes I even see postings that have "follows standards" but don't mention a language. There are red flags and then there are nuclear-powered billboards that can be seen from Mars. They're already looking for the next warm body for when this one "doesn't meet expectations."

Where I probably lose people is that I don't believe a shop where everything is an unstable undocumented mess has any moral authority to inflict their way of doing things on a developer when said developer is subject to dismissal when more of the same inevitably leads to more of the same. All of those successful projects on my resume? Done my way (for the most part). If my knowledge or track record ("experience") carries any weight in the selection process, why force me to discard the very tools that put me above the other candidates? It's like The Expert...if you already know how to draw five perpendicular red lines with green ink, why are you going through this?

If you have to keep fixing my code, then by all means come back and slap me for not camel casing if it makes you feel better. But even then, the real issue is bad code, which is going to be just as bad in camel as it is in Pascal as it is in L33+. At an even higher level, maybe the hiring process is broken, in either the sense that you're not asking enough technical questions (too many ) or putting the necessary focus on your top priority of casing style (too many ).

Frankly, I'd rather be a bank teller with programming projects at home than be subject to another style-only "code" review.

gleemonk

@Zenith said in When the reviewer doesn't understand my Javascript it's his fault:

I, on the other hand, have an extremely consistent style with reasoning that I'd be happy to explain to anybody that asked. So, yeah, I take offense to being told an actual standard is "unreadable" compared to a hodge-podge cobbled together on one person's whims.

I think we're in agreement that consistency should be valued. Somehow you disagree with me by citing examples of people being inconsistent, and I don't know why! Being rabid about using your style (be it exceptionally well reasoned and much consistent) is still going to get you the boot in any outfit that values collaboration. Learn to deal with it or live unhappy everafter. Just argue for some reasonable style. Not your style! Let me quote John Ousterhout, emphasis his:

Don't change existing conventions. Resist the urge to "improve" on existing conventions. Having a "better idea" is not a sufficient excuse to introduce inconsistencies. Your new idea may indeed be better, but the value of consistency over inconsistency is almost always greater than the value of one approach over another. Before introducing inconsistent behavior, ask yourself two questions. First, do you have significant new information justifying your approach that wasn't available when the old convention was established? Second, is the new approach so much better that it is worth taking the time to update all of the old uses? If your organization agrees that the answers to both questions are "yes," then go ahead and make the upgrade; when you're done, there should be no sign of the old convention. However, you still run the risk that other developers will not know about the new convention, so they may reintroduce the old approach in the future. Overall, reconsidering established conventions is rarely a good use of developer time.
(Taken from: A philosophy of Software Design)

Somehow you took offense with commenters that suggested tools to enforce consistency. Because you presume that these tools would be used to enforce a style you don't like. Now according to you the people you were working with were not even follwoing their own style. As I said: My sympathy. But how would tools worsen the situation?

Frankly, I'd rather be a bank teller with programming projects at home than be subject to another style-only "code" review.

Yeah, reviewing style in a code-review is rarely useful. But why again were you in that situation? Was it because you were not willing to follow conventions? And was that because the conventions were shit? Or because the conventions were not yours?

pie_flavor

@gleemonk said in When the reviewer doesn't understand my Javascript it's his fault:

Being rabid about using your style (be it exceptionally well reasoned and much consistent) is still going to get you the boot in any outfit that values collaboration.

If "your" is taken literally. But in a project there should be a style and it should be followed rabidly.

Zenith

@gleemonk said in When the reviewer doesn't understand my Javascript it's his fault:

I think we're in agreement that consistency should be valued. Somehow you disagree with me by citing examples of people being inconsistent, and I don't know why! Being rabid about using your style (be it exceptionally well reasoned and much consistent) is still going to get you the boot in any outfit that values collaboration. Learn to deal with it or live unhappy everafter. Just argue for some reasonable style. Not your style! Let me quote John Ousterhout, emphasis his:

We are in agreement about consistency, to some degree. I disagree because I've had so much experience with inconsistency being passed off as consistency.

I also don't particularly believe in telling developers they can't ever do better than what somebody else already did. There's Not Invented Here and then there's Never Invented Here. Sometimes you have to write custom code because COTS doesn't cut it.

@gleemonk said in When the reviewer doesn't understand my Javascript it's his fault:

Somehow you took offense with commenters that suggested tools to enforce consistency. Because you presume that these tools would be used to enforce a style you don't like. Now according to you the people you were working with were not even follwoing their own style. As I said: My sympathy. But how would tools worsen the situation?

Because the tools don't enforce the necessary consistency. They don't force every function to have a try-catch-finally block that returns a default on failure. They don't force you to validate parameters. They don't force you to always return null or always return blank strings on bad lookups. They don't force you to check return values. They don't force you to order parameters consistently (think PHP and its string functions). They don't force you to spell column names correctly. They don't catch code duplication, off by one errors, unreleased handles, reading 700MB files into an array, and other stuff. It's all about how many spaces between operators and what line the brackets are on, stuff that's swept away by the compiler.

The example I gave about the stupid date lookback passed the ".NET 1.1 coding standards" document being force-fed at that time. It was camel cased. It explicitly included the System namespace. It used int instead of Int32. And it kicked back exceptions the first three months every year.

Speaking of .NET 1.1, they've never elaborated on why a 2-letter acronym is capitalized and a 3-letter acronym isn't. To me, that's confusing, because the capitalization in key to realizing that it's an acronym. In other words, consistency with English.

@gleemonk said in When the reviewer doesn't understand my Javascript it's his fault:

Yeah, reviewing style in a code-review is rarely useful. But why again were you in that situation? Was it because you were not willing to follow conventions? And was that because the conventions were shit? Or because the conventions were not yours?

I have actually thought about this. They were late (if ever) introductions, designed to be wielded as a weapon.

Job 3 (date lookback), the CIO who hired me moved on and my Indian supervisor brought on several hopelessly lost Indians. I mean like couldn't-get-a-console-project-to-print-hello-world lost. She never noticed how they spun their wheels for weeks because she was too busy harassing me. Nothing was ever right for her. She'd demand stuff like non-breaking text that didn't scroll or stretch the screen. Or demand every action trigger a post-back and then complain it was too slow. If I put all the code on the page, it was too confusing, if I put it all in a library, it was too confusing. Hated every name, never gave suggestions. Always "knew a guy" who could do whatever I did better but never produced a line of code for me to study.

When she called us in for "the talk" about four months in, I had questions prepared. I don't particularly like the .NET 1.1 "standard" because it has holes and I had them documented. After three or four, she called the meeting to a close, promising to pick up where we left off tomorrow and then never did. I had so many projects thrown away because she wouldn't let me help the person doing the other half and then she's going have us "save time" not initializing types? Come on.

Job 5 (headless msgbox), the "standard" was never provided to me. Most of my work was on a half-implemented module with really warped inheritance just because. Hopped between static calls, global variables, sometimes half-overridden functions, etc. Total war zone. This was actually the first job where I had to use a debugger because I couldn't follow what was happening where. Lots of variables called "i" and "n" with scoping issues that were mutated in ways VB.NET accepted for backwards compatibility but wouldn't fly in C#. I wasn't allowed to fix any structural issues so I did the best I could closing 20 or so tickets (that had sat for a year) with what I had to work with. I had even backwards-engineered an XML format that I was told was an "industry standard" until I asked for documentation and then suddenly it wasn't.

Anyway, I got smacked because I added a JavaScript validation function to a screen and Pascal cased it. Like half the JavaScript in the project. The developer who'd created much of this mess e-mailed me "a good developer follows established patterns" and copied the rest of the team. If that isn't passive aggressive, I don't know what is. I could've gone back and fixed every function to be Pascal but I didn't. But I'm a bad programmer because I didn't guess what style they wanted that day? Excuse me, your help desk being so overloaded that the developers have to take a turn every week suggests you might not be in a position to judge.

Job 6 (locked framework), the "standard" was sent to me five months in. It was half a page long and they "didn't have time to write it down" until then. I was super bored at that job. I had about a morning's worth of work each week and most of that was rework. They didn't like to close HTML tags, so they'd "fix" the global CSS to "solve" one problem and create a hundred more, which were suddenly "my" problem. Think something like negative margins to "hide" unclosed DIVs that suddenly made every textbox in the correctly structured parts of the application overlap.

So one day, after "we'd" missed a deadline for the umpteenth time (it was three times as many months late as I'd worked there), I get raked over the coals for "bad" code. They'd point out stuff that didn't violate any rule or ran afoul of two contradictory rules. When I was told to go back and "fix" my code, I asked if they'd be fixing a list of specific modules that also didn't follow the "standard." When they said they wouldn't because they didn't have time, I asked what made them think I had time? I was always harassed about time. I could change a hard-coded value a hundred times but never ever calculate it once. I could have that optimization done a week ago and be told it was too hard. I did that one because I was sick of "somebody" changing margins and whining about screens scrolling or having too much white space.

So after I changed this one class, for absolutely no functional reason, I left in one really ugly line. Amberlamps had a bug in his Entity/Unity wrapper that threw exceptions when an object was saved twice. I reported it the first week I was there and again two months later. When I was harassed about "my" code not working, I wrote this workaround. One line, no spaces, reflecting up through three layers of private objects to reset a flag that allowed the save to work. There's a comment that says "doing it Amberlamps' way triggers error '...' until the framework is fixed." Guess what set them off after I applied their "fixes." Guess what I filed another bug report on. Guess what I was told wouldn't be fixed. WTF was I supposed to do?

Maybe it's this area but there seems to be alot of people in development that just don't belong there. I mean, I want so much to say "not all rock stars are assholes" but I don't want to infer that I think I'm a rock star. I can't get my head around 2D game engines no matter how hard I try. But when everybody else is struggling with loops and arrays and comments, the nation's pets look like rock stars in comparison.

Edit: sorry about the edits...can't seem to make nested comments work with whatever not-BBcode this place uses...

Oh, also, I should add that one (3) was a new platform, one (6) was the third attempt following two failures, and one (5) was the first of two planned rewrites (VBS to VB.NET to C#). The only one that had much code done when I onboarded was the dual rewrite. And it was full of stuff that showed a lack of experience with C-based languages. Having ported a larger system from VB6 to C#, I thought they should listen to me when I did something differently. And, really, as often as I see these three particular jobs keep coming up, any argument for me being the common denominator here is rapidly falling apart.

pie_flavor

@Zenith It's nice to have job security.

Zenith

@pie_flavor said in When the reviewer doesn't understand my Javascript it's his fault:

@Zenith It's nice to have job security.

Biggest mistake I ever made was leaving a job where I had autonomy but stagnant pay for "better" opportunities in the private sector. I left some of those jobs but had a few months of unemployment between others. By the time I'd had enough and wanted to go back, outsourcing was in full swing and my choices were operations and management. They're both hell because you're still responsible for projects that fail but have zero ability to do anything about it.

pie_flavor

@Zenith I think that by the time I enter the workforce people will have wised up to the fact that cheap labor gets you cheapshit code.

loopback0

@pie_flavor said in When the reviewer doesn't understand my Javascript it's his fault:

I think that by the time I enter the workforce people will have wised up to the fact that cheap labor gets you cheapshit code.

This will absolutely not have happened

pie_flavor

@loopback0 Enough will have for me to get a job, anyway. And with colleges churning out CS grads like they're going out of style, the free market will surely take care of the rest.

dkf

@Zenith said in When the reviewer doesn't understand my Javascript it's his fault:

There are red flags and then there are nuclear-powered billboards that can be seen from Mars.

I like your turn of phrase!

dkf

@pie_flavor said in When the reviewer doesn't understand my Javascript it's his fault:

I think that by the time I enter the workforce people will have wised up to the fact that cheap labor gets you cheapshit code.

Some are wise to that. Some aren't. That's not changed at all for decades. Don't expect otherwise.

Try to find a good place. May you have the best of luck when your time comes to seek employment…

pie_flavor

@dkf There's several factors. Software development seems to have caught up with itself; we're focusing more on new things to do than new ways of doing the same thing. Wages are rising in outsourcing countries, especially India. And tech capitals are much less likely to outsource; I plan to live in one.

Carnage

@RobFreundlich said in When the reviewer doesn't understand my Javascript it's his fault:

It's the other direction that's the problem. When I'm doing a diff or a merge, I want to see it in my format. So there needs to be a get hook as well.

I worked at a project that did that some 10 years ago. There were no problems because of that while I was there at least.

loopback0

@pie_flavor said in When the reviewer doesn't understand my Javascript it's his fault:

Wages are rising in outsourcing countries, especially India.

If that's true, the result will just be slightly less cheap (but still relatively cheap) shit. The quality isn't improving.

@dkf said in When the reviewer doesn't understand my Javascript it's his fault:

Some are wise to that. Some aren't. That's not changed at all for decades. Don't expect otherwise.

This.

I'm not saying you won't be able to find one of the good places, just don't expect the whole industry to have changed.

Carnage

@pie_flavor said in When the reviewer doesn't understand my Javascript it's his fault:

Software development seems to have caught up with itself; we're focusing more on new things to do than new ways of doing the same thing.

Not really, no. If anything, doing the same thing in a new, slightly different way has accelerated during my time in the field.

pie_flavor

@loopback0 said in When the reviewer doesn't understand my Javascript it's his fault:

If that's true, the result will just be slightly less cheap (but still relatively cheap) shit. The quality isn't improving.

Right, but the people who accept 'you get what you pay for' and outsource anyway will become fewer as they start paying more for less.

HardwareGeek

@pie_flavor said in When the reviewer doesn't understand my Javascript it's his fault:

And tech capitals are much less likely to outsource

In my experience living and working in Silly Valley, tech giants are very likely to both outsource and offshore. All of my jobs for the last 10+ years have been or started as an outsourced worker. Offshoring is also rampant; the only difference is that the company has its own office in Outer Oobleckistan, rather than outsourcing to the lowest bidder there. Whether this makes a significant difference in the quality of the work is debatable, but it still means somebody in Outer Oobleckistan has a job instead of a US tech capital worker.

Carnage

@pie_flavor said in When the reviewer doesn't understand my Javascript it's his fault:

@loopback0 said in When the reviewer doesn't understand my Javascript it's his fault:

If that's true, the result will just be slightly less cheap (but still relatively cheap) shit. The quality isn't improving.

Right, but the people who accept 'you get what you pay for' and outsource anyway will become fewer as they start paying more for less.

The only shift I've seen in my backwater shithole is that most companies realized they get shit quality from offshored development, so they keep the really important stuff inhouse, everything else gets sent offshore. The stuff that is on its way out get the cheapest shit offshore crap devs.
There are still plenty of companies that flat out see IT as nothing but bleeding money, and to them, paying less seems like a good idea.

Gribnit

@pie_flavor said in When the reviewer doesn't understand my Javascript it's his fault:

tech capitals are much less likely to outsource

that's not true. They spin up offshore teams from there and then you have to fucking manage them.

Zenith

@pie_flavor said in When the reviewer doesn't understand my Javascript it's his fault:

Right, but the people who accept 'you get what you pay for' and outsource anyway will become fewer as they start paying more for less.

You'd think that. If you owned a small company, you might learn, because it was your money at stake. But a larger company or government, it's not your money, so there's no consequence to giving the contract to your friend and his army of "guest workers." I can tell you right now, at the low end, state government pays $100/hour for H1Bs while an Application Developer 2 is maybe $50/hour including benefits. And the ratio of H1B to AD2 is like 10:1. The theory is the H1Bs will come in, do a job, and go away, taking their costs with them, but they never do.

What I'd found in state government was that this practice drove off people with hands-on experience, leaving an upper management that didn't know how to do what it was managing. It's like the crooked mechanic billing thousands in repairs to the little old lady who knows nothing about the car she only drives on Sundays. Except these idiots are paid six figures to flush hundreds of millions of our tax dollars down the toilet.

Gribnit

@Zenith this is also how banks operate.

Shoreline

@gleemonk Interesting. A few points...

People who use phrases like "you know that don't you" usually deserve atomisation.
was the correct emoticon. Good work.
"This is how JS is written" and you still haven't slashed his throat. You're a very patient human. Excellent work.
I've used timeouts in some places for async operations which don't have a callback of their own. I commented accordingly and hated myself and the world for making me do it, also accordingly. I don't trust this guy with timeouts.
I'm not clear on why you can't use promises. X-Browser? Maybe I am perfectly clear on why (IE is another abomination altogether).
There's no excuse for a 200 multi-indentation, multi-callback function.
Get him to agree to listen or be fired. Ego is for those with expertise, who must learn to manage their ego.

Basically I come here to be angry.

Shoreline

@gleemonk Just realised this post is a month old and you answered most of my concerns. Nothing to see here... move along.

boomzilla

@pie_flavor said in When the reviewer doesn't understand my Javascript it's his fault:

@Zenith I think that by the time I enter the workforce people will have wised up to the fact that cheap labor gets you cheapshit code.

So you're planning to be a professional student?

jinpa

@Shoreline said in When the reviewer doesn't understand my Javascript it's his fault:

@gleemonk Interesting. A few points...

People who use phrases like "you know that don't you" usually deserve atomisation.

Eh. Sometimes you need to find out whether the person you're talking to is the one who doesn't understand something, or you are. Seems a reasonable question, depending on how it's said.

stillwater

@Shoreline said in When the reviewer doesn't understand my Javascript it's his fault:

This is how JS is written" and you still haven't slashed his throat. You're a very patient human. Excellent work.

@gleemonk should get more credit for this than anything. I would have lost it. How someone can be patient and not get ticked off in this scenario is pure magic to me.

gleemonk

Finally getting there: Applied prettier to all files.

The biggest source of diffs was that wrote if(condition) { and wrote if( condition ) { (though with forgetting the space before the closing paren half the time). I don't know how either got the idea, I just tried not to squint every other line while reading. Glad this is over.

dkf

@gleemonk said in When the reviewer doesn't understand my Javascript it's his fault:

Glad this is over.

No more ?

brie

@gleemonk said in When the reviewer doesn't understand my Javascript it's his fault:

Finally getting there: Applied prettier to all files.

The biggest source of diffs was that wrote if(condition) { and wrote if( condition ) { (though with forgetting the space before the closing paren half the time). I don't know how either got the idea, I just tried not to squint every other line while reading. Glad this is over.

So you fixed them both to if (condition) {?

HardwareGeek

@brie said in When the reviewer doesn't understand my Javascript it's his fault:

@gleemonk said in When the reviewer doesn't understand my Javascript it's his fault:

Finally getting there: Applied prettier to all files.

The biggest source of diffs was that wrote if(condition) { and wrote if( condition ) { (though with forgetting the space before the closing paren half the time). I don't know how either got the idea, I just tried not to squint every other line while reading. Glad this is over.

So you fixed them both to if (condition) {?

No.

if (condition)
{

dcon

@HardwareGeek said in When the reviewer doesn't understand my Javascript it's his fault:

@brie said in When the reviewer doesn't understand my Javascript it's his fault:

@gleemonk said in When the reviewer doesn't understand my Javascript it's his fault:

Finally getting there: Applied prettier to all files.

The biggest source of diffs was that wrote if(condition) { and wrote if( condition ) { (though with forgetting the space before the closing paren half the time). I don't know how either got the idea, I just tried not to squint every other line while reading. Glad this is over.

So you fixed them both to if (condition) {?

No.
if (condition)
{

I wish that was our code standard (it is mine!). Ours is:

if (condition) {
    // stuff
} else {
    // other stuff
}

Oh, except when it's:

if (condition) {
} else
if (condition) {
}
...

Zecc

@dcon said in When the reviewer doesn't understand my Javascript it's his fault:

Oh, except when it's:
} else
if (condition) {

dcon

@Zecc said in When the reviewer doesn't understand my Javascript it's his fault:

Yes. I always have to double check. Is this multiple ifs or a cascading if? Oh, and fight with Visual Studio because it doesn't like that style either. (I should just turn style stuff off in VS...)

Gąska

@HardwareGeek said in When the reviewer doesn't understand my Javascript it's his fault:

@brie said in When the reviewer doesn't understand my Javascript it's his fault:

@gleemonk said in When the reviewer doesn't understand my Javascript it's his fault:

Finally getting there: Applied prettier to all files.

The biggest source of diffs was that wrote if(condition) { and wrote if( condition ) { (though with forgetting the space before the closing paren half the time). I don't know how either got the idea, I just tried not to squint every other line while reading. Glad this is over.

So you fixed them both to if (condition) {?

No.
if (condition)
{

Careful, this is JavaScript, a rigorous use of K&R can give you a very bad time.

boomzilla

@brie said in When the reviewer doesn't understand my Javascript it's his fault:

@gleemonk said in When the reviewer doesn't understand my Javascript it's his fault:

Finally getting there: Applied prettier to all files.

The biggest source of diffs was that wrote if(condition) { and wrote if( condition ) { (though with forgetting the space before the closing paren half the time). I don't know how either got the idea, I just tried not to squint every other line while reading. Glad this is over.

So you fixed them both to if (condition) {?

is up with that brain fart of a format?

HardwareGeek

@Gąska Speaking of which, I wonder what ever became of my old, 1st-edition, pre-ANSI copy of K&R. I'm sure I didn't throw it away, but I haven't seen it in ages.

Gąska

@HardwareGeek excuse my offtopic, but since this already came up - I've seen somewhere that in the first versions of C, a function's local variables would always go after the argument list and before opening bracket. Is that true?

HardwareGeek

@Gąska Yes. It's been a very long time since I used pre-ANSI C, so I had to look it up to double-check my memory. See the answers to this SO question for syntax examples:

What are the major differences between ANSI C and K&R C?

The Wikipedia article on ANSI C says: One of the aims of the ANSI C standardization process was to produce a superset of K&R C (the first published standard), incorporating many of the unoff...