|
LLSix posted:The point of meetings is to show other people how important you are by being able to waste their time. The director didn't want questions. Be honest, there are more companies that exist like this than good ones.
|
#
?
Oct 24, 2018 00:48
|
|
|
|
| # ? May 30, 2024 10:22 |
|
|
I've had zero issues using git on our repositories; but we do treat it like mercurial and just merge everything with no history rewrites, squashing, and minimal rebasing. So we've never gone beyond the bare minimum to get stuff committed, pushed, etc. Merge requests in GitLab is about as complicated as it gets.
|
|
#
?
Oct 24, 2018 08:24
|
|
|
Cancelbot posted:I've had zero issues using git on our repositories; but we do treat it like mercurial and just merge everything with no history rewrites, squashing, and minimal rebasing. So we've never gone beyond the bare minimum to get stuff committed, pushed, etc. This is the correct approach imo. I like to use the visual studio Git GUI. It's really limited, but that also makes it really hard to gently caress stuff up. If you need any esoteric Git magic your branches probably are too long-lived and you need to fix your process.
|
|
#
?
Oct 24, 2018 10:00
|
|
|
Ugh, this loving project I'm on. Me: "Hey, this'll take months to finish myself." PM: "OK, just get it working for Big Client. They're big any annoying to deal with." Me: "Can do." *works for ~a month and a bit* PM: "This is scary to test with all the other changes we're making for BC, so make it work for this other client - they're way more complicated so we'll assume it'll also work for BC." Total planning failure and I haven't done enough rear end-covering in email/Slack.
|
|
#
?
Oct 24, 2018 16:18
|
|
|
Jesus Christ. I hate the developers on my team. There are two developers in particular who enjoy writing code with no comments and vastly inappropriate variable names. For example, you'd think an appropriate property for a FileName field matching a column named FileName in the DB would simply be named FileName, right? Nope, it's "objUsrPath" which is supposed to mean the path that the user supplied. Straightforward, right? So this poo poo is horribly unreadable because the properties and methods aren't descriptive, and there are no comments to boot. So I refactor it, and now they're coming at me "why did you remove this flag? Why did you remove this property that only served to make your databinding go through an additional property for no reason?" If you would just write well commented code that is clear in its function and intent, maybe I wouldn't have to refactor your magic flags and superfluous properties. This is all made worse by a company wide policy that pull requests must have two people approve before code can be merged. Except each team has 4 developers. So these two assholes always sign off on each others stuff and make the new guy review it, but he doesn't have the knowledge to look out for this kind of stuff, so I never get an opportunity to block the pull requests before I'm knee deep in the code wondering what the gently caress is going on.
|
|
#
?
Oct 24, 2018 21:14
|
|
|
Protocol7 posted:he doesn't have the knowledge to look out for this kind of stuff, Option 1: Give him the knowledge Option 2: He's unable to perform an effective code review, he shouldn't be signing off on pull requests
|
|
#
?
Oct 24, 2018 21:25
|
|
|
The pull request echo chamber is the loving worst. At a previous job, I got pretty close to demanding that somebody on a different team had to approve every pull request for that very reason. We also had a mini-revolt because certain developers, including my boss, kept opening pull requests early and continuing to commit stuff when we were halfway through our review, forcing us to start over. My boss said that, if we wanted pull requests to wait until the very end to be opened, they would expect us to stay late sometimes to finish review so everything could go live on time on Monday. Fortunately, the other devs joined in with the sentiment of, "gently caress your poorly planned sprint." I also suggested that we needed to stop developing the automated testing code completely separately from the application code, with QA being held to different coding standards and the Dev team gaining no knowledge of what QA was doing. The QA Manager got really mad at the perceived attack on their department. Then I got laid off because the company "didn't need an Architect." Now I'm the only developer on my "team"! So no more sprint planning, code reviews, standards, career advancement, etc.!
|
|
#
?
Oct 24, 2018 21:31
|
|
|
CPColin posted:Now I'm the only developer on my "team"! So no more sprint planning, code reviews, standards, career advancement, etc.! Is it heaven? please say its heaven.
|
|
#
?
Oct 24, 2018 21:42
|
|
|
Dirty Frank posted:Is it heaven? please say its heaven. It's completely loving boring. My boss already noticed and asked if I was looking for other jobs. I said no (because I already finished looking and there wasn't anything good).
|
|
#
?
Oct 24, 2018 21:49
|
|
|
CPColin posted:Then I got laid off because the company "didn't need an Architect." Now I'm the only developer on my "team"! So no more sprint planning, code reviews, standards, career advancement, etc.! You have career advancement, just not job advancement. Your next job will move your career further along.
|
|
#
?
Oct 24, 2018 21:52
|
|
|
New Yorp New Yorp posted:Option 1: Give him the knowledge This is his first feature project, so he's learning. Not fast enough to deal with this kind of thing, though. Unfortunately, the PR process at my job is more of a checkmark than a valuable code review process. Unless you're an idiot like me and actually care a little bit about producing a high quality product, but hey, gently caress actually reading code in code reviews, right?
|
|
#
?
Oct 24, 2018 21:58
|
|
|
Hughlander posted:You have career advancement, just not job advancement. Your next job will move your career further along. I've been stressing lately about what I'm going to put on my resume for this job, besides, "Maintained a bunch of dumb poo poo for a department that shouldn't exist." Like, I do not want "Groovy" and "Grails" getting anywhere loving close to my "Skills" section. Although I guess "Took one web application from a dozen unit and integration tests to 432 tests" is a start.
|
|
#
?
Oct 24, 2018 22:04
|
|
|
"Refactored application improving test coverage, speed and reliability" can be one way to go about it. What's wrong with Groovy and/or Grails on your resume? Afraid that's the only thing you'll get form now on? I did Grails in 2009 (one application that was quickly brought to its knees by 20000 people accessing it at the same time) but i don't remember ever getting many offers for a grails job. Grails is fine for an internal web app, but definitely not for external.
|
|
#
?
Oct 24, 2018 22:14
|
|
|
Yeah, pretty much. Also, I have a feeling I'm not going to want to answer questions about it, starting roughly 1 millisecond after I stop using it. I removed PHP from my resume, for similar reasons. Don't want to talk about it, don't want you all on the interview panel to think you can get me to do it. Centuries ago, when I interviewed to work at Jiffy Lube (yes, there was an interview), I made the mistake of mentioning that I drive a stick-shift and quickly became the one lucky rear end in a top hat who got to stall or spin tires while being watched by skeptical customers. Focusing on the refactoring I had to do in order to write the tests is a good call, thanks. I don't know if I improved the speed any; when I asked the other dev and the sysadmins where to find permissions so I could get the EXPLAIN plan for a query, they both acted like I was speaking loving Klingon.
|
|
#
?
Oct 24, 2018 22:25
|
|
|
TheReverend posted:I'll have myself a proper title and even more exciting, (hopefully) a bigger check. There’s too many factors for anyone to just give you a number. Instead, you should go on interviews until you get at least one offer. That will tell you an appropriate salary.
|
|
#
?
Oct 24, 2018 23:43
|
|
|
Protocol7 posted:There are two developers in particular who enjoy writing code with no comments and vastly inappropriate variable names. For example, you'd think an appropriate property for a FileName field matching a column named FileName in the DB would simply be named FileName, right? Nope, it's "objUsrPath" which is supposed to mean the path that the user supplied. Straightforward, right? We've started using destructuring in Javascript as part of our move to ES6 and it's kind of annoying how much more readable everyone's code is now that all our data objects have the same keys from DB -> API -> front end. It's the most minor thing but you can understand how everything fits together so much more easily.
|
|
#
?
Oct 25, 2018 16:44
|
|
|
CPColin posted:I've been stressing lately about what I'm going to put on my resume for this job, besides, "Maintained a bunch of dumb poo poo for a department that shouldn't exist." Like, I do not want "Groovy" and "Grails" getting anywhere loving close to my "Skills" section. I have a couple lines on my resume that read something like, "maintained x lines of legacy code, adding y unit tests". The word "legacy" is fun, because interviewers always know what it means, and ask for stories.
|
|
#
?
Oct 25, 2018 17:19
|
|
|
Protocol7 posted:So I refactor it, and now they're coming at me "why did you remove this flag? Why did you remove this property that only served to make your databinding go through an additional property for no reason?" Not only that, but their intent and the functionality should be enforced through unit tests. If they can't write a test to enforce something like a flag in some chunk of code then their code is not structured correctly. If it is and they didn't write some tests then too bad so sad.
|
|
#
?
Oct 25, 2018 17:28
|
|
|
Most resume consultants usually like to recommend using more "business-oriented" impact like "Reduced production errors by 15% through increasing test coverage and adding 400 integration tests" but at a certain point in your career that's just a bunch of maintenance and people are looking for things like "Grew a team of 3 developers to 10 in a year while shipping n% more features" or "Shipped $feature and scaled $product from 1M users to 200M users." Basically, career growth happens through scaling... something. You write more code, more features, and trying to do it reliably is supposed to come with the territory. It's a really, really hard sell on a resume where you took something that crashed all the time and made it more reliable I've found out the hard way - every other person interviewing you understands what you mean, but most companies in a hiring mood that aren't terrible are looking for more growth-minded skillsets and experience rather than a Nights Watch. I try really hard to not put much down about legacy because I oftentimes get a bit triggered when talking about old codebases and horrible things I had to do to keep things running. If asked, I mostly describe the product, how big it is in terms of scale (users, instances, services - whatever sounds more impressive), what I did for it in SRE-style terms, and about how big it was when I wanted out. For dumpster fires that burned out and shuttered, I mostly talk about the projects themselves and what I worked on moreso than the impact I made (because "worked 100 hour weeks and it didn't matter in the end what I improved" is not how you start off a good relationship). Thinking of old jobs like ex-girlfriends is probably a very good analogy to use - only talk about the positives when asked, and if someone prods keep it positive / transformative and move on to better topics. This can be easier said than done of course.
|
|
#
?
Oct 25, 2018 18:39
|
|
|
Erwin posted:Not only that, but their intent and the functionality should be enforced through unit tests. If they can't write a test to enforce something like a flag in some chunk of code then their code is not structured correctly. If it is and they didn't write some tests then too bad so sad. Oh I haven't even bitched about our tests yet. They keep telling developers to write unit tests as part of feature work, but they never have held a training on how to write a unit test. Even worse, all of our tests are built on MS's testing libraries, but one of the dependencies for them is only distributed with Visual Studio Enterprise, and for whatever reason just over half of our devs were assigned VS Professional. Less than half the dev team has the tools to write unit tests, and the entire dev team has no idea how to actually write a unit test, let alone an effective one. It's a joke. They're supposed to be getting us full enterprise level VS subscriptions though.
|
|
#
?
Oct 25, 2018 21:33
|
|
|
At least they are trying. There is no requirement here for unit tests, and plenty of managers and devs have no idea what they are. My boss was saying the other day that "we're doing <thing> which basically the same as a unit test!  " They're testing embedded code on the real device by talking to it from a PC, so not a unit test in any way, shape, or form as far as I am concerned.
|
|
#
?
Oct 25, 2018 23:38
|
|
|
Protocol7 posted:Even worse, all of our tests are built on MS's testing libraries, but one of the dependencies for them is only distributed with Visual Studio Enterprise, and for whatever reason just over half of our devs were assigned VS Professional. Are you talking about Fakes? Because you don't have to have it installed in order to write or run tests that don't use Fakes. If your tests do use Fakes, rip it out and replace it with a real mocking framework. [edit] Basically, MStest (even the "1.0" version which has been superceded by MSTest 2.0, available as a NuGet package) will work with any SKU, including Community. There are some add-ons in Enterprise that you probably shouldn't use because they suck or are deprecated. Fakes, which is a crappy mocking/stubbing framework Coded UI, which was Microsoft's attempt to home-grow Selenium/Appium. CUI is explicitly deprecated and should be migrated to Selenium/Appium, per Microsoft's guidance IntelliTest, which tries to generate unit tests for methods by throwing random data at it to generate high code coverage, and thus it can also be called "the lovely garbage test high code coverage false sense of security generator", but that's way less catchy Load/perf testing stuff, which shouldn't be relevant to what you're talking about New Yorp New Yorp fucked around with this message at 00:54 on Oct 26, 2018 |
|
#
?
Oct 26, 2018 00:47
|
|
|
New Yorp New Yorp posted:IntelliTest, which tries to generate unit tests for methods by throwing random data at it to generate high code coverage, and thus it can also be called "the lovely garbage test high code coverage false sense of security generator", but that's way less catchy Isn’t that Fuzz Testing? A highly useful and good concept (which is also orthogonal to unit tests)
|
|
#
?
Oct 26, 2018 01:00
|
|
|
Hughlander posted:Isn’t that Fuzz Testing? A highly useful and good concept (which is also orthogonal to unit tests) Kind of, and I agree, and it's useful for that purpose. But Microsoft bills it as a "code coverage improver", which makes my skin crawl. I've tried it many times on many projects and never seen it generate anything other than useless, garbage tests.
|
|
#
?
Oct 26, 2018 01:11
|
|
|
It has it's niche but I remember when I watched some presentation at ignite and it was pushed really hard as a "solution to avoiding having to write lots of extra tests" because it's all ~automagic~ now. Of course all the examples they went through were just purely functional math functions with no need for any sort of mocking, so anyone that had done testing in the real world could probably see it for what it was.
|
|
#
?
Oct 26, 2018 01:22
|
|
|
Xik posted:It has it's niche but I remember when I watched some presentation at ignite and it was pushed really hard as a "solution to avoiding having to write lots of extra tests" because it's all ~automagic~ now. It does attempt to generate mocks, and it's really impressive in their contrived examples. I've just never seen it work well against Real Code.
|
|
#
?
Oct 26, 2018 01:30
|
|
|
New Yorp New Yorp posted:It does attempt to generate mocks, and it's really impressive in their contrived examples. I've just never seen it work well against Real Code. Interesting to hear it generates mocks. I'm either misremembering or they didn't show that off at the session I went to. Now I'm curious how they are automatically generating mock objects and how that is all defined etc, I'll have to look into it....
|
|
#
?
Oct 26, 2018 01:54
|
|
|
lifg posted:I have a couple lines on my resume that read something like, "maintained x lines of legacy code, adding y unit tests".
|
|
#
?
Oct 26, 2018 02:53
|
|
|
The Leck posted:I think I'm going to have to start asking for explicit proof of tests when I'm interviewing, because the last couple of jobs have talked a pretty big game about their testing and I've shown up to find environments ranging from "we don't write tests, they only slow down development" to "yeah, write tests, but releasing features is priority #1, and you can fill in some tests later if you have time" 
|
|
#
?
Oct 26, 2018 04:19
|
|
|
How many places that claim to do TDD actually write tests first, code later. Actually I don't do that myself for the most part because it's annoying as gently caress. I do often think out test scenarios ahead of time but don't write them down in code because the test setup/boilerplate depends so much on the specific implementation I end up going for.
|
|
#
?
Oct 26, 2018 06:38
|
|
|
The Leck posted:I think I'm going to have to start asking for explicit proof of tests when I'm interviewing, because the last couple of jobs have talked a pretty big game about their testing and I've shown up to find environments ranging from "we don't write tests, they only slow down development" to "yeah, write tests, but releasing features is priority #1, and you can fill in some tests later if you have time" Currently I am interviewing for a new contracting role and when pushed, many people seem to separate the activity of writing test from that of writing features. When arguing that this is the same thing, tests are part of your feature, those that look at me like I am the weird one go into the "rather work someplace else" bucket.
|
|
#
?
Oct 26, 2018 06:43
|
|
|
Can I just say that it's a very nice feeling that we as devs can basically set the terms of our interviews and easily walk away from crappy companies because every company is looking for devs anyway? Better than in many other fields, were you basically have to beg to be allowed to work the shittiest of jobs.
|
|
#
?
Oct 26, 2018 06:51
|
|
|
Carbon dioxide posted:How many places that claim to do TDD actually write tests first, code later. I end up doing them at the same time I guess? Usually when I start a feature for our API I'll kind of flail around in the codebase for a while until I figure out most of what I want to do, but when I actually start implementing code I'll write a test mostly so I don't have to figure out how to manually test it. Then it's make the test pass, do some refactoring, test again, try it manually with the front end, revise the test, etc. Now that I'm thinking about it, I don't really know how to write code without tests - how do you know it's doing what you want?
|
|
#
?
Oct 26, 2018 13:42
|
|
|
vonnegutt posted:Now that I'm thinking about it, I don't really know how to write code without tests - how do you know it's doing what you want?
|
|
#
?
Oct 26, 2018 14:39
|
|
|
Carbon dioxide posted:Can I just say that it's a very nice feeling that we as devs can basically set the terms of our interviews and easily walk away from crappy companies because every company is looking for devs anyway?
|
|
#
?
Oct 26, 2018 14:50
|
|
|
Carbon dioxide posted:How many places that claim to do TDD actually write tests first, code later. TDD should be a personal preference unless you're doing pair programming, since the end result should be a commit with tests. I don't want to work at a place that tells me how I should make the sausage, so long as the result is a timely, nutritious and delicious.
|
|
#
?
Oct 26, 2018 15:04
|
|
|
vonnegutt posted:I end up doing them at the same time I guess? Usually when I start a feature for our API I'll kind of flail around in the codebase for a while until I figure out most of what I want to do, but when I actually start implementing code I'll write a test mostly so I don't have to figure out how to manually test it. Then it's make the test pass, do some refactoring, test again, try it manually with the front end, revise the test, etc. You do manual testing most likely. At my current job there is very little automated testing and the code is not at all written with unit testing in mind. I'm trying to improve where I can though.
|
|
#
?
Oct 26, 2018 15:15
|
|
|
In the strictest form of TDD you write not just "the tests" first but one single test. Then you write the bare minimum amount of code to make that first test pass, and repeat until you're done. Nobody works like this. vonnegutt posted:Now that I'm thinking about it, I don't really know how to write code without tests - how do you know it's doing what you want? First, you do enough manual testing to be sure it suits your purposes. Then, you trust all future developers who ever touch the codebase, including yourself, to never accidentally break any part of it.
|
|
#
?
Oct 26, 2018 18:06
|
|
|
Volmarias posted:TDD should be a personal preference unless you're doing pair programming, since the end result should be a commit with tests. I don't want to work at a place that tells me how I should make the sausage, so long as the result is a timely, nutritious and delicious. Mr. manager, I can save 5 cents by making the sausage from recycled meat and ground bones. However it might fall apart at random times. Should I do this?
|
|
#
?
Oct 26, 2018 18:08
|
|
|
|
| # ? May 30, 2024 10:22 |
|
|
Oh, man. There is nothing better on a Friday morning than having a coworker who previously disagreed with you about the limitations of one feature of our application having wrapped up his research on the feature and agreeing that, yes, the limitation is currently in place, and will be prohibitively time consuming to refactor, and too risky to refactor because it is core functionality. It might be a good idea to listen when a developer who has worked on the feature many times in his 8 years at the company tries to tell you something important about the feature.
|
|
#
?
Oct 26, 2018 18:10
|
|