
What is the best way for a non-CS major to obtain credibility as a programmer? - ecounysis
http://stackoverflow.com/questions/999644/what-is-the-best-way-for-a-non-cs-major-to-obtain-credibility-as-a-programmer
======
kamechan
i could really write quite a bit about this. i'll try not to and instead
attempt to be concise.

i wasn't a cs major before either. 2 years ago i set aside a quite successful
consulting business i'd started to go back to school as a 30-something self-
taught industry programmer and "fill in the gaps" so to speak.

let me say that a good cs education makes a night and day difference to being
self taught. even if you're rather good. sure there are very good self taught
programmers and while, of course, i'm self-deprecating and don't consider
myself one, i've known quite a few. and sure there are also a lot of hacks in
university CS programs, even the good ones though relatively fewer the better
the program. i'm surrounded by lots of people who i stupidly judged as
"beneath me" at first, because of all my so called industry experience, but
90% of them continually surprise me with their ability to solve very complex
problems under very non-negotiable deadlines.

i thought i knew something when i went back to school. indeed, this actually
caused me quite many problems at first because i tended to rely more on what i
knew than what was being taught. but i reached a point rather quickly where my
industry experience wasn't going to help me at all, and in fact actually
hindered me because there was much i'd learned incorrectly.

but that's why i went back to school. so i threw much of what i'd accumulated
over the years out the window.

i was previously a math major, but even doing the required CS discrete math,
number theory, combinatorics, probability, set theory, formal logic, etc.
introduced me to ways of thinking about math i had not previously seen. i
think this is where a bit of rigor in the program one selects helps. some cs
curricula will just gloss over these details, but at a huge disadvantage to
the students because a really good understanding of a worthwhile algorithms
book (cormen, leiserson, rivest, stein, for example) requires them. there's a
big difference between doing something (i.e. writing code) and doing something
well (writing purposeful code that is an elegant expression of some
theoretical model).

a solid basis in algorithms is an immensely useful thing. even if it all just
seems like "theory" at the time.

why? because i can understand most research papers or published documents i
read now without having to look things up. or when i have to look something up
because i don't know the answer, i generally know the right direction to look
in. or i can look at someone else's code and see that they have actually
chosen the wrong data structure for accomplishing a task, leading to a vastly
inefficient algorithm. or, more importantly, framing the problem in the right
graph-theoretical model and, as a result, exposing a richness in the data that
i'd not known to exist previously. my first taste of this was the famous four-
color theorem. from there i was hooked.

...and that was just the first year of being in school. it's also worth
pointing out that year i really started to realize the importance of being
able to rigorously prove the correctness of each step of an algorithm. though
a lot of proofs are those by construction where one essentially describes
building the model as the proof, some loop invariants or algorithms must be
proven inductively for one to have any certainty about them. indeed, i now
believe this was a critical skill to develop. proving the correctness of
things improves one's ability to think clearly.

interestingly, in my free time i often consider how my education has affected
my old development patterns. it might seem that with all this extra formalism
that i now sit down and plan everything out before writing even one line of
code, harkening back to the old rational-rose way of doing things. to put this
to the test i've done a couple side projects in the last couple years and
found that my development style was about the same as it was previously: start
with an idea, address the nagging issues with implementing it, build a quick
(but refactorable) prototype, test the hell out of it, and revise it until it
all works. the thing is that in those interim steps i'm drastically more
competent now than i was before. when i get stuck on something i can often get
unstuck quickly by reasoning my way effectively out of being lost in the
forest, and with the tools i have (and paradigms i have access to) if i
absolutely must write my own solution from scratch, it's generally written
well. and if it's not, it's usually because i didn't understand the problem i
was trying to solve ... not the particular coding technique i was trying to
solve it with.

so other activities (non-chronologically) were things like writing operating
system components, replacing parts of the java collections framework with
probabilistic data structures or building our own red/black trees, designing
chips, writing an embedded system or microkernel, creating
oCaml/scheme/haskell parsers and REPL's, building C++ as stroustrup first did
(by doing lots of plumbing with void pointers in c), designing new DSL's,
spending hours on theory of computation proofs and decidability, implementing
the viterbi algorithm for a speech recognition system and other wondrous
dynamic programming problems, binary and stereo vision, distributed/parallel
computing, and the list goes on...

it has all built on the foundations we laid in the first few courses. had i
skipped those parts, my solutions would have been less elegant and less
correct, if i'd even been able to understand the problems well enough to solve
them. and it also has the unanticipated side-effect of my having an intimate
understanding of the beauty of the chain of ideas that has led us to this
point in technology.

of course i'm hoping that all this work results in less loathsome cruft. i
look at code i'd written from 5 years ago and shudder. some of it was quite
clever but, on the whole, also quite naive.

ok, so i wasn't as brief as i'd intended to be. the main point is: you can
have a great career as a self-taught programmer. i did previously. if you
really love cs material, why not study it formally? if you have the
opportunity to go back to school and do it, even if you're older or even if
you have to do it part time, it will be extremely rewarding. and if it
advances your personal "state of the art" and contributes to your passion,
chances are it won't be a waste of time.

of course there is an opportunity cost...the money you won't be making when
you're in school and the nagging thought that "what if you were on the path to
building the next tech revolution and you veered far in another direction to
go back to school". i'm afraid my opinion is totally useless here. for going
back to school was life-changing to me in many ways beyond cs knowledge. there
is much virtue in living a simple existence continually engaged in the pursuit
of knowledge. maybe it's just my personality, but i'd say "veer away".

...

edit: i'd just like to add that i'm not trying to insult self-taught
programmers here by any means. at the end of the day, i wholly believe that it
all comes down to deliverables.

i mainly wrote this to communicate my own experiences when i asked myself a
question similar to the original topic of the thread.

~~~
greenlblue
_so other activities (non-chronologically) were things like writing operating
system components, replacing parts of the java collections framework with
probabilistic data structures or building our own red/black trees, designing
chips, writing an embedded system or microkernel, creating
oCaml/scheme/haskell parsers and REPL's, building C++ as stroustrup first did
(by doing lots of plumbing with void pointers in c), designing new DSL's,
spending hours on theory of computation proofs and decidability, implementing
the viterbi algorithm for a speech recognition system and other wondrous
dynamic programming problems, binary and stereo vision, distributed/parallel
computing, and the list goes on..._

All that can be found in good books and without a blabbering blowhard in front
of a blackboard.

~~~
kamechan
yes, this is true. after all, we use books.

that said, there is much value in having a structured set of challenging
assignments with strict deadlines (presumably with some end goal) created by
an engaging and knowledgable professor serving as one's guide.

finding the books is relatively easy: dig through the course materials of a
respected school. i used to have quite a few of them on my bookshelf.

getting the most out of them, on the other hand, meaning both plumbing the
depths of their granularity as well as casting that knowledge back into the
framework of a coherent discipline, is something i'd argue is better done in
school.

~~~
mkramlich
> created by an engaging and knowledgable professor serving as one's guide.

Very often, an impersonable and overworked grad student from a foreign country
with poor English pronunciation, making it harder to understand what they're
saying. But sure, in an ideal world, your CS teacher is the equivalent of a
Feynman or Sagan, sure. That would be awesome, agreed. ;)

------
kenjackson
Ship code. Most developers get that CS isn't programming. Programming is much
more of a vocational skill, w/o the negative connotations that go along with
it. It's really a lot more dependent on what's hot right now and a lot less
concerned about first principles.

Your average computer scientist doesn't really care about refactoring, or
design patterns, or dependency management (unless you happen to research that
field -- and notice that everything I listed is in the software engineering
subdiscipline -- pretty much every other subdiscipline in CS is completley
uninterested in the programming flavors of the month).

For most professional dev shops knowing a particular technology well (patterns
and such included) is more important than being well versed on most aspects of
computer science (whether theory, algorithms, ai, programming languages,
architecture, compilers, discrete math, etc...).

So learn something well enough that you can ship/deploy/launch a good product
based on it, and do it.

~~~
mkramlich
yep I see real world programming as mostly a superset of so-called CS. Or say
they are two overlapping circles, and the circle representing programming is
much bigger than CS, and includes a lot of non-sexy and soft squishie stuff
like dealing with users, dealing with managers, clients, your own personality
and learning styles, work flow, best practices, tools, etc.

------
philwelch
Turns out, it's the same as the best way for a CS major to obtain credibility
as a programmer. All you have to do is major in CS to know how much
variability in talent there is among CS majors.

------
loginx
The best way would probably be to expose your work by contributing to open-
source projects. You can either start your own project if you have an idea of
something that could be useful to others, or join an existing project.

------
wccrawford
Program. Anything.

~~~
jbellis
Better: contribute to something open source so people can (a) see your work
and (b) see that you can work with someone else's codebase, which is harder
than just dealing with your own.

------
gsivil
I would guess(not all of them necessary of course):

\- Build something good enough to be proud to put it online

\- Maintain a technical blog

\- Get a job in a small software company and use this as a step and a
credibility-maker, after that you will be part of the CS-certified folks by
official experience

\- Do not think much about not majoring in CS

Good luck

------
mansr
The best programmers I know have EE degrees. Just saying...

~~~
mkramlich
The very best programmers I've known personally have, mostly, had no college
degrees, or, a degree in something other than CS or EE. But EE does seem to
attract a higher average intellectual caliber than CS programs do, so that may
explain what you've experienced. I know a lot of kids enter CS undergrad
programs with the hope of making "easy money" as a Blub Developer later on,
with many of them finding they hate it and dropping out before the end. You
don't see that anywhere as much with EE.

Also, I think there's this weird effect with degrees where if you're bad or
mediocre but you have say a CS degree, you're more likely to stay working in
the field than if you had no CS degree or no degree at all. Because if you
suck, and you have no degree, there will be so little demand for you you'll
have trouble staying continually employed. But by having a degree, especially
in CS, you gain an edge and can get past more hiring and big corp HR-ocratic
hurdles than you otherwise could.

This last bit is just a theory, I could be wrong about it as a contributing
force. But I'm confident in the first part of what I said, where I've seen a
disproportionate of the best without CS degrees, or without any at all.

Lastly, I know many guys who started programming as a kid and a common issue
for them is you'd get to 18 and have to pick a undergraduate program, but much
of CS, especially early stuff looked lame and child's play, whereas many other
fields were equally or more interesting and the chance of getting to play with
those other toys, and interact with those other professors, was way more
attractive.

------
epo
Write good code. Let people (whose opinion will confer credibility) see it.

------
bialecki
Attention to detail. Do the little things well and be consistent. Just
remember, talk is cheap, build stuff.

Also, keep learning. There's always more to learn.

This coming from a guy who was a Physics major, took a few beginning CS
classes in college, and then just jumped in. If you want to be good, you'll
get there.

------
mkramlich
I think the question suggests the obvious and rather simple and effective
answer: by programming. Make software. Get it out there. Learn more. Get
better. Repeat.

------
protomyth
You can do the modern "hey I can do this!" by getting a program you wrote onto
an app store (confirmation provided by good ratings and sales).

------
durbin
make something.

preferably something you can send people a url for or something you open
source on github.

------
SkyMarshal
Read the best books. OP already referenced SICP and TAOCP, so it sounds like
he's on the right track.

~~~
ashconnor
Nobody reads the TAOCP, at least cover to cover.

~~~
SkyMarshal
Certainly not, but the fact that the OP is aware of it means he's on the right
track.

Of course, someone asking this particular question will find TAOCP way the
hell over his head, as I can attest.

But the fact that he shows a tendency even at this early stage to dig down to
the fundamental underlying knowledge of the field, instead of simply being
satisfied with Visual Blub.NET, shows he's on the right track.

I'd wager he'll eventually read and reread most of what are considered the
best books in the field, and become an above-average developer at worst.

------
sp4rki
1) Github 2) Ship code 3) Blog about code

