> 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.
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".)
> 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.
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 (:
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?
> 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
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...