The Hail lab meetings are fun, but I feel like there is a need for regular meetings where we can explore specific topics in more depth. I talked to Cotton about this, and he agreed, so I’ll try to get the ball rolling. I would like to gauge:
People’s willingness to add more weekly meetings to their schedule.
What topics have the most interest.
Some possible topics:
Learning C++
General software engineering best practices
Distributed computing
I’m currently most interested in the first two, and if there’s interest I would volunteer to organize them. I’m also very interested in learning more about distributed computing, but I don’t currently feel up to leading that discussion.
Most of us will probably need to learn at least some C++ in the near future, so I think there would be a lot of value in getting together to discuss. I also think this would be a good opportunity for us as a group to come to a preliminary consensus on things like code style, what tools to use like test frameworks, static analyzers, etc., and what libraries to use. Some of these things get harder to change as the established codebase grows, so it would be good to start the discussion early. Also, C++ is a huge language, and I think we’ll be much more productive learning it together rather than independently.
Similarly with software engineering practices, I think we would benefit from starting a discussion and beginning to form a consensus on what expectations we have for new code contributions. For one thing, I think code review would be more productive if we’re helping each other meet the goals we’ve previously agreed to together, and if we’re all on the same page about why those goals are worth the time and effort.
Please share whether you would be interested in participating in any of these groups, as well as suggestions for other topics.
Sounds like a good idea. I should probably do a session on “Practical C++” - it’s a big language with a lot of features, and my focus would be on when and how to use the useful features (and how not to shoot yourself in the foot with the more dangerous and confusing features).
And showing modern (C++11 and later) examples which make clear the correspondence to other object-oriented languages (but I need to learn a bit more Python to figure that out).
For test frameworks, there are a lot of choices - most recently
I’ve used the “hamlest” header-file-only test framework
for C++ code, see https://github.com/martinmoene/hamlest,
which is shockingly lightweight but quite powerful. You want to
make it really easy for people to write tests without having to learn
a complicated framework.
On code review, yes it’s good if everyone can get on the same page - and it’s often hard . I like to have these principles in mind:
a) Does this code work ?
b) Does it stop working for some inputs ? And if so, does it catch
those cases in some obvious way rather than giving incorrect
output ?
c) Is the project as whole better off by having this code committed
now/soon to replace whatever else is there currently ? If so, get
it committed and tidy up later …
d) Are there low-effort changes which would make it unambiguously
"better" in some ways (e.g. easier to understand; more consistent
with the group’s consensus style; more efficient; able to scale up
further) ?
e) … or does it need a substantial re-design/re-write ?
I think it’s quite important to explicitly avoid the question “Is this the way I would have written it ?” - because the answer is almost always no, and in a medium-size team you just can’t scale up if everyone is trying to guess the way the likely reviewers would write.
Another tricky question about code review is what happens when a code reviewer suggests a change, but the original author thinks the
change makes it worse. Does the author have the final say ? Or does it go to an arbitrator ? The worst of all worlds is for the disagreement to cause an indefinite deadlock …
I could also wave my hands about distributed systems if that would be useful - with a focus on the scale that’s likely to be relevant for Hail, i.e. enough nodes that you have to worry about 1 or more failing, but all at a single site so that you’re not trying to keep going when an asteroid takes out a datacenter
I think the next step is scheduling. Does anybody have feelings about blocks of time they want to protect from being invaded by meetings, or times that adding meetings wouldn’t be too disruptive? Should we just keep piling on Tuesday/Wednesday?
I feel like we should avoid having it back-to-back with Hail Lab Meeting, because too much new information at once won’t sink in. Otherwise, I’m pretty open; Tuesdays or Thursdays seem like good options.
. I like to have these principles in mind: