<html><body><br />
On 31.05.23 18:22, James Cameron via linux-aus wrote:<br />> You can deepen this, using tools such as the source code, gdb, strace,<br />> valgrind, and tcpdump. Use them on top of how you use the programs.<br /><br />In a career in embedded systems, I only used gdb out of that lot. (But<br />perhaps should have used valgrind.) I did find Exuberant Ctags great for<br />navigating code. (Though it's no longer distributed with Vim)<br />Familiarity with a VCS is an asset. (It's all GIT now, so my CVS skills<br />are very Last Century.)<br /><br />When running teams, my first three rules were: Confirm that the code<br />repository backups work. Confirm that the code repository backups work.<br />Confirm that the code repository backups work.<br /><br />While working in the solution domain, problem domain awareness that<br />comes from understanding the hierarchical refinement of "What -> How",<br />descending from a Customer Specification, through a System Architecture<br />and Implementation Specification, down to module implementations, makes<br />a developer more able to work with minimal supervision. (Works best when<br />the project schedule includes module and subsystem tests prior to system<br />testing.) But that comes with experience.<br /><br />Incidentally, it appears that the Japanese Moon Lander crashed from 5 km<br />up, because management changed the landing zone, without rerunning the<br />simulation testing of the software. The new path sent it over a high<br />crater lip, the software then flagged (good) radar altimetry as bogus,<br />losing vital navigational feedback. The lower crater floor apparently<br />contributed to running out of fuel before touchdown.<br />The point?: Regression testing must include not only code changes.<br />(I never allowed any requirements change without an incremental<br />requirements analysis, a project delay and resource cost estimate, and a<br />meeting at which the proposed change could be withdrawn.)<br />The point?: Except for the first one, and one where requirements were<br />regularly changed due to the need for compatibility with an external<br />system, over 30 years the projects finished on time and on budget.<br /><div><br /></div><div>While managing teams, I had time to do some Solaris & Linux sysadmin, so<br />can understand the motivation to move from visible problems and<br />invisible successes to creative endeavour with demonstrable successes.</div><div>Good Luck!<br /></div></body></html>