New Yorp New Yorp posted:

Code coverage does not guarantee that code is bug-free or well-tested, just that someone has attempted to test it. Code coverage requirements are just asking to be gamed.

TooMuchAbstraction posted:

How do y'all get your junior teammates to build better software? At the moment all of my code reviews are involving a lot of back-and-forth because they're sending poo poo out for review really before it's ready. I remain hopeful that they're capable of better (i.e. they're not just crappy devs) but I don't know how to go about improving their output.

On a related note, how do you get your teammates to do more rigorous code reviews? Because those not-really-ready change lists are getting a pass from other teammates despite glaring flaws.

TooMuchAbstraction posted:

• Comments that assume you already have context on the problem the code is solving.
  

redleader posted:

Oooh, this is a tricky one, and I'm probably guilty of it myself. I find there's often stuff that if you're looking at it in any depth, you need to have some context on the issue at hand already.

Or maybe that's just what I tell myself, and I just write lovely comments...

leper khan posted:

Depends the level of assumed knowledge of the reader. There are definitely things that a random practitioner may not know that everyone in a sub field should.

If no one will ever benefit from the comment, it’s not helpful.

Then again, that’s exactly the argument maths PhD’s make when authoring whatever thing they’re doing. So maybe the assumed reader should always be a novice.

Ither posted:

How often do you all ask for raises? Once a year?

Cuntpunch posted:

I am assuming you're talking about folks who are clearly engaged with the work and otherwise enthusiastic - but just can't seem to give a drat about quality?
I've got a pet theory that this is especially common in software mostly because of the esoteric prestige that comes with BEING A COMPUTER PROGRAMMER! You get folks who love being a programmer more than they really love programming. Who get seduced by the feeling of 'oh gently caress yes everyone thinks I'm a supergenius when I tell them I WRITE SOFTWARE' rather than loving the work itself enough to give a poo poo about the bigger picture.

(Note, this isn't necessarily limited to programming and tech, but I think it's more prevalent here)

Ither posted:

How often do you all ask for raises? Once a year?

minato posted:

New Yorp New Yorp posted:

I don't ask. I just get them during my annual review. And they're usually good, between 5-15%.

Slimy Hog posted:

Is that standard? My company's engineering department just decided that we "need" to have 3 standard buckets for raises: 3%, 5% and 7%; no higher unless you're getting promoted.

TooMuchAbstraction posted:

3% is usually a pay cut when accounting for inflation.

Slimy Hog posted:

Is that standard? My company's engineering department just decided that we "need" to have 3 standard buckets for raises: 3%, 5% and 7%; no higher unless you're getting promoted.

TooMuchAbstraction posted:

It also bears mentioning that some of the people contributing software on my team are not formally-trained software engineers. My team does hybrid science/software work, so we have people who did other stuff in college than take three years of software deep dive courses, and their industry experience is at a lab bench rather than a desk. Otherwise, the main issue the team has is that it's very junior.

Rocko Bonaparte posted:

2. They think they're God's Gift to Software because they aced the lovely programming class they took in college in their major so you're just some rear end in a top hat to them.

TooMuchAbstraction posted:

On a related note, how do you get your teammates to do more rigorous code reviews? Because those not-really-ready change lists are getting a pass from other teammates despite glaring flaws.

TooMuchAbstraction posted:

This isn't failing to hew to specs. But, uh, some examples...

• code:

  for x in y:
    if z:
      <entire rest of for loop>
  

  (where it'd be preferable to say "if not z: continue" to avoid excessive indenting)
  
• Skipping writing tests, and pulling the old "I'll write the tests after this gets checked in" when they get called on it.
  
• Excessively over-extended functions (well over 100 lines long when there are clear points where they could be decomposed)
  
• Confusingly-named variables, and variables and functions that shadow other ones in the same scope
  
• Lists that should be sets, tuples that should be structs / named tuples, multiple arrays that have to be kept in sync (using the same index in each to access different aspects of the same data) rather than a single array holding a complex datatype.
  
• Throwing together six unrelated things into one gigantic change instead of breaking them out into smaller ones.
  
• Comments that assume you already have context on the problem the code is solving.
  
• Declaring a boolean as foo = False if bar else True. This one always makes me sad to see.

For the most part these don't on their own represent huge problems. I very rarely have to say "no, stop, this is a fundamentally wrong approach." But I end up with like 20-30 nitpicks and requests for changes and clarification even on relatively small changes. What worries me is that they don't seem to be getting better at this: I'm seeing the same categories of mistakes being made repeatedly by the same people.

TooMuchAbstraction posted:

[*]Throwing together six unrelated things into one gigantic change instead of breaking them out into smaller ones.

LLSix posted:

Some good pithy advice links including my favorite: "Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live." ― John Woods

Rocko Bonaparte posted:

1. The code is an auxiliary task for them that they don't care about at all.

TooMuchAbstraction posted:

I can definitely confirm that I was a snotty little poo poo as a young programmer and had to have the ego beaten out of me. So yeah, there's some truth there.

return0 posted:

Uncomfortable with how little controversy there was about code coverage; it is bad!

vonnegutt posted:

As soon as there is a number attached to code coverage you get management trying to reward/punish based on that number. Never make an easily-measured number a proxy for code quality.

vonnegutt posted:

As soon as there is a number attached to code coverage you get management trying to reward/punish based on that number. Never make an easily-measured number a proxy for code quality.

baquerd posted:

If upper management wants numbers, they will get their numbers.

vonnegutt posted:

I've witnessed formerly unconcerned management suddenly get obsessed with metrics once a metric was enabled. Especially a non-tech management when presented with a metric that supposedly measures something un-measureable. And very few people are content to see a number stay the same - they want it to go up. Once it can't go up any higher, then it becomes punishable if it drops. Keeping code coverage at 100% is much more difficult than keeping it at 95%, for very little actual quality gain.

TooMuchAbstraction posted:

I'm curious how you get 100% code coverage in cases like this:

TooMuchAbstraction posted:

My guess is that feedback isn't given because nobody wants to go anywhere near the realm of hiring discrimination, so even if they could accurately say "you didn't get hired because you punched your interviewer in the face and then shat in their coffee" they wouldn't. Much safer to leave it as a completely opaque process that generates results which were unfortunately not favorable in your case.

TooMuchAbstraction posted:

Interviewing is a skill and takes practice. You're also at the whims of your interviewers, so e.g. just because you passed a question may not mean that you passed it "hard enough" for someone with your experience level. Like, they might have this idea that anyone with over X years of experience ought to be able to solve their pet problem in five minutes. Basically it's a crapshoot. You can influence your prospects by practicing, but you can't guarantee that good interviewing skills will let you pass any given interview.

GeorgieMordor posted:

Frustratingly it definitely is seeming that way. Any advice on how to practice interviewing specifically? Are there coding exercise tools that are better suited for that than others, perhaps?

TooMuchAbstraction posted:

as an interviewer here's what I'm looking for from the interviewee, more or less in order:

• They demonstrate that they understand the problem. This includes things like clarifying what exactly the limits on the inputs are and what kind of output I want, and describing some examples and what their expected outputs would be.
  
• They talk as they think. Like, "Hm, my first thought would be to use a map to represent the grid edges." Interviewees that fall silent while they think make it hard for me to understand how they're approaching the problem.
  
• They come up with a rough sketch of a solution before they start coding. This doesn't have to be written down but I should be able to understand the algorithm they plan on using before they start coding. Interview questions are chosen to not be immediately obvious in how they should be solved, so typically if you dive in and start writing code without a reasonably complete plan, you're going to make mistakes. You have limited time to solve the problem and I have follow-on questions I want to ask, so the less time you spend going "oh wait, actually I need to do this a different way", the better.
  
• They can come up with a workable solution in something closely approximating a real programming language (i.e. not completely pseudocode).
  
• They can test and analyze their solution by stepping through it and identifying what each line is doing.

Your goal is to convince the interviewer that you have all of the above skills. That involves a lot of talking and maybe some diagrams that you typically wouldn't produce when writing code for your job.

TooMuchAbstraction posted:

TooMuchAbstraction posted:

I'm curious how you get 100% code coverage in cases like this:

code:

object, err := json.Unmarshal("[1, 2, 3]".([]byte))
if err != nil {
  returns errors.New("Welp, I guess our CPU is corrupt.")
}

In other words, technically json.Unmarshal can return an error, and the proper style is to "handle" that error (by propagating it up the call stack, because Go thinks exceptions are bad and therefore you must badly re-implement them with every function call), but in practice the error can't be triggered because you're passing the function a known-valid input.

TooMuchAbstraction posted:

Practice by interviewing. I guess you could also find a collection of interview questions, and then practice by bringing up a question you haven't seen before, then standing in front of a whiteboard and out-loud talking through how you'd solve it, then writing out your solution on the whiteboard. Actually writing code for a bunch of problems (like Advent of Code or Project Euler or whatever) can be a good way to get practice at solving little problems, too.

I know you didn't specifically ask for this, but as an interviewer here's what I'm looking for from the interviewee, more or less in order:

• They demonstrate that they understand the problem. This includes things like clarifying what exactly the limits on the inputs are and what kind of output I want, and describing some examples and what their expected outputs would be.
  
• They talk as they think. Like, "Hm, my first thought would be to use a map to represent the grid edges." Interviewees that fall silent while they think make it hard for me to understand how they're approaching the problem.
  
• They come up with a rough sketch of a solution before they start coding. This doesn't have to be written down but I should be able to understand the algorithm they plan on using before they start coding. Interview questions are chosen to not be immediately obvious in how they should be solved, so typically if you dive in and start writing code without a reasonably complete plan, you're going to make mistakes. You have limited time to solve the problem and I have follow-on questions I want to ask, so the less time you spend going "oh wait, actually I need to do this a different way", the better.
  
• They can come up with a workable solution in something closely approximating a real programming language (i.e. not completely pseudocode).
  
• They can test and analyze their solution by stepping through it and identifying what each line is doing.

Your goal is to convince the interviewer that you have all of the above skills. That involves a lot of talking and maybe some diagrams that you typically wouldn't produce when writing code for your job.