I'm on the faculty at Boston University in the computer science department, where I teach software engineering, intro courses, and application architecture and development. Also a bit of a Deadhead.
This is fine advice for your first year or so of your career. After that, you can quickly be pegged as 'that Laravel guy', and in the minds of your managers and colleagues, it's all you know. Moving up means that you have to move on, but you might not have a diverse enough CV to interest another employer.
My experience has been that the best colleagues have been those who have a really broad range of experience...they are able to pull from all of those when confronted with a new problem. IBM likes to talk about 'T'-shaped contributors, those who have broad, but not necessarily deep, experience, but are able to dive deep when they need to. That's the sort of person I would look for when hiring.
I like this: "IBM likes to talk about 'T'-shaped contributors, those who have broad, but not necessarily deep, experience, but are able to dive deep when they need to".
This is one of those very-well-described mental models. I just felt inspired to look up its origin:
The earliest reference is by David Guest in 1991.[1] Tim Brown, CEO of the IDEO design consultancy defended this approach to résumé assessment as a method to build interdisciplinary work teams for creative processes. In the 1980s and probably earlier, the term "T-shaped man" was used internally by McKinsey&Company for recruiting and developing consultants and partners, both male and female by then.
I've done everything from hardware design to drivers in (many flavors of) assembly to large COBOL programs to C++ monstrosities to async webbish APIS and websites and that's why I can jump in at any level if needed. Usually, I just see how the pieces go (or could go) together better than anyone with the kind of "focus" recommended in this article ever could.
I agree, maybe you need to do this early on to remain employable, but it's a self-defeating long-term strategy in a fast and always faster moving industry.
I think you're pretty right on with this comment Perry.
My first job was in a .NET environment, mostly writing and maintaining API integrations but my primary responsibility was improving/updating/maintaining an integration with an ERP system via a Windows service. I quickly became "the expert" in the ERP system integration and was the guy that got all of the calls escalated from support. I still occasionally get an email from the devs that took over the project for help.
My second job, I was looking for something different and ended up working in Salesforce. Completely different environment all the way down to the source control and OS I was working in. The lack of breadth hurt me moving to the new role.
Logic is logic, so that wasn't the hard part of the move. The hard part was picking up so many different technologies at once. It really was jarring and reshaped my thinking on the subject. Previously I focused on going as deep as I could with .NET to the detriment of my other skills. Currently I am focusing on gaining a broader understanding of the base technologies that are underpinning the majority of the "flavor of the week" technologies so I can pick them up faster in the future.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
< strokes white beard >
This is fine advice for your first year or so of your career. After that, you can quickly be pegged as 'that Laravel guy', and in the minds of your managers and colleagues, it's all you know. Moving up means that you have to move on, but you might not have a diverse enough CV to interest another employer.
My experience has been that the best colleagues have been those who have a really broad range of experience...they are able to pull from all of those when confronted with a new problem. IBM likes to talk about 'T'-shaped contributors, those who have broad, but not necessarily deep, experience, but are able to dive deep when they need to. That's the sort of person I would look for when hiring.
I like this: "IBM likes to talk about 'T'-shaped contributors, those who have broad, but not necessarily deep, experience, but are able to dive deep when they need to".
This is one of those very-well-described mental models. I just felt inspired to look up its origin:
en.wikipedia.org/wiki/T-shaped_skills
I've done everything from hardware design to drivers in (many flavors of) assembly to large COBOL programs to C++ monstrosities to async webbish APIS and websites and that's why I can jump in at any level if needed. Usually, I just see how the pieces go (or could go) together better than anyone with the kind of "focus" recommended in this article ever could.
I agree, maybe you need to do this early on to remain employable, but it's a self-defeating long-term strategy in a fast and always faster moving industry.
I think you're pretty right on with this comment Perry.
My first job was in a .NET environment, mostly writing and maintaining API integrations but my primary responsibility was improving/updating/maintaining an integration with an ERP system via a Windows service. I quickly became "the expert" in the ERP system integration and was the guy that got all of the calls escalated from support. I still occasionally get an email from the devs that took over the project for help.
My second job, I was looking for something different and ended up working in Salesforce. Completely different environment all the way down to the source control and OS I was working in. The lack of breadth hurt me moving to the new role.
Logic is logic, so that wasn't the hard part of the move. The hard part was picking up so many different technologies at once. It really was jarring and reshaped my thinking on the subject. Previously I focused on going as deep as I could with .NET to the detriment of my other skills. Currently I am focusing on gaining a broader understanding of the base technologies that are underpinning the majority of the "flavor of the week" technologies so I can pick them up faster in the future.