3 ms·
That’s brilliant! Very cool way to inspire. Next they can move on to TERPS procedure design! haha
by fallingmeat 3y ago
That’s brilliant! Very cool way to inspire.
Next they can move on to TERPS procedure design! haha
- leetrout 3y agoJust 500 pages of light reading material https://www.faa.gov/documentLibrary/media/Order/Order_8260.3D_vs3.pdf https://www.faa.gov/documentLibrary/media/Order/Order_8260.3...
- GalenErso 3y agoWhich jobs require one to read and understand this material?
- fallingmeat 3y agoprocedure design. if you want to design your own approach procedure, for example. or if you are designing a takeoff/landing facility.
- GalenErso 3y ago"Procedure design" isn't a job title. Do you mean procedure designer? And how many people in the U.S. work in designing landing and takeoff facilities?
- fallingmeat 3y agoyep. good question! no idea
- nickmc 3y agoIn the UK, the CAA approves procedure design organisations - listed here [0]. There are 8 and several are only a couple of people. Even the large ones probably only have 4 people max actual IFP designers. The total involved in the UK probably does not exceed 25. You could scale US according to the number of IFP airports. [0] https://www.caa.co.uk/data-and-analysis/approved-persons-and-organisations/approved-organisations/approved-instrument-flight-procedures-design-organisations/ https://www.caa.co.uk/data-and-analysis/approved-persons-and...
- Twirrim 3y agoa relative of mine was involved in developing the eSIM standards, working with a consortium of telcos and phone manufacturers. For whatever reason, docs like that one are something he just loves to both read and produce. Diving in deep to a topic, finding every rough edge, corner case, undefined bit of behaviour and getting consensus from involved parties. I think I'd rather bash my head repeatedly against a brick wall, but somehow he finds it a lot of fun.
- dylan604 3y agodidn't you just describe developing a large scale software package that is user facing?
- ajcp 3y agoI'm a Solutions Architect -albeit in software- and I LOVE documentation like that. I will spend days and weeks consuming esoterica on even the most "simple" of specifications (looking at you JSON). I'll spend hours just ruminating after reading a single concept for a protocol. Partly because I enjoy it and partly because it's my job. I need to understand not just how the code works, but the implications and implementations of it. I also need to be able to explain all of it at varying levels of detail in both technical and non-technical terms.