In almost any job I know of on earth. It helps a lot to somewhat know the work of the person directly in-front and behind any process queue. With diminishing rate of returns further down the chain.
So for a hypothetical fancy restaurant example.
Doorman > Waiter > Senior Chef (cook) > Junior Chef (prepare ingredients)
doorman/waiter benefits from knowing each other jobs, as it will help them coordinate the flow of human traffic (smoker section, VIP?) in and out of the restaurant to their appropriate tables.
Waiter/Senior Chef benefits from knowing each other jobs, as it will help them manage and communicate the demands of the consumers as the orders comes in (especially as ingredients starts running low)
Senior Chef / Junior Chef needs to know each other roles, as it will help in similar fashion ensure the flow of chopped fish/veg/meat/etc.
However for example, its really not needed for the junior chef to know the doorman job, as it will hardly improve each others performance. (in most cases, there will be exceptions)
So back the programming + design? Strictly speaking nope its not required, just like the restaurent example.
However with thousands of corporate and government website being built without a designer (due to budget constraints, and that its not meant to wow or sell to users, who instead must use the system, rather then choose to do so)
As you have experienced, while technically functional (if given a manual). It would have been so much more better, if the developer had some simple (not fancy) understanding of design.
So yea, it helps a lot =)
My goto for developers, is to point to material design guide, and ask they try to learn as much as they can from there.
Also one of the key points of "devops" is to bridge this chain, by letting each specialise individual educate across the team (eg. security, educating developers) to help improve the overall product. To help smoothen such flows
Anyway for dev here is the "typical chain"
UX
UI
API for UI
Data Services API
Database / Infra services (eg. network file servers)
30+ years of tech, retired from an identity intelligence company, now part-time with an insurance broker.
Dev community mod - mostly light gardening & weeding out spam :)
Thank you for bringing in an end-end delivery chain viewpoint! When I'm doing infosec awareness talks around the company, I emphasize the fact that a lot of security fails are because of gaps in that chain, disconnects in understanding each other.
This leads me to a thought - perhaps those of us who 'like a bit of everything' are actually well suited to infosec, able to see the gaps and help people close them? Does that appeal @queenoflilikoi?
Web developer at Greggs, UK with a proficiency in VueJS, Tailwind, and Storyblok, as well as other frameworks. I'm also passionate about web design, and mobile app development.
30+ years of tech, retired from an identity intelligence company, now part-time with an insurance broker.
Dev community mod - mostly light gardening & weeding out spam :)
I heard a similar viewpoint from what I see is a growing "trend" in security.
The change from typical "pen test" and "checklist", to "threat modeling", which takes a more incremental approach together with the development team.
Improving a few items at a time as part of the sprint. Across the whole chain (even the segments manually done by humans), onto what makes sense. Instead of overwhelming the team with a 1000 pointer checklist.
In such a setup, the security team is part of the process of the entire chain, and advice accordingly.
As such, recent recruitment by some of these infosec companies are more on generalist, than traditional "infosec graduates". Much to the horror of some of the recent infosec graduates, who is surprised to now realize they are expected to learn programming.
Web developer at Greggs, UK with a proficiency in VueJS, Tailwind, and Storyblok, as well as other frameworks. I'm also passionate about web design, and mobile app development.
Plugging in my comments to another question "Flipping the coin: Should developers design?", on why being a jack of all trade is "ok"
In almost any job I know of on earth. It helps a lot to somewhat know the work of the person directly in-front and behind any process queue. With diminishing rate of returns further down the chain.
So for a hypothetical fancy restaurant example.
Doorman > Waiter > Senior Chef (cook) > Junior Chef (prepare ingredients)
doorman/waiter benefits from knowing each other jobs, as it will help them coordinate the flow of human traffic (smoker section, VIP?) in and out of the restaurant to their appropriate tables.
Waiter/Senior Chef benefits from knowing each other jobs, as it will help them manage and communicate the demands of the consumers as the orders comes in (especially as ingredients starts running low)
Senior Chef / Junior Chef needs to know each other roles, as it will help in similar fashion ensure the flow of chopped fish/veg/meat/etc.
However for example, its really not needed for the junior chef to know the doorman job, as it will hardly improve each others performance. (in most cases, there will be exceptions)
So back the programming + design? Strictly speaking nope its not required, just like the restaurent example.
However with thousands of corporate and government website being built without a designer (due to budget constraints, and that its not meant to wow or sell to users, who instead must use the system, rather then choose to do so)
As you have experienced, while technically functional (if given a manual). It would have been so much more better, if the developer had some simple (not fancy) understanding of design.
So yea, it helps a lot =)
My goto for developers, is to point to material design guide, and ask they try to learn as much as they can from there.
Also one of the key points of "devops" is to bridge this chain, by letting each specialise individual educate across the team (eg. security, educating developers) to help improve the overall product. To help smoothen such flows
Anyway for dev here is the "typical chain"
Thank you for bringing in an end-end delivery chain viewpoint! When I'm doing infosec awareness talks around the company, I emphasize the fact that a lot of security fails are because of gaps in that chain, disconnects in understanding each other.
This leads me to a thought - perhaps those of us who 'like a bit of everything' are actually well suited to infosec, able to see the gaps and help people close them? Does that appeal @queenoflilikoi?
It may very well do, Phil. I'd have to look into what you mean by infosec: is it a shortened name for something? :)
Gah - sorry fell into the acronym trap: Information Security!
I heard a similar viewpoint from what I see is a growing "trend" in security.
The change from typical "pen test" and "checklist", to "threat modeling", which takes a more incremental approach together with the development team.
Improving a few items at a time as part of the sprint. Across the whole chain (even the segments manually done by humans), onto what makes sense. Instead of overwhelming the team with a 1000 pointer checklist.
In such a setup, the security team is part of the process of the entire chain, and advice accordingly.
As such, recent recruitment by some of these infosec companies are more on generalist, than traditional "infosec graduates". Much to the horror of some of the recent infosec graduates, who is surprised to now realize they are expected to learn programming.
Haha! I'll look into it :D