This is a profoundly ignorant question to ask:

- Lawyers do essentially have to practice law in their free time. Many, many state bars require continuing legal education in order to remain barred. Can you imagine having to pay money for classes or be legally prohibited from programming?

- This is also true for doctors and nurses. Continuing medical education is mandatory for both to be allowed to practice.

- Most professional academics spend a huge amount of their "free time" thinking about their field, reading journal articles to stay current, and taking classes to stay current on new statistical software, programming skills, etc.

As to academia... don't get me started. That is a strange and unusual profession which lies somewhere between 'hobby as job' and 'slave until you're tenured'.

The idea of a profession is that one is not generally paid by the hour for "work" even if one bills a client by the hour so time spent on professional development whenever it takes place is part of work and covered by a salary rather than a wage.

Of course it might be true that other professions do less non-billable practical work though this is probably more due to the fact that programming doesn't require a significant budget.

The issue I think is one that many companies want programmers to work more like wage laborers and take care of the professional side for themselves.

For example a law firm is probably more likely to allocate budget for associates to use for professional development than an IT contracting company.

- Medical professionals require 48 hours of continuing education per two years, of which 24 may be informal self study or hospital lectures - Legal professionals require 15 hours of continuing education per year - Professional engineers require 17 hours of continuing education per year

CEUs are obtained either through classroom instruction or attendance at recognized conferences or seminars. This is not the same as doing your day job after hours for fun or because you feel you must in order to actually get a new job. It certainly does not keep your skills sharp.

Doctors, lawyers, and PEs also have professional societies and often employers to facilitate obtaining CEUs in the most efficient manner.

That said, self-study is a different animal from the side project nonsense that the thread root is referring to. I personally engage in a significant amount of self-study. Some of it a roll back into my day job, some I experiment with in my free time, the rest is purely academic knowledge acquisition. I don't have anything tangible to show off, though, because most everything I have done off hours is the software equivalent of a carver or welder practicing with scraps.

Maybe that isn't the right attitude for a programmer, but in that case a programmer is a different animal than any of the professions listed previously.

Yes. My dad is a critical care doctor. He regularly spends some of his free time reading medical journals, or studying for the re-certification exam.

Not doing that may make them bad, but doing it will not necessarily make them good.

Yes, most professionals do. Licensed professionals--doctors, lawyers, veterinarians, civil engineers, teachers, etc.--are usually required to get a certain number of Continuing Education Units every year to retain their professional license. The specific requirements differ from state to state.

The only reason why I was able to land my first dev job fresh out of college is because I had an open source project that I built in my own free time. If it hadn't been for that, it's unlikely I would've got the job and that's why I loath the practice so much.

16+ years of formal education down the drain (or 30+ years of work, if you're older), unless you adhere to some arbitrary standards by IT blogosphere keyboard jockeys.

Lawyers who work for a firm? Maybe. If they work for themselves, they're stuck paying the bills; continuing education is required in many fields, and yet it's not always reimbursed.

>Staying up every night committing to Github in hopes of landing a job is a terrible terrible thing.

That's never the "right" thing to do. The right thing to do is to commit to Github because you want to.

>16+ years of formal education down the drain (or 30+ years of work, if you're older), unless you adhere to some arbitrary standards by IT blogosphere keyboard jockeys.

OP wasn't talking about arbitrary keyword standards. You're tearing down a strawman of your own creation. OP was just talking about whether a developer actually could code, not filtering based on exact keywords.

To your comment: Some domains DO take way more work to learn than I would be happy hiring someone with no experience in them. I'm not talking about the fancy JavaScript framework du jour, or experience using a particular database, but actually different domains. Like kernel programming. I wouldn't touch a Java developer with 10 years of experience at enterprise Java for a project that involved kernel-level code. Or game programming. Or Android app programming, even; most Java developers would still take months to get up to speed on Android, if they ever managed adapt to the Android way of thinking at all.

ETA - I do agree w/ your main point, though - I wouldn't put a Java dev w/ no kernel experience on a kernel project either.

Android is NOT just an API. You need to really grok the Activity Lifecycle [1], or your app won't behave correctly. I don't mean just skim it; I mean really get that you need to save state at the right places, or you'll break the behaviors.

You need to understand how to support multiple devices correctly [2], including how to best design the app to scale to multiple screen sizes. Ideally you'll support both phone-sized and tablet-sized devices, and so you'll probably need to understand how the Fragments API works [3]

You need to understand Intents and how they function. [4] You need to know whether you'll need a Service [5].

This is just the stuff off the top of my head that you need a clear understanding of before you write the first line of code. Most of these things are not easy to just "use when you need them;" you need to know how they all interact before you start, or you'll be throwing out a lot of your code.

Android is a really alien API, even to people who've done GUI work before: I think it's very poorly designed from a "Principle of Least Astonishment" point of view. They created a lot of new concepts, and I don't really think all of them are superior to the standard way of doing things in a GUI. But they are what they are.

I've TRIED to work with an experienced Android developer who didn't know all of these in advance, and he tried to charge me for 30+ hours of work for something that should have taken 2-3 hours -- just because he'd lied about KNOWING how to use Fragments. I can't imagine a Java developer with no experience diving in and getting all this right the first time.

[1] http://developer.android.com/training/basics/activity-lifecy...

[2] http://developer.android.com/training/basics/supporting-devi...

[3] http://developer.android.com/training/basics/fragments/index...

[4] http://developer.android.com/training/basics/intents/index.h...

[5] http://developer.android.com/reference/android/app/Service.h...

So you doubt they would be able to adapt to an environment that uses the exact same language they've been using for 10 years, simply because they don't know the API? Do you think that someone who is smart enough to do Java development for 10 years isn't smart enough to pick up a new Java-based environment in days/weeks?

Your attitude reeks or arrogance, elitism and lack of empathy. I'd never want to work with people like you in any capacity.

Not exactly. Probably 95% of "Java Developers" have never touched a GUI, or an event based OS, or graphics code, or an end-user app, for that matter. They'd have plenty of ways to fail besides not knowing how to read a manual.

>Do you think that someone who is smart enough to do Java development for 10 years isn't smart enough to pick up a new Java-based environment in days/weeks?

Weeks, maybe. Days: It depends on what you mean. Start tweaking Java code in an existing app? Sure, why not. Architect a non-trivial app from scratch? Extremely unlikely. Again, talking statistically.

95% of Java developers are NOT as sophisticated as probably half of C++ developers. There's a higher minimum threshold of skill to work on the problems that C++ developers work on than the ones that MOST Java developers work on.

You can be a 100% competent Java developer, and yet not have the right skills to do most of what I do on a regular basis.

And this isn't about YOU; I'm only talking statistically. Most Java developers work on server code, enterprise code, private company apps, and other things in very different domains that thinks that I work on. These things are important, skilled work; and they're VERY DIFFERENT than Android development. Or game development. Or low-level C development.

>Your attitude reeks or arrogance, elitism and lack of empathy. I'd never want to work with people like you in any capacity.

I do believe I'm a better developer than most. I feel like that's based on objective facts, but it certainly can come across as arrogance or elitism. Truth is I'm happy to work with developers of any skill level, as long as they have the skills to do the tasks they're assigned to do. I spent years working as developer tech support for a popular API, and I helped hundreds of developers to use it correctly, and to find the bugs in their apps -- by the end I had a nontrivial fan club, and a lot of people contacted me later to see if they could work with me. But have it your way.

I don't know how you glean lack of empathy from my post. I empathize with people just fine; if I'm hiring someone, though, I have to make a business decision that makes sense, and I'd have to be stupid to hire someone who can't get the job done, as much as I'd love to give everyone work. Too often I've not been ruthless enough; someone with years of experience in Android AND Java and tons of great references must be good enough to get my project done, right? Wrong. See: Mythical Man Month, some programmers are 10-20x better than others.

If you tell me who you are, though, I'll be sure that we don't accidentally work with each other in any capacity. Though since your comment sparked this thread with hatred at people who hire based on (among other things) GitHub commits, I suspect that isn't a danger to begin with.

The article presents doing your own projects as a thing you should do.

>Or Android app programming, even; most Java developers would still take months to get up to speed on Android, if they ever managed adapt to the Android way of thinking at all.

Are you suggesting that it would take an experienced Java programmer several hundred working hours to get up to speed on Android? And that you expect new hires to have worked several hundred hours on Android in their free time instead?

Well, if you don't want to, and you don't have real experience elsewhere in a domain close enough to what I need, then you won't likely be a developer that I work with, no.

>Are you suggesting that it would take an experienced Java programmer several hundred working hours to get up to speed on Android? And that you expect new hires to have worked several hundred hours on Android in their free time instead?

Most Android developers work solo, at least the ones I know. If you can find a team to work on somewhere -- some big company that has 4+ people working on an Android project, then maybe they can hire a Java developer and train them on Android. I have no desire to pay a developer for more than 20 hours to learn to do something that shouldn't take more than 4 if he already knew how Android worked (this happened to me, when someone lied and told me they DID know how the Fragments API worked, for instance -- after 20 hours he had a mess of garbage that I threw out).

But a solo Android developer probably needs at least two to three months of Android coding experience to really "get" the relatively more obscure parts of Android, yes. Can a Java dev write code on day one? Sure. Can a Java dev start writing production code from day one? Day 14? Not anything I'd want to use.

Major exception: Java is Java, and so having someone contribute to an existing, already working app, but staying in the "data mangling" domain, could be done from day one. I'm really talking about knowing how an app should be designed, not whether someone can write code to talk to a database on Android after 10 years of experience writing Java that talked with databases on servers.

All other things being equal, the person with experience in the specific tools the organisation uses will get the job.

Its just an unfortunate consequence of the industry we are in.

You are of course free to not chase the bleeding edge tools in your spare time, and youll probably stay employed just fine. But there is a risk you can be left behind or miss opportunities.

The people who were hacking on early IOS, Rails, Scala etc are todays experts enjoying niche markets. The people who didnt are working on VB or PHP for a Sausage factory somewhere.

I learned Android on my own time, because I liked the idea of a Linux-based phone OS. Most of the jobs I've gotten have been EXACTLY because I've been playing with the right technology on my own time. OP is right on, and VexXtreme is making noises like a mediocre developer who has a chip on his shoulder.

But The fundamental data structures/algorithms don't change and the problem solving skills don't change. For example, get an Oculus Rift dev kit, fool around on that for a few months when the consumer version comes out you'll probably have more work than you can imagine. It's the same pattern.

On the other hand, Linux kernel programming, which is what the author mentions, hasn't changed that much over the years. What the author seems to bemoan is that the developers are letting those core skills slide because they become dependent on the tools they use in their day-to-day jobs. But actually, I'm not convinced that the mediocrity of the candidates was due to decaying skills. They may not have been particularly skilled to begin with. Experience doesn't necessarily correlate to competence, after all.

Doctors are expected to keep up to date with the most recent research as part of their jobs, and they are payed to do so by going to conferences etc... I don't think the same can be said for software development.

I see your point but I don't think it is specific only to IT. Lawyers for example (at least in Germany) have to read a lot to keep up. So much that most of them can't do that at work.

Anyway, in a sense I agree with the author. To stay sharp programmers need to get out of their comfort zone. There's multiple ways to do that; side projects is one of them. If you don't get out of your comfort zone, you run the risk of becoming like a pilot who forgot how to land or take off, because you have only been flying mid air for so such a long period of time.

Now here's where you can win. The hiring manager or business owner wants to minimize risk. If you have 20 years experience working on mainframes in cobol, chances are you're going to be an a passable programmer with good fundamentals. Now say the hiring managers company is using rails or node.js. You know you can learn it quickly. But The manager might be nervous that you that you don't like to adjust and you won't be productive for 2-3 months while you learn. Maybe he/she thinks you're going to be complaining the whole time about how node.js sucks (while you forget how much cobol suck). You can alleviate this worry by having a few simply projects up in node.js or whatever the latest craze is + you have good fundamental experience.

So enjoy you're travels but maybe put a minimal side project up every year or so. That's my plan and I'd like to keep doing this developer thing for a while. I'd like to think, as someone who will eventually get old and have lots of experience on outdated stacks, these are some of the tactics we can use to combat ageism in engineering.

Software is a career requiring a much higher level of personal commitment than many other careers, while often not necessarily being better compensated.

Isn't the level of personal commitment subjective though? What would your solution be?

I think it's hard for programming because there's such a diverse array of programmers (university educated based on data structures / algorithms vs self-taught that might not know those things). My recent interviews with Amazon tested my core CS knowledge but nothing like frameworks or anything. I suspect those things would matter more at startups / web shops (where I used to work).

Except it really doesn't. Most of us chose to put in the personal commitment because we love it and then convince ourselves it's because we have to.

I know several people who code 9-5 Monday to Friday on whatever their boss tells them to code on and that is it. Sure non of them will ever be offered a top job at Google, Facebook or awesome SV startup of the week, and sure most of what they do sounds frightfully dull, but they still have a successful if unassuming career in software.

I read that article, and while i don't fully agree with it, there seems to be at least a grain of truth in there. He talks about how VB programmers are no longer wanted because VB.net is hot stuff now (the article was written in 2007.) He also talks about how one's professional knowledge counts for lesser and lesser as a programmer, and how a lack of any barrier to entry has resulted in a field flooded with cheap workers with no job security or general social prestige.

I consoled myself thinking this won't apply to the more sophisticated programmer, who is well trained in algorithmic and mathematical thinking. For example, writing machine learning systems, advanced statistical analysis or kernel development etc. DO have at least some barrier to entry, and these are not things that a random script kiddie can learn in a "x for dummies" book. Can a more senior engineer comment?

The areas that you mention only have a high barrier to entry because there is no bulk job market in those areas, plus no one has yet decided to write a 'x for dummies' book in it for the exact very same reasons.

There are more websites written everyday than kernels.

Web development isn't particularly easy, but has been made easier because there is demand for it that way!!

Let say you have a markup language. The language implements every kernel feature known to mankind. Now all you need to do to get your very personalized kernel is specify the interplay of the features though the markup. Lets say such language also keeps updated with all latest developments in Kernel development field. Over time you see, even the most noob guy producing their own framework to do a range of kernel work.

Kernel development will look pretty much like producing a HTML page. And you will have a dummies book for it.

This is kernel development would look if there were millions of jobs worldwide for it.

You could apply the same analogy for anything.

That makes me wonder what kind of technical skills have long lifetimes, valuable in the real world (as opposed to merely being technically interesting), and are difficult enough to acquire that one doesn't have to worry about competition against a low-paid worker army....

For me, software development and picking up new technologies and abstractions IS "making the most of this one life that I have." If you truly love what you do, then there shouldn't be some dividing line between what you do for fun, and what you do for money.

You shouldn't program on your spare time in order to pick up new high-demand skills, indeed that's just a pleasant side effect. You should program because it is fucking radical.