Hacker News Reader

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?

[0] http://en.wikipedia.org/wiki/Hamurabi

A lot of paper!

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. ; )

My path was different.

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.

This. I so agree with this.

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.

If it wasn't clear - I'm for people moving from support to dev, just acknowledging that it's more difficult than the traditional route currently.

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.

Well, I'm not sure it was so different then. In my case there's a pretty good story behind it. I was working as a temp doing data entry for 1000+ page industrial catalogs, and then we ran a Perl script to generate QuarkXPress files while sizing/moving products within the 3-column layout to cut down on pages. It was sort of a killer feature for the monstrous CMS app they made, and we were the pilot project. But this was 2000 and there were lots of Unicode bugs around © ® ™ ” etc. Since almost every product had a table with 10ish SKUs and 2-6 columns of various dimensions measured in inches, there were a lot of problems---I'd say hundreds per page. Oh and also the script added extra spaces around every special character. We temps were kept around longer than expected so we could circle in red every bad character on every page of the catalog. That was bad enough that I started poking around, saw the app was in Perl, and tracked down the problem (a single regex). When I told my boss I could fix it, he asked me to write up a proposal, which I did, and they asked the original developer if it looked okay. So that's how I got the services job. :-)

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 exactly how I learned. I wasn't fully competent until my mid 20s, but there are many ways to skin a cat.

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.