My father was an electronic engineer, and I would love to get into it eventually as I grew up organising his components drawer, burning LEDs and licking solder wire (yeah.. I regret it now), but that's going to be something I'll have time for when I retire.
I think I can an extend a little into the non software realm, though my undergrad degree/ first jobs were in civil engineering. I migrated to computers and ended up going back to school for that.
I work writing software for biologists now, though my understanding of the underlying biology in that is shallow (Compared to my biologist coworkers)
Complex job, but a fun one! And crucially important for any product more complex than a dish washer.
But please, don't steal the name for some software "engineering" role...
In that sense the naming has been misappropriated in the SV tech circle to mean a "backend engineer that actually understands what is going on under the hood" sort of role.
My personal record is two characters of code per two weeks of work.
Embedded device kept crashing when initializing GUI rendering library (a precompiled one, STemWin IIRC). Two weeks of disassembly, instruction-level tracing of the MCU core narrowed it down to the contents of external RAM not being correct (that is- what was being read did not match what was being written).
Some more poking with oscilloscope, reading the datasheets and low level memory initialization revealed an incorrectly set RAM configuration register that was related to burst writes. RAM test during bringup used word-by-word writes, but when DMA was used only the first word in transaction was written correctly.
"I'm Winston Wolf. I solve problems." - which I stole as my tagline. No Acura NSX for me just yet.
Mine is approximately minus one instruction per week, and it was the best money the company ever spent. Hard real-time is hard. (It was a strange processor with, among other things, delay slots everywhere, so you could never make just one change without ripple effects.)
I just dabbled in embedded, once debugged an arduino I2C peripheral, went through the same process, but never fixed the problem :) I was easier to get a different peripheral.
It's sad but I'm pretty sure "types" like you all will be labeled "enemy of the state" soon... Oscilloscope ? Registers ?? ;)
That is, if things will keep going the way things are currently going - corporations, banning periodic tables from schools, elected stallers and clan mentality on all levels.
Pretty much yeah. I can relate to everything you write there. I always thought most of this is related to when I learned reverse engineering in high school. That's basically when I started understanding memory and why it mattered.
Unfortunately recruiters also don't understand the kind of profile, they just lump us in the group of "generalists" and say you need to specialize if you want to progress and yet in a lot of projects I often ended up understanding more about the details than the so called specialists.
I once had a client that I saved dozens of millions a year due to a fix that they had accepted as "just part of the system" only for the manager to fire me with a severance, because by fixing it I undermined his decision to scrap the project.
But very very frustrating for the world to work in such an anti-productive and nonsensical way.
I also wonder if you would have been fired anyways when the old system was scrapped.
I've heard that one before, so I'm going to agree. It's also inline with what the guy told me.
The system wasn't being scrapped they were just going to pay for almost triple the infrastructure. But yes, this was the first time I was exposed to performance reviews, I was as you said hired for something else entirely and it's possible that I would have been fired anyways since my job was actually about writing firmware and migration tools to migrate away from the old system(which also saved them a couple of millions a year). The performance review itself was however about tasks completely unrelated to what I got hired for.
I have done mostly contract work since then, but I am wondering if it is common to put your actual job content into your hiring documents to make sure people don't do performance reviews about unrelated tasks?
Honestly for contract work (and usually also full-time employees), the best thing you can do is focus on all the people who are responsible for your performance review and make them happy, make their initiatives look good, and get along with them so that they like you. Sometimes this means doing completely different work than you thought you were hired to do. Or doing all that in addition to what you were hired for.
The absolute worst case for a contractor is that you're "hired to fail" where there's a project with a 90% chance of failing so they bring in a contractor/team who either miraculously save it, or you're blamed for the expected failure. However, even here, if you show competence and make friends with the people who will stab you in the back in the short term, you may also find that some of them call for your services again in the future -- because you did "the job you were hired to do" and made it easy for them, made them look good, and were enjoyable to be around.
The written "rules" of the performance review don't matter, at least in the USA (maybe different in other countries). Performance reviews basically boil down to "how much do I like working with this person?" which definitely includes competence (people mildly dislike working with incompetent people), but also includes things like "makes my day happier" or "great conversation over beers / at the sports game".
I'm mid 30's and have worked a few contracting gigs but never really made it work out (usually it coincided with life being a little too chaotic at the time for me to fully focus on my client). So hopefully some others with more experience will chime in. But there's a lot written on this topic on HN, you can find a lot of experienced views from all sides of the table with a bit of searching!
Self deprecation and lauding aside, I’m curious what new titles others would propose? When I migrated into the field many moons ago, the two titles I saw mostly were “analysts” and “programmer”. The first had underpaid connotations, the second was rife with social awkwardness cues that Hollywood had run with for a while.
Historically known as or referred to as a "Renaissance Man" [1] or polymath [2].
Despite the terminological thefts and oversimplifications, I'm still proud to be a part of this industry. We're like the James Bonds of the digital world; we go by different names, but the substance of our work and our contributions are what truly define us. So, let them call us whatever they want... They may not always understand what we do, but they sure as hell need us to do it!
I'll cut a bit of slack to the frontend as it's also gotten significantly more complex over the last decade or so. I've seen places where frontend means "our iPhone app". Microsoft Office now has a version that runs in the browser.
Doesn't really bother me, although it does make evaluating what you might actually DO in a particular role challenging. In this "SRE" position am I writing Kubernetes operators in Go, or am I a Jenkins pipeline janitor, or am I working the graveyard shift in a data center swapping dead hard drives? WHO KNOWS!
After 17 years in this career, I dislike calling myself a "software engineer" because it's a meaningless term that now is used to describe anyone that knows how to build a web page. "Full-stack engineer" has also been stolen from us by recruiter to refer to frontend devs. WTF.
As a teenager I started doing software interfacing with hardware, reversing on Windows then I wrote my own mini OS, got a job and did web dev, sysadmin, backend, infrastructure, and CTO, alongside dozens of consulting contracts.
I get hired to fix a problem, and soon enough I'm diving into the technicalities of the network stack, or tracking down a bottleneck with spit and strace, or scaling an infrastructure horizontally and making it fault tolerant.
At this point most of the value I provide is not in the volume of code I deliver, but designing, operating and maintaining systems as a whole. A systems engineer, if you like, but as the article mentions, that's a real qualification that's got nothing to do with this.
The issues is that in the job market I have to compete with everyone called a software engineer, slap a senior to it, which these days refers to anyone that has 5 years of experience, and feel it's very hard to convey to a recruiter the depth of my experience. A programmer operates on code, a "systems engineer" looks at systems holistically, horizontally (i.e. architecture) and vertically (i.e. diving down the stack)