narrow-and-deep or shallow-but-wide .. what is the best strategy ?
-
There is so much in IT these days (so many languages, frameworks, architectures, platforms etc.) that it is unrealistic for a person to have a reasonable knowledge of all of it. That being the case, which is the best strategy to pursue: pick a narrow field and develop a deep knowledge about it or pick a set of fields and develop shallow (but non-zero) knowledge about them all?
I think I'm going to go with the 'wide' crowd. a) if job-hunting time comes up, you're not locked into a certain field. b) for most jobs, the really, really, deep knowledge isn't used very much. As others have said, on that rare occasion you need to get deeper, you certainly can. That being said, it's important to understand yourself, and what you like. I enjoy the middle and back-end more, making sure the data is persisted properly. Don't care too much about css, for example. I know enough to get by, and make stylistic changes, but it's neither something I enjoy nor am great at. So pretty shallow there. (Although I am learning more and more about manipulating the document via jquery, that's pretty fun.) I have a pretty deep knowledge on the SQL side, which I like better. I guess the point of this rambling is that being a full-stack developer is best long-term. Most organizations simply don't have the resources to have specialists; you're going to have to figure out each bit anyway.
-
There is so much in IT these days (so many languages, frameworks, architectures, platforms etc.) that it is unrealistic for a person to have a reasonable knowledge of all of it. That being the case, which is the best strategy to pursue: pick a narrow field and develop a deep knowledge about it or pick a set of fields and develop shallow (but non-zero) knowledge about them all?
-
There is so much in IT these days (so many languages, frameworks, architectures, platforms etc.) that it is unrealistic for a person to have a reasonable knowledge of all of it. That being the case, which is the best strategy to pursue: pick a narrow field and develop a deep knowledge about it or pick a set of fields and develop shallow (but non-zero) knowledge about them all?
Just a few observations.. larger companies/teams are skewed toward hiring narrow-deep specialists. Smaller companies need shallow-wide people, but never seem to realize it. They mostly seem to try to hire narrow-deep and end up settling for shallow-wide for a variety of reasons. I've yet to see any company actually looking for a shallow-wide person.
We can program with only 1's, but if all you've got are zeros, you've got nothing.
-
There is so much in IT these days (so many languages, frameworks, architectures, platforms etc.) that it is unrealistic for a person to have a reasonable knowledge of all of it. That being the case, which is the best strategy to pursue: pick a narrow field and develop a deep knowledge about it or pick a set of fields and develop shallow (but non-zero) knowledge about them all?
Companies need both, and this is part of the IT Failure rate in my opinion. Management always goes back to the same team, which may have only one view. Then they give them a project which requires both. I am a shallow and wide person (Not just personality and girth either!) :-) But I go DEEP in some areas (e.g. DB optimization) But we build a team that has both. My current team has two PhDs capable of going so deep it scares me. A manager who goes much wider than I do, and always looking for the next piece to sell. My role, in understand the user/company requirements, choosing a metaphor, and putting the right people on the team for implementation. So the question you pose is tough. It is NOT an OR question to me. It is a WHEN question to me. When should I focus on being DEEP on understanding some technology (natural proclivity), and when should I stay shallow. If you think about it, most developers are shallow on DB Architecture (in the truest sense of building a scalable solution for thousands to tens of thousands of users). Sure they can do tables, views, stored procs, and occasionally and indexing approach. But that SHOULD NOT be their job. How many times do you need that skill. Then you have a client who needs to scan thousand of items, and you have developers who jump in (shallow) and throw together the scanning solution that makes the scanners lives miserable. They have deep knowledge on the programming side, but no clue as to what it feels like to scan for 8hrs every day, and how long fixing a dual page feed issue really takes. Or how to make it easy to detect. So my answer is. Be deep enough for every task. Start by being shallow, and staying shallow until you know the entire area you are responsible. Delay all design decisions until you can see the big picture flow (may not be exact), but strive to see the clients actually working the system. Then get deep as required.
-
There is so much in IT these days (so many languages, frameworks, architectures, platforms etc.) that it is unrealistic for a person to have a reasonable knowledge of all of it. That being the case, which is the best strategy to pursue: pick a narrow field and develop a deep knowledge about it or pick a set of fields and develop shallow (but non-zero) knowledge about them all?
In terms of IT, go shallow, allowing you to adapt quickly to changes in technology. But also go deep in some other specialty where IT is applied. My secondary speciaĺty was enterprise resource planning, with a focus on service and make-to-order industries. The combination has kept me going for over 50 years.
The difficult may take time, the impossible a little longer.
-
There is so much in IT these days (so many languages, frameworks, architectures, platforms etc.) that it is unrealistic for a person to have a reasonable knowledge of all of it. That being the case, which is the best strategy to pursue: pick a narrow field and develop a deep knowledge about it or pick a set of fields and develop shallow (but non-zero) knowledge about them all?
You can't do wide very well. That is, your brain will explode if you try to become even basically proficient with too many divergent fields (AI with Prolog, Stats for Big Data, C++ and OO Programming, and a little COBOL just in case). Doing narrow is fraught with risk. It amounts to predicting the future 45 years in advance. Absolutely nobody is any good at that. You can be a kick-ass VB programmer, but that won't help you when Microsoft decides to build a whole new language to supplant VB. The best you can do is pick an area of concentration that seems sustainable. You can decide to be a business programmer. You learn Windows, C#, Java, and probably some javascript, and keep your eyes on the horizon looking for the next thing. You can be a Linux programmer, which means C and C++ and javascript, and watch out for packagers and virtualization. You can be a systems programmer, which means Windows AND Linux, and C++, but watch out for D and Rust. You can't usefully predict the future out to the end of your career. So you take smaller bites (bytes?) You ask yourself, "How does this job prepare me for the job after that?" and only take jobs for which the answer is good. You spend less of your free time playing Call of Duty XVI and more of it reading dry, technical journals. You learn new things just as soon as they become relevant, like Android programming. And you leave your comfortable job for a job as an Android programmer, because that skillset is modern, and the skills needed for your comfortable job are not absolutely leading edge. Get comfortable for too long, and you wake up one morning to find you're obsolete, with no choice other than staying in your current job until your company decides to downsize.
-
You can't do wide very well. That is, your brain will explode if you try to become even basically proficient with too many divergent fields (AI with Prolog, Stats for Big Data, C++ and OO Programming, and a little COBOL just in case). Doing narrow is fraught with risk. It amounts to predicting the future 45 years in advance. Absolutely nobody is any good at that. You can be a kick-ass VB programmer, but that won't help you when Microsoft decides to build a whole new language to supplant VB. The best you can do is pick an area of concentration that seems sustainable. You can decide to be a business programmer. You learn Windows, C#, Java, and probably some javascript, and keep your eyes on the horizon looking for the next thing. You can be a Linux programmer, which means C and C++ and javascript, and watch out for packagers and virtualization. You can be a systems programmer, which means Windows AND Linux, and C++, but watch out for D and Rust. You can't usefully predict the future out to the end of your career. So you take smaller bites (bytes?) You ask yourself, "How does this job prepare me for the job after that?" and only take jobs for which the answer is good. You spend less of your free time playing Call of Duty XVI and more of it reading dry, technical journals. You learn new things just as soon as they become relevant, like Android programming. And you leave your comfortable job for a job as an Android programmer, because that skillset is modern, and the skills needed for your comfortable job are not absolutely leading edge. Get comfortable for too long, and you wake up one morning to find you're obsolete, with no choice other than staying in your current job until your company decides to downsize.
AI with Prolog, Stats for Big Data, C++ and OO Programming
Add to it: C#, C, Rust, Perl, Functional Programming with Haskell, F# and Lisp, a lot of computer science like Compilers, Virtual Machines and theoric things like Lambda Calculus, Type Theory, Category Theory. And a lot of many more languages like Python, Ruby, ES5/6, Lua, Erlang, Scala. I also play with Idris, Coq, Sisal, Clojure and Objective C. Brain still not exploded, must be because I refuse to learn Cobol. I have hobbies like Information Security, Cryptography and Music (that I've just started learning and is fun), and I am a gamer too. All that just leave no time for social life though, that's the price (who need it when I can have all that fun).
-
AI with Prolog, Stats for Big Data, C++ and OO Programming
Add to it: C#, C, Rust, Perl, Functional Programming with Haskell, F# and Lisp, a lot of computer science like Compilers, Virtual Machines and theoric things like Lambda Calculus, Type Theory, Category Theory. And a lot of many more languages like Python, Ruby, ES5/6, Lua, Erlang, Scala. I also play with Idris, Coq, Sisal, Clojure and Objective C. Brain still not exploded, must be because I refuse to learn Cobol. I have hobbies like Information Security, Cryptography and Music (that I've just started learning and is fun), and I am a gamer too. All that just leave no time for social life though, that's the price (who need it when I can have all that fun).
Luiz Felipe Stangarlin wrote:
Brain still not exploded, must be because I refuse to learn Cobol.
Maybe your proficiency is not all the way up to basic :-). Joking aside, I have programmed in prolog. That doesn't make me good enough to take on a professional project. It took me about 2 full-time years to achieve basic proficiency with C++. Anyone who says they became proficient in C++ in 3 months is lying or delusional, and there are plenty of these people. Can't say how long it takes to be proficient with Big Data. Betcha you'd want a year of college stats though. Proficiency is way more than just map/reduce. The problem with proficiency is that it takes time. There's way too much stuff out there to learn it all, so any investment in learning is a bet on the direction of the future. Unless you want to take only entry-level jobs for the rest of your life, you have to pick something to get good at. It's very challenging over a 45 year career (!!) to keep guessing the future correctly, so that the things you get good at continue to be relevant. You only have to guess wrong once or twice during that time, to find the world has passed you by. Then you can keep working with technologies you have mastered, but they gradually become obsolete. Or you can retrain on a new technology, but that often means a big pay cut.
"Mama, don't let your babies grow up to be software developers."
-
Luiz Felipe Stangarlin wrote:
Brain still not exploded, must be because I refuse to learn Cobol.
Maybe your proficiency is not all the way up to basic :-). Joking aside, I have programmed in prolog. That doesn't make me good enough to take on a professional project. It took me about 2 full-time years to achieve basic proficiency with C++. Anyone who says they became proficient in C++ in 3 months is lying or delusional, and there are plenty of these people. Can't say how long it takes to be proficient with Big Data. Betcha you'd want a year of college stats though. Proficiency is way more than just map/reduce. The problem with proficiency is that it takes time. There's way too much stuff out there to learn it all, so any investment in learning is a bet on the direction of the future. Unless you want to take only entry-level jobs for the rest of your life, you have to pick something to get good at. It's very challenging over a 45 year career (!!) to keep guessing the future correctly, so that the things you get good at continue to be relevant. You only have to guess wrong once or twice during that time, to find the world has passed you by. Then you can keep working with technologies you have mastered, but they gradually become obsolete. Or you can retrain on a new technology, but that often means a big pay cut.
"Mama, don't let your babies grow up to be software developers."
Perhaps I have proficiency with programming in general (solid theory) and can take new languages very easy, don't know, I know that I like to study and use many languages. Yes I have proficiency with C and C++, but I'm using both of them on work for at least 4 years now. C# and F# I used (still use them) for more than 8 years. Dynamic language come and go, but they are easy to grasp in some months. Perl I don't have a deep understanding of every behavior, but I can write scripts and read if I need, nothing that you can't get in months if you really want to go deeper. Rust I'm not using on "real jobs", but it's not like C++ or C, I'm gaining proficiency very fast in it. Yes, all of that takes too much time, I'm just programming for 13 years now, that is half my life (you must count that I don't have any social life, I just study and program and sleep). C++ is the hardest, 4 years in it and I think I can grasp 60% of it (I maybe wrong, I'll only see more years from now). Is every C++ delusional? From that those languages excluding the mathematical ones like Coq, Haskell, they are hard and fun, but I don't really do jobs with them, C++ is the most complex and slow to learn. C++ is a monster to learn, but its a fun game, you never stop discovering "hidden" things, I love/hate it for that complexity. You are right about guessing the future, that's why I try to spread my knowledge on various languages by doing projects with them, but in the end there's those 5 or 6 languages that must handle to the core to do the job. I still think you need at least 4 years to get C++, other languages are like 2 years or less. Perhaps every C++ starting programmer is delusional because of that, everyone immense underestimate C++. I think I still do that, even with years doing it.
-
Perhaps I have proficiency with programming in general (solid theory) and can take new languages very easy, don't know, I know that I like to study and use many languages. Yes I have proficiency with C and C++, but I'm using both of them on work for at least 4 years now. C# and F# I used (still use them) for more than 8 years. Dynamic language come and go, but they are easy to grasp in some months. Perl I don't have a deep understanding of every behavior, but I can write scripts and read if I need, nothing that you can't get in months if you really want to go deeper. Rust I'm not using on "real jobs", but it's not like C++ or C, I'm gaining proficiency very fast in it. Yes, all of that takes too much time, I'm just programming for 13 years now, that is half my life (you must count that I don't have any social life, I just study and program and sleep). C++ is the hardest, 4 years in it and I think I can grasp 60% of it (I maybe wrong, I'll only see more years from now). Is every C++ delusional? From that those languages excluding the mathematical ones like Coq, Haskell, they are hard and fun, but I don't really do jobs with them, C++ is the most complex and slow to learn. C++ is a monster to learn, but its a fun game, you never stop discovering "hidden" things, I love/hate it for that complexity. You are right about guessing the future, that's why I try to spread my knowledge on various languages by doing projects with them, but in the end there's those 5 or 6 languages that must handle to the core to do the job. I still think you need at least 4 years to get C++, other languages are like 2 years or less. Perhaps every C++ starting programmer is delusional because of that, everyone immense underestimate C++. I think I still do that, even with years doing it.
Not every C++ dev is delusional, just the ones who think they can pick it up in six weeks because that's how long it took them to learn Basic. I've been coding in C++ full time for 20+ years, (35 years altogether +/-), and I still have to run to keep up. I think the complexity becomes less and less troubling with time, and you see an inner regularity to it. I used to think of myself as a broad-not-deep person, but it's hard to maintain that lie with my career looking like it does. It's interesting, C++ was very relevant in the 1990s, then Microsoft and Sun tried very hard to kill it in the 2000s, but could not get applications written in more dynamic languages to scale, so C++ made a big comeback. The moral is, even if you can predict the future 20 years in advance, you may not be right 10 years off.