Ask HN: How I get a job that uses C? | Hacker News Reader

Ask HN: How I get a job that uses C?

79 pointsspeeder118 comments

My wife is pregnant and I need a job urgently... and like when I needed a job urgently in the past to pay student loans, I feel inclined to accept whatever offer I get.

But what I really wanted was work with C. But even searching for that is hard (often a company writes C/C++ and they mean only C++ and not C at all).

I tried in the past seeing if embedded would work but even entry positions require experience.

So no idea where to look for such jobs.

The vacancies list I found right now is just a long list of full stack, frontend, backend, sometimes java, the occasional SQL, nosql, and sometimes python or ruby. Not a single C job.

Where the C users are hiding? Is living programming in C even possible or it became a purely hobby language for people doing angular.js on their day jobs?

View on HN

>Is living programming in C even possible or it became a purely hobby language for people doing angular.js on their day jobs?

C is still widely used. I think if you really want to just work with C you should focus on embedded stuff, surely not every job in embedded requires experience.

One industry which is quite C heavy is aerospace. You do not need to work for Boeing/Airbus though, there are many, many suppliers who are doing embedded work.

I second this comment - aerospace and adjacent industries have a ton of embedded C work for all levels of experience. As others have mentioned, I would expect the automotive industry to be very similar, but I don't have any personal experience there. Good luck!

Just putting my experience out there, across the space/aerospace industry I've seen a lot of C++ and Ada, but not much actual "C".

I work for a car OEM.

We are mostly using C++. C skills do come in handy for the existing body of software in systems such as Linux, but we very rarely write new code in C.

I am a big fan of C, for all its faults, it's the language I have by far the most experience in, I have read multiple standard revisions multiple times at this point and regularly advise people on their understanding of the standard and how to write C.

I would absolutely hate working in embedded (if it runs linux it's not the kind of embedded I'm talking about) for a salary. Nobody treats C with any care or respect in those areas. Either that or the language is written like a legal document. If you like C because you've played around with it, understand the abstract machine and can write it safely working with a modern standard, don't expect embedded development to be ANYTHING like that.

I am not sure what you are trying to say here. It comes off as you trying to discourage people from entering Embedded Development which is absolutely wrong.

Anybody who is interested in learning/using C/C++ SHOULD absolutely look into Embedded Programming. That is where the "rubber meets the road" and gives you the intellectual satisfaction of learning/understanding "everything" (i.e. HW & SW). Embedded Development encompasses a broad spectrum from Application programming (eg. Apps in a Network WiFi Router), Kernel/Device Driver programming (eg. RTOS/Linux in the same Network WiFi Router) to bare-metal programming (eg. 8-bit etc. MCUs). So one really gets to know how to use C/C++ (the Good, the Bad and the Ugly) as the situation demands to solve a problem. All the standards are merely guides to follow (i.e. not commandments from above) which is only deviated from when needed.

It's strange to see the juxtaposition of the urgency + the major career leap... I don't want to tell you how to live your life, but if it were me I'd take the job I can get for right now, and look around for my dream job while employed

If you were miserable at your last job (not explicitly stated, but reading between the lines) there might be a middle-ground job that you can get easily, and may not be the ideal you're holding out for, but at least won't make you miserable. It can be a gradual transition to better pastures instead of a single huge leap

The problem I am having is exactly my whole career I am taking "whatever is available right now", and now I am getting not only very unhappy with this, but getting further and further from the careers paths that I would want.

People assume I want to "switch to C", thing is, I learned C first, coded C at home for years, and use C whenever I can on my jobs...

But because of the constant urgency I keep having to accept whatever jobs I find, and learn whatever they want me to learn.

Because of this I know C, C++, C#, Java, ASM, a little of Kotlin, Obj-C, a little of Python, a little of JS, etc... but what I love to do is systems design and programming, and I strongly dislike mobile. Yet, every single job in my career is mobile.

People now assume I am a mobile person and keep offering me more of these jobs, but I am not even particularly good at them, because in my free time I don't want to learn more about iOS or Android, I want to learn more about other things and end learning the other things.

I know how C++ RTTI work intimately, know how it looks in ASM, practiced how to make C code that fits in the L1 cache, I know the story of RDTSC and why it causes crashes in many older games...

Yet, all my job interviews involved Mobile, or Web. I don't care for those, specially web. My dream job involves figuring out if I can make some formula when doing a math operation that can be executed with SIMD and fit the cache, not figuring out how much I have to convince Java GC to cooperate and not pause during user interaction or figuring out why a web page is rendering 3 pixels off.

If i may offer a few suggestions;

* Given your current family obligations, Take any job you get in any field you are offered. Putting Food on the table and taking care of your Family are the primary non-negotiable needs.

* You wanting to work in C/C++ are wants which you pursue on the side to develop expertise in and then make a switch to when you get the right opportunity. This thread already has a lot of actionable good suggestions for you.

* Since you already are a "Mobile/Web App" person, go down the Software Stack in the same domain to scratch your C/C++ itch and become an "Expert". As an example for Android go through Roger Ye's books; 1) Embedded Programming with Android: Bringing Up an Android System from Scratch and 2) Android System Programming: Porting, customizing, and debugging Android HAL.

I understand the frustration, I guess I'm just wondering why it's not an option to shop around while already employed, even if it's (temporarily) at a job you don't really like?

I've had jobs I really hated- I quit one once without anything lined up because it was dragging my whole life down. I get that. But in my experience the things that make a job intolerable are uncommon. It wasn't too hard to leave a job that was intolerable and find an adjacent one that was at least tolerable. Maybe your experience has been different

I'm just wondering if it has to be all-or-nothing in the short term; whether you could find a tolerable one that pays the bills and leaves you time to really hunt for that dream job

The company I used to work decided that my position wasn't appropriate for remote anymore. I am still working and will still get some more money, but need while still working find fast a new job... (moving is not possible, since I am in Brazil, and the office where my former job will be done from, is in Asia, they will just hire someone local to them).

Gotcha, I see. My perspective may not have been sensitive to the geographical constraints. Wishing you the best of luck

C programmers are systems / embedded programmers.

I made my living doing C when I worked on Samba + Illumos.

Really, if it isn't systems or embedded, C is very rare, even for someone like me with 20+ years of it, I won't code in C unless it is really the "language of choice" for the problem. And that ain't often.

That said... I do write some C time to time, still.

This is far from a majority, but a lot of folks are still using C or an orthodox variant of C++ in the gamedev industry.

Many APIs, like Vulkan or OpenGL are using pure C.

All the current major game engines are C++. C hasn't been widely used since the Quake 3 days.

While yes the Vulkan & OpenGL APIs are pure C, that's very, very little of what you actually code against. You very quickly abstract that or use a middleware like bgfx or whatever. In the case of Vulkan while the spec API is C, there's first-class C++ wrappers/bindings provided as well: https://github.com/KhronosGroup/Vulkan-Hpp

And other than Vulkan & OpenGL, you'll find that most other APIs/libraries in the space are C++, not C. Valve's libraries are C++. Dear ImGui is C++. Bullet & PhysX are C++. Microsoft's glTF SDK is C++. etc...

You can argue endlessly about how "true C++" those all are or if they're just "C with namespaces" but that's largely irrelevant - they aren't C and they need a C++ compiler.

Sure.

bgfx and imgui are very close to C in practice.

This is not very common practice but a few small to medium size studios are using C only.

TheMachinery was pure C.

My own engine is built in C with C/C++/Zig APIs.

Yes and "systems" includes drivers, which is mostly hardware drivers but can also be eg Windows antivirus or filesystem filters.

Personally I find that kind of work very frustrating, and the limitations of C makes it worse.

> ... and the limitations of C makes it worse.

That's somewhat ironic considering that C is one of the few languages which can do literally anything, from the lowest-level direct memory access to the highest-level abstractions. It's the language many other languages are implemented in, so it can demonstrably do anything they can do.

The same could be said of writing x86 machine code directly in the binary format: it's the language every other language eventually executes in, so it can demonstrably do anything they can do.

Obviously C is a much better programming language for human use than x86, but the mere fact that a high-level language can be implemented in a low-level language is not evidence that the low-level language has no limitations. The limitations live in meatspace, between keyboard and chair, but they're very real.

No it can't. There's loads of stuff C can't do, which is why inline assembly & compiler intrinsics are quite common in the space.

Otherwise you're basically just saying C is Turing-complete. Which, yeah, so are most languages. That's not actually a special property.

Not exactly though, turing complete means the language can compute anything, not do anything. In the vast majority of popular programming languages, it is generally not possible to write bare-metal device drivers, for instance.

It's not possible to do that in pure C, either, though. You need at least some assembly to speak to the hardware, which you then make C bindings for to do the rest in C. But any language with an FFI can pull the same stunt for the most part, to varying degrees of difficulty. But there's no shortage of toy kernels written in dozens of different languages - C is very much not required or unique here.

I'm confused by the mixing of abstractions going on here. Technically it's not possible to do anything in any programming language without assembly. But barring that, it is absolutely possible to write bare-metal device drivers without any assembly, because most systems use memory-mapped IO and C can directly reference and dereference that memory.

And then, if an FFI is required do to X, can you really say it's possible to do an X in your language? C/C++/unsafe Rust or another language that can directly reference memory still ends up being required in that end.

memory-mapped IO is available from a ton of languages, and in C you still have to use an "FFI" as part of this to actually establish the memory map.

Using only the C language, you cannot make a device driver. Full stop. You must use an FFI / inline assembly to establish critical pieces of it. And if you're allowing that for C, then you necessarily need to allow that for all languages. Thus, C isn't very unique here. C's lack of anything resembling safety makes it "good" at working with things like device drivers, sure. But it's not actually that unique of a property, shared by quite a number of AOT'd languages. C++, Rust, Go, D, Zig, etc... heck, even Haskell ( https://tommd.wordpress.com/2009/09/13/kernel-modules-in-has... all can be used in this role.

C's prevalence in the kernel space is arguably more to do with legacy & inertia than actually being a good fit for it. See for example all the undefined behavior suddenly making kernel devs scream and wail endlessly.

Right now Handmade Seattle is happening and has job booths specifically target low level programming, check out some of those companies https://handmade-seattle.com/

It sounds like you're exclusively looking at 'webdev' jobs, where, yeah, approximately nobody uses C.

Try embedded. Never had a directly embedded programming job myself, but see a lot of it from recruiters 'C/C++' as you say, but in embedded my adjacent experience is that there's not a lot of C++, that's more likely to be the tooling than the firmware or whatever itself. (Binary size & stdlib issues I believe, or perhaps merely dogmatic assertion that that's the case.) Not to say it can't be & is never used of course, it can be and is.

I'm an embedded dev and yeah, I can confirm that it's mostly C. And the "C++" I often encounter is pretty much just C with a couple of C++ things thrown in like std::vector.

I agree that embedded is a good choice if you're looking for C.

Automotive, aerospace, industrial control/signals, and systems programming/engineering still lean heavily towards C (and C++). The ratio between the two will vary widely by individual company and domain.

Companies that make a lot of embedded products still use C extensively.

I can guarantee Garmin uses plenty of C, and continues to make new software libraries in C.

Having close-up experience with Garmin, just no. It's called Monkey C for a reason, and we're close to the point where even bluetooth wins over ANT+.

> I tried in the past seeing if embedded would work but even entry positions require experience.

Apply for those jobs anyway. Requirements are often flexible.

Upvoted; Everybody should follow this advice for everything.

For some reason people don't even take the first step of applying for a job they want/like just because it lists "X years of experience needed". This is never ever a hard requirement. Most companies try to over provision or are completely clueless about their needs. So don't doubt your abilities, be clear about where you stand and what you want and finally be willing to negotiate both on Salary and Position to get/do what you want.

Hi!

I got a job as an embedded C programmer after a MSc in "High Performance Computing". Weirdly the biggest supercomputers can use similar techniques to tiny microprocessors.

First of all I get why you like C, I loved learning it, and think it is a really elegant language (with obvious flaws).

I have some practical advice. Embedded is your best bet for getting to use C professionally. Are you into electronics at all? I would recommend getting some microprocessor/electronics kits, like the Arduino ones. If money is tight, Arduino clones are very cheap indeed. You could get going for < $20. You'll need a "bread board" some wires and a microcontroller. I remember getting a _very_ cheap oscilloscope kit too. You can make some cool stuff with sensors etc. I recommend any video by Ben Eater, if you want to know more about digital electronics. If you come up with a cool project idea you can write a blog post or even just talk about it in a cover letter. It would show you are very keen, even if you don't have professional experience.

You could also learn more about low level computing stuff by doing the excellent "nand-to-tetris" course, which shows you how to build a CPU. This is quite a commitment, and not essential, but I enjoyed it a lot!

Embedded Linux is also very widely used, so a project with a Raspberry Pi would look good too.

Good luck with a child on the way! Perhaps any electronics kits you buy could have a second life in 10-15 years...

>I would recommend getting some microprocessor/electronics kits, like the Arduino ones. If money is tight, Arduino clones are very cheap indeed. You could get going for < $20. You'll need a "bread board" some wires and a microcontroller. I remember getting a _very_ cheap oscilloscope kit too. You can make some cool stuff with sensors etc.

That stuff seems really cool, but as an embedded software engineer who never spent any time learning the ins-and-outs of hardware, it isn't strictly required. Especially if one needs a job quickly, learning C/C++ is difficult enough. Though I'm aware that excludes certain microcontroller-based embedded positions.

We say "c++" not scare off applicants; but, it's really c/asm/machine-code. Interview at c++ shops & ask how they manage lifetimes in their codebase.

> ask how they manage lifetimes in their codebase.

What do you mean by lifetimes?

Assuming they mean memory lifetimes (i.e. are they using pointers? smart pointers from STL? their own in-house solution?)

C++ codebases can anything from literal "C with some classes" to C++20-style practically-functional

Have you written any C at all? This post sort of reads like you don't know what you are asking for... C is a lot of fun, I don't want to discourage you, but if you don't have any experience with it the odds that you are going to be able to get a job in it are low. C is a high-risk high-reward language and writing programs in it competently requires a lot of patience and practice. It isn't shocking that even entry-level positions would want you to already know quite a bit about it.

Speaking from my own experience (and this is a route that might work for you if you are sure you wanna do this): At a previous employer, I worked as a C# developer at a transitioned into a C/C++ role when there was an opening on that team. I didn't do it because I wanted to learn C specifically, but that was one of the appealing things about the opportunity. (I also had already written some C in college, though that was years ago.) So looking for an organization that does C and other stuff and starting in the other stuff might be a valid way to go.

That said, the company only took a chance on me because I was already fully competent in the organization's domain and I had proven myself in a less challenging position; they believed I could learn. It was a huge learning curve for me and it took several months for me to get up to speed and be useful as a pure C developer, and this was with more experienced developers mentoring me every day. I am still nowhere near being a C expert; I am just good enough to be useful. (I also no longer work with it day-to-day, because I'm not at that company anymore, though I miss it sometimes.)

Honestly, it sounds like you should focus on your family first and your C aspirations at home or as a hobby. Think about how this ends: If you get into a position using C, and find it hard or just decide it isn't for you, do you really wanna be worried about losing your job or doing badly at it while dealing with your new baby?

You are spot on with this comment.

I've done misc small/medium sized software at various times, first in Uni to implement a compiler, later programming Nintendo DS and Wii homebrew using DevKitArm and DevKitPro.

Some days ago I started designing/implementing a system for "password sharing" and thought of writing at least part of it in C: I want to be able to get a password from say, KeePass2Android, then encrypt it with some OTP key (seeded from a preshared key), then generate a sound with it (say using DTMF like tones) and send it through the phone's speaker.

The C app would monitor the sound (microphone, maybe through SDL library), detect a specific tone/wave as the "start" of the message, decodify the message, obtain the string of the encrypted message and decrypted with the OTP key.

Finally, the C app (via xdotool ) would type the password as a keyboard.

I wanted to do this as an easy way to use my phone as my password manager for my computer. I started to write the C part of the application, SDL I've done before, I read a bit about Fourier Transforms and the libraries I'll have to use. In the end doing it in C is going to be a tremendous task, given that in languages like Python there's a lot of stuff already solved.

I love C and its heritage... but I really wouldn't think in starting a serious project in it at this point it time.

Most embedded jobs use C, some C++. But if you’re good at programming you should be able to pick any language fairly quickly tbh so I’d just tailor my CV according to whatever language is in their job spec.

Embedded, firmware, systems jobs all tend to use C. So using those terms to widen your job search may help.

Here's a personal anecdote: my father is an engineer at a small, 8-person company. He's 68. They use two languages: C and Java. The short story is, they created a system for telco companies in late 90s. Said system deals directly with specific Telco hardware and needs to run real-time fast. The system is over 20 years old and despite this or that patch over the years its core remains the same. So there's a C part, which is the engine and is really performant, and a Java part, admin tooling, testing and integration.

So I guess if I had to find companies with C jobs I would try: - niche jobs/industries - small companies - decades old systems

The problem is that those aren't usually on the mainstream channels for job searching, and they may take years to open a single position.

Do you have a CS or EE degree? Are you based in the US? Are you willing to move within the US if so? Then you should be able to get an entry level embedded job with C, but yes you might have to learn or use some C++ as well. Embedded devices aren't as limited as they used to be so it's become common to have a full version of Linux hosting even real-time systems that were formerly bare metal or sitting on a minimal OS and written in C. With that change, C++ has started to enter the field more.

Look into the aerospace and defense industry in the US for a large contingent of C systems. Though greenfield ones may not be C anymore, there's a lot of C code out there needing maintenance too as they move to new hardware or add features.

I don't know of a single embedded C++ employer who'd would turn someone who understands C fundamentals (e.g. stack/heap memory, the preprocessor, concurrency/semaphores, etc) for a junior development role. A lot of C++ features aren't used in embedded systems, like the STL.

I have been happily working in telecom for ~3 years now developing in C and I actually got the job without any prior experience.

However, prior to working there I did my Master thesis at the company, which enabled me to show commitment and learn a lot about their product. As you might have realized, this also makes me quite new to the job market, so take my advice with a grain of salt for these reasons.

Furthermore, I can't guarantee telecom is a good place to look for C work. We are the only section of our company with a purely C codebase from what I know.

But I still wanted to comment and suggest that Low level Networking might be a good option to look at. A good search term might be places that use DPDK.

If you really want to write C just do it--most popular languages have a defined way to interface with C code, and if not you can almost always find a way to communicate with a C program via stdin/out. You can always justify to your teammates/bosses on "performance reasons" and they'll probably think you know some deep magic. (In practice most interpreters have gotten fast enough that it can be difficult to come out ahead after the overhead of going through an interface layer, but they might not know that.)

Plenty of C jobs around, most are where there's a need for extreme performance (optimising usage/making the best of limited RAM/limited CPU), talking to bare metal or for things that have to last a long time (kernels, telecoms, other critical stuff).

There is less turnover though (stability again) so employers are selective (and quieter). One suggestion would be put C as your preferred language on your CV, with a little background why (not if you want to work with BigCo or anywhere with a buzzword-driven culture though).

Operating systems, especially kernel.

yeah, this is OP's endgame.. the only c jobs that pay big FAANG bucks are:

- Apple

- Microsoft

- Google (linux kernel)

- Amazon (they have some embedded teams)

- Facebook (some Android teams)

- Tesla

- Uber

I think most of those companies require relevant experience before they'll look at someone's resume, though..

Curious, what would Uber be using C for in the first place? Doesn't seem like any of their use cases would really require it nor would it be the first choice?

I'm just guessing based on the self-driving research, could be wrong there

+1 vote for the Linux kernel!

Bonus points because it's C99

In addition to those specialties already mentioned, I'd add older databases and storage systems. Some quite large, quite critical codebases that do still need maintenance in their original language. There are also some organizations, e.g. Linux Foundation, with specific initiatives to support "critical infrastructure" code which is often in C.

Vulnerability research jobs often involve some use of C if it's low level enough, either to write proof-of-concept exploits, or doing code review (e.g. Linux kernel), or both. Perhaps an option if you also have an interest in this area? Though you will likely need to know assembler too, probably for multiple architectures.

I think if you’re interesting in C you’re just going to have to deal with also working with C++.

When I started out I was looking for the same thing in the embedded space but there wasn’t any jobs strictly using C.

The “best” you could find out there is old code base is in C, new code is in C++. Which there are good reasons for.

Eh. My mileage has varied. Fitbit's embedded systems were all written in C, without a single bit of C++.

you can totally avoid c++. I've stuck to pure C (and better post c++) languages for 30 years

I would assume that's made much easier by having 20+ years of experience. OP is looking for entry-level positions

You will find jobs in embedded and games.

But embedded pays 40% less then frontend/backend.

Games pay good, but is stressful and demanding.

Anything with embedded/real-time software.

Believe it or not this is still a very large part of the industry.

I understand this isn't the answer to your question but given what you've disclosed I'll have to advise against limiting yourself to embedded jobs alone. A job isn't the only way to follow your passion, in fact it may cause you to hate your passion over time. Find the most in demand skill that is somewhat interesting to you and focus on that. To follow your passion buy a cheap embedded linux board and hack away in your free time. I was in the same boat as you but now I've come to realize most jobs in tech are interesting to me, so I might as well focus on the ones that are most in demand. Just keep an open mind. Edit: Typo

What is it about C that you want to work with it so badly, despite having no experience with it? It's a great language for what it does, but the difficulty level for avoiding bad decisions is so high that I would be very hesitant to hire someone with no track record to operate solely in C.

I'd have been inclined to say embedded would be essentially your only option, but without some experience and/or an EE background, you'll have a very hard time finding your feet in that world.

> without some experience and/or an EE background, you'll have a very hard time

Yep. We hire embedded people to write C (some of the time) but the critical qualification isn't C experience or even general programming skill. It's knowing what a multimeter, oscilloscope, and logic/protocol analyzer are and not being afraid to use them.

100% this!

When i started learning Embedded Systems (lots of C/C++ Programming experience but without an Electronics background) it was understanding the needed Electronics and how to interface/debug the Hardware-Software interface where i had the most difficulty.

I found the following helpful in my education and hopefully people with a Software-only background who want to get into Embedded Systems will also find these useful;

* Designing Embedded Hardware by John Catsoulis - Very good introduction to relevant practical Electronics without drowning you in nitty-gritty details.

* Patterns for Time-Triggered Embedded Systems by Michael Pont (free pdf available at his company SafeTTy website) - Full of C code showing how to interface to hardware and do stuff.

* Practical Electronics for Inventors by Paul Scherz, Simon Monk - Reference for when you need more Electronics knowledge.

* Understanding Signals with the PropScope from the company Parallax (search for free pdfs online) - Practical lab book showing how to use PropScope(a USB based Oscilloscope) to study Signals on circuits built using the Parallax BASIC Stamp MCU board. You can use any other MCU/Oscilloscope combination (eg. Arduino with Analog Discovery 2 aka AD2) to build the same circuits and do the lessons. Digilent also has a lot of lessons on using the AD2 at its website.

* Introduction to Embedded Systems: Using Microcontrollers and the MSP430 by Manuel Jimenez et al. - Excellent and nicely illustrated textbook to learn Embedded Systems from. The MSP430 MCU is used as a case study but everything is presented in a general way.

Are pure software jobs really that uncommon in the embedded world?

There's plenty of people who know how to write software. Not as many who know how to use an oscilloscope.

As far as the skill-gap, its a lot easier to train an EE signals dude to use C programming, than to teach a C programmer how to use an oscilloscope or otherwise do circuit theory.

For us it's less about the circuit theory stuff and more about the mindset needed to deal with first-spin brand-new totally-raw hardware. Anyone who's not comfortable checking up on the hardware will not be successful here. Training that kind of attitude is impossible, so you've got to filter for it somehow.

Fair.

In my experience, embedded work really isn't about C programming at all, and is more about understanding the device drivers / manuals. You _happen_ to be programming in C, but the real skillset is reading CPU-manuals or device manuals.

Its not "void foobar(int blah){}" that's hard to write. Its knowing how many cycles IO-pin B needs to be held low for.

Just a hobbyist here with ATMega328pb stuff and various 8052 stuff + some college-level student training. Not really a professional at this. But I figure the pros do similar kinds of work. And its really not the CPU-manuals that are hard (CPU manuals are often written clearly and relatively concisely). Its the various I2C boards and SPI boards that don't always function correctly that's the issue... and struggling through some incomplete / poorly written docs on that matter. (But you got like 10 spare parts you can experiment / blow up with. So its just a matter of playing with the darn thing until it works...)

-------

Asking for a C programmer would be like asking for a journalist who has "English Writing experience". Like... yeah, that's... expected. But that's not what you ask for. The skills they need are far beyond "just" C programming.

"CPU manuals are often written clearly and relatively concisely"

Not always haha. I've seen manuals for some very widely used ARM SoCs that are just a few hundred pages of registers with poorly translated, one sentence descriptions.

> Just a hobbyist here with ATMega328pb stuff and various 8052 stuff ... (CPU manuals are often written clearly and relatively concisely)

The manuals for CPUs that are frequently used by hobbyists are written clearly and concisely (decoding the causality to be left as an exercise for the reader). For many of the others (including a quorum of those priced for use at scale), you'd be lucky to get a document that's been machine-translated from x-ese, with an errata roughly the same size.

Exactly. If you're a nice, high-level developer, you probably think that GDB (or similar) sucks in comparison. You'd be wrong, but trust me, it's a hell of a lot better than the debugger for reality, which really sucks.

A lot of embedded C code looks like (to take some from an esoteric project I can share)

    void eurotherm902s_set_xs( unsigned int xs,  struct sp_port* port_choice )
    //Set the extension status word
    {
        char buf[8];
        assert( xs <= 0xFFFF );
        sprintf( buf, "XS>%04x", xs & 0xFFB7 );
        bvt3000_send_command( buf ,port_choice);
    }

This is not interesting, nor is it intelligent, nor is it (arguably) safe. It is, however, fast and functional and directly talks to the hardware. The difficulty in doing this isn't understanding what is going on in the code. It's in working out what the <bleep> is actually happening if you see the right blips on a logic analyser and nothing comes out the other end -- and that often touches on physics as well as EE and computing. I personally really like it, but it's much, much more frustrating as far as experiences go (at least compared to Stack Exchange and "apt install $magic_package_version" to solve your immediate problem)...

I can teach a programmer the basics of how to use a scope in 10 minutes. The basics of C for a non programmer would take what - a week minimum?

Every scope made in the last 20 years has an autoconfig/autoset button...

You ever deal with an Oscilloscope with a ground-loop problem?

You're not teaching electrical theory in 10 minutes. No sir, no way. I'm going to guess that it takes you more than 10 minutes to adequately explain what a ground loop is, even if the other guy is reasonably trained in electrical theory.

EDIT: Recognizing a ground-loop, understanding where it comes from (Oh, X device isn't grounded and my Y device ground is the Oscilloscope's ground right now), and finally solving it (switching to AC mode if you're cool with capacitive coupling).

And it can be rather dangerous / fire hazard / electrical hazard if you made a stupid choice (ex: connect X's ground to Y's ground. Are you sure there's no serious voltage difference here? After all, if there wasn't a voltage difference, you probably wouldn't be having a ground loop problem to begin with)

Any good references for learning how to use a scope and other equipment? I haven’t gotten around to cracking open TAoE [0], but I did pick up the “hands on lab” version [1] which looks promising. Any resources on getting familiar with test equipment would be appreciated.

This book from a parent post looks pretty good: Understanding Signals with the PropScope from the company Parallax [2] and it looks like there’s a bundled kit on Amazon.

[0] https://artofelectronics.net/

[1] https://www.cambridge.org/us/academic/subjects/physics/elect...

[2] https://www.jameco.com/Jameco/Products/ProdDS/2134871UsersMa...

If you're still at "learning to use an O-scope" stages of EE, you shouldn't be reading TAoE yet. TAoE is more about selection of proper components... such as figuring out if the 2N2222 BJT or the 2N3904 BJT is better for your particular circuit.

https://www.onsemi.com/pdf/datasheet/p2n2222a-d.pdf

https://www.mouser.com/datasheet/2/308/1/2N3904_D-1801586.pd...

They're both NPN type BJT transistors. There's a bit of knowledge you need to see the difference.

Anyway, when you're at the level where you're analyzing components like that and picking between them, that's when you're ready to read TAoE. I'd caution against jumping into it too early, there's just so much to learn before that textbook is relevant to you.

---------

I don't... really remember my 200-level classes. But there was at least one semester of rather boring, beginner level electronics. Just using OScopes, power-supplies, and shoving electricity into resistors, capacitors, inductors, diodes (etc. etc) and learning how to read / measure that stuff.

I think an older beginner book that teaches like, 555-timers and other simple circuits are what you need. As well as just a lot of lab time with an OScope + breadboard, debugging and groking, and understanding these already made designs.

Once you get a gist of how the common components work, then you are able to choose various components and make them work together yourself.

> There's plenty of people who know how to write software. Not as many who know how to use an oscilloscope.

As a software engineer who's been learning electronics in the last two years and now does know how to use an oscilloscope: Try it, it's not hard at all to get started, and very much fun.

I don't doubt it's fun. I did a Bachelors in CompSci but had a lot of fun in the few circuits / EE courses that were shared between the CompSci and CompEngg programs.

But sitting at home with an existing job, it's a lot easier to learn C than pick up an oscilloscope and some hardware to run it on. I can't exactly tear apart my home appliances as easily as I can write throwaway programs on a computer.

It's definitely more budget-intensive to muck around with hardware as a hobby, but at the same time, it's perhaps never been easier:

- Lots of used hardware on eBay/craigslist, if you're looking to acquire skills by dismantling or repairing stuff

- Good free tools (i.e. KiCAD)

- Affordable services to order PCBs from

- Lots of businesses selling parts to hobbyists

- Test gear such as scopes and DMMs are now much more affordable, with many low-budget options that are good enough - $1000-$1500 gets you a reasonably complete home lab

- Lots of 3D printing options for encasing what you make

- Large, vibrant communities full of other hobbyists to get help from (or buy used stuff from, if $1000 is above your means)

It's quite satisfying and achievable to build physical things on the side, or build complete systems with your hardware/device components involved.

Another reason it makes for a great hobby: It feels work-adjacent enough (to a software job) to be worth the time investment (i.e. you are gaining useful insights and knowledge that can inform your work as a SWE), while being different enough to feel like a change of pace.

Not that uncommon in my experience. Depends on the kind of microcontrollers/embedded computers. Weaker ones are closer to the bare metal and need some EE during development. More complex ones with a GUI or that run Linux are mostly application level work. And for mid-level microcontrollers (the kind I work on), once the drivers are there, it's all application work.

The problem for switching from pure software to embedded is that companies like you to have EE experience, even if the job doesn't require it at the moment, so you can use it if you need it. Of all my embedded coworkers, only one was a pure CompSci major. The rest were CompE or EE.

Personally I consider myself more SWE than EE, and half of my job titles have been "Software Engineer" instead of "Firmware Engineer" or "Embedded Engineer".

Teams are so small. As in commonly 1 hardware and 1 software engineer.

You at least need some common vocabulary. "Hey the gpios are floating at startup and messing with the meter. Can we pull them down? Hmm no but perhaps we can reset the meter after startup to a known state." That sort of thing.

Counterpoint: in the space/aerospace world, having embedded systems running tens of millions of lines of code is common.

These have many large software teams working together. Most software engineers on these embedded programs are just that: software engineers. I've worked in embedded for a long time and have never "physically" debugged or otherwise physically touched the hardware I work on. There's a lot to embedded systems outside of microcontrollers.

Depends on the embedded system. I've only worked in mid-sized companies, and most of my projects were teams of 4 to 12 SWE-type with 1 to 3 EE for the project. Typically light ARM4 or weaker microcontrollers will have smaller teams, or no team, while anything beefier, like embedded Linux projects or anything with a UI, will have bigger ones.

Depends on the project. Most of the teams I've been on were 4-12 SWE for 1-3 EEs. These were usually mid-range microcontrollers with GUIs. It's typically only weaker, single-purpose embedded without an RTOS (like sensors or whatnot) that has 1 to 1 unless the company wants the project to drag on for half a decade.

In the embedded world, running a multimeter, oscilloscope, or logic analyzer can be part of a pure software job. You're close to the hardware, and the hardware responds to what you do. For some bugs, the fastest route to debugging is to see what happened with the hardware.

Some embedded devices have robust OSes between you and the hardware; some don't. (This isn't a sign of bad engineering on the devices that don't, by the way.) The ones that don't, you need to get to know the hardware fairly well.

The only reason to use C in the first place is if you're doing something "impure": i.e. you're very dependent on memory layout, poking bytes directly into hardware, predictable timing properties, and so on.

"Embedded" means a deeper connection between the software and hardware by definition, so it might make sense for pure software to be uncommon.

Embedded means a computer is part of another product which includes satellites, spacecraft, aircraft and drones with millions of LOC. I've worked in embedded most of my career and in my experience, aside from driver developers and some middleware folks, the vast majority of embedded software engineers just work on embedded software applications.

I imagine the situation is vastly different for those working on a microcontroller, but that isn't the entirety of embedded systems.

I exclusively work on microcontroller projects, and my experience is the same. I've only worked on one project that really needed my EE experience to write some drivers. Once the drivers are there, it's all application layer for the rest of the project, which usually go on for 1-3 years for a team of 1 to 12 people.

> but the difficulty level for avoiding bad decisions is so high that I would be very hesitant to hire someone with no track record to operate solely in C.

People make bad decisions in high level languages all the time...

Absolutely. C lets you make all of those bad decisions too, then adds a whole new list of foot-guns on top. You can literally write bad code that will cause a different part of your program to segfault with no obvious connection between the two. So care must be taken.

Besides embedded and kernel spaces, which might not be everyone's cup of tea, try looking into Linux distro shops who contribute to GNOME, GTK apps, desktop experience that is.

> Where the C users are hiding? Is living programming in C even possible

About half my work is programming B&R PLCs in C, albeit it's C with a custom IDE and code generation that makes it quite different from a normal embedded environment. (The other half is Python, networking, radio comms, sysadmin, etc etc)

But it's actually somewhat rare to find people programming PLCs in C. The vast majority seem to be using a PLC-specific language, and even B&R is starting to move towards Python.

I'm in Industrial Automation (drives and power electronics) and none of the PLC guys here use C, all ladder, sometimes ST. The B&R Acopos Test Rigs that I've built with a B&R PLC do steer towards C for the logic program (Automation studio 2.x). TBH, if I did have to do any PLC programming I'd rather use C than most of the IEC languages. Personally I love C, although I can see the advantages of Python and C++ for tools etc.

Where are you located?

I am in Brazil.

Trying to get a Portuguese citizenship but mess with Portuguese ancestors renaming without informing the government is making it hard.

Second on this one.

It would also be helpful to know if you're likely eligible for a security clearance in whatever country(ies) you hope to work.

In the embedded space it's used quite a bit. I see a lot of handwaving about c++ and rust, but most that I encounter irl is c (with some asm sometimes).

>> Where the C users are hiding?

Not hiding... C domain are rather "limited" these days, like embedded system, microcontroller, OS kernel, robotics, etc.

I worked at a local smartcard manufactur for a few years, and the team who worked on our smartcard OS were C coders.

Well, try to apply those embedded jobs. I think experience requirement are negotiable through interview.

There are a number of SaaS and other offerings that offer C drivers. E.g. postgres, mongodb, oracle, snowflake all have C drivers or company-backed C work that isn't embedded systems. But as "framework" level code, I would expect pretty extensive knowledge and experience requirements.

Shameless plug: https://jobsort.com/search?q=lang:c%20-lang:c%2b%2b

I built Jobsort to support negative filters, so the query "lang:c -lang:c++" will give you only C and not C++ jobs :)

You in the UK?

If so, electric chargers are the way to go :) I got to touch plenty of IoT-type firmware at my previous employer. Current one doesn't deal with firmware but we're pretty specialized, business-wise. I'm sure that a similar industry is opening up in America

The embedded world, certain legacy domains (just saw a job the other day working on what I assume were old C business applications on AS400), and domains that are a pain in the ass to get into without a lot of work and a decent amount of luck

Search for companies using ebpf, like Cilium, Cloudflare, Sysdig, etc. Might not start on a team doing ebpf/c, but you could get exposure there (and depending on your level, maybe they will hire you on that team, who knows).

Definitely focus on embedded. You might try looking for startups. Many may list prior experience as a must-have, but will make exceptions depending on the candidate and skills of the other candidates who are applying.

They exist. Hard to find, but there. I found mine through a recruiter, first time doing so.

Searching through my email, "Triple Crown" and "EdgeWater" are two recruiters I had good conversations with.

LOTS of open source software in heavy industrial use written in C. The linux kernel for crissakes. Compilers. Web servers.

All those roles require deep technical domain expertise. That is the nature of C.

You can write C++ code in C, it will still compile the same way. Anything that is "written in C++" can also simply be written in C.

One of the most interesting cases I've seen is artists that work with addressable LEDs writing microcontroller code in pure C. Lots of super interesting pieces in SF that are done this way. Also some of them design pieces that communicate with each other across art installations to react to the audience together, etc. C is great for controlling physical art pieces.

Outside of embedded systems and kernel maintaining, there aren't many modern use-cases for C and some go so far as to argue that C is no longer really a programming language.

Linux Kernel and its drivers, but I would assume you would need to put up a lot of upfront unpaid labor before you are picked up by a company who wants to pay you

Check out https://jobs.embedsysweekly.com/

Have you looked at jobs in the security space doing reverse engineering? Leverage your low level experience tearing stuff apart.

I work at Microsoft on the hypervisor. The hypervisor and the NT kernel are mostly C - as are many other kernel mode components.

Look at people working with embedded systems. Often in companies supplying equipment to manufacturing or similar industries.

I just left a job that was mostly C towards the end. Linux kernel and TEE stuff. Mostly used in car entertainment systems.

So much to unfold in your post but I can guess you are very stressed due to your wife's pregnancy and your job hunt situation.

If you are looking for remote work and already know C enough to find a job, you can search Indeed for listings and apply to all of them. Otherwise, fiverr and upwork could help if you post your own skills with C and probably people are searching for small projects.

If you are not very well experienced with C and already making money from it already, you can try switching languages a little, focus on PHP and Python and you can find so many remote jobs fairly easily. Unsure if yours is a temporary solution or lifelong change, you can simply decide what you can do and make that change in 3-6 months or so.

Any panic induced decision will be wrong so please make sure you don't get your expectations high finding a remote job in 1-2 weeks because it is an emergency. Give yourself 3 months for the transition and meanwhile find out what you want your life to be in the next 5-10 years. If you don't like what you do at work, you will hate every minute of it.

TLDR; Find a job preferably online related so you can find remote opportunities that don't require you to be in an office. Most web related jobs are remote friendly. Congratulations again.

Video. Audio. Anybody who uses ffmpeg.

> My wife is pregnant and I need a job urgently

> what I really wanted was work with C.

I'd understand if the second sentence was "Where can I find a job that (pays really well | allows for parental flexibility | has high security | ...)" -- what is it about your wife's pregnancy that triggers selecting a rare job you really wanted?

> triggers

As I read the OP's sentence, there's such no implication of causality.

This is the sort of extremely sensitive personal situation that requires a gentle touch. Internet comments about this kind of thing, including questions with assumptions baked into them, can easily come across as personal attacks. The burden is on the commenter to avoid that (https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...).

This is a very good question.

Reply on news.ycombinator.com