How Completely Messed Up Practices Become Normal

Speaking of completely messaged up...

I had to add max-width, margin, and font-size styles before I could even attempt to read that page. For all that markup, there sure wasn't any attention payed to readability.

There's a variety of things you can still do as a middle-tier or above engineer to try to change the situation. (Very junior engineers are advised to A: watch how the situation develops with those poor practices and learn and if ambitious B: find a mid-tier or above engineer to ally with for these matters. You lack the social capital on your own to do much.) In my experience, at least with my development style, writing unit tests is either a net time wash or for larger systems, a net time gain [1], so use them. Even if nobody else runs them, you still get a better system out of them, and you get to run them when somebody complains. You can use analysis tools on your own code. You can set up an instance of a build server even if nobody else has one, and have it monitor your unit tests and other tools and fix things as others hack on your code. Etc. etc.

There's two basic outcomes that can happen here. Either you become a leader, and gradually and often quite begrudgingly at first, people start following when they see how well it works. (Unit tests can be a real eye opener sometimes, especially when you start having reasonable cause to show how the problem is unlikely in your code, being either in the other code or the specifications.) Or you get quashed from above. Contrary to the cynical answer, the latter is not inevitable, but it is certainly a possible outcome. At that point, yeah, it's just time to say you got some valuable experience and move on.

What you MUST NOT do is simply whine... from the point of view of those above, anyhow. Even if it's perfectly sensible complaints from your point of view that are all but objectively correct, it's unlikely to be heard as anything but whining. You need to lead by example. You also very much need to do so with some idea of cost/benefits analysis; you can't go from no discipline at all to a perfectly disciplined project in one step, so consider your steps carefully. Keep them small; stay away from "big rewrites". (Probably the biggest failure case I've seen is someone who thinks that code X is in the wrong paradigm and sets out to entirely rewrite it to make it "better". YMMV but in my personal experience this is usually someone who thinks the code needs to be OO, or a different kind of OO. This is guaranteed failure. Even at surprisingly small scales! You destroy everybody else's knowledge of the code.)

And I'll say it again to underline it... the cynical answer that this is impossible is wrong. It certainly won't be easy, but I can guarantee great growth as a developer if you follow this path, both technically and in dealing with people. Even if you have to change jobs.

As for the bottom line point, arguably you have a duty as a professional developer to be doing this stuff I describe, precisely because it does mean resources are being continuously and avoidably drained on issues that shouldn't exist. If you find yourself unable to discharge it, you should find somewhere you can.

[1]: I like to say that it lets me develop with monotonic forward progress. I even use unit tests during prototype work quite often, after I got sick of the way during prototyping I couldn't count on anything to work, ever, due to changes, and I realized that itself was actually inhibiting my prototyping ability. Sure, sometimes I dump entire subsystems but even then it was usually because the unit tests showed me a fundamental flaw far earlier than the rest of my prototyping would have, and I do so with far more information about the local landscape than I would otherwise have had.

This line perplexed and disturbed me: "...This is the same company where someone recently explained to me how great it is that, instead of using data to make decisions, we use political connections, and that the idea of making decisions based on data is a myth anyway; no one does that...."

One, that is depressing and implies the company seems to have a corrupting influence on society at large.

Two. The girl is right and it is called insider information. Another corrupting aspect of our society.

In other words, corruption is a new viable normal and workers have no problem with it because most workers are all desperate and happy to have a passport to middle or upper middle class.

I think it corresponds to a lot of normal practice - even if you don't use @flaky, if one build fails and you run it again and it passes, what do you do? It's very possible to build tests that will pass sometimes if the code is correct and fail always if the code is wrong (e.g. test where there are race conditions in mock initialization, test that asserts that rows come out of a database in the same order they were put in). IME that comes up much more often than a test that will pass always if the code is correct and fail sometimes if the code is wrong. It's not pretty and it usually indicates underlying poor design but it may be the pragmatic option.

Yeah...I mostly have experience only running test suites for popular libraries and for my own software...but the existence of this library is a massive WTF...such that had I read its official introductory post, I would have thought it to be really good satire:

https://www.box.com/blog/introducing-flaky-a-nose-test-plugi...

Can someone describe a real life production scenario in which this flaky behavior is desirable? That is, preferable to these other generally accepted practices:

- flag the test and mark the bug as an issue and at some point, attempt to fix it

- delete the test, if it happens to relate to dead code or was poorly conceived in the first place

- use fixtures and other libraries to mock dependencies, e.g. Webmock and/or vcr to intercept http request and respond with a pre-recorded fixture.

I understand that there are scenarios in which production most go on even when a test fails. But to throw on another testing layer that tells you, "hey, it kind of works, for some unknown reason", instead of just marking the test as a failure to be investigated...what possible value or insight could outweigh the additional noise generated? I guess one possibility is that it lets you know that something is truly fucked up...but that is not at all the tone of the Box blog announcement:

> When testing Sync 4, Box's desktop sync application, we also ran into this issue, but we also didn't want to simply remove our flaky tests. When we noticed that most flaky tests would pass when rerun, we realized we could make doing so automatic. Flaky is a nose plugin that can rerun flaky tests without interrupting your test run. Using it is as easy as decorating your test methods with @flaky