This is part of the reason I don't like to use it. I feel it's hiding things from me, compared to other models that very clearly share what they are thinking.
I love these. The https://www.youtube.com/@EvilmonkeyzDesignz channel does some wonderful explorations of chips with high powered microscopes, finding easter eggs and graphics left by designers. So much fun.
I think this core business model question is happening at all levels in these companies. Each time the model goes in the wrong direction, and I stop it - or I need to go back and reset context and try again - I get charged. The thing is, this is actually a useful and productive way to work sometimes. Like when pairing with another developer, you need to be able to interrupt each other, or even try something and fail.
I don't mind paying per-request, but I can't help but think the daily API revenue graph at Cursor is going up whenever they have released a change that trips up development and forces users to intervene or retry things. And of course that's balanced by churn if users get frustrated and stop or leave. But no product team wants to have that situation.
In the end I think developers will want to pay a fair and predictable price for a product that does a good job most of the time. I don't personally care about switching models, I tend to gravitate towards the one that works best for me. Eventually, I think most coding models will soon be good at most things and the prices will go down. Where will that leave the tool vendors?
really nice! do you support onion-skinning for building smoother animations? Motion paths would be cool too. Ok enough ideas, it's a great project already!
After using Cursor and Copilot for some time, I long for a tool that works like a "real" collaborator. We share a spec and make comments, resolve them. We file issues and pull requests and approve them. We use tests and specs to lock down our decisions. We keep a backlog up to date, maintain our user docs, discuss what assumptions we have to validate still, and write down our decisions.
Like with any coworker - when ideas get real, get out of chat and start using our tools and process to get stuff done.
This seems like an item that business would buy in bulk. $180 for single dev version, $90 each in packs of 10. Customized with your company branding maybe.
A very nice writeup and intro into USB, although - it's very focused on using an ST microcontroller, which is a lot more steps and toolchains compared the the recent ESP32 ecosystem that offers a number of easy plug-and-play ways to make USB devices work (for example, several projects from Adafruit's learning pages provide basic use cases). Another issue is differential pairs - having designed several working USB boards myself, this has not a concern for beginners, mainly relevant for doing high-speed work. USB controller ICs (as used typically with arduio/esp) can handle a lot of the details for you, so doing the calculations seems overkill, especially for someone making their first gadget.
One of the key functions of procurement: Checking for automatic renewal clauses in contracts and removing them when found. This is a red flag in many companies.
If you're going to go through the trouble of placing a microphone under someone's table or keyboard, you mind as well just install a keylogger. It would be much more likely to succeed given the risk.
Having actions on the right is more natural - this is reinforced by the UX of mobile devices we all use every day. Tap and we flow forward, to go backwards, we go left.
Like spoken languages, the language of design changes over time, and what used to be normal can be quickly outdated (like the reset button on forms).
I would guess that this statistic is about using the voice button on the keyboard, rather then commanding Siri "send a message to...". I've watched people that do this constantly, and perhaps they send more messages overall as a result of the behavior.
1) You ship stuff often. Programming isn't useful unless someone besides you benefits.
2) The code you put into production is stable and doesn't require a lot of operational work (bugs)
3) Other people can understand your code easily and modify it when needed, without requiring long explanations from you
4) You can work with other programmers and use best practices they recognize, and you are also good at teaching these things
This article resonated with me. We are going through a large platform re-launch, and using Kafka and events as a big part of the architecture. After much discussion, we decided against storing events, eventual consistency, or CQRS and so on. Instead, we use events to simply de-couple services. We have strong domain APIs and workers that respond to creates/updates/deletes. We use Kafka to partition things where it makes sense. Just stop there, and there's a ton of benefit. Things get simpler to reason about, easier to test, and result in less dependencies between teams.
Even if you're not a manager, both books are very approachable and packed with great lessons about how improve and better work with people, teams, and business.
It's hard to name one skill, but I'd put these into a single topic: the "soft skills" for becoming a more effective senior engineer.
Learning how to pair program effectively, and pass along skills to others. Performing great presentations and demos, and writing about your work. Being able to avoid complexity by finding simpler solutions. Separating yourself from your code and being open to criticism. Studying how goals, objectives and tactics relate to actionable tasks a software team needs to execute on. Becoming better a time management and prioritization, and delivering value faster.
None of these are very technical skills, but they require a lot of practice and a ton of patience.
I've run across this situation many times (I'm a "senior" team lead, meaning, I've been working for 25+ years). I've witnessed companies that overcame tech debt, and seen companies fail because of it. There's basically three approaches that people can take.
One is the "big re-write". They start on a new code base, and try to develop it in parallel. It takes a very long time, and the teams have to work on two solutions for some time. It's a big bang approach, and it often fails, or drags on for years.
The second is massive refactoring. It requires intensive testing and best practices. This strategy requires that the teams focus on testing intensely. However, often the testing culture is not there, which is why the code became unmanageable in the first place. It's kind of like starting over. And the new focus and discipline on testing is hard for teams to do without strong leadership, training, or new talent.
The last, and most effective in my opinion, is to go with a service-based, incremental approach. If the code base is not already using services, APIs must be built. Frontend/apps must be de-coupled from the legacy components. A clear domain model has to be agreed upon, and then parts of the legacy codebase are put behind APIs, and de-coupled from the rest. Over time, sections are refactored independently, and the APIs can hide legacy away. Maybe the legacy parts are refactored and replaced, or they stay around for a while. But the key is, that this approach allows multiple people or teams to work in parallel and focus on their areas. This is domain-driven design in action, and it works. New features can actually be developed sooner, even though the legacy is not replaced yet.
In the end, overcoming tech debt is about people. And on larger code bases, it's more of an organizational problem than a code problem. Developers need to be able to move forward without having to navigate too much code or too many different people.