Context matters. This is a forum full of programmers talking to other programmers. Within this group of people, preferences for certain languages or frameworks or techniques or jobs or programming styles or whatever are obviously a lot more valid than preferences for certain types of wine or for thinking software engineering sucks as a career, because those preferences are educated, based on actual expertise/experience, and relevant to a common foundation of programming we all share.

How is this a serious post you think is worthy of discussion here? I think Grue is right and you just shouldn't be engaged.

Like, you think I'm not fulfilled with what I'm doing now because I wrote that sentence? lol, wow, okay.

adios, how do you defend this garbage?

Yep, I'm done. Sorry for derailing the thread everyone.

This is incredible. We've had like multiple decades of completely useless flame wars on the supposed superiority or inferiority of various programming languages - this is literally documented on the first wiki ever:

http://c2.com/cgi/wiki?HolyWar

Pretty much. It's really hard for someone who understands what it means to be fulfilled to not realize that others are able to find fulfillment in things that they don't enjoy themselves.

No one said the truth has to be comfortable. Let's not suddenly pretend that kids in their first few jobs aren't insecure about status.

Doesn't have an entry for "finds flame wars useless vs enjoys flame wars", worst wiki entry ever

I'm even okay with a flame war because often people will make interesting points or share interesting perspectives. What's uniquely terrible about ChrisV/goofy/Craggoo's posts here is that they are not even bothering to make an argument. There's this bizarre presumption that because it's a personal preference it doesn't have to be defended but because we're in a programming forum something something, it matters.

Writing unit tests kind of sucks, but manual testing, debugging, executing just to eye-ball results (which is manual testing) sucks even more.

Writing unit tests sucks, but having them is completely awesome, and with very few exceptions I've never worked somewhere where someone else is going to write them for me, so...

I am in the middle of a very dicey refactor and I am loving my unit tests *so much* right now.

I love writing unit tests because they make you think about software design from a different perspective and force you take software engineering seriously but I'm a confirmed weirdo.

Yeah I've never heard of unit tests being written by someone else. When you have software engineers in test or QA//test-automation engineers, their work is focused on functional/integration/performance/etc tests and building tools that make it easier to write tests, not writing unit tests because it's actually hard to write unit tests without also owning the code and the design to some extent. Then again, testing is not an area where people tend to use terms correctly so he may have meant automated tests instead of unit tests.

Honestly I've never really even had someone else to write *any* tests of any kind. When I worked at places that had QA departments they did most of their testing by hand as far as I can tell.

And all superiority complexes aside, I am quite sure I do not want to do that.

If you don't find something to like at most programming jobs you may want to consider another line of work. I love what I do. Even when I was working on the most god-awful legacy crap imaginable - I took pride in coming up with creative ways to debug it and throw die in the water. It wasn't my favorite programming ever, but it still beats every other job I've ever had - including poker.

The only kind of programming that is not fun at all for me is boredom because I don't have anything to do.

Even repetitive stuff where I've already solved every technical challenge and am just doing the programming equivalent of taking out the trash - is a great opportunity to come up with innovative ways to automate and streamline the workflow.

Having said that, I have worked with PHP for a year or so and am glad I had the experience. I don't think it's any worse than anything else for what it needs to do. At this point in my career, as primarily a JS/node developer after 10 years in the J2EE world, I find deep Java inheritance structures and factories of factories a lot more annoying than PHP.

At the mongo class I took the teacher had a C# version of the same hackathon app everyone in the world does - a group voting app on where to eat lunch. He had about 30 class files with massive inheritance, abstract classes and factories for everything. I could to the exact same thing in a few node modules of less than 50 lines each.

I assume he did it for edification purposes - but why would you even take a chance kids will think this is a good way to create a small app? It's not even a good way to create a large app. Bleh.

Good video on inheritance vs. composition. I think I posted it before but anyway it's good.

Refactoring is where unit tests really shine. Which makes devs actually enjoy refactoring. Which leads to more frequent refactoring. Which is a very good thing.

Yeah at the startup we're actually doing unit testing, after like 50 failed attempts to get it off the ground (on a non-optional basis) at the place I've been working. It's such a game changer.

I was able to easily refactor another devs giant 400-line spaghetti code into independent modules, because the one good thing he did was set up cucumber tests for everything (which aren't even unit tests, but they go against stub data so they're close enough). Now I catch so many things writing cucumber tests as I go which would have been caught much later, possibly not even until production.

It is sometimes hard to get management to let you focus on unit testing, because it's very time consuming. A change that takes 5 minutes and 5 LOC might take a half a day to really test.

The project I'm on now is an API - some of it is customer facing and some is consumed only by the front end. There is really no sane way for me to code at all imo except to write basic tests for the feature I'm adding, then write the feature until it passes the tests, and then fill out more defensive tests to poke at the edges of it. I can't wait for the API because who knows when the FE guy will get to it, plus he's more or less waiting for me.

(We are working on getting a good API contract thing going but not much traction so far)

Have you tried swagger? I love it.

We are "using" swagger but pretty badly. It is just extract docstrings from our classes to generate docs. I did not design this thing and I hate most things about it.

I'm pretty sure we're going to use RAML.

Gonna give jest a try, looks pretty great.

let's all just love each other, okay?

@ suzzer: yeah you shared that one. it introduced me to that channel, which i still watch all the time. feels like it's gotten less about code and more about philosophicalish stuff relating to being a coder. I still watch every episode because I like that guys vibe.

Just realized it's a little strange that I use all this Facebook stuff and I dislike them so much that I block them at the hosts level..

What's the best/better way of doing this:

Right now I have something that needs to get done that usually happens but if it doesn't it needs to be redone (involving random of course).

So to do that right now I have a let foo = false at the top and then define a function that does the random thing, inside of which it assigns foo to true if the condition happened.

Then I invoke the function, and then I have a while loop on !foo that calls the function. Reason for all of this is that foo does not always have to be true to continue based on some user settings and the loop is wrapped in an if.

I thought this is fine but eslint has a "no-unmodified-loop-condition" which says that if what is being evaluated in the while loop isn't being changed in the body of the loop it fails the eslint rule, which sort of makes since, but of course I'm really doing that just in the function which was defined outside of the loop. Is what I'm doing fine and this is just a failure of the linter, or is there a better way hopefully without side effects?

Hope that made sense.

That does sound pretty bad - so your function is modifying some outer variable and your loop is relying on this side effect? It seems like the function itself should return true or false and that should be your loop condition. Hard to say more without knowing the specifics.

yeah, just return the condition from your function

of course if the loop doesn't need to do anything else you can just say

You know I thought about that but thats not really semantically what the function does, it does other side-effecty things and returns void. Thus I wouldn't even know what to name it... IDK I'll think about it. The assignment now is inside of another foreach loop inside of that function so I would have to do another 2nd level side effect and return that!

This is way too complicated to explain in typing.

TIL [].forEach returns undefined well thats helpful.