foz

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.

yes this seems a strange choice. The operator is clearly controlling it from the side with the small screen.

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.

Robert Elder give a detailed story about his experience at Amazon as an intern, the management interactions and the culture he felt there

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.

A user with access to a mac could enable the option to automatically install macOS updates, which given recent trends, could impose a security risk.

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.

"Managing Humans" by Michael Lopp made a huge impression on me and my career. https://www.amazon.com/Managing-Humans-Humorous-Software-Eng...

Also, "The Phoenix Project" which IMO is a groundbreaking work on how to make IT/business more effective (and the start of the DevOps movement). https://www.amazon.com/Phoenix-Project-DevOps-Helping-Busine...

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.

In case you would rather watch the talk than read the PDF: https://www.youtube.com/watch?v=0H6jd5yG7_A&list=PLH15HpR5qR...

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.

I think it's a myth that experienced engineers can write code that's more flexible and reusable. I've met plenty of experienced developers who believe they can architect a framework or library that everyone else can just build on. And they instead create big legacy software that breeds pain.

I would counter that a senior engineer is proud of his team, who knows the best practices to ship stable, working solutions. And they are not afraid to throw code away when it ages, because they have the confidence and the team to quickly build something new, that's maintainable and reliable.

I believe that copy and paste is needed in login forms, as a UX expectation. Typing a secure random password is really painfully hard, especially on mobile.

Sometimes password managers don't recognize the target form fields correctly, so copy/paste is the next step. The act is even encouraged through the use of convenient helper buttons in the password managers.

However. In MacOs Sierra, Apple will introduce the Universal Clipboard feature. This means when someone copies a password on desktop, it would be available on their phone. Which is just one step away from being pasted, by mistake, into an IM chat or worse.

I'm uncomfortable with the idea that when I copy something it's being sent around to different devices, and available to everything running.

I've actually made the terrible mistake of doing that - pasting a password into a group chat my accident, because I didn't copy text correctly, and my last paste buffer was still around. Or messing up when using pbcopy/pbpaste in a shell script.

1Password for instance can actually reset the copy/paste buffer after some time, but the settings need to be enabled. I wonder if Apple has any kind of security around this planned. Maybe applications and scripts should not be able to access the paste buffer until the user explicitly allows it (via the act of using it)?

The traditional RFP process is tedious and costly, in terms of time and communication. I was a contractor for years, and often found that after several days effort to craft a good RFP, only the last page (the price and timeframe) were relevant and discussed. For the last several years I have been on the other side, creating RFPs and evaluating responses from potential vendors. Writing RFPs well takes a ton of effort, and organizing the responses, which are all completely different, is a challenge.

I think this methodology could help. It's simpler for everyone involved, and can get the hard part out of the way sooner, so details and creative ideas can be discussed with a smaller group of vendors. I'll definitely give this process a try on my next RFP round.

The problem with high estimates, if accepted by the stakeholders, is the risk of over-engineering. When given lots of time, development teams often will find ways to use that time which don't add to the value of the features being delivered: over-testing, making things "re-usable", a chance to try something new. And the project is late anyway.

Maybe optimistic estimates are a motivating factor for teams. The desire to finish faster, to be more efficient than you were before, a commitment with a challenge.

In my experience, it takes a strong product owner and a mature development team to meet deadlines. Shipping on-time is always a game of tradeoffs. Accuracy in estimates is usually the result of doing things in a known, measurable way. And by keeping the stakeholders close, you can make critical decisions together to keep a project on track.

As a developer, I have spent years writing and learning to parse the meaning of sequences like ==, ===, <=, ~=, and so on. For nearly all of us, the ligatures in this font are completely new. I think it's a creative and interesting idea, but it means re-training my brain to recognize them, which would take time.

And even if I could get my preferred editors to work with it, I would see the traditional symbols when reading code on the web, or pairing with another developer who does not use the font. It seems like a barrier to understanding, something that by nature developers strive to eliminate.

I'm torn. This idea could be something that changes how we all express code symbolically, or it will just become a fad that a tiny percentage of developers will insist on using, to the frustration of everyone else.

We remember the songs and TV shows because we listen and watch them, repeat them in our heads, talk about them with friends. We dont do that with passphrases.

Just continue to use a password manager, and save the poems for your master password, your ssh key, your unix account, etc. Only then do you need to recall on demand.

This is a situation that happens all the time in teams developing code together. The first developer creates the abstraction, and the second developer feels the need to continue with it, and to refactor, despite the fact that it;s not really working. What Sandi does not talk about here is team dynamics, and communications. This is really a root cause of the problem.

The barrier for for the second programmer is cost of communication. It is far easier to continue a bad abstraction than to engage in discussion and perhaps arguments about the code the first programmer wrote. Her suggestion, to revert the abstraction and go back to duplication, will most certainly result in a long thread in the code review, or even a heated discussion between the two programmers. That's OK, but it assumes the team can handle this situation gracefully.

When a programmer spends time to come up with an abstraction, it often takes a lot of mental effort. The resulting code is something that the first programmer feels made everything better. They removed duplication, and they are proud of the new shiny abstraction. Simply reverting it is a big message that says "that was a bad idea", and is sure to bruise egos.

Perhaps the problem of wrong abstractions can be avoided in the first place when a team has a strong code review culture, and when developers pair more. In these teams, code ownership and shared responsibility lead to a lower barrier for making changes to abstractions, which are generally held on to more strongly.

In my experience, a codebase that suffers from wrong abstractions (and over-engineering in general) is also a sign that the team is not working well together. Typically one or more programmers are committing code without discussing it, due to bad team dynamics, physical distance, different POV on the project goals, or unhealthy "rockstar" mentalities.

This was the paper I loved for drawing Dungeons and Dragons maps in the late 70s. I loved how a #2 pencil looked on the faded blue grid. The paper has a distinctive smell, it's just delicious.

Thanks for the tip, I love rail magazines. In Switzerland, I subscribe to Railway Update [0] which is produced every two months and covers Swiss rails news as well as Europe and Asia (as related to European trains). They have great analysis of new planning, recent accidents, and deep tech discussions.

[0] http://www.minirex.ch/railway-update.aspx

As someone who has taught several beginners (non-programmers) Ruby, I would say the uptake is good. Teaching at events like RailsGirls, I've had complete beginners start to "get it" and deploy their own websites using Rails and Heroku within a day.

My personal experience has been that it makes a great first language, It's very natural to write, and easy to type. You start with super-short examples that are easily understood, using a bare-bones editor. Explaining blocks and iterators is a challenge of course.

There's quite a lot of approachable and creative content about learning Ruby out there, which makes it helpful for beginners looking to self-study. Books like "Hello Ruby" are great for kids starting from zero, who need more motivation and fun compared to the "For Dummies" or "From Scratch" approaches.

That being said, I agree with your feelings about the language as intended for beginners. However, I tried to teach my 9-year-old daughter Java (using an online course for making Minecraft Mods). And although she was able to get through it, Java is still perplexing. The IDE, strictness and verbosity were overwhelming. Similarly, I tried to teach my nephew Javascript (we made a game together) in a browser. Trying to explain `.this` and dealing with input handling was pretty hard to get through. He didn't take it much further.

Re: learning to code... I believe it's not so much about what language you choose to teach. It's about the quality of the course materials, and how quickly the concepts can be understood. Ruby has a lot going for it there.