The Greatest Developer Fallacy Or The Wisest Words You’ll Ever Hear?

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.

Wise words spoken by the foolish are foolish.

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.

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.

CAR ANALOGIES

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.

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.

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.

You can learn any number of things just in time, but have a core set of competencies which you invest in, upfront.

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.

PS: "We all communicate really well". I wholeheartedly disagree! I think you just got lucky with where you worked.

30 years into this career, and I'm still doing that.

Also: Don't budget books (or reading time).

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.

(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.