It seems to me that the specialist that's most needed is the "full stack programmer", the guy who understands how all parts of the system interact -- because without a holistic view, you're lost at sea when it comes to scalability, reliability, performance and security.
I'd also say that more projects fail because of problems with "soft skills" and project management than from anything else. When your marketing division has no idea at all of what can be produced at what time and how much it will cost, you're doomed.
At some shops I've seen, you'd think that the "software manager" is an endangered species. "Management" is selected by a caste system which excludes software people. I think there is a great need for specialists in software management, but many places won't hire them because they don't want to spend the $ and don't want to deal with an assertive software person.
In these lean times (the last 20 years), many companies aren't interested in hiring specialists but would rather hire junior people and take their chances. If you really do need a specialist, it often makes sense to bring in an outside consultant... If you've got some piece that fits in a box and will really stay inside that box.
As for developing your skills it's something you always ought to be doing. I think the HN crowd fetishizes learning exotic new languages -- that's fine, but that's not the way I prefer to do it. Lately I've found that my C#, PHP and Javascript are looking more and more like LISP. Lately I've read about algorithms used in genomics, parsing, and about description logics. On the other hand, I'm also learning salesmanship, getting a ham radio license, and mapping trails in the forests near me.
Part of developing new skils is reading books, getting certifications and stuff like that, but there's no substitute for "going where no man has gone before" and trying to build some of your own systems that push the state of the art... Do that, and pretty soon you'll find there aren't any books or papers about what you're working on.
It seems to me that the specialist that's most needed is the "full stack programmer"
It used to be like this, back in the day. When I started doing Java professionally (1996, yes really) anyone who did Java did all of Java and could reasonably be working on a GUI one day, a network server the next, databases, native code, compiler internals...
Fast forward to say 2001 and the game has changed, now there are specialists, I did JDBC and Swing and never touched mobile edition, and barely touched EJBs, etc etc. It just got too big. Greybeards I know tell me stories like that on the Mac, System 6 was the last MacOS where one person could hold the entire thing in his or her head. Come System 7 you had to specialize.
Maybe nowadays you can be full-stack in something relatively simple, e.g. LAMP but even then, the L is Linux and the guys who do both LAMP websites and Linux kernel hacking you could probably count on one hand.
Amen - I forget the interview, but there was a great interview with Steve Jobs where he said that to make great things happen, you need a broad range of life experience. That tends not to apply to engineers who stay in front of the computer all day.
I can tune apache s maxClients and most crockfords javascript good practices are just natural now, not to mentional the whole lot in between. but at interview this never helps me.
It's wise to learn by doing things that interest you and picking up the required skills as you go. It may be wise to avoid wasting time learning things you haven't encountered a need for that are on somebody's list of "stuff you should know" since there's legitimate disagreement over what people should know, and you only have one lifetime. A potential problem is that you may not know what it is you're missing until you learn it. A lot of CS fundamentals are like that; I recently saw somebody invent association lists in C# because he didn't know what a hashtable was. Just in time learning is a useful idea, but dangerous. Use it, but not to the exclusion of all other methods of deciding what to learn, and be careful with it.
It depends on what your goals are and what you're trying to accomplish.
If you are trying to get on a high-budget Formula One team, of course you're going to want to be the Best Wrench Mechanic Ever. The racing team already has the Best Gas Filler Ever, the Best Windshield Cleaner Ever, and even the Best Sign Holder Ever. You're filling a well-defined spot on the team, and your role is to shave 2 tenths of a second off of the pit time, which can result in millions of dollars for your team.
If you're just trying to win your local autocross league (and then work your way up to the regional leagues, and then maybe even some national racing), you're going to want to be reasonably good with all of the tools, because you don't have the multimillion dollar budget and your goal is just to get your car on the track to see what happens.
My recipe/plan to succeed as a generalist is to fully master the most fundamental building blocks; things that do not change so often. Practice algorithms, implement a lexer, write a web server, a compiler, build a computer, an i/o board, your own network cables etc. Your universe of discourse grows exponentially and it'll be a lot easier to pick up the things that change at a more rapid pace, as you need them.
I spend most of my time going full-speed and the list of things I'd like to learn continues to grow despite my best efforts to get through it. "I'll learn it when I need it" isn't a cop-out, it's a hard reality in an industry that generates useful skills faster than anyone can possibly acquire them.
Becoming a specialist is also a bit of a risk and sacrifice on the part of an individual. The better you become at something, the more narrow your focus. The more narrow your focus, the fewer career options you have. I suspect that's why people will list like 8 different languages on their resume (that and you have to know like 3 or 4 to build a web site... still).
Nothing can take the place of simple enthusiasm and curiosity. If you're in tech because you like building systems, programming, security, or what have you -- chances are you work on your own projects at work or on your own time that help you learn. The idea is that you become good at what you do instead of becoming the most knowledgeable person about one specific thing.
It has become a mantra for our whole industry which hasn't changed said industry for the better.
What is our primary responsibility, to make our whole industry better or to make our customers better? Sometimes, there are tradeoffs.
Why bother, it will be replaced, superseded, marginalised and out of fashion before you're half way done.
Why bother when you will never use it? There's enough to do already without learning every nuance of every tech out there. Lots of software running the world is using only 10% of the tools of the given technology.
...developers differentiating themselves based on soft skills rather than developer skills – seems a bit twisted.
Developers differentiate themselves on what needs to be differentiated. Sometimes that's deep tech. Sometimes it's shallow tech and deep domain knowledge. Sometimes it's good people skills. The only thing "twisted" is thinking that any one is better than the others.
You seem like an expert without ever being an expert...
Only to your customers, but not to other experts. One of the best pieces of advice I ever learned was, "All you have to do is stay one step ahead of your customers. No one else really matters."
You can't learn something if you don't know it exists.
Absolutely! The question then becomes, "How do I find out what exists?" There are several ways. Reading a book is one. Getting your ass kicked by a competitor is another. Which do you think gets more attention?
...there is a billion lines of code out there right now which can be replaced with a million lines of faster, cleaner, better code simply because whoever wrote it didn't know what they didn't know.
No question. Who's going to pay for that?
...skimming subjects doesn't allow you to retain anything, our brain doesn't work that way.
Our brain learns best by doing. If HaveProblem + SkimmingSubjects leads to Doing, then SkimmingSubjects serves it purpose. We can't possiblity learn everything. The trick is knowing what to learn based upon the problem at hand and the stuff we pick up along the way. Skimming is an invaluable tool to help make these choices.
OP brings up lots of great points. If the existing code base is any indication, our industry really needs to advance. Too many developers are building too much stuff with the same hammer and screwdriver from years ago.
Nothing scares me more, however, than the vision of developers becoming academics, learning the technology du jour and still not being able to build what's needed by the great masses. We've been down that path before and it takes a long time before anything is pretty. There has to be a middle ground.
There's nothing wrong with focusing completely on your customers - after a couple of years you're likely to find yourself a good businessman and a good-enough coder. There is something wrong with just coasting as a programmer, though: after a couple of years, you'll still just be a good-enough coder.
I read this when it was posted earlier this year, and I see where the author is going ... but I also see how he could be misunderstood.
All he's saying is that you should try new things, take some time out and actually build something in a technology that interests you ... not just read about them.
Its the only way to actually expand your skillset and your programming IQ. The really great developers that I've met do this constantly ... Erlang? Check. Haskell? ... been there! Clojure? ... built a webserver in it last night ... for fun. Node.js? ... built an analytics program in it with mongo db while I was on vacation.
Of course some of us aren't blessed that kind of ability to pick up and be productive in a language in a weekend, but it just means that we just need to be more selective with the things we commit to trying out. As with all things ... doing it more often actually makes it easier to pick up new things as they come up, since you get used to the mechanics of actually trying things out.
What I've found is that the 'cross pollination' of ideas from the different languages/frameworks you use will make you a better programmer across the board.
So yeah, don't wait till you actually need a skill to scramble around trying to pick it up ... do half the leg work up front and you'll reap the dividends down the road. Thats how I see it anyway.
I want to learn all sorts of new things, but my problem is mostly an inability to decide on what to learn next. For a while, I was looking at Django, and then decided Rails probably had more traction, but then thought "wait! Perhaps node.js is the next big thing and I should start looking at that!" So I tend to graze and have a very shallow understanding of almost everything.
I don't understand this article. I learn as much as I have time to learn while still getting all my work done. I'm constantly trying new things and developing my expertise on a number of topics that I don't currently consider myself an expert in. It seems like other people are doing this too so what's the issue?
The most valuable thing I learned in school, kindergarten through university, was how to learn. If my learning had stopped at the time I finished high school, I would have had only enough to survive; if it had stopped at the time I finished college, I would have had enough to hold down a steady job; but in neither case would I be doing what I do today.
In the same way, a developer that can only reuse code from a Google search can survive, a developer that can program decently in a number of languages can hold down a steady job, but a developer that can differentiate themselves by their ability to deeply understand a business need or language or technology can excel.
Learning for learning's sake is useful onto itself--the brain muscles that are exercised when a person learns the violin are the same that become exhausted learning deep domain knowledge.
Different people like different things. Some people like to study computer science for its own sake, do research, develop algorithms, AI, machine learning, natural language processing, graphics, etc. A lot more people just want to apply their software knowledge to build a product of value to society. Among those, most do not require heavy algorithms or optimizations. It's just data in data out. Supply and demand are well balanced proportionally among the various sub-needs, but the field in general is undersupplied.
PS: "We all communicate really well". I wholeheartedly disagree! I think you just got lucky with where you worked.
But, if that was the way, every old person would be an expert in a whole bunch of stuff and that is emphatically not the case.
Emphatically, huh? I guess it's not so obvious to me. Talk to an intelligent, clearheaded old person, and you may discover that they are experts in a thing or two.
Unfortunately, the vast majority of older (65+) people, despite their experience, are simply unable to keep up with technology. On that scale age matters, and 30yo can't be compared to 65yo. We all will be there.
That's neither good nor bad. That's just the way it is.
However, I know people that successfully started their startup company in their 50's.
Whether or not older people, as a rule, can perform as well as a 30yo isn't really my point -- I suppose some can, and most cannot. My point was that I don't agree that the vast majority of people who make it to old age have never become expert at anything. Older folk mostly want to talk about their youth and their grandkids, but that doesn't mean they really don't know anything other than that. They're just no longer interested (or think you aren't interested) in things they are or were experts in. Those subjects may well now be obsolete, of course; I'm not denying that.
I agree with you: what do people think happen to the brightest and the best from a few decades ago? They grow old and retire, of course. Perhaps the reason they don't sound like experts to younger folks is because they've become experts in a field we don't care about: how to view life once you have the proper perspective. After a certain point, how many lines of code or how fast your site can scale takes a back seat to how to lower your blood pressure and how to maximize your enjoyment from "simple" pleasure like family and food.
(1) Progress. The progress in computing he is talking about is not very important and not much worth following in detail. Bluntly programming is still:
(a) for needed data, select data types and name and allocate space,
(b) manipulate the data with expressions, assignments, if-then, and do-while,
(c) have some too simplistic approaches to exceptional condition handling that risk allocated resources not freed.
(d) simplistic concurrency tools that are hard to debug and have poor means to detect and resolve deadlocks,
(e) get modularity as needed in 'divide and conquer' by calling functions, methods, APIs, etc., standard old call-return 'semantics'.
So, no wonder given a new flavor of the month of syntactic sugar, people learn it only when they have to.
(2) He recognizes that he is asking people to learn things that go out of date too quickly. Good. But he is too accepting of having people waste so much time.
(3) For knowledge that has usefulness longer than the life of a butterfly, he retreats to communications skills?
So, net, he doesn't know where the powerful, lasting knowledge is.
So, what might such knowledge be?
Okay, start with a problem to be solved where we need to write some software. Okay, from 40,000 feet up, this software will take in some data, manipulate it, and deliver results.
So, ask, do you understand well enough now how to do those manipulations at least in principle by hand?
If so, then likely can start designing and then coding. Some huge fraction of commercial computing has been like this.
Else, for a hint on what such knowledge might be, have to ask, how will we determine the needed data manipulations? A huge fraction of computing in science, engineering, and for US national security has needed and often found answers to this question.
If computing is going to move past the merely old, and manual, then the "else" above needs to be followed.
By analogy, in part he's thinking that the main issue in good cooking is the shape of the chef's knife and the material in the cutting board and ignoring what is between the ears of the chef. That is, he doesn't understand cooking past what is routine with a knife and cutting board.
I'd also say that more projects fail because of problems with "soft skills" and project management than from anything else. When your marketing division has no idea at all of what can be produced at what time and how much it will cost, you're doomed.
At some shops I've seen, you'd think that the "software manager" is an endangered species. "Management" is selected by a caste system which excludes software people. I think there is a great need for specialists in software management, but many places won't hire them because they don't want to spend the $ and don't want to deal with an assertive software person.
In these lean times (the last 20 years), many companies aren't interested in hiring specialists but would rather hire junior people and take their chances. If you really do need a specialist, it often makes sense to bring in an outside consultant... If you've got some piece that fits in a box and will really stay inside that box.
As for developing your skills it's something you always ought to be doing. I think the HN crowd fetishizes learning exotic new languages -- that's fine, but that's not the way I prefer to do it. Lately I've found that my C#, PHP and Javascript are looking more and more like LISP. Lately I've read about algorithms used in genomics, parsing, and about description logics. On the other hand, I'm also learning salesmanship, getting a ham radio license, and mapping trails in the forests near me.
Part of developing new skils is reading books, getting certifications and stuff like that, but there's no substitute for "going where no man has gone before" and trying to build some of your own systems that push the state of the art... Do that, and pretty soon you'll find there aren't any books or papers about what you're working on.