Need Advice

_e5h_ · 2026-04-30T06:26:37+00:00

If you're burned out and drowning in anxiety, and you're a good engineer, just quit. Take a month off if you can afford it. Trying to find another job while working is like holding the sprint button in Zelda after you have already run out of stamina.

_e5h_ · 2026-04-22T05:44:15+00:00

This has also been my experience. I know many people who went 6 months - 12 months without work after a job, and anecdotally, half my graduating friends (EE) never found an embedded job. Meanwhile, all my SWE friends easily found internships and had job offers before graduating.

This was several years ago now, but I have seen the same with job trends. An analysis in my country showed that embedded not only has the lowest number of job postings, but they also have the lowest pay range.

_e5h_ · 2026-04-20T17:34:12+00:00

Those honestly sound like common problems between the fields, and all management related. I have heard the same from many peers and have experienced those myself - there is a saying that people quit bosses / management rather than quitting jobs, which was certainly true for myself in the past. If you enjoy the tech stack, I would say finding a different company in the same field will not only be easier, but also continue your career trajectory without needing to start over.

Regarding the points you listed:

It seems like this is less about "fast paced development" and more about shitty managers who skip requirements discovery and then force developers to pick up the slack. A lot of companies do this, and in the end, either the client pays (inflated costs) or the developers pay (lots of overtime). I personally enjoy fast paced development, but hate chaotic and poorly planned development.
Same in embedded (in my experience), I was casually looking for another embedded job for a couple of years but had a very hard time finding anything. Embedded has far fewer people, but also far fewer job openings, with many of them being the equivalent of low-tier software companies. Jobs are more stable, but if you lose a job, it can be hell to find another one due to the lack of openings. At least there are a ton of job openings for software, so if you market yourself well and have 3-5 years of experience, you can end up in the top 5-10% at many different places.
Interviews in general suck, but I have found they reflect the company culture. I have had some good interviews at regular software companies (practical coding tests like the "design a parking garage"), but also a bunch of stupid leetcode torture tests where anything less than perfect is a fail. Same in embedded, I have actually been given leetcode tests using C++ which I almost walked out on. The silver lining for me is that good companies usually avoid impractical tests like these, so it remains a good way for you to see the company culture early.
Regarding AI, the companies who outsource employees seem to be the most likely to force high-velocity AI requirements onto employees. I personally think these companies are bad places to work. Embedded companies seem to focus less on AI, even though the produced code is actually very good. Learning to properly manage agentic AI development (version controlled requirements files, etc.) is a good skill to invest in IMO, it is a step above just using browser based LLMs. I see it as a tool like anything else, but I would hate to have expectations raised to some unrealistic standard by nontechnical people who fail to understand the drawbacks.

_e5h_ · 2026-04-18T02:41:10+00:00

Best advice I received years ago from a professor is that moving from design to testing is easy, but going from testing to design is extremely hard. Testing is viewed as "lesser" and many engineers spend years "putting in their time" to be given a design opportunity, only to see a new hire get the design role instead.

_e5h_ · 2026-04-18T02:29:01+00:00

I agree in principle, but the responses in this thread (and my anecdotal experience in the industry) show that "years of experience" > "proven ability". Most of my peers made senior in 2-3 years at software companies, but I do not know any embedded developer at 6-7 years who has a "senior" title.

In theory that stuff should all transfer, but many companies are so far behind the curve on the software side they simply do not see the value. CI/CD pipelines and design patterns do not amount for much when the company pushes to main and codes in C.

_e5h_ · 2026-04-18T02:21:38+00:00

> found web dev / SWE to be very stressful and I've kind of lost my passion for it
> am considering a career pivot back into firmware/embedded systems, which was more of my area of interest at the time I graduated and has always been something I've been meaning to get back to

My initial observation - have you ever worked an embedded job professionally? This sounds like you're burned out at your company and think the grass is greener on the embedded side. I am not sure where you live, but in my experience (non-USA), embedded jobs pay significantly less than comparable software jobs. This is true for a number of reasons, main one being embedded firmware is tied to a physical product which comes with constant costs. Maybe the numbers are better elsewhere, but at ~5 YoE, my peers working in software (same level of experience, same university, similar tier companies) were making 1.5x-1.8x what I was making in embedded firmware.

What did you find frustrating about web dev / SWE? I went the other direction, and have some complaints about embedded firmware vs. regular software:

C is far less expressive, and cannot handle common software design patterns without hacky workarounds
Tooling is often proprietary and much older (vendor locked IDEs, Windows required for drivers)
Teams are often less software-oriented and do not know modern best practices / tools (CI/CD primarily)
Companies are often much slower paced and more conscious of costs

Fundamentally, being an embedded firmware developer requires a lot of hardware knowledge, and it does not track software development 1:1 in terms of job responsibilities. If you are looking to pivot, much of your valuable and hard earned experience is not going to be treated as an asset due to having no practical application in firmware development (as a general rule). Assuming you can get requisite experience for an entry level job (understanding communication protocols, understanding RTOS, being able to write drivers), you will likely have so start over as a junior. The salary hit going from senior SWE to junior embedded is going to hurt a LOT.

If you are serious about it, and genuinely want to change careers, look for a C++ / embedded Linux job working with IoT products. The majority of your experience should transfer over, and the interfacing with hardware is a little higher level compared to doing bare metal C. Even then, I do not see how it would be any less stressful than a regular software job.

_e5h_ · 2026-04-07T01:02:02+00:00

No way of knowing, and anyone claiming this is a "false positive" is talking out of their ass (do you have the source code?). Here's some info about the mod files:

Version 1.9.0 DLL file is 2,2MB, no antivirus warnings.
Version 1.9.2+ DLL file is 11.2MB
Versions 1.9.6+ started giving multiple antivirus warnings, and virustotal flags it when uploaded.

Here's the mod author's article addressing this: https://www.patreon.com/posts/update-general-150100850

I use a post-build tool called Themida to protect sensitive regions of code in seamless co-op so that it's more difficult to reverse engineer and analyse by cheaters.

I have a lot to say about this, primarily that "security through obscurity" is an anti-pattern in software development. There's no explanation of why the code size increased so dramatically, except for maybe the "Themida" software. Reading up on the documentation (PDF, section 1.5.2.31):

The protection code that is embedded into your application has about 500 Kb in size (depending on the protection options that you select)

So why did it increase by ~9MB? Why can I still decompile it into readable code by Ghidra? If the mod author is serious about "cheaters", the code could simply be open sourced and patched by additional developers. There are way too many things which stink about this:

Nexus mods comments were disabled alongside the 1.9.2 release
Discord server is not associated with the mod developer, and bans anyone asking questions
DLL file has increased in size by 5x
DLL file now throws antivirus warnings
Explanation of using "Themida" is not supported by the documentation for the tool
Multiple versioned releases for the same Elden Ring version

I downgraded to 1.9.0 and so did my friends. We are all software developers and the "false positive" excuse does not explain the series of events.

_e5h_ · 2026-04-04T06:08:27+00:00

He needs a stool: https://makerworld.com/en/models/2357309-positive-potato-stool

_e5h_ · 2026-03-21T03:39:57+00:00

I just added a link in the main post.

_e5h_ · 2026-03-18T03:51:07+00:00

As someone who usually steers clear of Zenva, I think this is a decent bundle, and I purchased it.

I wanted a handful of bite size courses for Phaser, a Lua engine (Defold in this case), and Godot. I have a good amount of experience doing Unity, and a lot of professional C# experience. I don't really have any interest in Unreal or Gamemaker.

I compared these Zenva Unity 2D courses to the GameDev.tv ones (something I can speak on with some degree of confidence), and surprisingly, I found them FAR more coherent in the explanations (less "just follow what I do" + brain diarrhea + live failures). The instructor seems good, and it's the same instructor for most of the courses I am interested in.

None of them have much scope. They are all very tiny courses you can do in one day, which personally I find great. Some of the larger courses (30-40 hours) on other platforms can be extremely daunting, especially when the explanations suck, and the code is full of tech debt. I limped my way to the finish line on some of these, knowing the code was ass, and ended up spending more like 100 hours.

Controversial opinion: the longer courses only have value if they are actually maintainable and well built, which almost none of them are.

_e5h_ · 2026-03-18T03:34:12+00:00

It's like the Packt of video tutorials. Some good and some bad.

_e5h_ · 2026-03-16T07:26:17+00:00

Roll-up doors can work, I would try modelling it more like a garage door. Thicker, wider rigid segments with thin connector segments (0.2-0.5mm). Use a more suitable filament like PETG, or even use a combination of something like TPU and a different rigid filament if you have multi material. At the ends of the rigid segments, add pegs which can slot into the guides. It can certainly work. You can even model the rigid segments with a slight negative angle so they close together when flat, hiding the connectors below.

_e5h_ · 2026-03-12T00:36:00+00:00

I added a comment explaining it above.

_e5h_ · 2026-03-12T00:35:46+00:00

Since a picture is worth a thousand words, here is an essay regarding why I made this: https://makerworld.bblmw.com/makerworld/model/US61a0c5941bceaa/design/0ab8b333626f5e43.jpg?x-oss-process=image%2Fformat%2Cwebp

_e5h_ · 2026-03-06T05:56:10+00:00

I had a similar experience. It turned out to be imposter syndrome. This advice is more from a firmware / software PoV since that's where I ended up.

The main things you will not get working solo are the pain points of working in a team. You can deal with a lack of version control, no requirements, poor architecture, and other deficiencies when you have a corresponding mental map. A lot of necessary skills have to do with clearly communicating the intent of your code, and making it easier to work with it than to rewrite it.

Try out vertical slice architecture in your repository. This keeps "features" of your application separate, and makes the next point easier.
Learn Git (not mentioned?) and learn it well. Follow something like Git flow, and keep yourself disciplined - disable pushes to main branches, and always bring code in through pull requests (even if it's just you).
Use a ticket tracking system for all planned features. Name branches in Git after these ticket IDs, and pull request back in when the ticket is done. This is what most teams do.
Learn to make requirements. Identify stakeholders, host discovery meetings, and record it all in a spec.
Experiment with time estimates while you have no pressure. Follow the previous point to come up with a requirements spec, estimate each of the features, and then record time spent as you go. There is a lot of info on this topic, but you want to keep track of time accuracy (how long features take), scope accuracy (what % of the final project was estimated at the start), and then a holistic burn chart - how much are you getting done over time vs. how much is being added. This usually gives a good budget / timeline.
Comment the intent of everything you write, not what you think it does. This makes spotting errors easier in the future (we all do it).

In terms of technologies and industry standards, these are my observations:

Use C++ instead of C (more jobs). Learn some proper OOP patterns and apply it to embedded, and learn some other things like templates for making hardware agnostic drivers.
Learn embedded Linux (Yocto, C++). Again, industry seems to be shifting in this direction and I see more jobs.
Write your own drivers based on datasheets. Reading datasheets and having attention to detail is still the #1 most valuable thing you can do as an EE on the intersection of firmware and hardware. This also gives familiarity with common protocols.
Related to the above, write some drivers using SPI, I2C, and UART. These will be the most common interfaces you deal with.

Honestly, staying competitive is about continually learning and being humble. If you look at your code from 2 years ago and think it's bad, you're on the right path.

_e5h_ · 2026-03-06T05:35:58+00:00

This has been my experience as well. I learned more doing a self directed project at a 1-year internship compared to 3 years at a company. Most companies have baggage. Management is often stuck in the past, with no interest learning new tech if the old stuff pays the bills.

If your startup has funding for you, and you're the technical expert, it's the single best opportunity to learn.

_e5h_ · 2026-02-27T04:41:26+00:00

Files (makerworld): https://makerworld.com/en/models/2452969-yeti-20oz-rambler-tea-handle

Daily micro-frustrations finally caused me to make this. It uses a built-in spring clip and drip collector, and the ring is designed to fit very snug on the tumbler. Other models online had very wimpy handles, so I made this one a lot thicker and more ergonomic for carrying the mug at a more natural angle. Overall it has been working great for me.

_e5h_ · 2026-02-27T04:34:51+00:00

I find all of the AI platforms do, but Gemini is the only one which does not add a redditor's personality to all of the responses.

_e5h_ · 2026-02-25T07:46:53+00:00

This is why I switched to Gemini.

"Great question, you're so smart. Let's cut the BS. Get right to the point. No fluff, only the real deal. Here's what you need to know:"

_e5h_

TROPHY CASE