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