If you are learning anything other than that, you should be in academia not building real world applications. Out there in the industry you don't have 10 years to give towards a specific cause. Given the overall pace of our industry, the rate at which tools are changing, and age related discrimination.
In two ten year sprints you will be due for retirement.
No offense, but you are living in a kind of unfortunate corner of "industry".
Where I am sitting, you absolutely have 10 years (or more) to give toward a specific cause, and the path of the software developer is one of lifelong improvement.
Stuff like "the rate at which tools are changing" doesn't matter too much, because that stuff is just surface-level knowledge, not deep knowledge.
I am 43, and have much to do yet; if you are telling me I am due for retirement, I suggest you have a very warped view of the world.
This is why I got out of areas of webdev etc that don't value deeper knowledge. I can't say how much more satisfying it is to be learning stuff that is useful for 10 years instead of the webdev framework of the day/month/year.
webdev requires deep knowledge, it just may be a kind of knowledge you aren't interested in. Placing more value in your own pet interests is more than a little condescending.
Deep knowledge of what? The way different browsers render things?
All of the Web dev I've been involved in is pretty straight forward stuff to manage records in a database or make it easier to interact with the records on a browser.
The only thing remotely complex was 3d rendering. Perhaps I have a narrow view of what is considered web dev now.
"Webdev" is not fundamentally any different from any other kind of development that involves a client and server component. It just happens to be served in a web browser. You need the same underlying knowledge as for other (common) types of software development.
It certainly can. But it feels like a lot of the Web dev scene is people chasing their tails around writing yet another JavaScript library that does the same thing as one they're replacing but with slightly different syntax.
>>I am 43, and have much to do yet; if you are telling me I am due for retirement, I suggest you have a very warped view of the world.
I didn't mean to say that. Everybody has individual choices, and I respect yours.
And not all of us would like to code when we are 50+. Personally I would like to retire early to take time off for other things. This is entirely a personal perspective, and might change from person to person.
This is the sort of attitude that is responsible for the proliferation of "cargo cult" style programmers. People in industry who don't understand anything at a deep level and barely understand what and/or why they do what they do most of the time. They just find code -> paste code -> tweak here, tweak there -> quick test -> move on. Now you have systems which contain massive technical debt and are not well understood or designed. People like this view everything as a black box.
No, no thanks. I work in the medical device industry, but this applied everywhere. If you don't understood your tools at a deep level please, study. Go off and write some trivial stuff before you infect important systems with your ignorance.
I think it's a trend in that today we have a lot more programmers than we did 30 years ago, and much of today's programming languages and tools are highly abstracted. Most programmers don't have to know much about how their computer or OS works to get something up and running. It's good for productivity, and I'm not recommending that we go backward, but there is a consequence to making things (seem) easier.
It's much worse for contracted stuff, in-house development, or B2B products, because in all of those cases user experience is not really a big deal and barely-functional, slow systems will continue to be used. In addition, many developers being hired at such places are being hired by people who are not, themselves, programmers, and therefore aren't screened the way they would be at a software company.
Our tools keep changing but we're all still relying on the same 50-year-old data structures and algorithms (or, I guess, in many cases, solving the same problems in a less effective way because many of us aren't familiar with them). That one gives me pause.
Ten years is an obvious extreme but the point is that hiring managers who try to get people who already know the programming languages and tools their company is using aren't idiots. It's a defensible posture.
Its not just about having math and other computer science information. Age related discrimination is a huge problem in this industry. Most of the programming jobs out there don't involve detailed interaction with algorithms and data structures in every day work. And if it does, its not like the 80's where you had to visit a library to learn about an algorithm. Access to knowledge has become very cheap and quick. Having a lot of information in your brain in itself has no value.
Young people are ready to work lower salaries, will do work on weekends, late nights and in general a lot more agile in a lot of issues.
In fact the 10000 hour/10 year rule itself is subject to a lot of assumptions like access to information being expensive in terms of time and effort, so having someone on the team with that information would help. These days you have stack overflow and a dozen places on the internet who can much of that at a far more lesser price.
Its getting easier over time to build systems and solve problems.
I can't tell if you're trolling or naive. No serious SDK, Framework or API is built without deep know-how of the domain. You atleast need to be great at data structures (or OOP), design patterns, language design.
Unless you're doing the literal bottom-barrel of engineering work where you don't involve algorithmic know-how, there's no escaping having deep engineering.
Perhaps what offends me most is the notion that "you can just google/stackoverflow it". No you can't. If you don't know your tools, every problem will be a nail and your only tool a hammer. You're not being fast, you're being hasty and creating a lot of waste by moving very slow on the aggregate. It's this attitude that introduces massive bugs in the system because an engineer copy/pasted code without knowing it's implications.
Development is knowledge working; you need to invest in your knowledge tools else you're just moving really slow and you don't even know it.
> Having a lot of information in your brain in itself has no value.
Having a lot of unstructured information in your brain has no value.
If you learn a lot, and then start putting patterns together and build more complex rules out of that - that has value. And by the way, the result of that process is the kind of thing that could be easily transferred to other particular areas.
Looking things up won't do you any good if you don't understand what you find, and you're going to waste time flailing around if you're unable to recognize the class of problem you have (which is what algorithms are for -- they're solutions for classes of problems).
Also, people without understanding of CS fundamentals often unwittingly write dog-slow code.
> Having a lot of information in your brain in itself has no value.
If you think of it as inert info, the accessing of which in the brain is equivalent to reading it on a web site...
But it isn't. Brains, especially in respect to deeply understood domain knowledge, change in response to how they're used.
Experts' minds create shortcuts to information in their area of expertise.
Having more information means having the ability to synthesize it, gain epiphanies that would otherwise be overlooked--and reading someone's blog post about their epiphany isn't the same as having it yourself.
I don't know where all this "age related discrimination" is happening, but I'm well past your "due for retirement" cutoff and I haven't seen any of it. Maybe it's because I stay out of the frothy race that is web-dev, and focus on system software, where experience is valuable and it's not just possible but mandatory to take your time learning the fundamentals.
If you are learning anything other than that, you should be in academia not building real world applications. Out there in the industry you don't have 10 years to give towards a specific cause. Given the overall pace of our industry, the rate at which tools are changing, and age related discrimination.
In two ten year sprints you will be due for retirement.