Feeling Stuck as a Solo Electronics Engineer – Looking for Guidance - Page 1
Forum section: electronics / general

author: conducteur
author_rank: Regular Contributor
timestamp: July 05, 2025, 07:39:03 pm
content: I'm an electronics engineer working in a small company (SME) in Belgium. I hold a Master's degree in electronics engineering (which is legally required here to officially call yourself an engineer). At my current job, I’m the only one with more than just basic electronics knowledge, so I’m responsible for everything from schematic design and PCB layout to firmware development, testing, and production support.To be clear: I genuinely like my job. The work is varied and interesting, the people are great, and the company is close to home, which is a huge plus. I started here just a few months ago, after working for four years at a larger company. I left that role due to economic reasons, but even there I wasn’t really involved in advanced electronics or product development. Now, I’m highly motivated to grow in this role and improve my skills. That said, I often feel stuck, not because of the company, but because I don’t have anyone around to learn from.There are no senior engineers or even technical peers I can ask for feedback. I don’t have anyone who can review my designs, challenge my assumptions, or guide me toward better practices. So even though I have professional experience, I’m only now doing full product-level design, and I’m doing it solo.I find myself falling back on familiar tools and platforms, even when they may not be the best choice. For example, I still tend to use 8-bit PIC microcontrollers. They work, I know the toolchain, and I can usually get something functional pretty quickly. But I’m fully aware of their limitations: no FPU, slow or avoided floating-point math, and having to write code that works in millivolts instead of volts, just to keep everything in integers. This adds complexity and messiness to what should be straightforward tasks.In my most recent design, I actually used floating-point operations to get the required accuarcy of my calculations. I ended up squeezing it into the device, but just barely, the memory usage was right at the edge, and I know I was lucky it fit at all. That kind of experience reminds me that I’m using these chips outside their sweet spot, but I still fall back on them because they’re predictable, and I know how to get them working without major surprises.I’ve used more powerful MCUs like the NXP LPC1768 mbed module during university programming courses. I got firmware running, worked with the online IDE, and experimented with the available peripherals. But I never took it further, I didn’t implement it in a real product, design a custom PCB around it, or integrate it into a commercial system. That gap in experience still holds me back today. I’m reasonably comfortable programming such devices in a learning environment, but I’ve never gone through the full process of selecting one for a real design, building hardware around it, and debugging everything from start to finish. And the truth is, I’m afraid that if I did try to use a more advanced MCU in a real project, I could easily end up in a situation where something doesn’t work, and I simply wouldn’t know how to fix it, or where to turn for help. That lack of support makes me avoid the risk altogether. So instead, I keep falling back on the 8-bit PICs I know, not because they’re ideal, but because I learned how to use them, and I can usually get them to work without getting stuck.Software development is another area where I feel underdeveloped. I know C++ and Python, and I can get things working, but I was never taught how to build a clean, maintainable, or testable codebase. I understand the syntax, but I don’t know how to structure firmware in a modular way. . Refactoring is something I avoid unless absolutely necessary, because I’m never sure what will break. It feels like I can write individual sentences, but not full chapters, let alone a book.On the hardware side, I’ve started designing 4-layer PCBs. And they work. But I have no real way to validate the quality of the layout. I try to follow best practices, ground planes, decoupling, trace width, return paths, but I’ve never had a board reviewed by a more experienced engineer. So while my boards function, I don’t know if they’re robust. I often wonder whether they work because of my design, or in spite of it.What frustrates me the most is that I feel like I’m doing moderately advanced work, but I’m not sure I’m doing it right. I want to grow, but I don’t want to make reckless mistakes. I want to explore better tools and practices, but I’m afraid of breaking something critical and not being able to fix it. And I don’t have a colleague I can turn to for help if things go wrong.At the same time, I’m not looking to leave this job. I’m happy here, and I want to grow within this role. That’s why I’m reaching out here, hoping to hear from others who’ve been in a similar position. Have you ever worked solo as an engineer, without mentorship or peer review? How did you keep improving? How did you build confidence in your work? How did you validate your designs, both hardware and firmware? Are there books, courses, tools, or habits that really helped you level up?Even just hearing from others who’ve been through this would be helpful. I’d really appreciate any advice, encouragement, or resources you might be willing to share.I think my biggest fear is that the technology around me keeps evolving, but my own skills and knowledge are only improving very slowly, if at all.Thanks for reading, and thanks in advance if you reply.

author: tggzzz
author_rank: Super Contributor
timestamp: July 05, 2025, 08:48:22 pm
content: Welcome to the real world; you are not aloneThere are several more or less independent threads in your post, which deserve to be treated independently.You are feeling isolated, with nobody to guide or challenge you. Join a professional society (e.g. The IET or IEEE) go to their events, take part in he local organisation, and ask them for a mentor.You continue to use the same devices and tools. That's not a bad thing (and is even good) in the short/medium term but might be limiting in the long term. Get hold of a different device and do something with it in a personal project - and push it so hard that you do "fail" in some way. Determine whether its capabilities could expand the scope of whatever you are doing at work.Explore something non-technical, such as project management/estimating or sales/marketing. Find out how they shape/influence technical decisions. Maybe those will help the leap into more advanced MCUs.Writing software... Find out about Design Patterns and Architectural Patterns, and how to chose which ones do/don't fit with your work. Keep an eye out for real-time patterns in particular, e.g. FSMs and event driven systems, queues and mailboxes, communicating sequential processes.Learn two significantly different languages, and understandwhythey are different, their differentphilosophies, and the advantages/disadvantages they bring. I suggest Rust and Erlang for embedded/server applications. Applying some of the concepts might help your current systems. As for C++,veryfew people understand it - and that includes the people designing it. Test yourself (and others!) withhttps://yosefk.com/c++fqa/and weepA personal experience of dubious relevance to you...After 3 good years in my first job, it moved to a different location. I had two choices: stay on the same site in a boring job, or go to the new site where the job might be much better but the travel was intolerable. I remembered the Bene Gesserit concept that "the easy path leads always downward to stagnation", and chose the high risk high reward option on the grounds that could not avoid making a difficult decision: move house (if job excellent) or change company (if job OK).At the same time I knew the key long term question I needed to answer was whether I wanted to stay technical or move into project management or sales/marketing.Since the job on the other side turned out to be merely OK, I found a company where I would be technical but would dabble in sales and project management (a contract R&D company, Cambridge Consultants). Excellent choice, and over time I decided to stay technical.ItThat was an example of thinking not only about my next step, but also how that step would help the step after that. It ensured I wasn't closing doors that I might want to go through in the future.So, overall you are in a normal position, and are actively thinking of how to improve. Good startNow you have to decide what is the most importantquestion. It will then become apparent either what the answer is, or what you need to do to find the answer.Good luck

author: KE5FX
author_rank: Super Contributor
timestamp: July 05, 2025, 09:08:57 pm
content: Quote from: conducteur on July 05, 2025, 07:39:03 pmNothing wrong with 8-bit MCUs, I love AVRs. If they're cost-effective, keep using them, and if anybody gives you grief, tell them where to go. (PICs, though?)Don't reinvent things... in fact, go as far out of your way as possible to avoid reinventing things. Study existing designs. There are so many! That's what eval boards and demo/training boards are for! Every major CPU, every FPGA family, every advanced mixed-signal component has demo boards that (usually) embody best practices for using those devices.If you think you might want to use something new at work, but find it intimidating to approach, try a hobby project with it first.Get comfortable working with LLMs, but don't waste time with anything that's not on the leading edge. Learn what they are good at, what they are not good at, and keep abreast of progress in the field. Disregard those who advise otherwise.

author: nctnico
author_rank: Super Contributor
timestamp: July 05, 2025, 09:10:31 pm
content: Been there as well. It can be lonely but nowadays help is nearby through fora. Also going to manufacturer seminars is an easy way to get in touch with fellow engineers and learn about new/different parts. Key is though to select parts based on their merit and fitness for your purpose, not what is appearantly popular.It could be an option to hire a senior consultant for a couple of hours every now and then just to bounce ideas back & forth.

author: Kasper
author_rank: Frequent Contributor
timestamp: July 06, 2025, 12:39:04 am
content: Quote from: nctnico on July 05, 2025, 09:10:31 pmI second this. I'm often on my own and found this arrangement worked well for everyone.Didn't take much time for consultant to provide a lot of valuable knowledge. Was great opportunity for me to learn and helped my employer get senior quality work on intermediate budget.What OP is saying sounds perfectly reasonable. If your employer is decent, they'll appreciate your desire to find the best solution and they'll understand that "career advancement" or "learning opportunities" is an important part of compensation.More recently I'm on the other end of this. Now I get called by my old employer to review work and to help troubleshoot when they are stuck. I still get imposter syndrome, they are smart guys and more familair with it than I am. If they are stuck, how am I going to figure it out!? I feel pressure, driving out there, having them pay for hotel and my relatively high wage and not knowing how I'll solve it.My fears are always unwarranted. We always figure it out and suprisingly quickly. Just be open when you dont understand something, warn them about technical risks ahead of time. Break it down into manageable pieces and solve them one by one then put them together. If one piece is stubborn, use other people, app notes, forums, dev kits, test boards and in worst case, your soldering iron. If none of that works, replace that piece with a different solution.I'd tell my boss: I can probably squeeze that through with my usual method but I'd rather try a more advanced solution. I'm not really familiar with it, can we hire a consultant here and there to point me in the right direction? This investment now will pay later. It will increase our capabilities and reduce the time I spend trying to squeeze things into our old tech.

author: temperance
author_rank: Super Contributor
timestamp: July 06, 2025, 03:08:37 am
content: QuoteI have exactly the same problem, and I'm still looking around for a proper solution. I bought some books on embedded systems but most of them start with how to connect an LED to a GPIO and extremely long explanations about what a register is and things like that. Those books present simple projects where a super loop is all you need. The other end of the spectrum are books about RTOS's. I haven't seen a book explaining methods to develop complex systems such that they are also testable and maintainable.This might help:https://refactoring.guru/design-patterns

author: WattsThat
author_rank: Frequent Contributor
timestamp: July 06, 2025, 03:09:22 am
content: One caveat about consultants: The good ones are worth everything they get paid. Anything less is akin to the consultant using your watch to tell you the time. Choose wisely, personal recommendations are always best. This also reinforces the getting out to seminars and industry events to stay current with your personal connections.

author: m98
author_rank: Frequent Contributor
timestamp: July 06, 2025, 10:07:19 pm
content: Quote from: tggzzz on July 05, 2025, 08:48:22 pmFun fact, I recently ran into someone at a conference who suddenly got very apprehensive for the fear that I could be an employee of Cambridge Consultants, who apparently have stolen some key technology of his company...A good way to improve your skills is to join a club that has members who are experienced engineers to work with them on projects. Not sure what to recommend in Belgium, your local variant of the CCC seems to be a wee bit radical, but have a look at hackerspaces, or even university racing or space teams.

author: nctnico
author_rank: Super Contributor
timestamp: July 06, 2025, 10:20:34 pm
content: Quote from: temperance on July 06, 2025, 03:08:37 am'Making embedded systems' by Elecia White seems like a good book to me to get started. The book focusses on ARM controllers (more precisely NXP's LPC1700 series) which I would highly recommend switching to. Being able to simply use floating point (even when simulated) and having lots of processing power makes writing code a lot easier and thus saves time & money.

author: tggzzz
author_rank: Super Contributor
timestamp: July 06, 2025, 10:23:51 pm
content: Quote from: m98 on July 06, 2025, 10:07:19 pmI never heard of any such thing, but I left 40 years agoOTOH, everybody in Cambridge was aware of what everybody else was doing in general. Ideas and concepts were readily discussed, as you would expect in a university environment. That does not imply secrets were shared or divulged.OTthirdH, at one company I did find someone was thinking that a competitor was standing on the footpath outside, trying to find what was going on. Complete and obvious nonsense, probably related to being under a mental strain.QuoteIn my limited experience Hackspaces are mostly about experienced amateurs guiding people with zero experience, and learning together. There will be exceptions, of course.

author: temperance
author_rank: Super Contributor
timestamp: July 07, 2025, 01:40:12 am
content: QuoteI found this book somewhereBut I think you didn't read what I wrote. This is yet another book starting from the very basics. It starts with how to read schematics. That part is not the problem part for me and I do know in detail what's going on in a microcontroller.The problem part is putting code together in a maintainable and testable way. Let's say a system with 4 UARTS, 1 Ethernet port, a user interface with some buttons and a TFT screen, some GPIO's, some ADC/DAC channels... You need 4 or 5 communication protocols, some state machines to handle user input, some state machines to handle GPIO's,...In short, for every part of such a system, you need state machines and one or more state machine to implement the device functionality. How do companies develop such a system with a team? You must split the system into blocks and developers must be able to work independent, and they must be able to test and maintain their code without relying on other pieces of code.I found this some time ago:https://www.state-machine.com/

author: EEVblog
author_rank: Unknown
timestamp: July 07, 2025, 05:38:14 am
content: Quote from: conducteur on July 05, 2025, 07:39:03 pmYep, been there as the only electronics engineer in a division of the company (not the whole company, so technically I did have some other EE's in the building I could at least hang out with occasionally).But yeah, same thing, no one to bounce ideas off, no design review meetings, you feel like you are working on your own hobby project, but with a deadline from managers who don't know or care about the technical details.It's tough, very easy to fall into a rut of a cozy job.Likewise I used PIC's, but when a new project came along, just for kicks mostly I went for a Rabbit 2000 processor I saw an ad for because it seemed to have what I wanted, and an integrated RTOS I thought sounded cool.I'd hassle management and HR a lot about using the training budget to send me on course like VHDL, CID+ PCB layout certification etc, just the break the monotony.Basically, I don't think you can force yourself to "improve" in this sort of environment. The only real option seems to be to move jobs, and I regret not doing that more in my career. I just ended up being content in the same cozy design role. The only thing that really saved me was that the company got bought out 4 times so I kinda got shuffled around every 3-4 years.

author: nctnico
author_rank: Super Contributor
timestamp: July 07, 2025, 02:13:39 pm
content: Quote from: temperance on July 07, 2025, 01:40:12 amThat is actually quite simple: make modules with defined interfaces. Each module is a seperate process talking to the hardware (or a thin driver layer) and whatever is on top. Different engineers make different modules and at some point you try integrating everything. How the modules deal with sharing the processor (as in a non-blocking super-loop or having an RTOS doing time slicing) is something the design team agrees upon in advance. Testing can be done indepedantly on hardware or on a PC.

author: temperance
author_rank: Super Contributor
timestamp: July 07, 2025, 03:38:07 pm
content: QuoteThat's what already wrote. The hard part is connecting all those together in a sensible way.Books on the subject come in two flavours:Books for beginers. The super loop, simple projects.Advanced books: RTOS's from simple introductions to very complex.There are many ways to do this, and super loops and RTOS's are certainly not the only method. If you look at some wiki pages on this topic you can spend a few weeks (or maybe months) checking out all possible and impossible ways to implement Interrupt-controlled system, cooperative multitaskers, preemptive multitasking, or hybrids of some sort... and study source code of various projects. I can't say I find this easy.

author: nctnico
author_rank: Super Contributor
timestamp: July 07, 2025, 05:16:38 pm
content: It depends on where you are going from. A better approach is to get the requirements for a specific project clear (including taking into account timeline, budget and the team member's abilities) and go from there. It is much easier to select the best option from a very limited set of choices bounded by the constraints of the project at hand. And really avoid adhering to dogmas like not using floating point, not using printf, keeping interrupt service routines short, etc as you'll be throwing away good options to choose from. BTW, a good mental model of the interrupt controller is to treat it as a timeslicing OS in hardware where the interrupt service routines are processes.

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: July 07, 2025, 06:05:05 pm
content: Quote from: conducteur on July 05, 2025, 07:39:03 pmThe best part is often the one you know. The effort in learning a complete new ecosystem to use a cheaper part is only worthwhile if you're doing large enough quantities to offset the cost of your time against savings in parts.If you're comfortable with PIC8, then I strongly suggest you look at the PIC32 range - same tools, same programmers, more speed, more memory, most peripherals are the same or a superset which default to the same behaviour as the smaller parts. Some even available in DIP, most have a choice of between 2 to 4 packages as well as multiple pin-count & size variants.PIC32MM for low-cost, PIC32MX1xx for mi-range, and plenty of others up to PIC32MZ parts running 200MHz with FPUs. Apart from some differences in the config fuse settings, you can write code that's pretty much the same as for PIC8, just more and faster.Having said that it can seem daunting to move to a completely different device family, especially after using the same thing for a long time, but it's usually less of a deal than you first think - the principles are pretty much the same, most of it is getting used to new tools, device quirks, datasheet styles etc.Floating point is rarely a good choice for embedded systems which have an inherently limited range of values as they've usually come from ADCs etc. - Using FP just because you don't want to use mV is not really a good reason. FP gives you range, not precision, and a scaled integer will have less precision than an FP of the same size.QuoteIn engineering there is rarely "right" or "wrong", only more or less applicable to a particular requirement.QuoteAn answer to that may be to get an external consultant to do a 1-off design review. This would be good insurance, and you'll probably learn some useful things in the process

author: nctnico
author_rank: Super Contributor
timestamp: July 07, 2025, 07:22:27 pm
content: Quote from: mikeselectricstuff on July 07, 2025, 06:05:05 pmActually it is a very good reason. Especially when dealing with a multitude of units, it makes code much easier to write and maintain when you can use base units (like Volt, Ampere, Pascal, bar, etc) for calculations instead of using oddly scaled (fixed point integer) variants. And there can be added complexity like using several calibration factors (like 2nd order approximations) to correct / linearise sensor readings. Been there, done that. I have been using oddly scaled integers for a long time but I came to the conclusion I was jumping through lots of hoops without gaining anything so nowadays I'm simply using floating point.

author: tggzzz
author_rank: Super Contributor
timestamp: July 07, 2025, 09:37:29 pm
content: Once upon a time languages had integers, floating point, and fixed point variables.https://en.m.wikipedia.org/wiki/Fixed-point_arithmetic#Computer_language_supportNowadays fixed point is frequently found in FPGA and DSP code.

author: temperance
author_rank: Super Contributor
timestamp: July 07, 2025, 09:41:28 pm
content: QuoteCompanies must use specific frameworks to build scalable and maintainable embedded systems. Otherwise, they will be out of business pretty soon. There are quite a lot of companies out there and blogs advocating certain principles and structures to build maintainable software. They exist because many companies often create spaghetti like systems because they get stuck in dysfunctional structures. I'm sure not the only one questioning how to do things properly. To use floating point numbers or not is a different subject.To give you a better idea about what I'm after:But maybe I'm just to stupid to understand the easy part about how embedded system firmware is developed on a professional level. I know what interrupts are and how they behave, and I don't have any problem manipulating an ARM interrupt controller.

author: EEVblog
author_rank: Unknown
timestamp: July 08, 2025, 12:17:09 am
content: Quote from: mikeselectricstuff on July 07, 2025, 06:05:05 pmYes, the Microchip tools make it practically trivial to use any part from the PIC8 to their latest highest power PIC64

author: Njk
author_rank: Frequent Contributor
timestamp: July 08, 2025, 02:45:50 pm
content: Quote from: EEVblog on July 07, 2025, 05:38:14 amSilicon Labs was our official HW partner. In my understanding, such deals are not only about the price discount but also includes some kind of engineering support. With every project, I had to travel to Silabs HQ for design review purposes. It was never my initiative. Obviously, the reasons were political:1. If a service is paid, it must be consumed. Otherwise, we'll be looking stupidly.2. We don't know what exactly this guy is doing, we're not a technical people and we don't trust him. Before investing in the production, let his design be reviewed and approved by someone who can be made accountable in a case of subsequent failure.One time, I've found how to make two incompatible parts to communicate adding a simple glue logic, reducing the BOM cost substantially. Silabs liked it and placed a reference to the design on their web site.But the main problem with that operation style is that the success is limited by your imagination and performance. It's hard to invent something new enough to position you ahead of competitors. Another challenge is to come up with a plan that will satisfy all the stakeholders and your personal acceptance criteria. There was a period, about a year, when I was really scratching my head about the next project. That's not simple. It's like a single bandit can be easy to repel, but a gang is another matter. Advertising, marketing, social influencing, etc. (up to using the military), with the only purpose to force the client to buy a product which is of little actual need. A collective effort, similar to what gipsy women are doing. This is how it works now.

author: conducteur
author_rank: Regular Contributor
timestamp: July 09, 2025, 08:18:50 am
content: Quote from: EEVblog on July 08, 2025, 12:17:09 amThanks for the advice from everyone here. Yeah, that's one part i maybe need to dive into.We’re in a very niche market, and component or dev time cost isn’t scrutinized like it is in high-volume consumer products. The limiting factor is mostly my time, as i do a lot more than developping electronics....The consultant is an idea I will propose here certainly.