3 ms·
Sorry I didn't mean to be shallow or dismissive. I'll elaborate: As a application developer you have the luxury of relying on the underlying frameworks to do m
by ostenning 5y ago
Sorry I didn't mean to be shallow or dismissive. I'll elaborate:
As a application developer you have the luxury of relying on the underlying frameworks to do most of the leg-work for you. As long as you follow basic principals within the framework you can have a reasonable degree of confidence that your application will run and the end product will probably be OK. Things like iOS development are so heavily streamlined that sticking to the docs will mean from a technical perspective the app should be fairly solid.
Of course, it does depend on the application because you could be solving complex problems that are outside of the framework, so I'm not dismissing the engineering definition entirely, but generally speaking I think most developers are developers, not engineers. Developers leverage existing systems and build on-top of them.
Juxtaposing the idea of a web or iOS developer with an electronic engineer that is building a physical product with a microcontroller. The application is written in a "bare-metal" embedded environment which generally only relies on a Hardware Abstraction Layer (which basically just maps memory locations and may provide initialization code for various peripherals) and virtually nothing else. The application will likely need to employ interrupt handlers with safety (Mutex/Semapores etc) that must execute within time restrictions or the system will crash, complex DMA buffering techniques and integration with other hardware using physical layer protocols (SPI, I2C, I2S, 802.11 WIFI, USB, etc).
The transfer protocol chosen will have its own trade-offs, such as speed vs noise and then noise compensation techniques will need to be used such as increasing the spacing between PCB tracks, using ground planes etc, but these then also have trade-offs because your device may have space restrictions.
The list goes on for a while, and every decision that is made eventually enforces a limitation somewhere else in the system. Engineering (in my mind) is about the balancing of these decisions/limitations to ensure the system runs harmoniously and within the defined constraints.
- karmakaze 5y agoI started out buying into them being different, but then the description of protocol selection, tradeoffs and restrictions sounds very much like developing a distributed software system.
- ostenning 5y agoWell, then probably because your experience or knowledge of distributed systems is actually akin to engineering. I'm not debating that it doesn't exist, what I am saying is that generally speaking most application developers, who write a discrete piece of software on an abstracted stack likely aren't making any real engineering decisions.
- karmakaze 5y agoNot to get into a flame war with Frontend devs, but does this 'akin to engineering' only apply to backend? I know that there are a lot of choices made on the frontend too but don't know enough to see if it has engineering-y constraints in this context. Similarly, even on a team that does engineer a distributed system, only some of the team members do that sort of activity, the other members follow the set conventions so things work out. Eventually they could work their way up to doing 'real' engineering. I really don't like calling only some things engineering as much as I agree that software development doesn't have the rigor of traditional engineering fields.