Systems Engineering, or "why james gets paid"
I work as a systems engineer, so it always tickles me to see the rare SE-related link make the front page of HN.<p>I think my org is pretty good at the informal SE process described in TFA. We used to be more strict about it, and I definitely remember hearing the term "model-based systems engineering" when I was interviewing, and after I started. Fancy UML generator tools, the works. But we've gradually become more informal and I don't particularly feel like we've lost anything in the process.<p>One thing we are bad at, though, is onboarding. We have some very basic first-day-type documents, to get newbies started on domain knowledge. But the standards we hold employees to and how our work is done on a daily basis... is pretty much not written down at all! (actually some of it may be, but scattered throughout Wiki pages, probably out of date, and definitely no central document with all the necessary links...)<p>Incidental to TFA, my org generally considers people (like James) who can do both the software work and the SE work unicorns. I personally started on the SE side with almost no software ability, but gradually clawed my way up to a decent level of technical competency, and it continues to be my competitive advantage. I don't code on a daily basis, but I do fix bugs & work on small features every once in a while. I dream about setting up a crash course to get my colleagues on the same path I took (currently I'll take a few hours here and there to help individuals pick up the skills)<p>Kind of curious what other peoples' experience is on this point. Is it normal in other orgs for SEs to not also be good coders?