jchmbrln
I think you’ve stated it too politely. :) The current HN title is a lie meant to generate outrage.
Of course I hear plenty of people complaining that apps on top of hypertext is a fundamental mistake and so we can't expect it to ever really work, but the way you put it really made it click for me. The problem isn't that we haven't solved the puzzle, it's that the pieces don't actually fit together. Thank you.
Can someone comment on why this is? My understanding is that the existing diesel trains use diesel generators to power electric motors.
My questions are: 1) Does "electrified" mean pulling power from a third rail? 2) Whatever it means, what makes "electrified" twice as fast as diesel-electric?
> How you unwrapped an abstraction and made things better by removing it? I have dozens of battle stories.
But then also say:
> After all, you didn't use the abstraction so you don’t know if it was good or not, and you can only speculate that the decision you made was actually a good one.
So if I remove indirection I can know the code is better, but if I avoid indirection to begin with, saying it's better is just speculation and arrogance. Huh?? I guess your advice would be to always add the indirection just to see how bad it can get?
A principle takes skill the apply, but it's still worth stating and pondering.
And yet, the big takeaway for me is that to be a high performer it isn’t enough to A) know what needs to be done, or B) be able to do it well. The key is C) figuring out the incentive landscape.
His story of carving out his own job only to find he had no support from the board is what I’ve tried before. In my low performing organization, I thought I could be a high performer by knowing what needed to be done and doing it well. Everybody I directly worked with loved me and thought I was highly effective, but I never made any lasting change like this author. I didn’t understand the need to skip way up the levels until I was already burnt out.
> The WolfsBane Hider rootkit hooks many basic standard C library functions such as open, stat, readdir, and access. While these hooked functions invoke the original ones, they filter out any results related to the WolfsBane malware.
I took this to mean some things like a simple “ls -a” might now leave out those suspicious results.
It looks like the new, thick bags are 5x thicker than the old, thin ones (0.5 mils vs 2.5 mils) [0]. 11lb is a lot less than 5x 8lb, so the per-person bag trashing must be drastically lowered, unless weight and thickness aren’t correlated.
That said, this could still reduce my plastic use. The old, thin bags were sufficient. The new, thick bags have been overkill since day one. Given that the frequency with which I take out the trash didn’t change when the thin bags were banned, I’m sure I use quite a bit more plastic than before the ban. Maybe bags sold for small trash cans are thinner, and I’ll go back to pre-ban levels of use.
And Amarok! I haven’t thought of that in a while. Losing Amarok was my single biggest regret when I became a Max user. I’ve not used anything since that came close.
It’s hard to beat the simplicity of Leaflet, but neither it nor OpenLayers can handle Mapbox Vector Tiles in a performant enough manner, so Maplibre is the future for us.
I was not aware of Microsoft’s involvement. It’s great to see some big players using it too!
I started a personal folk song collection using ABC notation. For simple tunes ABC is fantastic, but now that I'm doing more choral/four-part works, I'm reaching for the more powerful tool. Yet there seems to be a huge gap between ABC (simple things done simply and in one way) and LilyPond (do literally anything you want following any format you want, dropping into Scheme as necessary). Ease-of-use/quality-of-life tooling to fill that gap is appealing.
P.S. I'd also love to hear the story of your music publishing venture. It sounds intriguing!
When I put my dev hat on, I want the option of attaching a debugger and adding breakpoints. Anything there?
If you have any questions about the process or roles, don’t hesitate to email me at Joshua dot chamberlain at my company’s domain.
My team is looking for hybrid engineers who are comfortable with both infrastructure and code to support a massive modernization of our tech stack and processes. But more than good tech, we need good listeners: technical leads who can bridge the gaps between product, engineering, and operations to create solutions that meet real needs and make us more effective as a whole organization, not just modern for the sake of modern.
Bonus points if you’ve read the Google SRE books.
Our tech stack is Java/Groovy, a rapidly increasing amount of Kotlin, some Python, Angular+TypeScript, AWS, Ansible, Terraform, EKS/K8s, MySQL/MariaDB+Galera, MongoDB, ScyllaDB.
Senior: https://careers-oportun.icims.com/jobs/11467/sr.-site-reliab... Staff: https://careers-oportun.icims.com/jobs/11260/staff-devops-en...
There are plenty of SWE roles open too, not just SRE, so look at Oportun.com/careers even if you don’t want to join my team. :)
And tell the recruiter you came through HN.
Speaking of which, what caught my eye in your post is the problem you identity with how SRE is usually practiced vs. what it was supposed to mean. My mandate in this new role is to update our practices and technology to make our software more reliable, and I'm shooting to accomplish that specifically by tackling that problem. In my opinion, there's a reason why the term "SRE" was coined, and it all centers around shaping the organization, _not_ the technology. In an organization with properly aligned incentives, the technology should follow. (Of course it's not entirely one or the other—tech can feed into incentives and help shape the org as well.)
I'm doing my best to carefully guard the term "SRE" here and educate people about its meaning because the ideas and philosophies it brings to the table are precisely what will allow me to deliver what I was asked. If this resonates with you or anyone reading this, send me a message. We're hiring.
This summer I finally hopped over to the DevOps side of the house as a manager, having always been a software engineer. My mandate from higher ups is to reform the team to start practicing SRE, but I think it's really more about reforming the whole organization. In every way possible, I'm trying to build a team of people willing to "be the change" like you say. But I also hope that SLOs, as a formal way of agreeing on priorities, will grease the wheels a bit.
> And often, it's not a technical solution.
Absolutely. In my experience, it's almost never technical. If you can structure the collaboration so that correct incentives apply, any technical solutions required come naturally.
(I wrote about my Rackspace experience here: http://zephyri.co/2016/can-devops-be-outsourced/)
Without more information, what you just described sounds to me exactly like a supply-constrained scenario. Population can’t grow, so prices skyrocket.
The only thing you've got wrong is page load time and overall responsiveness. This needs at least a couple more MB of JS.
Good work.
This is the precise reason I've not yet devoted the time to learn C++. I'm a little scared off by having to learn the biggest programming language and also which large sections of it to avoid before I can be productive.
> It's nice if you're copy/pasting stack overflow snippets or your use case is very standard, it sucks if you want to modify the code to do something a bit different and out of the box because now you have to learn the rules of this custom DSL.
This basically describes Spring, and I'm not just being snarky. To someone from the outside, Spring's annotations seem to have all the problems you list. I have trouble imagining that heavy use of macros could be much worse, and I can certainly see the overlap between macros and frameworks.
> These estimates are based on a universal basic income paid for by increasing the federal deficit. As part of the study, the researchers also calculated the effect to the economy of paying for the cash handouts by increasing taxes. In that case, there would be no net benefit to the economy, the report finds.
> "When paying for the policy by increasing taxes on households rather than paying for the policy with debt, the policy is not expansionary," the report says. "In effect, it is giving to households with one hand what it is taking away with the other. There is no net effect."
TL;DR: If we create money, there's more money in the economy. If we don't create money, there's not.