
Become an exceptional programmer by learning to ship - markoa
http://renderedtext.com/blog/2014/01/30/become-an-exceptional-programmer-by-learning-to-ship/
======
sgift
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.

~~~
asolove
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.

------
Nursie
Meh.

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.

~~~
silverbax88
++ for #1.

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.

~~~
csmithuk
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.

------
thu
That maybe looks like a sensible approach, but it really seems like another
arbitrary approach to put the bar "higher".

People have had such "requirements" since ages. "We only hire candidates with
university degrees", "we only hire PhD's",.

Unless you're a small company, not everybody will "ship", or write audio
codecs, or interact with prospects, and so on.

~~~
invalidOrTaken
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.

------
dictum
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.

~~~
dasil003
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.

~~~
vonmoltke
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.

~~~
dasil003
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.

------
bowlich
> 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.

~~~
nawitus
Yeah, apparently according to him it's not enough to have a github account
with quality software, it also has to be used by hundreds of developers.

------
umsm
This is probably the most important point:

Young programmers, due to lack of experience, sometimes don’t see that writing
code is only a small part in producing software.

------
peterwwillis
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".

------
dahart
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!

------
maguirre
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"

------
polskibus
Productionalization is important indeed, however I'd say that it is a trait
desired in any engineer, not necessarily a programmer.

------
coldcode
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.

------
edabobojr
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.

