|
Splitting up code into classes by separation of concerns / business domain (sounds like that's what you did) and then defining a controller/service class solely responsible for orchestrating them together works pretty well IME. That way you can unit test the individual components and integration test the controller while keeping the intent of each of them clear, and there's still 1 single place someone can look at to understand how it all fits together, without needing a giant unreadable unmaintainable god class It sounds like a good coaching opportunity though, maybe best done in a verbal conversation. Sounds like there's a misunderstanding somewhere
|
#
?
Oct 16, 2019 21:58
|
|
|
|
| # ? May 20, 2024 17:49 |
|
|
Are you able to go into more detail about why encrypting a specific thing and uploading a specific thing are complex enough operations that they call for their own classes? Or did you write a generic uploady bit class and a generic encryptiony bit class to handle these concerns?
|
|
#
?
Oct 16, 2019 21:59
|
|
|
Vulture Culture posted:Are you able to go into more detail about why encrypting a specific thing and uploading a specific thing are complex enough operations that they call for their own classes? Or did you write a generic uploady bit class and a generic encryptiony bit class to handle these concerns? It wasn’t that abstracted, that’s way overkill. The partitioning was just to keep related logic together while still making it easily digestible since we’ve had a spate of PRs languishing in review because of how chonky they get.  Either way it’s been resolved so problem solved. Edit: in case you’re wondering, there’s one class for the CSV we build, one class for the data type that each CSV row represents, and a composition class for queries and overall logic. It’s not a great architecture, but it did the job. Pollyanna fucked around with this message at 22:14 on Oct 16, 2019 |
|
#
?
Oct 16, 2019 22:06
|
|
|
Volmarias posted:2) If there's a particular style in your codebase about this and you aren't ready to push for change, just follow the style in the codebase Consider: On how many projects have you established style afresh at the beginning? Now then, how did you establish that? Right, you just copy/pasted it from somewhere else. Guess where they got it: Yes they copy pasted and bastardized it too. In any case, Pollyanna is lucky. My project is ready to release the first main component of three and, because a generally-disconnected manager happened to be walking through when I was explaining existing limitations, now gets to rollback months of standing design decisions. "Oh but we're going to do this" is not very aglie when that thing is months away, we have a vetted solution now, and it's consistent with the existing architecture. Just because you never did it is not enough justification to prevent us from doing it.
|
|
#
?
Oct 16, 2019 22:54
|
|
|
PhantomOfTheCopier posted:What's amusing about this is that there's a very, very high chance it's terribly substandard. That's already all of my code though, so...
|
|
#
?
Oct 17, 2019 02:02
|
|
|
PhantomOfTheCopier posted:My project is ready to release the first main component of three and, because a generally-disconnected manager happened to be walking through when I was explaining existing limitations, now gets to rollback months of standing design decisions. "Oh but we're going to do this" is not very aglie when that thing is months away, we have a vetted solution now, and it's consistent with the existing architecture. Just because you never did it is not enough justification to prevent us from doing it. This is the part where I say: "Agile does not mean we change directions every few weeks." and release as intended to gather metrics on use.
|
|
#
?
Oct 17, 2019 05:57
|
|
|
Keetron posted:This is the part where I say: "Agile does not mean we change directions every few weeks." and release as intended to gather metrics on use. I'm pretty sure agile means "We reassign the entire team every time management experiences an issue that is impacting exactly 0% of real users." and you're doing it wrong.
|
|
#
?
Oct 17, 2019 13:15
|
|
|
Wallet posted:I'm pretty sure agile means "We reassign the entire team every time management experiences an issue that is impacting exactly 0% of real users." and you're doing it wrong. In my vocabulary agile means whatever as long as it allows me to do whatever I want.
|
|
#
?
Oct 17, 2019 13:53
|
|
|
Wallet posted:I'm pretty sure agile means "We reassign the entire team every time management experiences an issue that is impacting exactly 0% of real users." and you're doing it wrong. This is every management style though, not just agile.
|
|
#
?
Oct 17, 2019 15:01
|
|
|
Speaking of agile; what tools/processes do you have in place for change management: requesting poo poo gets released, approvals, denials, incidents etc. Is it a bespoke application written in ASP.NET and loving Angular 1 with a 12 week backlog of work and no people available to update it? I want to drown it in a loving bath and have them buy something, or use something someone who spends their time building this corporate enterprisey poo poo instead. I've got 4 weeks of my notice period left and in that time I want to see it burning in a ditch, this craptastic app was built by developers who got bored doing their normal work as well and have long since gone. It doesn't help the two people who run "service delivery" seem to want all the control in the world when it comes to authorising changes. We've only just got to self-certified changes after 12 months of fighting. Cancelbot fucked around with this message at 20:23 on Oct 17, 2019 |
|
#
?
Oct 17, 2019 20:21
|
|
|
Our process is to push stuff to prod all the time without much oversight as all the QA is done as part of the development cycle. I think you should check out mentally for the coming 4 weeks. What are they going to do? Fire you?
|
|
#
?
Oct 17, 2019 20:28
|
|
|
Volmarias posted:This is every management style though, not just agile. That was me bitching about management, not about agile.
|
|
#
?
Oct 18, 2019 01:00
|
|
|
Pollyanna posted:Today I got a review on my code saying that I shouldn’t be creating multiple classes for a particular solution that has several problem domains (and is split up accordingly) and should instead keep all the logic (CSV generation, queries, encryption, uploading, etc.) in one class and file because it’s easier to understand. I specifically split it up like that so that each piece would be easy to understand on its own, and you didn’t have to keep the whole thing in mind when working on it, because it’s a highly business critical thing that touched several parts of what we do and has a particularly heinous handwritten SQL query that I wanted to sequester. Personally I would tell the reviewer to go gently caress themselves.
|
|
#
?
Oct 19, 2019 14:44
|
|
|
I think it should all be in one function with an enum value as a mode toggle that determines whether you are preparing the data, encrypting it, or uploading it. Then you just call it three times with the different arguments. That is peak reuse! It would be even better if all that code just reimplemented things in the standard libraries. Ask me more about coworkers reimplementing Python file I/O this way! Or don't!
|
|
#
?
Oct 19, 2019 17:36
|
|
|
Rocko Bonaparte posted:Ask me more about coworkers reimplementing Python file I/O this way! Or don't! That's extremely stupid and you should tell us all about it!
|
|
#
?
Oct 19, 2019 17:47
|
|
|
return0 posted:Personally I would tell the reviewer to go gently caress themselves. 
|
|
#
?
Oct 19, 2019 17:48
|
|
|
rt4 posted:That's extremely stupid and you should tell us all about it! There was some kernel of nobility behind the whole idea because these file operations originally were also going to have to be done through things like a cable to another machine with an amount of abstraction. So if you wanted to copy a file, you'd use this to say to do it. That part was mostly fine. The bad part was instead of using abstraction in the design, it was all crammed into a giant megafunction predicated by an enum. Well, these people didn't know about enums in Python so it really was just constants mapped to numbers. Then it would fall into a pile of if-else logic to find the operation and then do whatever it wanted with the arguments that came in. Now, we ended up not needed all that abstraction in the first place. However, the real problem then became wrapping perfectly normal Python file operations with extra handling by people who had a defect rate of one per three lines of code. You know, because none of this was being tested. One of the people totally hated objects and using abstraction to generalize solutions to problems and would do poo poo like this instead. Given the defect rate, don't even try to act like they had a better methodology or were really into functional programming or some other alternative. They just wanted pure procedural programming and even hated break code into functions.
|
|
#
?
Oct 19, 2019 20:37
|
|
|
Rocko Bonaparte posted:One of the people totally hated objects and using abstraction to generalize solutions to problems and would do poo poo like this instead. Given the defect rate, don't even try to act like they had a better methodology or were really into functional programming or some other alternative. They just wanted pure procedural programming and even hated break code into functions. How long until you
|
|
#
?
Oct 20, 2019 06:16
|
|
|
Keetron posted:How long until you When I win the algorithm lottery in a coding interview.
|
|
#
?
Oct 20, 2019 08:49
|
|
|
Rocko Bonaparte posted:When I win the algorithm lottery in a coding interview. Oh, sorry for that. The role I'll be starting at in two weeks was landed with a single interview and some good references. Not yet sure if this is good or bad, I have seen inept developers at places with and without coding lotteries.
|
|
#
?
Oct 20, 2019 10:05
|
|
|
Rocko Bonaparte posted:When I win the algorithm lottery in a coding interview. I like this phrase and I might steal it.
|
|
#
?
Oct 20, 2019 11:54
|
|
|
Keetron posted:Oh, sorry for that. "M31, check out this guy, he's really good. He answered all our questions correctly" "But it says he plagiarized all of them" "It's ok, he answered everything correctly! I'm going to hire him" - the hiring manager of my department (he didn't get hired because our HR is just as incapable and hasn't onboarded anyone in the last 6 months)
|
|
#
?
Oct 20, 2019 14:33
|
|
|
https://youtu.be/r8RxkpUvxK0 If you ever feel bad about the algorithm lottery, watch this video from a former interviewer at google. In it he talks about how his team was known for being tougher than normal, and one time they were sent 8 anonymized packets, and they rejected every one of them. Then the recruiter who sent them said, “these were your packets. You all just rejected yourselves.”
|
|
#
?
Oct 20, 2019 18:17
|
|
|
M31 posted:"M31, check out this guy, he's really good. He answered all our questions correctly" Your manager is bad for ignoring advise from the people that the new hire has to work with. A bad hire is so much worse than no hire.
|
|
#
?
Oct 20, 2019 19:27
|
|
|
rt4 posted:Sounds like the separation of concerns is useful and the lead is clueless, time to quit return0 posted:Personally I would tell the reviewer to go gently caress themselves. ^^^
|
|
#
?
Oct 20, 2019 21:17
|
|
|
Hollow Talk posted:I like this phrase and I might steal it. You're not the first to say so and I kind of prefer people would and help me mock it a little bit. I mean not too much because I'm pretty sure whatever replaces it will be worse. lifg posted:https://youtu.be/r8RxkpUvxK0 Stuff like this is good ammo to keep my spouse's morale up because she's having to deal with me being cranky at my current job while being rejected elsewhere. My most paramount, personal fear though is that my current job has successfully rotted my brain and tarnished my reputation enough that everybody just thinks I can only program in Microsoft Outlook (send emails all day). It's still really annoying to have to basically wait to retry with a fresh set of topics. I just try to set aside time to see more goofy little programming puzzles used in interviews without burning myself out. I have other personal coding projects I'd rather use and I seldom fine any of the stuff I've had to study really helped me.
|
|
#
?
Oct 20, 2019 23:17
|
|
|
Rocko Bonaparte posted:everybody just thinks I can only program in Microsoft Outlook (send emails all day). Have you considered a scrum master role? (I'm joking but also maybe?)
|
|
#
?
Oct 21, 2019 01:44
|
|
|
lifg posted:https://youtu.be/r8RxkpUvxK0 "I've had candidates cry"! After 250 interviews I've not seen that. I guess this guy was still learning how to interview. I'll have to watch the remainder later (it's an hour presentation) but I'm consistently amazed by the anti-whiteboard sentiment. There are some outliers but every company makes it clear that is what will happen at an interview. Also if they didn't hire themselves... Had the company changed in the interim? A big company looks for different things year over year. "How do you put a number on that?" "You can't put a number on that". I think the ML people would disagree.  Honestly, you know most teams really only need to ask a few key questions: Tabs versus spaces. Here are four code samples, which is the cleanest? Which editor/IDE do you loathe? What hours of the day do you want to work? Which software development methodology do you find most natural? It's like the modern equivalent of geekcode/queercode/purity tests.  ... PhantomOfTheCopier fucked around with this message at 02:39 on Oct 21, 2019 |
|
#
?
Oct 21, 2019 02:30
|
|
|
PhantomOfTheCopier posted:Still seems weird to me that Google's hiring committees don't include the interviewers. It's an attempt to remove unconscious bias from the interview process, to try and be fair to everyone. Is your perception of a candidate influenced by their race, gender, and percieved socioeconomic class? Yes it is, and if you think you're above that then it probably actually influences you even more than it does other people. Nobody on the hiring committee knows any of that stuff, so the idea is that they can be more objective in their evaluation of the interview summaries.
|
|
#
?
Oct 21, 2019 03:25
|
|
|
It's not clear how much of a difference that actually makes if the bias is already baked into the interview summaries.
|
|
#
?
Oct 21, 2019 03:55
|
|
|
Pollyanna posted:Today I got a review on my code saying that I shouldn’t be creating multiple classes for a particular solution that has several problem domains (and is split up accordingly) and should instead keep all the logic (CSV generation, queries, encryption, uploading, etc.) in one class and file because it’s easier to understand. I specifically split it up like that so that each piece would be easy to understand on its own, and you didn’t have to keep the whole thing in mind when working on it, because it’s a highly business critical thing that touched several parts of what we do and has a particularly heinous handwritten SQL query that I wanted to sequester. This sounds pretty familiar. Guy I work with who writes and advocates for the continued existence of many many thousand LOC god classes broken up with regions (  ) but also grills prospective engineers relentlessly about SOLID and will throw around SOLID principles in defense of any bird brained decision he makes. It’s maddening.Doesn’t help that he’s the definition of why the No rear end in a top hat Rule exists.
|
|
#
?
Oct 21, 2019 04:25
|
|
|
ultrafilter posted:It's not clear how much of a difference that actually makes if the bias is already baked into the interview summaries. The interview write-up will also contain everything the candidate wrote, so if the candidate wrote garbage code the hiring committee will still see it and vice versa. The interviewers will write their summaries and opinion but the HC still makes the final call.
|
|
#
?
Oct 21, 2019 04:35
|
|
|
Something from that video caught me. He seemed to be pretty impressed with people that talked about the problem until they wound up with the optimized solution before coding. I had the impression that you start kind of naive and code that before advancing, and that's what I had been doing. If the fast way just kind of jumps into my head from the start, then I'll go with it, but I'm wondering if I should change my tact there.
|
|
#
?
Oct 21, 2019 04:35
|
|
|
Rocko Bonaparte posted:Something from that video caught me. He seemed to be pretty impressed with people that talked about the problem until they wound up with the optimized solution before coding. I had the impression that you start kind of naive and code that before advancing, and that's what I had been doing. If the fast way just kind of jumps into my head from the start, then I'll go with it, but I'm wondering if I should change my tact there. The interviewers want to see you solve a problem, in addition to or even instead of writing code. Talking about what you're thinking about isn't natural, but it's the best signal interviewers can get. Don't forget that the ability to communicate effectively is pretty important. Don't start coding until you're ready, unless you can't think of a good solution yet and need to just get the juices flowing. The time you waste writing something you throw away is significant.
|
|
#
?
Oct 21, 2019 04:37
|
|
|
If you like watching smart people talk about databases and distributed systems, join this slack: https://dist-sys-slack.herokuapp.com
|
|
#
?
Oct 21, 2019 17:11
|
|
|
Volmarias posted:The interviewers want to see you solve a problem, in addition to or even instead of writing code. Talking about what you're thinking about isn't natural, but it's the best signal interviewers can get. Don't forget that the ability to communicate effectively is pretty important. One thing you can do is to start talking through solutions and give your interviewers opportunities to cue you to turn your ideas into code. Good ones will take advantage and help you manage your time best, and lovely ones will screw you no matter what so it doesn’t really matter what tactic you take.
|
|
#
?
Oct 21, 2019 19:46
|
|
|
Good ones will give you hints, too, because you staring at an empty white board going "HMMM  " for five minutes doesn't help either of you. Better to give the candidate a small hint and see if that dislodges the rest of the problem than to assume they're a dullard for not thinking of that piece.
|
|
#
?
Oct 22, 2019 00:18
|
|
|
I don't think I have an issue with the general act of talking more so of a specific strategy of starting to code the less efficient solution and then revising for the more efficient one. I had gotten a notion that was kind of the way to go with the idea that most don't expect to code the more sophisticated solution. Now I'm thinking from hearing some more stuff that I should be talking through until I get away from brute force (usually) and then code the 2nd-level approach.
|
|
#
?
Oct 22, 2019 00:35
|
|
|
There's only a limited amount of time in an interview, and the interviewer is going to be mindful of how things are going throughout. Generally when I'm holding an interview I'll let the candidate keep iterating on their design until they're either finished, or I feel that further iteration is going to cut too much into the time needed for actual coding or further discussion. If you end up spending a significant amount of time on coding up a naive solution and then don't have enough time to code up the more interesting solution, you're not really putting your best foot forward.
|
|
#
?
Oct 22, 2019 00:58
|
|
|
|
| # ? May 20, 2024 17:49 |
|
|
Volmarias posted:Good ones will give you hints, too, because you staring at an empty white board going "HMMM If you’re a candidate that stands in front of a whiteboard going “hmm” for 5 minutes, I would give you a hint but I wouldn’t hire you. At least tell me your thoughts or what wouldn’t work.
|
|
#
?
Oct 22, 2019 01:22
|
|