HN user

jrott

719 karma

Currently working with data and doing operations work. Good at breaking prod and mediocre at fixing it.

Posts46
Comments121
View on HN
www.construction-physics.com 3y ago

The Story of Titanium

jrott
2pts0
www.freaktakes.com 3y ago

How did places like Bell Labs know how to ask the right questions?

jrott
3pts0
startupwin.kelsus.com 3y ago

What no one is saying about what AI will do to software developmen

jrott
4pts0
iism.org 3y ago

Driving engineers to an arbitrary date is a value destroying mistake

jrott
3pts0
www.jeffgeerling.com 3y ago

Cracks are showing in Enterprise Open Source's foundations

jrott
3pts0
www.systeminit.com 3y ago

DevOps Without Papercuts

jrott
1pts0
www.brendangregg.com 3y ago

ZFS Is Mysteriously Eating My CPU

jrott
3pts0
netflixtechblog.com 3y ago

Linux Performance Analysis in 60k Milliseconds (2015)

jrott
4pts0
blog.container-solutions.com 3y ago

Money Flows Part III: You’re Only as Agile as Your Budget

jrott
1pts0
softwareengineering.stackexchange.com 3y ago

Who created the idea(s) of the first loop constructs?

jrott
2pts0
twitter.com 3y ago

Neural networks in the 1990s

jrott
131pts84
lumpenspace.substack.com 3y ago

How come GPTs don't ask for clarifying information?

jrott
2pts0
dl.acm.org 3y ago

Efficient Redundancy Techniques for Latency Reduction in Cloud Systems (2017)

jrott
1pts0
acoup.blog 3y ago

Collections: How to Raise a Roman Army: The Dilectus

jrott
5pts0
resume.joshuaschultz.com 3y ago

Growth versus Scale

jrott
1pts0
truemped.github.io 3y ago

Cities of Software

jrott
1pts0
albertcory50.substack.com 3y ago

How About Not Overcoming Fear?

jrott
1pts0
rust-analyzer.github.io 3y ago

Three Architectures for a Responsive IDE

jrott
1pts0
abseil.io 3y ago

How to Work Well on Teams

jrott
2pts0
en.wikipedia.org 3y ago

El Paquete Semanal

jrott
183pts51
www.newyorker.com 3y ago

The Beautiful, Brutal World of Bonsai

jrott
3pts1
www.protocol.com 5y ago

An Oral History of Hugops

jrott
2pts0
www.cnn.com 5y ago

Suez Canal blocked by traffic jam after container ship runs aground

jrott
5pts0
jrott.com 5y ago

Internal Tooling Is Underrated

jrott
2pts1
globalecoguy.org 5y ago

We Need 4 Waves of Climate Action

jrott
3pts0
dondo.org 5y ago

On “Technical Debt”

jrott
1pts0
www.esquire.com 5y ago

If the Fire Goes Out

jrott
3pts0
peoplingthepast.com 5y ago

Kingdom: The Mitanni, with Mara Horowitz

jrott
2pts0
www.snewsnet.com 5y ago

Goliath's reckoning: Has REI grown too large?

jrott
1pts0
acoup.blog 5y ago

Collections: The Universal Warrior, Part III: The Cult of the Badass

jrott
6pts0

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.

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.

“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

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.

"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.

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.

Buy Don't Build 6 years ago

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

Buy Don't Build 6 years ago

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.