As some noted, the fact that you realized what drives your desire is very impressive. It takes a certain skill to understand those things!
As someone who's been at it for years, I'll just give you one little piece of advice. If you've already been through the fundamentals, you've done enough. Now, instead of focusing on learning technology, focus on building things, this is what real engineers do.
Let me explain. You'll probably get much better with at least one thing once you ship a real project to the end, and this is where you'll get better.
One of the best programmers I've ever worked with was a PHP guy when I met him, and he was good because he shipped efficient, tested, and working code fast, all while being able to document and communicate about it with his team. That's what being a programmer is. You won't become a good professional programmer by chasing after hip technologies (even though learning different paradigms always help), but by building things, and preferably with people, because this is how things work in the real world.
As long as you stay with startups and technology companies, you'll see that any CTO or lead dev worth his salt would rather hire a smart Perl programmer with strong fundamentals who shipped things over someone (maybe smart too) who knows a bit of JS, a bit of Java, and a bit of Haskell. This is, however, not true with a lot of non-tech companies, where keywords on resume, a professional-looking attitude, and some good sales skills will usually get you better positions.
It's never too late, don't fear irrelevance, build things, and have fun!
> Let me explain. You'll probably get much better with at least one thing once you ship a real project to the end, and this is where you'll get better.
+100. I did exactly this. After working for 12 years, took a break, learnt 3D game programming and actually shipped a playable 3D sport simulation game on iOS. Enjoyed graphics programming a ton. Also prototyped the game in Common Lisp before porting it to iOS.
End result: I now work as a scientific software developer specializing in 3D visualization all thanks to the graphics knowledge gained in the process of shipping the game.
So I would say once you have covered enough fundamentals, you must ship something you think is hard but just harder and not completely beyond you.
For me the fundamentals are: 1. Multiple programming paradigms 2. Algorithms 3. Data Structures 4. Digital Electronics 5. OS 6. Networking and 7. Math for CS. This will take a lot of time. I invested a lot in 1 - 4, skimmed 5,6,7; shipped a game and things unfolded.
This sounds very inspiring and it's one of the paths I'm seriously considering for my own future.
Do you mind asking you a couple questions? Where are you based? How does the market look like and what kind of pay can you expect as entry-level/experienced scientific programmer (i.e. is it a significant hit pay-wise when compared to standard enterprise/finance/google developer career track)?
I am based out of India. Irrespective of the location, being in this domain for 2+ years now, I can tell you that while there may be comparatively few open positions, the pay (irrespective of location again) is above par if compared to enterprise but on par otherwise, for experienced programmer!
If you are at entry level, I can think of having a related self project or contributing to any of the numerous open source projects in the scientific stack will do the trick. Hope this helps.
Regarding the pay, I'm a bit worried that it might not be the case in UK. For example, when working in Big Data positions (my current area), it's not hard to get 100k pounds per year or more, while I ads for scientific or graphic programmer (or anything non-enterprise for that matter) rarely exceed even 50k. The difference is that on 100k I can retire before 40 and on 50k I'll probably work forever... If that's indeed the situation I'll probably try getting into the US as H1-B as I hope the situation should be better there.
As for getting a self project - I'm thinking of doing a physics engine focused on static forces - something inspired by structure engineering methods (solving with finite element analysis for example). I have no idea if I can make things bend or break believably in real time but it seems like a cool idea to pursue.
You don't get as many job offers by becoming an expert in one area though....
How many job offers do you see looking for a smart Perl programmer. How many do you see listing 10+ technologies, plus experience in scrum? (Does doing a stand up every day make you better at it? )
You don't want those job offers anyway, so don't worry about it. Finding a good job is not a numbers game.
(Anecdote: I rejected an offer from a YC startup once because ~60% of the process was them fretting about me not having Ruby on Rails experience. I didn't (and don't) want to work for a CTO that doesn't understand that fundamentals travel between languages.)
As the GP said, any CTO or dev lead worth their salt would hire a dev with good fundamentals in the 'wrong' language over one with poor fundamentals in the right one.
You have to do some legwork to identify who these CTOs and dev leads that care about good fundamentals are. You'll need to engage with the tech community around where you are/want to work and talk to people. It's not a numbers game.
> As the GP said, any CTO or dev lead worth their salt would hire a dev with good fundamentals in the 'wrong' language over one with poor fundamentals in the right one.
For sure. You can learn a new language in a few months, but not how to think like a programmer.
However, there could be an argument to be made for holding out for someone who is a good programmer AND knows the right language. Especially if it was a future leadership position. In the busy world of a startup, I may not have 3 months for you to learn Ruby / whatever language of the day.
I've been to a few interviews with startups. Some of them didn't care about not having their language on the résumé while some of them did. The impression I got is, you can just tell which one of them are looking for a code monkey and which ones want you to take a bigger role of contributing as a software engineer.
If you ended up in that situation, obviously pick the candidate more familiar with your stack, but that's a hypothetical, hiring in this business is not generally characterised by a glut of qualified candidates.
That is a racist comment. You could had said "in the US they make those job postings catered to a specific person that they want to hire as an H1B" instead, but specifying that it is intented to weed out americans (specially given the fact that no one said we where talking about the US market!!) and hire specifically Indians (and not foreigners, or people in search of a visa) is racist. It shows a specific prejudice against Indians and a belief that the position they fill are less legitimate than the ones an American fills.
- HR requirement that all positions be advertised externally, even when there is an internal candidate who is suitable and people are happy with (similar rationale for the H1B policy but at a smaller scale and less likely to engender foamy-mouthed rantings)
- hiring company is actually an agency who is fishing for CVs
I should have said so they can use the H1B visa. I wish I had a time machine to go back and correct my mistakes. When I see a long list of requirements for a position I fantasize about creating a resume that says I am an expert in those things because that is just what happens when they fill the position with a H1B applicant anyway, it is faked they meet the requirements then are trained on the job.
remember, not everybody here lives in "freedom loving" US. Some of us live in free countries, where no court has time for that BS.
And then probably you are Indian, and Indians from what I noticed are extreme bigots towards their own minorities, not to mention raping women is like national sport in India.
Those ads are written to the specifications of the resume of someone that the hiring company wants to get an H1-B visa for. By making the desired skills very specific they make diwn the pool of possible applicants enormously. When there are no " qualified applicants" they can get the visa for the person they wanted to hire in the first place. It's often used by bodyshops like TCS or Infosys.
> This is, however, not true with a lot of non-tech companies, where keywords on resume, a professional-looking attitude, and some good sales skills will usually get you better positions.
By the way, these things are hackable, too. It only takes a bit of practice to become a better salesperson than most programmers, and only a small amount of effort to look more professional, too. (And a good suite can even be comfortable.)
A good suit should always be comfortable. If your suit is uncomfortable it doesn't fit. If you spend $1000 on a good interview suit it will help you earn many times that much. It will also last much longer than the same amount of money spent on electronics.
OP mentioned reading Gang of Four, which could be considered fundamental knowledge.
More generally, by fundamentals I mean a pack of things including CS101, basic understanding of C (K&R), data structures and algorithms (those available in coursera courses are enough to get the basics), good use of source control systems, and project architecture basics.
As someone who's been at it for years, I'll just give you one little piece of advice. If you've already been through the fundamentals, you've done enough. Now, instead of focusing on learning technology, focus on building things, this is what real engineers do.
Let me explain. You'll probably get much better with at least one thing once you ship a real project to the end, and this is where you'll get better.
One of the best programmers I've ever worked with was a PHP guy when I met him, and he was good because he shipped efficient, tested, and working code fast, all while being able to document and communicate about it with his team. That's what being a programmer is. You won't become a good professional programmer by chasing after hip technologies (even though learning different paradigms always help), but by building things, and preferably with people, because this is how things work in the real world.
As long as you stay with startups and technology companies, you'll see that any CTO or lead dev worth his salt would rather hire a smart Perl programmer with strong fundamentals who shipped things over someone (maybe smart too) who knows a bit of JS, a bit of Java, and a bit of Haskell. This is, however, not true with a lot of non-tech companies, where keywords on resume, a professional-looking attitude, and some good sales skills will usually get you better positions.
It's never too late, don't fear irrelevance, build things, and have fun!