I’ve never encountered that, is that because it flushes the buffer?

Honestly I don't remember the mechanism but my guess is that if you are accessing uninitialized memory, you'll have more problems if you're using a piece of memory that you recently used and then deallocated. I think the cout might increase your chances of getting a fresh piece of memory with nothing in it (i.e. all zeros) which for a lot of degenerate cases will work OK.

Consider for example that strings in C/C++ are null terminated. If you use an unitialized pointer to a random segment that contains some data, it'll treat it as a string, terminated by the first NULL it finds. If the pointer is to an address that already contains a zero, then it'll be an empty string, which is probably what you wanted in the first place. And if it's not in the middle of memory you're already using/reusing, then it's unlikely to overflow into other variables.

A dirty secret of memory allocation is that if you screw it up, it might work anyway, if you get lucky and get pointers to memory that coincidentally contain compatible values or lucky address layouts.

Yea that happens all the time in my C programs when i use pointers to declare strings rather than setting their size, it’ll work like 99% of the time.

One particularly evil memory bug i dealt with recently that took me forever to find was i was using a global array to store data in, and i had an off by 1 error somewhere where even though i remembered to reset the variable that tracked the size of the array on each run of the function, like 1/10000 runs would use the last value improperly and it’d have data from the previous run and it took me like 4 hours to find it.

it was never noticed by me because you had to have two extremely rare things happen in a row to trigger the bug.

lol recruiters.

her: "hey we have this job that is x" where x is the general title/responsibilities I would look at if I was looking.

me: "that sounds good but unless its the comp is something I couldn't turn down ($foo) I'm not looking now".

her: "well its not $foo but it is up to (67% of $foo), want to talk more?"

I'm going to guess that a large number of people don't give the actual bare minimum that it would take for them to change jobs.

lol ok so i got assigned my first project today.

my boss calls me into his office with his two programmers for a certain sub-section of the overall project and says he wants to do a "guinea pig" sprint with us and have me lead it. so i sat down with the 2 devs and we went through the rather large list of issues and went down the list and figured out what was feasible for the next two weeks. we're going for a "stability release" so they just picked the most glaringly obvious stuff that can be fixed relatively quickly.

we're not using anything other than github's project section so I just created a project for this sprint, automated it, and put the issues in there. then i went down the other list of issues and shoved them into a separate project called "backlog" and i'm going to try to get either my boss or some of the other devs prioritize them all in the next 2 weeks.

I brought up the topic of daily stand up meetings, and one of the devs winced pretty bad. so i asked her why she thought that would be a problem and asked if she thought it was a waste of time and pretty much said "yea it is" so I got them to agree to a few times a week at least for this trial run and if they don't like it we can change things later.

not really sure what else I'm supposed to be doing and my boss still hasnt told me much so I'm just going through the issues and trying to understand them all, slowly going through the backlog and categorizing things in my notes, and then I found one easy-ish looking bug in our current sprint that no one has assigned themselves to yet so i think it'd be really good for my street cred if i worked on that one on my own. if i cant fix it, no loss, but if i can, it'd be pretty good i think.

basically i'm just winging it and in tomorrow's standup i want to try to gauge where they're at with this project and where the frustrations are so we can work on them. that's all i can do i guess.

almost nothing about this is scrum, so i guess i could slowly try to incorporate things if they like them.

so how does a PR work over there? How many people have to approve it before staging? Then what happens before a merge?

Daily meetings are overboard. Think weekly is ideal. You should be communicating over slack anyways during the week.

Pretty much just my boss. They have like unmerged branches all over the place too. I’m not even sure if i should talk about it, lol, it’s a mess.

I told them each sprint the goal should be 100% to try to merge to the master branch and they agreed and i’m gonna add the merge mess stuff to the backlog after i speak to my boss about it, but there’s so many other things that seem like they need to be dealt with.

I think daily meetings are fine but they should literally be 2 minutes/person and if they're more than 10 minutes your team is probably too big.

^^ I'd say 20 but yeah

I think full backlog grooming/prioritization is a big waste of time. I'd say always focus on the short/medium term stuff and don't worry about the rest. About every 18 months I use to delete 2/3 of my team's backlog w/o thinking about it at all.


Daily meetings are great and super useful. But, obviously have to be run well. My average time for a 8 person team was still under 10 minutes. Just a few rules:

1. You start on-time with (almost) no exceptions. It's a daily meeting, if someone misses or is late occasionally its not a big deal.

2. You don't talk about a single issue for more than 15-30 seconds. You can save these things for the end (when people are free to leave) or just write down the topic + the people and let people figure out when to talk. Or whatever. It doesn't matter except getting through scrum quickly.

3. Someone runs it. There are lots of formats for scrum, but one person needs to drive it and move through **** quickly. Cutting off discussion. Etc.

You don't need to be an ******* about any of these either. Tell people up front what the deal is and that its just so the meeting stays useful and not a waste of everyones time.


Merging to master probably shouldn't be a sprint goal as much as a task/story goal. The task/story isn't done until the code is merged. This obviously depends on your build/release process.

In actual practice, I have never had stand ups where someone didnt talk for 2+ minutes

standups need a moderator, and they need to be ruthless

"lets take this offline" x 100

Exactly this or call it a meet after.

Getting the team to agree on a definition of "done" is good. You've already begun it with suggesting the goal is get things merged back to master. This can catch hidden work that isn't being scheduled for like testing or showing whoever does the deploys how to deploy the new feature. It's a good thing to talk about during the retrospective to make sure it's still providing value to the team.

JJ whoever is building the roadmap cares about stuff more than 4 or 5 sprints away but the team doesn't. They should be doing just enough to make sure their is stuff ready for the next sprint. Which means the product owner should probably have the next two sprints of work prioritized so the pointing goes faster.

Yea our first sprint pretty much just has 1 “story” and i think thats fine.

i'm just really ****ing glad they gave me actual work to do today, even if i have no idea how to do it

Kerowo, the medium/long term roadmap shouldn’t be issues / stories in the backlog. By the time you get to them they’re almost certainly wrong and need to be rewritten. And half the stuff you thought you were going to do just becomes not important.

This is especially true at a small company.

Jmakin, a one story sprint isn’t great for lots of reasons. But generally, smaller tasks are easier to divide up and tackle and leads to better quality as well (imo).

Yea, but this is kind of a test run to get my feet wet

Plus i kinda have a feeling the devs took on too much in this one, we’ll see how it goes

Prioritizing and grooming the backlog is something to be done by the product owner. Shouldn't require anyone else really except for maybe a few questions.

Daily standups of 10-20 mins max are incredibly helpful. As was said "take this offline" needs to be a respected term and it also leads to great collaboration. Scrum master should be ruthless about running an efficient scrum.

We do grooming for incoming stories once a week and cancel it at least 50% of the time if we don't feel like we have enough worthy of grooming (are continuing to work on already groomed stories). I often like to work remote on days we groom so I can be quickly assessing the code-level of whatever it is we are talking about to get a better sense for the effort required and things I want to clarify.

This is one advantage of small stories - you can still get some stuff done (meaning complete done) even if you’ve picked too much work (and picking too much work is good then). It’s also good to realize you’re not aiming for 100% done each sprint because that encourages picking low goals. I’ve seen different numbers at different places but I’ve seen anywhere from 50-90% as the long term average goal.

We don’t actually measure on a sprint level but our sprint backlog is never close to empty at the end.

My company just restructured the teams and I was moved to another team with a tech stack and code base that I'm not familiar with. I'm familiarizing my self with the code by setting up a test environment and during that process I found a bug so I decided that fixing that would be a good way to figure things out. But most of the time this week has been taken up by meetings regarding the reorganization.

During the week the developers who have been in this team for years have been sending me 10ish pull requests with hundreds of lines of changes. I reviewed them but honestly can't say much about them because this is all new to me.

Today one of them gave me **** about not accepting the PRs. I said I didn't feel confident in accepting a PR for code that I barely understand yet, and his response was "You're an experienced developer, why don't you understand this?"

This is completely unreasonable by him, right?

One other thing I’d say about a daily scrum is that I think it’s important to emphasize its not about proving your worth.

People don’t need to say everything they’re doing - just cover what’s relevant to the project and team. It’s fine for someone to say they didn’t work on something the day before because they were dealing with unexpected production problems. You just don’t want a detailed list like ‘dealt with issue A, had an interview for position B, talked to C about issue their team was having, debugged my laptop, went to company wide meeting , ...

This is a bit tricky because naturally people want to justify why they’re not doing something everyone thinks they should be. But it’s important to keeping the meeting actually useful so you need to build a culture where people feel ok with this.

And then your job (and their manager) is to actually figure out when there is a real problem and deal with that outside of scrum.

This also means you usually shouldn’t use scrum (the main meeting at least - fine as follow up discussions) to question someone on why their stories are taking too long or why stuff isn’t getting done.

There’s some amount of ‘it depends’ but the attitude is unreasonable and I think most of the time his expectations are too.