My boss just gave me a warning. Is there a way to get faster at solving bugs? | Hacker News Reader

My boss just gave me a warning. Is there a way to get faster at solving bugs?

arstechnica.com

48 pointsshawndumas42 comments

Blogspam. Original content here: http://programmers.stackexchange.com/questions/197675/is-the...

Ars republishes good SE articles from time to time. It is not about link spam, but rather about promoting SE on Ars, and vice versa. I think this approach is quite reasonable.

I don't think they give a f*ck that someone on hackernews happens to notice it on Ars rather than SE.

It really is pretty much spam. It's pageview-bait at its finest. (And that's one of the main reasons I've filtered Ars's non-forum stuff, I've been a subscriber there for years but I'm not giving them pageviews for bad articles anymore.)

Ars writers have been very honest about their use of pagination. Sometimes, I guess it is to get more hits, often its just a way of breaking up the story and to reduce page load time. If you are a subscriber, don't you get access to PDF or something like that?

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.

often its just a way of breaking up the story and to reduce page load time

It's 2013. Articles are text. This is silly.

Articles are text with huge images. Believe it or not, a page still loads slowly for those of us in 2nd world countries behind great firewalls. Also, I think pagerank still takes page load times into account, so putting everything into one giant long page would actually hurt their google rankings.

I say SO on Ars is not blogspam because unlike, say, most everything on Lifehacker, the content on Ars is not a thin veneer of bullshit/fluff designed to position an ad between the user and actual content.

How is it different from hackernews? They are using content from another website to create traffic and content on their own, pretty much the same thing hacker news is doing.

It's not about promoting SE on Ars, it's about free content that pulls from social sites.

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.

To put some context on this: Ars Technica is republishing this under the full cooperation of Stack Exchange in a capacity that goes beyond simply obeying the letter of the CC-BY-SA license on the content.

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[1], but I don't know if that's still going on.

[1]: http://meta.stackoverflow.com/questions/119398/do-lifehacker...

It may be fancy/legit, but it is blogspam.

Thanks for posting the original link to SE, it has so much more valuable content that garbage articles on Ars..

Can we discuss what's said in the post, instead of adding meta comment spam?

It tends to be easier to fix bugs that you caused yourself. You see something blow up and you can think "yea, that's because I did thing X in Y to achieve Z".

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.

The manager in this case seems like a flake; using a stupid metric to justify a pre-determined review score (stackrank scores are usually based on perception, not reality) rather than coming up with some better fiction.

Yeah, reading this question I started to feel anxious about my own employment. I am almost afraid to go to work on Monday.

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.

You should do two things:

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.

If you're so fearful of your job you should quit right away. It's not healthy to live like that.

That was a bit of sarcasm. Sorry I didn't make it clearer.

There's clearly one very easy fix that nobody seems to have mentioned so far: Communicate in a better way.

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 read the rest of this comment about the "very easy fix" of communicating better, and then edit my reply if I think there's anything else to say.

> I'm going to read the rest of this comment about the "very easy fix" of communicating better, and then edit my reply if I think there's anything else to say.

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.

I was quite honest about what literally happened there.

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.

Becoming a better communicator surely requires practise, but there are some very easy steps that produce instant results. Short daily status emails and/or weekly email status reports are EASY and yet it isn't done by all developers. This is waaaay easier than improving your skills on debugging multi-threaded systems. The latter is definitely a noble goal, but will fail short if you don't even write that stupid status report once in a while.

And yes, these tips are utterly trivial but nonetheless important. Do you write status report emails?

I do write status report emails, but that kind of communication has operated very differently at every different organization I've worked in.

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.

Thanks for sharing your experience.

Precarious position to be in when you have to clean up after others, and these 'others' are not pro-actively helping you out, or have no incentive to do so.

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.

Technical: The "break out the notebook" is close. Use the scientific method in your debugging. By this I mean form hypotheses about the bug and test them ... rinse and repeat. The important bit here is that you keep track of the hypotheses you come up with and the way you tested them. This track serves as proof of your work that you can ask for a co-worker to examine for its effectiveness. You don't need to do all the hypotheses testing yourself if your hypothesize about some part of the system that a colleague is more familiar with. No shame in asking for help here, even if it is repeatedly denied.

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.

I think there is an interesting generalization of this question:

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 think you're generalizing too much yourself here, there is no distinct line between the two types you mention. I know enough programmers that are capable of doing both things you mention pretty much equally well, this seems especially the case for those with >10 years of experience. This is already indicated by the description of the first type as being able to "completely rewrite and (re)architect an existing piece of software": that imo implies being able to "fix and understand an existing system" as you describe the second type. If you program long enough, you should be able to both start from scratch and hack into existing code. Unless you're just not good enough or have some weird split personality :]

...you're kind of right, I know that I am getting better at what I call "type 2 tasks", but I'm desperately looking for any shortcut that will allow me to get better at it faster :) (I don't have > 10 years experience)

Not really relevant to OP. But I've seen parents distinction being made in companies more than once. They basically let the 'senior' programmers create new products and features (type 1 work). They let the 'junior' programmers do the maintenance on the results (type 2 work). The biggest problem with this organisation is that there is no feedback loop for the 'senior' programmers. They can mass produce garbage code and not worry about the consequences at all. Often the 'senior' programmers even start looking down on the 'junior' programmers for being merely maintenance programmers. Which is obviously messed up.

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.

Just give your boss what he wants. Optimize for metric "number of bugs solved". Fighting back costs way to much energy and is usually useless.

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.

Troubleshooting is a skill like any other, and naturally different programmers have different aptitudes with all of the skills.

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.

Once reported/found, study the bug, reproduce it, debug it, and try to understand as much as you can about it, but once you get stuck, even for a couple of minutes, take all that you have found about it, form a simple, clear way of presenting this problem to someone else, contact that person and deliver the explanation.

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.

May I offer some practical advice?

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 (???).

Supporting your suggestion; I find that GDB is the best weapon in my arsenal. I am also fond of assertions that end the app and squawk loudly if a constraint is unmet.

A job is not a marriage. If you start having problems respond by looking for another job. A job that gives you lots of stress or makes you feel bad is not good for your health or well being. And I would normally advise against trying to "fix it" as well. That process itself is always stressful and rarely results in anything except recommendations about how you can change.

The only thing the OP needs to get better at is giving interviews.

Sure, have the code better organized and documented with good test buckets at each level of integration. And when that approach is widely taken by supervisors who ask such questions, a person can get rich selling cast iron umbrellas to protect against the giant flocks of flying pigs.

I would ask the boss to sit down with me and give me some guidance and advice on how to improve.

unit testing!

He's just pressuring you to work longer hours. That's cheaper for him but abusive to you.

Reply on news.ycombinator.com