Which #dbgeng interface to use? For example, both IDebugSymbols2 and IDebugSymbols3 implement GetModuleNameString(). Should I use I2 to support older OS versions or I3 for a possibly improved implementation? #windbg
In general, if you need to change a test because you changed the code, you didn't have a test at all. The whole _point_ of a test is that, when I make a change, I want to run the test to see if I've broken anything. A good test works both before and after the change. If I have to change the test, too, I've proven nothing. Any test that knows how the code works (as compared to what the code does) is fundamentally flawed.
I hear a lot about using an LLM not only to write code but also to write tests. I've rarely seen that work. IME, the LLM-generated tests are too fragile and test the wrong things (the implementation, not the intent).
People talk about spec-driven design, but the best spec you can have is a test—a test you write before you write the code. You don't write a test to see if the code adheres to a spec. The test IS the spec. Don't write specs. Write tests.
Custom frameworks:
> I designed a new utensil for eating.
It looks like a weird spoon. I don't need it. I have utensils.
> I put a lot of work into it, so you need to eat with it.
I'm trying to eat spaghetti. I can't pick up spaghetti with your weird spoon.
[three days later]
> I modified it so you can attach a fork to it. Now it works. Be sure to use my new utensil.
I can't cut my steak with it.
> Well you shouldn't be eating steak. That's your problem. If you stop eating steak my utensil won't have any problems.
Ok, fine. But I can't cut this healthy baked potato with it.
> Look, I'm busy. Working on this utensil isn't all I do. You need to pitch in and figure out how to modify it to do what you want.
I'll just use my old utensils.
> We can't have everyone using different utensils. New people who eat with us will be confused. That's why we're standardizing on my new one.
Fine.
[one week later]
>> Who changed the utensil? Last week I was using it to eat soup, but now the potato-cutting part pokes me in the face.
> I'm starting over on Utensil 3.0. It's going to automate all of that. When it's almost done I'll record a video showing how to work it. Everyone set aside time to switch over.
How to stop the #windbg dx command from only showing 0x63 elements at a time along with […]? I tried ‘-c 1000’ and nothing was displayed. I tried ‘-c 1’ and ‘-c 0’ and the behavior was the same as not specifying ‘-c’ at all.
"Writing code is no longer the bottleneck" is how AI fans tell their bosses "it's okay now, I chased the monster out from under the bed and he won't be back."
A total lie, but one that they can hear instead of the truth: that it never was.
Oh wow, appending ‘.Where(p => p.Count())’ did the trick. But what the heck is being counted? The number of threads that satisfied the where clause?
How can I get this #windbg LINQ command to return only processes with a suspended thread? As is, it returns empty process objects for those without suspended threads: dx -r2 @$cursession.Processes.Select(p => p.Threads.Where(t => t.KernelObject.Tcb.SuspendSchedulerApcWait != 0))
In honor of today's 25th anniversary of the Agile Manifesto, I'd like to remind everybody that the very first sentence starts with: "We are uncovering better ways of developing software by doing it…" The critical word in that sentence is "uncovering." They didn't say "uncovered," which would mean there's no more work to do. Instead, they are talking about an active and ongoing activity: uncovering.
Nowhere in the Manifesto does it tell you *how* to work. There are no sprints, backlogs, standups (or any other meeting), SMs, POs, PBIs, tickets, or any of the other barnacles that have accreted over time, often added by people with suspect agendas (like selling certificates). The one exception is: "the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly." We are constantly improving how we work ("uncovering"), which, to me, suggests that we add, remove, and change things, and we make those changes based on observation and assessment.
This attitude is particularly important when a radical new tool, such as an LLM, emerges. We improve "by doing it." We use the new thing, then decide based on our experience. We don't just sit back and say it doesn't work because it's not what we're doing now, or because some moron has hyped it too much. Agility is scary. It requires constant personal experimentation with new ways of working. Some of those things work, some don't, but you don't know until you try.
The next important word is "ways," plural. I've never seen any good come from everyone marching in lockstep to a specific process or framework. At best, that uniformity adds friction. At worst, it adds dysfunction. Every team, every story, every situation, is unique and requires unique ways of working. Create a set of values and principles, and as long as people adhere to those, you're golden. The people who do the work are in the best position to figure out how to do the work. Of course, control-obsessed people high up in an organization hate that because they can't control it. They call it "chaos." Replacing control for trust is an essential element of becoming "Agile," however.
Finally, the end of that initial sentence is "…and helping others do it." We improve as a community through collaboration and communication. That can be fraught. E.g., the #NoEstimates tag began when Woody Zuill posted that his team had just finished a successful project without estimates. Instead of "that's interesting, tell me more," the reactions were often hateful attacks that came down to "It's not possible to work without estimates, so you're an incompetent, irresponsible liar." But it _did_ work. That was the whole point. Working is the starting point of the discussion. Try it and then comment. Experimentation fills in the details. That's how you learn and improve. That's Agile.
@33y0re Thank you!! Followup question: Why do both ‘@$myThread->’ and ‘@$myThread.’ work when calling ToDisplayString? It seems that @$myThread is both a pointer and an object.
In the #windbg data model, I can get a thread’s _ETHREAD via ‘dx @$curthread.KernelObject’. But how can ‘dx’ be used to get the address of the _ETHREAD so that I can pass it to the older ‘.thread’ command?