rhymenoceros

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.

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.

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.