Hacker News Reader

Long ago, I was hired as a "systems engineer." My boss described it loosely as a super-technician who doesn't fit into any of the traditional engineering disciplines such as electrical and mechanical. The unspoken expectation was that the traditional engineers would design the pieces, and then the systems engineer would be the one to get them all working together.

That was a lot of fun for a while, but it was pretty clear that I needed to get in front of projects, rather than behind them, to have any useful impact on new products. Also, I hit a couple of home runs: Creating the architectures for a couple of successful products because nobody else wanted to learn the theory. So I was invited to have a more front-end role.

This led to a new informal definition of "systems engineer." I've become the person who understands how products work in their entirety, when it requires synthesizing knowledge from multiple disciplines. I create and test the theory of operation. This is a good use for physicists in industry, by the way. Physics research, especially in small labs, is multidisciplinary. We don't really have any of our own techniques, so we constantly borrow from others. My graduate research involved optics, electronics, programming, mechanics, and data analysis. In fact, I've dropped the "systems engineer" title, and am now a "scientist."

Today, I'm at a level where I am much more focused on onboarding and development of junior colleagues. I'm also finding and developing talent within the organization for people who might like to have more of a systems role. It is a hard role to fill, because engineers tend to specialize -- perhaps for good reason based on job markets. And if traditional engineers get good enough at coding to do it for money, they get sucked up by the software industry.

> This led to a new informal definition of "systems engineer." I've become the person who understands how products work in their entirety, when it requires synthesizing knowledge from multiple disciplines. I create and test the theory of operation.

How is that an informal definition of it? It's almost identical to the Wikipedia description of it:

> Systems engineering focuses on analyzing and eliciting customer needs and required functionality early in the development cycle, documenting requirements, then proceeding with design synthesis and system validation while considering the complete problem, the system lifecycle.

Damn, that sounds like an extremely cool career. Have you written about it in more detail before? Would love to hear more specifics (as allowable) about your path.

What you describe sounds like a dream career for me! Would it be possible to have a chat with you on what sort of a path led you towards it?

I see you have no contact info on your bio, but you can find mine in my bio.

Author here!

Definitely started as a software engineer, but in a safety critical field (avionics), at a company/team that in my opinion has an incredible "systems culture" (Garmin Avionics). During onboarding, we were taught WHY we needed to do so many things for the safety critical process.

After leaving safety critical, and going to much more start-uppy companies, and realizing that SE knowledge was not widespread, and how to put the "easy but good bits" in place quickly, is pretty much how I ended up where I am.

I started out writing software after graduating with a EE degree. For 5-10 years, I wrote software and led some small teams. I then transitioned to being a SW SE, working with project SEs to allocate system requirements to software, writing software development plan, and software test procedures. The final 20 years of my career, I became an SE and principal SE, doing the whole SE dance. During that entire time, I still wrote software for testing purposes, simulations, and algorithm development. Am I a good coder? I think so. Although the development teams use C++ and Python, I'm fine with C and Python. And even though my code could be considered to be "throw away", I try and use a common methodology for developing it.

BTW, I like the term "unicorn". I'd never heard it in this context before.

> 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.

This is exactly my experience. I'm SE since i finished my school. I always feel frustrated by the SE global vision. Some projects do allow me to go toward more technical stuff (sysadmin, network, dev, signal processing, CAD...) and it's quite enjoyable.

I've also started with no SW skill, but i've learn and it has been a great help in my daily job. My SE collegues only do the SE part and don't want to deal or see the more technical parts. In the end, i'm always offered to work on new projects because of this ability to switch from global vision to technical stuff, but in my org, this is not really encouraged nor rewarded.

Where do you sit in the organization? How do you "get ahead of projects"?

Im a Systems Engineer by title, but have no idea where my place is (its all confusing). I'm basically an 'super IC' on a team - and try to play with other groups my group interacts with... So there is no power to set the design. Basically just answer 'will this work with your part of the system'?

I basically end up just finding issues, POC end-to-end (well outside of my discipline: I'm a HW guy to I'll do a FW to Cloud security thing).. and well, why business does the HW Systems person have suggesting we use PKI for authentication?

I'm a "software systems engineer." I write a lot of code for various projects (I'm good at it), operate a spacecraft, do some sysadmining, and am leading a citizen science project. I'm not really sure what my title means. Sometimes I write software specs or list requirements. I've read a few definitions of SSE but as far as I can tell, it's not a well-defined discipline like mechanical engineering, philosophy, music theory, or geochemistry (my PhD). Shrug. I guess it's reassuring to see that lots of people have questions about what systems engineering is supposed to be exactly... I was worried I was missing something.

I work at a large 'mechatronics' company, where software is just one discipline - we basically have engineers from any discipline you can think of, but mechanical engineers are our bread and butter.

Systems engineering is a huge thing for us, so every single project involves one or more systems engineers. This is a more senior role - the systems engineers usually start out in a specific discipline, and once they have more experience they become systems engineers.

So for us, no, most SE's aren't particularly good coders, but every SE is good in some discipline. We staff projects with systems engineers based on their specific strengths.

Perhaps one thing lost with moving to informal approaches is that documentation loses fidelity, and therefore review-ability is compromised.

There's no better way to find out how bad your documentation is than having a new hire go through it. I always assume that the docs are out of date as soon as the ink is dry if not sooner, but the ones working there just keep the processes going with the intent to go back and update the docs "as soon as it slows down".