As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
I was wondering... There are people out there who code stuff going to mars, satellite control systems, nuclear facilities. What kind of training did they do ? What is their career path ?
I have a friend who, after graduating with a BS in optical engineering, went to work for Perkin-Elmer, grinding among other things, the Hubbel mirror. In his free time, he wrote software to calculate the trajectories of earth projectiles and teaching himself orbital mechanics. His interest and accomplishments so impressed people at NASA that they hired him and his career included managing SW development for the space shuttle simulator and acting as mission specialist on a couple shuttle missions.
I have had discussions with people working at Los Alamos National Laboratory and they say that in order to work there, you find someone who already does and then call them every week for at least two years and that may lead to an interview.
In other words, be interested and persistent.
A counter question - are you talking about R&D or production code?
Alot of the answers above apply to the R&D teams developing new ideas to enhance existing inventions, or to enable new scientific adventures that were not previously possible - in those cases I agree.
But there's still a slew of people writing the code that actually gets deployed with the hardware. As with any major endeavor - you don't want the visionary dreamers who came up with the radical solution to be the guys actually implementing the thing that could risk human life. It's two different focuses and two different careers.
I agree with the Academic, research approaches you're talking about the R&D teams.
But if you want to write the production code, get familiar with process and quality control and assurance practices. All of the fields mentioned involve development contracts with the government which will require the highest degree of due diligence and care, since they cost huge money, may risk at least a few human lives, and in the case of a nuclear facility - they could destroy entire populations. You want to make sure that code went through plenty of review and testing!!
To get on the development teams, learn some of the high end development processes and practices - CMMI, Six Sigma. Learn as much as you can about testing and lifecycles. Work in an internship close to this field, particularly if the internship will submit you for a clearance - a lot of the work you mentioned may require defense clearances, and it's a huge leg up if you graduate college with a clearance in hand.
There are dozens or perhaps many dozens of different types of jobs involved. Some do more physics, simulation, GUIs, command and control, and so on. Is this question "How do I get started down this career path?" or "I'm curious, who are these people?"
Those type of fields require an education (probably through at least masters) in Physics and Mathematics, where programming is a secondary skill.
The typical path probably looks like:
Get a student job in a University research lab
Learn from the "old" graduate students and employees
Get hired as a temporary employee in said research lab
Teach the "new" graduate students
Do something good to get noticed
Make contacts with people in the granting agency
Get hired by the contracting agency or one of their contractors
Related
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
I am a final year Computer Science Student and as part of my Bachelors degree I am doing a project on Data Mining of Microarray DNA expression data. I will have to develop a few algorithms such as Bayesian Networks to run on my datasets to find out how each variable(genes) affect each other.
As part of my Project Proposal I have to talk about which methodology I will use to develop my software. From what I have learnt in school and from extra reading I find that the Incremental Development model seems a good idea. I would run 2- 3 iterations of Plan, Design, Implement until I get the full functionality of the software. Could somebody with more knowledge than me please tell me it this sounds like a good idea.
The reason why I am not 100% sure which methodology I would use is because I don't have a team to work on the software, I don't have a client with requirements and I am very limited in terms of the amount of time to work on the project as I have 3 other modules. All the methodologies which I have read about seem to be for big software projects with teams of developers. What do you do if you are just 1 person and focusing mainly on getting 3-4 algorithms to work rather than focusing on getting broad range of functionality.
I was also thinking of using UML to get a better idea what I want the software to do and using like a stripped down version of an Object Oriented Methodology.
My guess would be I would have to use parts of more than 1 methodology at a very basic level but I just can't pick.
I am very confused and lost on the subject so any help is greatly appreciated.
Thank You,
For these types of work, I would suggest not to pay much of attention to methodologies, because after all, what matters is the algorithm. But, for the sake of having a response for your dilemma, I would suggest using XP (eXtreme Programming). Why?
Is light
It doesn't require filling many papers as RUP & others
Is more suited for changing evironments, such as yours
Just take a fast search at Google for XP methodology and you'll get a bunch of useful results. ARUP (Agile RUP) might be worth looking also.
I hope I can help you.
XP/TDD is harmonious with the scientific method; each iteration is a theory, the tests are experiments
It takes a lot of discipline to follow a methodology while working solo, make sure you pick one that isn't labour intensive or you'll never live up to it.
If I was back at school in your situation with what I know now I'd probably go for Test Driven Development. Unit tests are ideal for testing algorithms and will leave you with a body of tests that you can use to demonstrate that you did follow a methodology.
Your idea to do the project in several iterations of plan, design, code and test is fine however with small projects it's sometimes difficult to resist the urge to do it all at once.
In case you do get carried away and finish the project in just one or two iterations, keep notes about the order in which you did things (ideally use a version control system) so that you'll at least be able to fudge your documentation to make it look like you used several iterations. Not that I'd endorse such an approach of course ;-)
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I'm a Ruby on Rails newbie. I'm learning Rails in my spare time (my day job is C++ developer) and I like it. I would like to be paid to do Rails development full-time instead of C++.
How can I find a job in Rails when most job offering requires 2-5 years of Rails experience? What is the most effective strategy to get some credibility as a Rails Developer?
Thanks in advance for your answers.
I can't tell you how to get hired. I can give you the story of how I got hired, though. It may be helpful. Rather than putting the summary at the bottom, it's quite the long post:
Have a pet project
Learn all the time
TATFT: Test all the fucking time
Attend the local user groups
Share all the cool shiny things you come across
Contribute back to open source
Be active, helpful and constantly visible in the community
I got started with Ruby on Rails in September of 2006. My first project was not a blogging system like was cool at the time, but a forum system. I remember one of my first questions in the #rubyonrails channel was asking why I was getting an undefined method find on Thread, not knowing Thread was already a class.
In June 2007, I was hired at my first Rails job. I didn't know much then, perhaps a smidgeon more now. So as you can see, the process wasn't instant. Very few processes are.
What happened during this interval though was (aside from PHP contracting, being a checkout bitch and studying) that I continued asking questions in the #rubyonrails channel and refining the forum system until I got something I was happy with. In April 2007 the first official user group meeting of my home town begun and I attended that, mentioned I was doing PHP work whilst toying around with Ruby and was offered three business cards on the spot. I basically did cards.rand and picked a job that landed me an 8-month contract which I enjoyed.
I learned a huge amount during this job, as you should with any job. I applied what I learned to my forums, refining it using the techniques I was learning on the job. I've been refining it further and further since then and in its current incarnation it's probably my Open Source Magnum Opus.
After I left that job I was quickly picked up at another company where, again, I learned new things and applied what I had learned to my open source work. One of the greatest things to learn was automated testing. If you're not writing tests, you're at a huge disadvantage to those who are. I know of many prospective employers who are looking for people who can write good tests for their code.
Now that Github's about, I have a nice central location to share all my work where prospective employers can look. The only feature I crave from Github would be a list of all the projects I've ever contributed to, since this is what lures most employers. So far the "Big Three" in my mind would be: RSpec (better Hash diffing + other changes), Cucumber (That list of failing scenarios when Things Go Wrong(tm)) and Rails (documentation such as the Querying Guide and the in-progress Initialization Guide as well as bug fixes).
It also doesn't hurt to keep a blog of the technical (and not so technical) things you come across. If you provide useful information, you'll get noticed for that too. I got noticed enough that I was recruited to write a book.
I also attended the second Railscamp event in November 2007 where I met one of my future bosses and made a lot of "connections" with people in the Ruby community. I then went on to run a Railscamp in Adelaide (#4), and assisted with the ones following that in varying degrees.
I'm also very active in the community, helping out on of course here and the IRC channels on Freenode. Helping out is definitely one of the ways I've learned how to be a better Rails coder. You can witness other people making mistakes and suggest fixes, and also watch other people suggest fixes that you may not have thought of.
Currently, I'm teaching people Ruby on Rails and when there's nobody to teach I do development work. That's my day job. The night job is writing the book. I would advise you to only have one job, because over-work can lead to burn outs. That's what weekends are for, or so I'm told.
The best thing that you can do is have a live web application that is being used and is providing a useful service. Bring your laptop with the source code along on interviews and walk through it, demonstrating your mastery of and passion for the technology.
Contribute to open-source Ruby-on-Rails projects. You'll find lots of them on Github.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
What are some solo developer programming methodologies for smaller projects?
Just about any development methodology will work in a solo environment except for those that explicitly require a team (such as side-by-side programming). But even then you could get around that by just creating some imaginary friends/teammates or developing a multiple personality disorder.
Even as a solo developer you can use methodologies applied to large development teams.
Write a Spec.
Layout a UML.
Do pencil-and-paper UI design.
Hallway testing: If your expect a large crowd, ask Mom if it's easy to use.
Peer review: You can build ad-hoc review teams with other solo developers.
Keep an up to date schedule.
and so on...
I solo develop all the time, and these practices keep me in line with my own work and give my bosses a great resource to know what I've done and how far along I am. And they keep me on track, to boot!
The rubber duck methodology comes to mind:
http://lists.ethernal.org/oldarchives/cantlug-0211/msg00174.html
Many agile techniques work great solo:
User interviews and stories: If you don't know what your users want, why would your software be useful?
A simple spec: Or even just be a mission statement. "Let people broadcast short messages to their subscriber lists." "Use in-degree to sort internet search results." "Let people collaboratively answer programming questions." Whatever.
A strictly-ordered todo list: Helpful to keep you from drowning in thoughts.
Tangents log: A good to-do list has a "to-don't" component, so you don't obsess over things you aren't going to do (yet).
YAGNI: Stay on target. This is very important when working by yourself, because no one is there to tell you "No! Don't reinvent dynamic typing in Java! Get back to the project." To-don't lists help with this.
Test-driven development: Writing tests forces you to think about the end result, rather than getting bogged down in implementation details. You'll get bogged down enough anyway; no need to make it worse.
Frequent releases: Make yourself stick to deadlines. "We'll have a feature-complete version that includes user stories 1-4 by Friday. It won't connect to the network or save data to disk, but XYZ..."
User testing: Have your buddies look at what you're making on a decently frequent schedule -- maybe once a month, maybe every week, depending on how many friends you have and how much beer/pizza you want to feed them. Pay very close attention to what they say and do and think when using the software.
And other things that only seem like they make sense in big projects can help a lot:
Source control: Install git. It's bone simple. Use it. Don't obsess over it.
Off-site backups: Y'know. In case of house fires or floods.
A blog: But you're only allowed to write there when a release comes out. ;) Also helps you build an audience for your product before it even ships.
Hope this helps! Solo programming on a large project can be very daunting.
Follow what is laid out in this Stack Overflow question:
What Tools/Techniques can benefit a solo developer?
Also. Use Source Control. You wouldn't believe how many times I've been bitten by that on personal projects.
There's this:
http://en.wikipedia.org/wiki/Personal_Software_Process
It's probably overkill
The issue is more a question of what you are comfortable with and what problems you hope to solve. Most methodologies are used by a solo developer at some point (pair programming is a notable exception). The issue is are you actually alone, or just working by yourself? I have found that it is invaluable to have people I can bounce ideas off of. Furthermore having someone else to look at you code (peer review) is a great way to find issues that you just cannot "see". So to agree with Aiden Bell "Programming on your oen is uncool."
I would try and connect to a community (like SO) where you can bounce ideas off of others. Then you need to build your methodology in such a way as to allow for interruptions when you send an idea out.
Does that make sense? Why are you programming alone?
Pat O
Not really an official methodology, but I have done a lot of solo development (independent consultant and ISV), and here are the things I have found to be important:
Find an online organization (like
oisv.com) to share thoughts and
ideas
Make sure you take time to interact
with actual people in the real world
Set project goals, deadlines, and
milestones
Take time to do appropriate up-front
design and project planning
Set aside working hours are stick to
them
Don't work too much and burn yourself
out
Nothing is ever perfect, so strive
for good code that works, not
perfection
Get some non-programming hobbies
This is more of trick than a methodology. When you're debugging, explain the bugs out loud to yourself as though you were trying to explain it to a co-worker. It feels silly, but forcing yourself to articulate the problem out loud often reveals what the problem is.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
Myself and a friend have created a startup, but we are both software developers. We are quickly realizing that we are going to have to deal with and understand, all of the intricacies of business.
Are there any resources that can help us avoid common problems encountered by the non-business-savvy? How do you balance creating your product with maintaining realistic goals to reduce time-to-market.
It's like you need to take off your programmer hat and put on the business hat, and vice versa.
My software business was in a very, very small niche market centered on computer aided design of the magnetic layer in hard disk drives (www.micromagnetica.com - please note that I am in the process of closing down my business as the number of potential customers has shrunk to the point of making the business not viable. The web site reflects this point). I have been in business for 10 years and have done pretty well. My competition was a series of commercial and open source programs (mostly university or government sponsored), so, although the market was small, I was able to create a unique product that sold well.
Pitfalls:
Putting your needs above the customer - Customer comes first - always listen to your customer's needs and make sure your development follows their needs rather than yours. Every programmer has a list of things they want to learn or do. Don't use this list a guide for your development unless it solves an issue or helps create functionality that the customer wants/needs. This one point can make or break your company.
Not clarifying your business idea - Put together a business plan - it will help clarify what you are doing. Read the book, "The Art of the Start", by Guy Kawasaki to get the business perspective of starting a business. If you need money then you can use this to help secure financing from either angel investors or venture capitalists. Otherwise, it will help clarify what you are doing.
Not marketing yourself - Do this the following:
(a) Find a good name for your company and secure your domain name. Even though a bad choice for company name won't kill you (my first company was called "Euxine Technologies" and it doesn't get much worse than that), but my product sold itself and was not encumbered by the name.
(b) Put together a web site as soon as possible with a good description of your product. Google will eventually find you and traffic will start flowing to your site.
(c) As soon as you have a working prototype create a mechanism where potential enthusiastic customers can download it and start helping you find bugs. You can make this the full version with a limited time or a limited version with no time limit. I have done both and both work. Make sure that users know it is a beta (or alpha) version of the software. The most important part of creating the beta user relationship is they will ask for features that you did not think about and this could take development along an otherwise unforeseen (and lucrative) path. This will also give you a way to keep your hand on the pulse of potential users.
(d) If your product is applicable to a particular industry go to relevant conferences
(either get a booth or make contact with potential customers) and sell your product through demonstrations, flyers, and the distribution of free limited versions of your software on CD.
Not Branding yourself - come up with a logo that you will use to identify you and your product. This logo will show up on your web, your business stationary, and business cards.
Not Managing your money - initially there is going to be a long spell before the money starts coming in. Be very frugal with your seed money. The money will not start coming in the moment your deem the software is ready to sell. There could be a time-lag of at least a couple of months between when people show interest in your software and when the sale comes in. This will depend on how much your software costs. The more costly the software the longer the time-lag.
Once you start making sales, there will be seasonal variations in how much money comes in. Always try and keep at least 6 months worth of money in the bank to cover salary and operating costs.
Not knowing who your customers are - Once you start selling software, make sure you know who your customers are - they might be different from what you thought they were. When I started my software company, I thought my customers would be all R&D engineers who were doing research in magnetic layers. After a while it became clear that most of my users were the subset of this group that couldn't program, but understood the physics behind the software.
Not acting in a professional manner - When interacting with customers be professional - act and dress in a professional manner.
Creating a product because the technology is cool, rather than because there's a market.
Creating a product because you want it, rather than because there's a market.
Creating a website that lists the features of your product, rather than the benefits.
Assuming that advertising on Google AdWords will work for you.
"Build it and they will come."
The #1 rule of StartUp Club: Every startup should have both nerds and businessmen.
Most computer nerds don't know anything about how to run a business or market and sell a product. There should be at least one businessman at your top level (but watch them like a hawk, lest they steal away with the fruits of your labor :-).
Not understand/knowing who you are competing with.
Not understanding/knowing your target market.
Not including your customers in the design phase.
Not spending enough time gathering product requirements.
Spending too much time gathering product requirements (analysis paralysis).
Not enough marketing.
Have a strong team so you can trust the people you hire to do their job.
Be prepared to do whatever it takes to succeed (ethically of course).
Not having a direction (business plan).
Not having goals or having unreachable goals.
Not understanding cash flow. There are a vast number of profitable businesses who do not succeed because of clash flow issues. Just because you sold a 1000 units doesn't mean you can afford to pay your staff and or other expenses. As I have heard it before "Cash is king!"
These are just some things that might get in your way. I would recommend not only worying about the business side, but worry about what are reasons software projects fail. There are numerous books about how to collect requirements, produce quality code, testing code (e.g. TDD), project methodolgies (e.g. XP, Agile, ...), and many more topics.
Your startup will likely fail if you can't deliver a product or if you can't deliver a product that doesn't solve the problem.
Finally, it is hard to judge success if you don't define what it means to succeed. Is it staying in business, doubling your revenue in 1 year, breaking the $250,000 mark, or doubling your staff size. You need to define what it means to succeed not only in your business, but with each product you create.
Do your homework. If you are in the US, the small business association is a good place to find resources.
Trying to be all things to all people.
Often in trying to create a product that appeals the everyone, the product becomes so general that really no one can get excited about it.
In my opinion, it's better to target your product to a niche community of people with a very specific need and then fill that need better than anyone else.
Here's a common pitfall, but it's not restricted to just small companies: Lack of diversity in the management. The kind of diversity that's important is diversity of experience. I've seen a couple small companies that suffered from this pitfall. They can often go along for a while making good decisions. The problem is that it's almost impossible for them to tell when they're making bad decisions. This doesn't necessarily mean that they'll fail, it just weakens them to varying degrees.
Company Development - in the software industry you can make a lot of money (respectively to other trades) in a very short-time. most people tend to get greedy and want more money so the accept more projects and hire lots of people - but they don't develop their infrastructure, their communication-lines, their responsibilities, their developers etc. Because it costs money and you don't have a direct benefit from it and you lose your cool "flat-hierarchy-everyone-is-a-boss"-image (which is not the case anyhow)
I myself witnessed two promising start-ups fail because the grew way too fast.
So keep an eye on that one.
Shiny! Don't let developers chase the latest shiny thing on the internet that catches their attention. Keep developers focused on the core strategic needs of the company instead of steering your product in different directions as their interest is caught by other things.
There's a blog full of tips at OnStartups. A few recent, relevant posts: learn from the underpants gnomes: have a business model, and here are some marketing tips. The author is a developer-entrepreneur himself, which sounds like exactly your perspective.
Update: Dharmesh just set up a StackOverflow-powered site for just this sort of question: http://answers.onstartups.com/
Make sure you know your target users and their needs.
I worked in a really cool startup where we thought we had a great product, but we were unable to generate that great user story to really demonstrate how our product filled some need for them. This shortcoming prevented them from "connecting" with our product in an exciting way.
In my opinion, the disconnect was due to the fact that we didn't know our target users and understand their problems as well as we should have.
Sales Sales and More Sales. Plus a willingness to release before the code is "perfect" and release features incrementally. There is actually a pretty good Hanselminutes about this very topic and this very site (http://www.hanselminutes.com/default.aspx?showID=152)
Not having some people on the team with different ideas/backgrounds/personalities.
If everyone is always agreeing with each other all the time, and there isn't any friction, you aren't going to get anything done. Oh, you might be alright for a while, but if everyone thinks the same way, when you get stuck (and you will), you will stay stuck. When you're on a roll, a curveball is a distraction; when you're stuck in a rut, or up against a wall, a curveball can get you moving in a different direction. It might be the wrong direction, but at least it's a direction.
Not having enough knowledge and experience in marketing. Although selling a good product is easy.
The problem is what I call IBM OS 2- geniuses build a very good product but the product is not marketed well nor tailored to effectively massage the ears of buyers. I despise some things about business workers like short-term thinkings, perfering quick-and-dirty developers over slow-but-great developers and other issues- but they are the ones who make money and drive software into customers' hands. If a start-up does not have developers who can function effectively work with business issues- then it need to go get someone who can. Failure to do so make is what made Windows 95 a hit and IBM's OS 2 a dinosaur.
Not having a specific market in mind when developing a product. A couple of places where I worked tried to do anything and everything which lead to not enough effort on one market to get profitable first so the business could still be running.
Micro ISV links has some links that were shown in a top secret presentation I attended a little while back that may also be useful.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
I have had a talk with a friend of mine about the relative vulnerability of different types of IT workers to unexpected unemployment (e.g. layoffs, company going out of business, obsolete skills etc.)
as it seems COBOL developers (or maintainers?) seems very secure in their positions, regardless of the state if the economy or even how good they are. With so much critical COBOL code being around on the one side and the deminishing number of COBOL know-hows on the other , it actually makes sense to recommend someone starting their way in the IT world and looking for a relativity secure job to study and intern in COBOL!
what do you think ?
I started as a programmer with Cobol more than 10 years and worked with Cobol at different institutions then for several years.
Cobol as a technology is fairly easy to learn if you know any imperative programming language.
Cobol itself differs a lot on various platforms and versions - thus it is difficult to study the right version before hand.
The real challenge with Cobol is not the technology, but the complexity of the underlying business and the lack of documentation of the systems/programs. Thus the real value of a lot of COBOL experts is in fact not the actual COBOL knowledge, but the understanding of the business.
I think it makes sense to be a good software developer. For me personally, your question sounds a bit like: "What silo should I occupy to feel secure about my job and stop improving myself?" I know you didn't mean exactly this. But anyway, that's not the best motivation for choosing a career path.
I'd say: try tinkering on some COBOL code. If it's fun for you, go for it! Just as for dozens of other things you should try.
You have to understand that the arguments you made, are relative to time, that is now. We have seen time and again, how technologies seems so prominent at time t and becomes obsolete at time (t + 0.001). Though your arguments rotate around the very fact that COBOL is more or less obsolete, but they may find a new way to deal with it and again you become out of job. So here's rule number 1:
Never rely on one single technology.
With time, they always find ways to have lesser and lesser resources do the same thing. All you can do is to be a smart software professional. When you get the core part of computer programming, technologies wont matter, with time you could just learn them. So here's the second rule:
Don't just try to expertise a
technology, expertise software
engineering
Finally, to survive in IT you always need to be cutting-edge-aware. Also immaterial of all the above, you can still be laid off depending on the harshness of the recession. So finally:
Keep a back up line of work ready,
tommorow IT industry might not be
there :)
Try it, and if you like it then study it seriously.
If you learn it too well you may find you end up stuck in a COBOL role with no way out; it begins slowly and then you are drawn in because the knowledge is very specialised. If you enjoy it, that's fine - but if you try it and don't like it, then don't continue.
IMHO, It always makes sense to study a new language.
It's true that there's a lot of COBOL code running today, and much of that code is mission critical. However, how much actual COBOL coding is happening? I see large enterprises gradually replacing those COBOL systems.
From a practical standpoint, there's a huge base of legacy COBOL code running a lot of systems out in the world (many of them mission-critical) and it's likely cost-prohibitive to replace all of that software any time soon. The average COBOL programmer is probably nearing retirement age. Therefore one could reasonably assume that there will continue to be demand for new COBOL programmers for some indeterminate amount of time to come.
From a personal development/enrichment perspective, it certainly makes sense to study COBOL (and any number of other technologies both new and "less-new".). I'm not sure I'd put it near the top of my list, but its historical significance is reason enough to put it on the list. Somewhere.
My guess is that one of the reasons COBOL programmers (I'm a Fortran programmer, similar situation I suspect) are relatively secure is because they have oodles of experience; you won't get this from learning the language. Rather than ask how many COBOL jobs are there, ask yourself how often you see a COBOL job advertised. I think that it is much easier to hold on to one of these jobs than to get one.
And, of course, when one is advertised, you're in competition with all those very experienced currently-working-in-COBOL programmers.
Regards
Cobol developers are secure in their positions because their code makes money. It is not a horrible language to learn. Actually, it is rather nice once you grok the structure of it.
But it is only one tool in your tool box, you should have several.
I'd say it is not a complete nonsense to learn COBOL, as long as it is not the only technology you learn.