- Elsa Gonsiorowski, LLNL
- Mark Miller, LLNL
- Machael Garland, nVidia
- Jared O'Neal, ANL
- Wyatt Spear, U of OR
- Hal Finkel, ANL
- good to have some people focused on each aspect
- short-term results, while important, you need to keep an eye out for the long term.
- productivity: how much effort does it take to achieve your goal?
- goals are always evolving, each person has different goals
- problem comes when goals are in conflict
- hard to normalize wrt to different goals
- how do individuals measure productivity?
- is self assessment (without quantification) enough?
- frustration / emotional state is a big indicator about productivity
- teams need to learn from the macro failure of 'wasted' effort
- as long as an individual learns during the process, maybe
- Is the "wasted" work the only way you could have reached the conclusion that this was the wrong approach?
- how can we reduce the "wasted" effort next time around?
- is there a de-brief that not only looks at what lead to the failure, but then communicates this to others
- you know it when you see it
- inefficient -> duplication of effort
- matching individual skills to the right problems
- resources aligned to the problem
- example: how to get the team to write documentation?
- one person would start writing the documentation, then hand it off to a second person to take it over and own it.
- useful to build documentation with other people
- paired programming / paired documentation
- interpersonal challenge, both people need to get credit for the end result, both the documenter and the 'original coder'
- what are the incentive structures at the management level? can you change those to the get the behavior that you want?
- project manager & system engineer roles with opposite incentives.
- project manager: deliver on time
- system engineer: deliver a quality product
- in DOE, these roles might be handled by the same person. maybe it should be more explicit, so that people can think clearly about what needs to be done.
- customer interaction vs technical writing
- align with what people like to do
- are tools helping you, or getting in the way?
- wait for the community to reach critical mass on a tool before personally investing in it
- good news for tool developers, keep running sessions and getting the word out
- it may depend on the type of tool that management
- forced to use a macbook
- management can make tools available: atlassian suite, make it easier to use
- need 'fresh blood' people who know whats out there, and can bring it in to the internal work
- CI testing
- getting teams used to using that
- making it easier to learn / documentation
- how long can you use the resources?
- which tests exercise the code that was changed?
- and this needs to be automated, not chosen by a human
- spack for system administrators
- CI with spack does has some technical challenges
- tools that are otherwise available, working on HPC systems
- identify where the gap is small, but the benefit would be large
- recognize the problems
- have good community education in place
- can we do requirements gathering, before jumping in to technical solutions, esp. if we are solving a problem as a community and each side has their tool to evangelize
- requirements gathering is a super import part of the process
- common file format? each lab had a different experience, but then had vastly different requirements
- have an objective 3rd party to bring everyone to the table and find the common ground
- 3rd party owning the result, not any one lab
- community branding, not just any individual lab
- allow people doing the work the ability to collaborate, without the branding discussion