tarmstrong

Agreed that they should mention an alternative in the article.

Another article on the CBC from last summer has a good list of alternatives that I found helpful: http://www.cbc.ca/news/canada/bbq-cleaning-alternatives-bris...

> Software is significantly different from buildings in that it can be substantially upgraded or redesigned after going into production.

I used to think this was true, but after talking to architecture/civil engineering friends a lot about this, I've learned that this is less true than I believed. There are often changing requirements for buildings due to different use cases, changing regulations or building codes, or a change in energy prices (or the social cost of using a lot of energy). Sometimes new technologies are used without a lot of experience with them, leading to high operating expenses for the lifetime of the building.

I asked my friend about your comment and he gave me a few interesting examples: 1) "flying form construction" that leads to exposed concrete slabs on buildings that bleed heat in the winter. This was really cheap to build but turned out to be really awful for energy efficiency (once we started caring). 2) a building in the 50s-60s that was built with automatic window blinds. The maintenance cost of fixing the blinds when they inevitably broke led to them not getting fixed, and the building becoming basically useless.

If you're interested in reading more about this, Stewart Brand's "How Buildings Learn" is a really good read for laypeople. I was really surprised by how much of the book could be applied to software engineering.

(This is not a field I'm familiar with so any errors are mine, not my friend's.)

"500 Lines or Less" is an entire book of articles just like this. Each chapter guides you through a small (500 loc or less) implementation of a common component (eg a web server). http://aosabook.org/en/index.html

When you say cyclists in Toronto can be awful, what do you mean? Are they mean to you, or do they not follow the rules of the road, or something else?

When I cycle I fear being killed by a motorist; when I drive I fear killing a cyclist. It's important to clarify whether cyclists are putting you in danger or if they are stressing you out. Both suck, but one sucks a lot more.

This is a great teaching moment for anyone who works in UX or observability, but it's worth keeping in mind that the FCC's Public Safety and Homeland Security Bureau (who operate the Emergency Alert Service (EAS)) has a yearly operating budget of around $17MM this year. The system itself was launched in 1997.

This is a legacy software (and hardware!) system with a relatively small budget and number of employees that needs to coordinate with other large organizations (FEMA, HI-EMA, NOAA, etc.). I think the most interesting lessons to learn from this have to do with long term software maintenance. I'm sure folks at the FCC/*EMA knew that this UI was janky but why did they not have the budget/power to fix it? How do we ensure that the public sector can benefit from the technical advances that most people on hacker news take for granted? Curious to hear from folks with experience in relevant parts of the government.

No difference — we are using Kubernetes's native cronjob support. This post is about how we migrated to that system.

They're making a joke about the misspelling of Matt Damon. "Daemon" is a computing term [0] and /sbin/ is a folder that you might want to put a Matt Daemon in. (Also, daemons are often named with a "d" at the end, like "etcd" or "mattd".)

[0] https://en.wikipedia.org/wiki/Daemon_(computing)

> You need to be just as sure that the partial revert will not interact poorly with other parts of the new code that you are not reverting.

By partial revert, I'm imagining that three people have changesets (A, B, C, in that order) that have been deployed. You notice that A broke and you make A' to revert it. I think the author is arguing that it is easier to review A' to see if it is a safe change than it is to verify that A', B', and C' (the full revert) are safe to revert.

In other words, even if you don't use version control to record that you reverted A, B, and C, you still effectively do that by reverting in full. You just know that the combination of A', B', and C' was safe when it was deployed.

Is that what you're imagining or are we talking about different things? (I don't have strong opinions about this, I just want to make sure I understand your perspective (: )

> But the author's idea that you should generally plan to soldier through to newer code if things go wrong during deployment as a standard operating procedure betrays a lack of experience and sends a dangerous message.

The author says "reverting smaller diffs as a roll-forward is more verifiable" near the end of the article. I agree the title makes this a bit confusing, but I don't think he's arguing that the only way to recover is to write a patch under pressure.

> No one argues that.

I've encountered this argument in real life. I agree it sounds a lot like a straw man though and doesn't help much with my argument -- thanks.

And I agree that it is more expensive to hire this way because of how diverse CS graduates are. Do you think it might be worth it in order to help nudge the industry at large in a more positive direction?

If you took all the time you spent writing comments like this and spent it instead on questioning why the norm for other companies is 10-90 or 20-80, we probably wouldn't be having this conversation quite so much.

Part of the reason why this announcement is significant is that people frequently argue that it is impossible to build a gender-equal team. This shows pretty clearly that it is possible. I don't think this is equivalent to saying that all companies need to be exactly even in the end.

> The men that don't get jobs because of these new 50-50 splits, where do they work?

Do you think there is a shortage of tech jobs? If the end state was equal for men and women it seems more likely to me that plenty of people would still be employed, but the best jobs would be going to the best people rather than just the best men.

Does all that make sense? I'm genuinely curious about why equality is uncomfortable for you.

I'm Canadian too. I sometimes use "you guys" when speaking to a group that has women in it; I don't use "guy" in the singular when talking about generic technical roles because it implies that being a guy is part of the job. In many cases this is effectively true due to sexism in the industry, so it's not something to take lightly.

I don't think this is what you intended, to be clear! But I do think that is how it would be interpreted, even by Canadian women.

Not all programmers (engineer or otherwise) are guys -- probably worth keeping that in mind if you want this to be a welcoming community for everyone (:

Great point. Thanks!

There are regulations that affect the work of software engineers. PCI DSS is one that I am familiar with. Perhaps unfortunately, if your software interacts with the real world (like payments infrastructure), you have to heed regulation. This tends not to affect people who are casually writing software or working on many open source projects, but it does impact large companies like Google.

(I like to think of this as pretty similar to the Haskell IO monad. At some point you have to break out of your cozy side-effect free code and actually do something. At that point you have to deal with the messy real world.)

OP here. I work at a company that is able to move quickly, and yes, sometimes breaks things in the process. Tradeoffs between speed and safety are fine to make, in my opinion. It does seem like it would be useful to regulate things like ethical conduct, though. Maybe this dictates what systems are ok to move quickly and break and which systems aren't. What do you think?

> their primary obligation is to the ethical standards of their profession, not to their employers.

OP here. The intended subtext of my post was that it would be nice if our industry had ethical standards as well. (:

> The only thing better that I would recommend is to actually make your own Docker. It's not that difficult, you're basically just slapping together some system calls and execvp()ing some other standard tools, which is what Docker does

Not sure if you've seen this, but the author wrote a great post about the Linux primitives that Docker is built on: http://jvns.ca/blog/2016/10/10/what-even-is-a-container/

The third book was released earlier this month. Since then, nothing new.

Thanks! And a whole lot more congratulations are owed to the kind folks who wrote the words that go inside the book, and those who helped with copyediting. :-)

We're veering off-topic here, but why did you buy so many bay leaves?

"Scale" is a funny word. It doesn't scale in terms of decision making speed. But it does scale in terms of decision making quality. Obviously if social cohesion within the group is too high, or if the people present cross too many hierarchical levels, the group won't use its diversity to make excellent decisions. But if done properly, including more people in decision making results in good decisions.

This is one of the ways that you can get over narrow-minded specialists making decisions that work for them but screw everybody else.

You raise a good point, but I think the "adolescence" part is when you say mean things about The Man behind his back over beers during frosh week. When you start your own company, is that really the same thing?

This comment came off as really grumpy. You have exactly the "get in line" attitude the author was complaining about.

You come across as incredibly entitled and arrogant in your post, I hope for the sake of the success of any future "start ups" you participate in, it's not the case.

Entitled? I don't think he feels entitled to some measure of success. I think he feels entitled to a healthy dose of experience, which is what he'll get.

Arrogant? Read his post again. I'm not getting the arrogance vibe.

"I have no deference to authority figures and have never been shy to voice my opinions, oftentimes to my detriment." This doesn't make you a good entrepreneur, it makes you an asshole.

1. Those aren't mutually exclusive. 2. It doesn't make you an asshole, it makes you one of the few who can make a difference.

Using a debugger has been useful to me lately. They can take a while to learn (depending on the language and environment), but they're well worth it. You get to step through everything that the interpreter sees. The only drawback is you can get lazy, as it lets you read only what you need to read. You won't be disappointed unless you know the codebase well enough for the debugger to be tiresome.

Then you are trying new things that are too difficult. Uncomfortable is best in moderation.

Somewhat related: there's a Processing port to JavaScript.

http://processingjs.org/

You can write your code in Processing or JavaScript, which is nice if you want to take advantage of the Processing library without having to learn a specific language.

This is better written as "I agree".

> Not trolling... I know I could just Google this question, but this kind of > search usually turns up rants by language zealots.

Isn't that what trolling is?

I'm not sure why that would even provoke rants by language zealots. It's a simple question with a simple answer: big libraries and projects that can't be ported in an afternoon.

That is to say, Haskell is a nice language but there's no Drupal port to Haskell.

> but they also have communication they never had before

Funny you say that. People in 1848 also had "communication they never had before," and they could "organize efficiently as they never could in past".

From _1848: Year of Revolution_ by Mike Rapport:

> The speed with which the wave of revolutions swept across

> Europe was due to the wonders of modern technology. In

> 1789 it took weeks for news – carried, at its fastest, on

> horseback or under sail – for the fall of the Bastille to

> be relayed across Central and Eastern Europe. In 1848,

> thanks to steamships and a nascent telegraph system,

> reports were being heard within days or even minutes.