6 ms·
What is the best way for a non-CS major to obtain credibility as a programmer?
- wccrawford 16y agoProgram. Anything.
- jbellis 16y agoBetter: 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.
- loginx 16y agoThe 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.
- gsivil 16y agoI 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
- epo 16y agoWrite good code. Let people (whose opinion will confer credibility) see it.
- mansr 16y agoThe best programmers I know have EE degrees. Just saying...
- gaius 16y agoIndeed. Perhaps a better question would be, how can a fresh CS grad convince a team of experienced software engineers he's not hopelessly theoretical...
- protomyth 16y agoI keep running into Music majors that are very good programmer.
- mkramlich 16y agoThe 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.
- durbin 16y agomake something. preferably something you can send people a url for or something you open source on github.
- SkyMarshal 16y agoRead the best books. OP already referenced SICP and TAOCP, so it sounds like he's on the right track.
- ashconnor 16y agoNobody reads the TAOCP, at least cover to cover.
- mkramlich 16y agoIf I have the choice between reading TAOCP cover-to-cover or building a software-based startup which I can later sell for millions of dollars, I know which I'd choose. And have chosen. And I'm confident you can do the latter without doing the former.
- SkyMarshal 16y agoCertainly 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.
- philwelch 16y agoTurns 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.
- protomyth 16y agoYou 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).
- kenjackson 16y agoShip 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 16y agoyep 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.
- deleted 16y ago[deleted]
- deleted 16y ago[deleted]
- bialecki 16y agoAttention 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.
- kamechan 16y agoi 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.
- sp4rki 16y ago1) Github 2) Ship code 3) Blog about code
- mkramlich 16y agoI 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.