Hi. I am interested in getting a job as a computer programmer, however I don’t know the best way to go about it. You can possibly do very good at it while being completely self taught, but I don’t know how if you can outcompete people who have been professionally schooled. Or maybe you pay for all the schooling to find that you didn’t have to pay for that because you can do just as well or better on your own. So, which is better?.. which do companies prefer, if any? Thank you.
One data point:
My last job was for an e-commerce company. We were lousy with IT folk. I was a self-taught SQL guy, in addition to my primary duties.
The conventional wisdom in that company was that “results” really wasn’t enough.
The thing about training was that you had consistency in the product. If programmer #1 dropped dead, programmer #2 could step in and continue where the first person left off.
Every programmer has their own (often, readily recognizable) “style,” but one thing the training does IS to ensure a sort of stability and consistency that – as I was always reminded – mattered kind of a lot.
I had friends who were self-taught programmers. They rarely got good gigs with “good” companies, but were reliably kept busy by ‘brokers’ (who managed a stable of contract IT people and got them gigs) or by finding small business clients on their own.
It doesn’t matter how good you are. It matters how good you can convince the hiring manager you are. Even if you’re a self-taught absolute genius, how do you convince HR of that? Certifications and degrees and the like are easy to put on a resume.
-
Talent plus training is the best.
-
No talent with training may get jobs easier than talent with no training. But they won’t last in the good jobs. Talent will learn on the job and quickly get better enough to last and to compete for later good / better jobs.
-
No talent plus no training will waste a lot of time piddling with teach-yourself websites then still fail to get a job and end up at McDonalds. Or be utterly Peter Principled while slowly building an empire of obsolete unmaintainable spaghetti code at a small and clueless company with a one-person IT presence.
It also depends a lot on how old the worker is and what non-IT experiences they bring to the table. IT is a young person’s game and age discrimination against doddering 40yos is rampant.
My son-in-law left a major textbook publisher and signed up for a coding course. He then got a job with a small software company that eventually got taken over by Amazon for whom he is currently working quite happily.
On the other side my son was entirely self-taught, although he did eventually study CS in college. But he doesn’t feel that anything he learned in CS made any difference. He has written a book about his experiences that should have been called Why Software Sucks, but is actually called The Troubled with Software that analyzes why academic CS is useless for programmers. But I don’t know if companies are hiring self-taught programmers any more.
I had this discussion with my boss when we were hiring programmers (OK, about 25 years ago). The consensus seemed to be a year of school was about (!!) equal to two years of real life experience. Take SQL or database theory - you can figure it out as you go along, try self taught courses, read books - but being forced to actually do exercises in a variety of different time-limited scenarios was perhaps a deeper exercise of the knowledge. And the purpose of a course was to get you to try many different ways of doing things. Plus, what is “experience”? We had programmers who did nothing but payroll for 10 years. They could tell you exactly what each subroutine did and the likely cause of an error just from the message - but a lot of other stuff like scientific databases (sampel analysis), or accounting, etc. - they might be lost. When i took a IT degree, we did math, accounting, number theory… other than accounting, the most math I did was some statistical output. Every IT person should have Accounting 101 because odds are they’ll do some work on accounting systems.
It all depends on what you mean by being self taught. How much code did you write? Anyone can write exercises from an online course, but the trick is writing code that is robust enough to stand up to the inevitable changes. How are your data structures? I only appreciated them after I taught it, and thinking deeply about them truly helped my code.
Was there an opportunity for someone to look at the code and say “this sucks, and here is why?”
When we taught assembler we had a first assignment that was specifically designed to let us hammer the kids’ code. (They all had an intro class.) We tossed out the grade, but we wanted to scare them before letting them loose on assembly language. It worked pretty well. This was back when “structured programming” was a new and fairly controversial topic.
What does he consider academic CS? I suppose that studying the complexity of algorithms isn’t that useful if you are going to be working on accounting software. But a quite academic concept I learned in 1972 came in handy for a real problem in 2010. You never know.
\Engage grizzled greybeard mode.
Software is such a wide ranging subject that it is useless to make generalisations. I am becoming more of the opinion that for the majority of people in the game it is becoming a trade. This isn’t a bad thing. Back when I started things like Object Oriented paradigms were still a matter of great interest and discussion. Smalltalk 80 was freshly minted and OOPSLA attracted delegates in their thousands. It was an exciting time and research was similarly exciting.
But it was a very small crowd compared to now.
There is such a wide variety of things that need coding, from embedded real time control up to web stores. Employment ranges from single person business to companies with tens of thousands of employees. Code bases can vary from hundred line scripts to multi million line behemoths. Languages from assembly, C, to horrors like JavaScript and Perl, newish languages like Rust or Python, to whatever the cool kids are using this month. Developing ecosystems range from an ad-hoc bunch of files with cryptic names to large scale managed repositories with a dedicated team whose only job is curating the build process.
A large fraction of my career has required at least undergraduate mathematics in order to write the code needed. That sort of thing isn’t going to go away. But a huge number of coders spend their lives doing different kinds of work.
Having done my time teaching as well I have mixed feelings about the value of a formal tertiary education for coding. If you want to be a real software engineer, you need the background to at least be any sort of engineer. There is an ethos that comes with that that transcends the specific area of expertise. A good university course teaches stuff that doesn’t go out of date. The fundamentals if you will. Coding skill is a byproduct. Someone who has the theoretical framework of discrete mathematics, linear algebra, automata theory, numerical analysis, a smattering of signals, language design basics, and has learned proper software engineering is set for life. They should be able to pick up any of the new tools and ideas without trouble. Experience counts. Good mentoring and learning the ropes in a good job environment makes a huge difference. Building on the basics to fill out a well rounded capacity.
But a degree mill churning out cookie cutter coding cannon fodder leaves everyone worse off. And there is no shortage of cynical businesses with their snouts in the trough ready to sell you the dream.
Perhaps the bottom line is that I don’t regard the act of cutting coding as the core skill. It is what wraps that and turns it into engineering that matters. Some of that directs how code is written, but looking outwards to the environment and processes rather than inward makes the difference
\Disengage grumpy bastard mode.
yes, ha ha - I joked during my career that I learned untold amounts of fancy math theory, calculus and algebra galore, N-complete and the ahlting problem, NlogN algorithms, then in my working life the most complex things we programmed involved taking percentages. My favourite code critique was the fellow who needed to take a square root as part of a process control, and calculated a linear answer instead. (To be fair, the range of numbers he was working with, it would be usually within 20% which for a 6502-level Process Control unit was fast anf “good enough”.
Yes, you are typically automating someone else’s complex job. (Not necessarily replacing them, but streamlining the process to make them more efficient). This requires an ability to understand a variety of technical work and exactly what is needed with it.
My education goes back to the days on bubble sorts, binary sorts, and the algorithm speeds involved… Which on an 8088 computer, mattered. The mainframe, you just called “SORT”. It also helps to have a serious understanding of self-balancing trees, depth-first searches, index files, and all other type of processes even if you will never actually program them yourself after that course is over. But it also gives you an inspiration sometimes when an unusual task comes along.
I was lucky to work in a smaller company where I got to do everything, from mainframe business programs to setting up PC servers. We’d joke that in a giant corporation like a bank, someone may spend 15 years doing nothing but payroll or account updates.
Which of course begs us to quote Dilbert -
Secretary: “My son is flunking all his courses. I was hoping he could get a job in computers instead.”
Dilbert: “Doing what? Stealing them?”
You’re not wrong. As someone with a computer science degree, I’m often reminded of that line in Starship Troopers (the book), where Sgt. Zim tells Rico’s recruit class that there aren’t dangerous weapons, only dangerous men.
The reason it reminds me is because what I got out of college was how to program in a broad sense. How to structure things, how to decompose problems, how to choose the best algorithm, why documentation is so important, and so forth.
The language I (or any other well trained programmer) would use to do so is trivial - that’s the difference between a soldier using a rifle, a machine gun, a pistol, or even a knife. It’s his training that makes those things both the right tool for the job at hand, and extremely deadly. Same thing for having a real degree or certificate vs. being sefl-taught or having some kind of extended learning course, etc… Once you’ve got that, the languages are, while not irrelevant, not the point of being a good programmer.
Most self-taught programmers are fairly limited, in that (in my experience) they have hitched their wagon to a specific language and/or sort of coding, and can be left in the lurch when the industry pivots to something else, as their whole value proposition is that they are really good at that specific sort of programming, not that they’re a well-rounded, well trained programmer who can do it all with a minimum of retraining.
He considers as academic CS what he was taught in college. You want a more detailed answer, read his book.
Doesn’t matter which way you go, you won’t understand software looking at isolated examples of code. Real software consists of massive of amounts of code, functionally localized plus the nearly incomprehensible world of interconnected software. Nothing but experience, and the curiosity to look past the tiny project you are working on will turn you into a software engineer. But software engineering doesn’t comprise most of the jobs out there because mostly nobody cares about quality product, just something that looks like it does the job produced as quickly as possible and a promise that all the bugs will get fixed in the next version. The vast majority of the jobs are for code monkeys who will cobble together something that seems to work with insufficient testing. If for some reason you actually need engineered software you can pay experienced people to fix it all for you.
OTOH, a code monkey with some expertise in a particular field is very valuable. The job for most programmers is to convert ill defined concepts into code. Specialized expertise allows you to better define concepts for a better solution through code. To expand on that, remember this - “Code is crap”. A well defined problem and a well defined algorithm that can be represented in code has value. A software engineer can take that and turn it into quality software if someone cares to pay for that. And it won’t cost them as much as the usual approach.
Chronos addresses the most direct answer to the OP above. If HR can decide whether or not you get a job then you are looking at a low level job. Experienced and skilled programmers get jobs based on that experience and skill as recognized by someone who can actually evaluate their ability and the value they bring with them. Otherwise, all that matters is what someone in HR thinks about you. They are unlikely to be impressed by self taught skills, if for nothing else because someone declares a CS degree as a job requirement.
So interesting. That exact description applies to programmers with degrees also.
I’m just thinking that back in 2002-ish, I knew a lot of self-taught people who had to pivot into other careers because they were laid off long enough to no longer be current in their chosen language. Nobody I knew who was a college grad had to do that. I think it has to do with the way hiring is done in technology- they’re often willing to fudge a little for degreed people in ways they’re often unwilling for self-taught people.
Education (when it works) is best at teaching first principles – not how to use a specific tool, but how to understand a task in order to accomplish it with whatever tool is needed.
Therefore, a degree from a coding mill is of lower value than learning (academically, OJT, self-taught, whatever) how to study and understand a problem into an implementable design and implementing it.
Short answer: if you’re able, get the degree. Getting your foot in the door is hard and it will help.
As covered in the replies already, software is a very broad field, and you’re going to get different answers from everyone. My area is web development broadly, and government contracts more specifically. My company requires a degree because it helps us win contracts. Beyond that, we don’t much care what the degree is in or where it’s from, we’re going to make sure you know what you’re doing regardless.
Interviewing is hard in a field where everybody has imposter syndrome and also lots of people seem to be able to get and maintain jobs in software development without actually being very good at software development. We do what we can to suss out the difference but one thing we look at is, how much time are we going to spend bringing this person up to speed? At that’s something we struggle with while evaluating self-taught programmers. Hobbyists, not to use the term as a pejorative, are probably only working on things they like or that interest them. But the job itself is full of really boring stuff, and the boring stuff is what a good education is going to cover. Since all of our applicants have degrees in some sort of CS program, our interviews are basically validating that they understand what they were taught. “Did you take a class in this? Great, explain this to me.” That sort of thing. Note that this is no guarantee they’ll actually be good in practice, but it’s the best we can do.
Coding boot camps are another hot topic; they do tend to cover the boring stuff, but we as interviewers have no idea if the applicant actually retained any of the information that was thrown at them. That’s a problem with conventional degrees as well, but we’re all a little more skeptical of boot camp grads because there’s insufficient validation at the end.
FWIW, I started out in a computer engineering program and it wasn’t for me. I then got a CS degree, and while I learned some really good stuff I had a lot of classmates who were just kind of shuffled through class after class and never really understood what they were being taught. That’s why people say a degree doesn’t really matter. But I’ve at least seen the actual engineering side of this profession, and as a result I really hate being called a software engineer. I’m a tradesman like mentioned above, no different from a mechanic. I solve problems and fix things using a bunch of tools I’ve added to my toolbox over the last 20 years. Don’t ask me to write mission critical software, though, in the same way that you wouldn’t ask a welder to certify a bridge.
I have been in the industry for 30+ years, running the same company for 25 years.
I dropped out of university after majoring in Biology and then a pivot to Political Science, so no CompSci courses at the university level. I had the advantage of a) starting my own business and b) being in the early 90s.
I was briefly employed for a couple of years in 96-98 and I got that job because of my skills in both programming and business analysis. No one cared then about a degree.
Since I started my current company, I have hired hundreds of people over the years. When I wanted someone with specific skills (data warehousing, SQL, or domain specific expertise) a degree was largely irrelevant. If I’m hiring a junior with no or little track record, a degree is table stakes.
Of course, back in the dark ages, there was a lot that was not covered in theoretical computer science. Cleaning data input (like avoiding "little Bobby Drop Tables ") was unnecessary when all data went through keypunch operators, and even screen input user interface (CICS and then PC’s) was something too pedestrian, you figured it out on your own
Yes, you could talk to people and see some actually seemed to grasp the big picture of what they were doing, and some didn’t. They were just following formulas. When most programming involved things like adding changes into a sorted file, or generating reports, it was pretty trivial.
I’m reminded of the discovery that they’d been paying statutory holidays wrong for 10 years and nobody noticed, because the formula was so obscure nobody could tell. It was the average amount of the days worked in the last 30 days. The program worked fine for Monday holidays, but forgot to include any days of the current week if the holiday was later in the week. It still used only the previous 4 weeks and 2 days. The programmer ran across this and fixed it, and nobody else outside IT ever knew.
.
The other problem, which we discussed years ago when I was working in that mainframe environment, was particularly this. The place had a payroll (and accounting, and order and warehouse) that used sequential files on tape. As tech advanced, the tapes became disk files one by one to minimize tape changes - eventually entirely, except backups. Then the sequential files were made into database tables. Etc. But when Y2K was looming, the fix for 2 digits was immense - so they switched to purchased software. Our job was far less “write a program” and more “take this product and set the parameters so it fits our needs”. Software is more and more written in some cloud out in Silicon Valley and just purchased. With PC’s, even more so. Even now, more and more websites are simply “fill in the blanks” on an existing program.
Since this is more opinion and advice than factual, let’s move this to IMHO (from FQ).
I started and ran an ISV for about a decade in the era between the web bursting on the scene and cloud computing taking over so much of on-prem ops. So sorta modern but well short of contemporary. We built server-side web apps for a government / enterprise vertical.
This snip totally echoes what I learned at that time. @FinsToTheLeft has far more experience in the industry than I do / did. And his is apparently up to the minute as well. Unlike mine.
A dev that’s expected to churn out usable testable reliable code, even for basic business automation, 40 hours a week doesn’t come from a boot camp or from self-taught. There’s just too much learn-by-doing that they haven’t done yet and that I don’t have time or spare cash to pay for them to bricolage their way to a good-enough solution. With very rare exceptions.
Back in the day there were no end of small businesses built on totally manual procedures looking to “computerize” their business. Many self-taught devs found there first job there tinkering alone amongst the beleaguered clerks and clueless owners. Some of those devs never moved beyond that one job, becoming ingrown with and therefore indispensable to that one business. Others graduated to larger businesses leaving the horror of their self-taught mess behind for another generation of the marginally qualified to try to understand, maintain, and extend.
I don’t really know what corresponding low-barrier-to-entry jobs might be out there nowadays that aren’t already occupied by overseas devs working for $5/day.