|
I would not be surprised at all if the response is, “I couldn’t get the tests to pass so I changed stuff until they did”, with no understanding of the point of the tests that were failing.
|
#
?
Jul 12, 2019 04:58
|
|
|
|
| # ? May 9, 2024 14:16 |
|
|
Just file a bug ticket and fix it. Don't throw anyone under the bus or anything. It's not worth it.
|
|
#
?
Jul 12, 2019 11:42
|
|
|
Blinkz0rz posted:Just file a bug ticket and fix it. Don't throw anyone under the bus or anything. It's not worth it. That's going to make noise in the backlog, since it isn't 'a bug' - it's the failure of a developer to do their job properly, and possibly with intent. If you let this stuff go, it starts to seep into the organization, because other folks will take notice, his work-buddy will hear about how he totally got past the annoying unit tests by just changing a namespace, and inside a year, it's gone from 'let's fix this now and not do it again' to 'welp, there is two weeks of tech debt to fix these mistakes' - and that's a much harder sell.
|
|
#
?
Jul 12, 2019 12:18
|
|
|
Fine make it a story and alert your PM that it needs to be handled immediately. Throwing coworkers under the bus is a lovely thing to do. You're on the same team with the same goal so act like it.
|
|
#
?
Jul 12, 2019 12:26
|
|
|
vonnegutt posted:Sounds pretty sketchy but I've always found it best to go in with a fact-finding attitude first rather than a blame-y one. It could be that this dev didn't realize how the test suite used the namespace and didn't realize his tests weren't running. It's unlikely but it could happen. I like this response but if you prefer not to have actual interaction with someone who does this
|
|
#
?
Jul 12, 2019 12:33
|
|
|
Blinkz0rz posted:Just file a bug ticket and fix it. Don't throw anyone under the bus or anything. It's not worth it. I agree with this one, but I'd also probably just fix it then and there without a ticket. Then probably just flick the original dev an email and be like, "hey, noticed you did this thing, I've fixed it up, here's the PR, can you approve it". If there mistake was genuine then you've hopefully shown them they made a mistake without fuss and they can learn? If they did it on purpose, then now they know you found it and it didn't just slide under the bus. If they keep constantly pulling this poo poo then yeah I guess escalate it to your technical lead or whatever.
|
|
#
?
Jul 12, 2019 12:38
|
|
|
Cuntpunch posted:That's going to make noise in the backlog, since it isn't 'a bug' - it's the failure of a developer to do their job properly, and possibly with intent. Almost all bugs I encounter are due to a developer not doing their job properly. I know it is the case for most bugs I write. Example: we had a problem where an API call to a 3rd party suddenly started failing. You could say: "They changed the API, bad 3rd party!" but while they in fact changed the API to better follow the standards, our handling of the new situation was wrong from the start. I can give more details, it was actually a funny situation. For connecting to the API, we (I) generated a java client based on their OpenAPI spec. This caused problems but prevented more, so I'd do it again. Anyway, the code generator is java 7+ and therefor uses org.threeten.OffsetDateTime. We develop in OpenJDK11 and thus can use java.time.ZonedDateTime. These two contain the same information but I cannot take one and create another, you have to go through ... something. I choose to go through a String with specific formatting because.. I dunno, it made sense and it worked. At least, it worked until the API we used started doing what they promised in the spec saying that a specific time property would be rounded to the nearest 5 minutes! In the json we would get from the http request, the property would contain 0's for seconds and for nanoseconds. And for some reason I don't understand, this was rendered to OffsetDateTime as null for seconds and nanoseconds... and thus would not be parsed in toString, causing the DateTimeSerializer that I told there would be seconds and nanoseconds to barf a "WrongCharacterAtPosition" error (or something). HOWEVER... the try/catch block only caught a very narrow exception in another line, so this error did not even show up in the logs. We found this when using the received response from the 3rd party API in our integration test as a mock content, I was glad we had that in place. Solution: parse through EpochSeconds. Nowhere in this situation did I think of: a) running extensive unittests on the String-to-ZonedTimeDate for all possible permutations of the incoming time b) put a mock in place that would actually have matched the requirements c) translating through String was a bad idea. Cherry on the cake was the part where it was me who pointed out to the devs that their specs say "rounded to 5 mins" but the API returned "whatever nanosecond we feel like" so I brought it upon myself in multiple levels. So tell me, did I fail or succeed as a developer?
|
|
#
?
Jul 12, 2019 12:52
|
|
|
Xik posted:I agree with this one, but I'd also probably just fix it then and there without a ticket. Then probably just flick the original dev an email and be like, "hey, noticed you did this thing, I've fixed it up, here's the PR, can you approve it". I basically did this, mentioned I needed to do some extra work on his entities as there were some naming standard issues I noticed. Offhandedly mentioned the way he'd made the namespaces were hiding the entities from the unit test. He didn't get all mad or anything and just agreed with me that we'd solve the issue.
|
|
#
?
Jul 12, 2019 14:39
|
|
|
Keetron posted:Almost all bugs I encounter are due to a developer not doing their job properly. I know it is the case for most bugs I write. You didn't intentionally sabotage your project by knowingly checking in code to avoid team standards? I mean, that sure sounds like doing your job just fine. The problem here isn't 'bugs' or 'wow poo poo I didn't think of that' - it's that if a developer on the team is intentionally undermining the quality of the project, then the project has cancer. Treat with mentoring, education, and - as a last resort - management.
|
|
#
?
Jul 12, 2019 19:27
|
|
|
So someone sent around that DoD written article about Agile BS in organizations to our development department and our Development Manager and CDO (Chief Development Officer) threw a fit. Our processes have been exposed in a way that I guess embarrasses them politically. Any ways, they didn't fully shut it down so maybe it will be healthy in the end for the department but I got an earful about it as I am seen as a leader on the team of the dev who sent it around. Lol, it turns out the dev that sent this around was explicitly told to do this by the Owner/President of the company so in reality he superseded no one. He did exactly what the owner of the company told him to do. Le Saboteur fucked around with this message at 22:17 on Jul 12, 2019 |
|
#
?
Jul 12, 2019 21:47
|
|
|
Don't you love being "seen as a leader"? I get lectured by management about tiny, ticky-tacky perceived things I've done "wrong" because "everyone on the team looks up to you and  "
|
|
#
?
Jul 12, 2019 22:00
|
|
|
Where does “changing code but not the tests because it still had 100% coverage” fall on the list of dev sins?
|
|
#
?
Jul 13, 2019 00:04
|
|
|
If you are "seen as a[the] leader" then you need to get paid for it. That is some bs statement some a bad employer would whip out to get effort/experience they don't want to pay for.
downout fucked around with this message at 02:55 on Jul 13, 2019 |
|
#
?
Jul 13, 2019 01:40
|
|
|
My wife just got a job that pays a fair amount more than me and is very secure so I'll be shopping myself around real soon. I'd only been sticking it out here, and earning quite a bit below the local market average, because I was the bread winner for so long and it was stable.
|
|
#
?
Jul 13, 2019 01:43
|
|
|
smackfu posted:Where does “changing code but not the tests because it still had 100% coverage” fall on the list of dev sins? A change of the micro implementation without breaking any of the testable surface is the most perfect of changes. Unless you mean, "we changed the contracts/api but our tests still have 100% so it's fine  " in which case I guess they weren't accurate tests to begin with and the 100% coverage figure was a lie.
|
|
#
?
Jul 13, 2019 02:13
|
|
|
downout posted:If you are "seen as a[the] leader" then you need to paid for it. That is some bs statement some a bad employer would whip out to get effort/experience they don't want to pay for. That’s what they did to me at my old job. I said if you’d value me as much as you say you do, you’d give me a raise. Yeah, they never did, and were yet shocked when I put in my two weeks.
|
|
#
?
Jul 13, 2019 02:24
|
|
|
Protocol7 posted:That’s what they did to me at my old job. I said if you’d value me as much as you say you do, you’d give me a raise. Needless to say a lot of people are unhappy with our manager and executive responsible for the department and there is now a meeting booked with the owner of the company to figure out why his decision to tell our developer to pass around that DoD article and a survey to get some reflection on our process should be overturned by the manager and the executive. This dev in particular has had the ear of our owner for some time and the owner related to him how he has suspected his management hasn't been being truthful with him and how frustrated with one of our long term projects being a money pit (a heavily mismanaged project). Knives out on Monday.
|
|
#
?
Jul 13, 2019 02:27
|
|
|
Le Saboteur posted:Needless to say a lot of people are unhappy with our manager and executive responsible for the department and there is now a meeting booked with the owner of the company to figure out why his decision to tell our developer to pass around that DoD article and a survey to get some reflection on our process should be overturned by the manager and the executive. This dev in particular has had the ear of our owner for some time and the owner related to him how he has suspected his management hasn't been being truthful with him and how frustrated with one of our long term projects being a money pit (a heavily mismanaged project). Maybe good? It's my understanding that DoD article (assuming I'm thinking of the right one) is pretty valid. Although, I'd be suspect about an owner telling a dev to pass around an article behind the managers back because apparently the owner can't call out these deficiencies to the manager directly?
|
|
#
?
Jul 13, 2019 02:59
|
|
|
downout posted:Maybe good? It's my understanding that DoD article (assuming I'm thinking of the right one) is pretty valid. Although, I'd be suspect about an owner telling a dev to pass around an article behind the managers back because apparently the owner can't call out these deficiencies to the manager directly? Almost as if he had a theory that what he was told and what was actually happening were two different things and he wanted to test that.
|
|
#
?
Jul 13, 2019 03:02
|
|
|
downout posted:Maybe good? It's my understanding that DoD article (assuming I'm thinking of the right one) is pretty valid. Although, I'd be suspect about an owner telling a dev to pass around an article behind the managers back because apparently the owner can't call out these deficiencies to the manager directly? It wasn't meant to be behind the managers back. The dev had no idea of a process for this sort of thing where we are just using the article to reflect on our agile process having to go through our management. the owner just told him you should send it around to the rest of the department and he did. And as a dev with almost 10 years at this company I didn't either, they just basically came around after it was out saying no you should have sent this to us first THATS THE PROCESS while also saying we have no problem with this survey or article. Le Saboteur fucked around with this message at 03:04 on Jul 13, 2019 |
|
#
?
Jul 13, 2019 03:02
|
|
|
Keetron posted:Almost all bugs I encounter are due to a developer not doing their job properly. I know it is the case for most bugs I write. Agree with this and the guy who said don't throw your co-worker under the bus. Unless they are using software to plan a terrorist attack or embezzle money in which case yeah report them. But if they are seemingly trying to sneakily evade the unit tests, try to handle it with them privately first.
|
|
#
?
Jul 13, 2019 03:41
|
|
|
Le Saboteur posted:It wasn't meant to be behind the managers back. The dev had no idea of a process for this sort of thing where we are just using the article to reflect on our agile process having to go through our management. the owner just told him you should send it around to the rest of the department and he did. And as a dev with almost 10 years at this company I didn't either, they just basically came around after it was out saying no you should have sent this to us first THATS THE PROCESS while also saying we have no problem with this survey or article. That's unfortunate, hopefully everyone is ok with some toes being stepped on. Especially if it was in good purpose. I'd be super happy with a dev calling out improvements than can be made, and it'd be bad for one to take a bad rap for just trying to make things better.
|
|
#
?
Jul 13, 2019 04:57
|
|
|
Xik posted:Unless you mean, "we changed the contracts/api but our tests still have 100% so it's fine It's not a lie. This comes up in this thread all the time so I hate to repeat it yet again, but code coverage is not an indication of correctness or quality.
|
|
#
?
Jul 13, 2019 05:52
|
|
|
My Rhythmic Crotch posted:Don't you love being "seen as a leader"? I get lectured by management about tiny, ticky-tacky perceived things I've done "wrong" because "everyone on the team looks up to you and I got that once. I thought it was a nice compliment, though. It made me feel empowered to tell the other developers that they needed to be interviewing at other companies at least once a quarter. I told them what my salary was and I told them what companies I was interviewing at and how it went. Several of them took my advice and got better jobs shortly after I left, so I really was a leader.
|
|
#
?
Jul 13, 2019 05:53
|
|
|
New Yorp New Yorp posted:It's not a lie. This comes up in this thread all the time so I hate to repeat it yet again, but code coverage is not an indication of correctness or quality.  arguing about semantics. If all your tests are complete garbage but they make the coverage tool report 100% then it's a "lie". When normal, even marginally competent developers talk about "coverage" and throw coverage stats around what they mean is "covered with half decent/useful tests" not, I twiddled with this tool to report the number 100. If you write garbage tests just to make the coverage report ding to 100% and then say "we have coverage of 100%" to other people you are lying. There is an implicit agreement when you use words with other technical people. Like, if someone asks me if I wrote tests for my PR and I say yes, then they expect I wrote useful tests not wrote empty tests just so I can say that I wrote tests.
|
|
#
?
Jul 13, 2019 06:24
|
|
|
Xik posted:
Or you're mocking out service calls that have changed in some format during your update. Your unit tests can be perfectly reasonable and test the logic itself, but you're not going to be able to meaningfully test calling out to any service dependencies with coverage unit tests alone. That's what good integrations tests are for. But who writes those? 
|
|
#
?
Jul 13, 2019 12:02
|
|
|
Le Saboteur posted:So someone sent around that DoD written article about Agile BS in organizations to our development department and our Development Manager and CDO (Chief Development Officer) threw a fit. Our processes have been exposed in a way that I guess embarrasses them politically. Any ways, they didn't fully shut it down so maybe it will be healthy in the end for the department but I got an earful about it as I am seen as a leader on the team of the dev who sent it around. Hah, I remember reading that article and thinking they nailed our organization. Although it's mostly government pushing waterfall-style deadlines and big releases, while the prime contractor insists that what we do is agile.
|
|
#
?
Jul 13, 2019 12:47
|
|
|
Xik posted:A change of the micro implementation without breaking any of the testable surface is the most perfect of changes.
|
|
#
?
Jul 13, 2019 13:13
|
|
|
smackfu posted:In this case, they fixed a bug and didn’t update any tests. "I don't understand why I have to test for a bug that's never gonna happen again, I fixed it"
|
|
#
?
Jul 13, 2019 14:45
|
|
|
If you fix a known bug, don't update tests, and they still pass shame on you; your tests aren't testing what you think they are. If you refactor a private api and your tests still pass then congrats, your tests are either good enough to test the public api that consumes the changes or worthless enough that they aren't exercising the public api as much as they should. Which one is the case? 
|
|
#
?
Jul 13, 2019 16:49
|
|
|
Xik posted:If there mistake was genuine then you've hopefully shown them they made a mistake without fuss and they can learn? If they did it on purpose, then now they know you found it and it didn't just slide under the bus. Hi please don’t mix metaphors, people get thrown under busses. if we need to hide an issue I’d use a carpet.
|
|
#
?
Jul 13, 2019 18:07
|
|
|
Xik posted:
Other people have already covered it, but I'll repeat: Even if you have a suite of non-garbage unit tests that give you 100% code coverage, you can still be missing valid test cases. Every single test can be confirming a legitimate use case, but that doesn't mean that there aren't gaps. Code coverage helps you find and close the obvious gaps (code that no one has tested at all), but once a line of code is hit by a test, you're on your own to ensure that you're testing the behavior in all of your valid and invalid use cases.
|
|
#
?
Jul 13, 2019 18:47
|
|
|
Take a look at mutation testing, which changes arbitrary lines in the code under test and sees if anything fails. If everything passes, your tests need fixing.
Volmarias fucked around with this message at 22:31 on Jul 13, 2019 |
|
#
?
Jul 13, 2019 18:54
|
|
|
Writing good tests is hard.
|
|
#
?
Jul 13, 2019 19:37
|
|
|
An easy example of the problems of niavely trusting test coverage is if statements with complex conditions, like A or B. If existing test only exercise the when only A is true and A and B are both false but not when only B is true you will see that line as covered in the code coverage report but you've missed an state.
|
|
#
?
Jul 13, 2019 21:15
|
|
|
captkirk posted:An easy example of the problems of niavely trusting test coverage is if statements with complex conditions, like A or B. If existing test only exercise the when only A is true and A and B are both false but not when only B is true you will see that line as covered in the code coverage report but you've missed an state. For java, a SonarQube scan should find this and some code coverage tools also have branch coverage reporting. We use Jacoco and that would check for all 4 possible combinations of the bools A and B.
|
|
#
?
Jul 14, 2019 12:41
|
|
|
Keetron posted:For java, a SonarQube scan should find this and some code coverage tools also have branch coverage reporting. We use Jacoco and that would check for all 4 possible combinations of the bools A and B. Yeah, I assumed there were more clever coverage tools out there but it's still a good example that you need to understand what your coverage report is telling you.
|
|
#
?
Jul 14, 2019 20:58
|
|
|
New Yorp New Yorp posted:It's not a lie. This comes up in this thread all the time so I hate to repeat it yet again, but code coverage is not an indication of correctness or quality. It surely is an indication of correctness and quality (unless you're deliberately gaming it, as has been pointed out). It's just not a guarantee.
|
|
#
?
Jul 15, 2019 13:10
|
|
|
Yeah, testing provides confidence, not guarantees.
|
|
#
?
Jul 15, 2019 19:42
|
|
|
|
| # ? May 9, 2024 14:16 |
|
|
For anyone working remotely, do you ever reach a point where you just crave and need some kind of external validation about what you are doing?? Even if the answer to some issue maybe should be obvious you reach a point where you just need some kind of interaction to solidify it. I dont feel like I ever used to quite get this, when I was newer working remotely I was just still learning stuff now I feel like occasionally I have to show someone something and just hear them say "uh huh. Yep" whatever just to feel like I am not crazy?? I think I am just on my periodic mood swing about love/hate for remote work
|
|
#
?
Jul 16, 2019 04:39
|
|
