Ah, the old "we only hire people with experience" topic. Same question as usual: Where should they get that experience?
Answers I usually get:
- "on their own": You want to tell me that someone should learn on their own how to go through all phases of shipping a software without guidance? And you think that will produce programmers who know how to do that 'correctly'? I'd like to advise you that playing the lottery has comparable chances and that you should try it.
- "at our competitors": That will only 'work' if your competitors don't have the same same idea.
New answers are very welcome, the topic seems quite stale to me.
As someone who has worked on teams willing to train less-experienced developers, I find that previous expertise in any other subject is a good indicator of future success in web programming.
I've seen good Ruby and JavaScript developers learn their way up from expert-level html/css buildout people, from professionally-trained musicians and chefs, or in my case from a MA in Chinese literature.
Yes, programmers need to be able to model program execution in their head, and only some subset of humans can do that. But after that hurdle, the biggest factor in success is sustained practice, humility about your skills, and a willingness to listen to advice without following it dogmatically. These skills can be developed and demonstrated in lots of non-programming backgrounds.
In an interview, you want to establish that the candidate knows what they're talking about, can do basic boolean logic, functional decomposition, etc. But after that, you just talk to them about their internships, class projects, and hobbies. Find something they are clearly proud of, and ask them about it. Probe the strategic decisions and tradeoffs they made to see that they have some awareness of their process. If you find someone who can't talk about something they're really mastered, in any field, programming is not magically going to become the first skill they practice to mastery.
Ultimately, being able to identify people like this is an enormous strategic advantage. There is no boost to a team like a new junior teammate who asks questions, takes advice, works hard, and show enjoyment at tackling new hurdles. And nothing better for a businessperson than someone you can pay less now and continuously give big raises over the next few years while still getting a better deal than hiring a senior person.
1. Exceptional programmers write neat, maintainable code. Anyone can ship something that works right now but has maintenance costs up the wazoo later.
2. If you recruit based on open source contributions you'll miss out on the many, many fantastic devs who have no involvement in FOSS in their day jobs and like to switch off at night. (I love FOSS but I also love sleep)
3. All of what is written about in this blog entry is better termed experience. What you want is experience of working well in the industry. The blog entry is about as useful as saying "if you want a good employee then choose someone that's already shown they can do what you're asking". This is not new information.
There are dozens of projects I've supported that were built by guys who banged it out in a couple of weeks, or a month or so of development, and it's almost always built for a single purpose. The moment the business starts thinking about other ways to use it, it becomes a mess.
Unfortunately, there are a ton of businesses who think they can get ramped up with a tiny, banged out product to sell and then 'scale up'...when in reality, they have a throwaway toy on their hands.
On the plus side, there are those of us who are brought in for their experience at untangling these messes and coming up with solid solutions that can scale up feature-wise. The same people will willingly dig out problems and fix them in production when all else fails.
People queue at your door if you have these skills.
Mediocre programmers create a lucrative market for unicorn shit as I was once told.
#1 is very true. But exceptional programmers are also extremely rare birds. To the fact that it's quite plausible to expect that the average company trying to hire one won't be able to. And even if they do manage to find one, keeping him may prove challenging and arduous.
Given this, having a mediocre coder whose managed to ship finished projects is worth many times the mediocre coder who hasn't.
Further: it's possible to select for whatever makes your particular shop special. Fifteen years ago "only early adopters with the foresight to learn ColdFusion" might have been the metric.
If reliability and predictability are the goals (and I think they are with this kind of thing), I think a far more sensible approach would be to treat developer groups like cults. "You can code however you want at home; here we are dogmatic, and everyone uses JetBrains. Everyone tests, everyone debugs, everyone ships."
It sounds draconian and not altogether pleasant (and I agree), but I wonder if it might be a solution for companies who distrust off-the-street devs so much that they erect hiring barriers out of fear.
Honestly, I think this is delusional. A developer that successfully develops and launches a product probably won't be looking for a job, they'll be maintaining and trying to grow the product's user base.
This approach will get you people who shipped products no one (or very few people) wanted. It's not as bad as it sounds, but it's not the amazing you-big-developer-ubermensch-you thing these articles on shipping your way to a job make it seem.
Perhaps, but consider there is a shocking number of professional developers who have never actually built and shipped something. They have only done maintenance on existing products, and for all you know they are NNPPs hiding out in a large team under thick blankets of political management.
Sounds like you are creating a false dichotomy between maintenance and greenfield short-cycle product development. What about the embedded developer at Ford or Boeing for whom product development means taking the code from the previous product and adding/removing features? Where product life cycles are measured in years instead of months? How about the developer writing machine learning code for Bloomberg or Wal-Mart, whose code will never see the light of day and whose "product" is never really finished?
I could go on, but this demonstrates there are many good professional developers who do not fit the SV bubble's concept of a good developer.
Of course what you are saying is true. I didn't mean to imply that I think this is some kind of great litmus test. In fact I think all litmus tests are bullshit. The uncomfortable truth is that there are probably people out there with no programming experience at all who will be better programmers after a year than some 20 year veterans who have learned enough to get by but just aren't that good.
My point was simply if you have to filter on some arbitrary criteria, finding people with a habit and verifiable record of shipping is probably a pretty good indicator.
> So for example, publishing source code of an implementation of an audio compression algorithm on GitHub is not shipping. On the other hand, a library with multiple versions, downloaded and used by hundreds of developers is a clear indicator of shipping behavior.
My initial thoughts on this are that there are many us who are completely uninterested in spending time promoting our code. I'm fine with developing stuff and putting it up on github as an example of what I'm capable of doing, but promoting that code, getting other people involved and using it? That's marketing, not development.
I grew up in the open source community. There's a lot of really good best practices that you pick up there as you contribute to or pull from other projects. Among those are the development/stable release trees.
If you have something that "just works", you do a release, but to a development branch. Eventually some of those features can get backported to stable, or the release will get upgraded to stable after thorough testing, or all new feature development will end once it's been tested enough to ensure a stable release. There may be 10 development releases before a stable release comes out. The benefit is you get to "just ship" code, but stable users aren't forced to deal with your bugs and various changes just because you wanted to get an experimental feature out the door.
"To ship" is not a software development practice. It's silicon valley hype. It's the idea that delivering an average product is more important than designing, developing, testing, and producing a really good product. The author is right, this is difficult. But this is not what I think most people consider when they say "to ship".
People I respect told me the same thing, so I used to believe shipping made me a better programmer. It probably did in the sense that you see what it takes to finish, and sometimes it takes dropping your ideals for a while. Sometimes it takes a lot more polish than you expect. Sometimes you see the flaws in your genius designs exposed, and you learn what ways you failed to cover all possibilities even though you had 'proved' it.
But, shipping has also done me as much damage as good. Unreasonable deadlines lead to bad decisions. Crunch times make me stupider, take many months to recover from mentally, and frequently are so crowded with patching things up that the lessons I should have learned about what I did wrong are lost in the wind.
Any company that wants to get on their white horse and trumpet about the virtues of shipping should be required to back it up with strong data on the virtues of excellent project management as well as how they have figured out how to ship software on a deadline with absolutely no overtime!
I don't know what I am missing here but after reading the article I came out with the following:
"If you want to be a good programmer you should do a job well done"
Real programmers ship, i.e. real programmers that work for sane companies and management sometimes ship code that customers actual want. Shipping products is rarely dependent only on programmers.
I think that either I misread this article or some of the other posters have. The author isn't talking about shipping a product, the author is talking about delivering code to production.
Answers I usually get:
- "on their own": You want to tell me that someone should learn on their own how to go through all phases of shipping a software without guidance? And you think that will produce programmers who know how to do that 'correctly'? I'd like to advise you that playing the lottery has comparable chances and that you should try it.
- "at our competitors": That will only 'work' if your competitors don't have the same same idea.
New answers are very welcome, the topic seems quite stale to me.