|
Plorkyeran posted:Slack threads are fine and after the initial adjustment period of having a guy yell USE THREADS at us a lot I have no problem with them. There are still limitations with them, where messages in threads are second class citizens. For example, you can't (afaict) tell slack to remind you about a message in a thread, which is central to a difficulty I have with slack vs email; tying the protocol to the interface reduces flexibility in individual work patterns. I highly value the ability to structure my email use around inbox zeroing: if something is in my inbox it means it requires action. Getting something out of my inbox requires explicit action on my part. This has helped me basically never forget to do anything for a long time. With slack, if something comes to my attention that needs action on my part, I need to take action on that immediately to avoid it falling out of my brain, whether that is marking the message unread, asking slack to remind me, or emailing myself about it. It's not the worst thing in the world to deal with, but threads make it worse.
|
#
?
Aug 13, 2020 02:42
|
|
|
|
| # ? Jun 3, 2024 02:24 |
|
|
My morning routine (as someone who is a bunch of time zones behind most of the people I work with) consists of going through every slack message and building a todo list of things that I need to come back to. I find the process of making todo items to be valuable on its own and it completely eliminates relying on slack unread tracking, which I found to not work well because it made it hard to see when more messages came in before I got to doing the things for the first set.
|
|
#
?
Aug 13, 2020 04:10
|
|
|
Plorkyeran posted:My morning routine (as someone who is a bunch of time zones behind most of the people I work with) consists of going through every slack message and building a todo list of things that I need to come back to. I find the process of making todo items to be valuable on its own and it completely eliminates relying on slack unread tracking, which I found to not work well because it made it hard to see when more messages came in before I got to doing the things for the first set. To be honest I imagine this is a lot easier given that you are many timezones off. When I start my day and have a bunch of unread messages to respond to, this is when it is easiest to triage and follow up (in part because I can at least then have slack email me when I have mentions or dms that are unread). It's _harder_ when the messages come in the middle of the day when I'm focussed on other things.
|
|
#
?
Aug 13, 2020 06:27
|
|
|
The fact that I have fairly minimal distractions after noon or so is definitely one of the things that helps me tolerate all the downsides of shifted working hours. It's very nice having distinct "talking to people" and "doing things" parts of my day.
|
|
#
?
Aug 13, 2020 06:43
|
|
|
Steve French posted:There are still limitations with them, where messages in threads are second class citizens. For example, you can't (afaict) tell slack to remind you about a message in a thread, which is central to a difficulty I have with slack vs email; tying the protocol to the interface reduces flexibility in individual work patterns. I just tested this. You can tie a slack reminder to an individual message in a thread on the Windows desktop and iOS clients. Slack also does a pretty good job exposing hooks to other applications, so it's possible to send a message to, say, Todoist or Evernote, in the same way you'd set up a reminder.
|
|
#
?
Aug 13, 2020 16:25
|
|
|
Steve French posted:There are still limitations with them, where messages in threads are second class citizens. For example, you can't (afaict) tell slack to remind you about a message in a thread, which is central to a difficulty I have with slack vs email; tying the protocol to the interface reduces flexibility in individual work patterns. I do the same thing regarding zeroing my work email inboxes. All of the people I've worked with that are always forgetting requests, missing deadlines, and generally just being inconsistent and unreliable have email inboxes with the every email since they started. I don't even know how they use the email. They'll look up an email I sent a week ago, and it will take 30 minutes. It takes me 30 secs because it's in a folder, I barely have to search.
|
|
#
?
Aug 13, 2020 18:10
|
|
|
downout posted:I do the same thing regarding zeroing my work email inboxes. All of the people I've worked with that are always forgetting requests, missing deadlines, and generally just being inconsistent and unreliable have email inboxes with the every email since they started. I don't even know how they use the email. They'll look up an email I sent a week ago, and it will take 30 minutes. It takes me 30 secs because it's in a folder, I barely have to search. I work remote, so I don't get exposed to my coworker's failures all that often, but we had an in-person week last year where we rented a coworking space to hash things out in person. Two people on my team had EVERY notification turned on so all day long we were treated to the sound of whatever random thing got sent to them. New email? Beep. Build passed? Ding! Barely five minutes could pass in silence. Even worse, both of them checked every single time. How do you maintain a train of thought? All their inboxes looked like absolute poo poo, too. I have all my poo poo locked down tight. Nothing is allowed on my phone (I can access work email if I go looking for it, but it doesn't notify me of anything), and all my work stuff on my laptop is set up with automated actions for nearly everything. If anything ends up in my actual email inbox, it's probably something I have to actually deal with. I check email once a day. Once, my manager complained that I didn't respond to an email meeting invite for a same-day meeting because I was subsequently late to the meeting. He wanted to me to check my email again at lunchtime to make sure I didn't miss any same-day meeting invites in the future. I (politely) told him to shove it, because we have Slack for that kind of thing, and if he wanted me to continue producing features at the same level, I wouldn't be able to if I were chained to my email.
|
|
#
?
Aug 13, 2020 21:01
|
|
|
vonnegutt posted:I work remote, so I don't get exposed to my coworker's failures all that often, but we had an in-person week last year where we rented a coworking space to hash things out in person. Two people on my team had EVERY notification turned on so all day long we were treated to the sound of whatever random thing got sent to them. New email? Beep. Build passed? Ding! Barely five minutes could pass in silence. Even worse, both of them checked every single time. How do you maintain a train of thought? All their inboxes looked like absolute poo poo, too. I am all for reducing cognitive load from notifications but uh if you are (politely) telling your manager to shove it for having the audacity to ask you to check your email more than once a day, it may not be your manager who is in the wrong here
|
|
#
?
Aug 13, 2020 21:27
|
|
|
ChickenWing posted:I am all for reducing cognitive load from notifications but uh if you are (politely) telling your manager to shove it for having the audacity to ask you to check your email more than once a day, it may not be your manager who is in the wrong here To be clear, I did not tell my manager to shove it. I pointed out that he had several ways of getting in touch with me, ranging from phone calls, text messages, Slack messages, and email. He chose to use the least-synchronous one for something he needed a synchronous response for. I politely asked him to message me on Slack next time, and that I wouldn't be changing up my entire daily workflow for a situation that has so far come up exactly once. vonnegutt fucked around with this message at 21:51 on Aug 13, 2020 |
|
#
?
Aug 13, 2020 21:42
|
|
|
Space Gopher posted:I just tested this. You can tie a slack reminder to an individual message in a thread on the Windows desktop and iOS clients. Yeah I just tried again (on Android) and you're right. Not sure what I did wrong the first time. Regardless, my point is more that it's a fundamentally different workflow than what I have found to work much better for me in email, and that's because with slack, "remembering" to take action on something requires action on your part, whether that be setting a slack reminder, marking the message unread, sending to Evernote, whatever. A workflow that email enables that I prefer, that is not possible in slack, is to require me to say, explicitly (eg via archiving) that I am done with a particular thing (where in _most_ cases "done with" just means "i read it"), and until I do, it's still there in the inbox waiting to be dealt with. Now, it makes sense that this is not a reasonable workflow in slack, I don't want to have to do that for every single message. I don't think of it as a lacking functionality in their product, but rather a problem with the idea that slack is an email replacement. In addition to the above, there is implicit information conveyed by the medium of communication; phone call vs text vs slack vs email, etc. That is lost when trying to shove everything into one medium; there's not a great way that I'm aware of to convey the difference between "I have a message for just this one person that is not at all urgent" vs "I have an urgent message for this one person" in DMs, for example. The closest I've come is creating a private channel with just two people for the more frequent instances of the former.
|
|
#
?
Aug 14, 2020 02:35
|
|
|
vonnegutt posted:I work remote, so I don't get exposed to my coworker's failures all that often, but we had an in-person week last year where we rented a coworking space to hash things out in person. Two people on my team had EVERY notification turned on so all day long we were treated to the sound of whatever random thing got sent to them. New email? Beep. Build passed? Ding! Barely five minutes could pass in silence. Even worse, both of them checked every single time. How do you maintain a train of thought? All their inboxes looked like absolute poo poo, too. I don't miss emails, but then my company seems really good at not pointlessly sending them (maybe to the engineers). Which actually I learned to keep my email clean because I used to get burned in the military for missing meetings that I got email notifications for. But whatever, checking emails was easier than the real job, so sure I'll burn time doing that five times a day. Either way, keep the inbox empty makes my life immensely simpler. Kinda like my car; don't leave it full of trash then I don't have to clean it often.
|
|
#
?
Aug 15, 2020 01:37
|
|
|
 This never fails to amuse me.
|
|
#
?
Aug 15, 2020 14:07
|
|
|
Our biggest email problem is that we have group emails for each team, and someone will tag us on some email chain and say “oh maybe Team X” know this and we do not and then we get 20 more emails on it.
|
|
#
?
Aug 15, 2020 14:19
|
|
|
Our alert system is stupidly oversensitive and bombards me with 250+ alerts a day. I'm supposed to manually review every one of them, investigate, and create ops tickets to resolve them. I just bulk delete them because lol.
|
|
#
?
Aug 16, 2020 00:50
|
|
|
Speaking of which, the Ops team at my work wants "automatic ticket creation via email" and I'm like, "lol no you don't"
CPColin fucked around with this message at 02:44 on Aug 16, 2020 |
|
#
?
Aug 16, 2020 02:39
|
|
|
Moving the problem from "nobody cares about email" to "nobody cares about tickets"
|
|
#
?
Aug 16, 2020 04:51
|
|
|
prom candy posted:Moving the problem from "nobody cares about email" to "nobody cares about tickets" That buys them 6 months until they can kick the can down the road again. Sounds like software development to me
|
|
#
?
Aug 18, 2020 17:06
|
|
ultrafilter posted:
|
|
|
#
?
Aug 18, 2020 17:23
|
|
|
Anyone ever had a product manager or other non-engineer decide on performance targets for an application you own based on performance numbers from a vendor's application that your application interfaces with? Like, "this third party service does its part of the job in X time on average, so our part of the job should take X/4 time on average" ? Does that strike anyone else as absurd?
|
|
#
?
Aug 26, 2020 08:55
|
|
|
Che Delilas posted:Anyone ever had a product manager or other non-engineer decide on performance targets for an application you own based on performance numbers from a vendor's application that your application interfaces with? Like, "this third party service does its part of the job in X time on average, so our part of the job should take X/4 time on average" ?
|
|
#
?
Aug 26, 2020 09:05
|
|
|
Are these just targets or actual SLAs? If the latter, 
|
|
#
?
Aug 26, 2020 09:37
|
|
|
Che Delilas posted:Anyone ever had a product manager or other non-engineer decide on performance targets for an application you own based on performance numbers from a vendor's application that your application interfaces with? Like, "this third party service does its part of the job in X time on average, so our part of the job should take X/4 time on average" ? Is it to keep your app from becoming the bottleneck?
|
|
#
?
Aug 26, 2020 12:18
|
|
|
Pile Of Garbage posted:Are these just targets or actual SLAs? If the latter, Just targets thank god, and they aren't set in stone yet, he just came up with them as something that sounded good, based on nothing else but the vendor's numbers. Xguard86 posted:Is it to keep your app from becoming the bottleneck? The goal is to go from proof-of-concept performance to grown-up-product performance. A round trip to the vendor's product is one part of the lifetime of a request to our service. Our software is definitely the slowest piece of the equation right now, I just don't think taking the time of step 4 and saying "steps 1-3 should take 25% of what step 4 takes" makes sense. We don't know anything about what goes on under the hood of step 4.
|
|
#
?
Aug 26, 2020 17:40
|
|
|
Hello thread, just stopping by to remind everyone that ORMs are a faustian bargain and god help you if you let people who are Not Good At Sql develop with them. Sitting here trying to figure out exactly how the hell we untangle this chthonian N+1 query problem and counting the hours until I don't have to deal with this godawful codebase anymore (new team on Monday woo)
|
|
#
?
Aug 26, 2020 19:48
|
|
|
I think it kind of depends on whether you're in some way competing with this vendor or whether this was just an arbitrary way to pluck a performance goal out of thin air. Assuming the performance of step 4 is more or less a fixed target, this is roughly equivalent to just saying "steps 1 to 3 objectively take way too long, we want to make them run in 25% of the time or less". Which could still be a ludicrously difficult ask, but it's not weird as such.Che Delilas posted:We don't know anything about what goes on under the hood of step 4. That seems odd to me. Presumably it does the thing you requested it to do? And/or returns some kind of useful result which you need?
|
|
#
?
Aug 26, 2020 19:50
|
|
|
Doom Mathematic posted:I think it kind of depends on whether you're in some way competing with this vendor or whether this was just an arbitrary way to pluck a performance goal out of thin air. Assuming the performance of step 4 is more or less a fixed target, this is roughly equivalent to just saying "steps 1 to 3 objectively take way too long, we want to make them run in 25% of the time or less". Which could still be a ludicrously difficult ask, but it's not weird as such. It's not a competing vendor, they're downstream. Their part of the job is different from our part of the job. quote:That seems odd to me. Presumably it does the thing you requested it to do? And/or returns some kind of useful result which you need? Yes it does, but we have no idea how it does that, on a technological level, that's what I mean by "under the hood." They're a black box. They could be running their piece of the process through a billion dollar supercomputer (they aren't I'm just making a point), and extrapolating performance expectations for our product on our infrastructure doesn't make sense when we don't and won't know theirs. What makes more sense to me is figuring out performance targets based on the expectations of the customer and/or what makes sense for the industry. For a random example, ordering a t-shirt online; a customer is going to expect when they push the "complete purchase" button that they're going to get some kind of immediate feedback in the form of a page transition or loader gif, but they might tolerate a few minutes between the page responding and a confirmation showing up in their email. If I'm building an online store I don't say "Visa processes initial credit card transactions in 5 seconds so the time from button-click to calling Visa's API should be 2.5 seconds." Those two operations are unrelated.
|
|
#
?
Aug 26, 2020 20:28
|
|
|
Che Delilas posted:Just targets thank god, and they aren't set in stone yet, he just came up with them as something that sounded good, based on nothing else but the vendor's numbers. I'd probably approach it with: " - Delivery Time - Cost - Round Trip Time Pick Two" Oh sure we can do that 25% of step 4, we'll just need a billion dollar supercomputer to quote your downstream message. Or, yes if we spend the next 9 months optimizing the flow that could be doable.
|
|
#
?
Aug 26, 2020 20:42
|
|
|
Hughlander posted:I'd probably approach it with: Yeah we know how to manage expectations in terms of performance targets. It's just baffling to me where these particular ones came from.
|
|
#
?
Aug 26, 2020 21:07
|
|
|
ChickenWing posted:Hello thread, just stopping by to remind everyone that ORMs are a faustian bargain and god help you if you let people who are Not Good At Sql develop with them. I’m having the same problem! I’m so glad there’s a name for it.
|
|
#
?
Aug 27, 2020 01:11
|
|
|
ChickenWing posted:Hello thread, just stopping by to remind everyone that ORMs are a faustian bargain and god help you if you let people who are Not Good At Sql develop with them. Dealing with an EntityFramework related issue was the entirety of my Monday. The original call didn't include any navigation property data in the original query, and the result set ended up getting iterated over in a loop which resulted in 5-6 fresh SQL queries being run for each iteration of said loop, ending with one of the API calls for some new functionality we're working on taking > 30s to finish. The developer who originally wrote it was flabbergasted when I filed a PR to fix it, reducing the API call down to < 300ms, at which point we had a long, hard talk about why SQL-in-a-loop is bad and how libraries like EntityFramework are awful about hiding issues like that behind convenience. 
MadFriarAvelyn fucked around with this message at 01:35 on Aug 27, 2020 |
|
#
?
Aug 27, 2020 01:33
|
|
|
ChickenWing posted:Hello thread, just stopping by to remind everyone that ORMs are a faustian bargain and god help you if you let people who are Not Good At Sql develop with them  JPA in particular has some real pitfalls around joins/relationships that can result in running tons of extra queries.
|
|
#
?
Aug 27, 2020 16:02
|
|
|
Pedestrian Xing posted:
We're in a particular pickle because we've got a monstrously intertwined domain model (retail promotions) combined with massive amounts of data (we only do work for big fuckin' retailers) so a lot of our basic queries end up with a lot of joins on a lot of long tables with a lot of entities that have a lot of lazy-loaded relationships. Thus, when we add something as simple as a grouping function to a set field derived from a relationship, our already burdened 2min query turns into a request destroyer.
|
|
#
?
Aug 27, 2020 17:56
|
|
|
Yeah, anything beyond "Hello, Database!" apps become a nightmare when using an ORM. Even just object mappers like Dapper can become difficult once you start delving into splitOns.
|
|
#
?
Aug 27, 2020 19:15
|
|
|
I'm going to just state that the vast majority of software developers have a big hole in their expertise, and that hole is SQL. Most would hugely benefit from a deeper understanding of important SQL concepts like execution plans (and how to analyze them), indexes and locks.
|
|
#
?
Aug 27, 2020 19:29
|
|
|
what's there to learn really? you put stuff in the database when you want to save it and you get stuff out of the database when you want to show it and when your actions start taking way too long to save or show data you simply find a new job at a young startup and start all over again.
|
|
#
?
Aug 27, 2020 20:22
|
|
|
That's what Mongo is for, not SQL.
|
|
#
?
Aug 27, 2020 20:53
|
|
|
Use an in-memory SQLite that runs a backup to disk every 5 minutes
|
|
#
?
Aug 27, 2020 20:56
|
|
|
You kids get off my lawn.
|
|
#
?
Aug 28, 2020 07:45
|
|
|
prom candy posted:what's there to learn really? you put stuff in the database when you want to save it and you get stuff out of the database when you want to show it and when your actions start taking way too long to save or show data you simply find a new job at a young startup and start all over again. When you need to calculate things, just do SELECT * FROM, pull everything into python, then insert it all again after your calculation is done by iterating over all rows and inserting each one individually. Do this in pandas if you are a Data Scientist. Put SQL 5/5 on your resume.
|
|
#
?
Aug 28, 2020 18:04
|
|
|
|
| # ? Jun 3, 2024 02:24 |
|
|
Hollow Talk posted:When you need to calculate things, just do SELECT * FROM, pull everything into python, then insert it all again after your calculation is done by iterating over all rows and inserting each one individually. Do this in pandas if you are a Data Scientist. Put SQL 5/5 on your resume. I've had PRs land on my desk from a contractor where they were doing at least some of their filtering in memory after pulling in all rows, and were doing their own aggregations (literally they did not preserve ANY individual row data for what they were doing). It took me a lot of attempts to communicate how to make the database do this instead, I think I had to straight up send them example code.
|
|
#
?
Aug 28, 2020 18:52
|
|
