andreimackenzie

PayByPhone also shows ads in the parking experience (thankfully, not too obtrusively, and not until the parking is confirmed). So, they could be covering some of the cost that way.

Agreed; I look back in horror at how much I spent on delivery fees and tips in my 20s before I took control of this part of my life.

This struck me too, but I think it is intentionally a high limit to prevent problems like relatively low impact/high LoC tests from tipping a small change into a large one. That would encourage gamification like skipping useful scenarios to keep a change "small".

The other criteria are more important.

Something that made MVC, dependency injection, and ORMs more palatable is that there is typically a well-structured interface between "our code" and "their code". The current state of agentic dev rarely has AI doing its thing behind some abstraction layer. It's really more like a new coworker that needs to be steered toward team norms very quickly.

I think the main challenge is pressure for more productivity with AI. I often go back and forth about if I am scrutinizing too much (and not being as productive as I could be) or not enough (and shipping slop). Building the additional QA harnesses and feedback loops for agents seems like the best known path forward to accelerate with some safety, but it is still pretty challenging to context-fiy all of the nuanced judgements a seasoned dev team makes.

Agree with you on model quality, but Anthropic has done a nice job developing stickiness. The connector ecosystem, integrations with desktop apps, browser use, etc. are all pretty compelling for a typical business use scenario. It's expensive, but also a "safe choice" akin to buying IBM or Microsoft back in the day. My workplace (not just developers) is deeply invested in the Claude ecosystem & it would be pretty disruptive to pivot it.

This will shorten many test files!

This is spot on. Also, many orgs build to the needs of the business or whims of stakeholders rather than customer needs. Good product strategy and product discovery remain difficult despite AI.

Fair enough. I use plenty of disposable stuff in other contexts.

The habitual part is what makes a difference for me with my local coffee shop. I usually walk over around midday when I WFH, mostly to move around and re-energize for the second half of the day. Since I know I will be coming right home after, it is easy for me to adjust my ritual to include the cup.

My local Starbucks offers a 10 cents discount and extra loyalty points for bringing your own cup. I've started bringing an insulated one that keeps coffee hot for longer & doesn't sweat with an iced beverage. I seldom see others bringing their own cups, even regulars I see there every week, even when Starbucks themselves sell reusable cups. It is almost like there is a weird stigma about handing the barista something that doesn't come from behind the counter. I encourage trying it, especially if you visit the same coffee shop habitually like I do.

The Cambridge, MA location still has an aisle of keyboards and mice outside of their packaging. It's very nice to be able to hold and feel those peripherals as part of the shopping experience.

From my experience: re-orgs and limiting backfills for attrition can lead to these awkward states. Someone starts off with a sensible number of directs, but it can devolve over time.

> In limiting the number of bidders, Google inflated the prices for ad inventory.

This part doesn't make sense to me. Limiting bidders should drive the price down, because fewer advertisers are competing for the same potential ad impression. The article describes Google's influence as "Google controls the auction-style system," which is a bit more open-ended about the specific alleged practices.

I think it does because a researcher can pick up context about the quality of their sources through the course of web research. The BigCo chatbot AIs are marketed to represent that BigCo, and people generally trust Google, in this case. It's good when they cite sources, but a major point of the chatbot is to abstract that legwork for most people.

"Lack of obstacles" really resonates. If we're talking about software dev, it's fun to get into a flow state and solve problems. Whether you actually get to do that at a BigCo seems like a roll of the dice. For every team that seems happy & effective, there are two encumbered by lack of agency, bureaucracy, pointless meetings, etc. Most people who got into software dev will work hard when there is actually something to do that is fun and engaging.

Most people don't decide about their own medical "needs." They trust doctors, who are by and large expert and professional, yet frequently discredited by insurance companies.

Insurance companies have too much power in this dynamic, and there should be limits to what they can deny once doctors deem it needed.

I would be surprised if they don't already do this. The question is how big a buffer to trade off for delay...

A lot of BigCo people's (myself included) perception of Java is tainted by the challenges of old, inherited code bases. Java has been ubiquitous for a long time, and it's not surprising to accumulate code bases that have been underserved maintenance-wise over the years. Updating dependencies on a Java 8 codebase isn't much fun, especially because semvar wasn't widely followed back in those days.

Early-in-career folks are more vulnerable. Even before major family/life costs start to play a role, it can be difficult to save enough for a safety net after moving to an apartment (even w/ roommates) from college & managing student debt, etc. I remember it took me a couple of years of stability to not feel at risk.

I've observed that the quality of third-party SDKs for Microsoft office formats improved substantially. The .xls format was notoriously fickle to process or produce from outside of Excel. As of .xlsx, the open source community produced myriad SDKs in various languages, and the ones I have experience with worked quite well. The format becoming less arcane and better documented was important to enable this.

Assuming the query language for the graph DB you have in mind is declarative like SQL, I recommend templated queries. I have found this technique scales pretty well for query complexity, makes it relatively trivial to "get to the query" if something needs to be debugged in the details more easily outside of the app, and it makes performance-oriented optimization work far easier.

I've had my share of headaches with the various flavors of ORM and GraphQL and always come back to query templates, e.g. MyBatis in the JVM ecosystem or Go's template package. There is still value in abstracting this from the REST web service interface to make it possible to change the app<->database connection without disrupting REST clients. It's possible to reuse parameter structs/classes between the REST client and DB+template client layers to avoid a lot of rote translation. It seems simple and repetitive, but actually saves time compared to the GraphQL/ORM complexity as apps & query complexity scale, in my experience.

Simplicity is a feature. Sure, how complicated can effective enums really be, but Go's general philosophy is to think hard (& sometimes for a long time) before adding every bell and whistle.

I have a far easier time delving in to previously unknown Go code for the first time compared to something like Scala (or even Java). Go is a solid language for those who value that and want to enable the experience for others.

About 10 years ago we set up a pretty slick integration from our office wifi controller to Google's account directory using WebDAV and Radius. It allowed us to have a WAP for insiders who could authenticate with their Google-issued one-time-passwords (needed because normally a Google login requires MFA if configured) and access our internal network with their individual Google accounts (no sharing of wifi credentials; no separate wifi login to manage for offboarding).

It was certainly Less Secure by modern standards, but it saved a boatload of time for everyone to be right on our internal network as soon as they connected to wifi instead of having to VPN in.

Agree. The main benefit of environment variables is portability. They work pretty much the same way in every platform I have encountered. As soon as a system gets into files, it's possible to get bogged down in the complexity of Windows vs. Unix, file permissions, SELinux, etc. The simplicity is often worthwhile over the extra security theoretically possible with well-managed files.

Advertisers not spending as much

I wondered about this exact risk as I learned about the "overemployed" phenomenon. It feels like a matter of time before credit bureaus offer this as a service to the many corps that already pay them for credit checks. It's hard to be legitimately employed without a data trail these days.

I've really enjoyed Golang for this reason. The powers that be take a cautious approach before adding major new stuff, even when the community complains loudly about lack of important features (e.g. generics for many years until recently). Go code I've written years ago is easy to adapt to new versions and ways of doing things, even when I have to switch gears to others languages for months/years at a time. Go is predictable.

How estimation is marketed matters, too. Don't let your stakeholders think of it as an over-estimate. It's an estimate that considers the needs of the full software development lifecycle: automating tests, developing monitoring, refactoring to clean up old tech debt, etc.

These are real problems, but there can also be mitigations, particularly when it comes to people scaling. In many orgs, engineering teams are divided by feature mandate, and management calls it good-enough. In the beginning, the teams are empowered and feel productive by their focused mandates - it feels good to focus on your own work and largely ignore other teams. Before long, the Tragedy of the Commons effect develops.

I've had better success when feature-focused teams have tech-domain-focused "guilds" overlaid. Guilds aren't teams per-se, but they provide a level of coordination, and more importantly, permanency to communication among technical stakeholders. Teams don't make important decisions within their own bubble, and everything notable is written down. It's important for management to be bought in and value participation in these non-team activities when it comes to career advancement (not just pushing features).

In the end, you pick your poison, but I have certainly felt more empowered and productive in an org where there was effective collaboration on a smaller set of shared applications than the typical application soup that develops with full team ownership.

Once ancient content no longer produces enough ad revenue for the companies storing it, I suspect they will support it only in paid tiers for users who really want it. Something like this is already happening in Google's paid tiers: each user is valuable as part of Google's advertising audience, but the economics no longer make sense once those users keep many GB on Google's servers.

Honest and collaborative companies will be as open as they can about their cash burn rate and prospects for more funding. If this aspect of the business is not done well, it can have pretty sudden and unpleasant consequences for the folks doing the work on the front lines. As a dev, you might feel like you are building a something awesome one month, and the company suddenly has no cash left to pay anyone the next.

My experience in the US is that companies can cut it pretty close between funding rounds - just a few months, and those moments can be nerve-wracking if you like what you're doing.