andreimackenzie

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.

I am getting an `alert(1)` when visiting this site. This smells like cross-site scripting. Beware.

I'm happy to read encouragement to consider the wider group of stakeholders in the scope of testing. In many organizations, incentives are out of alignment to find issues beyond the obvious user-facing correctness ones, so "testing theater" wins, because it allows teams to declare victory more quickly. Software as a discipline would benefit from more testing attention to security, accessibility, usability, etc.

Arriving at Penn Station has benefits if you're traveling for business. Hailing a ride to get to an office within 15 minutes beats the long ride to get downtown from one of the NYC airports.

Agreed. Jira makes it easy to add a new field, plugin, or workflow step for a particular use case, but it is much more difficult to determine if an existing field/plugin/workflow step can be safely removed. As a result, everyone is afraid to touch it, projects accumulate cruft over the years, and it degrades the entire workflow. The problem is especially bad if there is shared ownership of JIRA, and therefore everyone feels empowered to add, but nobody feels responsible for the dirty work to clean up the mess from time to time.

My company had resisted the urge to bolt on additions more than most. We recently migrated from Cloud to on-prem Server as a result of being acquired, and it is amazing how much zippier our project is compared to some of the peer projects that have accumulated cruft.

I completely agree that some types of changes are much more expensive with a bare metal architecture than with cloud.

6 years ago, I worked for a company in the mobile space. This was around the time of the Candy Crush boom, and our traffic and processing/storage needs doubled roughly every six months. Our primary data center was rented space co-located near our urban office. For a while, our sysadmins could simply drive over and rack more servers. We reached a point where our cages were full, and the data center was not willing rent us adjacent space. We were now looking at a very large project to stand up additional capacity elsewhere to augment what we had (with pretty serious implications on the architecture of the whole system beyond the hardware) or move the whole operation to a larger space.

This problem ended up hamstringing the business for many months, as many of our decisions were affected by concern about hitting the scale ceiling. We also devoted significant engineering/sysadmin resources to dealing with this problem instead of building new features to grow the business. If the company had chosen a cloud provider or even VPS, it would have been less critical to try to guess how much capacity we'd need a few years down the road to avoid the physical ceiling we dealt with.

It can help to establish rules such as "new DB migrations must always be compatible with old code" aka "migrations first". This gets everyone into the mindset that a db+code change must be carefully staged in a way that both (new DB, old code) and not just (new DB, new code) are tested. If the migration goes wrong due to different data in prod, it's easier to roll that back before new code is deployed.

I don't think this is the norm. My experience is at least as anecdotal, but most of my friends in tech seem to work pretty hard.