Many of the coders I know (which is mostly folk in their 40s) never learned from scratch. More often, we started in support roles, and slowly worked into the code. First, learning to read it to help troubleshoot issue, then making basic changes, and slowly picking up more and more of a specific codebase. Once the basics were understood, we'd start making basic apps on our own, often while still supporting more complex apps. After a year or two, we'd be competent enough to do things from scratch, and then we'd move into a full-time coding role.
I know that few people learn like this these days. I've heard extreme negative criticism when I tell people that a few years of 2nd/3rd tier support on a large codebase is actually a good start to a coding career.
But I also never experienced the troubles described in this article. There were hard times, which would have been eased with today's online content. But it wasn't hard because of a downturn in confidence, and resulting "despair" that is described - it was a slow, but steady increase in confidence and abilities.
So are people better off today? Maybe. They certainly are coding at younger ages... but I have no complaints about my path. I still was fully competent in my early 20s, did a startup at 26, etc.
So there are many paths to developing your career. I'd recommend people keep an open mind to all options, and do what works for them personally.
My first job was Night Operator at Transdata, a dial-up timesharing company in Phoenix, for the summer of 1969, earning $2/hour.
The fun part was that they turned off the timesharing service at night - but they didn't want to power down the Sigma 5 for fear that it might not start back up in the morning. There were occasional overnight batch jobs to run, but mostly I didn't have much to do.
I already knew BASIC, having punched programs on paper tape in high school to run on Transdata's service (which was how we got acquainted). I found a copy of the Algol-60 report at the office and thought it looked interesting, so I read it, tried out a bunch of programs, and learned Algol.
Then I found an assembly language and opcode reference for the Sigma 5, which was fascinating. There were plenty of blank cards to punch, so I learned machine language too.
I could have just sat back and done the night operator job and not much else, but man, there were such interesting things to fill in the rest of that time. And it's stayed interesting ever since.
Of course that was an unusual situation, and I suppose not one you could repeat now. After all, how often do you get a chance to have a whole computer all to yourself?
I was 8 years old in 1970. My dad was working for NCR in Waltham, Mass. He'd bring home a honkin' huge teletype and an acoustic coupler on the weekends. I taught myself BASIC and got hooked on Hamurabi [0], my first computer game vice.
How much paper did all of us go through back then?
Do you remember the first time you saw one of those newfangled "glass teletypes"? A terminal that printed out your typing and the mainframe's reply on a CRT instead of paper?
Was your first thought anything like mine: "How do I look back at what I was working on a few minutes ago? There's no roll of paper piled up behind the machine! How do I see my printouts?"
Yes, I used a video display terminal for the first time in a computer lab full of strange gear at MIT 40 years ago. The computer had to have its initial boot loader loaded from a strip of perforated paper tape. The terminal had characters "drawn" by the crt tube's electron beam. If there were a lot of characters on the screen the first few lines would start to fade before the e-beam was able to back to the top of the screen. By keeping the overhead room lights off, we could see almost a full 24 lines of 40 character. It seemed so advanced compared to the punch cards that I'd used for years before. Those were the days!
You know, I honestly can't recall my first glass teletype. I'm younger than you are so maybe it seemed like a natural evolution at the time.
I left the computer world in the late 70s when I discovered girls, music and partying. I came back to it the 80s when I learned about networked computers. Even through all of the intervening years, my coding still sucks. ; )
I was decent enough to implement basic algorithms and data-structures since high-school. I couldn't build apps of course.
Then in the first year of college I got hired for a small and shitty company doing web development, on a very low salary. My first project was to clone a popular dating website (Match.com). For me the project was overwhelming, as I knew nothing about what it meant to do real things. But I felt the pressure of delivering and I really needed the job, so my path from a near zero to somebody hirable took one month, because that was the deadline for showing something working.
So basically for me the driving force was hunger - and I'm talking about both the attraction towards CS and the need for an income.
Of course, from there to somebody that can call himself a decent software developer, well, that took another 12 years. And the kind of projects you're working on matters a lot. At some point I worked for a startup that had crazy technical challenges, crazy constraints, crazy deadlines, crazy everything. For 3 years I worked on that and learned much more than I learned in the other 9 years.
I was lucky enough to fiddle with computers as a kid, so I kind of knew what I wanted to do, so I had years and years of "play time" in which I gently and accidentally introduced myself into programming, databases, operating systems, hardware, the web, etc. Often, things that I never thought would be useful turned out to be down the road. I also learned to be more fearless when experimenting and understanding a system - versus it takes some people years to get out of the "afraid to break things" mindset into the mindset of experimentation, trying things out, prototyping, poking things to understand them.
I think these are things that the sausage factory modality of education can't really provide, and working in the field will definitely give you this kind of thing too.
But the issue I see often is that the self taught or "graduated" (whatever that means) from support folks aren't taken as seriously as a person with a BsC in CS from a "legitimate" engineering school.
I /did/ get a formal degree, and it taught me tons (won't comment on the whole is it necessary thing) but I think it would have been way harder for me to get a programming job otherwise even though I probably had adequate skills for an entry level job in many places.
I don't think in many places today that someone would consider training a support person to do engineering, for various good and bad reasons, and we need to think hard about providing more long term learning-through-doing and on the job apprenticeships that other craftspeople do.
I'm 37 and my first programming job after college was doing support & custom integrations for a larger product (which I wasn't allowed to change). I'd already been programming since 8 and knew BASIC, Pascal, C, C++, sh, Perl, Java, etc., but I had only taken a few CS classes and majored in English. It was a great chance to learn new things, e.g. SQL, and there was a ton of variety, autonomy, responsibility, and client interaction. Even the bad parts (Excel files, CORBA over firewalls, backwards intransigent IT departments) were great learning experiences. After maybe a year, having proven myself, I switched over to the web development wing of the company.
Amazing that there was a time that English majors could get hired for programming jobs. Nowadays your resume would be rejected by an ATS without ever passing before human eyes. You would be treated as a non-entity, incapable of offering any value.
That's pretty much exactly my recommended approach for both training people who are new to software development and bringing an experienced developer onto an existing codebase (or language, or platform, etc) they haven't worked with before. The only difference, per individual, is how long they need to spend at each level before moving on to the next.
When you get into real-world software development, it's much easier to work with an existing codebase than to start from scratch on a new one. If the application is in production, then you know that the existing code works, so you've got a baseline. You can study it to figure out how it works, and you can compare that to requested changes in the way it should work, and then you just need to figure out how to change the code to make the behavior change. That leads you to asking the right questions, focusing on the right code. It's like the hand-holding phase, except it's real code instead of play code. Figuring out how the code works also teaches you a bunch of stuff on the side, like how to do debugging in this new codebase, how to set up and work within your development environment, the practices and patterns of your team, etc.
this is good to read. i am 7 months into a trainee developer role. the first 6 months were spent working on other peoples code and it was brilliant once they dropped me onto my first project, i didnt realise how much i was learning at the time.
did you have people readily available to ask questions to and get correct answers? it makes all the difference if you have somebody to guide you through periods of being stuck.
I know that few people learn like this these days. I've heard extreme negative criticism when I tell people that a few years of 2nd/3rd tier support on a large codebase is actually a good start to a coding career.
But I also never experienced the troubles described in this article. There were hard times, which would have been eased with today's online content. But it wasn't hard because of a downturn in confidence, and resulting "despair" that is described - it was a slow, but steady increase in confidence and abilities.
So are people better off today? Maybe. They certainly are coding at younger ages... but I have no complaints about my path. I still was fully competent in my early 20s, did a startup at 26, etc.
So there are many paths to developing your career. I'd recommend people keep an open mind to all options, and do what works for them personally.