Reviving a 19 Year Old Test to See If an Employer Is Worth Working For | Hacker News Reader

Reviving a 19 Year Old Test to See If an Employer Is Worth Working For

alcamine.com

8 pointsardme6 comments

It's absolutely shocking how many companies don't understand how important these points on the Joel Test are. I forget who made an amended version of this list to change "best tools money can buy" to "giving developers wide allowance in buying tools and hardware which make their job easier. Sometimes this is a 3rd or 4th monitor; sometimes it's a $1500 chair that is so comfortable and makes back pain disappear so that one can concentrate on a feature/bug fix for hours without needing to get up and stretch (yes, a personal thing for me), or non-standard-issue software/tooling like GitKracken or RedGate or BeyondCompare or Sublime Text....

Managers complain about spending so much money that's not in the budget but how much does turnover cost you in terms of lost productivity and recruiting fees?

(And speaking of recruiting fees: why are companies willing to pay $20k or more to recruiters but only a $500 for a referral from current employees? Recruiters in the midwest pay $1000 or more for referrals who get hired -- companies are telling their employees that it's in their interest to tell their qualified friend/lead to contact the recruiter instead of doing an internal referral.)

What's the standard issue alternative of sublime text?

I would like to hear some comments about: "I like having dedicated testers on my team but many places don’t anymore and if you have a good process in place for automated testing you can do just fine."

In the 1990s, I recall (perhaps wrongly) one of the Microsoft books talking about one tester for every two developers.

At the tail end of the 1990s, I worked as a developer in a group with a QA team, and they caught bugs, including ones where it took me a while to even see there was a bug. Which means that I couldn't have written the tests for them.

Nowadays, I do consulting/contract programming, and my clients always do manual testing of what I shipped them, before signing off on the payment. That's in addition to the unit tests I write. And they find bugs.

So, what does it mean "if you have a good process in place for automated testing you can do just fine"? Does it mean that it's okay to let your users be your QA group, since there's a process for handling that?

Or is it something else I don't know about, given that I'm a one-person developer?

Dedicated testers can be quite skilled at figuring out ways to break software (sometimes annoyingly so). As a dev I'm usually thinking of how to make my apps work, not how to make them fail.

Unit tests: certainly good, but on one team I recall there being the phrase that a good integration test was worth 1000 unit tests: if the individual parts work but they don't work together correctly as a whole system then what practical value was our unit test?

The unit tests and integration tests serve different primary functions. There may be some overlap, but if you’re good at writing them, then you already know about that and can minimize that.

Yeah, I can expand on that. What I meant is that when I have been on teams that are basically just writing services that we are exposing via an API, it has been sufficient to just have really great test coverage and monitoring.

When I have been on teams that are doing a whole vertical as part of a product that includes UI work, it has generally been nicer to have real dedicated testers on the team.

So because I think you can't really generally say what is going to be enough, I think you just need to ask people about their process and decide based on what the project is.

Reply on news.ycombinator.com