We have post-its with file names on a wall in the office. You take one down if you edit the file, and put it back up when you're done. Easy.
Though I wish I was entirely kidding. ~12 years ago or so we did that if one of two parallel development teams had to modify a message of the network protocol to avoid incompatibilities and merge problems.
Mind you, these were SVN merges. I can't even verbalize my feelings about SVN merges but by a mixture of laughing and groaning in pain, like if you stubbed your toe in a painful, but entirely funny way.
What is this eternal meme about merges in svn being harder than in other tools? Git used literally the same merge algorithm, even if that has changed a bit since then, and merge conflicts are not something a tool can't just magically make disappear. If you want concurrent edits (the c in cvs), conflicts come in the same package. Various algortihms can supply their own dose of magic, but they're more similar than different (minus a few special cases such as rerere in git).
My interpretation within that company: You know this new idea of "If it's painful, do it more"? People in that company didn't do that in the SVN days or earlier, because merges were painful. Thus, merges filled a sprint if they had to be done. This made sense if you came from CSV or nothing, tbh.
Git in turn made branches easier, causing merges to be more prevalent and developers overall learned to merge more, merge more often.
That doesn't make any sense to me. Why would you merge more often if it takes less time to create a new branch?
What types of merges are we talking about? Surely it must be where you merge in changes from a main branch to your local branch, which in the case of long-lived branches will be the more common merge. Creating new branches isn't even part of that workflow.
Keeping it when tech can't keep up is genuinely a good hack for any kind of engineering. Physical lock out tag out on industrial machines for instance. Passing paper notes/wooden blocks in air traffic control towers to see who's responsible for what even if computers go down.
You joke, but when I was doing my start-up we made good money on the side from monitoring websites to detect when the designers had pushed regressions to the live site. We would keep track of change requests that were filed and resolved, then scripts would monitor the sites to see if any earlier changes had been backed out. (Getting the designers to use version control was considered to be in the "too hard" bucket. This was back in the mid 2000s.)
That's a single point of failure. If you email code changes around and use an email client that copies everything offline, then the history of your code base is distributed across all of your developers' laptops.
Yea this! How many devs say "it doesn't do what i expect" did not try to write up a plan of action before it just YOLO'd some new features? We have to learn to use this new tool, but how to do that is still changing all the time.
There's a huge caveat i don't see often, which is that it depends on your language for programming. IE. AI is reallllly good at writing Next.js/Typescript apps, but not so much Ruby on Rails. YMMV
I agree with this. People who are writing Python, Javascript, or Typescript tell me that they get great results. I've had good results using LLMs to flesh out complex SQL queries, but when I write Elixir code, what I get out of the LLM often doesn't even compile even when given function and type specs in the prompt. As the writer says, maybe I should be using an agent, but I'd rather understand the limits of the lower-level tools before adding other layers that I may not have access to.
My hunch is that to exploit LLMs one should lean on data driven code more. LLMs seem to have a very easy time to generate data literals. Then it's far less of an issue to write in a niche language.
Not familiar with Elixir but I assume it's really good at expressing data driven code, since it's functional and has pattern matching.
I think for some languages like Clojure and Elixir, it's just so easy to get to the level of abstraction you need to write your business logic that everyone does so. So the code does not have any commonalty with each other. Even when using the same framework/library.
But for Python, JS, etc,... it's the same down to earth abstraction that everyone is dealing with, like the same open a file, parse a csv, connect to the database patterns.
Everyone posting should be considerate of your language/stack. It's pretty likely that Cursor doesn't work equally for every language. I'm working on a Next.js/Typescript/Solidity monorepo with multiple apps and packages and it handles pretty much anything I throw at it. I know I can squeeze more out because I have only been really using it heavily for the past month or so.
And Typescript simply doesn't work for me. I have tried uninstalling extensions. It is always "Initializing". I reload windows, etc. It eventually might get there, I can't tell what's going on. At the moment, AI is not worth the trade-off of no Typescript support.
My entire company of 100+ engineers is using cursor on multiple large typescript repos with zero issues. Must be some kind of local setup issue on your end, it definitely works just fine. In fact I've seen consistently more useful / less junky results from using LLMs for code with typescript than any other language, particularly when cursor's "shadow workspace" option is enabled.
Have you tried using Cursor with Claude embedded? I can't go back to anything else, it's very nice having the AI embedded in the IDE and it just knows all the files i am working with. Cursor can use GPT-4o too if you want
