jrott

there are some weird phases that happen for sure. I've noticed the same thing with programming languages. There are periods where there is tons of stuff about functional programming and then it'll die down again for a while.

I occasionally post on jrott.com

The compute itself can be in your account. The control plane is usually managed by databricks

At this point there are so many layers that it would be hard to figure out the common problems without doing some serious work profiling a whole bunch of applications

No no no Kubernetes or Serverless or ChatGPT is going to save us this time.

More seriously it always going to be complicated and annoying. It's really past time we started dealing with the fundamental complexity of everything we are trying to do with software.

It's interesting how things hold up over time

"This calculus means that eliminating barriers to switching is the most important thing you have to do if you want to take over an existing market"

Still holds up today for software products, switching between products is still a pain and making that easy makes it possible to justify switching.

Having a child now makes wanting him to be "like me" seem like such a fools errand at this point. He's so obviously his own person that even if he decided to do things in a similar way to me his path to getting there would be so different that it wouldn't actually be the same at all.

The fact that they are planning on doing this across multiple releases gives me hope that they'll be cautious with this.

At this point I’d rather see the how to fix it when things go wrong demo. Of course very few tools can show that either because it’s messy or it’s to hard to show all the pieces.

Open office plans are a huge problem. It’s very hard to do anything that requires deep thought when there is a ton of noise and visual distractions.

“Having done this job once upon a time, I think the downtrend in title is inevitable”

I absolutely agree with this. It seems like a it inevitable for anything that a business needs to do but doesn’t really want to do. Another place where you see it is with project management, where there have been many different titles for the same role.[0]

https://chiefofstuff.substack.com/p/the-job-status-cycle

Not zero if I can't figure out how to get started in a reasonable amount of time. I'll go look for another solution

At this point I believe that documentation is the most important marketing artifact that a project has.

This article is such a mix of hilarious and deeply frustrating.

It does identify a real problem of people who get things done but what they have done is useless at best or harmful at worst.

The issue is what to do about it. I’m guessing it’s hard to say because the two skills that I’d think of as smart in the context of this article are, understanding what is important and taste to know what good looks like.

Of course both of those things are very hard to teach and in practice mostly seem to be taught via apprenticeship.

Probably deal flow. Seems like a good way to find AI startups.

"Languages and their tooling ecosystems express how computing is concretely embedded and used by society. People adopt the tools to get jobs and to get the job done, whatever the "job" is. In turn the available remunerative jobs fit certain business models and markets."

This seems like the key thing. We've gone through something similar with operating systems where there hasn't been a ton of change for a very long time now. It seems like we've just hit the same part of the lifecycle with programming languages where change happens much more slowly.

Also works for health data as well[0] if anonymity is actually important it's really hard to collect data at all.

[0] https://www.nature.com/articles/s41467-019-10933-3

not sure you're going far enough there. Obviously we need a scrum king to guide our scrum lords as they help our scrum masters transform our organization.

> In my experience, code with too many functions is more difficult to grok than spaghetti code. It's like trying to read a book with each sentence reference a different page. So, I try to code like I would write, in digestible chunks.

This is so true. The worst code that I've dealt with is the code that requires jumping to a ton of different files to figure out what is going on. It's usually easier to decompose a pile of spaghetti code than to figure out how to unwrap code that has been overly abstracted.

There is a real trap in always feeling like you need more career wise or comparing how you are doing to other people.

It's way too easy to shift the goal to being a little bit more successful then you currently are and it makes people miserable even if they are doing well by most people's standards.

I didn't see it either. Hoping it's semi-reasonable because I'd like to be able to really use it.

Yeah developing actual customer facing features is the goal. That paragraph needs to be edited

Author here I actually think spreadsheets are great because they are so accessible. What isn’t great though is when there is a business processs that is a spreadsheet and knowledge that exists in one persons head.

Actual debt has a few major differences with tech debt though. First it's easy to quantify the cost of. Second and more importantly where it's good and bad are almost the opposite of where tech debt is good and bad. You want to use debt for financing when you have a relatively stable mature business where as when things are still uncertain you want to use equity.

Tech debt is a bad metaphor. Having lots of debt can be a smart business decision. The problem is usually engineers do a terrible job telling the story around why having lots of tech debt will cause problems. Usually if you've got non technical managers the best case is they've lived though it before and know.

Most of the worst production issues I've been involved with have come from trying to fix a minor issue and then somebody making a mistake. The way our brains are wired to handle stress isn't really useful for debugging complicated problems.

Working at a fortune 500 company it feels like the tools that we have for planning alone is almost as long as that list. I'm exaggerating some but this is totally a small list compared to what it could be. The amount of SAAS tools that you want seems to scale pretty linearly with organizational complexity.

They love us seems to never be that useful. I actually meant more in terms of there worried about foo or finding out about the dumb workaround there using. That stuff seems to be an early warning sign that something isn’t going well.

practically if you are dealing with large enterprise customers it's better to use qualitative data from your account managers to figure out how much risk there is with each customer.

This is painfully funny. It's interesting though I feel like it's harder to do data science right because the iterations are so much slower. If it takes all day to run a model it's hard to get in enough reps to really understand what good practices are for the domain.