ellius

I wasn't imagining a full rewrite, more like a "holding area" that could defer some of the load. Again I may be totally wrong about this—I have never written a COBOL system, and if there is some plausible way to make it effective for this problem in a reasonable timeframe, then I understand why that would make sense. I understand all of your reasoning and agree with it in general. I know rewrites are very expensive and often ineffective. I'm just skeptical that the system can be modified quickly to deal with this new load. But again I am not an expert and could be totally wrong, and I'm open to being convinced.

I'm a younger engineer, so I say this with a degree of humility, but is trying to modify these monstrous legacy systems on the fly during a worldwide catastrophe really the most responsible or intelligent solution? Is there no way to authorize some kind of emergency system built with modern tooling to offload the system burden and then process it later through the system of record? If I were trying to deal with this problem, my approach would be the following:

- Organize the legislature(s) to pass some kind of emergency act that gives protection around PCI compliance and that sort of thing to new engineering teams

- Hire business and technical experts, fast

- Build a system on AWS that can handle massive scale and start offloading the most important business functionality to that system (things like registering for aid, fraud prevention)

- when things begin to return to normal, start processing requests through the original system, deal with problems, whatever

I know all of this is not easy. Legal and compliance stuff is tough, and I know the domain itself must not exactly be simple. But this is an emergency, and it calls for emergency measures. Trying to hack your way through an ancient code base on the fly seems like it might be doomed to failure.

This reminds me of the article "COBOL and Legacy Code as a Systemic Risk." Like the pandemic itself, this was a foreseeable risk:

https://www.nakedcapitalism.com/2016/07/cobol-and-legacy-cod...

If that's the case, that's what should have been made clear. OP clearly doesn't think that's what happened.

Yeah whatever happened here, the communication from this person's leadership was bad. I'm not trying to vilify them—maybe they had their reasons—but OP is clearly confused about why they were laid off and how (if) it could have been avoided. If I were going to fire someone with 15 years' experience, I would really try to give several clear warnings and actions leading up to it, assuming that was my actual reasoning.

This is the thesis of Popper's "The Open Society and Its Enemies." He argues, correctly I think, that you can find intellectual strands going back to Heraclitus and Plato which revolve around the idea of some "central force" or "law of history" that enables a thinker to predict the future. He says that the alternative and preferable society is a skeptical one that views history as a series of experiments and tries to infer what amount to rules of thumb rather than grand "world historical" theories or forces.

"East of Eden." Steinbeck draws beautiful vignettes of human life and emotion, and I think the book's main idea about human motivation is largely correct and explains a wide variety of behavior. It helped me see both myself and others with more clarity.

Seconded, this is a really excellent book.

I think that's a good example because it shows individual objects instead of curves on a graph, which for many people doesn't translate to reality.

I think that's exactly the issue. People can't picture it. You can show them a curve on a graph, but that doesn't translate for people without a mathematical/scientific background into "a shitload of people will get ill very quickly." Our brains seem not to be very well wired to make the connection between mathematical abstractions and reality, and aside from the minority of people who seem to just "get it," people don't understand without a good explanation from a very good teacher.

If there are two "mental tools" I wish we could teach every person, they are exponential growth and statistical thinking. Neither is intuitive, but they would help people understand this whole situation (and many others) a lot better.

You're right, this is really the deeper principle. I'm talking more "useful rules of thumb" as people are trying to build intuition for why passive voice might be useful. But at the end of the day it gives you more options about how to structure information. I think like a lot of tools it's easy to turn into a foot gun, so having some ideas about when and why it may be useful is good.

He also freely admits at the end of the essay that he's sure he committed many of the sins he's preaching against. I suspect he'd also freely admit that there are reasons to use the passive voice. But I think his primary complaints, especially his egregious examples of academic and political writing, were right on the money.

This is a great example of where to use the passive voice. Austen reverses the sentence structure to pack the punch at the end.

In general, 2 good principles are:

1. Put the punch at the end of a sentence.

2. Put familiar information at the beginning of a sentence and new information toward the end.

The passive voice can help you with both of these design goals.

Orwell talked about where the passive voice is most dangerous/bad. It mainly comes down to thoughtlessness or insincerity. The passive voice removes or hides the actor, so it's useful for people trying to cloak their beliefs or hide assumptions.

"Politics and the English Language" is a great read, as is the book "Style."

You'll find that even in the hard sciences, which are more objective many times over than the social sciences. Any complex field is going to generate controversy. That doesn't mean it isn't worth learning about.

That said, you should know why you're studying finance if you're going to spend the time on it. For me intellectual curiosity is a good enough motivator. It also helps me evaluate claims made by, for example, public officials. But I think it is reasonable to question whether it will significantly improve your personal financial situation.

"Money Stuff" is excellent. I also recommend the FT. Their Alphaville section is very good. One of my favorite classic Levine articles is "Regulators Want to Slow Runs on Derivatives."

Some other resources I came across via those and friends:

• "Other People's Money" by Kay

• "Zombie Banks"

• "The Money Problem"

• This NY Fed study of shadow banking: https://www.ft.com/content/1a222bf4-f33d-11df-a4fa-00144feab...

• "All the Devils are Here"

I saw this design on /r/security and thought it was a good idea:

https://news.ycombinator.com/item?id=22343786

It seems like if we want to solve this problem we need to somehow modify users' behavior by making them aware that indiscriminate browsing is a risk.

"The War of Art," if anyone needs a source.

My most recent team ran a version of XP, and I found IPM (iteration planning meeting) to be one of the most effective and important things we did. We had a very good back and forth with our Product Manager, with conversations usually going something like this:

PM: Let's go through our prioritized features. First we would like Feature A.

Team: That's probably easy, we can do it in a day or so.

PM: Great. Next we need Feature B. I know this one looks a little more complicated.

Team: Yeah, that's more like a week.

PM: That probably isn't worth it to me. We can probably push this feature back a couple releases, and maybe take out part of it.

Team: Would it help if we just did Part X? That seems like it would give you most of the value and it would be much easier.

And so on. The constant cost-benefit analysis, reprioritization, and rescoping was a great lever and made the team very productive.

The other 4 things, all related I think, that made us effective were:

• Everyone sitting together. I could go ask the designer or PM a clarifying question at any time.

• TDD. I would constantly start to write a test and realize that something didn't make sense—some assumptions were conflicting, or we needed to do another story before the one I was working, etc.

• Pairing. Many times I'd have written the test, had cleared my plan with the PM, and my pairing partner would point out a different perspective or catch one of the things I described above.

• Frequent releases, about quarterly at first and down to bi-weekly at one point.

In all cases, what we were really doing is optimizing the value of NOT doing things. We were helping the PM understand her costs, but we were also helping her eliminate huge chunks of wasteful work, e.g. building things users didn't want, things that didn't integrate well, and so on. Estimating was a piece of it, but it was really the buy-in from the business to accept our estimates and more importantly to trust us as partners in the scoping and planning process, and doing that process fluidly, that made us successful.

There is only one physical bookstore I go to anymore, and it's for exactly the same reason. The walls are positively stuffed with books. Nothing can beat Amazon for speedy search. If I know exactly what I want, that's where I'm going. But that feeling of browsing around and coming home with a bag full of books you'd never have thought of, or of hanging out in a community of readers, is not replicable online. I think both curation/browsing and creating hangouts (really good coffee or whatever) are ways physical stores can still compete.

Any of those frameworks that you endorse particularly?

As an addendum to this, I would frame the problem as "complexity," one aspect or symptom of which is requirements volatility.

Complexity comes from two sources in software projects. The first is the domain. As other commenters have pointed out, domain experts are usually half-aware of their domain requirements because much of the complexity has been buried under their expertise and intuition. Domain requirements also inherently change over time as markets, professional standards, and technology evolve. So the process of development involves a shifting discovery of new aspects of the domain as things which were unconscious become consciously learned.

The other aspect of complexity is the technology applied to the problem. Computer technology is inherently complex, and the imperfect mapping between domain problems and technology adds a third angle.

The best books I've seen for dealing with these problems are "Clean Architecture," "A Philosophy of Software Design," and "Principles of Product Development Flow." The first two explain how to build good systems that encapsulate complexity and are geared towards changeability. Such systems are flexible as new aspects of domain complexity are discovered over time. The latter book takes a higher level view of how to design projects to cope with the discovery process in a way that is economically viable and justifiable to the people financing projects, and also in a way that arranges work so that developers can actually be productive and not become swamped by the complexity problem or bad processes and practices.

It really isn't that surprising either. People want to write off the notion that some people are massively better than others at solving problems, but it's completely obvious that's the case. Of course there are insane outliers like Claude Shannon or John von Neumann, but those were real people that existed, and it stands to reason there are people at smaller multipliers who are still much better than average.

Sure, but what do you count as a "component"? It varies by language, framework, platform, and pattern.

Debatable but I get your point. The thing is that Flux is a pattern, and you often want to test the full pattern to get a meaningful "unit" of behavior/logic. There can be meaningful logic in the individual pieces, but frequently they only make sense as a whole.

Bounced around 2 projects in the last 12 months, one Angular and one React, that are using the Flux pattern. It is a real bitch to unit test anything but the individual pieces, which ends up being kind of meaningless.

This was my thought too. At least while they're getting ramped up, then maybe slowly let them go off and take pieces on their own.

The Bullet Journal book actually has a really good point about this, which is that you should be archiving this stuff to have the exact realization you just pointed out and then figure out how to adjust your behavior to focus on things that are actually meaningful to you.

I use a mix as well. I think plaintext lacks three qualities that are very important to me:

1. Discrete structure/form. Yes you can enforce this yourself, but it's not inherent to the system. This means it takes some additional layer of work to group and move items around (e.g. of trying to keep in a prioritized order).

2. Free-form drawing/diagramming.

3. A built-in notion of time.

All of these are very important to me. Being able to group and shuffle the order of discrete items like todos is very nice for categorizing and prioritizing. Arranging future concerns on the basis of time (I have hard-time, soft-time, and any-time sections of my lists) is important for forecasting. And being able to freely draw is really important for things like architecture and logic diagrams, or UI mockups, or anything abstract that has structure (like a graph or list).

Where text really does shine, IMO, is logging/journaling and capturing knowledge bases or project details. Being able to just dump that stuff somewhere in a stream of consciousness manner and search it later is very useful.

My personal system is to use a pocket-size Moleskine (soft cover) and Microsoft Office tools, which is nice because I run Linux but have to deal with Word and Excel junk all the time anyway. Excel is great for organizing tasks in a GTD-ish manner and moving items around in a discretely, Word is good for checklists and knowledge bases, OneNote is a solid journal, and Outlook is a good calendar for week-ahead type planning. They also all support photos, so I can snap pictures when I want to persist things from my physical notebook such as diagrams or ideas.

I really don't think there's a silver bullet when it comes to tools or systems, so you should start from a fine-grained understanding of your needs and work from there. But plaintext as a format has pros and cons like everything else.

I think we all just want something simple to clean up the giant, overwhelming mess of modern life, so we're primed to approve of anything that looks like a silver bullet.