When it first started a couple of years ago, the agreement (as it was explained to us) was basically Ars Technica gets new content in areas they don't normally have good coverage in (in this case, workplace issues for programmers) while Stack Exchange otensibly gets more exposure. The actual content creators (question askers and answerers) are not compensated in any way beyond the normal SE gamification features that kick in when a question becomes popular on the network.
I don't know if Ars Technica now decides on their own what questions to feature, but when the partnership started, Stack Exchange itself was actually deciding which questions to feature.
N.B. SE also had a Lifehacker content-sharing agreement a couple of years back, but I don't know if that's still going on.
I don't think they give a f*ck that someone on hackernews happens to notice it on Ars rather than SE.
I find Ars to be one of the better web publications out there. Until theverge came along, I would say they were bar none the best.
It's 2013. Articles are text. This is silly.
Social sites including HN matter so much to these sites that many of them (not Ars) including media giants have been caught spamming them many, many, many, many times to pull the traffic, the SEO link juice and the viral spread of their shitty rewrites, rewordings, and repostings.
So it's possible that the other programmers are actually just causing more bugs than this person, jumping in to band aid a fix and maybe causing another bug in the process.
This sort of whack-a-mole looks very productive on a bug tracker.
We have quite large code base and my colleague and I are the only people developing it - and all the original devs left long time ago. I spent last three weeks chasing down a very peculiar race condition, which in theory couldn't happen. Finally I discovered a bug, mostly by accident, in one of the in-house libraries the project uses. It was unexpected to say the least, because I was told many times over that "the library code is ok, check your own". It took me another week to fix the bug, because it was really complex and even "less my own" than the code of the actual project.
In the same time my colleague fixed a multitude of bugs (mostly in our, "fresh" code) and implemented three new features.
Which means I should get fired... Hopefully, I won't - our boss is a technical person, a programmer with many years of experience, and I believe he will be just happy that the bug finally went away. But, you know - what if he retires? What if I find myself managed by someone who doesn't know the difference between wading through thousands of lines of code and years of accumulated cruft, deprecated apis and inaccurate or completely missing comments?
I think the OP should - he did this already, as he wrote in the second update to the post - just find a new, better job. The environment and management which only watched him struggle in silence and then fired him make no good place to work.
1. Get more tickets that show progress and work on both. The hard one that takes you a week and some filler-nonsense that makes you look good in terms of progress and number of tickets closed.
2. Play the ball back to the manager and discuss the in-house-library problem with him. Make it a problem for him that he needs to solve. It clearly is anyway, because you got a broken in-house library and were told that it is fine. It wasn't, thus, management problem.
Tell him that you found the bug and solved it and that you wonder how many hours other developers wasted on a bug like that before, but now it's gone (communicate that you provided value by reducing maintenance cost in the long term and that other developers probably struggled with the same problem and didn't solve it).
Then ask him how both of you should deal with situations like that in the future. Apparently, if you were told that the library is fine but it isn't, you can't complete your tickets on time. Ask him how he wants you to communicate problems like that the next time this happens and how he can allocate more resources to you if it happens.
The idea is to make the manager perceive you as someone, who is eager to solve problems, but needs a reliable working environment. Make the manager responsible for setting up this environment. This way, you communicate strength, because you are not that dumbass slow developer who accepts everything as is, but someone who proactively creates a sane working environment.
Notes: If your manager is nuts, it won't work. If it was a minor problem, do not make a big problem out of it but still mention it. Since it took you a week, it doesn't seem to be a minor problem though.
I found that the overall performance of a programmer is very hard to judge from the outside, especially from less-technical managers. But managers are there to allocate resources and track progress.
Tracking progress is the most single crucial thing for them. They want those tickets closed and they don't care about the bug. They don't understand that 1 line code might take a week and at other times, you do 500 lines of (easy) code in a few hours.
Getting a negative review could mean from the manager's perspective: You don't appear to make much progress. The solution then is not necessarily to become faster (although that might be an issue as well), but to learn to communicate in a manager-oriented way.
This could be a very simple status update email once per day and a summary of progress once a week. Don't communicate weakness ("I'm very slow at this"), but problems and their solutions. E. g. "The multi-threading task was implemented in a very inefficient way before. Occasionally, it leads to errors that are very uncommon and thus hard to trace. I'm working on it and I have an idea for a good solution that will increase performance as well, but it might take a bit more time."
Or turn the task back to him: "I can't reproduce the error in a reliable way. Could you please provide test cases / test data that lead to this error?"
These might be some more or less contrived examples, but you get the gist.
I'm going to reply to your comment, so that in case you will say something worthwhile in your future edit, I could edit my reply to your reply if I think there's anything else to say.
If you truly believe that learning to be a better communicator is extremely easy, why would you need to state that prior to several paragraphs of explaining how to be a better communicator?
Ask any educator about the effectiveness of lectures beginning with "X is easy, just follow these 5 weird tips!"
Either the 5 tips are trivial, or you were lying about it being easy.
And yes, these tips are utterly trivial but nonetheless important. Do you write status report emails?
I'd assume the department responsible for debugging kernel driver bugs is far less interrupt-driven than the operations-oriented departments I base my experiences on. The common thread though, was usually about prioritizing between the work we already roughly understood how to do. The more common communication failures were about coordinating and scheduling. But when you're doing something specialized enough as debugging multi-threaded embedded drivers, and you have a specific metric like bug closure rate, then all of that information is already captured in the bug log.
The first response in the Ars thread says that keeping detailed notes for yourself is both a powerful tool to help you learn, and also a tool for communicating in very specific ways with the rest of the department. One reason better communication isn't a "very easy fix" is that multiple people are involved, and you can't just force everyone to pay attention to all the relevant information already available.
Alternatively: I worked on a small development team / startup with daily stand-ups that would tend to last 15 or even 30 minutes. Not a single person in the room ever seemed to know what they were going to say prior to opening their mouths. No amount of "leading by example" seemed to convey the concept that summarization is the most important feature to communication in daily status meetings.
Every software company - or so it looks from my anecdotal experience - has one of more of these positions. It seems to be more rampant in larger companies or companies carrying a lot of legacy code.
Nonetheless, I've seen this pattern consistently in QA and Rel-Eng groups where the impossible expectation of delivering quality out of incomplete and poorly designed products.
It's also funny that usually the ones building new things - vs fixing / delivering things - are the ones getting the highest compensations.
Managerial: Ask how to improve. Are bugs being prioritized properly? If some level of management is not involved in prioritizing bugs, ask them to take and look and prioritize. It is not enough for you to think "hmm .. no hurry to fix this bug for the next release 'cos its a very obscure case and there are these other important ones to tackle first."
Self management: If you're overwhelmed by many bugs and are zombied about where to begin or touch next, just pick whatever looks the easiest to fix and fix it, irrespective of priority (and loop that). This at least gets some momentum going. A management that expects bugs to be fixed exactly in the prioritized order is ignorant. That's not how systems fail. What might be thought of as trivial might turn out to be very significant, and vice versa.
How can one get better at debugging in general?
(My context is that I know there are two types of programers:
Type 1 programmers, what I call "starters, imagineers and architects" - great at starting things from nothing/scratch/blank-piece-of-paper or at completely rewriting and (re)architecting an existing piece of software, but horrible at fixing/debugging things, and
Type 2 programmers, what I call "uberhackers and master fixers" - great at finding bugs (and either fixing them or exploiting them for good or evil) and at fixing and understanding existing systems, but horrible at starting things from scratch, like they totally "mindfreeze" if you put them in a blank-piece-of-paper situation and desperately search for something that already exists to adapt for solving the existing problem, even if nothing really fits well, or in the end they start but with a very hacky badly-architected design that degenerates into a mess that only other uberhackers and master fixers can use and understand.
And I know that I am a Type 1 guy, but I really want to get better at Type 2 tasks.)
I treat anyone who claims he's a pure type 1 programmer with suspicion. I seriously question anyone can be good at the type 1 work and be bad at the type 2 work. There are a lot of programmers out there who hate doing the type 2 work though.
On the other hand there are also a lot of people out there who really shouldn't be doing any programming at all. They usually end up getting stuck in type 2 work and maybe reinforce the idea that a distinction between type 1 and 2 programmers could be made. But the reality is they should probably choose another profession entirely.
I have been in similar situation before. I joined team with absolutely un-maintainable code. Build process took 1 hour, was semi-manual and involved 3 machines. This was mission critical application, but management rejected any sort of investment into maintainability. We made QA builds only once a month, because it was too tricky to test and verify entire app.
I fought back and cleaned worse mess in my free time. I automated and virtualized build into single machine. I wrote 'sort of' integration tests to automatically verify build. At end we even had continuous integration.
But it was not me who benefited from improved productivity. Number of closed bugs in UI skyrocketed. But I usually do hard & sneaky concurrency issues, which were still hard to fix. At end I was marked as 'unproductive' and eventually quit.
I think that you need some kind of troubleshooting aptitude to be a programmer, but the reality is that the variance is quite significant. In a land where not all bugs are created equal this multiplies the results people get.
I think it's OK to acknowledge weaknesses, and to hand-off certain tasks to those who excel at them, i.e. "Rod is a gun troubleshooter, let's give this one to him".
The whole agile idea of spreading the tasks around equally is such a naive practice, and a great way of wasting customers and employers money. In a world dominated by so called best practices we're just going to suffer these kinds of results ad infinitum.
Maybe you just suck at solving bugs? Maybe you are amazing at feature development and UI design. Great! Do what you're good at.
From here it's collecting three things, answers to future questions, better understanding of the system, and more efficient ways of finding out about a bug. These three complete each other and would help you reach faster either the solution, or the question to your colleague/friend/support person/IRC/forum/other.
You do have extensive logging, especially around the buggy code?
Do you have source-level debugger that shows your variables and that can step/trace through code?
These are the 2 tools that I have found most indispensible when squashing bugs in the past. Somehow source-level debugging seems to have disappeared from the developer's toolbox the last couple of years. I am told you don't need it anymore as you can write tests (???).
The only thing the OP needs to get better at is giving interviews.