|
Vulture Culture posted:8 hours isn't fine for one step (if the interview is based entirely on technical prowess and 0% on team fit, run the gently caress far away). It's fine if you're already between jobs because you can afford to be, or because you're an unencumbered twenty-something or early thirty-something with no other demands on that time. It's not okay for people with multiple jobs, people with children, people with elder care responsibilities, etc. This will be reflected in the demographics of the workplace. 8 hours was meant as an absolute upper bounds for the entire process.
|
#
?
Oct 7, 2016 18:33
|
|
|
|
| # ? May 10, 2024 08:07 |
|
|
pugnax posted:How do you guys treat documentation in your ~agile flow~? An extra story per feature? Treat it like a feature in itself? Gounads posted:8 hours was meant as an absolute upper bounds for the entire process.
|
|
#
?
Oct 7, 2016 18:47
|
|
|
Gounads posted:8 hours was meant as an absolute upper bounds for the entire process. Yes and I agree with this also. I really just need to solidify my stance against doing these tests. I've done two so far, the results; one mysterious company that was recruiting with "hacker" challenges--I made it to the last step and they told me to set up a web app. I went a little overboard and even implemented a system that popped my resume up in a PDF viewer when visiting the site. They wanted me but it turned out that they literally had no money and were looking for people to work for free. gently caress idea guys. The other one, I had to implement a fully-fledged app to order pizzas online. They hired me and I instantly hated the job and despised my boss. I should have listened to my gut on that one. No more, I'm putting my foot down against interview "homework." It's loving bullshit. It's annoying because I really would like to find a new job but solid non-bs jobs are scarce as gently caress right now. I'm about to just put in my notice at my current job and live off savings because I can't stand my current boss, even in spite of the current hiring climate. Company got bought out and this idiot that doesn't even know what a hosts file is, is now in charge of every move I make. I literally built the CI system at this company from the ground up, but this idiot is the only one who is allowed to sign off on deployments now. He's trying to fire me at the moment because he ordered, ORDERED me to have a complex project done by midnight on wednesday and I told him that was unlikely. This dude is so completely delusional he has this idea in his head that whatever he says goes, regardless of whether his expectations are realistic or not. He's had me working 60 hour weeks for over a month now and just ordered me to go to loving Detroit on basically no notice to do a bunch of poo poo I could easily do from here. After he ordered me to complete that project by midnight, I told him I'd likely have it done but I felt it needed more testing than our usual UAT. His response was basically "Are you refusing to comply with my order?" I told him that we needed to discuss this between myself, him and the CTO. His response? "No." I basically wrote a letter to the CTO telling him this is bullshit and I'm taking the day off for a mental health day, fire me if you want. Idiot boss then sends me this text (verbatim): "Just in case you're not monitoring your email I want to make sure you understand that you are not authorized to take tomorrow off" Who the gently caress says that? Now, I currently am almost completely maxxed on PTO right now, I've haven't had two days off in a row since August, and while I understand how disruptive just taking a sick day out of the blue can be, I basically just had to take a time out so I wouldn't do or say something I'd regret. The CTO was cool with it and fully understood but my boss is just raging at the moment. He's very clearly and obviously trying to build a paper trail so he'll have some ammo to try and get me canned, but he also doesn't have the clout and the whole thing is just kind of hilarious to me. I really wish they'd just fire me to be honest. I wonder if they remember agreeing to a $15k severance or striking out the binding arbitration clause from my employment contract....
|
|
#
?
Oct 7, 2016 19:33
|
|
|
Do you work for Chris Roberts?
|
|
#
?
Oct 7, 2016 20:10
|
|
|
I hope you forwarded that message to the CTO with the message "and this is why"
|
|
#
?
Oct 7, 2016 20:33
|
|
|
hobbesmaster posted:Do you work for Chris Roberts? I think I'd rather work for crobbits tbh. Highlights of some of the stuff this dude has pulled recently: - Instituted a whole new workflow for everything and didn't tell anyone. I found out when I notified him about a deploy I had pushed out to fix a customer issue and he made me revert the deploy, hotpatch the DB to fix the customers issue, and then re-deploy the same code the next day with his blessing. This caused a time-sensitive overshoot with our customer. - Did not know we do UAT with the prod data. Why is this? Because we're stretched too thin at the moment to create a proper dev environment and our "prod data" is a 290TB read-only hadoop cluster. - Constantly puts me onto random tickets with other deadlines looming and then is abusive when those deadlines are not met. - Messages me constantly on Slack. To the point where it intrudes on my work. The other day I checked the chat logs and he had occupied three hours of my time by noon. Usually he will asks questions about information that's already in tickets, or he'll ask for updates and constant re-estimates of work I'm in the middle of. - Didn't know what a CNAME was, and was apparently also too lazy to google it and educate himself. Also does not understand what an A record is. This is a software development / network engineering company. - Doesn't know how to create a user account on our flagship product. You literally login and go to 'Users' and click 'Add user' - I built a SSO system using Oauth2. I fully documented the process for customers to integrate with us. It provides verbatim step-by-step instructions that can easily be replicated in Postman by even a non-developer. He wanted me to walk him through the entire process to prove that it's functional but got stuck on every single step including step 1, 'create a user.' His .NET folks have ALREADY figured out this integration and they're already using it. The dev had a couple clarification questions towards the end, but I only had to give him maybe five minutes of guidance to implement. - Literally thinks deadlines are magical incantations - Tried to get me to schedule a thousand miles of driving with 3 days notice. - Told me to go get dinner with my wife twice as a "thank you" for working overtime. He never expensed the meals. - Literally had to spell out for him that a ticket waiting on other tickets for implementation, couldn't be done first. He was the one who documented the dependancies in our ticketing system. - I start early. He'll message me "Good morning!" and then bother me four 20 minutes with insane drivel. Then an hour later he'll message me "Good morning!" again as if we'd never even spoke. This is just the recent stuff that pops into my head. There's more that I'm forgetting. The guy's absolutely insane.
|
|
#
?
Oct 7, 2016 20:37
|
|
|
Vulture Culture posted:8 hours isn't fine for one step (if the interview is based entirely on technical prowess and 0% on team fit, run the gently caress far away). It's fine if you're already between jobs because you can afford to be, or because you're an unencumbered twenty-something or early thirty-something with no other demands on that time. It's not okay for people with multiple jobs, people with children, people with elder care responsibilities, etc. This will be reflected in the demographics of the workplace. Exactly, the problem is that it's a self-selection issue. Only people who have no problem with giving up multiple days will apply to that company, so it will be stocked with people who think that's ok and normal. You're completely limited in the number of places you can apply for at a time. I remember a few jobs ago I had two weeks of flying around the country to WA (twice), MD, and MA from CA. If one of those wanted the day or two of travel for a f2f and another day or two of a test, I'd drop them off the list. This line of thought makes me really glad i'm not an artist or designer where their take home tests run 20-40 hours routinely.
|
|
#
?
Oct 7, 2016 20:50
|
|
|
Reading this post stresses me out.
|
|
#
?
Oct 7, 2016 22:00
|
|
|
You...uhhhh...work remotely for a web hosting company around Detroit that just hired a new guy that starts on Monday?
|
|
#
?
Oct 8, 2016 00:25
|
|
|
rt4 posted:You...uhhhh...work remotely for a web hosting company around Detroit that just hired a new guy that starts on Monday? Haha wow. Uhh pm me.
|
|
#
?
Oct 8, 2016 01:44
|
|
|
I have a coworker Who is a good guy But messages Me on slack like This constantly and doesn't Think to just write a single Sentence.
|
|
#
?
Oct 8, 2016 05:24
|
|
|
That's a terrible poem.
|
|
#
?
Oct 8, 2016 06:40
|
|
|
ratbert90 posted:I have a coworker Hey *10mins pas* I work with That guy Too
|
|
#
?
Oct 8, 2016 11:17
|
|
|
/giphy haha cool
|
|
#
?
Oct 8, 2016 11:23
|
|
|
Vulture Culture posted:8 hours isn't fine for one step (if the interview is based entirely on technical prowess and 0% on team fit, run the gently caress far away). It's fine if you're already between jobs because you can afford to be, or because you're an unencumbered twenty-something or early thirty-something with no other demands on that time. It's not okay for people with multiple jobs, people with children, people with elder care responsibilities, etc. This will be reflected in the demographics of the workplace. What do people mean when they say they test for team fit? It's been a while since I went for interviews and I don't remember much about seeing if I fit in to a team. What would that even be? Making sure the person isn't an rear end in a top hat, or expecting everyone to be wearing suits at the company?
|
|
#
?
Oct 8, 2016 16:14
|
|
|
return0 posted:If you need to go to the toilet or make a coffee or spend two minutes wrapping up then that's obviously fine, the point is you cannot defer peer review and must do it immediately. It works pretty well, and is quite well aligned to a one-piece-flow / kanban philosophy. Would you mind sharing the exercise? If not that's cool. We haven't had the best experiences hiring lately and the exercises / questions our leads are asking aren't getting the job done. I'd rather transition to something like what you're describing.
|
|
#
?
Oct 8, 2016 17:00
|
|
|
piratepilates posted:What do people mean when they say they test for team fit? It's been a while since I went for interviews and I don't remember much about seeing if I fit in to a team. What would that even be? Making sure the person isn't an rear end in a top hat, or expecting everyone to be wearing suits at the company? When people say "testing for team fit" they usually mean a part of the interview which is attempting to make the candidate fits their ~ company culture ~. The concept is given a lot of crap but I have interviewed many people who passed our programming tests but then turned out to be absolute shits of human beings. A couple of standouts: person who couldn't stop leering at one of the female interviewers, person doing a remote interview where we screenshared and they had a wallpaper saying "What do you call the extermination of six million Jews? A good start!" Vulture Culture's point, and I agree with it, is that If a company believes you should only interview 100% on technical skills and don't even consider the part where the candidate may ever have to interact with some other person then that company will probably end up hiring people who normal individuals cannot stand to be around.
|
|
#
?
Oct 8, 2016 17:29
|
|
|
piratepilates posted:What do people mean when they say they test for team fit? It's been a while since I went for interviews and I don't remember much about seeing if I fit in to a team. What would that even be? Making sure the person isn't an rear end in a top hat, or expecting everyone to be wearing suits at the company? How white, male, and young are you, or can you pass for? It's supposed to be how well you'll get along with and work with your new prospective team, but ultimately seems to be a way to make a monoculture more than anything else.
|
|
#
?
Oct 9, 2016 13:28
|
|
|
csammis posted:... person doing a remote interview where we screenshared and they had a wallpaper saying "What do you call the extermination of six million Jews? A good start!" Wow, that's quite something... How can he have thought that was ok?
|
|
#
?
Oct 10, 2016 10:49
|
|
|
csammis posted:When people say "testing for team fit" they usually mean a part of the interview which is attempting to make the candidate fits their ~ company culture ~. The concept is given a lot of crap but I have interviewed many people who passed our programming tests but then turned out to be absolute shits of human beings. A couple of standouts: person who couldn't stop leering at one of the female interviewers, person doing a remote interview where we screenshared and they had a wallpaper saying "What do you call the extermination of six million Jews? A good start!" Startup culture, which often has no formal HR, has sort of ruined the term by taking it to mean whatever handwavey bullshit they use to justify hiring people with their own specific biases (white, male, young, programs in their spare time, shows up to the interview in a t-shirt, likes to go out after work and socialize with coworkers). So it's important to have an idea of what you want beforehand and restrict your impressions to those things instead of doing gut post-facto rationalization. But to give an example of where I've passed on people for culture fit in the past: when I was the manager of a wide swath of IT roles at my last job, we had a guy interview for a storage engineer position who was really good technically, but was really high-strung, and this was in an environment that culturally had been really casual because it didn't pay well at all and had very little budget. It was clear to basically everyone that the guy was going to go crazy trying to get anything done the way that he wanted to work and that the entire team's dynamic and morale was going to suffer for it. Vulture Culture fucked around with this message at 13:38 on Oct 10, 2016 |
|
#
?
Oct 10, 2016 13:35
|
|
|
I did end up getting feedback from one of my co-workers on my performance, and the response boiled down to this:
It helps to mention that this is all against the background of another co-worker being the driving force behind "don't let a single bug into staging, test literally everything, don't rock the boat too much", which both I and the one giving me feedback are a little skeptical about. I fully admit to being too ambitious in refactoring and abusing the PR review process, but I'm not entirely sure I'm happy with the direction the team is going in. But hey, if this is the way we work, I'll do whatever's best for the team. In the meantime, I'm gonna see if I can get these "how we work" guidelines written down somewhere. Pollyanna fucked around with this message at 15:05 on Oct 10, 2016 |
|
#
?
Oct 10, 2016 14:59
|
|
|
quote:Refactoring is a team effort, not a PR-level thing. Refractors need buy-in from the team at large in order to tackle, which means going through the "add to list of improvements -> accept into backlog -> make ticket -> add to backlog -> estimate at backlog pruning -> drag into sprint" workflow. This is the feedback that my co-worker was least sure about, and we talked about the difficult in balancing it with "leave things better than you found it". We settled on PR-level refactoring being limited to the immediately relevant code touched by the PR, and even then to as minimal as possible. The Chromium Project has an odd take on refactoring, they prefer completely fixing the larger picture than smaller PR's that improve what is there today. This can mean ugly code lives in the tree for a long time.
|
|
#
?
Oct 10, 2016 15:03
|
|
|
Pollyanna posted:tl;dr: Make sure PRs are as polished as possible before submitting. I agree with this one, for the most part. We had issues where, near the end of a sprint, people started opening pull requests early so reviewers could get a head start. They'd then repeatedly commit single-file changes in responses to comments that came up, forcing everybody else to reload the pull request and potentially start over. I suggested that projects that were so close to their deadlines that this had to happen maybe should be bumped out of the sprint and my boss got mad at me. On the other hand… Pollyanna posted:tl;dr: Code to the lowest common denominator on the team. 
|
|
#
?
Oct 10, 2016 15:26
|
|
|
Pollyanna posted:I did end up getting feedback from one of my co-workers on my performance, and the response boiled down to this: That sounds pretty reasonable. Your PR's should be polished. If you want earlier feedback, just ask someone to pair program or be your rubber duck. Whether you should test everything really depends on how critical the thing you're making is. The "permutations of feature A * permutations of feature B * permutations of feature C" does worry me a bit. That smells of too much coupling between features. The last point I definitely agree with. Boring code > clever code. That doesn't mean you should be avoiding useful language features just because someone isn't willing to learn them, but in general it's a good rule.
|
|
#
?
Oct 10, 2016 15:28
|
|
|
CPColin posted:I agree with this one, for the most part. We had issues where, near the end of a sprint, people started opening pull requests early so reviewers could get a head start. They'd then repeatedly commit single-file changes in responses to comments that came up, forcing everybody else to reload the pull request and potentially start over. I suggested that projects that were so close to their deadlines that this had to happen maybe should be bumped out of the sprint and my boss got mad at me. The PR one is the most reasonable and a legit fuckup on my part. I'm used to the "gently caress it get it out as soon as possible and let others comment on it" mentality that I got from...somewhere?...and it's probably just making things worse. I guess I just don't fully understand how to go from "it works" to "it's acceptable" outside of "make the code look good and more robust". I'll have to experiment with that a bit, it's high time I held myself to a better standard. The common denominator thing is mmmmmeh? A minor example of that is string interpolation vs. constructing a string from an array of substrings that was procedurally updated. Personal preference, but they still accomplished the same thing...that's the kind of thing that often comes up in PR reviews, which makes me a little nervous. We'll see how it goes.
|
|
#
?
Oct 10, 2016 15:30
|
|
|
Pollyanna posted:I did end up getting feedback from one of my co-workers on my performance, and the response boiled down to this: Most of that doesn't seem entirely unreasonable, but there's a reading of it that's extremely process over people. The last point is pretty bad depending on where the line is drawn.
|
|
#
?
Oct 10, 2016 15:47
|
|
|
MrMoo posted:The Chromium Project has an odd take on refactoring, they prefer completely fixing the larger picture than smaller PR's that improve what is there today. This can mean ugly code lives in the tree for a long time.
|
|
#
?
Oct 10, 2016 15:49
|
|
|
leper khan posted:Most of that doesn't seem entirely unreasonable, but there's a reading of it that's extremely process over people. The last point is pretty bad depending on where the line is drawn. Yeah, it makes me think, "An ebbing tide lowers all boats." in that, if the new-to-programming developers never encounter anything advanced, the average skill will drop and drag the code down with it.
|
|
#
?
Oct 10, 2016 15:50
|
|
|
Pollyanna posted:The PR one is the most reasonable and a legit fuckup on my part. I'm used to the "gently caress it get it out as soon as possible and let others comment on it" mentality that I got from...somewhere?...and it's probably just making things worse. I guess I just don't fully understand how to go from "it works" to "it's acceptable" outside of "make the code look good and more robust". I'll have to experiment with that a bit, it's high time I held myself to a better standard. Maybe contributing to projects on GitHub? In the times I had PRs open there, it was normal to have a substantial PR and then lots of smaller commits while it's open to fix things the repo owner asked.
|
|
#
?
Oct 10, 2016 15:59
|
|
|
Pollyanna posted:PRs should go through the red-green-refactor cycle as much as possible before I submit it. There should be as little involvement from or work done by the reviewers as possible, to minimize the time spent reviewing PRs and preventing them from lagging behind. Their feedback was that my PRs were often in a working but not optimal stare and reviews would be spent getting it as close to acceptable as possible (we never established what acceptable means, probably the minimal-review-necessary metric mentioned before). I explained my general approach to PRs re: get feedback as soon as possible, but said I understood the need for tighter review cycles and will polish PRs more before asking for review. tl;dr: Make sure PRs are as polished as possible before submitting. As a caveat, this is different when you're working on huge projects with really disconnected, asynchronous flows like the Linux kernel, for instance. And reviewers should be making a concerted effort to not be anal about the One True Way to do things until a few people have tried different ways of solving the same problem and hit walls and refactored. The best approach has a habit of shaking itself out of all the alternatives in a project with a high enough development velocity.
|
|
#
?
Oct 10, 2016 16:02
|
|
|
Pollyanna posted:I did end up getting feedback from one of my co-workers on my performance, and the response boiled down to this: I think your tl;dr is wrong for this one. Simple, easy to read code is almost always better than clever, hard to read code. You need to think about the long-term maintainability of the code, particularly if people who aren't familiar with the code base are going to be working on it in the future.
|
|
#
?
Oct 10, 2016 16:06
|
|
|
Slash posted:I think your tl;dr is wrong for this one. Simple, easy to read code is almost always better than clever, hard to read code. You need to think about the long-term maintainability of the code, particularly if people who aren't familiar with the code base are going to be working on it in the future.
|
|
#
?
Oct 10, 2016 16:07
|
|
|
Well, the LCD thing was straight from the discussion, but that's a better way of looking at it anyway.
|
|
#
?
Oct 10, 2016 16:08
|
|
|
I'm not super good with testing, and there is a couple of thing I don't understand about that test every single possible scenario statement. With one integer variable there is 4 biliions possible scenario. 2 integer ? that's 4 billion square... How can you really test all possible scenario of any function that has 18446744073709551616 possible scenarios ? Even if you can test a billion time per second it would take over 200 thousand years to test them all. It seem to me like testing is more about testing edge case, that's what make more sense to me. In that case, you can't say you are testing every possible scenario, just the one you think might mess up the code. It seem more reasonable to test edge case and catch exceptions and handle exception gracefully. Testing every possible scenario just seem subjective and arbitrary to me. But yeah as I said I don't have a lot of experience with testing. I usually prefer to write solid code, log extensively, monitor logs, and fix important bug, this method as served me well over the years. Anyone care to enlighten me ?
|
|
#
?
Oct 10, 2016 16:13
|
|
|
AskYourself posted:With one integer variable there is 4 biliions possible scenario. 2 integer ? that's 4 billion square... How can you really test all possible scenario of any function that has 18446744073709551616 possible scenarios ? Even if you can test a billion time per second it would take over 200 thousand years to test them all. Your tests just have to verify you can correctly go through the different code paths as much as possible. You'll find plenty of bugs just dealing with that. You're not worried about a cosmic ray flipping a bit in RAM and wrecking your program. Okay, you're not normally worrying about a cosmic ray flipping a bit in RAM and wrecking your program. Generally, if you have something that does X, you first just verify it can do X in its most controlled way possible. You can then handle more evil scenarios as necessary. You generally shouldn't have to worry about people violating the contract of what that thing does. So if you take in floating point numbers, you normally don't have to worry if they pass in a bunch of NaN or whatever. There may be a context where you do, but it should be very apparent. Or in dynamic languages, you may be testing a method that takes an int and suddenly it's passed in an instance of SomeDumbClass(). That is generally not your problem unless you have some specific knowledge that it is. Even with those training wheels and handholding, the project will eventually be extended and those tests will fall on their rear end. They will have done their job.
|
|
#
?
Oct 10, 2016 16:38
|
|
|
The idea is more like "cover all branches" not "all inputs". If you're testing something that takes two integers you should be thinking about things like the a < b, a > b, a == b, one zero or negative, both zero or negative, both high enough to overflow if you add them. Obviously it always depends on what you're doing, but you should aim to exercise all the different paths in your code. Sometimes it's also worth putting tests in that you think are obvious if makes it easier for others to check their assumptions about your code too. Disclaimer: You always need to consider the effort vs provided value when you're writing tests.
|
|
#
?
Oct 10, 2016 16:41
|
|
|
Rocko Bonaparte posted:Okay, you're not normally worrying about a cosmic ray flipping a bit in RAM and wrecking your program. Is this a thing that actually happens or am I better off not knowing and being able to sleep peacefully?
|
|
#
?
Oct 10, 2016 17:24
|
|
|
Polio Vax Scene posted:Is this a thing that actually happens or am I better off not knowing and being able to sleep peacefully? Yes, but it's more likely that you have a bad RAM chip or something. Space Kablooey fucked around with this message at 17:36 on Oct 10, 2016 |
|
#
?
Oct 10, 2016 17:31
|
|
|
With regards to testing paths and scenario combinations, here's an example of something I'm working on right now. We encode 2D data as a Datum that coordinates between a Row and a Column. We recently had a production issue where there somehow ended up being two Datums per Row+Column pair where it is assumed that there is only ever one, and we need to enforce a one-Datum-per-pair rule to prevent that from happening again and causing bugs and unexpected behavior. The important thing to keep in mind is the different dimensions to each interacting system and the assumptions placed upon them. For example:
Additionally, there are a couple different places where the number of Datums associated with RC pairs is important (i.e. where poo poo broke in the first place):
Our actual goal is "make sure each Row-Column pair hs only one Datum associated with it". But in order to be comprehensive and cover all possible paths, we need to test this validation given each permutation of model validity, Column type, existence of a Target, and pre-existing Datum given each context of "Table view" and "Graph view". So, the list of test cases, in RSpec, looks like this (without expectations written out): Pastebinned for length. Now, this is close to the worst case scenario, where we try to test each possible outcome regardless of relevance. But, we've run into many bugs where a part of the application that appeared to be totally unrelated to the feature or bug at hand ended up relevant somehow (e.g. the user that's logged in, the type of data we're working with, the user's permissions, the Board's relation to other Boards, the JavaScript in the view, etc.) and so the current sentiment to testing is to play it safe and try all sorts of possible states. That's the idea behind our approach, at least from talking with my other co-worker. I personally disagree with testing the Target portion of that since it was orthogonal to the "only one Datum per pair" issue, but it seems like we're leaning towards testing that anyway.
|
|
#
?
Oct 10, 2016 17:49
|
|
|
|
| # ? May 10, 2024 08:07 |
|
|
Polio Vax Scene posted:Is this a thing that actually happens or am I better off not knowing and being able to sleep peacefully? It's a thing that happens. Even without rowhammer / FFS, there's a surprising amount of traffic to sites one bit flip away from windows update's url, for instance.
|
|
#
?
Oct 10, 2016 17:51
|
|
