^TITLE
I want to be something special and will dedicate myself to becoming an expert in the hardest most sought after (by employers) job.
I just want to be worth something in the world, no pity case, I just really have a passion for being in a small supply in huge demand category.
Are there any routes I can take in the industry to become virtually indispensable to employers?
Thank you.
These probably exist but if everyone knew about them they would be filled pretty quickly. I'd just advise you to try to get a job where you can meet plenty of different people (a consultant maybe?) and make connections.
That really depends on who you ask. People who have a knack for UI, databases, and enterprise level software find embedded systems, kernels, drivers and possibly things like scientific software (e.g. physics modeling) very complex. Getting tripped up by some super corner-case bug in a widely available processor (yes, there are hardware bugs that low-level people need to worry about), dealing with bitmasks that set various aspects of UART registers, floating point precision at the 53rd decimal place, is all probably complex, tedious and miserable for such people.Originally Posted by new2C-
On the flip side, the people with a knack for low-level stuff probably find the super high level stuff like functional programming, large-scale OO systems with complicated databases to manage complex tedious and miserable.
For that exact reason, I simply suggest you try lots of things, and do whatever you enjoy most. Enjoying what you do is one of the most, if not the most, important factors in being good at whatever it is you do. It could be that your only true aspiration is to be in high demand, but being good at what you do is really what makes you in high demand, not the specific sub-field of programming you choose.
There is a good feeling you can get from being in high demand, but (in my experience), it's relatively shallow and ephemeral. The good feelings that run deep and last a lifetime (or at least as long as from when I got them until this point in my life -- 10-20 years) come from experiences. Experiences that still make me happy now are:
- The excellent teams I've worked on, full of brilliant people I've had great chemistry with and built strong bonds with. I don't work with most of them any more, but were still good friends and we still take advantage of eachothers knowledge.
- Jobs where I learned a lot and grew academically and profesionally.
- Jobs that provided the freedom and opportunity for me to design and build excellent software, that I could be truly proud of.
Your worth is ultimately up to you. Somebody telling me I'm awesome is great, it makes me feel good. But me feeling -- knowing -- that I'm awesome at what I do, that is orders of magnitude better.
I've had programming jobs where I wrote dime-a-dozen software (sales system) and made crap money from an ungreatful employer, but it was worth it, and I felt worth something. I learned a ton, worked with great people, and made the most kick-ass software I could. I was a very positive asset to the company, my colleagues and customers. When the work you do improves other people's lives in some way, that makes you worth something.
A note on the small supply, huge demand: basic economic theory says that situation doesn't last. Either the supply rises to meet the demand (when the web blew up, there were relatively few JS and PHP experts, now they're everywhere), or the demand lowers to reconcile with the low supply (if you can' find any more good COBOL programmers, maybe it's time to start moving your software to more current technologies).
Acquire very broad programming skills, then pick your specialty and gain very deep knowledge of it. This may start with a university education, upto and including a PhD, but none of that is required. It could be all "on the job". Being even virtually indespensible however, is virtually impossible. Even though you may be as unique as a snowflake, you are probably still very replaceable. Your best bet is to be valuable to the employer. This means you must prioritize the company and business. If you can create more value in their product by adding needed features or whatever, and can decrease development and support costs (good code design, implementing best practices, etc), then you have become very valuable to a company.
I like what this guy has to say: Teach Yourself Programming in Ten Years. Also, https://www.thc.org/root/phun/unmaintain.html.
And never forget, demand for any specialty will wax and wane overtime. It may be that it becomes difficult -- virtually impossible -- for you to be gainfully employed in your area of expertise. So remain flexible. That is half the reason I suggest building a broad base of programming skills. The other half is, being able to see the whole picture, and to see things from multiple angles, often helps you understand how to best solve problems in your little corner of the programming world.
Last edited by anduril462; 02-27-2014 at 12:14 AM.
I have discovered a truly marvellous speciality, which this post is too small to contain.
Don't try this too soon.
Take some(5..10..?) years to acquire knowledge naturally.
You'll know what to specialize in long after you become a competent developer.
I think numerics is promising provided you have the graduate education to back it up, though it seems like the demand is small.
AI and machine learning are rather complex areas with comparatively little innovation. Particularly because every time you here something extraordinary being done about it, you soon realize they are instead trying to have a machine simulate human intelligence or cognitive abilities. In a finite state machine, no less. We need better and smarter engineers that want to look at artificial intelligence and machine learning as belonging to the domain of machines. We need better artificial intelligence and better machine learning. We don't need mankind emulation in a FSM. We need artificial intelligence in a FSM. Something that we can really use and depend on. Something that makes computers stay as reliable sources of information and with predictable behavioral patterns that we can trace back.
Last edited by Mario F.; 02-27-2014 at 12:15 PM.
Originally Posted by brewbuck:
Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.
The best specialization? Being an excellent programmer.
I'm not actually kidding. The world is filled with mediocre programmers, even with advanced degrees. The truly talented are not easy to come by and companies will fight tooth and nail to hire you.
When we hire, we don't even care if you know the languages we use - we just expect that you're a great programmer. Actually, if there was one "nice to have", it would be real-world, non-programming experience in the industry we supply software to (in my case, the medical industry), but again, that's a nice to have. The requirement is to be a top-notch programmer.
You ever try a pink golf ball, Wally? Why, the wind shear on a pink ball alone can take the head clean off a 90 pound midget at 300 yards.
Cat, I have to ask, what makes someone an "excellent" programmer to you?
Is it dedication to detail? A willingness to write, erase, write, erase, write until you have the "perfect" code (most efficient [memory or speed], clearest variable names and flow)?
I'm happy to hear that a company knows the languages you know are irrelevant but the majority of jobs are run by recruiters who recruit by doing the following, "Do you know Visual Basic?" and if not then they say, "Well, goodbye."
Seriously, I had a senior VP of recruiting or whatever tell me that he didn't know the difference between C and C++ because I made the joke about my C++ experience at the time, "Well, all C code is valid C++, right?"
But if I had to define an "excellent" programmer, I'd say it's one that also works well with a team and can throw away mountains of work for a superior algorithm that is not theirs. There is no ego, only good code.
Well, of course one needs to have good fundamentals - i.e. translating business requirements into functional code. However, what I think really separates the best from the average:
1. Someone that can structure code well. For example, proper encapsulation / separation of concerns, clearly defined functions/methods that do one specific goal, etc. Mediocre programmers often produce code that works, but is poorly encapsulated, difficult to reuse, etc.
2. People who code for maintainability. Especially in my company, the expected lifetime of code is very, very long (multiple decades), and there's a good chance many people will be maintaining your code in the future. Writing understandable code is of course a key element here - cryptic variable names, confusing flow control, hidden side effects, etc. are major impediments to maintainable code.
3. People who can grasp the right level of abstraction for a problem. I see people fail in both directions - either they make something that is too specific, so it works for only one customer / situation but not others, or they make something that is too general, and tries to do far too much (this can cause the 'inner platform' effect, where configuration becomes as complex as the original programming language).
4. People who take the time to solve the problem right, instead of solving the problem easily. This can be a bit of a judgment call - sometimes it truly is too resource-intensive to solve a problem right - but at least you should know what the right solution is and get as close as possible.
5. Along with #4, people who solve the problem completely. For example, if you fix a bug that was causing corrupt data, did you also take the time to fix the existing corrupted data? If you're creating a new feature that replaces an old one, are you also making it as easy as possible for people to transition from the old feature to the new?
6. People who actually care about usability, and make features that are intuitive to their target audience, not just intuitive to the programmer who made the feature.
I'm sure there are others, but those are some rambling thoughts about what I like to see
I do agree with you on teamwork. Someone that can't work effectively on a team really has no place in most programming environments.
Last edited by Cat; 03-02-2014 at 12:13 AM.
You ever try a pink golf ball, Wally? Why, the wind shear on a pink ball alone can take the head clean off a 90 pound midget at 300 yards.
While I agree with everything you said, Cat, I don't think this has anything to do with the word "specialization". A perfect grasp of a language semantics and good practices won't do me any good in specialized fields of programming, if I don't take the time to study them. And this may (often will) include studying fields completely unrelated to computer science. Particularly in this day and age where software development is pretty much capable of addressing any problem domain.
I do agree the OP motivations seem a little misdirected, which in turn indicates he's certainly not ready. But in any case, when answering for the topic of specialization, we can generally agree to the assumption the user would have already gained the necessary grasp of the programming language.
Last edited by Mario F.; 03-02-2014 at 05:05 PM.
Originally Posted by brewbuck:
Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.
My stance is that it's an order of magnitude easier to take someone great and teach them a specialization than it is to take someone with a specialization and teach them to be great.
You ever try a pink golf ball, Wally? Why, the wind shear on a pink ball alone can take the head clean off a 90 pound midget at 300 yards.
but... what if they're great at being specialized?
