You won't get in the door just applying to jobs and saying you've got 30 years of being a hobbyist and love Assembly. You'll have to demonstrate something you can do, and ideally it will be something interesting to the person receiving your message/application. This becomes a marketing issue, and you can market yourself as a junior programmer and career transition candidate willing to take on junior work at junior prices for the chance to get in the door.
You can usually disguise your age at least a bit by omission in resumes. A resume isn't a full biography, so we don't need to list every single thing (especially since you will likely have lots of irrelevant professional experience). We can also delete things like graduation dates (if you attended college) in order to avoid someone guessing your age.
I'm the same age as you - if you're priced correctly for your skill level, your age might even be considered somewhat of an asset (maturity) in certain companies and jobs, but the key for you is marketing whatever skills you do have and leveraging those to get the skills you want (more programming).
You aren't old. They were 55+.
When I interview people, age does not concern me (45 wouldn't even make me blink). It is only if I think that person will be an asset to my team. And if they are, why should age bother me?
More important questions I ask myself is: Is this person going to be self sufficient or are they going to need a lot of assistance?
Is this person a generally positive person who is willing to communicate with others and me about any struggles they are having so we can fix it?
etc...
There are still tons of projects/products that use very small microcontrollers or microprocessors. You're not going to run Linux and Java on an embedded system that's got 8KB of EEPROM and 256 bytes of RAM.
Good luck!
How much of a deployed base - and perhaps more importantly, how much future demand - is out there for this sort of thing? Would it be worth it for me (as a random person on the Internet, not OP) to spend the next N years learning these microcontrollers' instruction sets, errata and idiosyncrasies?
Like OP, I'm incredibly interested in assembly language, and "really tiny microcontrollers!" is one of the instinctive responses I also gave in my own answer, but I'm not sure how widespread demand for it is, so I was somewhat more cautious.
They are absolutely here to stay in consumer products. Whether the job market will be good and constant over the next 25 years is something that I can't say, but they're likely not going away, and to the extent they do, they'll likely be replaced with something so similar that those skilled in the art will still be able to adapt.
I wonder if compilation for Harvard architectures is any more or less difficult than for Von Neumann. I'm guessing there are pros and cons with both.
Thanks for mentioning that they're here for a good bit yet, I'll definitely take a look at them.
These parts are sold by a lot of vendors but you can get everything you need from Digikey [2]. And when you're trying to build a consumer device, it's nice to buy a microcontroller that is inexpensive - you can get this [3] one for $0.38 if you buy 3000 at a time. We normally started with flash parts and committed to OTP once our firmware was solid.
[2] http://www.digikey.com/product-search/en?keywords=microchip
[3] http://www.digikey.com/product-detail/en/microchip-technolog...
I didn't think about environmental restrictions though, that's really interesting to take into account, huh.
Looks like the single-unit (or handful-of-units) price is $1.14 for the PIC10F202T, which is very nice considering that Digikey is in a bit of a different class to the Chinese OEM Arduino clones you'll find on eBay for $2-$3.
I am curious though - I remember reading in one of my old phonebook-sized product catalogs that certain variants of the PIC line were not recommended for new designs. Does the PIC10F202T fit into that category? I can't see any indication for or against on the webpage, nor any links that look like they'd reveal that info. (I ask because my memory of exactly what was marked legacy is poor, and I remember that some of the PIC10 range was listed as such, but I don't recall exactly which. I'm also curious what this marking means exactly - whether the chip will be phased out at some point, or what.)
Next time someone is looking for those skills, hopefully your name will show up in their Googles?
You can crank the Medium post or Youtube video strategy to the max by targeting the people you want to meet. First make a list of all the most prominent and connected people in your field of interest, say "reverse engineering". FollowerWonk is one place to start that list, e.g.:
https://moz.com/followerwonk/bio/?q=reverse%20engineering&q_...
Now start a blog, or maybe a Youtube channel, where you post about reverse engineering topics. Approach a target for an interview about reverse engineering today, and how they and their company are approaching the issues, because you are passionate to learn everything about reverse engineering. Make the post all about them, with their picture, their bio, etc. Almost no one turns down such an offer. Your interview post becomes a line item on their resume, and they share the link to all their friends. Do ten of these. Ten leaders in reverse engineering now know your name and return your phone calls. Let it be known you are open to new opportunities, and they may direct you to their friends who are hiring, etc., etc. You end up with some of the top search results for current topics and issues in reverse engineering.
Have you used these tactics yourself?
http://blog.asmartbear.com/cold-calling.html
A careful listening to Mixergy interviews shows two or three of his guests have used the same strategy to get started. It is a very general technique, but it also has a significant level of effort, so you can't really do it in multiple niches at once. Thus, any one person won't have valid statistics about it.
Someone should really write an entire book about this general approach. I think it would still work even if your targets knew what your goal was.
A word of caution... doing RE in a mediocre way is fairly easy. Doing it well requires knowing, well, a lot of shit about a lot of shit. Encryption, compilers, information theory, high level compiled languages, network protocols, etc. are all required knowledge to not get stuck at some point while doing that job. And sooner or later you'll find you'll be writing your own RE tools out of necessity.
This might sound cynical, but the good news for job seekers is that there is often a higher demand in the security industry for a mediocre reverse engineer who is willing to make a lot of guesses, abandon problems that are too difficult, and move on to the next thing quickly. If you're willing to learn in the job it's almost an ideal place to start.
One would be to start working on an OSS project that is well supported locally and to attend relevant meetups. Get known in the community, get credibility, and, after a while, let people know you are looking for work.
Another would be to start in testing - if you have the mindset for it. I know quite a few people with non-technical backgrounds who started in testing and moved onto careers as developers, integrators, and more, all with non-technical backgrounds. Testing is more about mindset, curiosity, organization, and detail, than about specific technical skills - or at least some types of testing are.
FWIW, YMMV.
Both assembly language and reverse engineering are vast, ambiguous fields of knowledge, so it's difficult to provide an on-point answer. A couple things come to mind though:
- Quite a lot of demoscene-related sourcecode has been released over the past few years (covering many individual productions along with supporting tools), and quite a lot of it is in assembly language. Considering that you've been tinkering for 30+ years, DOS/similar-era stuff may be of particular interest to play with or explore. This would best be considered akin to soldering practice, to use an electronics analogy - DOS-specific knowledge (including eg low-level VGA or SoundBlaster/GUS control) is not likely to be helpful commercially. That said. old technology is similar to learning a language like Latin, and provides the advantage of neatly sidestepping the general social/human confusion concentrated within the current focuses of technological development.
- Many people are likely to generally recommend microcontroller development, but I understand chips with eg ≈256 bytes of RAM or ROM (where hand-assembling code would be useful) are somewhat rare nowadays. This may be interesting to explore though.
- Finally, considering that you really like reverse engineering, you could make yourself available for hire for medium/long-term contract work reversing major applications or systems. Depending on the system in question this may be a lot of fun or incredibly tedious; reverse engineering is generally nontrivial work, as on the one hand there's the occasional tedium of picking IDA up when it doesn't realize it's fallen down, and there's also the general strain of ensuring the technical specifications you produce are complete, bug-free, and provide 100% coverage (or, in the case of self-modifying code, "100.∞% coverage").
As an aside, I think your age is actually a big asset - I don't think enough emphasis is generally put on the fact that age and maturity means an applicant already has a lot of "life" things taken care of. Obviously domain-relevant skill(s) remain key, but it's possible an employer may be willing to provide additional education to someone who's been around the block a bit. Case-by-case-specific though.
This forum doesn't provide a way to edit posts and comments after an hour, but you can always update it via a top-level reply.
Like the other commentators here I'm also curious what you've been working on. I'm very fascinated with assembly language and machine code myself and interested to get a head start with that too.
You've probably heard of Coreboot, an open source BIOS that's been ported to a handful of systems (230 total different configurations, along with a QEMU target for playing with). It's also the foundation of all Chromebooks. This is very short but may be fascinating reading: https://www.coreboot.org/Developer_Manual
I'm not quite at the shellcode-comprehending stage yet, although I realize it's incredibly simple. Agh - I have a basic working knowledge of C, but nonexistent understanding of low-level hardware at this point :)
https://www.nayuki.io/page/a-fundamental-introduction-to-x86... has been on my to-follow-up-on list for a while, along with http://beginners.re/. (Both found via HN)
TRUE: Many hiring executives actually prefer 'mature' staff. No need for all the mollycoddling, mentoring, constant feedback loops that 20 somethings often demand.
Age is definitely not a factor. The speed with which you are able to learn definitely is. Good luck. I think this is awesome.
Your main barrier is experience, but if you're willing to go for a junior level position, that shouldn't be an issue.
So generally, look for companies with a more mature culture - avoid buzzwords like "rockstar" and "ninja" (secretly, everyone should do this), steer clear of "unicorns", and read the bios on a companies website, and you should be able to find a good fit.
If you really want to get into programming, I'd go for something higher level like PHP, Ruby, JavaScript, Python, etc. Then create some stuff in the language(s) you've chosen. This will give you a shot at getting a junior level job in that language.
When I hire someone to a junior level position, I'm still not going to hire someone with no experience. It's going to be someone with less experience but still some. I don't have the time to teach someone starting from zero. You need to go from zero to a low level of experience on your own.
As others pointed out: 45 is young and you can do low level programming for as long as you've got your health. At 45 you still have half your career ahead of you.
It's not so hard to demonstrate assembly knowledge by putting some projects on github. Low level programmers are in high demand, so it's just a matter of interviewing until you get a yes.
"First find a problem to solve, then we'll talk."
I know it's glib, but I genuinely believe that learning to program or learning to be an engineer is, in and of itself, pointless. And every time I've tried to teach people the fundamentals of programming, they get bored, move on, and never come back. It could be that I'm a bad teacher - and I am - but I think there's something else at play.
I think it's that the reality of being a programmer is very different to what people think it is. For example, people think you can lean to program to a point were you "know" how to program. As though at any point a programmer can accomplish any task by sitting at a computer and bashing the keys in just the right way to solve any problem as if the solution was pre-ordained, just hanging in the aether waiting for you to pluck it into existence.
In reality, it's a never ending journey of learning. You can never stop learning. There will never be a day when you can stop educating yourself and proclaim to the world that you are now, and will forever be, a programmer. And I think when that dawns on people, they lose interest.
Also, programming is just the tool. The job is something very different. I could teach you how to swing a hammer in no time at all, but you'll be no closer to being a sculptor or a joiner or a stone mason. A web developer can't write a high frequency trading algorithm without first learning a lot about a lot of other subjects.
People often want to learn to program for all the wrong reasons. But if your desire is to solve a problem? Well that's a different story.
If you can find a problem AND you have a desire to solve it then you've taken your first step towards becoming a programmer... or a doctor... or a farmer... or anything else. And if you can also think of a good solution, that's your second step. What follows is a few million more thankless, frustrating steps. If your problem is best solved with the help of a computer, you will become a programmer.
So I would say this to you. You're probably going to have a hard time breaking into assembly as a career at your age for all kinds of reasons. Some valid, some not.
But if you can use what you know to solve a problem, and it's a problem people want someone to solve, or better yet if it's a problem people don't even realise they have! If you can do that, then all the challenges you would otherwise face in your quest to become a professional assembly programmer, they all disappear. You won't need a job. The people who have all the jobs to give, they'll need you.
I find that your advice also applies to learning human languages, too, and that people who don't have a problem to solve are very likely to quit quite quickly there as well. There just isn't enough motivation.
You gotta decide on something to build. It doesn't have to be anything big and fancy, or something that a company or user would pay for. Could be just automating a task that you have to perform a lot, or just something that you think would be cool. And of course it has to make sense to perform with the platform that you're learning. You don't want to try and build a web app with assembly, for example. But you could get some kind of microcontroller that you can program in assembly and try to automate some electronics stuff around the house or something like that. Doesn't matter if there's an easier way to do it or not, it just matters that you built it and you figured out how to do it.
I've had Python's doc and interpreter for years, but it's not until I had a problem and I wanted to solve (mobile credit transfer for subscribers on different networks) that I started to actually do Python.
I haven't solved the problem because I hit a roadblock back then (a technicality I missed that forbade a certain tier of SIM cards to do what I assumed be possible), but I've learned more during that tiny silly project than I've learned in years.
You make an excellent point about using a hammer vs. being a stone mason. It's not enough to have discrete skills, one also needs to have the glue that binds those skills to make a coherent whole. i.e: programming, abstracting, managing time, breaking down a problem to manageable bits, tracking an issue, testing for different cases, saving knowledge and things you learn, etc.
This glue is very important and I still don't have enough of it. For hardware, it's slightly different but there's a lot of overlap. I started a small project to build an interface to allow some cars with head-units with a certain feature (like the ones the Tesla has) to work with something else. And just putting it down in writing helps, even if it's just because it displays the date I wrote it and reminds me I should get back to it.
Everyone who asks me about this kind of stuff, I just tell them to find stuff to do and build their toolbox early on so they don't make the same mistake I've made.