Xyz makes sense because that is what those axes are literally labeled, but ijk I will rail against until I die.
There's no context in those names to help you understand them, you have to look at the code surrounding it. And even the most well-intentioned, small loops with obvious context right next to it can over time grow and add additional index counters until your obvious little index counter is utterly opaque without reading a dozen extra lines to understand it.
(And i and j? Which look so similar at a glance? Never. Never!)
> There's no context in those names to help you understand them, you have to look at the code surrounding it.
Hard disagree. Using "meaningful" index names is a distracting anti-pattern, for the vast majority of loops. The index is a meaningless structural reference -- the standard names allow the programmer to (correctly) gloss over it. To bring the point home, such loops could often (in theory, if not in practice, depending on the language) be rewritten as maps, where the index reference vanishes altogether.
The issue isn't the names themselves, it's the locality of information. In a 3-deep nested loop, i, j, k forces the reader to maintain a mental stack trace of the entire block. If I have to scroll up to the for clause to remember which dimension k refers to, the abstraction has failed.
Meaningful names like row, col, cell transform structural boilerplate into self-documenting logic. ijk may be standard in math-heavy code, but in most production code bases, optimizing for a 'low-context' reader is not an anti-pattern.
If the loop is so big it's scrollable, sure use row, col, etc.
That was my "vast majority" qualifier.
For most short or medium sized loops, though, renaming "i" to something "meaningful" can harm readability. And I don't buy the defensive programming argument that you should do it anyway because the loop "might grow bigger someday". If it does, you can consider updating the names then. It's not hard -- they're hyper local variables.
In a single-level loop, i is just an offset. I agree that depending on the context (maybe even for the vast majority of for loops like you're suggesting) it's probably fine.
But once you nest three deep (as in the example that kicked off this thread), you're defining a coordinate space. Even in a 10-line block, i, j, k forces the reader to manually map those letters back to their axes. If I see grid[j][i][k], is that a bug or a deliberate transposition? I shouldn't have to look at the for clause to find out.
The context is i, j, k as indices in programs. No doubt FORTRAN was influenced by prior use such as you cite. But in no case does i used as an index come from i designating an imaginary number, which is what I aimed to refute.
If you're logging and reporting on ERRORs for 400s, then your error triage log is going to be full of things like a user entering a password with insufficient complexity or trying to sign up with an email address that already exists in your system.
Some of these things can be ameliorated with well-behaved UI code, but a lot cannot, and if your primary product is the API, then you're just going to have scads of ERRORs to triage where there's literally nothing you can do.
I'd argue that anything that starts with a 4 is an INFO, and if you really wanted to be through, you could set up an alert on the frequency of these errors to help you identify if there's a broad problem.
You have HTTP logs tracked, you don't need to report them twice, once in the HTTP log and once on the backend. You're just effectively raising the error to the HTTP server and its logs are where the errors live. You don't alert on single HTTP 4xx errors because nobody does, you only raise on anomalous numbers of HTTP 4xx errors. You do alert on HTTP 5xx errors because as "Internal" http errors those are on you always.
In other words, of course you don't alert on errors which are likely somebody else's problem. You put them in the log stream where that makes sense and can be treated accordingly.
The frequency is important and so is the answer to "could we have done something different ourselves to make the request work". For example in credit card processing, if the remote network declines, then at first it seems like not your problem. But then it turns out for many BINs there are multiple choices for processing and you could add dynamic routing when one back end starts declining more than normal. Not a 5xx and not a fault in your process, but a chance to make your customer experience better.
From both the developer and manager side of things, I've found that the most important attribute of estimates is frequently the least paid attention to: that they be kept up to date.
When you discover more work hidden under that "simple" pile of code, you absolutely HAVE to update your estimate. Add more points, add more tickets, whatever. But then your various managers have the ammunition to decide what to do next - allocate more resources to the project, descope the project, push back the release date, etc.
Far too frequently, the estimate is set in stone at the start of the project and used as a deadline that is blown past, with everyone going into crisis mode at that point. The earlier the estimate is updated, the calmer and more comprehensive action everyone responsible can take.
Which if you try to do - those agile people will kill you for it.
They wrangle a number out of you which goes into an user story estimate, which feeds into a Gantt chart they use to make their pretty powerpoints they present to upper management to say that the feature will make it into the Q4 release.
If you move this number around the whole estimation will crumble, not that it wont in real life but you deprave them of two things - an illusion of control and somebody to blame when things go south.
> Which if you try to do - those agile people will kill you for it.
Does this actually happen to you? This is literally the whole point of agile, is to change the plan as you learn more about your work. If you didn't want to change the plan you'd spend a lot of time on up-front planning and do waterfall.
Like, a Gantt chart is more or less explicitly anti-agile. I'm aware of the 'no true Scotsman' thing but we shouldn't buy into people using agile terms for what is really a BDUF-based plan.
Yes and millions of other devs who work in an enterprise 'agile' environment - where a single huge project is/was developed by armies of developers work on a single product with a strict-ish release cadence?
Have you heard about the horror that is SaFe?
I'm not convinced that true agile works or has ever worked on a project that was bigger than a dozen devs.
In practice, it's just another dishonest way of selling consulting hours, infantilizing and disempowering devs, and putting folks who have zero subject matter knowledge in charge by doing these feelgood rituals.
Agile (scrum) in practice at enterprise-scale projects tends to be a combination of feelgood BS +top-down micromanagement (product owners dicking around with task priorities) +traditional project management.
One of the key ways these agile people are incredibly dishonest, is that Agile at the top level is sold to enterprises as a way of keeping the old high-level project management style, with push-only command-structures, and agile people subsequently try to sugarcoat it as it somehow 'empowering' the devs and giving them autonomy, when the truth couldn't be farther from it.
Yes, and I successfully argued against it by pointing it was was a wolf in sheep's clothing. It has as much to do with agile as waterfall does.
> I'm not convinced that true agile works or has ever worked on a project that was bigger than a dozen devs.
It works fine, large projects are inherently trouble which is why organizations should spend some energy into reducing the scale of an individual team's work rather than piling dozens or hundreds of people into yet another Too Big to Fail megaproject. If Google can build and maintain Bigtable with like a dozen devs then maybe you don't need 200 people and a PMO for your enterprise data warehouse consolidation project.
In fact the biggest issue with SAFe is the size of the project you'd try to use it on, not that it references agile style methods. Waterfall methods were even worse, which is the only reason charlatan consultation manage to keep selling organizations on things like SAFe.
> One of the key ways these agile people are incredibly dishonest, is that Agile at the top level is sold to enterprises as a way of keeping the old high-level project management style, with push-only command-structures, and agile people subsequently try to sugarcoat it as it somehow 'empowering' the devs and giving them autonomy, when the truth couldn't be farther from it.
You're right that this is dishonest and that people try and fail to cargo cult successful efforts they watch from afar. But that doesn't mean these successful teams weren't successful, or that there aren't common attributes of those successes.
That's always been the problem with methodological fixes to the software delivery process for organizations, you usually can't impose the structure from the outside anymore than you can meld your bones with adamantium without having a crazy mutant healing factor...
Yes, but the comment is targeting those people that usually would say about themselves that they embrace agile, while actually fighting everything that changes their little schemes...
So should we be talking about how "those democratic people" put everyone who disagrees with them in concentration camps because that's what the Democratic People's Republic of Korea does?
There are, of course, extreme-right-wing reactionaries who make exactly that argument, but I don't think their example is a good one to follow.
I have noticed the same for a lot of long-running software projects. The estimate is created at the start an never revised.
Projects can and will fail or run late; but heck; a 6-months projects cannot found late after 5 months and 29 days; things must be discovered early, so that the most important issues can be addressed.
> But then your various managers have the ammunition to decide what to do next - allocate more resources to the project, descope the project, push back the release date, etc.
In your view, is this a good thing or a bad thing for developers? In other words, are developers incentivized to update their tickets because it gives their managers "ammunition" to make project changes?
I find that this is usually more evidence of organizational dysfunction.
Sometimes, its developers who don't have enough ownership - someone higher-ranking filled out all the tickets for them and left no room for interpretation, so changes require trashing a bunch of irrelevant tickets and writing a bunch of new ones, making for more communication overhead and less time spent in development. Developers are disincentivized to update tickets since doing so just becomes write-amplification for more bureaucratic overhead.
Sometimes, it's a communication breakdown. Tools like Jira are necessarily asynchronous, and decisions about what to build are necessarily political. Politics and asynchronicity don't mix, such discussions need to be held face-to-face. If they're held face-to-face, then having developers update Jira is pure overhead. Developers are disincentivized from updating Jira because either it's a one-sided conversation (lag in getting notified that your ticket was closed and the work on it should be thrown out, PMs don't always follow through with issue links from the closed issue to the newly opened issues, so developers lack context on what decisions were made on replacements), which is emotionally draining, or the conversation happens outside of Jira, in which case updating the ticket is a formality/not actual communication, in which case it feels like a waste of time.
For most development work, I'd argue that developers shouldn't be making changes in Jira, their managers should be, on the basis of frequent, synchronous communication with the developers they manage.
Exactly. And I’ve found this is incredibly hard to get people to do, developers especially. No one wants to say a task is going over / taking longer than expected but will gladly run over. It’s hard for pms to resource if estimates are not updated as scope and complexity changes.
Also doesn’t help when estimates become due dates.
This is why stuff like Jira is so polarizing for many developers. It is an additional translation tax on me, the developer, to have to go constantly keep this tracking tool thing up to date so that the product owners/managers stay off my nuts. The burden of effort is placed on me to make their tool functional that they can have what they need to provide roll up status. This tool virtually never benefits me, it's always a time consuming sidequest that breaks focus and scatters important information all over a kanban board where tickets disappear and makes it really hard to cohesively work as a unit to get anything done. Like many orgs we've had PM's and stuff try to mandate expectations on when those updates should be provided, somehow completely oblivious to the human nature of development: you should never expect that a developer can simply hop in and out of moments of deep focus and suddenly provide a bunch of updates regularly when it's convenient for you, as if that has zero impact on their work. It takes a toll, full stop. I won't say no to it, but I do expect PM's to know that style of PM'ing is effectively asking me to make your job easier by populating your tool with updates that are useful to you and not me because I'm well aware you aren't involved enough to assess where things are yourself.
We've gone through so many cycles of how to use Jira well at my org where these frustrations are shared and we try a different approach, and we're finally starting to converge on the idea that this has historically been a little too lopsided requiring too much tax on the developer doing the actual work. We agreed on a new approach that has actually been pretty awesome: the product owners or managers that are trying to direct a body of work must be a little more in the trenches with us to have an overall understanding of where the different pieces are in a moving body of work. We don't expect them to understand the nitty gritty work in the trenches, but at the same time no more 30,000 foot view product managers who just ask for status updates at EOD. _Everyone_, developers included, is responsible for keeping documentation up to date as we go. So we have central working-bodies of information to find details without having to cruise thru 100+ jira tickets to find details we're looking for. The expectation is that they're engaged enough with development whether in chat or on meetings that if they were blindsided by an executive asking for an update, they could speak to it with some authority over at the water cooler without having to go check Jira. This has really helped weed out the lazy product owners/managers, has forced them to thoughtfully consider their meeting schedules, and has placed the exceptional ones in the pod of work being done and really added a lot of velocity and together-ness about the things we're pushing along.
This approach we're using now was born out of some hurt feelings from projects that didn't go so well & we had to have some real restrospective convos where everyone aired out their beef. Those are good convos to have, I think a lot of teams would find that people aren't deceptively trying to screw you over. Being encouraged to level set human-to-human genuinely is one of the greatest parts of working where I work. Always walk away from those types of chats learning valuable things: for the most part our product owners really do care. Not just about their career aspirations but also about _us_ nerdy and sometimes socially maladjusted developers. They look forward to working with us, and they want to make this as easy as possible for themselves but also for the developers. In the past they spent a lot of time in planning phases trying to scaffold out a project in Jira and attaching timelines to it so that their needs are met to provide predictable timelines to their bosses... but also with the hope that by plainly outlining work it sort of 2 in 1 satisfies our needs and will make development timelines a breeze. We've had to ask them to cede rigidity on that latter part because even the software architects admit the work being done is often a moving target. And when that target moves, maybe you realized you need to add a pivotal software solution to the stack, you can sometimes throw like 45 planned tickets into the dumpster. New ship dates need to be assessed. This was our reality check that we were all collectively shit at adapting to the dynamic nature of any given project. Now, our product owners decided that the expectation they have of their own role is that they understand this dynamic and are prepared and willing to make the case about why the shipping timeline must change. So there's actually a pain point solved here: don't break your back doing so much up front work to try and guess/capture what the body of work might look like only for it all to possibly get thrown away, involve architecture a bit more in the planning phases, but most importantly let's engage throughout the project and we'll try our best to have shared ownership/interest in making sure where we are in the project is broadly understood by everyone involved.
We're currently in phases of implementing a major platform right now and it's just night and day better and dare I say fun. We're still keeping Jira up to date, but the product owners and PMs are more or less managing this as it is a tool they find useful. Removing the "can you update this ticket please" 24/7 has forced them to be a little more involved and have the right chats, but also makes us developers happier to jump in and get it updated on our own volition because we also want to help them have an easier time. If my PM pings me and says "hey I'm looking at this ticket that's stuck in blocked, I just wanted to make sure we got an update from so-and-so about provisioning this credential so I can follow up if needed" I will likely automagically jump in and be like "still stuck, but let me update that ticket for you there's a couple key details I want to make sure our there for you before you reach out". There's an inherent "we're both interested in seeing this ticket through" here that doesn't strike a nerve with either party. Pretty much everyone involved both developers & non developers has a really solid read on where anything's at and we're all just talking a lot more. And for developers I find that it's really good, even if you've got them committed in one narrow body of work, to understand the larger pieces in motion. When they're in tune with the broader orchestration of a projects timeline, they tend to weigh in during unsuspecting moments that might tie seemingly unrelated pieces together. They might be assigned to work on x, but in a group chat about y they notice y has a dependency on x and they'll speak up and call out the need to test that they both work together. We've had a lot of great callouts materialize like this, and on a human-psyche level I think it snowballs & avalanches encouraging developer participation in a way that is really meaningful for PMs. It's interesting that Jira & the expectation that predicting development time in an arena of uncertainty was previously in the way of forming the group dynamics we have now. Jira, despite just being a tool, can really amplify a lot of bad outcomes when it's used by those who aren't fit to be near development, it sort of devolves into a two dimensional behind-schedule tracker that detrimentally impacts how team members on the ground communicate with each other.
And since we're talking a lot more there's just like... way more memes. And memes are important in any development timeline. We prioritize laughing through the pain together.
This is a fantastic description of why Technical Program Managers (TPMs) can be force multipliers. Imagine involving someone who understands both the needs of Product and Engineering and whose job it is to allow both of them to focus on where they add the most value. We do exist!
It is very much this, your types are insanely valuable to how quickly and effectively we can blast through massive bodies of work that are well beyond the scale of personal-hobby-project. We're in the annoying HR-involved process of revising the role internally to actually include the word 'Technical _' & the bullet points of expectations will demand such capacities. It's been an exciting shift for us and we've reappropriated non-technical product owners/managers to roles they are happier in (and believe it or not we are happy for them).
We didn't get it right the first, second, third, fourth or fifth time. I'd say as an org we are learning lessons that other orgs may have learned a decade ago, but it's just nice to come to these conclusions on our own & really understand how our setup came to be. We hope we remember that things can evolve again in the future, but are grateful that we journeyed together and didn't just throw in the towel and fire people when things didn't work out. We believe sending people through some fires of hell, reassessing, then reattempting is sort of a cycle that levels people up.
We hope to have more technical product guys on board up ahead cause it's a dream setup that really organizes and harnesses velocity in all the right places, but also effectively stops unnecessary side-quests. It's so nice to have a technical product guy step in and say "no" to some absurd executive request because he/she is well aware of what such an implementation would look like. They can actually be vanguards and stewards over development personnel in their own way and it seems to go hand in hand with a lot of mutual respect for each other. Always get a kick out of nerding out over possibilities with our technical product dudes.
Multiblocks power fail and void, but then your machine shuts down until you restart it. This is much better than suggested above, where you'd void over and over, but it can still utterly mess up a large craft being orchestrated thru AE2, which is still waiting forever for he failed craft to submit a part back into the system.
Yeah people talk about GT:NH being this super tedious hard pack, but it actually has tons and tons of quality of life fixes to the various mods that make it up - and voiding materials is something that is almost nearly gone (iirc very early on a single block, even steam, losing power would lose the materials, which made learning early steam (especially the alloy smelter) really painful).
GT:NH is a very interesting software project in itself, a long-living open source environment with devs maintaining forks of a lot of mods included in the pack and backporting features and fixes to 1.7.10, custom tools for development/planning and a lot of spreadsheets with data
There are more situations than just "a 55mph head-on crash" that need to be considered. What about getting clipped at 5mph when the driver is turning, and on a Cybertruck you've now got a brutal gash dug into you. And a camera that covers a full 360 isn't really all that useful when you're making a normal turn and not looking at the camera, but have your normal vision heavily obscured by the massive frame.
It's not perfectly safe. If it were, it would be legal everywhere and it's not.
Absolutely this. I was so excited for a second that they were re-branding and re-launching the mini. My 13 is getting long in the teeth, and won't be supported for OS updates in a few more years.
> we could probably agree that human intelligence is Turing-complete (with a slightly sloppy use of terms).
> So any other Turing-complete model can emulate it
You're going off the rails IMMEDIATELY in your logic.
Sure, one Turing-complete computer language can have its logic "emulated" by another, fine. But human intelligence is not a computer language -- you're mixing up the terms "Turing complete" and "Turing test".
It's like mixing up the terms "Strawberry jam" and "traffic jam" and then going on to talk about how cars taste on toast. It's nonsensical.
Game of life, PowerPoint, and a bunch of non-PL stuff are all Turing-complete. I don't mix up terms, I did use a slightly sloppy terminology but it is the correct concept - and my point is that we don't know of a computational model that can't be expressed by a Turing-machine, humans are a physical "machine", ergo we must also fall into that category.
Give my comment another read, but it was quite understandable from context. (Also, you may want to give a read to the Turing paper because being executable by a person as well was an important concept within)
Again, you're going wildly off the rails in your logic. Sure, "executable by a human" is part of the definition for Turing machines, but that's only talking about Turing-specific capabilities. If you want to argue that a Turing machine can emulate the specific definition of Turing machine capabilities that humans can perform, that's fine. But you're saying that because humans can ACT LIKE Turing machines, they must BE Turing machines, and are therefore emulatable.
This is the equivalent of saying "I have set up a complex mechanical computer powered by water that is Turing complete. Since any Turing complete system can emulate another one, it means that any other Turing complete system can also make things wet and irrigate farms.
Human intelligence is not understood. It can be made to do Turing complete things, but you can't invert that and say that because you've read the paper on Turing completeness, you now understand human intelligence.
That's not a computation, it's a side effect. It just depends on what you wire your "computer" up to. A Turing machine in itself is just a (potentially non-returning) mathematical function, but you are free to map any input/output to it.
Actually, the way LLMs are extended with tools is a pretty much the same (an LLM itself has no access to the internet, but if it returns some specific symbols, the external "glue" will do a search and then the LLM is free to use the results)
You can build this today exactly as efficiently as you can when inference is 1000x faster, because the only things you can build with this is things that absolutely don't matter. The first bored high schooler who realizes that there's an LLM between them and the database is going to WRECK you.
It’s actually extremely motivating to consider what LLM or similar AI agent could do for us if we were to free our minds from 2 decades of SaaS brainrot.
What if we ran AI locally and used it to actually do labor-intensive things with computers that make money rather than assuming everything were web-connected, paywalled, rate-limited, authenticated, tracked, and resold?
There's no context in those names to help you understand them, you have to look at the code surrounding it. And even the most well-intentioned, small loops with obvious context right next to it can over time grow and add additional index counters until your obvious little index counter is utterly opaque without reading a dozen extra lines to understand it.
(And i and j? Which look so similar at a glance? Never. Never!)
reply