software-development VS eng-practices

The thought feels weird, but DHH is not the first one to utter it.

A recent HN submission [0] links to a post in a series about reducing development friction. I do recommend reading the whole thing, but one post is specifically about not using CI [1].

0 - https://news.ycombinator.com/item?id=38831991

1 - https://github.com/aaronjensen/software-development/blob/mas...

Totally agree that it has lost its meaning. We call things “incomplete work” that are, well, incomplete work.

https://github.com/aaronjensen/software-development/blob/mas...

sbellware may have more to add, but there isn't a name for it. We focus more on the "it" than the branding of it. We do use the word "continuity" to describe our goal: https://github.com/aaronjensen/software-development/blob/mas...

> The words "equipment log" and "work product" sound pretty unique.

We call them "material logs", as equipment logs are more or less a subset of those. Just think about the sheet in every bathroom at a store that says when it was last cleaned, or the clipboard attached to the factory machine that lists its maintenance record and problems. Or the patient record outside of the patient's door.

"work product" just means, the product of our work. Nothing special about that one, I don't think.

> Are Erl's SOA books and Yourdon's on OOP still relevant?

I haven't read either, personally, though I have Yourdon's book en route. We use the term "structural design" quite a bit, so I'm curious to see Yourdon's take on what they call "structured design". From everything I've read about it, it sounds very similar to a lot of how we think about things as it seems to be the basis for much of the coupling and cohesion thought in our industry.

I'd also recommend studying Lean (not Lean Startup, which has much to do with Lean as non-fat yogurt does).

There’s another way that feels totally unnatural at first, but puts the subject (the most important part) of the commit message first. It makes the commit about the change and the code, rather than the author. This is how we do it in all of our projects. I fought it at first, but I was wrong and it’s a lot better.

Example:

EntityStore build method records the specifier argument when given

Article about it: https://github.com/aaronjensen/software-development/blob/mas...

P.S. Learn more about how Google accelerates reviews here: Fast Review.

i think google's resource is really good in this topic: https://google.github.io/eng-practices/

For the last point, some places DO teach this, see https://github.com/google/eng-practices for an example. The other bullets have entire volumes of books written about them.

I think you get the idea. I've never worked anywhere in my 15 years that actually actually enforced high quality code, testing, and process. Google posts there engineering practices (https://google.github.io/eng-practices/) and if they follow what they preach Gmail is probably scrunched harder then the dialysis machine that I worked on.

There's an open source repo documenting advice for code reviews from the perspectives of both the coder and the reviewer: https://github.com/google/eng-practices

IMO most of the practical "research" I've seen comes in the form of best practices from Big Co. who a) hire very intelligent people and b) have extreme financial incentives to write the best code & have the best processes possible.

In a world where the dependent variable isn't something that can easily be measured in a lab, the next best we can do is either 1\ Ask experts or 2\ experiment in an environment where it's financially advisable to experiment & measure (AKA an environment where running an experiment with 100 engineers is <1% of your engineering headcount).

I.e. I don't work for Google, but I do share things like [0, 1] with new engineers who join my team.

[0] https://google.github.io/eng-practices/

This is a through explanation of how to do Code Reviews as the author and reviewer https://google.github.io/eng-practices/

Google's Engineering Practices