I have something of a childlike wonder for creation, for making things and being able to say 'look, I did this!'
An admirable mark of a great engineer! I cant speak for all employers, but my co founder and I have a soft spot for engineers who have such moments.
But where does it end? Where do I stop and realize I have to settle for one?
On the employer side, no you do not. Just keep growing! At what excites you!
Discuss with yourself and your team leader if you should focus on one area first (and go back to others later), or keep going along learning everything. There is no right answer.
For any company, there will be a large variety of work that comes down the pipeline, just to point to uilicious.com, internally our devs do ...
social marketing (yes our devs do take part in events),
lots of boring CRUD (how many times is it now?),
hard math / infra (our internal test engine does some crazy stuff)
And because different companies will have very different compositions of workload, there is never a right or wrong answer to this ... for even the most random of skills (like how origami, ended up being used in solar powered satellites )
The MMORPG gaming analogy I sometimes use is that everyone is equipped with skills across different elemental types, they can go learn broadly new elemental skills from a huge skill tree. Or to min-max and focus onto one skill path.
With all of us forming a team for guild raids, that faces random monsters and obstacles on a quest to save the world (or kingdom, timeline, etc).
As the "team leader" organizing the team, I then have to recruit party members to align accordingly to the challenges. And as per most RPG games there isnt 1 single answer.
For most startups : I can have the team consist mostly of generalist (a little of everything here and there), but when the level 99 fire element monster comes which none of them can damage, we call upon our level 99 ice mage (who cant do anything else, or a temp part timer for this quest only!). Who would not survive with the generalist protecting the glass canon.
Or I can have a team who is maxed out in 1 element each, and swapping roles when needed.
Or some complex mix inbetween the 2
Unfortunately, just like in some RPG's games, this can also mean that certain team members can end up as "dead weight" not because they are bad (their maxed on 1 element), but the company has entered into a new region, and they have bad compatibility with the given challenges. One way to avoid the above is to discuss with your team leader or company, and see if the alignment make sense for you (do not force yourself, you own your own development)
And that's alright, because they will then be able to find another team who they can help better.
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.
I'm 100% here for that MMORPG analogy holy moly! It feels like everything just clicked into place in my brain - that makes so much sense :O THANK YOU. Gods above I cannot tell you how much I'm going to call upon that when I'm doing team building and project management work in the future. :D
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.
An admirable mark of a great engineer! I cant speak for all employers, but my co founder and I have a soft spot for engineers who have such moments.
On the employer side, no you do not. Just keep growing! At what excites you!
Discuss with yourself and your team leader if you should focus on one area first (and go back to others later), or keep going along learning everything. There is no right answer.
For any company, there will be a large variety of work that comes down the pipeline, just to point to uilicious.com, internally our devs do ...
And because different companies will have very different compositions of workload, there is never a right or wrong answer to this ... for even the most random of skills (like how origami, ended up being used in solar powered satellites )
The MMORPG gaming analogy I sometimes use is that everyone is equipped with skills across different elemental types, they can go learn broadly new elemental skills from a huge skill tree. Or to min-max and focus onto one skill path.
With all of us forming a team for guild raids, that faces random monsters and obstacles on a quest to save the world (or kingdom, timeline, etc).
As the "team leader" organizing the team, I then have to recruit party members to align accordingly to the challenges. And as per most RPG games there isnt 1 single answer.
For most startups : I can have the team consist mostly of generalist (a little of everything here and there), but when the level 99 fire element monster comes which none of them can damage, we call upon our level 99 ice mage (who cant do anything else, or a temp part timer for this quest only!). Who would not survive with the generalist protecting the glass canon.
Or I can have a team who is maxed out in 1 element each, and swapping roles when needed.
Or some complex mix inbetween the 2
Unfortunately, just like in some RPG's games, this can also mean that certain team members can end up as "dead weight" not because they are bad (their maxed on 1 element), but the company has entered into a new region, and they have bad compatibility with the given challenges. One way to avoid the above is to discuss with your team leader or company, and see if the alignment make sense for you (do not force yourself, you own your own development)
And that's alright, because they will then be able to find another team who they can help better.
I'm 100% here for that MMORPG analogy holy moly! It feels like everything just clicked into place in my brain - that makes so much sense :O THANK YOU. Gods above I cannot tell you how much I'm going to call upon that when I'm doing team building and project management work in the future. :D
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