Hacker News Reader

> At this point most of the value I provide is not in the volume of code I deliver,

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.

> My personal record is two characters of code per two weeks of work.

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

Oh dear.

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.

> work ... embedded ... disassembly ... correct ... reading ... transaction ...

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.

Looking at the number of high school graduates passing physics exam each year in my country (around 250 out of ~12 thousand total high school graduates), I'm pretty sure corporations won't even have to break a sweat.

> "Full-stack engineer" has also been stolen from us by recruiter to refer to frontend devs. WTF.

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.

Classic principal-agent problem. Additionally I think you misunderstood who your employer was and what your job was!

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.

> Additionally I think you misunderstood who your employer was and what your job was!

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?

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

Amen to this. When I explain to full stack web devs that I do bare metal C, Python + Linux on edge nodes, server side processing, and native mobile apps they either say “you should AWS, we really like AWS” or “wow, so you’re like the real kind of full stack”.

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.

I've used the term "Deep Generalist" before. Broad knowledge, deep capabilities. You know enough to know what you need to learn and execute on demand.

Historically known as or referred to as a "Renaissance Man" [1] or polymath [2].

[1] https://en.wikipedia.org/wiki/Renaissance_Man

[2] https://en.wikipedia.org/wiki/Polymath

Hmmm... Maybe I'll marinate in something like PolyWareIst for a while :D

I find that the software industry is one of those industries where all role names are made up and change meaning all the time. As you said, just a few years ago (ok maybe a decade) a "Software Engineer" was a person who built Software, now it's a frontend developer that has a basic understanding of the backend.

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!

> just a few years ago (ok maybe a decade) a "Software Engineer" was a person who built Software, now it's a frontend developer that has a basic understanding of the backend.

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.

This is absolutely true, there is zero consistency in titles, levels, or their meaning across companies. I've been doing more or less the same stuff (if you zoom out enough) for more than 15 years. In that time I've been a System Administrator, Systems Engineer, DevOps Engineer, Cloud Engineer, Software Engineer. I haven't gotten SRE on the bingo card yet but it's one of the main titles I search for these days.

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!

Funny (I am not too serious about this point :D ), but I feel systems engineer is actually an engineer that has a multi-disciplinary skill set (mechanical, electronic, software etc) that guides a multi-disciplinary team to develop a complex product. Now it is repurposed for full-stack software engineers.

Is there anyone that can extend their knowledge to mechanical and electronic engineering, as well as software? I feel that my breadth in software knowledge is reaching the limits of my mental capacity and I have to shed useless weight now (i.e. I haven't kept up with frontend for 3 years now)

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.

You have a limited time to learn things. I learn for projects, that keeps my scope limited.

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)

Embedded software tends to need at least some EE knowledge, though how much will depend on the job. A tiny bit of ME knowledge also helps (consider thermal management, consider vibrations during shipping, consider vibration in use, etc). For robotics and mechatronics, ME knowledge becomes far more important.

I work close enough to systems engineering to have some insight: The good systems engineers are strong generalists, have one core competency with deep knowledge and expertice, good enough knowledge in related fields to understand and work with experts, and are generally good at engineering.

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

I think parent is refering to the fact that in a formal context (think large Aerospace systems), a Systems Engineer is the role that oversizes all interfaces mech/electric/software and makes sure there are no requirements misalignment.

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.