atheken

Brenden Eich:

https://en.wikipedia.org/wiki/Brendan_Eich?wprov=sfti1

Writing fast unit tests will require some refactoring that could end up being pretty extensive.

For example, you mentioned “cloud storage” - if this is not already behind an interface one ticket could be to define an interface for accessing “cloud storage” and make it so that it can be mocked for most tests and the concrete implementation can be tested directly to confirm the integration works. Try to hone down that interface so that it’s as few methods as possible, only allow the parameters you’re actually using to be exposed and used in the interface. You can add more later if it’s absolutely necessary.

Do this for anything that does I/O and/or is CPU intensive.

So, to do tickets, I’d basically say, one per refactoring.

Going forward, writing “unit tests” should not be separate tickets, it should be factored into the estimates for the original stories, and nothing should go out without appropriate tests. The operational burden will decrease over time.

QA should have their own unit for how they want to test the application. Usually this is a suite per section of the app. If your app has an API, that is probably going to have a nice logical breakdown of the different areas that could each have their own ticket for adding QA-level test suites. The tests that developers write should only be additive and reduce the workload of QA. What you want to be sure of is that change sets are getting reviewed and through the entire pipeline without getting logjammed in any stage. Ideally, individual PRs are getting started and deployed in less than a week.

If you’re interested in more techniques, check out the book “Working effectively with legacy code.” It has a lot of patterns for adding tests to existing codebases.

I don’t have “heroes” per say, but Anders Hejlsberg is up there.

Generations of programmers have benefited from his work. His focus on ergonomics in C# made the language a total powerhouse.

Just to be clear, that is not exclusive to “engineering,” as other professionals have similar legal requirements (doctors, lawyers, fiduciaries).

More generally, on a personal level, people are expected to act with integrity, and we have laws that provide them legal protections for whistleblowing.

The actual practice of engineering is about problem-solving within a set of constraints. Of course the solution should not harm the public, and there are plenty of circumstances where software is developed to that standard.

When a PE stamps a plan, they are asserting that they personally have reviewed the plan and process that created it and that it meets a standard for acceptable risk (not no risk!). That establishes the boundary of legal liability. In software, we generally do not have that process that fits in a legal framework, but that doesn’t mean that professional software engineers aren’t making those assessments for life-critical systems.

For other kinds of systems, understand that this is a new field and that it doesn’t have the bloody history that got “real engineering” to where it is today. A lot of the work product of most software engineers just don’t have stringent safety requirements, or we don’t understand the risks of certain product categories yet (and before you try to rebut that, remember that “building codes are written in blood” because people were applying technology before it was well-designed/understood).

Anyway, “engineering” is defined by a lot more than if you or your boss has a stamp (and in point of fact, there are plenty of engineers in the US that work as engineers without being a PE, or with any intention of ever having the stamp. Are they real engineers?)

You should do some research on wasm.

You can run frickin’ docker containers in the browser now.

I don’t make the rules.

Rebasing and merge conflicts are the top ways that git can turn into a mess. I know that rebasing could (in some circumstances) make merge conflicts less of an issue, but I just mostly think the value of "commit grooming" is overrated. I don't want to argue about this, if you like doing it, go ahead.

I’ve used the git cli exclusively for more than a decade, professionally. I guess it varies wildly by team, but CLIs are the only unambiguous way to communicate instructions, both for humans and computers. That being said, I still don’t mess around with rebase for anything, and I do use a gui diff tool for merge conflict resolution. Practically everything you need to do with git can be done with like 10 commands (I’m actually being generous here, including reset, stash, and tag).

Well, a couple things:

My points are related to provable advantages to doing it while writing code. They’re also not argumentative.

Your points are related to a personal preference of aesthetic while reading code. They are not provable advantages. They’re also quite “ranty,” which is rarely a persuasive way to convince someone of your position.

If you actually want to get people to change their habits around this, I think you’ll have better luck with my approach than ranting about why you don’t like how it looks.

Along with this, once you’ve dealt with enough kinds of problems, you end up developing an intuition for how something was probably implemented.

This can help you anticipate what features are probably included in a framework/library, as well as how likely they are to work efficiently/correctly (you know that XYZ is a hard problem vs. ABC which is pretty easy for a journeyman to get right.)

As an example, a friend of mine reported a performance issue to a 3rd-party vendor recently. Based on a little bit of information he had on data scale and changes the 3rd-party made to their query API, he basically could tell them that they probably didn’t have index coverage on the new fields that could be queried from the API. That’s with almost no knowledge of how the internals of their API were implemented, other than that they were using Postgres (and he was right, by the way).

That’s not always going to happen, but there are just a lot of common patterns with known limitations that you can start to anticipate stuff after awhile.

I would recommend email for this. It’s a text-based protocol and the original RFCs 821/822 are pretty straight-forward. There are some additional rabbit holes related to content encoding, but if one can implement a simple MTA, a huge amount of the magic of the internet becomes accessible.

I would not recommend trying to build a “production grade” MTA, as there is a lot of minutia to get right, and it’s easy to screw up.

I agree with the need, but not your rationale, I’m in the “always curly braces” camp for two reasons:

• when a second line gets added in a condition block, the braces might not get added, a bug.
• one less decision to make while coding. Anything that removes trivial decision-making can speed up authoring and reading code.

Not at all! Glad it was something simple!