Hacker News Reader

Taking to an internet forum to vent personal grievances is a shaky business. The audience is ever-eager for red meat, but that doesn't make it ok. There is also the question of how low you really want to go. And HN has rules that you need to abide by if you want to comment here.

Here you go below what's acceptable by HN's civility rule:

> The CEO of Freelancer.com is a complete jerk.

And here the bottom falls out altogether:

> gossip going round that the CEO had sex with a female employee and she got pregnant

Please don't sling mud like that here, regardless of how disgruntly you feel or how justified your grievances are.

https://news.ycombinator.com/newsguidelines.html

> because I was too slow to implement a feature because I was spending extra time writing tests.

This. Just yesterday, I was asked by an interviewer at a Startup. "How do you test your code? Do you write tests? What's your familiarity with TDD."

My answer: "I prefer to do a test driven approach. However, none of the companies I worked for allocated time for writing tests in the sprint, so I have not been able to actually do this in practice. I usually debug my code and run it through all the happy path and edge cases."

Was bitten once very early in my career just like OP, and decided to only write tests after initial coding, if there was time left. Most (not all) Companies expect you to do TDD, but never allocate time for it in the estimation. So I've made it a point to ask the PM if there was time allowed for writing tests in the estimate, and if they say something like "Oh no we don't have time for that" I don't do it.

I couldn't imagine to work without writing tests and I firmly believe it actually makes me quicker than manual coding. Sure, if you aim for 100% code coverage it takes time, but instead of trying out my code a few times, I just write those try-outs as tests and am happy ever after.

I don't really mention tests to my management. To me, they are just part of coding. My coworkers don't mind, they are happy when maintaining or changing my code that they have tests for support.

This, exactly this. I've felt the same increase in development velocity; and an equal increase in confidence. I'm able to deliver systems and walk away with 99% confidence that no one is going to come back to me with a problem. And if they do, it's easy enough to write a regression test to prove the problem and then fix it.

I've adopted your same approach. I don't mention testing, but I'll be damned if I'll ever write a piece of code without it.

The light-bulb moment for me was when I realized that testing happens one way or another. Either you're in the console manually setting up and running everything... or you could just write a program (a test) to do the same thing for you. Once I realized that, I never looked back!

I just started learning how to write tests for my APIs. Changed my life! Now when I need to make broad changes I can easily tell what needs to be fixed because my tests cover each end point with multiple success and failure cases. Love it.

Maybe you can help me understand something because I hear this a lot. You manually debug and run your code through "the happy path and edge cases", if I'm understanding you correctly... so, does it really take that much longer to write an automated test that does the same thing?

What I'm saying is if we accept the company's viewpoint as truth -- I don't -- then you'd just be writing code and handing it over. No testing. No execution. No nothing. But if you have time to manually test the code, then it sounds like you have time to write automated tests.

Now, I'm with you, these tests aren't going to be beautiful or well-factored, but they'll be helpful to you, right? That way you don't have to manually test the code over and over again.

On the other side of the coin, I've taken on the practice of including time necessary for testing in my estimates (as an employee and contractor). If a manager doesn't want to accept that, then they can fire me, because that manager is fully incompetent -- no ifs ands or buts. As a professional, I need to operate with a test-driven approach. It's the only way to deliver complex systems with confidence.

Testing happens one way or another.

Having automated tests written mean that future changes that break the existing code will cause the test to fail - that's the advantage.

Having automated tests also means that future changes can break the existing tests and force you to rewrite them.

As the saying goes, you don't have to test all your code, only the code that's supposed to work. I don't give estimates that exclude tests for the same reason I don't give estimates for pseudocode that nearly compiles.

Sounds like you learned a valuable life lesson.

It's always been obvious that freelancer had no test platform and that they would simply push releases to production and wait for things to break, and then maybe fix them.

The most interesting lesson from this was that this attitude has no apparent downside. Users either don't care, don't even notice, or sadly, may have no choice given that there are not many sites that fill this niche.

The company went public a few years ago, investors have no clue as to what's under the hood, and tbh it doesn't seem to matter much.

It's interesting to see what freelancer is doing now that they are accountable. Me, I think it will be more of the same.

In their defense, the one thing that bothers me most is if I specifically tell someone to code something a certain way (for example, to skip tests on this project), and they don't listen and do it anyway because "it's the right way." I on the other hand know what is right for my project... not the person I'm hiring. That's why I asked X person to do it a specific way.

Btw Im not saying they arent toxic, they sound like pieces of shit. Just pointing it out more generally.

They didn't give me any instructions about how to implement the feature. I had just arrived 2 weeks earlier and there was a lot of code there so it would have been impossible for me to get it to work (without breaking existing stuff) if I did not write tests.

Also this is a company that handles business transactions; high-value stuff; there should have been more tests.

Fair enough, sounds like a horrible place to work. D:

>Several of these horrible people went on to work for Facebook later.

Seems like they're a better fit anyway for the company of "move fast and break things".

I'm a slightly longer term ex-Freelancer employee whose tenure overlapped with Jon's, and I feel like I should say that my experience wasn't that bad.

As I suspect afflicts many companies, when I joined it was struggling with the transition between "hack something together so that we make some money" and "we need to care about the long term". Not to mention the usual small-ish company disregard for HR niceties. It didn't finish that transition while I was there - and may still not have - but I mostly had a good time (worked on a huge variety of stuff, and even wrote a bunch of tests).

Also, though there were other factors, I think the primary reason retention was low is that Freelancer's hiring policy was geared towards 'cheap grads', so people tended to leave for better paying positions elsewhere.

PS Hi Jon - sorry you had that experience. I wasn't privy to exactly why you were let go.

PPS And yes, I think there were definitely parts of Freelancer which were (IMO) far too focused on making money without caring about the customer experience. On the other hand, capitalism (argh).