mr_tristan

I'm more concerned AI will spew garbage we end up getting stuck spending time cleaning then actually replace me.

The software developer trades in abstractions, fundamentally, and not code. So if I could get an AI that actually helped me build and evaluate those abstractions, that would be fantastic. I don't think our current AI approaches are anywhere close yet, because it's all just fancy code generation, which isn't that useful, once you're in an ecosystem with good abstractions.

But, the world I fear might happen are pseudo-technical managers using AI generators to spit out "something cool" that has very poor definition, breaks all the time, and then just wants people to "make it robust". And then any change you recommend has to have some kind of business justification. This is the AI hellscape I fear.

The cloud era seems to exacerbate these kinds of issues. The only way to truly have "long term" service is to be a subscriber, not a "buy once" customer. If you're a part of their revenue next year, they're going to try to keep you. Otherwise, you're just one excuse away from being dropped.

The "right to repair" laws being developed might help here, but I don't know what this means for anything "connected to a service". If the service goes down, are there laws that say we need to be able to connected to something else? I'm not aware of much.

I mean, as an Arlo customer, I knew this was coming, but that's because I've worked in tech for over 20 years, and know none of these companies can operate a plan that looks ahead more than 2 years.

Ultimately technology is either subscribed, or "rented" for an undefined period of time. It's never "bought". It's gonna take some serious regulation to make that happen, and I'm not even sure how that will work.

Yeah, I've noticed more applications just need to focus on making sense of raw information really quickly, but usually don't need an archive to make decisions.

There are lots of interesting things that can happen with "big streaming" than necessarily "big data". Like, cybersecurity is evolving to monitoring and reacting what everyone's machine is doing in the last 15 minutes, instead of having a huge database of hashes you trust. But not a ton of things really utilize what happened, say, 10 years ago on people's machines.

There's definitely some things that can use massive archives of old data, but I have found far, far fewer things that would benefit from it, and often that comes with some very big maintenance hassles. Most of the time, you can just set data retention to 30 days and be done.

Not an employer, but work at a pretty big company where the CEO made a pretty big tell: he mentioned that remote work seemed to cause a loss in overall productivity. But then almost all engineers chafed, and he had to clarify: we was talking specifically about the sales organization.

My sense is that leadership making these decisions simply isn't really tuned into how engineering operates. And that's mostly it; they're focused on the business, and probably are dialed into the sales pipeline. And that probably leads to tons of questions and one-off-style clarification sessions where video chats and Slack just aren't great, to be frank.

At the same time, I do think there are significant tradeoffs between a remote team and a "shared meatspace" team. With remote teams, cross-team relationship building is really challenging, and I've noticed that there's a natural tendency to focus purely on your team. With all teams in a same physical location, it's easier to actually just pop by and clarify complex details. But, I did work at a place that got hundreds of engineers together about 3x a year, and that seemed to be enough to build significant bridges across the org.

Ultimately though, in my experience, these kinds of decisions are just because upper management is more aligned with sales organizations than engineering.

So, it's great the author has recognized they are unhappy, but "heading to the mountains because I had good experiences there" seems like terrible decision making.

The "happiness trifecta" still seems to be a sense of purpose, autonomy, and expertise. Money just helps remove stressors.

I'd like to see more stories of people working to open a path in a system where it didn't exist before. Like, "how I carved out a new position at this huge company that gave be a better sense of why I do what I do". Everyone tends to think they need to go to a small place to have a big impact, but I think you can bend the world wherever you are a bit if you know how to define the targets, and get there slowly, one day at a time.

Big career changes are sometimes worth it, though I wouldn't follow this guy's lead. I found this experience from a woodworker who left architecture much more interesting: https://www.youtube.com/watch?v=MQoqGPnRLbU

This seems rather extreme, and likely to cause a lot of backlash due to how disruptive calendar manipulation is.

At my company, we have started "async weeks", where, basically once a quarter, we try to basically use async communication instead of recurring meetings.

First, this is executed without a lot of shock. You know it's coming and plan around it. But two, it does help promote writing - teams experiment with doing one or two things differently. It's a slow roll, but I'm seeing a bit more adoption of written tools, like doing reviews in Google docs instead of just reading them, etc.

Importantly, the lame "status update" meetings have become much more tighter and focused. We used to pack things into these generic one hour sessions, and now more meetings are starting to have better focused agendas, people get used to saying "you know, maybe only two of us need to discuss this...", etc.

Taking a week 2-3x a year to iterate and experiment with process changes like this feels pretty useful. Teams _should_ be doing this frequently if they're "agile", but I've rarely seen that actually pan out in reality. But it's a lot easier to take than the CEO surprising everyone electronically the first week back after a break.

I'm in that boat actually. It really just comes down to the people, like always. The teammates that meet together show respect for the remote folk, so it works. But I've definitely been at places that didn't really have that sensitivity for others, and it sucked.

We've got that channel, and many, many other "help" type of channels, like "help-who-do-i-talk-to" as well as "help" for many different teams, subjects, etc. They work pretty well, but, there's just a lot of communication, and I think the new grads and very young engineers get overwhelmed.

Ultimately, communication between thousands of people is just hard, and technology solutions aren't going to solve all problems perfectly. And again, I want to stress that in general, Slack has been a pretty nice tool. We still just need to do other practices to make sure nothings flying under the radar.

Technology is often very, very distracting, and everyone feels it. I've noticed that we've hit a point in my team where juniors don't even feel comfortable asking questions in a team channel, because they think it might add to the noise. It isn't just that they don't want to "look dumb", but they genuinely don't want to bother a senior engineer. So, paradoxically, the low-effort nature of Slack has actually created barriers to communication in this case. (I have no idea how common this is, but I suspect, at very big companies, there are similar dynamics.)

One solution I've found as a more senior engineer is to force a working session with a junior regularly. Like, we're not there to do anything specific, just work on something together. This ends up becoming a much more comfortable space for them to open up with all their questions.

Tech really isn't a direct cause of real social problems, but often just presents distractions, which can add up over time. Phones have just taken us to a point where tech is just always with us, thus, we've hit some kind of "maximum distract-ability" point. But the real solution isn't to really ban new tech, it's just to learn how to identify and avoid letting it distract us further.

This doesn’t seem like they figured out anything about “high functioning teams”, they just performed a survey.

Like, do these companies actually ship faster, have lower rates of issues, better MTTR, etc? This just says things like “there are more full stack engineers”.

At least the Puppet state of DevOps report gives you a “low, medium, high” categorization. This doesn’t seem to be describing much other than some trends they saw this year.

It's an interesting thought experiment.

Recently, I've started switching my note taking to being more aligned to the ideas in the antinet zettlekasten. (See https://zettelkasten.de/posts/overview/). Basically, I handwrite notes into images that I store. This basically makes it less "convenient" to search, but I've found that doesn't matter - I seem to recall things that I handwrite far, far better than anything I've ever typed. And I can make pictures. But it's still pretty nice to have it on my tablet vs a card index (though I can still transfer between the two formats pretty easily using a scanner or my phone camera).

My sense isn't that there's this strict "convenience vs satisfaction" thing going on, but that there's more of a bit of a UX mismatch between how people kind of naturally interact with the physical world and the very limited interactions we currently have with the digital ecosystem. I find handwriting to be much more engaging, even on a tablet, versus typing anything. Though it still feels like we've barely scratched the surface here of what you can do with digital interaction.

Maybe AI improves on this, making these more physical interactions easier for machines to understand. Like, in my note taking example, maybe my handwriting could be used as input to a recommendation system for new books. Or, instead of thinking about YouTube as a replacement for physically being on a construction site, you could have shorter, contextual videos sent to something like an AR system while on a site, and then ask more significant questions of people when you get stumped.

After timers, the #1 use of Alexa in my house: 'make a fart noise'.

We've tried to use Alexa for some games, like Jeopardy or Whose Line Is It Anyway, but it always is an incredibly buggy experience. Even just simple multiple choice games should work perfectly, and yet, a lot of the time even basic answers don't register, and the games themselves crash.

I've always wondered - stupid mobile games are dominating video games in terms of money right now. Voice platforms seem like they could do something similar, but all the platforms want to be your shopping AI or whatever. Just seems like the two worlds - voice platform and game developers - just could never get together and figure things out.

How easy is it to transfer between teams? Some companies make this easy, others make it almost harder to apply internally then externally.

I've been using digiKam in a similar way, where Affinity Photo is where I do manipulation, and digiKam for organization. It's been working well enough, though, I am very much an amateur hobbyist.

I had the first generation iPad Pro. And eventually I gave it to my wife for a lot of the same reasons you list.

Ultimately, Apple will just doesn't want you to separate your data from the app. It's not just that it's a walled garden, it's a wall around you maintaining your data.

My primary tablet usage during the work day is taking notes. With a pen. And I've started organizing my notes into a self-indexed hierarchy of images. And for backup, those images go into S3. I can then just sync any other machine and peruse the images using Digikam which is kind of nice for a free open source app.

Every solution I've found in the iPad just requires you to put your data in some kind of isolated app playground, and then jump hoops to try to move it into any kind of backup system you can access on desktop OSes. I bought a Microsoft Surface, and despite not having worked in Windows in a decade or so, I was able to get my image-based note taking workflow done and set up in a day.

So, this iPad is a beautiful device I will never own. Purely because of their software policies. It's annoying.

That's an excellent example. Mostly because I've probably had to replace simple retry loops more than once after they triggered various kinds of death spirals.

Even recently, an engineer on my team spotted a retry technique, where the system tried to check if the DB's replication mechanism was slowing down, then would just re-enqueue the message for later. This ended up doing a bonkers amount of wasted effort because when DB replication started getting overwhelmed, messages would just constantly be re-enqueued and not ever processed. So the queue system ended up just having a bonkers amount of messages that were just popping off the queue, doing nothing, and hopping right back on.

There is so much abstraction going on now, debugging can be very, very challenging. Many systems are distributed and virtualized, so even trying to create a detailed visualization of "what's going on" can require mind-boggling amounts of information.

Also, even if you understand and agree with Werner Vogels' mantra "everything fails all the time", it's incredibly challenging to make a truly robust distributed system. There's just so much happening so rapidly, low-probability problems become consistent failures as you scale, and the wrong recovery approach can have non-obvious second-order effects leading to bigger problems.

While this is interesting, I'm very curious if there's any analysis that looks at other pressures that might happen in tech that's different from the broader business world. Are acquisitions more frequent?

I say this, because in my 20+ year career, this has preceded most of my job changes:

1. A major business event: usually acquisition, or one time, a CEO just quitting outright

2. A major management restructuring from 1 week to 12 months

3. New managers try to make their mark and trigger death marches or just erode confidence

4. I leave and get a decent pay bump and realize my mental health is better

I actually consider myself to be pretty conservative about job changes. I'm at about 3.5 years per position. I've probably left money on the table too.

I see this more as a challenge of managing the different threads of communication. Basically, threads, as they are implemented in most chat apps, just suck. If you're not involved in that particular thread, you tend to just skip over it. And most of the time, you have to manually interact with each thread to figure out what's going on.

As a more real-world example, in Slack, you can decide to use more channels instead of having a big channel with lots of threads. But this tends to need a lot of discipline on channel management. Places devise naming conventions, etc. Or maybe they integrate with some other tool to manage the conversations.

So, a lot of my DMs tend to just be me and a "tiger team" on a particular subject. Which is really just a workaround to not having to figure out channel management. It's not a carefully thought through system, it's a workaround to our current crop of chat tools.

Personally, I've found older "discussion forum" systems do a better job of threading instead of a chat-style tool. But maybe I'm just getting to be an old person.

> It seems that in many places, "DevOps" is all Ops and no Dev.

This was definitely my experience at my last couple of jobs. At my last one they "scaled out their DevOps team" by hiring tons of juniors with next to no software development background. And then they "empowered" teams by assigning the juniors to each dev group. As a result, we ended up having to train them how to do their core jobs, which... went about as well as you'd think.

Eventually, there was an attempt to shift everyone to kubernetes. They had a special "DevOps" team build a layer on top of it to handle the non-kubernetes aspects of deployment as well, and somehow manage them together using Helm. If you're wondering "what the hell does that mean", well, it turned out nobody really knew. These "DevOps" engineers didn't really seem to understand kubernetes core concepts, and just ended up hacking away with some scripts on top of terraform delivered via Helm until something got configured. It was incredibly slow to deliver, hard to use, and I just stayed away from it until some exec threw down the mandates. (And then everyone started quitting because it was an absolute disaster.)

Ultimately, these are really stories about bad management, not really anything to do with DevOps. But that's how these things roll - some new hot concept comes to town, and bad managers try to adopt the term, without really understanding it.

A sax is really easy to control (or lose control) of the pitch. And in fact, many saxophonists will just shift various ranges around sharp or flat to suit their style (cough Phil Woods cough).

So basically, a woodwind like a sax will tune a few notes with a piano or whatever, but it's really up to the player to keep playing in tune. I would not even bother trying to autotune or use post-processing; it'll just sound weird.

This is also how you can get a room full of student musicians "tuned" but it still sounds like a disaster.

I see these articles focusing on cars and density, and don't seem dive into details of policy decisions.

This year I moved to a city (Spokane, WA) with an abundance of parks and a few smaller commercial businesses within the middle of residential areas, and the amount of interactions I have with neighbors has exploded. Just yesterday, I'm in front of my house breaking down cardboard for recycling, and met someone new just walking over to a nearby park with their dog. This never happened to me in the last 3-4 cities I lived in.

My sense is that policies like parking minimums, restrictions on small commercial businesses in residential areas, access to parks, might actually have a bigger impact than simply trying to have lots of people living on top of each other.

Not that density is bad, or necessarily good, I just don't see it as particularly significant to improving social interaction. Simply stacking people together isn't going to fix this problem.

We can only hope that the US doesn't let a corporate interest put limits on this a la Intuit with free tax filing.

Otherwise, yes, it sure seems like this would pretty much obsolete a lot of payment platforms.

As a hobbyist who used Fusion 360 for various woodworking design and CNC tasks, this doesn’t really impact me, however, it basically pushes me a lot closer to investing in other tools.

Basically, pulling features without much communication or forewarning is just not OK.

Part of me wonders about the feasibility of an open source business based around paid support and training of a complex professional tool. I know of cases this works for tools aimed at software engineers, but I’d be curious if that was really attempted with CAD

I suspect for something like this to happen, the upper levels of management needs to understand the individual contributor better. I've worked now for some very large companies, and, most of them simply do not think about individual productivity at all. To them, this is simply "not their problem". Instead, it's something for the manager that directly interacts with the individual to deal with.

The problem is, you might have one team agree to this, and others not. But how many companies would let one team take control over their physical space? Very few places I know of would even let a lower-level manager relocate people together.

Problems of our working culture somehow seems tied to our hierarchies and specialties. We don't really give individual teams the budget to go find their own space; instead, it's all specialists who have very little interaction (and often zero insight) with individual contributors.

I wonder if companies should be more organized where teams were "mini-businesses". Instead of worrying about setting up one giant space, it was up to the team, with their own support staff (and budget) to figure everything like their working standards up. I suspect that would change culture quite a bit, mostly, because there wouldn't be this weird "this is the way we do things here because there's this massive team nobody interacts with" wall. Instead, if the team felt like they could do things better, they just do it.

My gut is telling me remote work will upend a bunch of things, because workers will feel more empowered.

It is interesting to use a library as a model, but I would be amazed that you could get any particular company to understand and implement it. I could see teams having dedicated coworking areas that are extended from a large central open area. But, I could also predict that people would just carry their discussions into the open area, and constantly walk up and disturb the peace by asking "quick questions" anyway. Anyone asking others to "please be respectful" would probably get laughed at and ignored.

On the other hand, a coworking space might be able to pull off such a model, with a large open area, and then dedicated areas for team collaboration. You don't play by the rules: see you later.

I do think working physically next to others could be quite pleasant. But, given that in almost 23 years of work, I've never experienced this, I'll take remote work instead, since it at least gives me control over the mayhem. And maybe I'll ask if there's budget for some coworking space time. But given the current economy, I'm not holding my breath...

The general workflow I'm finding useful is to generate a ton of simple logs, ingest all those logs into a SQLite database (that acts like a "data lake"), and then use the customized REPL to generate some charts (typically .png files), CSV, or ascii reports.

I could see using a REPL to generate a TUI, e.g., "run a query and generate your own `top`". This seems like it could be a lot easier than trying to generate a PDF, interactive Excel, or complex HTML report (which usually means a bunch of javaScript).

There's something about text interfaces that just fundamentally "flows" from most programming environments.

I'm surprised how much time is spent thinking about planning and execution, and so little is really discussed about defining goals well. Because I've found that goals are often really vague, and frequently, they shift. And, shocker, if you change your goals you need to change your plans. Also, if you're not able to see progress against your goals, you probably need to change your plans.

A basic framework like "SMART" can help. But it does require some careful management; people can get really, really conservative if you're not careful, i.e., "undercommit and overdeliver" becomes a mantra. Some engineers and their direct management will throw up a lot of roadblocks to avoid looking bad.

This tension between trying to deliver consistently vs trying to take on bigger problems absolutely wrecks plans. If you want to deliver consistently, just focus on small problems. But not all problems are small, and some are even hard to break down because there's a lot you simply won't know. Periodically redefining and re-evaluating your goals is probably "step 1" in this process, and from there, the plans should flow.

> My recollection is that Chris Anderson's "Long Tail" never particularly promoted prosperity for those in the long tail but rather for the aggregators of the long tail. And that seems to have happened to a large degree.

This was exactly my understanding as well, but, some personal anecdotes also bring up some interesting questions.

The people on the long tail that I've seen be successful often just do things a bit differently, so I'm not entirely sure how you could easily measure success. Creators I know of use the aggregator platforms like a marketing tool, and sell "other things". So, for a couple of working musicians I know, no more CDs or any real money distributing music, you sell schwag, live concert revenue, etc. Woodworker's I've followed seem to embrace teaching and use a combination of schwag, recommended tools, educational tools, etc. in addition to the occasional custom piece of furniture. The successful ones do seem to follow the "true fans model", where they basically try to "live in their niche" out on the tail, and regularly connect with people.

But I'm not sure the long tail examples that are succeeding, are the "future of business". Really, they're just people who've done the math and figured out how to keep a small business afloat. But this money is a drop in the pond now compared to the platforms itself.

These aggregation platforms are basically becoming the gatekeepers and central banks of their marketplaces. And at least the way I've seen the long tail theory presented, they never really talk about the potential central gatekeeping aspect. It's always a happy "gee, we'll be really diverse and stuff", but never, "at the cost of fewer places to access a lot of these goods".

Visualizations are just one aspect of documentation, so I would recommend looking into how you organize your documentation, and build visualizations to support that. This is, after all, what I think you are really going for: just better written explanatory documentation, with useful organization.

The divio system is a good place to start, IMO, when it comes to organization: https://documentation.divio.com/

So, I would treat a visualization used in an explanation-style document very differently from a reference guide. One is intended to illustrate a concept quickly, another is intended to be precise. I don't think you'll see a single "visual system" ever take over, largely because documentation can have very, very different goals for the reader.

Visualizations in reference guides are (unfortunately) rare. I happen to like the approach taken by project reactor, embedding visuals into java reference docs: https://projectreactor.io/docs/core/release/api/