Anchovy spawning causes temperature swings and turbulence in ocean layers(hakaimagazine.com)
hakaimagazine.com
Anchovy spawning causes temperature swings and turbulence in ocean layers
https://hakaimagazine.com/news/anchovy-sex-is-a-force-of-nature/
7 comments
Weird title, since as the article takes the time to note, anchovies don't have sex.
If the article really claims that anchovies don't have sex, then you have saved me ten precious minutes of my life. Thanks.
The article mentions it in passing. This isn't a controversial claim or anything; it's very common in fish.
Let me fix it for you. It must say: All fish species have sex.
I would even dare to say that a few even have better sex than us.
I would even dare to say that a few even have better sex than us.
You want to replace accurate information with lies?
I don't think being playful with the use of "sex" in the headline is weird. The article is more infotainment than hard science. Its audience might not necessarily know about spawning, and for all intents and purposes, using "sex" to mean "reproduction" generically as a figure of speech isn't really a stretch.
Reminds me of the grunion, really.
wonderful article, both entertaining and educational. helped to pass the time during my hour-long stand-up.
This is a question I want to know - is anyone actually paying attention to everything during standup? It seems some people are, because they occasionally have insightful comments. Even when I'm not distracting myself, I totally zone out in meetings and have no idea what was being said.
The only times where I can actually pay attention is in meetings where I have the right to (and it is conducive to) constantly interrupt with questions. Then my brain suddenly sees the information as useful because I'm looking for opportunities to say something.
The only times where I can actually pay attention is in meetings where I have the right to (and it is conducive to) constantly interrupt with questions. Then my brain suddenly sees the information as useful because I'm looking for opportunities to say something.
* Alternate different people at random to run the standup
* Control people who talk for too long or go into detail that's not worthwhile
* If you have a board, run through each ticket in progress/in review for a casual update, record it as a note
* Have an icebreaker (1 minute) before or after, ie "fun fact of the day" or something and randomly choose people to do it
* Ends with a section on anything else to add, if anyone is blocked, whatever, and have people break out into their own meetings if necessary
* If it spills over 15 minutes then continue to trim down on the update complexity
* Control people who talk for too long or go into detail that's not worthwhile
* If you have a board, run through each ticket in progress/in review for a casual update, record it as a note
* Have an icebreaker (1 minute) before or after, ie "fun fact of the day" or something and randomly choose people to do it
* Ends with a section on anything else to add, if anyone is blocked, whatever, and have people break out into their own meetings if necessary
* If it spills over 15 minutes then continue to trim down on the update complexity
> Alternate different people at random to run the standup
I feel like having to resort to tricks to keep people engaged in a meeting is a good sign that the meeting isn't a good use of time.
I feel like having to resort to tricks to keep people engaged in a meeting is a good sign that the meeting isn't a good use of time.
It's less about keeping people engaged and more about making everyone in the team understand how it should be ran. Once you run these meetings a handful of times you start to appreciate that people coming in late or giving nonsensical contributions is irritating and the outcome is that the individual who ran it ends up contributing better to the same meeting next time.
This goes for all meetings (and literally all roles in all workplaces even outside of tech). It's there to build first hand understandings and empathy and, if these meetings are a waste of time, empowers the entire team to change it or abandon it.
This goes for all meetings (and literally all roles in all workplaces even outside of tech). It's there to build first hand understandings and empathy and, if these meetings are a waste of time, empowers the entire team to change it or abandon it.
I dunno when I run standup I am just as passive as when I'm part of it. I just prompt people to speak and then zone out if its not useful like every time.
You forgot the most important part - buy-in from management. It wouldn't surprise me if they're the reason the updates are lengthy.
That's true, but some people also just like to ramble
The rambling is easier to correct than having a boss that wants an in-depth status on every ticket.
We routinely have standups less than 5 minutes unless someone has something they want to discuss with the team. Our EM doesn't even want status updates since that's already shown on the JIRA board. "No blockers" is a fine verbal contribution to standup.
This business of hour-long standups sounds insane and so wasteful. If it's taking devs that long, it sounds like something is missing elsewhere.
Here are some questions that might help identify the problem. Are you using a good ticket/issue tracker? Are devs talking/collaborating during the day? Is there a sense of group ownership of work done? Is there a tech owner/point person for each epic/larger unit of work? Are you breaking tickets down into small pieces (no more than a few days of work each)? Do devs discuss implementation plans regularly? Are business requirements clearly communicated? Do you practice continuous delivery (release each ticket directly to production when done - if need be, behind a feature flag)? Does the business optimize for DORA metrics? Do dev teams own decoupled vertical slices of technology?
This business of hour-long standups sounds insane and so wasteful. If it's taking devs that long, it sounds like something is missing elsewhere.
Here are some questions that might help identify the problem. Are you using a good ticket/issue tracker? Are devs talking/collaborating during the day? Is there a sense of group ownership of work done? Is there a tech owner/point person for each epic/larger unit of work? Are you breaking tickets down into small pieces (no more than a few days of work each)? Do devs discuss implementation plans regularly? Are business requirements clearly communicated? Do you practice continuous delivery (release each ticket directly to production when done - if need be, behind a feature flag)? Does the business optimize for DORA metrics? Do dev teams own decoupled vertical slices of technology?
I think creating a culture where it’s ok to not have to justify yourself is so hard but important. Being able to say “nothing of note to update the team on” or “still focused on X,y,z at the moment” is great. If team members or leaders want to dig in / ask questions great. So many organizations create dynamic where people
feel they need to demonstrate all the work they’re doing (and some people just have an innate need to do this as well (often the least productive people)). Obviously leaders and managers to need to be connected to that - but standups don’t seem to be the right place for that
This is a problem created by management though. So many meetings are just reiterating data. Managers feel the need to say "ok everyone, here is the data we all have access to. I will now read it aloud to you." or "Please give me all the information that is already in our ticketing system and read it to me." And that justifies their paycheck.
There's just no fixing that.
There's just no fixing that.
> This business of hour-long standups sounds insane and so wasteful.
The media has been proclaiming "Agile is dead" recently. I wonder if all these tech layoffs have come simply because that hour was gained back for productive use?
The media has been proclaiming "Agile is dead" recently. I wonder if all these tech layoffs have come simply because that hour was gained back for productive use?
I think most of what people call "Agile" (big A) is a cargo-cult where they try to imitate and prioritize the very things the original manifesto[0] devalues -- especially processes and tools and following a plan.
All that while devaluing or ignoring the power of individuals and interactions and responding to change.
It turns out that who you hire, how they interact, and how productive you allow them to be have far more power to create value than applying certain "Agile" processes and tools.
[0] https://agilemanifesto.org/
All that while devaluing or ignoring the power of individuals and interactions and responding to change.
It turns out that who you hire, how they interact, and how productive you allow them to be have far more power to create value than applying certain "Agile" processes and tools.
[0] https://agilemanifesto.org/
If you find that people need to discuss so much that it takes too long and people aren't paying attention, those discussions need to go into another meeting.
Having a good product owner is important for coordinating meetings in general. Standups should be for tracking progress on tasks and nothing more. If someone is blocked they should briefly state why and follow up ASAP, but after the standup.
Having a good product owner is important for coordinating meetings in general. Standups should be for tracking progress on tasks and nothing more. If someone is blocked they should briefly state why and follow up ASAP, but after the standup.
> Standups should be for tracking progress on tasks and nothing more.
Then what's the point? I probably don't care about someone's status in the first place, and when I do a big fat notification informs me when the status has changed the second it changes. "Duh. I'm still working on it, obviously." doesn't tell me anything.
> If someone is blocked they should briefly state why and follow up ASAP
If someone is blocked by my doing, they would have already told me 23.5 hours[1] before the scheduled meeting came around, when they became blocked. I don't need to hear it a second time. If it has nothing to do with me, I don't care. What's the point?
[1] Or even longer if not on a daily meeting schedule. Way too long if you sit around and wait for the meeting to finally come around before talking to anyone.
Then what's the point? I probably don't care about someone's status in the first place, and when I do a big fat notification informs me when the status has changed the second it changes. "Duh. I'm still working on it, obviously." doesn't tell me anything.
> If someone is blocked they should briefly state why and follow up ASAP
If someone is blocked by my doing, they would have already told me 23.5 hours[1] before the scheduled meeting came around, when they became blocked. I don't need to hear it a second time. If it has nothing to do with me, I don't care. What's the point?
[1] Or even longer if not on a daily meeting schedule. Way too long if you sit around and wait for the meeting to finally come around before talking to anyone.
I used to think like this before I worked on projects with more coordination and visibility than just other devs.
The daily standups are for management and whoever else is invited from time to time. You're 100% correct that you shouldn't wait for tomorrow's standup to discuss something technical with another developer. You shouldn't be getting lost in the weeds during standups anyway. That's one of many reasons standups can take forever.
Also, a well run standup can be as simple as one person sharing their screen while walking through the tasks and asking yes/no questions. You don't need everyone to speak all the time because as you said that wastes time. Anyone can read the issues statuses at any time or query what they need.
These meetings are for more insightful questions than that from management: "You and a couple of other devs on this story said your tasks are blocked because this servicenow ticket for another team is still in progress? I've reached out and they said they're going to be done by noon. Will you complete your in progress tasks by then or should we reassign or push their dates back so you can continue this higher priority ticket?" ... "Great I'll update the backlog for the sprint starting next week and your time in the capacity tracker" ... "You scheduled PTO? We've got everything all set for the next sprint so no worries. Have a nice vacation!" It's not a dream. Agile done right is like this.
If you hate the idea of a meeting like this it's possible your managers suck and don't listen to you. They're supposed to be working for you to keep the runway clear. When they hear all the status updates all at once in daily meetings they should be getting ready for the next sprint and coming up with good ideas behind the scenes. That includes bringing in resources, making sure dependent tasks on other projects are completed so you don't get blocked, etc.
The daily standups are for management and whoever else is invited from time to time. You're 100% correct that you shouldn't wait for tomorrow's standup to discuss something technical with another developer. You shouldn't be getting lost in the weeds during standups anyway. That's one of many reasons standups can take forever.
Also, a well run standup can be as simple as one person sharing their screen while walking through the tasks and asking yes/no questions. You don't need everyone to speak all the time because as you said that wastes time. Anyone can read the issues statuses at any time or query what they need.
These meetings are for more insightful questions than that from management: "You and a couple of other devs on this story said your tasks are blocked because this servicenow ticket for another team is still in progress? I've reached out and they said they're going to be done by noon. Will you complete your in progress tasks by then or should we reassign or push their dates back so you can continue this higher priority ticket?" ... "Great I'll update the backlog for the sprint starting next week and your time in the capacity tracker" ... "You scheduled PTO? We've got everything all set for the next sprint so no worries. Have a nice vacation!" It's not a dream. Agile done right is like this.
If you hate the idea of a meeting like this it's possible your managers suck and don't listen to you. They're supposed to be working for you to keep the runway clear. When they hear all the status updates all at once in daily meetings they should be getting ready for the next sprint and coming up with good ideas behind the scenes. That includes bringing in resources, making sure dependent tasks on other projects are completed so you don't get blocked, etc.
It would be nice if standup was actually about asking active questions only because then I wouldn't mentally fall asleep during it. In reality its almost always about just calling out names and hearing someone ramble until maybe you wake up enough to ask a follow-up question.
Yes, once every thousand days (made up, but not too far from reality) when there actually is something for the group to come together and discuss, the standup is a useful tool. Although you're probably better to just schedule the meeting only when there is something to discuss. Gathering everyone each day just to see is kind of wasteful.
Granted, that waste keeps people employed. The tech layoffs of late is unquestionably because "Agile" isn't cool anymore, and those hours wasted to standups are now, by and large, put to productive use instead.
Granted, that waste keeps people employed. The tech layoffs of late is unquestionably because "Agile" isn't cool anymore, and those hours wasted to standups are now, by and large, put to productive use instead.
> Agile done right is like this.
That doesn't sound like Agile, at least not the Manifesto one. Agile is pretty clear that there are no managers. It, ultimately, offers suggestions of what you need to think about if you are to move to an ad-hoc organization structure. For instance, per the 12 Principles, "Business people and developers must work together daily throughout the project." There is no room for a manager in that. There is no independent "keeping the runway clear" or "coming up with ideas behind the scenes". That's the work developers and business people are doing – why they are working together.
Here's a few more:
* "Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale." – Translation: Without a manager keeping tabs on everyone's progress, the easiest way for the team to stay on top of progress is to see it.
* "Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done." – Translation: Don't accept people into your group who need someone (i.e. a manager) to hold their hand.
* "The most efficient and effective method of conveying information to and within a development team is face-to-face conversation." – Translation: There is no manager ensuring everyone is aligned and on the same page.
* "The best architectures, requirements, and designs emerge from self-organizing teams." – Translation: With no manager to organize the group, you need to figure out who is going to do what on your own.
* "At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly." – Translation: You don't have a manager watching over to see where improvement can be made. Figure it out for yourselves.
Whether or not Agile is suitable for your organization, or any organization!, is another matter. Indeed, one should not accept Agile into their life just because it has a catchy name. Probably not at all. One must remember that the Agile signatories live in a different reality to most developers.
> If you hate the idea of a meeting like this it's possible your managers suck and don't listen to you.
Whether or not they are listening, I'm not sure what I would want to tell them? What I do know from many, many years of experience is that when you have a good manager, you won't even know they exist. A manager who needs to gather the group around the campfire each day is decidedly not a good manager. Heck, even most staunch standup supporters will tell you that managers shouldn't be invited to the standup as it easily becomes a crutch for bad management.
That doesn't sound like Agile, at least not the Manifesto one. Agile is pretty clear that there are no managers. It, ultimately, offers suggestions of what you need to think about if you are to move to an ad-hoc organization structure. For instance, per the 12 Principles, "Business people and developers must work together daily throughout the project." There is no room for a manager in that. There is no independent "keeping the runway clear" or "coming up with ideas behind the scenes". That's the work developers and business people are doing – why they are working together.
Here's a few more:
* "Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale." – Translation: Without a manager keeping tabs on everyone's progress, the easiest way for the team to stay on top of progress is to see it.
* "Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done." – Translation: Don't accept people into your group who need someone (i.e. a manager) to hold their hand.
* "The most efficient and effective method of conveying information to and within a development team is face-to-face conversation." – Translation: There is no manager ensuring everyone is aligned and on the same page.
* "The best architectures, requirements, and designs emerge from self-organizing teams." – Translation: With no manager to organize the group, you need to figure out who is going to do what on your own.
* "At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly." – Translation: You don't have a manager watching over to see where improvement can be made. Figure it out for yourselves.
Whether or not Agile is suitable for your organization, or any organization!, is another matter. Indeed, one should not accept Agile into their life just because it has a catchy name. Probably not at all. One must remember that the Agile signatories live in a different reality to most developers.
> If you hate the idea of a meeting like this it's possible your managers suck and don't listen to you.
Whether or not they are listening, I'm not sure what I would want to tell them? What I do know from many, many years of experience is that when you have a good manager, you won't even know they exist. A manager who needs to gather the group around the campfire each day is decidedly not a good manager. Heck, even most staunch standup supporters will tell you that managers shouldn't be invited to the standup as it easily becomes a crutch for bad management.
In my personal experience I’ve found stand ups are incredibly easy to sidetrack. One dev starts going into too much detail about a troublesome aspect of their ticket instead of simply stating what the problem is and then organizing a time after the standup to meet with the colleague best suited to assist.
Standups shouldn’t be a rubber duck session with the entire team.
Standups shouldn’t be a rubber duck session with the entire team.
Imo standups shouldn't have more than 5 or 6 people in them. If there's more than that you're probably not all working closely enough for the standup to provide much value - find some nice cutting point in the project, split into smaller teams.
Depends on the stand-up.
For the past 10 years I'd say most of my standups have been painless, quick, and productive, but I've both selected good jobs and/or worked with the team for that to be the case.
Mine usually don't last more than 10-15 minutes, no one has to read ticket by ticket and give detailed status updates, we simply look at 2 columns on the board (for what's in progress and what's in waiting/blocked) and ask: "anything someone want to bring up about these tasks?" to have a sanity check if everything is alright or if someone needs help, or if someone wants to share some quick information. After there's a general question "anything else you want to bring for the standup?" for the stuff we don't have a ticket for, or quick updates from PMs/EMs about things outside of our current scope/context.
Any further discussion is taken after the standup, if some topic starts to grow into a discussion we are strict about bringing it for discussion with the interested ones right after the standup. Those discussions never last more than 20-30 min, if they need more time we schedule a meeting with proper agenda, etc.
Whenever I worked at a place with dysfunctional ones I either managed to help correct course, or quit the job.
To me teams with good standup hygiene will very likely have meetings/processes hygiene as well, and is a very good signal of a well functioning team.
For the past 10 years I'd say most of my standups have been painless, quick, and productive, but I've both selected good jobs and/or worked with the team for that to be the case.
Mine usually don't last more than 10-15 minutes, no one has to read ticket by ticket and give detailed status updates, we simply look at 2 columns on the board (for what's in progress and what's in waiting/blocked) and ask: "anything someone want to bring up about these tasks?" to have a sanity check if everything is alright or if someone needs help, or if someone wants to share some quick information. After there's a general question "anything else you want to bring for the standup?" for the stuff we don't have a ticket for, or quick updates from PMs/EMs about things outside of our current scope/context.
Any further discussion is taken after the standup, if some topic starts to grow into a discussion we are strict about bringing it for discussion with the interested ones right after the standup. Those discussions never last more than 20-30 min, if they need more time we schedule a meeting with proper agenda, etc.
Whenever I worked at a place with dysfunctional ones I either managed to help correct course, or quit the job.
To me teams with good standup hygiene will very likely have meetings/processes hygiene as well, and is a very good signal of a well functioning team.
Would love to suggest this. Might be bold as a fairly new junior though haha. I do think these meetings would make far more sense if we only discussed things that people had issues with. If everyone's just rambling it's pointless. My standup are rarely an hour but they are often about 30 mins which is already just unnecessary most days.
The thing I hate most is sprint planning and refinement. People make such big deals about everything and it can easily last over an hour. I especially hate all the drama about making sure our workload is right and moaning about how long things will take and politics and such. I'm starting to think it's some sort of cult of unproductivity ever since the senior frontend guy said that an angular upgrade would take us 2 years and loads of seniors so it's not worth starting this year. It's a massive load of version but ain't no way that's gonna take 2 years and that we can't do it with the one senior frontend, one mid frontend and one junior fullstack (me).
The thing I hate most is sprint planning and refinement. People make such big deals about everything and it can easily last over an hour. I especially hate all the drama about making sure our workload is right and moaning about how long things will take and politics and such. I'm starting to think it's some sort of cult of unproductivity ever since the senior frontend guy said that an angular upgrade would take us 2 years and loads of seniors so it's not worth starting this year. It's a massive load of version but ain't no way that's gonna take 2 years and that we can't do it with the one senior frontend, one mid frontend and one junior fullstack (me).
> or quit the job.
sadly it took me years to understand that this is a perfectly valid solution.
But damn, that's so hard to do (at least to me :-))
sadly it took me years to understand that this is a perfectly valid solution.
But damn, that's so hard to do (at least to me :-))
Depends how they're done.
I try to push for people to actually stand up during a stand up, because that encourages the meeting to be short and to the point, not an hour of pointless waffle (and if it's an hour long meeting, waffle is probably an apt description).
I try to push for people to actually stand up during a stand up, because that encourages the meeting to be short and to the point, not an hour of pointless waffle (and if it's an hour long meeting, waffle is probably an apt description).
YES. I remember watching day in the life of a se videos like 7 years ago when I was 18ish and vaguely considering the career (I didn't go for it and took a long route), and I remember distinctly that the whole point of stand up was that you STAND. it's in the name and its like that for a reason. Now, having started in the industry, I was so confused that people ignore the whole imperative of the name and make it into the exact sort of sprawling business meeting that it's not supposed to be.
Standing up is not enough for some managers to cut it short. I recommend standing on one leg, or keeping your arms raised.
I once worked at a company that decided to do Samson's chair during standup.
It was brutally effective, especially those who went last sounded like a new Eminem single. Standupps went from >30 to <1 minute immediately
It was brutally effective, especially those who went last sounded like a new Eminem single. Standupps went from >30 to <1 minute immediately
I just had to look that up. It’s another name for a wall sit. Brutal!
I can't stand for more than a couple minutes before my back hurts.
I propose that whoever is talking must stand. This punishes people who get into details of their task, and nobody else.
I propose that whoever is talking must stand. This punishes people who get into details of their task, and nobody else.
> This finding suggests that in shallower water, the ruckus produced by plentiful piscine participants procreating all at once might be more powerful and more important for ocean mixing than previously thought.
And, of course, fantastic use of alliteration.
And, of course, fantastic use of alliteration.
The POINT of calling it a "stand-up" was supposed to be that we STOOD up during the meeting in order to ensure that we wouldn't let the meeting run too long. 10 mins was a reasonable time for most team sizes when the idea was first created.
"during my hour-long stand-up."
And I thought my organization was dysfunctional.
And I thought my organization was dysfunctional.
[deleted]
> hour-long
> standup
what
> standup
what
Every place I have worked at has remained seated for the "standup" because it's tiring to stand for that long.
(For those who aren't looped into the irony: the entire reason why it is called a "standup" is because you are supposed to stand up to create subtle pressure against long unnecessary meetings. Sitting down for a stand-up isn't just a quirky paradox of jargon-meets-reality, it is a fundamental rejection of the entire premise while cynically parroting the terminology itself.)
(For those who aren't looped into the irony: the entire reason why it is called a "standup" is because you are supposed to stand up to create subtle pressure against long unnecessary meetings. Sitting down for a stand-up isn't just a quirky paradox of jargon-meets-reality, it is a fundamental rejection of the entire premise while cynically parroting the terminology itself.)
Exactly.
My stand-ups are 10-15 minutes, usually. When they use the full allocated 30 minutes it's because somebody wanted to dig into a specific topic (and anybody not interested in that topic is free to leave).
This is a normal agile development team - 1 manager (me) and ~6 engineers. We do the quick round-robin update, I'll make any announcements or ask for clarification, then if there's something that requires it, a deep dive (as deep as you can get in the remaining time).
My stand-ups are 10-15 minutes, usually. When they use the full allocated 30 minutes it's because somebody wanted to dig into a specific topic (and anybody not interested in that topic is free to leave).
This is a normal agile development team - 1 manager (me) and ~6 engineers. We do the quick round-robin update, I'll make any announcements or ask for clarification, then if there's something that requires it, a deep dive (as deep as you can get in the remaining time).
> produced by plentiful piscine participants procreating... powerful
perfect
perfect