rhymenoceros

RAS syndrome - Recursive Acronym Syndrome (syndrome). See the Wikipedia link: https://en.wikipedia.org/wiki/RAS_syndrome

Hah! Both words have (slightly) different meanings, but yeah, I ironically didn't follow my own advice :-)

Judicious editing.

I think the Blaise Pascal quote about not having the time is relevant; making things concise takes more effort, particularly if you are not already in the habit of doing so already. Start with your communication, remove redundant or unnecessary words, then think about ways to compact things down even further by removing or rephrasing sentences.

Going through "Elements of Style" by Strunk & White wouldn't hurt too.

Not quite a+b, but a+b+c reordered may give different results[1]. Example from Python:

  >>> 0.1+0.2+0.3
  0.6000000000000001
  >>> 0.2+0.3+0.1
  0.6

It's an associativity problem and not a commutative one, however, that is relevant to the original point about folding floating point operations over lists.

[1] https://www.quora.com/Is-floating-point-addition-commutative...

This post has some claims on AES that seem out of date. For instance, most CPUs nowadays support 256-bit AES without resorting to bitslicing. And most implementations have had plenty of time to address the side-channel timing attacks from djb's paper.

The recommendation for 2048-bit RSA is also a headscratcher. I get why you'd want to prefer ECC, but if you have to use RSA for some reason is there any scenario where you wouldn't also want 4096-bit keys?

Mozilla's TLS and SSH recommendations are pretty solid though.

https://latacora.micro.blog/2018/04/03/cryptographic-right-a... is an alternate, arguably better, source of information.

A lot of devops tools, including Ansible and Salt, have higher-level concepts of ordering across hosts. In some cases this is implicit in the way the tool operates and people just take advantage of it, but in others (like Salt's orchestrate runner) the ordering of operations across hosts is explicitly defined by users. That can be useful for scripting blue/green deployment cutovers, pushing out new load balancer rules, etc.

> I'm actually curious about things like ansible; what exactly does it do that you couldn't just do with a bunch of redo scripts?

That might be more of a philosophical question :-) Most of those tools could be replaced with a sufficiently intelligent set of scripts. I think they get their popularity from providing more convenient syntax, building in parallelism for applying changes across hosts, offering cross-platform ways of doing common admin actions like creating accounts, etc.

But if you look at them the right way, they definitely share a lot in common with build systems, particularly when it comes to managing dependent actions.

> I'm sure almost everyone reading this thinks I'm hopelessly pedantic to care so much about the sequence of lines of output in my build logs.

Not at all! In fact there are other tools in other domains that could benefit from careful thought about how to interleave parallel outputs in a way that favors interactivity/immediate output but preserves (effective) ordering [1][2]. This is a tough problem a lot of tools just give up on, but the status quo of "buffer everything until it is completely done" grates against one's senses.

[1] https://github.com/saltstack/salt/issues/22733

[2] https://github.com/ansible/ansible/issues/3887

Indeed. Also, non-founder CTOs often find themselves in the odd position of being responsible for success and delivery but not being able to influence overall company strategy, particularly in tech-focused companies. It's almost like being a second-class citizen of the leadership team.

Not all companies are like this, but smaller ones that are looking for CTOs (whether due to founder splits or turnover) often are.

The other thing that sometimes happens is when a CTO position is carved out for a company that is doing well but needs "maturity," typically due to missed deadlines/etc. This can be a pretty terrible experience unless this sort of thing floats your boat - a lot of the downsides of working for a large company, but still the risks of working for a small one.

> Sure, I'm working with Angular now. I might switch to Vue.js because I'm not crazy about Angular and I've heard very good things about Vue, but I'm also wondering if I'd like Angular more once I reached proficiency in it.

I am probably preaching to the choir here, but if you are looking to sharpen your skills, it's almost always better to stick with a single tech and learn it really, really well. That doesn't mean it's harmful to step through some Vue tutorials to get a feel for how it is different, however, if you're not careful you can end up losing a ton of time learning about the JS framework du jour and not actually making progress on anything. Especially if you are not in any hurry to build something useful.

Just about the only constant in JS frameworks is that any decision you make now on which one to use will probably be wrong in a year.

That's not to say optimizing for development speed isn't a good thing, especially if you are looking to bang out POCs as quickly as possible to vet startup ideas. But if you're not careful this can devolve into "funtime with tech" that could be a major distraction which might not even look or feel like one.

Speaking from experience :-)

The problem is that metric, like any metric, is both easy to game _and_ can provide misleading information.

Measuring number of commits? Create fewer, larger commits. Measuring commit size? Pull in more third-party libraries, even where it does't make sense. Author count? Add more/less documentation and recruit or inhibit new devs depending on what your goal is.

Not to mention the number of commits/authors before and after an arbitrary point in time might conflate a successful growing project with a project in a death spiral being passed around from group to group.

It's a good idea, but in practice simple metrics like this often (but not always) devolve into prime examples of Goodhart's law.

I think it's a little more subtle than that.

In the context of a startup, if you try something and fail, you'll generally be recognized for taking initiative even if the result does not pan out. At that level, learning what doesn't work is often as valuable as learning what does work. Startups often bias towards hiring people with just this mentality because that is what they actually need.

In the context of an established company, sticking your neck out is like career suicide unless it's a sure thing. Unlike a startup, you're risking an _established_ reputation on a new idea. So you end up working in an organization that has an inherently different view of risk and trying new things.

I'm not sure whether "nobody knows how to do anything" results from an institutional aversion to risk or from the natural result of hiring people that fit within that system, but the end effect is exactly as you describe. It's way too hard to do anything off of the beaten path, and trying to do anything along those lines _immediately_ results in negative feedback which makes employees a lot less likely to attempt such actions in the future.

This is an improvement but it still seems like HAProxy is offloading a small (but annoying) amount of responsibility to users when handling restart requests. You still have to track the existing process' PID and give it to the new process, give the new process the same "-x [socket_file]" argument, and make sure the new process comes up before making any subsequent changes to the HAProxy config file.

Does HAProxy have any plans to wrap this process juggling to make things as stupidly easy as nginx's reload behavior?

How does Tyk compare with Kong and other "API gateway" implementations?

Has HAProxy cleaned up their dynamic reload issues? I am a pretty big fan having used HAProxy in production, but compared to the relative simplicity of "nginx -s reload" the restart complexity of HAProxy always gives me pause.

Traefik[1] is written in Golang, which is technically a (depending on your viewpoint) memory-safe language. It has a pretty decent adoption rate, has a reasonable story for being built on battle-tested libraries, and has a pretty good reputation.

Haskell has yesod[2] but I don't think there's a variant of that dedicated to nginx- or haproxy-esque reverse proxy duties.

[1] https://github.com/containous/traefik

[2] https://www.yesodweb.com/

I think Fernando Serrano captured it perfectly: https://twitter.com/fernandojsg/status/1017411969169555457

How many direct reports does Musk have? Looks like he just got a few more, which might not be so great for a (reportedly) overworked schedule.

Where did you get an 100% overhead for an employer?

I've done back-of-the-envelope estimates before and have come nowhere near that. At best, it's somewhere between 15-25% depending on employer 401(k)/etc matching, deferred comp, and office space pricing.

The worst I could find is 40% - http://web.mit.edu/e-club/hadzima/how-much-does-an-employee-... - and that uses a much different cost basis (not $125k).

Where in the world did you come up with that number?

Indeed. Some of the ideas for LFS made their way into ZFS and btrfs: http://pages.cs.wisc.edu/~remzi/OSTEP/file-lfs.pdf

Don't forget he was also one of the original authors of Raft: https://web.stanford.edu/~ouster/cgi-bin/papers/raft-atc14

Nice! Ironically the Go version is much longer, mostly due to the interop overhead (and partially due to the code style).

I know the JS ecosystem has some pretty counterproductive culture when it comes to package management (leftpad), but can you provide some examples of terrible issues still present in NPM? I hear this complaint often and I'm wondering what other people think of as insurmountable technical issues or design flaws in NPM.

Title needs a (2016).

Not to mention, for a lot of these companies that pay well, your position will be replaced by someone who is likely in a worse situation than you who could not afford to quit even if they wanted. Net result, an employee that is less likely to complain or leave when things start going off the rails.

Sometimes (not always) it's better to try effecting change from the inside.

Oddly enough, the three biggest cloud vendors by revenue are MS, Amazon, and _IBM_ (see links below).

IBM Cloud revenue is a head-scratcher. I've had to use them in the past, and while they have some unique features, it's hard to imagine anyone choosing them unless they had an explicit need for those features, or were forced into using IBM due to existing business relationships. I guess corporate inertia (possibly from the SoftLayer days) is a hard thing to overcome.

https://www.forbes.com/sites/bobevans1/2018/07/11/microsoft-...

https://www.forbes.com/sites/bobevans1/2018/05/21/top-cloud-...

https://www.forbes.com/sites/bobevans1/2018/04/27/microsoft-...

According to WinAmp folklore, he was a contractor for WinAmp 3 skins and not necessarily a full-time dev: http://forums.winamp.com/showthread.php?s=&threadid=118192

You might be thinking of Justin Frankel: https://en.wikipedia.org/wiki/Justin_Frankel

The connection is still kind of cool though!

> To paraphrase some Cal/UC Berkeley professor that I cannot remember, he said that the problem with scaling is that when you go up a magnitude or more, you may need a qualitatively different solution for the same problem.

You might actually be thinking of Jeff's Stanford talk from a few years ago (2011). Slide 21 of:

https://static.googleusercontent.com/media/research.google.c...

  Ensure your design works if scale changes by 10X or 20X
    but the right solution for X often not optimal for 100X

There's no attribution, but that is good advice I've kept with me throughout my career. Props to the original author (perhaps apocryphal at this point?).