|
prom candy posted:Okay I read Designing Data-Intensive Applications, what next? I forget, what kind of books are you looking for?
|
#
?
Sep 13, 2023 22:41
|
|
|
|
| # ? May 12, 2024 23:55 |
|
|
lifg posted:I forget, what kind of books are you looking for? Anything and everything! After DDIA maybe I could use something else in the system design world but more practical/applied? I'm just a mid-career full stack dev and I don't know what I don't know.
|
|
#
?
Sep 13, 2023 23:34
|
|
|
I recently got pushed into an architect role over some data warehousing and analytics people, and was told to read The Data Warehouse Toolkit: The Definitive Guide to Dimensional Modeling, 3rd Edition https://a.co/d/6CKhY8L Building a Scalable Data Warehouse with Data Vault 2.0 https://a.co/d/680D3sM Definitely a different way to think about data than I have as a normie app dev. I’ve only just started the first.
|
|
#
?
Sep 14, 2023 02:14
|
|
|
This is a cross-post from the careers thread, but was thinking I might get some good comments from here from people who work in the field. I work on a team doing algo development/signal processing/data analytics stuff. Recently a team member has been presenting some ML stuff that has managed to gain some traction with the boss. The thing is, the stuff he's presenting is all stuff I explored 3 or 4 years ago, but basically received a pat on the head and was told that's nice, now get back to work. To be sure, my frustration is not directed to the colleague per se, but rather at my supervisor for somehow ignoring/overlooking my own (and others) efforts here and only suddenly now realizing the value of it, upon seeing it from someone else. I would like to bring this up with my supervisor, but without coming across as angry/bitter. I was thinking of sending something along the lines of: "I feel the need to be direct here and bring up some frustration with our current ML investigations. The image-based peak detection that Chris presented was something that Matt had up and running 4+ years ago. The issues regarding labelling accuracy were well-known already and documented by myself and others who had been exploring this space. In the next steps portion of the meeting a holistic model idea was mentioned - incorporating segment validation followed by feature detection - which is exactly what the ML approach I presented a year+ ago was doing (and was working very well). This is not a criticism of Chris' work, but an expression of frustration that all this prior effort seems to have fallen on deaf ears" Does something like this seem reasonably well-worded? Any suggestions from others who have been in this position would most appreciated! (Brief background: been at this company for ~5 years. Working in the space for 10+ and have a relevant MSc degree)
|
|
#
?
Sep 15, 2023 04:01
|
|
|
When you’re feeling strong emotions like anger and bitterness, a good idea is to open the conversation by just outright acknowledging it. “I’m feeling a bit angry and bitter here, and I’d like to talk about it.”
|
|
#
?
Sep 15, 2023 04:56
|
|
|
Also wait a week.
|
|
#
?
Sep 15, 2023 05:05
|
|
|
It’s also possible that four years ago your organization wasn’t equipped to make good on the ML research, at least from your boss’s perspective, but now it is and this new so-and-so just managed to hit the right time. That’s being pretty charitable but I’m in a decent mood at the moment on account of I decided to take tomorrow off, citing a total and complete lack of any more fucks to give this week.
|
|
#
?
Sep 15, 2023 05:11
|
|
|
I'd start by asking yourself what you're hoping to get out of this
|
|
#
?
Sep 15, 2023 05:28
|
|
|
Cyril Sneer posted:(Words) I don't think that's totally unreasonable. It all entirely depends on your manager and how they'd take this feedback, but I think it's worth being frank most of the time. Another thing to consider is: what did your coworker do that you might not have done? It might very well be that your boss literally just blew you off, but it also might be an opportunity to figure out what your coworker did to succeed. Maybe it literally is just nothing, but
|
|
#
?
Sep 15, 2023 05:51
|
|
|
Person A is retreading ground and should be referring to earlier work is very valid and helpful. Person A is presenting stuff I could have told you is not helpful. Getting a project going is a sales job, a mix of fact and presentation. But also, since chat gpt, ml has had a huge jump in credibility
|
|
#
?
Sep 15, 2023 06:42
|
|
|
Seems unlikely they will acknowledge this work if that means acknowledging they dropped the ball earlier. Also, this new guy has already got the recognition, at best you can hope for another pat on the head. I would focus on what you can add to the process. Like, just present your old stuff again if there's stuff there that this guy didn't cover. You can mention it's old news as a dig for your own satisfaction, but presenting it as new might make you seem quick and clued in. If he's already covered everything I think you're poo poo out of luck.
|
|
#
?
Sep 15, 2023 07:17
|
|
|
Cyril Sneer posted:fallen on deaf ears
|
|
#
?
Sep 15, 2023 14:25
|
|
|
epswing posted:Also wait a week. That's why I'm hanging out in the ol' SomethingAwful forums. csammis posted:It’s also possible that four years ago your organization wasn’t equipped to make good on the ML research, at least from your boss’s perspective, but now it is and this new so-and-so just managed to hit the right time. Oh, its definitely part of that, but that doesn't really change the situation for me. prom candy posted:I'd start by asking yourself what you're hoping to get out of this Acknowledgement that I was right and ownership of the project. StumblyWumbly posted:Person A is retreading ground and should be referring to earlier work is very valid and helpful. Right, part of my post is for advice on how properly formulate statement 1. We're not using chatgpt and not doing any advanced ML stuff at all really. thotsky posted:Seems unlikely they will acknowledge this work if that means acknowledging they dropped the ball earlier. Its exactly this.
|
|
#
?
Sep 15, 2023 16:56
|
|
|
If you have to tiptoe around your boss, you can turn it into a set of questions to them. Something like "what has changed since the time I presented this that has generated so much interest now? And what could I have done differently to have been included in the re-investigation?" It's absolutely managing upwards and putting your boss' diapers on for them, but this is how I've had to deal with reactive, petty managers before I secured a replacement. Also, secure a replacement.
|
|
#
?
Sep 15, 2023 17:40
|
|
|
What are people's opinions on purely manual code reviews? I generally hate them because the code doesn't come with any information about it possibly working at all. So I'm having to assess code for readability and maintainability against whether or not it even actually runs in the first place. I don't think most people are particularly good at that, and I also think reviews like that ultimately just take much, much longer (4x and higher). Also, in my head I tend to call them "naked code reviews" because the code is naked, but I dare not say it at work because it sounds like I want everybody to rip off their clothes and stare at code. I guess it would be somebody's idea of a good time, but . . .
|
|
#
?
Sep 15, 2023 17:42
|
|
|
From context I assume you mean PR without automatic tests?
|
|
#
?
Sep 15, 2023 18:08
|
|
|
Its what we do and it's better than nothing and we do catch stuff. Far from ideal though.
|
|
#
?
Sep 15, 2023 18:15
|
|
|
Rocko Bonaparte posted:If you have to tiptoe around your boss, you can turn it into a set of questions to them. Something like "what has changed since the time I presented this that has generated so much interest now? And what could I have done differently to have been included in the re-investigation?" It's absolutely managing upwards and putting your boss' diapers on for them, but this is how I've had to deal with reactive, petty managers before I secured a replacement. Also, secure a replacement. Asking questions is the way. Never tell anyone anything, people hate that.
|
|
#
?
Sep 15, 2023 19:36
|
|
|
Rocko Bonaparte posted:What are people's opinions on purely manual code reviews? I generally hate them because the code doesn't come with any information about it possibly working at all. So I'm having to assess code for readability and maintainability against whether or not it even actually runs in the first place. I don't think most people are particularly good at that, and I also think reviews like that ultimately just take much, much longer (4x and higher). Please print your top ten most recent commits and bring them to my office.
|
|
#
?
Sep 15, 2023 20:04
|
|
|
Rocko Bonaparte posted:What are people's opinions on purely manual code reviews? I generally hate them because the code doesn't come with any information about it possibly working at all. So I'm having to assess code for readability and maintainability against whether or not it even actually runs in the first place. I don't think most people are particularly good at that, and I also think reviews like that ultimately just take much, much longer (4x and higher). Yeah I'm going to need more context on what this means. Cup Runneth Over posted:Asking questions is the way. Never tell anyone anything, people hate that. How dare you.
|
|
#
?
Sep 15, 2023 20:34
|
|
|
Rocko Bonaparte posted:What are people's opinions on purely manual code reviews? I generally hate them because the code doesn't come with any information about it possibly working at all. So I'm having to assess code for readability and maintainability against whether or not it even actually runs in the first place. I don't think most people are particularly good at that, and I also think reviews like that ultimately just take much, much longer (4x and higher). ... do you just not have unit testing as part of your codebase or something?
|
|
#
?
Sep 16, 2023 01:19
|
|
|
Rocko Bonaparte posted:What are people's opinions on purely manual code reviews? I generally hate them because the code doesn't come with any information about it possibly working at all. So I'm having to assess code for readability and maintainability against whether or not it even actually runs in the first place. I don't think most people are particularly good at that, and I also think reviews like that ultimately just take much, much longer (4x and higher). iirc Code Complete says it's quantifiably the most effective way to prevent defects, followed closely by integration tests
|
|
#
?
Sep 16, 2023 01:27
|
|
|
Falcon2001 posted:Yeah I'm going to need more context on what this means. We have a repository that does not have a code review policy, or rather a few people can push directly to it to get it to build against the Linux kernel in a hurry. It's out-of-tree module code so it's vulnerable to a new kernel commit just wrecking everything and causing broken output. So we allow hotfixing that code. Well, somebody changed somebody's file for this in a way that didn't build and now there is a lot of screaming to review all changes. The people involved are on the other side of the world and this will put a 24-hour cycle on it--assuming they don't ask questions. Some other people then sent me a code review for the repository, which also failed to build, and their fix for that also failed to build (variations in Linux kernel versions). An eyeball inspection would not have sorted that out. I just had the hardware and wherewithal to check out the review and try to compile it myself. So I have been resisting a mandatory review policy in favor of getting some build gates in place first. Most hotfixes can at least wait for that. Something can at least try to compile it independently. I'd like some automated checks too, but the people who had their file changed really want to scour it without even knowing if the change compiles. So I am not trying to have no reviews, but I am devaluing them when I can't even tell at a glance if the code builds and has some proof of function. I just see those reviews go for days and days of staring--not even requesting changes. It's just a much harder activity to muster for a reviewer and then they have to be really on their game.
|
|
#
?
Sep 16, 2023 01:28
|
|
|
Volmarias posted:... do you just not have unit testing as part of your codebase or something? Nope! I would prefer to retrofit some, but a lot of it is Linux kernel code going back over a decade so I can't even find good ways to cordon it off into units in the first place. I do not endorse that model. The real crime there is a lack of effort in any kind of integration or regression testing; there was no effort to test it at all. I'd at least like some integration and regression tests. This has previously required special hardware but we finally have commodity software emulation so I am intending to use that as a test target.
|
|
#
?
Sep 16, 2023 01:33
|
|
|
It compiles ... ship it.
|
|
#
?
Sep 16, 2023 01:51
|
|
|
Rocko Bonaparte posted:We have a repository that does not have a code review policy, or rather a few people can push directly to it to get it to build against the Linux kernel in a hurry. It's out-of-tree module code so it's vulnerable to a new kernel commit just wrecking everything and causing broken output. So we allow hotfixing that code. I think you're absolutely correct. Even without unit tests a super basic "does it build on the target hardware at all" test should be mandatory.
|
|
#
?
Sep 16, 2023 02:08
|
|
|
Volguus posted:It compiles ... ship it. It doesn't compile, though  Ship it anyway I guess
|
|
#
?
Sep 16, 2023 04:47
|
|
|
Volmarias posted:It doesn't compile, though Just call it a beta version 
|
|
#
?
Sep 16, 2023 13:33
|
|
|
Starting with a basic "does it compile" gate should be straightforward and not politically controversial. Is there a reason (like requiring a special licensed compiler or something) why you can't just have a build server attempting to build every single change before it gets merged? Does it have to be compiled on the target hardware because cross-compiles don't work?
|
|
#
?
Sep 16, 2023 16:20
|
|
|
The amount of times I would have shipped a CR containing a breaking minor build issue due to some weird pattern is way too high to ever accept avoiding it, IMO
|
|
#
?
Sep 16, 2023 18:18
|
|
|
If you don't have continuous integration, you're not taking things seriously.
|
|
#
?
Sep 16, 2023 18:34
|
|
|
Where I work right now we have a bit of an issue with too many integration tests. It’s got to the point where each commit requires hundreds of days of EC2 time. It’s enormously impressive that the tests aren’t unworkably brittle, and they’re highly varied (we banned matrix style tests ages ago) but it still seems a little expensive to me!
|
|
#
?
Sep 17, 2023 01:11
|
|
|
Do you have any test coverage information?
|
|
#
?
Sep 17, 2023 02:37
|
|
|
Rocko Bonaparte posted:Do you have any test coverage information? We do, but as far as I know, it's not a number that anybody looks at. If there are correctness issues coming out of the codebase, it's viewed as a management problem. And if the blame lands there, it's very hard to make the argument to deprecate a test just because it already has 100% LoC coverage.
|
|
#
?
Sep 17, 2023 05:05
|
|
|
Jamus posted:Where I work right now we have a bit of an issue with too many integration tests. It’s got to the point where each commit requires hundreds of days of EC2 time. It’s enormously impressive that the tests aren’t unworkably brittle, and they’re highly varied (we banned matrix style tests ages ago) but it still seems a little expensive to me! How much realtime is this? It sound like either you're testing way too much and need to rethink your strategy, because I can only assume this has a lot of weird knock-on effects when it comes to releasing code. Edit: to expand on this, the rule of business changes is 'turn an issue into a measurable cost of some kind'. If every time you push a new build you have to wait 24 hours to see if it completes, that means that you're highly incentivized away from short, regular releases and into massive huge ones, and the development cycle also becomes increasingly frustrating. We have a legacy web application where I work (big scale FAANG company) that still operates somewhat like this, but it has a modern version that's way nicer to use on a bunch of levels, so at least if you're stuck in this mode its something you're supposed to be moving away from. I also don't think the integration tests are nearly that complex, like holy cow. Falcon2001 fucked around with this message at 19:37 on Sep 17, 2023 |
|
#
?
Sep 17, 2023 07:18
|
|
|
Jamus posted:Where I work right now we have a bit of an issue with too many integration tests. It’s got to the point where each commit requires hundreds of days of EC2 time. It’s enormously impressive that the tests aren’t unworkably brittle, and they’re highly varied (we banned matrix style tests ages ago) but it still seems a little expensive to me! WTF is your testing strategy to have hundreds of days of automated test running time ? Do you test for every values of integer for every functions or something ? Are you sending robots to another planet ? How did you even get pass an hour of run time without agreeing it has to be optimized ? Genuine curiosity here
|
|
#
?
Sep 17, 2023 16:18
|
|
|
Yeah I can’t make any sense of that. It would take a massively parallel test that you run thousands of copies of, or each test taking an hour each, or both.
|
|
#
?
Sep 17, 2023 17:15
|
|
|
Falcon2001 posted:How much realtime is this? Maybe about 12 hours, and we try to make sure there's at least 1 full run of the suite per day. It's very parallel. I am finding out about all kinds of AWS rate limits I wasn’t aware of previously here. On some of the older instance classes in peak times AWS just doesn’t have enough of the instance in the region. It’s bonkers!! The stuff you wrote about the types of problems this causes is absolutely true. Seeing each test in terms of the "value" it contributes per cost to run is where we're heading now. I don't want to make it too easy to guess where I work, but we have one major product where correctness problems directly cause significant sales losses. However, it is also the kind of domain where correctness issues can be statistical due to unexpected CPU branch predictor results or similar factors. Additionally, we have the kind of engineering culture where sometimes even fairly senior engineering leadership will drop in and read your unit tests. I think perhaps where we diverge from the testing issues of a standard SaaS are “integration” could be also considered “hardware-in-loop” testing maybe. We’re right on that line where we can’t afford to abstract away the actual hardware we run on. I kinda love it here, a company of software engineers with good opinions™ about testing, many of whom are in management, and the problems we’re facing because of it are at least new and interesting. Edit: we absolutely have the “a release is a big deal” problems Jamus fucked around with this message at 22:16 on Sep 17, 2023 |
|
#
?
Sep 17, 2023 22:00
|
|
|
Jamus posted:Maybe about 12 hours, and we try to make sure there's at least 1 full run of the suite per day. It's very parallel. FWIW I also agree and don't think this is the worst problem to have: you definitely have a problem, but I don't think it's nearly as bad as many other tech companies. Having a culture that's overly safe is far from the worst place to be; it limits your ability to push changes quickly and I'm sure it's frustrating, but it also helps you be more confident that changes will do what you expect, and you'll almost certainly spend less time scrambling to fix an error that wasn't caught (ask me how I know). It is also hilariously high in cost, but that's not necessarily your problem. Some industries are just significantly more risk averse for good reason; my uncle worked at a big payroll company and their less of risk aversion was incredibly high because well, loving up someone's paycheck is a big loving deal. I think your approach is pretty reasonable; I'd try and get a review of the testing and see if there's at least redundancies/etc that could be identified and eliminated as well.
|
|
#
?
Sep 17, 2023 22:10
|
|
|
|
| # ? May 12, 2024 23:55 |
|
|
Jamus posted:it is also the kind of domain where correctness issues can be statistical due to unexpected CPU branch predictor results or similar factors. 
|
|
#
?
Sep 18, 2023 12:24
|
|
