This is "what an applications programmer does for a living". Its a series of steps to accomplish a domain-specific task. Which is fine, that's what almost all programmers do.
Other developers (e.g. systems programmers, common library developers, device driver hacks) do something almost completely unrelated. They look for nuggets of functionality that can be used by applications. Like "make a list of things to do, then execute them in order". Or "accept instructions from a program, but authenticate the source". Or "make a concordance of all the terms in a problem space, for use by other code".
And making these pieces is also not at all like the process described. Its more like "look through endless manuals for ill-described OS features and diddle with them black-box style until you find out how they really work, then stitch them together. Test for time-domain anomalies (internal object lifetime; task termination order etc) and prove you have covered all the bases. Try to make it idiot-proof. Create a document that describes how to use your invention, using analogies and examples because few will have the attention span/willingness to actually delve into it.
Secretly plot the torture and murder of the web guy who redesigned the login page and got piles of credit while your widget gets a perfunctory "ok" from management. Despite the login page having no effect and your widget saving the company thousands of dollars.
Other developers (e.g. systems programmers, common library developers, device driver hacks) do something almost completely unrelated. They look for nuggets of functionality that can be used by applications. Like "make a list of things to do, then execute them in order". Or "accept instructions from a program, but authenticate the source". Or "make a concordance of all the terms in a problem space, for use by other code".
And making these pieces is also not at all like the process described. Its more like "look through endless manuals for ill-described OS features and diddle with them black-box style until you find out how they really work, then stitch them together. Test for time-domain anomalies (internal object lifetime; task termination order etc) and prove you have covered all the bases. Try to make it idiot-proof. Create a document that describes how to use your invention, using analogies and examples because few will have the attention span/willingness to actually delve into it.