How I learned to program
danluu.com
danluu.com
However, it's amazing when you read about <insert famous programmer>. They grew up with Apple II's and Commodore 64's, but they mastered them. Or at least that's the narrative from the author of the articles that talk about them.
They don't just write silly BASIC programs like the rest of us, they started using assembler and learn the machine like the back of their hand. They learn how to optimize the living crap out of their code. Maybe their schools just had better books in their libraries or they subscribed to the good magazines of the day. Or they were just that much better at programming and smarter and more focused, one of the above, or all three.
you've got a thing you want to make, but you get stuck along the way. it's too slow, or doesn't fit in memory, so you have to figure out how to optimize what you've got before you can keep building.
Kids don’t necessarily know where to look, and it’s easy to get very stuck or discouraged if the learning curve is too steep to get something simple working within a reasonable amount of time.
There's probably a lot of fumbling common to all computer users in their early days. But what separates people is how far you can go in a short time.
I guess I was lucky to have access to the books: I went to a (monthly?) Philips ‘old crap’ sale. If I remember it was in the bottom of the PSV stadium and they had old electronics and mags and books for sale for cheap. It was so lovely; we took a car full of old circuitboards to get components off, books, printed papers etc home and spent the next month working on them (this was summervacation usually as it was close to my grandparents).
Here I am, 30+ years later, spending a couple of years trying to learn programming properly having been made redundant from 2 jobs... I don't think I'm an idiot, but I think it's a combination of others being smarter than me and more attuned to the task in hand, but also there's an element of luck to it. I think if some of the cards fall slightly differently and the things you try happen to work (mostly skill, but with an element of luck), you can get drawn into it, gain some resilience and make progress. If you stumble too much before you make real progress you can think you're stupid and give up.
Have a similar parallel experience with playing the guitar (which is how I've mostly earned my living in the intervening years) - an element of picking technique which I didn't manage to work out in the 80s when I was learning and again put it down to my own inability; now with better resources and research in the current era, found out what the 'missing part' of the jigsaw was, and realise that if I had found it (I was close, but no cigar) then things could have been drastically different. Fortunately it happened at a playing level which was already beyond 'give up, you're useless'!
Those are real programs, but looking back, I actually do think this might contain a seed of why I never did become as strong a programmer as my peers from those days. I floated away fr programming, got into writing and music, floated back in. Some of my peers from those days couldn’t take their eyes off computers, it was a deep fascination.
There are lots of good ways to be a programmer. But the real experts do seem to have a deeper fascination with the inner core, the hardware, machine code, actual design of programming languages (debates about ruby vs python or similar almost always go beyond my depth, I just like how ruby looks on the page. I just like how quickly I can get my answer in python).
I wonder how many of these "teach your kid STEM" toys have this result. I learned to program when my mom got me a vtech precomputer 1000 for Christmas when I was a kid. But becoming a "developer" took many years of effort. Hopefully more kids will be set on the path like I was.
I didn't Hello World until my 20s, and it took years to really grok the programming world, but I think my lifelong exposure to logic and programming of sorts made all those concepts accessible outside of a classroom environment. Ie. I could understand what a python snippet was doing because I knew what a loop and conditional was.
Sadly, I've taken some really bad logic classes. Usually this is because they use terrible toy languages that are artificially difficult to work with. They should just do those classes in Javascript or python or something, after they cover the old Aristotelian logic bit. (Socrates is a man, all men are mortal...)
You could rig up a test suite to brute force truth tables and verify when you create correct logical statements. It would be a blast.
Instead you spend all year having to derive known logical theorems from scratch. Because reasons?
Example:!(x and y) == (!x or !y). I had a class where in the toy language it took a whole hour to derive that theorem. Instead, how about we have to draw out a truth table or actually use that statement? You can do that in half the time and get more from it. I've had to use that in programming all the time. You can flip if!(!x.isEmpty and !y.isEmpty) into if(y.isEmpty or x.isEmpty)... If I typed that right. Comes up all the time refactoring or simplifying logic.
Maybe i'm missing something, but what does for-loops have to do with logic in a way that it might be part of the class?
You can go in a direction of explaining logic and computing together, and by what I skimmed from your article it does seems to be a cool way to tackle the problem, but that's not what someone who takes a logic class should expect from it, they should expect it from the "topics of logic in computing or something like that" class.
You absolutely need something more. Maybe the teaching of logic as a means to solving a larger problem, whose result is beautiful, exciting, engaging. This is why I love robotics for children. How do we make a hand-built toy robot do the things we want it to do using logic?
https://www.quora.com/Are-there-any-lies-that-your-parents-t...
I don't know about "meant to". I avoided writing anything but plain HTML and CSS for years because I thought I wasn't a programming type person (wasn't smart in the right way, didn't like math, hit brick walls with basic as a teenager, etc). The terminal did nothing for me and still isn't my favorite place to be, but I do really like writing little web apps that solve problems and work. Programming, like most things, is available to anybody who wants to do the work to understand it and can put in the hours to get competent.
I see the risk in Scratch turning some kids off and would never suggest just providing anybody with one option for how to learn a skill. But I don't know about this "meant to program" idea. I'm more in favor of fostering the curiosity that can fuel real learning by any means that work.
HTML/CSS does not teach things like algorithms and data-structures, but it doesn't need to. It's complex enough that kids with an affinity for programming will find it stimulating, but not so complex that dumbo Timmy over there can't do at least something productive with it. And it straddles that line between nerdy-programming and design, so you can engage the creative kids as well.
Family member's been teaching HTML/CSS to 14-15 year olds, with good results. Like all class topics, the engagement-distribution is a bell curve. 10% is lost like a puppy at sea, 80% is following along with varying degrees of success, and 10% are absolutely doing amazing things and taking it way beyond the class contents.
One difference with the other type of kids-programming isn't that some robot scoots around the gym, but that at the end these kids are making goofy 90's websites, with bonker color-schemes and bouncing images. Parents and administration love the former. The latter only really clicks for parents with some familiarity in the domain.
I strognly disagree. Playing around with markup languages only trains a person to expect a computer to map a particular input to an output. That's far from programming, let alone real-world programming practice. Writing software is much more than getting a computer to output something in a one-shot process. Making these sort of claims does a diservice to anyone interested in programming because it paints a rosy picture of how programming is trivial and free from any intellectual challenge, which goes directly down the crapper once the first crash or bug needs to be solved.
As someone who's spent many months teaching people to code from scratch, it seems to me you're ignoring just how tough it can be for people (especially kids) to learn challenging new information. Most will quit when they hit a wall.
In my opinion, baby steps are much wiser when the goal is to teach.
I would disagree with one thing. Writing HTML/CSS most certainly is an intellectual challenge, especially for beginners, and does engage parts of the programmer's brain.
I wrote it up here: https://henrikwarne.com/2017/12/17/programming-for-grade-8/
HTML and CSS are great for learning because everything they change will adjust the webpage instantly. This is the web's biggest teaching advantage: insanely fast iteration time. To folks learning this speed feels like a super power. (And when they try iOS/Android programming, they will miss it)
Where Javascript comes in, is it helps tie that fast iteration into a place where variables and functions can exist. Functions are especially hard to grasp, so starting those pretty early matters a lot. Simply put: if you don't understand functions, then all the HTML/CSS in the world won't save you!
You can do some cool stuff with LOGO like create state machines, implement sorting algorithms, and create simple games.
Yes. However, at a fundamental level, LOGO is actually an advanced programming language.
Or really anything you want, though after several years of experience students might find other tools more convenient for some types of modeling.
I had no idea that was even a thing, even though I'm definitely of your generation, though probably not in the same general area, situation, etc.
You should have had an Amiga, C64, or C128 or... I'm happy that you made it, though!
QBasic might not have been the greatest language, but it had a pretty sweet IDE, fantastic live documentation, and was really just fun to play with. I feel like there ought to be a packaged up Python distribution with the same kind of attributes, but I've never really seen anything that really aced that spot the same way.
Only if I told my younger self to actually go through the Macromedia Flash book I borrowed once in high school, I would have had my first glimpse in computing. But during my early days, I never had anyone who was remotely interested in computers. I wasn't great at socializing either which would have lead me to people who were in machines. There was AP CS course at my university but I never took it only because I thought it was too hard and instead took AP Calc.
Without any concept of computing or the power of programming, how can a kid get into life of software development? All the random success stories I've read of popular programmers these days, all of their younger days began with someone giving them a gift or some 'assembly' language computer and started from there.
Wish the pursuit of programming caught me much earlier in life than right now, went into wrong major and always thought about programming, programming. Having friends and family who aren't into computers didn't help either until last year. So much life was wasted.
Everyone has periods of low productivity, you just need to roll with the punches and keep learning and building whenever you can.
In my case, I learned how to program when I was much younger but it was never actually my job - or at least, not the primary component of my job. I kind of backed into it, writing more complicated scripts which helped automate what I was getting paid to do, until I eventually just got a "real" programming job.
The big thing I think I have in common with the OP: I always try to automate every task possible. This can allow you to add value for your organization above and beyond whatever primary task they hired you to complete, and any company worth its salt will recognize that contribution and try to find ways to help you contribute more elsewhere too.
"but that’s so obvious that it’s not even worth stating"
1) There's a lot of value in writing down something about one's experiences, even if the result is "obvious" to anyone else who has gone through the experience. There are likely a lot of people who HAVEN'T gone through that experience who would benefit from reading about it.
2) I worked on a project, mostly independently, for a year or so and produced something useful. To me, it seemed fairly pedestrian: some basic data structures, some ordinary algorithms, nothing particularly novel. A mentor suggested I write a conference proposal about it. I resisted, using the "it's obvious" argument. He came back and said "You've worked on this for a year, and no one else in the industry has worked on it. By definition you're the expert. It's worth a conference talk." Indeed it was, and it launched a significant portion of my career as a conference presenter.
I think this is largely about the difficulty of thinking about what others think when one is too close to a topic. After working on something intensively for a time, one develops a familiarity and intuition of the knowledge about that area. When working with that understanding, things may seem "obvious" but that are totally non-obvious to someone who hasn't worked in the area. This is less about absolute intelligence per se than it is about expertise, and so it's a variation of Kay's aphorism "A change in perspective is worth 80 IQ points."
It absolutely poisens the learning atmosphere. And after 20 minutes of lecturing on a difficult topic they ask if anyone has any questions and wonder why noone raises their hand or says anything.
Dude, if you had to think about it for 45 minutes, it's not obvious.
I have on multiple occasions sat down and worked with another mathematician on a problem for an hour+, only for us to find the solution and both conclude that the answer was "obvious."
Is that not inherently obvious? Good things are... good, and bad things are not?
Assuming something is obvious is dangerous.
Looking back I can't understand why it took me so long. It's so obvious.
Sometimes it's really hard to understand why some things are not understood.
Actually, the advice to avoid managers who are not helping employees is eminently actionable. It's just that the actions are either tedious or radical.
Tedious steps to take, before you are in the situation: find other current and former team members on linked in and do backchannel references on the position.
Radical steps to take, after you are in the situation: quit your job and find another one.
He speaks a lot faster than I do, which is not something I'm used to. We exchanged Flandersian fusillades of words (including some about the relative speed of talking in different places, languages and scenarios).
He's legit. We'd struggle as a programming pair, though. Both too keen to hold the lock on the talkbit.
That _is_ the advice :P seriously. Most advice is far too subjective to likely be applicable to yourself (because life is so messy).
With one exception: "leave bad roles more quickly and stay in good roles longer", as the author mentions, it seems far too obvious, but it's not... because "bad" is actually subjective, so "not working well enough" is perhaps more accurate.
Some "successful people" have never had a "not working well enough" part of their career because they are crazy lucky, and others have simply been perceptive enough to recognise it and move on. Some label this as "luck" but luck implies some objective "good", it's about chance, the chance of landing in a well fitting scenario.
Rolling the dice can be painful, and knowing when it's good not always obvious. Perhaps at least knowing to look out for this even though you don't know what it will look like for you, is the only general advice?
* break the hard problem into smaller problems (e.g. "make a car that drives itself" would really benefit from considering smaller components)
* reframe the problem. Sometimes changing the perspective on a problem lets you leverage tools or techniques from related fields. For instance, there isn't much good literature on techniques for understanding obfuscated programs, much of it gets bogged down in low-level details and has a very short shelf life. But there is one field that has a lot of good literature on understanding and transforming programs: compilers. Realizing that was transformative in my own research.
* go bottom-up: are there special cases that are easier to solve than the whole? Can you generalize from there?
* go top-down: pretend that you could use some off-the-shelf components that would automagically solve parts of the problem. See if you can compose them into something that looks like a solution, then see how to implement them.
Beyond the straightforward approaches of chunking the problem to sub-problems or what have you, which you will apply anyway, sometimes a little brainstorming can surprisingly help you with that "spark."
Actual, specific approaches to tackling tough problems are taught by the famous Hungarian mathematician George Polya in his classic book How to Solve It [3].
Discrete Mathematics is a field that covers a number of areas, but especially in counting problems (from combinatorics) and graph theory there are a number of results that are not hard to grasp but lead to beautiful solutions for real problems. There are many powerful theorems and principles in discrete math that will unlock seemingly impossible problems. Unfortunately, the books for this subject are mostly written for math majors that are interested not only the application of these results but how to prove them and consequently the books may not appeal to everyone. Perhaps something like Schaum's Outline of Discrete Mathematics would suitably cover the way to apply some of the important theorems without bogging down in the proofs.
Finally, I think there is value in doing small interesting programming projects. Two older books, available used, with interesting projects are Etudes for Programmers by Wetherell [5] and Software Tools in Pascal by Kernighan and Plauger [6]. Etudes has my favorite exercise for trying out new programming languages, building an interpreter for the simple TRAC programming language; Software Tools has a number of programs in Pascal that do interesting things, try implementing the programs in your programming language--they cover a range of difficulties and the book has a nice discussion for each that explains why the programs are structured the way they are.
A more advanced book, Structure and Interpretation of Programming Languages, available as a downloadable pdf [7] is a classic book for those wanting to become better programmers.
[1] https://www.amazon.com/Martin-Gardner/e/B000AP8X8G/ref=sr_tc...
[2] https://www.amazon.com/Raymond-M.-Smullyan/e/B000AQ1NF0/ref=...
[3] https://www.amazon.com/How-Solve-Mathematical-Princeton-Scie...
[4] https://www.amazon.com/Schaums-Outline-Discrete-Mathematics-...
[5] https://www.amazon.com/Etudes-Programmers-Charles-Wetherell/...
[6] https://www.amazon.com/Software-Tools-Pascal-Brian-Kernighan...
1) it helps answer if the problem is worth solving in the bigger picture
2) it allows me to approach the problem differently. (A new approach compared to head banging against walls)
I would be interested to know what teams Dan worked on while he was at Microsoft. He says that team #1 couldn't build their source code on most days, and that while team #2 was better, they still often had broken builds in origin/master.
This was his second MSFT team, as I recall - I don't know that he ever publicly identified the first.
> However, I can already tell that this experience broadened my horizons. Two examples I got out of the experience are a better understanding of how sales worked and I have a better idea of the range of processes that exist across different teams.
> To the first point, the company produced some decent products backed by a world class sales team. Watching the sales team work was a revelation. The sales people would regularly go in and create sales even when the product wasn’t the best thing for customers. I’d always known that sales was at least as important as engineering, but seeing this in action was different from knowing in the abstract.
> To the second point, I once wrote a blog post on build uptime where I looked at uptime data that seemed surprisingly bad to me and said
> at every place I’ve worked, two 9s of reliability (99% uptime) on the build would be considered bad. That would mean that the build is failing for over three and a half days a year, or seven hours per month. Even three 9s (99.9% uptime) is about forty-five minutes of downtime a month. That’s kinda ok if there isn’t a hard system in place to prevent people from checking in bad code, but it’s quite bad for a place that’s serious about having working builds.
> A number of people responded with comments like “lololol that guy has been pretty lucky in the team’s he’s worked on”. I didn’t think much of those comments until this job. At my first team on this company, we couldn’t build on most days for most of the time I was there! My second team was better, but I would regularly get broken builds when I fetched and merged from origin/master. I had no idea that companies that considered themselves serious about development could have practices like this and it’s good to have this new information.
JavaScript is the new BASIC, in the sense that it is universally available and a great first language to pick up.
It is easy to forget that self-taught programming is motivated by that intrinsic discovery factor, and JS feeds the dopamine loop!
> High school (1996 - 2000)
This does't seem right. What sorts of competitive programming sites were around that early?
whois topcoder.com | grep Creation
Creation Date: 1998-12-30T05:00:00Z`
So plausible, but extremely early adopter. More likely would be craigslist, IMO.
next step - CSS for dummies, because this is awful[1]
During school hours, I'd just sit in the computer lab learning Photoshop 2.0, HTML, and the new cutting edge thing called CSS. I'd have loved to take one of the BASIC classes because I had already worked with it a bit on my TRS-80, but they were only offered to kids who had taken AP Algebra 2. One pleasant spring day I was coming back onto campus after smoking a butt across the street, and the vice principal told me I wasn't allowed back onto school property because I was no longer a student. After a few months of just working, I went back and finished high school in a part-time night school program while working full time. Oddly, I've always thought of this as a somewhat pleasant time in my life despite my negative feelings about high school in general.
A year or two after graduation, around 2000, I took a few classes in a UNIX undergrad certificate course at Northeastern. Not only did I ace the classes, but I ended up teaching my classmates more than the instructor did in the Linux class. (That was way less cool than it sounds though; he recommended everybody drop the course and ask for a full refund because he was under-qualified and knew it.) Also, the second-level C class teacher— a hardcore windows guy— emailed me asking questions about developing in a Linux environment for a few months after the class ended.
It was a confidence boost which SHOULD have pushed me towards college, but I still assumed that no 4-year college would have me, and the thought of essentially trudging through two more years of high school in the form of community college was... unpalatable. I stopped taking classes before I finished the certificate because they didn't offer me anything I couldn't learn on my own— even if I did enjoy learning little-unexpected things like C-shell scripting, and advanced awk— and it wasn't going to lead to a real degree. I was much more interested in working in bars and living in shitty apartments with a million roommates with only discount pizza and malt liquor for sustenance. (wait, maybe I did go to college...)
I was lucky enough to get a $10/hr job as a university library IT assistant where the systems administrator gave me a bit of flexibility with what I worked on, a bit of leeway for solving those problems, all of the tech books I wanted, and all of the scrap hardware I could muster up. I ended up learning how to use Perl, first as a systems language and then for CGI programming, honed my shell scripting skills, built a few slightly more involved internal web applications using PHP, learned how bigger networks worked, good IT practices, and lots of other cool stuff. From there I bounced around to a few higher-level support type jobs and then got my first regular software development job after that. Since then, I've tackled problems with increasing complexity and managed a few projects.
Though the more 'vocational' path I took to coding instilled some good practices and a rock-solid work ethic, I feel like there's a bit of whiteboard swag that people who took a math-first, comp-sci-heavy path to coding have that I lack. As the level of complexity with my work projects increases, I sometimes struggle because I picked up a lot of the math and comp-sci knowledge magpie style without having the solid theoretical foundation to tie it all together. I thought learning a programming language without a real-world problem to solve, and no real deadlines was a slog; doing that with things like discrete math is much worse. (though I do think it's super neat.)
It's pretty funny that the primary difference between me and him is that I believed a guidance counselor who told me it was impossible. Approaching 40, I realize how full of shit she was.
[…]
I went back and finished high school in a part-time night school program while working full time.
[…]
I believed a guidance counselor who told me it was impossible. Approaching 40, I realize how full of shit she was. ”
So, what were your grades at that night school program?