Where I started might not be useful to you
rachelbythebay.com
rachelbythebay.com
And I hate my answer, especially when the employee is around my age or older: I first installed Slackware from floppy disks when I was about 12 years old. I installed it because I heard that Linux had a great C compiler, and I was getting tired of the Power-C compiler that I'd been using for 2 years.
Like Rachel, I started on a Vic-20, around age 8. The computer was at my dad's house though, and I lived with my mom most of the week, so I would take out books from the library, write all of my code on loose leaf, and then fast & furiously type it in when I got over to dad's house to see if it worked. POKE 36879 indeed.
When Stack Overflow and Google do not help, you start doing it yourself. You use tools like a debugger. If the tools do not help, you can look for other tools. If you cannot find them, you can develop your own. You can look at your code, the code of your operating system, and every library you use. You can trace and observe every instruction a CPU performs.
In my experience there are only two ways to really learn about programming: teaching and debugging.
I'll add curiosity to stubbornness too. I very much have to understand how a system is actually working before I'm willing to call it quits and call something successfully debugged. I've definitely worked with folks in the past who don't have that drive; they're more concerned about making it work than understanding why it does/doesn't work. My revelation last night was "deep in this (internal) library, a URL is being manipulated using a badly conceived regex, and that's why this URL is getting mangled".
The curiosity to understand it on a deep level pretty much defined my academic career too. I'd already been programming (in some capacity) for about a decade by time I turned 18 and finished high school. Computer Science was a pretty obvious career path. But I ended up doing an EE/CS dual major, entirely because I wanted to understand the pieces below software as well. A few years after undergrad, I realized that a lot of people struggled to debug complex "cloud" systems, and went back to do an M.Sc. to study the problem more carefully.
(And, per cup-of-tea's comment, I spent a fair bit of time during my M.Sc. teaching as well, including taking on a Spring & Summer session 200-level CS course as a sessional lecturer)
Where do I sign? When I get really stuck on a bug it's sometimes taken weeks to solve in a never ending game of software dominoes. In very rare cases it ended up being a bug that you could only solve with a soldering iron and some creative rewiring of interrupts.
Bugs can be crazily obscured. To the point where you wish you hadn't started but the sunk cost of time invested is such that there is no way back either. This is one of the reasons I was so happy to switch to Unix (and later Linux), the fact that in most cases the program crashes with a core file and access to post mortem debugging (and in many cases a nice stacktrace of how you got there) made short work of most of the bugs. Of course that means you now only have the hardest categories to deal with.
"All causes shall give way. I am in code
Stepped in so far that, should I wade no more,
Returning were as tedious as go o'er."
My substitute is to externalize my brain: Write things down. Journaling. Blogging.
Debuggers are still useful but I don't actually recall the last time when I hit a bug that required interactive debugging.
Microcontrollers: As a side rant, I'm perpetually grouchy with the fact that Arduinos don't have debugger support. I was using AVRs well before the Arduino was a thing (still have my STK500 kicking around...) and I feel like it's a pretty big lost opportunity for hobbyists to not be able to do a deep dive into what is actually going on for when they want to "level up" their MCU skills. Printfs over serial are great, but they often dork with the timing enough to change the character of bugs; JTAG debugging does too, but you can often insert breakpoints with surgical precision to see what's happening without breaking the timing of what you're trying to debug.
One thing that's been fascinating me this past decade or so is that clearly programming and lots of other 'nerdy' stuff is quite mainstream now, and as a result the 'old-fashioned' concept of a hacker (or the 'hacker ethos' or whatever) seems to have become less of a specific subculture.
But at the same time, I've been trying to do some 'code school' style teaching and I find that there's still a very distinct difference between the coders who mostly just want a job and see coding as a viable path (and even enjoy it, much of the time), and coders who have that same kind of 'hacker' mentality.
It's hard to describe, because it's not just about skill or 'good code' or 'productive results'. I guess it's some degree of unusual passion or excitement about the whole thing. And definitely a tendency to just 'hack it' and coming up with sometimes horrifyingly creative solutions to the problem.
For example, one guy I was teaching was incredibly messy in his code style, undisciplined, and clearly copy/pasting stuff from Stack Overflow on occasion. But when we talked about computers, programming, what kind of cool stuff he'd like to build, he was clearly different from the others. Where the others would sometimes diligently go through the Rails Tutorial chapter by chapter, with him sometimes the only thing that got him to actually learn was to give him something that 1) tickled his particular passions (games), and 2) was problematic enough that he'd be cursing at his computer until well after the 'official' study time.
And while his solution rather predictably was often messy, different from what he'd been taught, and somewhat unconventional, he usually figured it out and there was almost always some 'cleverness' to it.
In case you haven't seen them, the SysInternals tools can serve as an interesting middle ground before popping the DLLs into an assembler. There's one (whose name escapes me) that is basically strace-for-Windows, and I've used it to successfully solve some pretty gnarly Win32 problems before.
I mentioned elsewhere in this thread that I did an EE/CS dual degree after having programmed for a long time beforehand. I really don't understand why, but some of the EE-only software I've worked with has been absolutely atrocious.
One of my favourite moments in undergrad was in my Digital Communications class. I don't remember exactly what we were doing, but it involved Matlab and some kind of signal decoding. I handed in my assignment and got called in to have a one-on-one with the professor; he was certain that I had cheated and just hard-coded the answers to my assignment instead of actually writing the decoder. Why? Because my code ran instantaneously instead of sitting and grinding for 30+ seconds. What was my secret? I'd seen a couple of triply-nested for loops in the code and decided they could all be accomplished with a matrix multiply instead of doing all of that computation by hand.
In the same class, a friend (also an EE/CS dual) and I came up with the dynamic programming solution to the Viterbi decoding problem as well, and again, got taken to task for having a solution that ran too fast. Sigh...
Be warned that FANUC is very litigious about that sort of thing. I can't go into specifics, but they've sued companies out of existence for less.
1. Youthful trial and error is really powerful. I had access to a 286 during my formative years, along with the manual for DOS 4.0. I sat down with that manual and typed in every command to see what it did, until I got to one (I think it was RECOVER?) that overwrote all 30 Mb of the hard drive with garbage files. Then I had to learn how to install an OS. After that, I stopped entering random commands, but fortunately I'd already discovered BASICA and EDLIN.
2. Being able to hold a program in your brain and write it down in a notebook is a huge advantage. I've done all of my best work with pen and paper.
I basically followed the same path you did. Once you have to wipe and reinstall you have gotten to a comfortable level with your systems and tend not to fear making mistakes.
I've got this feeling that we have neural pathways built for typing and, subconsciously, we favor phrases, words, and sentences that are easy to type. I know I even have a tic where if I pause to think I'll insert extraneous commas.
It's kind of like how musicians tend to improvise around licks and scales that they have practiced a lot. There's something to thinking about the idea of a song on paper that is more creative than unintentionally falling back on chords/forms that are easy to play. (Adam Neely discusses this very well here: https://www.youtube.com/watch?v=6c_LeIXrzAk)
I have horrible handwriting and am a VERY slow writer (and my hand gets cramped after writing a few words). I know whenever I have to write something by hand, I tend to choose small words and short sentences. On the other hand, I am a very fast typist and can type faster than I can think in most cases, so I tend to be much more verbose.
Yes, the medium we use matters.
I can definitely type faster than I think, though. So my hands always end up in this kind fo wait() loop while my brain processes. Sometimes, I look back at my previous sentences and realized that my hands kept going for a while before by brain even bothered to stop them. I guess I don't have that problem as much with pens.
Shortly after I took out the 20Mb HDD on my dad's work pc with RECOVER he bought me my own little home computer to wreck instead :)
This is what the previous generation pondered:
I sometimes wonder if growing up before pre-built computers and lots of books about computers was actually a boon for my problem solving skills. I spent so many hours with nothing to go on but some schematics and my own persistent trial-and-error. If I'd done the same stuff these days I don't think I'd have learned half as much (although would I have done more, different things? Probably...)
We all work within a context of abstractions, and in any given generation, poking and prodding at those abstractions and trying to understand what happens below it is immensely valuable and instructive. For one generation, below it might mean pen and pencil, and for the other it might mean looking into what jQuery actually does.
Let's not forget that 'pen and pencil' was once upon a time an abstraction inaccessible to many too!
I guess what I'm saying is that the determined problem-solving mentality that were required before Google/SO are still important, but its possible to learn them even with Google/SO.
It ties into one of the best things about programming / software engineering / software architecture, which is that it's a self-scaling system. Everyone eventually finds the level at which it becomes 'too hard', so it's always a challenge.
We're going to need you to time-box that fix. If you don't have a solution within a day, assign the Jira to Bob so he can take a look at it.
In my current gig, I guess I'm Bob. Whenever someone can't figure out the solution to a problem, it just gets punted over to me to figure out wtf someone did a couple of years ago that makes no sense but coincidentally worked for exactly the problem they had. /rant from last night.
“Experience: that most brutal of teachers. But you learn, my God do you learn.”
I started out on a similar computer, but once I worked my way through the basic manual that came with it, that was it. I couldn't get any more documentation until I got my hands on an XT many years later.
It was a town of 35k people, and I just happened to luck out and meet the right ones at the right time. The owner of the computer store that gave me the C compiler ended up hiring me for summers and weekends through high school, and then had me back for the first couple years of summer during univeristy too.
I started coding by reading the huge instruction manual that came with the Amstrad CPC and didn't have an issue moving on to other languages later. As long as you're willing to keep up with what's new and are passionate about improving your skills it doesn't matter what you started with.
http://www.cs.utexas.edu/users/EWD/transcriptions/EWD04xx/EW...
At least, the "mentally mutilated" phrase is about BASIC. The "criminal offence" phrase was actually about COBOL. You'll note that Dijkstra also had choice words about FORTRAN, APL, and PL/I, which were popular programming languages of the day.
It's tempting to say that Dijkstra was being tongue-in-cheek when he wrote this. I never met him, but based the attitude I picked up from his other writings, I'd guess that if you had asked him he'd have said he was completely serious.
And he has a point. I first learned programming in BASIC, and look how I turned out. (Well maybe I confirm Dijkstra's point. Others will have to judge.) But I do recall a bunch of characteristics of early BASIC systems that potentially led to terrible programming habits: GOTO and line numbers leading to spaghetti code; all global variables; no scope; no functions; self-modifying code (overlays); etc. All of these had to be unlearned at some point.
I think it was working with others and pulling apart code and shrinking it down until it does one thing and one thing alone was the most important learning experience. Dijkstra might be one of the smartest computer scientists ever but I don't think that his assessment of learning that way was correct.
Compared to just being told these things are bad and should be avoided, I'd like to think that being forced to code in the above ways makes you better rounded as you have first hand experience for why those practices are a bad idea. It's not like you have much choice if you have to code in something like assembly as well.
I've worked with programmers before who can regurgitate the names of current bad practices but can't describe the reasoning behind them which isn't a good thing.
Personally, I think it's an absurd idea that e.g. if you began coding with all global variables and no functions you'd be unable code in a different way. If you're amazing at coding in an environment that makes it challenging to write complex programs, you're going to quickly become efficient at writing code in environments that makes it easier to write complex programs.
On the other hand, sometimes other people never transcended those bad habits from BASIC. Sometimes you run across programs that are one big function, with variables reused, etc. I don't know what the thought processes are of programmers who write such code. There's an old saw, "You can write FORTRAN in any language." Maybe this should be applied to BASIC as well. That's probably what Dijkstra was driving at. I don't know about "mental mutilation" (certainly hyperbole, in my book) but only Dijkstra knows what he really meant.
The kind of people that don't actively keep up with current best practices and latest developments are always going to be bad programmers though. It's not like you can pick a perfect language to start coding in that will teach you all the current and future best ways to do things. I personally don't think it matters what language you start coding in as long as you're always learning and adapting.
I started with computers in 3rd grade, logo. It was enthralling. I was enamoured with computers right away. I learned you could stop some Apple games and view the code. I learned you could even print it, (I had reams of printed code I didn't know what 99% of it did, what is a gosub? lol) most of this learning was by accident, as I didn't have a single book to teach me anything, and only 1 other real nerd friend who showed me how to program lowres graphics. (One friend got bootleg copies of games from his older brother though, lol. Anyone remember punching holes on the side of a floppy disk to make it store more data?)
I tried over and over to create games, and made dozens of odd text adventures and stupid space invaders games that crashed after a couple minutes of play. In highschool I found (by watching the older kids) about hacking system resources on Macs, and we'd mess with the menus, lol. Pascal was interesting, but I never learned to make anything cool with it. Finally when I got into college, I got some real coding experience, and found out you can mix art (I was a flip-book animating nut as a kid, made hundreds of them) with programming.
Eventually the web took over, and I found out you didn't have to "install" anything on someone else's machine ever again, I was hooked.
As bad as the web is in so many ways, I never want to go back to supporting other peoples computers ever, ever, ever again.
I will take JS hell over that garbage. (Imagine helping a client debug an install issue on a computer over the phone, and he's 2,000 miles away on a Carribean island living it up and blaming your for him clicking the wrong button because he simply refuses to follow your instructions "explicitly" and can't ever be wrong... ugh)
Instead, that client is using IE6, doesn't know how to tell you that, and IT restrictions prevent them from upgrading or using another browser. Or they have Chrome and a shitty addon that breaks your site in a way that you can't even imagine. Or they are behind a workplace firewall that blocks some specific domain used by the site.
I've done support for a webapp, and I've had to use remote desktop sharing quite a few times.
At least _I_ personally can do something about it, instead of grasping at straws and begging someone else to do something right on their end. If they want to use IE, fine, but they only get IE supported features and everything cost 10x as much, win-win.
>Or they have Chrome and a shitty addon that breaks your site in a way that you can't even imagine.
Dealt with this repeatedly,"sir, try Firefox, it works there? Great, use that instead, or remove the Chrome plugins."
I had a client that was in the Beta channel of chrome and had some obscure bug causing her issues, but no one else. I figured that out just fine.
Just last week a client had the stupid Grammarly plugin wreck something online, fixed in minutes.
>Or they are behind a workplace firewall that blocks some specific domain used by the site.
Say, "Call your tech support guys, I am unable to fix that." I can't say that to a guy that is holding only a CD that got mailed to him, because I am the only support then.
>I've done support for a webapp, and I've had to use remote desktop sharing quite a few times.
Yep, and in the near future this will work in the browser, we are close now. And the beauty of the internet is that if they don't have access, we don't have to debug until they do. (their ISPs/intranet problem) But in the old days, it didn't matter what the issue was, and if the computer was not online, then the only data I could get to debug from was irate staff.
You need a TCP/IP stack, HTTP server and client.
You'll need an editor & graphics tools. Sketch and Zeplin have a pretty steep learning curve. You'll probably want Webpack or Gulp.
That is, unless you're writing HTML 1.x, which gives you such exiting tags as <BLINK> and <P> and <HR>.
On the other hand, I can fire up a Commodore 64 or Atari 800 with built-in BASIC interpreter and do actual math. I can process input and interface with hardware at the lowest level. I can generate graphics (in multiple graphics modes). I could, in theory, write that same HTML 1.x code (in BASIC) with a set of routines to generate and save the very same.
Financial investment is lower, and I'd say the return on that investment comes 10X quicker than with a Mac running Sketch, Zeplin and YouTube tutorials.
That's how I got into programming professionally. One of my users said "Anyone who can write a BBS for a Vic can program!" and hired me as a programmer. Thirty-two years later, that same guy now wants me to work with him at Google.
I had a Geocities web site, and I loaded it down with JavaScript widgets that I wrote. Things to flip images around. Things to annoy you with alerts. Then I spent countless hours in MS Paint making images out of bitmaps which I then wired up using JavaScript to emulate an Iron-man watch (complete with glowing and a very bad battery!)
There was "no risk." It was fun and exploratory. It didn't achieve anything useful for anyone else, but I learned and got confident in learning (and experimenting.) When someone actually hired me and threw ColdFusion at me, it was wildly different... from QBasic and from JavaScript... but I just experimented and figured out how to do CRUDDY things.
A teacher so far ahead of his time at school had a TRS-80 that we would have lessons on. It would be at least 5 years later that I would touch another computer, a PC XT running DOS.
I learned by trial and error, before you could just google a problem and have it pop up in StackOverflow. It taught me one major lesson: debugging is how you learn about everything in the environment. A bug is an opportunity to explore the programming environment, framework etc and you'll get a grasp of the platform through searching for solutions. StackOverflow is nice for quick fixes but it doesn't give you the deep knowledge that debugging does. I recommend to my team, if they find a bug spend half a day figuring stuff out from the ground up (where we have that time luxury) and it makes everyone more knowledgable in the long term.
Those of us who started programming in that era had simple, relatively cheap, fully comprehendable computers in front of us.
> "Just about any computer you can buy today is going to have some kind of non-trivial boot time. It probably will require a whole ecosystem of crazy things to make it work. It will be fragile. You can break it easily."
I vehemently disagree with the italicized portion, at least in the way it's presented.
Those on here probably aren't affected, but many of the non-technical users I know are afraid of learning how to go beyond simple tasks on their computer (word processing, internet browsing, etc.) because they're afraid they'll break their expensive box and have to pay someone to fix it.
Most UIs today seem to help users avoid breaking things and typically have some sort of notification if they'll change something that would break their machine (e.g. UAC in Windows, padlock in OS X).
Even beyond this, general application development wouldn't pose these risks. Hardware hacking certainly could, but any time you're dealing with the physical workings of something that's an assumed risk.
There is also numerous ways you can make computers unbootable by removing files, installing the wrong thing that runs on boot and so on. I maybe wouldn't say it's fragile and can break easily, but it can, and if you just go around clicking on things, it's probably gonna break after a while.
The VIC-20, C64, Timex-Sinclair and other computers of their day had the OS in ROM that couldn't be changed. So you couldn't break these computers via the keyboard (or other peripherals) but if there was a bug somewhere in the firmware (which included the OS and BASIC) you had to live with it for the life of the device.
You can get back to those days via emulation - https://vic-20.appspot.com/emus.htm, but there's nothing (that I know of) that's a physical device with these characteristics.
Bootstrapping an 8-bit Microcomputer is so much simpler than the first order of operations in the hosted VM model.
A modern equivalent might be the Micro Bit (http://microbit.org/) - it doesn't plug into a TV but it does have a rudimentary display built in, it's programmable and it has various sensors and I/O on it.
Also the entire Arduino ecosystem fills a similar niche, of a bare-metal-ish platform which lets you jump right in and start coding things.
If you want something more in that spirit regardless of hardware, maybe PICO-8? It's basically a (virtual) minimalist 8-bit computer / gaming console for the modern era.
Works like a charm and can run C64, VIC, Atari ST, various older computers like PET or TI99/4a or zx81/spectrum.
It worked fantastically for my kids and brought back waves of nostalgia watching them grok the basics like I did.
She also has dealt with a lot of the social issues inside Silicon Valley, and has some pretty good insights there as well.
Perhaps 1/3 of her stories are cool "How the hell did she figure that out?" debugging stories. 1/3 are social commentary, and the remaining third are about odd bits of technology, like this post.
I read them and upvote the ones I find interesting.
https://hn.algolia.com/?query=rachelbythebay.com&sort=byPopu...
Sometimes it's submissions of interesting links from the discussion of a previous article (I've done that more than once), sometimes it's from people who decide to read past entries from the same source (or add said source to their reading habits). And I'm sure there's other reasons why this happens.
I thoroughly enjoy her writing and every time it is posted to HN I read it.