Hacker News Reader

Comment by hvasilev | Hacker News Reader

The thing that burns out web developer is web development. The constant shift of technologies (just for the sake of it) and the nerfed (to oblivion) environment is hell. As a web developer, after you learn the basics (~5 years) there is no feeling of where the "up" direction is. Everything feels like sidesteps. There is no feeling of permanence to your knowledge, unlike a lawyer or a doctor. The knowledge feels like water pouring into a full container - as much of it goes out, as it goes in.

Switched to embedded systems 7 years ago to avoid the burnout. It is better, in my opinion. Funny enough, there is a natural barrier to entry that keeps most programmers away - You have to understand how computers work, how operating systems work and you have to be able to code in C/assembly. I have a lot of fun and actually picked up electronics as a hobby, which will help me better myself professionally. I think there is enough here to keep me entertained until I retire.

View on HN

> There is no feeling of permanence to your knowledge

I couldn't disagree more. Maybe it's my situation as a full-stack web developer that makes it different, but over the past 5 years my understanding of all the layers that a website interaction goes through (from mouse click to database and back) has only deepened, and none of it feels like it went out of date over that timespan.

Sure some company may use technology X for the job another company uses Y, but overall it feels more like different paint jobs for the same thing with slightly different trade-offs, than an ever-changing barrage of completely new things.

Agreed. It's more like switching from latex to enamel paint, and then someone inventing a new type of paint that has some better properties, but some worse, and is situational.

Nothing is static for any discipline.

Doctors have a constant influx of new medicines and procedures. The doctor that operated on my wife had heard of a just-in-case tip that ended up saving my wife from having full-blown have-to-get-kemo cancer. Most doctors still don't do it that way, and it's an incredibly rare situation... We got super lucky that that doctor was on the ball.

And while it's not life-threatening, I see the same kind of thing in webdev constantly. New 'best practices' come into effect all the time because of security vulnerabilities, and new tools come into existence to make hard things easier.

Yup, those same tools sometimes make easy things harder, but that's the trade-off. You do not need to make the switch. But it has its benefits.

I agree, once you know the patterns and the foundation of the web new tech is not that hard to adapt to. I agree as a new dev it can feel like a bottomless pit, in the same way low level programming feels for most new devs.

That said web frontend has had a wild ride the past years. But its really starting to stabilize now, around a few core frameworks (react and angular for example). Sure there is still forks and revamps but its not the big world changing differences (like going from jQuery to react was).

I think it's hard to disagree with the parent on the frontend side. New frameworks every few months (and it has been like this for years) and even stablished ones keep changing in incompatible ways (Angular, React, Vue).

Backend is much more stable, with the exception of Node, which seems to be suffering a disenchantment, a bit of reality check after the early euphoric years.

I am yet to be convinced that any of the 3 top frontend solutions (Angular, React, Vue) are worth the trouble.

What about Node has changed? It's been the same for several years save for the introduction of some new (optional) APIs and support for language features in JavaScript.

I would say, using it with Typescript became much more common.

There is also deno (https://deno.land/), from the same creator.

Well, it's not a web thing. All of software development is migrating into strict/expressive/implicit type systems. The web frontends just happened to move faster there because Typescript has a great type system and is backwards compatible.

Embedded and system programming aren't much behind, because of Rust. Everything else isn't migrating to Haskelllike languages nearly as quickly, but most software will go eventually. The slowness is probably more due to bad market dynamics for the tools than to long term issues.

I just see node growing stronger adoption wise every day.

> New frameworks every few months

React is going on 9 years.

> even stablished ones keep changing in incompatible ways (Angular, React, Vue)

React's API has been incredibly stable. There has been one major breaking change in the API (deprecation of the lifecycle methods) and even those are still supported.

These arguments are tiring. Think of something new.

What about hooks? That's a pretty significant change.

Even if class based components are still supported, the community is moving to hooks be the standard so you don't have much choice but to learn them.

Redux became popular and then has slowly been replaced by context and libraries like React Query.

You can learn hooks in a weekend and it's really the only major change in years.

Here's a few examples of knowledge becoming obsolete:

  - JSP, JSF and PrimeFaces in Java are essentially dead (server side and hybrid rendering technologies)
  - Vaadin and GWT are essentially dead (Java to JS transpilation of sorts)
  - AngularJS is essentially dead (Angular 2+ are way different)
  - jQuery is on its way out
  - class based React is on its way out

Each of those have a lot of internal complexity that i'd suggest is more than just a paint job. Of course, it's inevitable that technologies that didn't work out for one reason or another will be sunset and will die out, however at the same time there is definitely churn.

For example, we don't know if something like Bulma or TailwindCSS will work out and will be around in their current form in 5 years. You could say the same about how state was managed in React, nowadays we have MobX and Redux, but also the Context API. You can say the same about most languages, approaches, frameworks and libraries - nothing is set in stone.

I'm not sure whether that's a bad thing or a good thing, i just personally hope that eventually the more stable approaches will survive and the developer experience will be all the better for it, as opposed to introducing more and more complexity to the point of rivaling that of JSF/PrimeFaces.

My personal approach is just vaguely along the lines of:

  - learn the fundamentals that are unlikely to change much (abstract concepts, architecture etc.)
  - learn the most common technologies, refresh knowledge every few years (HTML, CSS, JS)
  - learn the frameworks and libraries to the point where you feel vaguely competent with them (React, Angular, Vue, have a vague idea of how to do stuff with CSS libraries/frameworks like Bootstrap)
  - maybe pick up a few useful tricks here and there, if you have the time explore a new technology or two in non-prod projects every now and then

Tangential. I don't understand why class based react is disliked. Hooks are complex magic, and don't work like rest of language. Compared to that, class component will do exactly what you say.

I actually agree with this and liked when you could see the full behaviour of a particular concern within a component, for example, its shouldComponentUpdate() method.

But now, with hooks, you might instead have 3 or 4 useState hooks, each of which could cause a component update. Worse yet, with useEffect hooks, you might run into the interdependent dependency array problem, which would cause a refresh loop.

Now it feels like your components have now become containers for smaller loosely coupled units of code with their own behaviour and life cycles, all of which may result in lower coherency as well.

I actually voiced some of my concerns a while ago in a slightly satirical portion of my blog, called "Everything is Broken": https://blog.kronis.dev/everything%20is%20broken/modern-reac...

Once you grok hooks, they are just better.

With hooks, it is easy to create re-usable state controllers than with class based components. Components that use hooks are easier to read, understand and modify. Hooks are also easier to test and annotate with typescript.

In classical class based component you would often have complicated code in componentDidUpdate, componentDidMount or getDerivedStateFromProps. Code ended being complex and interaction between lifecycle methods and constructor hard to debug.

> Once you grok hooks, they are just better.

Disagreed. It's likely that there are factors at play here that we're not considering, such as personal preference or certain people enjoying different patterns more.

> Components that use hooks are easier to read, understand and modify.

Hard disagree. In my experience, hooks take a single concern within a component (whether it should update, or reacting to a certain event within it) and scatter the logic throughout multiple hooks in any non-trivial application, which leads to the control flow becoming harder to understand and lower overall coherency of the code.

> In classical class based component you would often have complicated code in componentDidUpdate, componentDidMount or getDerivedStateFromProps.

This feels like an indicator that you should split your components into smaller parts and compose those, as opposed to look for other ways which may or may not be better (because of the aforementioned differing preferences) to express that same level of complexity.

> Code ended being complex and interaction between lifecycle methods and constructor hard to debug.

I apply this very same quality to hooks.

In my case I found that for most web dev jobs I needed to learn the libraries thoroughly or live in constant stress because I was always getting behind my expected velocity.

I find most frontend libs code too convoluted to be able to understand what is happening just by taking a glipse at the code.

In contrast I've doing backend in .NET since 2008. To catch up with the latest releases I need at most a couple of weekends a year and probably less.

> I find most frontend libs code too convoluted to be able to understand what is happening just by taking a glipse at the code.

This is definitely a valid concern, especially when the authors of some frameworks attempt to be "clever", which unnecessarily increases the cognitive load that one has to deal with.

That said, it's also probably a matter of the abstractions that are used, for example, in Java for back end you can use any of the following: Spring, Spring Boot, Dropwizard, Quarkus, Helidon, Vert.x, JSP/JSF with something like PrimeFaces, Apache Struts, Play and others. Whenever you run into a framework that uses MVC or its own way of templating, you're stuck learning all of its specifics and idiosyncrasies, even if the end result that you want to achieve is the same.

Thus, i'd posit that if you're not the person making the choice of which framework or library to use (the ones that you're familiar with), on some level you've already lost.

If you're used to Angular, for example, but instead get thrown into a project with React, Redux and Tailwind CSS because someone wanted it on their resume, you'll both be less productive and will look less productive compared to everyone else.

Similar route myself, though I've been in embedded longer. I do appreciate the relative stability of embedded, where in many ways I feel like we're still living in the 90s when you could realistically master the whole chain of tools and ideas as an individual. Things do change, of course, but at a much slower pace, and depth of understanding of Arm, C, various transports and their oddities, etc., is more important, but the underlying tools and ideas rarely shift in a major way.

You need a more fundamental understanding of how your MCU works (again, similar to any home PC in the 90s or early 00s), but once you learn those fundamentals they transfer very well, and knowledge has a high degree of transfer from one project and generation of devices to another.

I also find it highly satisfying to work on things you can actually touch or point to, versus spending 6-18 months of your life for something that just sits on a server somewhere as a cog in a short-lived system.

You do need a certain type of brain to enjoy this kind of low level development and HW design since there is some overlap and you often have to roll your own versions of common-seeming operations, and I suspect salaries are lower than in some shinier fields, but overall I've always appreciated the work I do, and the colleagues I've had in this field. The egos tend to be smaller, and the drama minimal since the people doing this kind of work tend to have been at it long enough to have some perspective on things.

>like we're still living in the 90s when you could realistically master the whole chain of tools and ideas as an individual.

Well, I personally quite near the beginning of my career had the exact same problem as the OP in the 90s. I started off learning the MacOSX API and C, then C++. Then started looking at Windows API - DirectX and COM were also new then (Win 95) and MFC was just getting started as a direct response to OWL and the Borland tools and VB 3.0 was starting to make big inroads into RAD dev. Then the straw that nearly broke my back was Delphi, which I have never used but was wildly popular and a 'must learn'. By the time Java came out I had decided to stick to the WIN32 API and COM and ignore the rest so I had a career focus but a lot happened in the 90's and it was easy to be totally befuddled as to where to focus your energies.

Programming is hard, let's go shopping.

>MacOSX API

I think you mean what's now called classic MacOS. System 7, Mac OS 8/9

>Programming is hard, let's go shopping.

What you are describing is not programing, but life and career choices, which is much, much harder in my opinion and most of us are sorely unprepared for.

Yes, you're right, System 7. I had a Performa 275 with a 68030 CPU and learned to program C & C++ with Metrowerks (a fantastic IDE for the time). I don't have that anymore but might still have a copy of Inside Macintosh somewhere.

>Programming is hard, let's go shopping. Phrase borrowed from Jeff Atwood :) https://blog.codinghorror.com/programming-is-hard-lets-go-sh...

>What you are describing is not programming, but life and career choices, which is much, >much harder in my opinion and most of us are sorely unprepared for.

This is true, you can either simply bob along on the currents of fate and take whatever comes to you, or try and take control. At first I was just happy with a job, and luckily (all my working life actually) there's been plenty of opportunities for my skills; but later chose more carefully. I'm sure that's the experience of plenty others too.

Any suggestions for books / courses for a developer who wants to go into embedded development both professionally and as a hobby?

Like any niche, it's hard to know where to start and it also depends if you are more interested in HW design, or the firmware side of things. You need some knowledge of both since they overlap in many areas in embedded, but they are different paths.

Assuming you mean more writing firmware, the biggest thing to understand is that embedded is all about C. You'll absolutely want to learn the basics of C and properly understand pointers. A key part of C is understanding data types (signed, unsigned, float) and notations you rarely used in other fields like hexadecimal which is omnipresent in embedded. If you grew up learning C#, node, etc., you likely don't properly appreciate these fundamental types, and you'll need to learn those fundamentals, but that will come with learning C.

For books, I like Jack Ganssle's "The Art of Designing Embedded Systems". He does a good job of laying a solid foundation for planning embedded projects. It's opinionated, but you could do worse than start with his ideas.

And start with a professionally maintained foundation for your projects. Arduino is good for some people, but it won't scale and won't give you the skills you need professionally, and scripting languages like MicroPython won't help you later in life. Use a language (C) and platform you can go to production with, such as Zephyr RTOS, Azure RTOS, FreeRTOS, etc. It's more work and harder up front, but the investment will pay dividends and you'll learn good habits from the start.

The comment above is great advice overall, but I break with it on the last paragraph. I think most people in the "I don't know C or electronics, but want to get into electronics and firmware" camp should start with Arduino (or clones).

Not because it's great technically and not because the editor is great (frankly, it's awful). The reason I argue to start there is that they've made the first 15 minute experience stupidly easy and convenient and, as a result, it's become wildly common and popular and you can readily find Arduino-platformed examples for most of the basic electronics technologies. If you're the type to learn best when you can see glimmers of visible progress, Arduino gives you smooth on-ramp.

You will need to wean yourself from that reliance/training wheels at some point, but I think it makes the first 2 months 20x easier, especially if you're trying to learn datatypes, bit-packing, pointers, memory management, analog electronics, digital electronics, communications protocols, in-circuit programming, and everything else (PCB design?) all at once. Break it up a little.

I certainly don't disagree, and wrote many an Arduino library and drivers and tutorials myself.

As long as you eventually take the training wheels off, and know that Arduino isn't a path that leads to being able to create financially viable products, and it's a first step.

It won't teach you certain good habits, but it will perhaps get you hooked and motivated, which is useful in itself, and does give you the satisfaction of making motors whirr and LEDs blink quickly.

I really, really like The Art of Programming Embedded Systems but I think that (1) it's out of print now and (2) it has some dated advice (that was excellent at the time) that can send a modern programmer down the wrong path. OTOH, Jack has a mailing list: http://www.ganssle.com/tem/tem432.html that is current and very informational.

I agree that Arduino is not a good start if you intend to become a professional. Arduino works really well for the non-technical person who will never progress beyond the arduino ecosystem, and for the experienced embedded programmer who is well aware of its limitations. Beyond that, if your intent is to learn embedded systems professionally, pick up an ST Discovery development system (about $20 IIRC) and have at it. Although I worked for a company that standardized its embedded development on Nordic processors, I don't recommend them unless you need wireless in your project.

Replying to myself: ST Discovery only brings up Star Trek references. If you're looking for the dev kit, try searching for STM32 Discovery instead.

Update since I should have mentionned HW as well.

If you're looking for something to play with at the HW level, it can be overwhelming to know what to start with. Stick to Arm Cortex-M. That will get you the furthest the fastest IMHO. If I was to suggest one company -- even though they all have their strengths and weaknesses and niches, and I work regularly with several like NXP, ST, etc. -- I think Nordic Semiconductors does a very good job with their support forums, SDKs, tools, etc. BLE is also a very rewarding place to start since you can talk to your phone, laptop, etc., which is Nordic's niche.

A development board like the nRF5340 DK has a HW debugger on it out of the box (to program the MCU and debug programs), is reasonably priced, works cross platform, and packs a lot of processing and peripheral punch. Being based on the Cortex M33 it has a solid security foundation (TrustZone and TF-M), and works well with a first-class RTOS like Zephyr with open source networking and wireless stacks.

You'll find answers to common questions with this chip on their forums and online.

There are other options -- ST and NXP have many excellent MCUs and inexpensive dev boards -- but the nRF boards and the ecosystem around them make them a good choice to make a serious start and learning embedded, and they are one of the only vendors who reliably answer questions on their support forums. The nRF53 dev board brings a lot of value as a serious learning platform if you're getting started.

Again ... just an opinion!

There’s a certain churn to it sure, but I wouldn’t call all the development “sidesteps” I think it’s just the scope of changes that’s staggering. You knew jquery, gulp and express and you were fine, but thats such a low low bar if you take the whole of human achievement in CS. Web developers just re-experience the growth and invention of all the other branches. For example you get virtual dom with react - an idea that’s been in client side’s dev arsenal for quite a while. Webpack/esbuild are re-discovering compilers, etc.

It’s all just a process of convergence in my eyes. And if I put it in that way I can cope with it. Any new fancy library comes up - I check ok were have the ideas come from, language, environment etc. Go read that and understand the original concepts, and then watch the web dev slowly move in that direction.

To be honest it’s pace is sometimes actually frustratingly slow if anything. You can see some Ideas that have been tested and you think they would be great, but takes time to actually permeate into web dev.

This comment appears in every HN thread about web development. Always coming from someone who clearly doesn’t understand the web deeply.

If you did you would realize things haven’t changed that drastically in 5+ years now. The new libraries and frameworks are small iterations that take a weekend to check out and pick up.

Once you have the deep knowledge you’re set in this field. The problem most people have is that it can be less straightforward and much wider surface area, especially if you’re doing stuff like React then React Native, and also trying to understand native libraries while also bundling code for both platforms.

>If you did you would realize things haven’t changed that drastically in 5+ years now. The new libraries and frameworks are small iterations that take a weekend to check out and pick up.

I think the issue is the fact that the browser has no native rich and efficient components like desktop tookits have.

So you implement some coold grid view to showcase all the user projects but later some user created many projects and because angular performance is garbage you need to solve it now, You can do a shit solution and implement pagination or waster your time and implement a DataGridView similar like in desktop toolkits that is actually smart and efficient or maybe you do the shittiest thing and install some random stuff that might give you what you need. Same problem would not exist on desktop and probably mobile tookits.

Repeat same issues for all possible widgets that exist in a mature toolkit.

On the web you always spend a lot of time on shittiest things instead of the cool part. A designer wants say a horizontal scrollbar that would work only with the mouse(no Ctrl to press) =? install a library, a designer wants a dropdown with some extra styling -> install a library (or create a inferior dropdown - see YT autocomplete one that gets stuck on all the time) , modals -> create your own system. The only widget that is not handicapped in the browser is the text input one.

People will say how in the past on desktop you can drag and drop widgets and make the app , the reason it works is because those widgets where powerful and efficient. Probably mobile devs can understand this point, you don't have to hunt for a framework or library to get a smart and efficient table widget.

> The new libraries and frameworks are small iterations that take a weekend to check out and pick up.

If this is the case, then i congratulate you on being a pretty productive and capable front end developer!

However, that's definitely not the case for me and many other people: i'd say that you need at least a week to get comfortable with both using technologies, ways of misusing them, their footguns and to get a deeper understanding of what you're actually doing. I've seen sites fail to work correctly because people attempted to use React hooks with overlapping dependency arrays, where one of the hook bodies calls a state mutation, which ends up in an endless loop and breaks the entire page.

If hooks indeed were such a small feature that could be reasonably understood in a few days, then we wouldn't see cases like that, nor would it be difficult to write your own hooks. You can say the same about the Context API, as well as the migration from class based components to the functional ones.

If that's the only set of technologies, then good. But i work in a company that does consulting and occasionally i have to unravel messes in everything from React, to Angular, to Vue, even jQuery and AngularJS. If i want the lifestyle where i spend long evenings and weekends of my own time working on learning these technologies, then sure, but the company has neither the resources nor the patience to wait for days to weeks until i become productive in a project.

Is that a social issue rather than a technical one? Perhaps, but at the same time these kinds of factors cannot be ignored. Sure, the churn isn't too bad and hopefully has good outcomes in the end, but at the same time it definitely is there and sometimes it definitely is detrimental from the point of view of just getting things done (e.g. AngularJS needing to be abandoned for Angular or something else - it should be better in the end, but as someone who has a rewrite of an app that has had thousands of hours sunk into it looming over me, i'm not overjoyed).

> Once you have the deep knowledge you’re set in this field.

Examples of this deep knowledge?

>someone who clearly doesn’t understand the web deeply

Maybe this is the root of the problem. Should you need that deep knowledge in order to be proficient? I mean, the point of so many libraries and frameworks was to remove the need for a deep understanding of the underlying technology.

Perhaps the need to understand it deeply indicates that they've largely failed?

My theory is that most of these comments are coming from backend devs who rarely do frontend and then complain that the space has evolved since MooTools was hot shit.

React is going on 9 years people.

The issue is that web development encapsulates too many different roles, each of them is a job in itself. The role has grown to encompass too many specialties:

-You need to be an expert* JavaScript developer with strong understanding of computer science at the same level as say a Java engineer.

-You need to be an expert on cross browser, cross-device and cross-OS compatibility and performance of Javascript, HMTL, CSS.

-You need to be an expert in animations, transitions, SVG, canvas.

-You need to be an expert of analytics, statistics and presenting data.

-You need to be an expert of responsive design, accounting for countless myriad possible platforms, compatibilities, viewports, constantly evolving standards and best practices.

-You need to be an expert of accessibility, semantic html.

-You need to be an expert in working with various types of databases, or API and local storage, caching etc

-You need to be an expert at test automation, writing unit and integration tests with increasingly high stakes.

-You also need to spend time and have strong understanding of ancillary issues, such as package management, devops, CI etc etc

-You need to do all this and your work is pretty much almost entirely customer facing (or stakeholder). People who don't understand the constraints, or dont appreciate the difficulties of what a problem may require.

And this is without talking about things like Typescript, React (and the millions of other dependencies, libraries, hot new things) you have to deal with

Just look at the URL shared on this article and see how many subject mentioned were totally not part of web dev say just 10 years ago.

5-10 years ago my job was:

- build websites with a bit of javascript DOM, ajax, or jquery UI interaction

Now my job is:

- same as above but with the added responsive aspects

- building single page applications

- building browser extensions

- building command line tools

- building react native mobile apps

- building electron apps for desktop

- writing tests

- building tooling and managing dependencies

- building internal libraries, style guides and associated documentations

*this is the expecations, i know the reality is not really the same.

> -You need to be an expert* JavaScript developer with strong understanding of computer science at the same level as say a Java engineer.

I would put Java engineers in the "software engineering" category more than the "computer science", but that may be just an expression of my bias.

I think it's one of the most complex jobs the only thing that helps is that technical expectations generally are low.

> The role has grown to encompass too many specialties

The good news is that none of the successful lead web developers I have worked with meet these requirements. I feel like you're talking about a large team more than a single developer, and in many places where you say "expert," I would say "willing and able to tackle the subject to the extent required."

I think a better way to sum up web development, instead of making it sound like an impossible job, is to say there is virtually unlimited scope to make yourself better and more valuable at the job by expanding your technical skills.

Now if only people stopped saying "you need to be an expert" and said "you need to not be clueless at it" then it would be easily achievable over a few years.

The "expert" expression is abused by approximately the whole tech sector. No one meets those job requirements anymore, and yet the world (of web development) still moves on.

Exactly. People like the parent make themselves crazy thinking they need to be the expert at absolutely everything. You don't. Learn your fundamentals, and learn how to learn. All of these front-end frameworks, that's just tech. All of them do the same thing in slightly different ways. You'll work in a team anyway, someone will be good at something, someone will be good at another thing.

Yeah. My current take on the shit coder jobs I've taken, as compared to the rocking blue collar jobs I've performed, is when you're a coder you're getting paid to learn.

Paid to learn. Does that sound noble? Maybe it is. It depends what you're learning, frankly. Learning to code for the very first time, and seeing the fruit of your imagination materialize in front of you? Great! Learning the idiosyncrasies of a system that was designed to dodge responsibility?

Learning during a meeting where you were introduced as the software expert even though you only took over the solution last week?

> The thing that burns out web developer is web development. The constant shift of technologies...

I have a friend who manages a dev team in a small webdev shop (~8 people total) and is about to quit because of the customers delivery schedules. These customers are BIG name (billion dollar) companies so they feel pressured to grind and get the site built otherwise the customer will just pay some other desperate company who will. So it seems that on top of tech churn there are insane customer demands ruining the mental health of everyone involved.

Can you work remotely on embedded development? Giving up remote work is a huge drawback for me.

Sure. It is a little more difficult though, since you need a little bit of an additional equipment. It is not uncommon for people to be mailing each other oscilloscopes. :P

I'm thinking of investing a little bit of money to buy myself my own equipment, since I want to use it for fun as well as for work.

A logic analyser (Saleae Logic, etc.), a HW debugger (J-Link for Arm/RISC-V), a good quality multimeter (spend the extra money here, don't get the $10-20 crap DMM off Amazon), and an entry level 200 MHz oscilloscope (Rigol, etc.) should set you back somewhere from $1-1.5K I guess, but that will give you 90% of what you'll need to debug most embedded MCUs (Arm Cortex M, etc., not Embedded Linux or Arm Cortex A which is a WHOLE other world).

That may or may not be a large amount of money for someone, but those tools can last you a good part of your career for the price of a low/mid range development laptop.

Can you explain your remark about "not Embedded Linux or Arm Cortex A which is a WHOLE other world"? Do you need oscilloscope with GHz frequency?

You'd likely need a higher frequency scope if you're debugging timing issues or something on a processor that runs in the GHz range.

Exactly. Measuring things at 10-200 MHz is easy and relatively accessible, and there are only so many things that can go wrong.

Dealing with anything in the GHz range is not only extremely expensive (order or magnitude more), but you also start to deal with far more complex problems that boil down to the need for a very good understanding of the underlying physics of signal transmission: concepts like impedance matching, crosstalk between signals on the PCBs, etc.

The design AND debug requirements are far more complex, and you need to account for a lot more explations of why something isn't working as expected ... and the software/firmware AND physical level.

USB3.0 bluetooth interference issues anyone?

Hmm. A followup question: are there any cheats/hacks that would make it possible (if painful) to for example explore the world of USB3, PCIe, or Linux on low-end-ish ARM (eg https://www.thirtythreeforty.net/posts/2019/12/my-business-c..., based on the tiny 533MHz https://linux-sunxi.org/F1C100s), without needing to buy equipment in the mid-4-figure/low-5-figure range, if I were able to substitute a statistically larger-than-average amount of free time (and discipline)?

For example, I learned about https://github.com/GlasgowEmbedded/glasgow recently, a bit of a niche kitchen sink that uses https://github.com/nmigen/nmigen/ to lower a domain-specific subset of Python 3 (https://nmigen.info/nmigen/latest/lang.html) into Verilog which then runs on the Glasgow board's iCE40HX8K. The project basically creates a workflow and hardware to use cheap FPGAs for rapid iteration. (The README makes the point that the synthesis is sufficiently fast that caching isn't needed.)

In certain extremely specific situations where circumstances align perfectly (caveat emptor), devices like this can sometimes present a temporary escape to the inevitable process of acquiring one's first second-hand high-end oscilloscope (fingers-crossed the expensive bits still have a few years left in them). To some extent they may also commoditize the exploration of very high-speed interfaces, which are rapidly becoming a commonplace principal of computers (eg, having 10Gbps everywhere when USB3.1 hits market saturation will be interesting) faster than test and analysis kit can keep up (eg to do proper hardware security analysis work). The Glasgow is perhaps not quite an answer to that entire statement, but maybe represents beginning steps in that sort of direction.

So, to reiterate - it's probably an unhelpfully broad question, and I'm still learning about the field so haven't quite got the preciseness I want yet, but I'm curious what gadgetry, techniques, etc would perhaps allow someone to "hack it" and dive into this stuff on a shoestring budget, on the assumption the ride would be a tad bumpier? :)

Anecdotally, I manage fine with just a multimeter for debugging my hobbyist projects. I generally use ARM Cortex M0 or 8051 microcontrollers. 90% of debugging, as in any domain, is just thinking hard about what the problem could be and trying out all the hypotheses. Not to deny that a logic analyzer and oscilloscope could be useful, but I wouldn't want someone on a budget to be discouraged into thinking that these things are necessarily required.

I guess it depends on the problem you are debugging. I rarely fire up my oscilliscope anymore (maybe once or twice the past year), but it's hard to replace a cheap logic analyzer when writing drivers for new sensors. You really want to see the signals going out, and the response coming in to understand if you have the I2C/SPI/I2S/etc. bus configured properly, or if the polarity is correct, etc.

A logic analyser is cheaper than a scope, and does a much better job displaying this kind of data in volume. I'd say a DMM + some equivalent to a Saleae Logic are the two tools I couldn't live without ... IF you ever have to write drivers. But so much of embedded is about interacting with other devices, and it's a common enough requirement to have to port a driver over to a new chip, etc., that I can't imagine anyone regretting buying one sooner rather than later.

You can get by with printf, clearly ... but an analyzer is worth it's weight in gold for the right problem.

Most of my projects are built around interfacing microcontrollers with I2C sensors. I've never had too many problems getting I2C communications working. I think a lot of it is psychological. Without a logic analyzer you can feel a bit helpless when you're not succeeding in connecting to an I2C peripheral. However, there's only a few things that plausibly can be going wrong with something as simple as I2C. (You have the wrong address, you have it wired up wrong, or you're misusing the uc's I2C peripheral.) It's quite feasible just to work through that list of possibilities until you find what's wrong. It does require a certain amount of faith, as you generally see no indication of progress at all until you get it working.

I'm not denying at all that a logic analyzer can be helpful. I'd just encourage people who can't justify the expense to have a try without one.

Edit: That said, I see that low-end logic analyzers are actually pretty cheap. I should probably get one!

Low end analyzers are good for slow signals. 24Mhz is a common sampling rate for less than $30. Just remember that your bus needs to be less than half that speed, and even then the analyzer may lie to you if your bus speed is anywhere near half your sample rate. Also the timings in your bus can greatly effect what the logic analyzer will show vs what the cpu sees. I had a false positive last week when I should have just looked at the rx the cpu was seeing when trying to get an SPI peripheral working on a new chip.

So I may be in the market for a better analyzer soon. But all in all my $30 was a good investment, and has made it easier to setup new serial protocols.

Word of warning. I lost several days of debugging what looked like a working serial bus using a logic analyzer. I was about to give up when a friend asked what it looked like under the scope. The problem jumped right out at me. Certain bit patterns would distort the signal and I wasn’t crossing a threshold. Solution was trivial to fix after that, just replace a pair of pull up resistors and the scope showed good squares again. Had a similar problem with an optocoupler after that. Logic analyzer hid the fact that the optocoupler was too slow, and none of the leading edges were ever square. Ended up replacing that outdated part with a similar priced newer part. My client at the time was strggling with a whole batch of these optos for a number of SKUs that were within spec, but the variance was so high that it was common to get a batch that weren’t good enough for his designs.

Haha. I remember having exactly the opposite experience about a year ago. I was debugging serial communications with a scope and everything looked perfect. Couldn't understand why it worked at power up and stopped working a few seconds later.

However, looking at the data on a logic analyzer and being able to see several seconds of data at once showed that the external module I was trying to interface with was buggy. Turned out that the unit we had was a preproduction prototype!

There are some excellent multimeters around the $25 price point, like my Aneng AN8009 (especially after doing the capacitor mod)

Take a look at the reviews at https://lygte-info.dk/info/DMMReviews.html, they're very through.

I did WFH during initial Covid (changed job later) and I had to go to the office like 2-4 times every two weeks to test code on hardware. So it works, but unless you can have the hardware and any testing equipement on your desk I don't see "fully remote" work out.

You need about $3k worth of equipment to start to effectively do basic hardware from home, but can maybe start for less than $1k. A scope and logic analyzer are a must, for dealing with misbehaving peripherals, so there’s around $900 just to get started. There’s other tools that may or may not be necessary depending on what you’re working on. But I’ve spent just under 3k in the last 2 years to do embedded work from home. That includes troubleshooting hardware, which may be someone else’s job. I also have a bunch of tools and materials to make it easier to breadboard and prototype.

If you’re thinking about making the switch, the hard part is learning all the things you didn’t know you needed to know. That’s where having someone you can walk up to, wait until they look interruptable, then ask a really dumb question is priceless, and really hard to replicate remotely.

Yes. I'm doing it right now and was for the previous year at my last job.

That said, I do have a suite of hardware development tools since I've been doing this a long time. But the only times I've needed to turn on an oscilloscope recently was because I was doing some low-level hardware debug.

Once you get past the really low-level stuff like measuring signal levels or debugging a weird PWM behavior, i.e., the hardware is pretty stable and you're building out functionality, you really won't need anything more than a JTAG or SWD connection and the hardware for those is trivially cheap.

Actually the web debelopment is much more stable now than it was 7 years ago. Major frameworks and tools are the same. Web standards are much more stable now, and languages are quite established. I haven't touch React or Vue for 5 years, but my knowledge is still relevant. Server side technologies are very stable for 10+ years too.

I don’t recognise a lot of what you’re saying here.

Yeah, there is churn in JavaScript frameworks but to me that’s all they are: frameworks that sit on top of the DOM, and the nature of the DOM (for better or worse!) hasn’t changed all that much in a long time. When I think about what those frameworks are actually doing there’s a lot of consistency (this thinking also helps you avoid the stupid turf wars)

I personally like that’s there’s no “up” in web development. I’ve gone from perfecting REST APIs to understanding video encoding and streaming, to sending data via WebSocket or WebRTC… the list goes on. I hope someday soon I’ll have an excuse to dive into WebGL and WebAssembly.

And the development environment (i.e. the browser) is actually pretty wonderful compared to XCode, Android Studio and the like. There’s a reason native developers have pushed and strained to get things like hot reloading that browsers can do very easily!

Most Doctor's training is out of date within a decade of completing med school. It's why ongoing and continuous training is critical for advanced professions just like how you and I need to catch up on the new tech and systems in IT.

I'm curious how to went about making the switch to embedded systems. I've always been fascinated by embedded programming, but I have no idea how to get employed in the field.

I've met 2 people who have tried to make that switch and overwhelmingly they get told by shops they apply to after passing the technical interview that they have to take a 30k (usually more) paycut along with worse culture/benefits to go into it and change their minds.

or just pick a stable stack like go with something like hotwire for FE and just roll with it.

Is this sarcastic?

Nope why?

I'm pretty up-to-date on front-end developments but Hotwire is barely on my radar, so I had to look up the release date, but it seems to have been released just this year? (I thought it was last year.)

Though my stack has certainly evolved, it's been mostly the same since 2016, with really not that much new to learn. Adopting something released just this year doesn't seem like the most obvious choice when looking for a stable stack.

It's a tiny lib that replaced turbolinks from DHH and the gang. It's used for many prod deployments and it's pretty convenient for people who do not enjoy FE SPA style dev. There are obviously other options.

Hotwire is just a name for a bunch of tech that has been around for a while. The components of Hotwire - Turbo and stimulus - have improved over time, for sure, but the core ideas haven't changed much, if at all. I worked on a hotwire side project recently and described it to a friend as "writing Rails like it was 2009." It feels really good because I've always found it hard to grok SPAs and the like, but could generate tolerable server-side generated webapps.

Old wine in a new bottle, basically.

Even if it is not hard to grok it's often unnecessary complexity as users literally can not tell the diff. in most cases.

Hotwire and a few analogues (e.g. LiveView for Phoenix) are an emerging design pattern.

I think for a lot of business cases they are going to replace js frameworks. They are domain specific (Rails, Phoenix, etc..), but they allow you to essentially replace a lot of SPA functionality with a library that takes an afternoon to grok for a back-end dev.

They won't replace React, Vue, etc... But they can replace it in places where a full js framework is overkill (which is probably a majority of the places that I see it).

As a backend dev, I think that they have incredible promise. They make interactivity MUCH easier.

Hotwire is lang/framework agnostic.

go as in Golang and hotwire to have simple server side rendering that feels like SPA for the user

I understand the references, and maybe its that I work in robotics and not web dev. But if the criticism of web dev is that domain knowledge erodes unlike law or medicine, the response shouldn't be that long term stable skills exist such as these two things that have come into prominence in the last decade in go's case, and the last year? in hotwires case

Hotwire is not really a skill. It's a tiny lib that lets your old school server rendered app feel like an SPA. There are obviously other options for your serverside code you can use c if it's up your alley.

fair, I might give it a look if I ever need to create web project. I think ultimately the critique is still valid though. At least in robotics, new knowledge is typically complimentary of existing knowledge. My ML projects don't negate my knowledge of control theory, physics, operating systems, embedded computer architecture, etc.

To be fair in Go's case, it came to prominence at or before the time many of us started. And the Go I learned at the very start of my career (10 years ago) is still usable today.

Hotwire or htmx? :)

I use them too, but even In this niche there are several, like liveview for Phoenix.

liveview is great and Elixir is really nice lang.

After 10 years fullstack I moved into WordPress. The code I deal with is a mess but to be honest so was everything else I've ever been paid to work on.

WordPress is stable and maintains backward compat for as long as possible.

It's a real joy to build things on top of as you know you won't need to run framework updates every month to prevent a Nasty suprise down the line.

After writing 2x more CDK code than actual app code for the last year I can really relate :)

As a web developer who's a keen electronics hobbyist I definitely feel this too. But how did you make the switch? In London, there are few embedded roles, and they seem to pay worse than web developer roles. On top of that, companies seem to be looking for people who already have extensive professional experience of embedded development (which is fair enough, I guess).

All true. In my case I had to take a huge pay cut just so I was able to get into the industry. I'm not sure if this is the correct way (or the only way) to get in from a web development background. It is just what I did.

There are fewer companies that do embedded systems, but there are also not that many developers. Headhunters call me a few times a month just to ask if I'm willing to change my job, since experienced real-time embedded systems engineers are so rare that they have to actually steal one from somewhere else.

Really, really, depends on your situation.

It tends to be a very small world where you get to know everyone after a certain point, or you know someone who knows someone, and jobs tend to be had by word of mouth. If you have a good reputation (which can be gained working on problems on visible open source projects), work tends to present itself. Even more so than in other fields because it is such a small world, despite the enormous amounts of money involved in semiconductors.

There aren't a lot of advertised jobs, but I think this is often because they tend to get filled via word-of-mouth and employability is rarely a problem for a decent embedded engineer.

> Everything feels like sidesteps. There is no feeling of permanence to your knowledge, unlike a lawyer or a doctor.

Then you are doing it wrong.

Focus on the fundamentals, not the implementation. Any job or degree that doesn't value growth and a good grasp of the fundamentals is a pretty big red flag.

Do you have any tips on how to improve in the embedded domain? I've got some professional experience, mostly doing embedded application (MMU-less) development. I'm looking into linux driver development, but it feels a bit above my skill level.

If you want to improve, look at an open source project with a lot of momentum, and learn from what people are doing there.

I'm actively involved with Zephyr RTOS, for example, which is backed by the Linux Foundation and has people working on it full time from almost all the major MCU manufacturers. The development tends to correlate closely to Linux kernel as a model, and a lot of the key members were/are Linux kernel contribs, so skills learning with Zephyr can help you move to Linux dev later if you're new to it.

There is a non-trivial learning curve with Zephyr (device tree, KConfig, etc.), but it has more momentum than any RTOS I've seen in my career, and it has a very helpful community, while keeping the technical bar high.

If you prove your worth there, it's also an avenue that can possible even lead to job opportunities, which I've seen and benefited from myself.

That may or may not be of use, but if you want to improve in the embedded space, getting involved with something like Zephyr is some of the best use of limited time in my opinion to learn from some of the better embedded engineers working in the open.

Wow, the list of supported targets is a tad longer than I've yet seen elsewhere: https://docs.zephyrproject.org/latest/boards/index.html

The number of PRs and committers is what boggles my mind ... it's an endless stream, which is highly unusual for an embedded project. This is where the momentum and technical investment is happening today for open source embedded, IMHO.

> I'm looking into linux driver development, but it feels a bit above my skill level.

Same here. I managed to reverse engineer some of my laptop's USB functions and write Linux drivers for them. That little driver was the most fulfilling software development project I have ever made. Tried the ACPI and I2C stuff but couldn't figure it out. I really want to learn it all but I don't even know where to start...

Any suggestions for books / courses for a developer who wants to go into embedded development both professionally and as a hobby?

When you made the switch how did you go about getting embedded employees to take your applications seriously?

Can you provide some guidance on how a web developer can transition into the field of embedded development?

Reply on news.ycombinator.com