I agree with what their saying about the two different camps of development. A lot of developers I know, including myself, tend to have interests that align with one or the other.
However, the conclusion here should be applied to both camps. There is a ever growing mountain of resources to help the application (“plumber”) developers figure out and grow in their career path. There seems to be far less resources for the tooling and systems level developers though.
This article seems to shrug that off as a something a CS degree gets you, but that is far from a guarantee you’ll be able to land a job working on tools, complex systems, or systems level development.
On that note, any resources on the latter are appreciated.
Combined Skill = (1) education + (2) professional license(s) + (3) experience + (4) natural abilities + (5) natural/developed interests + (6) risk tolerance + (7) work ethics + (8) emotional affinity to particular system that’s already in place
So, basically, a combination of soft+technical skills.
The ‘job’, on a high level may emphasize, to some degree some of the above, and de-emphasize others. This depends on circumstances, regulations, etc.
The match between the ‘combined skill’ and the ‘job’. Clearly is not a ‘single’ variable problem.
Constructing a team for a particular job – is like one of those Constraint Optimization problems.
And just like in those problems, one can search for optimal solution for a very long time, or can settle for something faster, yet less optimal.
Everything, has a price…
I have observed large organizations with multi-billion internal IT budgets, going through this kind of ‘restructurings’ (that take a couple of years and cost millions of dollars’
(A) We will align software development with our ‘Business Unit’ leadership – because then, software produced will be more attuned to the needs of a particular business
(B) We will carve out a significant portion of our Software (may be all) to sit outside of business unit leadership, so that we have more ‘common’ stuff developed with higher quality and standards. It will cost less (because ‘common’) and work better.
–
One can argue that (A) would emphsize short-term goals in software development practice, and therefore will create jobs for certain types of people (quick thinkers, full stack, high risk tolerance, lack of strong/long term expertiese in particular technology areas).
The other (B) will create jobs for ‘framework’ folks, that are more specialized, etc.
I personally, do not find either (A) or (B) correct. While I have thought of alternatives, did not want to derail discussion in to that way, just wanted to illustrate the forces, that might driving different ‘weights/biases’ on the types of skills I described earlier.
–
I think though, to, largely, remove ‘business drivers’ from the consideration – our industry would have to have professional certifications, exam boards for various technical skills.
These skills would not be based on a particular tool of a day, but on a methods and standards of implementation.
The businesses creating the job opportunities, will also need to evolve into expecting much ‘less’ rework – more at the levels that we are accustomed in microcode/firmware.
–
The combination of business demands that emphasize less rework, safety (both physical and security), and, professional certifications – will create the juxtaposition of layers and educational structures that the article is advocating.
Today, constant changes in structure of the business (like (A) or (B) ), + the tolerance to buggy software, incomplete functionality in business software (and some tools)– makes it software to evolve/adjust quicker, but also creates the ‘oscillations’ and ‘mis-directions’.
Professional licensing has its own problems (from corruptions, to locking an individual into a particular frame) – and anything in between. So the larger legal/regulatory environments need to be considered (that, obviously, should involve international bodies/agreements as well).
I agree with what their saying about the two different camps of development. A lot of developers I know, including myself, tend to have interests that align with one or the other.
However, the conclusion here should be applied to both camps. There is a ever growing mountain of resources to help the application (“plumber”) developers figure out and grow in their career path. There seems to be far less resources for the tooling and systems level developers though.
This article seems to shrug that off as a something a CS degree gets you, but that is far from a guarantee you’ll be able to land a job working on tools, complex systems, or systems level development.
On that note, any resources on the latter are appreciated.
I am definitely more of the plumber type, but here’s some things that may be of interest to you:
Interesting thought and discussion.
I would define
Combined Skill = (1) education + (2) professional license(s) + (3) experience + (4) natural abilities + (5) natural/developed interests + (6) risk tolerance + (7) work ethics + (8) emotional affinity to particular system that’s already in place
So, basically, a combination of soft+technical skills.
The ‘job’, on a high level may emphasize, to some degree some of the above, and de-emphasize others. This depends on circumstances, regulations, etc.
The match between the ‘combined skill’ and the ‘job’. Clearly is not a ‘single’ variable problem. Constructing a team for a particular job – is like one of those Constraint Optimization problems. And just like in those problems, one can search for optimal solution for a very long time, or can settle for something faster, yet less optimal. Everything, has a price…
I have observed large organizations with multi-billion internal IT budgets, going through this kind of ‘restructurings’ (that take a couple of years and cost millions of dollars’
(A) We will align software development with our ‘Business Unit’ leadership – because then, software produced will be more attuned to the needs of a particular business
(B) We will carve out a significant portion of our Software (may be all) to sit outside of business unit leadership, so that we have more ‘common’ stuff developed with higher quality and standards. It will cost less (because ‘common’) and work better.
–
One can argue that (A) would emphsize short-term goals in software development practice, and therefore will create jobs for certain types of people (quick thinkers, full stack, high risk tolerance, lack of strong/long term expertiese in particular technology areas).
The other (B) will create jobs for ‘framework’ folks, that are more specialized, etc.
I personally, do not find either (A) or (B) correct. While I have thought of alternatives, did not want to derail discussion in to that way, just wanted to illustrate the forces, that might driving different ‘weights/biases’ on the types of skills I described earlier.
–
I think though, to, largely, remove ‘business drivers’ from the consideration – our industry would have to have professional certifications, exam boards for various technical skills.
These skills would not be based on a particular tool of a day, but on a methods and standards of implementation.
The businesses creating the job opportunities, will also need to evolve into expecting much ‘less’ rework – more at the levels that we are accustomed in microcode/firmware.
–
The combination of business demands that emphasize less rework, safety (both physical and security), and, professional certifications – will create the juxtaposition of layers and educational structures that the article is advocating.
Today, constant changes in structure of the business (like (A) or (B) ), + the tolerance to buggy software, incomplete functionality in business software (and some tools)– makes it software to evolve/adjust quicker, but also creates the ‘oscillations’ and ‘mis-directions’.
Professional licensing has its own problems (from corruptions, to locking an individual into a particular frame) – and anything in between. So the larger legal/regulatory environments need to be considered (that, obviously, should involve international bodies/agreements as well).