4 ms·
Jack drops a couple turds into your codebase, but so does Diane. Hers just take longer to arrive. Inability to seek actual best tools based upon personal fear o
by pnathan 13y ago
Jack drops a couple turds into your codebase, but so does Diane. Hers just take longer to arrive. Inability to seek actual best tools based upon personal fear of the unknown does not a great developer make.
Basing one's code off the familar or the purported "best practice" without actual knowledge leads to drek down the road. A great developer chooses the right tools for the task (along with other things...) Diane's, for instance has these flaws:
- Requires a relatively heavy runtime.
- Requires HTTP stack.
- Wastes CPU/power
These are not negligible considerations for embedded devices.
Someone who knew what the crap they were doing would likely have chosen a binary protocol standard (many such exist), then pumped that information out over an appropriate topology - someone suggested UDP. The database should probably be SQLite; maybe berkDB, depending on the complexity of the data model and the CPU used. Bluntly, the proposed "great" solution isn't. It's an inelegant solution putting heavy demands on the hardware unnecessarily.
Judgement is fine. What you use as a proxy in hiring for judgement is experience. E.g., you don't hire a Ruby dev to do embedded work. Experience tells you that.
What makes a developer great is great wisdom: knowledge applied skilfully.
n.b.: I wouldn't hire either Jack or Diane based on this article; Diane is fearful and Jack picked a javascript engine too immature for embedded. Jack might be led to understanding and might be worth more; I don't want to go around trying to convince people that better is better - I have no hope for Diane if she can't spend a day learning postgres.
- mwcampbell 13y agoI thought that in this contrived example, Jack and Diane were writing the software that runs on the server, not on the kitchen devices. Also, what if the "devices" are small-form-factor PCs? That would relax the constraints considerably.
- pnathan 13y agoAh, see, I read the spec as saying that it would be things stored on the kitchen devices (toaster, etc). You do want to make sure your comms layer is easy to make reliable when talking from the device, regardless. Might be HTTP, might not be - I'd likely take a gander at ProtoBuf myself for feeding over TCP/IP to minimize comms complexity on the phone home code.
- mwcampbell 13y agoI think I'd use HTTP as the synchronization protocol, because GET and PUT are specified as being idempotent, meaning it's safe to retry them. Also, HTTP is a ubiquitous standard, meaning there are several implementations to choose from, on both the client and server sides.
- pnathan 13y agoThe ubiquitous of HTTP is indeed a definite point in its favor(as is its popularity and level of documentation). > GET and PUT are specified as being idempotent, meaning it's safe to retry them. Entirely OT: Abstractly, yes, that's how they should be implemented, but they don't have to be and consequently it's entirely up to the receiving server whether they are or not. Which, in terms of assuming that someone will make unverified and bad assumptions, means that the implementer at some point will let them slip and become non-idempotent.
- dirkgently 13y agoI would also factor in the ability to understand the requirements. In this case, knowing where the module is running - the server side.
- pnathan 13y ago:grin: Yep! As the original article said, digging into the spec and clarifying is absolutely a trait of a great developer (even an average one). Possibly being able to write a very clear requirements/spec with very few words is one of the hallmarks of the greats. (The initial RFCs for TCP/IP are amazing).