# ZK - 2022-11-04 - Embedded development is not like web development - Embedded development and Web development have different tooling, and significantly different onboarding - In one case, you often need to bring up a board - Install toolchain, programming tools - Use hardware to debug and interact with the hardware - Oscilloscope - Programming probe - Connectivity (cables) - Actuators, sensors, often prototype versions of them or shared prototypes - Often shared franken prototype with the team - Changing board versions - Small codebases, often completely under the control of the implementor - Need to learn a new processor architecture (often big datasheet, a lot of reading up on obscure) - Usually low code reuse - Limited opensource community (although that is changing with rust, for example) - Style and constraints of programming are different - Manual memory management - Realtime constraints - Having to write interrupt handlers - IO is done usually by writing and reading from memory mapped areas, instead of a synchronous interface - Interfacing with OS - No or limited storage - Limited opensource community (although that is changing with rust, for example) - Web development - Need to learn a bunch of peripheral technologies - CSS, HTML, SQL, Linux - Large opensource frameworks - changes rapidly - lots of tooling - lots of innovation - Lots of established services and platforms to write against - Mysql / PostGresql - nginx - memcached / redis - kubernetes - GCP / aws services / azure - docker containers and different container runtimes - secrets management tooling - Much more stringent security and data reliability constraints - Style of programming changes often, many new fads, cyclical approaches - Lots of code reuse - npm, supply chain - lots of dependencies, need to be aware of lots of peripheral complexity - Usually necessitates a local dev environment with mocked or cleaned up data - Mocked services - Deployment infrastructure can be significantly different from running the things locally (say, serverless) - Debugging often necessitates correlating frontend to backend working - Complicated user UX - Significant amount of work is spent on styling / graphics / rendering - Knowledge of different browser quirks that need one to stay up to date - A lot of APIs, data formats, services to interface (just look at AWS) - JSON - REST - gRPC - websocket - WebRTC - A lot of code is just knowing which framework to use and having muscle memory / knowing which modules exist to solve a specific problem - Runs on real computers, with a real OS, and thus all the niceties (memory separation, dynamic memory allocation) - Lots more CPU cycles to burn, much easier use of datastructure (hashmaps, vectors, queues) - Lots of synchronous APIs for communication - Shellscript glue code is often necessary for bringing up servers, bundling, doing backend infra work - Infrastructure work has a lot of tooling and different approaches - ansible, cloudformation, terraform, chef, kubernetes, nomad - deployment pipelines with packer, vault, docker - much more contact to product work and customers - observability and monitoring / devops work is a must - interfacing with lots of other teams usually - customer support - ops - marketing - sales - UX/design