Project install should be one command. That's probably going to mean a script. Local setup options should be handled by either taking a config (with an example

Project install should be one command. That's probably going to mean a script. Local setup options should be handled by either taking a config (with an example provided) or interactively. This doesn't count the commands to download the archive/clone the repo/etc, but that should be one step anyway. Building, both artifacts and tests, should be single commands. That might mean you need to write a script that does the "cd into a directory, cmake .., make, make install" dance, but it should be handled. Dependencies should work, should not conflict with system dependencies, and should be fetched if not already present. Hi Python! Good IDE support: IntelliJ has some great features, I'd like to use their stuff. But some people want to use other IDEs or editors. Maintain project files for common ones. Self-contained PRs. Keeping PRs small is all well and good, but having PR A depend on PR B and C and D getting merged in the right order makes review much harder than if they were all just stuck in one. Must work on Linux, Windows and Mac, at least. Preferably also some BSDs. Documentation, with all of the following: An introduction saying what your project does, tutorials on how to do intended tasks, how-to guides on solving detailed issues, explanations with examples of how things are used, and a comprehensive reference of what can be done. Divio has a good article[1] about this, though it misses the need for an introduction while providing one itself. Strong types, with good type inference. Dynamic typing is nice for scripts, but not for full-on programming. Good safety around memory issues. GC or Rust-style ownership based will depend on application, of course. Interoperability with different languages. Especially an issue is building multi-language projects. As an embedded dev, the hardware should be debuggable. Provide a damn JTAG or SWD port. Provide a GDB server or OpenOCD plugin. Provide test points, and a dev board with a damn schematic! Have your datasheet actually describe the function of the chip and how to communicate with it. LTC (now owned by Analog Devices) datasheets tend to be great examples, try to be like LTC/AD. For example, see the LTC4015 datasheet[2]. It provides example application circuits, clear pin configurations, detailed typical performance info, a nice detailed block diagram, I2C protocol info (because that's chip specific), functional descriptive text, equations to calculate the needed supporting component values, operational state flow charts, detailed component selection procedures, PCB layout considerations, a full register map, and a recommended solder pad layout. Too many datasheets lack too much of this info. [1] https://documentation.divio.com/ https://documentation.divio.com/ [2] https://www.analog.com/media/en/technical-documentation/data-sheets/4015fb.pdf https://www.analog.com/media/en/technical-documentation/data...