Ask HN: Isn't keeping up with tech for your career same as “timing the market”?
32 comments
You have to "invest" in a low risk one that pays the bills. Then go for things that are medium risk, high returns.
Many people go in at the peak of hype where it's "overpriced" and lose out. Even if it's a good stack, you won't be as good as the people who have years of experience in it now. It's too late.
Just go for things that actually excite you. For me, it's GPT-3 today. It's too early for job openings, but mature and impactful enough that it feels like a secret weapon. I adopted Kotlin before Google officially did, because it was cutting down lines of code by half.
No matter how boring you are, there should be things that actually excite you as an expert, and those are the only ones worth investing in early. Since you already browse HN, you shouldn't worry about missing out on them.
Many people go in at the peak of hype where it's "overpriced" and lose out. Even if it's a good stack, you won't be as good as the people who have years of experience in it now. It's too late.
Just go for things that actually excite you. For me, it's GPT-3 today. It's too early for job openings, but mature and impactful enough that it feels like a secret weapon. I adopted Kotlin before Google officially did, because it was cutting down lines of code by half.
No matter how boring you are, there should be things that actually excite you as an expert, and those are the only ones worth investing in early. Since you already browse HN, you shouldn't worry about missing out on them.
> You have to "invest" in a low risk one that pays the bills. Then go for things that are medium risk, high returns.
This is why I started as a javascript programmer. These days I code almost exclusively in elixir but that wastn't before spending. lot of time learning elixir on the side while nodejs and react paid my bills.
My current big bet is rust and more math heavy stuff like ML and graphics which don't go obsolete so fast
This is why I started as a javascript programmer. These days I code almost exclusively in elixir but that wastn't before spending. lot of time learning elixir on the side while nodejs and react paid my bills.
My current big bet is rust and more math heavy stuff like ML and graphics which don't go obsolete so fast
Out of curiosity, why? Perspective projection is based off of an old insight from hundreds of years ago:
https://en.wikipedia.org/wiki/Pinhole_camera
Projective geometry and the perspective projection matrix (extrinsic and intrinsic parameters of your modeled camera) is basically the "mathified" version of that. Or just "perspective drawing", as artists used it for 100+ years by now.
In my opinion, computer graphics is basically applied math (or linear algebra). (You even don't need linear algebra or matrices to render stuff on the screen, but it will be painful to keep track of what's going on.)
Math hardly dies off, it seems. Maybe some methods change. Like calculating results by using some geometry and measuring its length.
However, unless we don't have any need for projecting something from 3D (world/scene) to 2D (image, monitor, photo, photosensitive sheet, ...), I think we can count on it for a long time.
What changes might be some algorithms. Earlier, we used the "edge walking" algorithm to fill out triangles. Now, we use edge equations that tell you whether an image point is inside a triangle or not. But they do essentially the same, namely, filling out a triangle.
Also, things like the Phong model may stick as well.
There are other methodologies, that are basically still based off of the pinhole camera model. In ray tracing, you shoot rays into the scene and check whether they intersect an object. If it intersects, then you color that pixel with the intersected object's defined color. Otherwise, you leave it out and move on pixel by pixel. So the shooting of the rays from the camera to the scene is basically the reversal of the pinhole camera where light enters the hole and "colors" a photosensitive sheet of paper.
At least this is my understanding of it.
Just learn math, math, math, and you will be fine. Math is the lingua franca for engineering and science, so learn it and understand the concepts from those other fields/branches.
https://en.wikipedia.org/wiki/Pinhole_camera
Projective geometry and the perspective projection matrix (extrinsic and intrinsic parameters of your modeled camera) is basically the "mathified" version of that. Or just "perspective drawing", as artists used it for 100+ years by now.
In my opinion, computer graphics is basically applied math (or linear algebra). (You even don't need linear algebra or matrices to render stuff on the screen, but it will be painful to keep track of what's going on.)
Math hardly dies off, it seems. Maybe some methods change. Like calculating results by using some geometry and measuring its length.
However, unless we don't have any need for projecting something from 3D (world/scene) to 2D (image, monitor, photo, photosensitive sheet, ...), I think we can count on it for a long time.
What changes might be some algorithms. Earlier, we used the "edge walking" algorithm to fill out triangles. Now, we use edge equations that tell you whether an image point is inside a triangle or not. But they do essentially the same, namely, filling out a triangle.
Also, things like the Phong model may stick as well.
There are other methodologies, that are basically still based off of the pinhole camera model. In ray tracing, you shoot rays into the scene and check whether they intersect an object. If it intersects, then you color that pixel with the intersected object's defined color. Otherwise, you leave it out and move on pixel by pixel. So the shooting of the rays from the camera to the scene is basically the reversal of the pinhole camera where light enters the hole and "colors" a photosensitive sheet of paper.
At least this is my understanding of it.
Just learn math, math, math, and you will be fine. Math is the lingua franca for engineering and science, so learn it and understand the concepts from those other fields/branches.
I don't think we're disagreeing. the fact that math doesn't change is exactly why I'm saying it won't go obsolete
> Many people go in at the peak of hype where it's "overpriced" and lose out. Even if it's a good stack, you won't be as good as the people who have years of experience in it now. It's too late
But what if that is the case, and also there aren't many other options because the tech reached a critical mass. Do you try and catch up, or do you quit, or somewhere in the middle?
For example, I don't really have much React experience, and now the entire market is basically React. It's not hard, I know at least enough to get going reasonably well, but I probably don't know as much as some bootcamper who graduated 2 years ago and now their 2 years of React is considered more highly than 5-8 years of various other things.
But what if that is the case, and also there aren't many other options because the tech reached a critical mass. Do you try and catch up, or do you quit, or somewhere in the middle?
For example, I don't really have much React experience, and now the entire market is basically React. It's not hard, I know at least enough to get going reasonably well, but I probably don't know as much as some bootcamper who graduated 2 years ago and now their 2 years of React is considered more highly than 5-8 years of various other things.
Like other investments, it's good to check whether it's overpriced or underpriced. Supply and demand will always change, and so will the value.
One hint of oversupply is when everyone does it. I don't mean there's a lot of jobs, but when your farmer uncle is telling you to learn React the same way they'd tell you to go to law school or buy Bitcoin.
A hint of a bubble is when it's expensive and people try to sell it off to the next sucker, normally in the form of classes. When bootcamps are cropping up everywhere and there's FOMO, that's a good hint that it's a really bad time.
I think this is where time in the market matters too. Bitcoin price history is an interesting analogy. If you bought at the top and held through the dip, you'd be ahead of those who never came in.
Android was similar for me. It dropped as hybrid, RN, and Flutter were trending and there was a dry spell for 3 years where there were few native jobs. Then companies like Airbnb were hitting a barrier on RN, plus Android Jetpack was introduced. Now the Android skillset is valued highly, especially those who bought the dip (learned Jetpack+Kotlin). It's still trending hard now that Jetpack Compose puts it on par with Flutter so I'll keep investing into it.
The other thing to look at is when something peaks, a lot of things crop up that don't actually make things better. This is around the time people complain about frameworks and stuff. Android had RxJava, JS had CoffeeScript. So you want to avoid investing into these kinds of things.
One hint of oversupply is when everyone does it. I don't mean there's a lot of jobs, but when your farmer uncle is telling you to learn React the same way they'd tell you to go to law school or buy Bitcoin.
A hint of a bubble is when it's expensive and people try to sell it off to the next sucker, normally in the form of classes. When bootcamps are cropping up everywhere and there's FOMO, that's a good hint that it's a really bad time.
I think this is where time in the market matters too. Bitcoin price history is an interesting analogy. If you bought at the top and held through the dip, you'd be ahead of those who never came in.
Android was similar for me. It dropped as hybrid, RN, and Flutter were trending and there was a dry spell for 3 years where there were few native jobs. Then companies like Airbnb were hitting a barrier on RN, plus Android Jetpack was introduced. Now the Android skillset is valued highly, especially those who bought the dip (learned Jetpack+Kotlin). It's still trending hard now that Jetpack Compose puts it on par with Flutter so I'll keep investing into it.
The other thing to look at is when something peaks, a lot of things crop up that don't actually make things better. This is around the time people complain about frameworks and stuff. Android had RxJava, JS had CoffeeScript. So you want to avoid investing into these kinds of things.
I don't want to derail the parent thread, so let me ask you: what job skills are "low risk" for you? Can you give a couple of examples, please?
Thank you! :)
Thank you! :)
Sales is the lowest risk job tech related skill I know of; it works even if we were hit by an apocalypse and had no electricity. In all likelihood, we'll still be making tools and selling those tools. It helps you to think in the problem/business domain too. So you're not simply learning PHP to build a website, you're doing it to say, help people find hotels.
It works on your resume, it works for job searching, it helps with getting promotions (proving yourself useful), and it works with landing a higher salary without negotiation. You still can't sell crap. So you need a good product (i.e. yourself, your skill) worth selling. But it complements any other skill you have.
There's also communication skill in general. How to refine ideas into denser, cleaner formats that people and AI can understand. This works for sales, and it works for code.
Tech-wise, I can't say. The nature of tech is that it's very high risk. If you've had a look at how GPT-3 is engineered [1], it makes you question whether algorithms and OO will be a useful skill in the future. Sam Altman expects us to hit AGI within 2025 [2]. He's probably being a little optimistic, like every other programmer, so let's double the estimate and say we have until 2030. Codex itself scored #96 when pitted against 9000+ humans in a coding challenge [3]. So whatever you pick, it should be fairly AI-proof.
Data will be around, and anything that deals with data will be helpful. Even if you could tell AI to do whatever, it has to pull data from somewhere. Spreadsheets are great. Databases will be around for a long time. The top 3 most used DBs or so use some variation of SQL.
There will also need to be some kind of front end for data for people (and even AI) to use. Low/no-code has been around forever but there's always a domain it can't solve. Something specialist like Shopify, Magento, WordPress that solves a problem millions of people have. If you want something that combos well with higher risk work, you can learn UI/UX.
Again, low risk, low returns. The absolute lowest risk is food. Everyone needs to eat. Farming and cooking will keep you from starving, but probably won't take you much higher than that.
[1] https://www.gwern.net/GPT-3#prompts-as-programming [2] https://twitter.com/sama/status/1081584255510155264 [3] https://challenge.openai.com/codex/leaderboard
It works on your resume, it works for job searching, it helps with getting promotions (proving yourself useful), and it works with landing a higher salary without negotiation. You still can't sell crap. So you need a good product (i.e. yourself, your skill) worth selling. But it complements any other skill you have.
There's also communication skill in general. How to refine ideas into denser, cleaner formats that people and AI can understand. This works for sales, and it works for code.
Tech-wise, I can't say. The nature of tech is that it's very high risk. If you've had a look at how GPT-3 is engineered [1], it makes you question whether algorithms and OO will be a useful skill in the future. Sam Altman expects us to hit AGI within 2025 [2]. He's probably being a little optimistic, like every other programmer, so let's double the estimate and say we have until 2030. Codex itself scored #96 when pitted against 9000+ humans in a coding challenge [3]. So whatever you pick, it should be fairly AI-proof.
Data will be around, and anything that deals with data will be helpful. Even if you could tell AI to do whatever, it has to pull data from somewhere. Spreadsheets are great. Databases will be around for a long time. The top 3 most used DBs or so use some variation of SQL.
There will also need to be some kind of front end for data for people (and even AI) to use. Low/no-code has been around forever but there's always a domain it can't solve. Something specialist like Shopify, Magento, WordPress that solves a problem millions of people have. If you want something that combos well with higher risk work, you can learn UI/UX.
Again, low risk, low returns. The absolute lowest risk is food. Everyone needs to eat. Farming and cooking will keep you from starving, but probably won't take you much higher than that.
[1] https://www.gwern.net/GPT-3#prompts-as-programming [2] https://twitter.com/sama/status/1081584255510155264 [3] https://challenge.openai.com/codex/leaderboard
No, as the need to learn new things is going to be inevitable. Even if you have been a Java dev forever (and that language will last your career), I know a couple Java programmers who took months and months to find work in this market as they didn't keep up with the latest in Java.
Keeping up with the latest tech is more properly compared to diversification. You are not abandoning your old skills, but you are adding some new ones that have a good chance of being valuable in the future. You may end up learning something worthless, but as long as what you learn is mainstream, there are probably jobs for it.
Keeping up with the latest tech is more properly compared to diversification. You are not abandoning your old skills, but you are adding some new ones that have a good chance of being valuable in the future. You may end up learning something worthless, but as long as what you learn is mainstream, there are probably jobs for it.
I don’t think that’s an apt analogy. You have very little to loose by taking a few hours to spin up some new tool and see what it’s about. Even if you don’t use it, you know what it’s about and could if you wanted/needed. You don’t loose your investment in PHP by doing so. In fact sometimes new tech could inform your existing knowledge.
I do think there is wisdom in not immediately using every new thing in production, but that’s different from wanting to stick to one language and never try anything new.
I do think there is wisdom in not immediately using every new thing in production, but that’s different from wanting to stick to one language and never try anything new.
I don't think the analogy really works, for a few reasons.
The first is that you've already (accidentally) timed the market by "buying" PHP in the late 2000s when that was dominant. There's an illusion that everything that existed when you got into the industry is somehow dominant, fundamental, and long-lasting, and everything that comes after is a transitory fad. That might even be true for some things, but many things are transitory fads, and PHP was one of them - the problem is you didn't sell / rebalance as it was declining.
Secondly, getting into / out of a technology can be a gradual process, more akin to a dollar cost averaging strategy. If you start to learn Rust, your PHP skills won't vanish - some of them will even transfer, and others will fade, but still be there if you need them.
The first is that you've already (accidentally) timed the market by "buying" PHP in the late 2000s when that was dominant. There's an illusion that everything that existed when you got into the industry is somehow dominant, fundamental, and long-lasting, and everything that comes after is a transitory fad. That might even be true for some things, but many things are transitory fads, and PHP was one of them - the problem is you didn't sell / rebalance as it was declining.
Secondly, getting into / out of a technology can be a gradual process, more akin to a dollar cost averaging strategy. If you start to learn Rust, your PHP skills won't vanish - some of them will even transfer, and others will fade, but still be there if you need them.
I think it depends on technology to technology. I know people who are still milking their Enterprise Java and Spring skills almost 20 years after they started. Now obviously they don’t work at FAANG but rather at smaller companies but the advantage is that they can spec out and complete the work much faster and don’t have to slog more than 20-30 hours a week.
An investment analogy can be "Core & Explore" portfolio of skills with pareto distribution (say 80% Core, 20% Explore).
The core skills are those that have stood the test of time over multiple decades (OOP, FP, Operating Systems, Distributed Systems).
The "Explore" portfolio is essentially venture capital like bet on new tools/frameworks/languages. Most of the venture bets will fail, but few of them will have exponential returns where you will get ahead of the rest of the market or discover early that your side-project/prototype is very valuable in the market (e.g. ML, Cloud services, etc).
The core skills are those that have stood the test of time over multiple decades (OOP, FP, Operating Systems, Distributed Systems).
The "Explore" portfolio is essentially venture capital like bet on new tools/frameworks/languages. Most of the venture bets will fail, but few of them will have exponential returns where you will get ahead of the rest of the market or discover early that your side-project/prototype is very valuable in the market (e.g. ML, Cloud services, etc).
In my experience if you get to a senior+ dev level, specific tech doesn't matter much. My background was C, assembly, C++, Java and others with solid SQL for a good chunk of it. Most everything else is syntax/sugar on those and pretty transferable. There's typically two framework styles fat (rails/django) or thin (sinatra/flask). GC and static typing can be nice.
Front-end has more vertical tech e.g. mobile platforms and another framework flavour (Vue/React).
More advanced tools (NewSQL) and languages (F#, Elixir) would be great to use but don't often find opportunities.
Front-end has more vertical tech e.g. mobile platforms and another framework flavour (Vue/React).
More advanced tools (NewSQL) and languages (F#, Elixir) would be great to use but don't often find opportunities.
Regarding Elixir specifically, the situation is much more nuanced; I went to ElixirConf last month, and the impression I came away with was that most companies present, and most speakers representing their companies, were desperate to find Elixir devs. And most attendees who already knew some Elixir were not looking to move.
If there were a sudden event that caused a new army of developers to learn Elixir, such as a Harvard or MIT course switching to it, it might change this reality.
But for the time being, Elixir developers are in short supply in relation to demand, so we tend to be treated (and paid) well. Our interviews are probably less frivolous, as well, because companies can’t afford to miss an opportunity to hire folks who know Elixir (or can learn it easily) just because they can’t invert a binary tree on a whiteboard (https://mobile.twitter.com/mxcl/status/608682016205344768).
Timing-wise, this is probably the best time to get into Elixir, and get a head start before it reaches critical mass.
Lots of interesting companies are using it, the community is fantastic, salaries and dev satisfaction are among the highest in the industry (https://fossbytes.com/these-programming-languages-pay-highes...). And besides, it’s an amazing language and ecosystem in its own right.
If there were a sudden event that caused a new army of developers to learn Elixir, such as a Harvard or MIT course switching to it, it might change this reality.
But for the time being, Elixir developers are in short supply in relation to demand, so we tend to be treated (and paid) well. Our interviews are probably less frivolous, as well, because companies can’t afford to miss an opportunity to hire folks who know Elixir (or can learn it easily) just because they can’t invert a binary tree on a whiteboard (https://mobile.twitter.com/mxcl/status/608682016205344768).
Timing-wise, this is probably the best time to get into Elixir, and get a head start before it reaches critical mass.
Lots of interesting companies are using it, the community is fantastic, salaries and dev satisfaction are among the highest in the industry (https://fossbytes.com/these-programming-languages-pay-highes...). And besides, it’s an amazing language and ecosystem in its own right.
If they’re having such a hard time, maybe they should spend a month teaching solid engineers Elixir when they on-board? The erlang family would be intuitive and fun to learn for any distributed systems engineers.
Are they using Phoenix framework? They should hire Ruby/Rails engineers interested in working with Elixir and invest in onboarding.
What if you love working with php and when you start working in other languages you start noticing shortcomings that have been solved in php?
Let's say you wanted to jump into golang. It is easy enough to learn but you are forced into structuring your app a certain way. You lose some joy you had with php. How do you deal with those feelings?
Historically it was widely believed on here that php lost the race to Ruby/rails but fast forward and Ruby has grown out of fashion and a php developer is more employable.
React has the most job postings but most of them are frontend jobs. Comparing php to node jobs is probably a better match for a backend developer.
Most jobs are trending for python this year. Different types of companies use python. Typical startups may use it as a replacement for php but others may be more interested in unlocking ml. That complicates that stack.
One thing is to consider is culture . Moving from php into a different stack usually means a different culture. Chances of bigger teams, daily standups.. bigger orgs.
Let's say you decide to switch to React how would you leverage 20 years of php experience into a React position?
Let's say you wanted to jump into golang. It is easy enough to learn but you are forced into structuring your app a certain way. You lose some joy you had with php. How do you deal with those feelings?
Historically it was widely believed on here that php lost the race to Ruby/rails but fast forward and Ruby has grown out of fashion and a php developer is more employable.
React has the most job postings but most of them are frontend jobs. Comparing php to node jobs is probably a better match for a backend developer.
Most jobs are trending for python this year. Different types of companies use python. Typical startups may use it as a replacement for php but others may be more interested in unlocking ml. That complicates that stack.
One thing is to consider is culture . Moving from php into a different stack usually means a different culture. Chances of bigger teams, daily standups.. bigger orgs.
Let's say you decide to switch to React how would you leverage 20 years of php experience into a React position?
I think about technical skill development as a diverse portfolio. I spend a majority of learning budget on fundamentals, mostly overlearning core knowledge and skills. I spend a small amount of my learning budget on specific techniques, tools, and packages that currently popular. A very small fraction of my learning budget is spent on high risk / high reward elements.
"time in the market" tends to mean that you invest what you can in broad funds _at regular intervals_, and ignore if the market is going up or down, as it tends to always trend upwards.
"timing the market" would then be saving up for a long time, then dumping it all in when you think it has hit its low.
To transfer the analogy, it would be like shireboy describes. You would keep up with the news to see what technology is brewing. That does not mean that you have to be the industry expert on every single technology you decide to look into, but you are more aware.
I think your last paragraph can be compared to stopping investing into the market, and rely on interest to keep you growing.
"timing the market" would then be saving up for a long time, then dumping it all in when you think it has hit its low.
To transfer the analogy, it would be like shireboy describes. You would keep up with the news to see what technology is brewing. That does not mean that you have to be the industry expert on every single technology you decide to look into, but you are more aware.
I think your last paragraph can be compared to stopping investing into the market, and rely on interest to keep you growing.
Even more, timing the market would be like going to school or taking a "gap year" because you don't think it's the right time to put your effort into the job market. Timing is when to put your money/effort into the market, not which fund/job to pour your attention into.
> "time in the market" tends to mean that you invest what you can in broad funds _at regular intervals_,
Why at regular intervals? “Time in the market” seems to imply the earlier, the better since obviously earlier means more time.
Why at regular intervals? “Time in the market” seems to imply the earlier, the better since obviously earlier means more time.
Two reasons: IMO primarily because it’s written to address people who are learning about the market and likely in the accumulation phase of their financial life. They are likely to have money to invest at regular intervals (and if they don’t have money to invest, knowing when/how they should is fairly academic).
Secondarily, if you say won a large cash lottery, you might choose to invest that over a series of spaced investments to ensure you got some kind of blended/average price rather than facing the market-timing dilemma of “should I invest this on Monday or wait until Friday?”
Secondarily, if you say won a large cash lottery, you might choose to invest that over a series of spaced investments to ensure you got some kind of blended/average price rather than facing the market-timing dilemma of “should I invest this on Monday or wait until Friday?”
How is that not timing the market?
The premise of “time in the market > timing the market” is that all you know is that at a point sufficiently far in the future, the value will be higher.
Which means at any given point in time, if you have the ability to invest, and your goal is to achieve long term returns with low risk, then you simply invest as soon as you can. Since the longer the investment is held, the less volatile it should be. You are not trying to maximize returns, you are trying to minimize volatility.
The premise of “time in the market > timing the market” is that all you know is that at a point sufficiently far in the future, the value will be higher.
Which means at any given point in time, if you have the ability to invest, and your goal is to achieve long term returns with low risk, then you simply invest as soon as you can. Since the longer the investment is held, the less volatile it should be. You are not trying to maximize returns, you are trying to minimize volatility.
Timing the calendar is different from timing the market. I internalize the latter as “buying when you think the price is lower than it should be and/or selling when you think it’s higher than it should be”.
(I agree with your approach and do not make an effort to dollar-cost-average or otherwise smooth my investments over time. But I don’t think of a pre-defined calendar based approach as “timing the market”.)
(I agree with your approach and do not make an effort to dollar-cost-average or otherwise smooth my investments over time. But I don’t think of a pre-defined calendar based approach as “timing the market”.)
I'm not sure it really works like this. Suppose you've spent 10 years becoming a master java developer, and now all the investment is going into python. You're going to better than the boot-campers after 1 week and a master developer after 3 months, whereas the others will still need years to catch up.
I think it's worth keeping a loose working knowledge of all the mainstream software in your field, but don't really go deep until you need it.
I think it's worth keeping a loose working knowledge of all the mainstream software in your field, but don't really go deep until you need it.
People who have only used one language way overestimate the importance of having a decade of experience in one language and way overestimate the amount of time it’ll take them to be production-ready productive in a new language.
Syntax is easy and learning a new approach to language design is a great learning experience. You’ll still transfer most of the good parts over but you’ll also learn that maybe some things you’re used to can be made simpler.
Syntax is easy and learning a new approach to language design is a great learning experience. You’ll still transfer most of the good parts over but you’ll also learn that maybe some things you’re used to can be made simpler.
That only natural for people that are not interested in technology or programming itself. People that are interested in new technology and keep learning new things will become more successful as IC and have more opportunities. If you are lucky, and you start with something that is popular long term like Java, you can find decades of stable employment in big corporations. If you are unlucky and start with PHP/Perl you either switch stack or you will stuck in low paying jobs maintaining legacy apps. Programming is less forgiving than other industries, as there are more fundamental changes over years. On the other side, huge demand make it easy to find and change job. You could make AWS certificate and some JS/Python/go training, update LinkedIn profile and wait for offers to flood in. In less than 1 month effort you could rebrand yourself and find jobs in new stack.
There is good satire of the stone to Bronze Age transition. https://www.youtube.com/watch?v=ZHGafC7zOUE
There is good satire of the stone to Bronze Age transition. https://www.youtube.com/watch?v=ZHGafC7zOUE
I think an important part of tech is continuously learning.
e.g. if you can't find jobs as a PHP developer, but you see there are many jobs for (say) NodeJS web development, or Golang API development, you may need to learn some things, but that can build upon how you did things with PHP.
You still have a website still involves HTML, CSS, and JavaScript. A website will still send HTTP requests (and receive responses). The program will still need to be deployed so that it's reachable from the web. etc. etc. -- And there will always be adjacent things which you will either need (or benefit from) learning.
e.g. if you can't find jobs as a PHP developer, but you see there are many jobs for (say) NodeJS web development, or Golang API development, you may need to learn some things, but that can build upon how you did things with PHP.
You still have a website still involves HTML, CSS, and JavaScript. A website will still send HTTP requests (and receive responses). The program will still need to be deployed so that it's reachable from the web. etc. etc. -- And there will always be adjacent things which you will either need (or benefit from) learning.
And there are many similarities of syntaxes between languages. For example javascript, php, C# and java all are c-like languages syntax wise.
The problem isn't on languages, it's on tooling. Docker, kubernetes, elasticsearch, git etc all have their own workflow and learning them isn't fast. Though with a solid basic programming, learning them is only a matter of time.
The problem isn't on languages, it's on tooling. Docker, kubernetes, elasticsearch, git etc all have their own workflow and learning them isn't fast. Though with a solid basic programming, learning them is only a matter of time.
You can’t compare “timing the market” with skills directly because the products sold on the market are inherently limited (a zero sum game) and knowledge can always be shared and does not take away from others.
I guess the market analogy would be that you want to buy into an index. So if you’re invested in PHP but you see over 20% of jobs say React it might be time to diversify a bit into React.
This leaves out that diversifying one’s tech skills isn’t as easy as diversifying a portfolio though. You could do a React side project, but it won’t be considered as highly as a full time job. I guess that’s the difference between adding a bit to your portfolio vs. going all in.
This leaves out that diversifying one’s tech skills isn’t as easy as diversifying a portfolio though. You could do a React side project, but it won’t be considered as highly as a full time job. I guess that’s the difference between adding a bit to your portfolio vs. going all in.
But the more I look at the job market in software, the more I see advice for managing a software engineer's career like trying to "beat" the market. I don't know if I still like this approach. I'd rather not want to keep trying to predict when the high point of some skill or technology is approaching. I prefer to do what I personally like and only change/learn something new because I get bored, and not because the job market doesn't favor it.
Tech trends feel like moving targets, and I have a dilemma. I like working in tech but I also don't like being forced to hit moving targets.
To give you an example, I started my web development career in the late 2000's. I didn't "buy" into cloud computing when it went on the rise, and I didn't "sell" my PHP skills. That's making it tougher to get interviewed at jobs probably because my experience doesn't have enough of the right keywords. Trying to just keep up with new concepts just for the sake of the job market is stress-inducing and it's like constantly monitoring stocks to buy and sell. It's an emotional roller coaster.
Is it just possible to hold on to your initial "investment" of skills long-term, and regardless of what you started with continue to build returns from that? I know that the advice to just spend more time in the market is advice for the regular joe, but I actually do just want to be a regular joe programmer.