21 ms·
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
by hvasilev 5y ago
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.
- foldr 5y agoAs 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).
- hvasilev 5y agoAll 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.
- ktownsend 5y agoIt 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.
- qaq 5y agoor just pick a stable stack like go with something like hotwire for FE and just roll with it.
- lugged 5y agoAfter 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.
- qaq 5y agoAfter writing 2x more CDK code than actual app code for the last year I can really relate :)
- gmadsen 5y agoIs this sarcastic?
- qaq 5y agoNope why?
- Vinnl 5y agoI'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.
- qaq 5y agoIt'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.
- vbezhenar 5y agoCan you work remotely on embedded development? Giving up remote work is a huge drawback for me.
- hvasilev 5y agoSure. 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.
- ktownsend 5y agoA 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.
- vbezhenar 5y agoCan 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?
- dbetteridge 5y agoYou'd likely need a higher frequency scope if you're debugging timing issues or something on a processor that runs in the GHz range.
- ktownsend 5y agoExactly. 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.
- glassconclusion 5y agoDo 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.
- ktownsend 5y agoIf 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.
- exikyut 5y agoWow, the list of supported targets is a tad longer than I've yet seen elsewhere: https://docs.zephyrproject.org/latest/boards/index.html https://docs.zephyrproject.org/latest/boards/index.html
- ktownsend 5y agoThe 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.
- 5y ago
- ktownsend 5y agoSimilar 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.
- bigbizisverywyz 5y ago>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.
- 5y ago
- seer 5y agoThere’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.
- a20eac1d 5y agoAny suggestions for books / courses for a developer who wants to go into embedded development both professionally and as a hobby?
- hobofan 5y ago> 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.
- wccrawford 5y agoAgreed. 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.
- wwn_se 5y agoI 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).
- tambourine_man 5y ago
- daniel-cussen 5y agoYeah. 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?
- SketchySeaBeast 5y agoLearning during a meeting where you were introduced as the software expert even though you only took over the solution last week?
- afavour 5y agoI 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!
- 5350-uiop-1130 5y agoThe 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.
- Zababa 5y ago> -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.
- 5y ago
- zackify 5y agoThis 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.
- dntrkv 5y agoMy 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.
- simion314 5y ago>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.
- yoyohello13 5y agoI'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.
- namelessoracle 5y agoI'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.
- MisterTea 5y ago> 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.
- charwalker 5y agoMost 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.
- 908B64B197 5y ago> 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.
- foofoo4u 5y agoCan you provide some guidance on how a web developer can transition into the field of embedded development?
- potbelly83 5y agoWhen you made the switch how did you go about getting embedded employees to take your applications seriously?
- vogre 5y agoActually 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.