we're in the minority I think. I always find it easier to just debug a problem from first principles instead of assuming that it worked at some point and then someone broke it. often times that assumption is wrong, and often times the search for bad commit is more lengthy and less informative than doing the normal experimental process. I certainly admit that there are ases where the test is easily reproducible and bisect just spits out the answer, but that a seductive win. I certainly wouldn't start by reading the commit log and rewinding history until I at least had a general idea of the source of the problem, and it wasn't immediately obvious what to try next to get more information.
if you look at it as in investment in understanding the code base more than just closing the ticket as soon as possible, then the 'lets see what really going on here' approach makes more sense.
> I certainly wouldn't start by reading the commit log
Me neither, for what is worth. But even if the idea is "when in order to figure out this issue, you have to go to the history", a linear history and a linear log never helped me either. For example, to find where a certain change happened to try to understand what was the intent, what I need is the commit and its neighbors, which works just as well with linear vs branching history because the neighbors are going to still be nearby up and down, not found via visual search.
maybe. I think we're really just starting this, and I suspect that trying to fuse neural networks with symbolic logic is a really interesting direction to try to explore.
that's kind of not what we're talking about. a pretty large fraction of the community thinks programming is stone cold over because we can talk to an LLM
and have it spit out some code that eventually compiles.
personally I think there will be a huge shift in the way things are done. it just won't look like Claude.
I'm finally revisiting a distributed syscall model for transparently scaling unix instances. syscalls get translated into batched operations on an underlying non-transactional datastore. On the service side, database operations get backed by a proxy serving whatever filesystem or socket interface you like. Scaling is one motivation, but the ability to enforce fine-grained policy on these data operations is another big one.
its not not about fun. when I'm going through the actual process of writing a function, I think about design issues. about how things are named, about how the errors from this function flow up. about how scheduling is happening. about how memory is managed. I compare the code to my ideal, and this is the time where I realize that my ideal is flawed or incomplete.
I think alot of us dont get everything specced out up front, we see how things fit, and adjust accordingly. most of the really good ideas I've had were not formulated in the abstract, but realizations had in the process of spelling things out.
I have a process, and it works for me. Different people certainly have other ones, and other goals. But maybe stop telling me that instead of interacting with the compiler directly its absolutely necessary that instead I describe what I want to a well meaning idiot, and patiently correct them, even though they are going to forget everything I just said in a moment.
> ... stop telling me that instead of interacting with the compiler directly its absolutely necessary that instead I describe what I want to a well meaning idiot, and patiently correct them, even though they are going to forget everything I just said in a moment.
This perfectly describes the main problem I have with the coding agents. We are told we should move from explicit control and writing instructions for the machine to pulling the slot lever over and over and "persuading the machine" hoping for the right result.
I wasn't trying to enforce reciprocity. I'm just saying that if you don't need help you shouldn't be asking for it from strangers.
If you have a job and income you can afford transportation. Behaving like a broke person when you are not is taking advantage of other people, and taking limited kindness resources away from people who actually need help.
If you are morally obligated to use your own resources if you have them, then you're stratifying society. The financially comfortable can never ride a bus. The rich cannot drive themselves. Nobody can ever learn what those less fortunate are like, and must necessarily look down upon them and use their imagination to figure out what "those people" care about and need.
So that's not a great outcome either.
(I don't exactly disagree with you either. Accepting a scarce resource from someone when you possess significantly more? That rubs me the wrong way too. Get their mailing address and pay it back later, in spades, if it deprived them of something!)
I did a DFU firmware update app for Jawbone once. after a bit of screwing around trying to figure out some of the reset paths we were good. and then the marketing people got involved. this was a customer touch point, and opportunity to reenforce the brand that just couldn't be ignored.
thats a largely meaningless response. enforcing a decent and maintainable architecture is potentially of great value to the company. Unfortunately thats a subjective call. I'm sure you've lived through codebases that dont really admit bug fixes or feature enhancements - things that the company knows that it cares about.
as professionals who are invested in the long term success of the company, it our responsibility to bring up concerns about the future, and attempt to negotiate a good compromise between the short term and long terms goals.
I've worked some in metal fabrication and supported some light industry. if you think anyone in a normal business in the US that hires less than 50 hourly people has even read the OSHA regs, you're completely unconnected with the reality
we really do call those stamping machines 'finger eaters'
I work in manufacturing and stamping machines scare the shit out of me, usually because of the forces involved but I did work on some that were not guarded. That was not in the US however.
My first job with a stamping machine was in a company with about 30 production workers. This was early 2000s in the southern US, all the workers were from Latin America and I think that most of them were not here legally(I say this because the company used temp agencies to employ the workers and at one point later they wanted to bring one of them on in a management role so they had me(also a temp) ask if the person wanted too switch the the higher paying but also requiring them to submit legal documents role).
Even under those circumstances, I never saw the company do something that skirted OSHA regs. Their stamping machine was a POS that was annoying as hell to use, mostly because the light curtain and other safetys kept tripping but it was never bypassed.
they did the same to me just by going through the job listings and x-ing out the ones that I wasn't interested in. of course for some reason that doesn't really work, the keep coming back, but wth, might as well try to keep down the noise.
If you read the paperwork for the visa application, this is pretty much all it's about. no one is trying to judge the quality of your artistic contribution. its all about how much money you're moving as a professional artist.
if you look at it as in investment in understanding the code base more than just closing the ticket as soon as possible, then the 'lets see what really going on here' approach makes more sense.
reply