Ah, the old "we only hire people with experience" topic. Same question as usual: Where should they get that experience?<p>Answers I usually get:<p>- "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 <i>without guidance</i>? 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.<p>- "at our competitors": That will only 'work' if your competitors don't have the same same idea.<p>New answers are very welcome, the topic seems quite stale to me.
Meh.<p>1. Exceptional programmers write neat, maintainable code. Anyone can ship something that works right now but has maintenance costs up the wazoo later.<p>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)<p>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.
That maybe looks like a sensible approach, but it really seems like another arbitrary approach to put the bar "higher".<p>People have had such "requirements" since ages. "We only hire candidates with university degrees", "we only hire PhD's",.<p>Unless you're a small company, not everybody will "ship", or write audio codecs, or interact with prospects, and so on.
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.<p>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.
> 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.<p>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.
This is probably the most important point:<p>Young programmers, due to lack of experience, sometimes don’t see that writing code is only a small part in producing software.
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.<p>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.<p>"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.<p>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.<p>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.