We also score a 1 on the Joel test, and that's because I helped setup a version control server soon after arrival. We could score around a 4-5 if the emergency project I'm working on to switch platforms ever hit production, but it's been nearly a year of "it's a month away, you need to scramble to get it done in time or the company goes under".
I wonder if perhaps I should start looking for new employment or something....
Then our Director (also a developer) told us "this SVN thing isn't useful" and demanded that we stop using version control. Then he saw Mantis (our bug tracker) and complained about how ugly it was. Instead of choosing a prettier one, we had to use his Excel spreadsheets on the local fileshare. It got worse and worse until our 7 went back to a 2 in about 60 days.
Six months later, 8 of the 10 had left. Even the people who hadn't originally been on board with the changes but saw the benefits left.
Similar story here, but it's a problem when most of the Joel points are only held up by one person. Eg only one person is driving the version control (managing the server, making people use it, and making people use it. Also making people use it.) Or only one person can be expected to clean up the project so it builds in one action, and you're then also the only person who can document this build action. Or only one person is running the bug DB, and others are resistant to using it. Or only one guy is reading about new tools.
When that happens, your Joel score isn't really a 7 or whatever. Or it's a very fragile 7.
I do remember an incident where a guy who'd worked for 7 years with us wondered out loud whether there was some magical piece of software that could tell you what the production code was on a given day in the past. That's the kind of thing that makes your respect for the guy collapse.
A few other team members were convinced later because we jsut had a batter clue of what was going on, what we were planning to do, and what was deployed.
This definitely wasn't a lone wolf effort.
> Even the people who hadn't originally been on board with the changes but saw the benefits left.
That must provide at least the feeling you and your co-workers had done good things. Keep it up.
The rest is much harder to influence and make happen, but if you can't get a bug database to happen before your new-person enthusiasm / grace period ends then I'd jump ship.
I've a bunch of experience working for places which don't score well on the Joel test. It's not the end of the world but you will have to make adjustments so you don't dream of better while reading about how other people have build systems which spin up instances and run integration tests on every check-in while simultaneously running machine learning over their live logging for early fault detection.
Remember those kind of things are the exception rather than the norm and focus on the things you can change.
You probably have a month or two more before your "I can fix this!" attitude fades and you end up the jaded developer that you saw when you arrived and wondered, "how do they put up with this environment?".
It's a one, it's so bad to get to a one, you might not even get a computer to work on!
If (when, really) the productivity gains come, management will notice and you'll be known as that person who improved things. This will give you good favour.
And if it doesn't work out, next time you get asked in interview, "What are some challenges you have faced?" you can talk about how you introduced Git and JIRA to a company that didn't have source control and bug tracking. You can talk about how you tried to change a company culture from hand-editing files in production to having deployment scripts. You can talk about the challenges you faced. It gives you a clear answer to "Why are you leaving?", you can talk honestly about your expectations in terms of what a company should provide for its developers, talk about how your current company isn't or wasn't meeting those and use that to indirectly talk about how much of the joel test the prospective company can meet.
It will give you a fresh sense of perspective too. In the future when you're struggling with a build system you can think, "well at least we're better than we were at Initrode".
And maybe it's just a really nice place to work, not all work is about being as efficient as possible at all times. Sometimes you can stand back and realise that while other teams could do what you're doing in half the time, you're still getting paid to do this job and maybe your colleagues are warm and friendly.
Management let it get this bad, what makes you think they will appreciate you improving things?
The company simply doesn't value your environment or it wouldn't be like that. You are young and naive to think you can improve things and get credit.
I have attempted on multiple occasions to encourage others to use something, anything with me, but to no avail.
The standard response when you bring up a bug is "we have too many emergencies going on right now, we can't handle that until someone notices it and says something", which is usually the point where it becomes an emergency. :\
I have good reason to work here, but it's quickly getting drowned out by the reasons to run to the hills.