Teach Yourself Programming in Ten Years (1998)(norvig.com) |
Teach Yourself Programming in Ten Years (1998)(norvig.com) |
I had done some MSX-BASIC, but after we got a "real" PC I wanted to learn a "real" and modern language. This is what they had at the local bookshop.
The "10 minutes" is done by explaining what C++ is and then it declares "there, in the last 10 minutes I explained things and you now know what C++ is". Ehh...
I didn't understand a lot of it. Chapter 5 or so is templates. It's pretty thin, and just rushes past things and never takes the time to really explain anything. It may be somewhat suitable if you're experienced in other languages, but it's absolutely not suitable for beginners. Visual Studio also didn't help (at the time I thought you needed VS to program on Windows – it was 1999, we didn't have internet, and I was 14, so what did I know?)
Aside from being a border-line scam, these books are worse than useless and actively harmful. As a result of this book I gave up programming for years, thinking I just didn't have what it takes. Wasn't until years later that I discovered this "Linux" and then "FreeBSD" thing that I discovered you can "just" write programs with "just" a text editor, and that things like Perl and Python and C exist.
If you see one of these things at the bookshop you should steal it and throw it out. Haha, only serious.
Fast forward another decade and then a lot of these Packt publishing style books on making games and learning coding - except for the holy grail of book series - GPU Gems… if you ever want to feel stupid, go read some GPU Gems articles. Today there’s a lot of choices - PBR - Vulkan - anything Eric Lengyel.
I still feel like it’s a trap. All these “Teach yourself…” should really be titled “Become obsessed with…”
Because we live under an economic system that says you must produce value for capital or die.
This is all very good advice. AND, I think we would have many fewer bad programmers and many more good ones if fewer Knuths were spending eight to ten hours a day mopping floors at fast food restaurants for $7.25 an hour, or writing garbage JavaScript for fly-by-night startups for $65,000 a year.
Can you name any social structure in which this is not true? Even medieval monks who are participating in a completely different society have to do the chores.
> Knuths were spending eight to ten hours a day mopping floors
I don't believe this happens and I know quite a few eccentric and unsocial smart people. Much more likely is them to spend the next 10 years at a relatives house speed running Mario.
Selection bias. People who have been able to distinguish themselves as “smart” are already a narrow sample, as the results of many UBI initiatives suggest.
> I am, somehow, less interested in the weight and convolutions of Einstein’s brain than in the near certainty that people of equal talent have lived and died in cotton fields and sweatshops. — Stephen Jay Gould
That's a rather disingenuous framing; I think we could probably do quite a lot to reduce the extent to which it's true without any particularly radical changes to our society. When we do start talking about radical changes, there are a lot that are not just likely to work but actually pretty well proven, like a UBI, improved labor rights, well-regulated and well-supported unions, wealth taxes, and so forth.
The possible alternatives are not "if you don't have a job you starve on the street" and "fully automated luxury gay space communism".
> Much more likely is them to spend the next 10 years at a relatives house speed running Mario.
Despite the disdain which you seem to hold for speedrunners (why?), a lot of really interesting hacking comes out of the speedrunning community. Some very interesting applications of deep learning had their start in the TAS community.
I'd rather ten people "waste" my tax dollars on speedrunning or art I don't like than one person be prevented from making art that's important to me (or doing some cool math, or whatever) because their boss's boss wanted a percent of a percent towards another yacht.
When I was 16 I was looking at programming books at Borders and a guy handed me a copy of "The C Programming Language"; changed my life.
So much of my career has been shaped by running into developers or just people interested in programming out in the world.
Thanks.
Some of those books were laughably bad. But thing I miss from back then, was the feeling that the book was going to be the key to getting you started writing whatever crazy idea you had for a program in your head.
I think the last time I had that feeling was walking out of Microcenter with a new MacBook and an iPod Touch, ready to make the next Angry Birds...
Yes! I miss it too. For me, that book was Head First PHP & MySQL[0] - Late 2000's, I was living and working in Thailand for a family friends small logistics company in the capacity of a BA, trying to move them into this century. We were trying to find a vendor for any system that would allow us to keep track of the movements of shipping containers within a container yard, and something sparked and I thought "hey, I did a semester of programming at Uni, how hard can it be?!", over the span of the next 6 months or so, this book helped me put together a solution that scarily, they are still using to this day.
Fast-forward 15ish years and here I am, still cutting code, although in the capacity of a dev lead, but after all that, I have the book to thank.
[0]https://www.oreilly.com/library/view/head-first-php/97805961...
I don't know who it was, it might have been one of the guys my dad worked with, be they said "You won't be able to write a game with a book like that, but you might be able to write a phone directory." Didn't phase me.
I remember someone asking me later on if I was going to write a game. I just looked at them blankly and said: "I'm going to write a phone directory".
I just learned today that "Sams Teach Yourself C++ in 24 Hours" was co-written by Jessee Liberty, one of my all-time favorite technical book writers. "Programming C#, 2nd Edition" was a great book.
I loved tech stores too. I still have all of the Apple pamphlets that CompUSA had sitting next to the display units.
I learned C first in high school because I found a pirated copy of "Learn C in 24 Hours" online, and I actually felt that they did a reasonably good job getting me started, though if I recall correctly some of their examples with pointers and memory management were actually incorrect. Still, it was enough to make programming interesting to me, and when I dropped out of college the first time I was able to salvage a somewhat decent career because of that interest.
My particular life-changing book was the BASIC manual that came the C64.
This was then reinforced when (~8 years later) I got Turbo Pascal, and it came with everything needed to get up to speed, then further reinforced when I started with Linux in 1995, and discovered that manpages (and info) were installed that basically got me up to speed on everything needed to write programs for that system. Later, late-90s, ISTR reading through the EGCS manual front-to-back.
I miss the days when the software came with all information required, instead of simply requiring you to search google for a product page or a manual.
I guess in about 5 years I'll miss the ability to easily google stuff (which I used to get in manuals) because all the relevant information got posted to discord and remained unindexed.
In early 2000s I learned sockets programming on Linux and FreeBSD completely from the manpages. Later I got Stevens' book and got through it very quickly, thanks to having already tried the manpages and written a few programs.
I remember transcribing code from the book to attempt to play a sound file when my program opened. I remember being stunned when it actually worked!
What an honor it has been to make a career in software development since.
For me my first programmed action was adding a button to a form, coloring it yellow, and having it exit program. I was absolutely shocked and geeked out.
Still just a hobby for me, but I have something in the works. I hope to share it with you all here soon.
This is probably less common now, but remember not to laugh at young girls in the programming section of a bookstore. In the 90s, that was a pretty standard response: no advice, just incredulity.
I can't believe anyone needs a reminder to act like an actual human being, much less not to belittle someone -- anyone! -- who is interested in learning anything constructive.
Unbelievable that anyone, ever, would act that way.
I still firmly believe that the move to transparent bags is what killed them. For me it ruined my annual tradition of buying Christmas presents while family was next door in another store, but I’m sure for others it was being treated like a criminal. Those magnetic readers aren’t great but they aren’t in your face.
Once I stopped going in routinely I stopped going in at all.
Not the kind of insult or atmosphere anyone should have to put up with, and, further, the generally affluent people of Harvard and MIT, which the store was located right between, weren't accustomed to it.
I called this out in 2000, when I made Web page about assembling PCs, during the rise of Web ecommerce retail. https://www.neilvandyke.org/cheap-pc-2000/
> I actually spent a lot of time checking out the local vendors, but was generally dissatisfied, and used them only as a last resort. If you're in Cambridge, MA, USA, some vendors I looked at: PCs for Everyone (informative Web site, but long waits at their showroom, and they didn't have a floppy drive after I'd waited 30 minutes), MicroCenter (large superstore, mailorder generally has better prices, didn't have advertised CD-RW drives in stock, the three of the four things I bought there were somehow defective), BestBuy (very poor component selection, guards at the entryways), and CompUSA (smaller version of MicroCenter, guard at front door insists upon comparing every shopper's purchases to their receipt as they leave). So much for brick&mortar service.
> UPDATE 2018-12-10: MicroCenter brick&mortar has risen to the challenge, and is now my overall favorite source for PC parts.
For me it was dBASE III PLUS programmer's reference guide from 1987 and it imparted enough knowledge to start a programming career. Read that dog eared thing end to end and still have it in my book collection.
Thank you, Alan Simpson wherever you might be.
Jeff Duntemann? or was he the Pascal books guy?
Maybe Robert Lafore.
Let beginners cut their teeth on stuff like Python and Go. Rust can wait.
You must not be very familiar with Rust.
It connected me back to some of that magic.
The same magic at "computer fairs (faires)". That same magic when you happened across that other nerd in the college/school lab doing something cool and subversive.
It does use features of C89 that may not compile after C99, but those aren't weird.
But, as someone who actually did try to use K&R to teach themselves to program, I agree it's not ideal for that. It's definitely not the best programming book ever, which some people say. The exercises are pretty good, though.
Another favorite book was Turbo Pascal DiskTutor.
My C++ book was C++ How to Program.
Re-reading it now, I was surprised to see references to Malcom Gladwell, since I didn’t remember Outliers becoming a thing until much later. Then when I saw the reference to Ratatouille, I realized the article had been updated since its posting in 1998. The original is still available on archive and is significantly shorter: https://web.archive.org/web/19980206223800/https://norvig.co... Respect to Peter Norvig for continuing to edit his posts over the years.
I’m giving Norvig a pass here because I don’t remember it being such a cliché in 2008, and because I appreciate the point he’s making about the importance of practice. (Early in my programming education I often felt that I might just not be cut out for programming, and I wish more articles at the time had emphasized that it takes a lot of practice to become a good programmer).
A recent negative book example for me is the Quantum Programming book from O'Reilly. I found that it did not discuss quantum circuits in a detail that helped me really understand what I was doing -- though I suppose that is a conceit of quantum computing. Perhaps I will return to it later (I am working through Nielsen/Chuang now, which is very theoretical, but explains things very clearly)
My policy is that a book is nothing more than a learning tool, which a hobby project can also be (perhaps more effectively due to the experience gained).
Then again, knowledge is power, and books are great at pointing you in the right direction -- assuming you found the right one for your needs, of course.
I know some people who won't open a book unless they know they can read the whole thing, which I think is a ludicrous attitude.
I did just order O'Reilly's Generative Deep Learning book, and am hoping to get something out of that, and if I only retain a handful of snippets to use in my career, that is profitable for me.
The least I can count on is that it will look nice on my shelf.
(edit: Reposts are fine after a year or so; links to past threads are just to satisfy extra-curious readers)
Teach Yourself Programming in Ten Years (1998) - https://news.ycombinator.com/item?id=33287618 - Oct 2022 (112 comments)
Teach Yourself Programming in Ten Years (1998) - https://news.ycombinator.com/item?id=27411276 - June 2021 (115 comments)
Teach Yourself Programming in Ten Years (1998) - https://news.ycombinator.com/item?id=20543495 - July 2019 (87 comments)
Teach Yourself Programming in Ten Years (1998) - https://news.ycombinator.com/item?id=16574248 - March 2018 (51 comments)
Teach Yourself Programming in Ten Years (1998) - https://news.ycombinator.com/item?id=9395284 - April 2015 (61 comments)
Teach Yourself Programming in Ten Years (1998) - https://news.ycombinator.com/item?id=5519158 - April 2013 (86 comments)
Teach Yourself Programming in Ten Years by Peter Norvig (2001) - https://news.ycombinator.com/item?id=3439772 - Jan 2012 (29 comments)
Teach Yourself Programming in 10 Years. - https://news.ycombinator.com/item?id=1060176 - Jan 2010 (32 comments)
Teach Yourself Programming in Ten Years - https://news.ycombinator.com/item?id=191235 - May 2008 (19 comments)
Norvig: Teach Yourself Programming in Ten Years - https://news.ycombinator.com/item?id=43243 - Aug 2007 (7 comments)
[0] http://www.amazon.com/gp/search/ref=sr_adv_b/?search-alias=s...
Or is there? Has anyone here done one of those 0 to 1 bootcamps with success?
I think this is the really important part, you have to challenge yourself and go outside of your comfort zones to keep learning.
Peter Norvig (Copyright 2001—2014)Realistically, it takes closer to 10 years to achieve that goal.
[0] https://youtu.be/ecIWPzGEbFc?si=A4qBR2YdX-0CV2bM thanks to comment by wild_egg
Can safely say after 20 years that there's maybe a bunch of information I don't need to know anymore that people <5 years experience probably would never need. OTOH experience is experience and knowing the constructs of things and their reason for being is always helpful.
And that there's plenty less experienced programmers than me that can do many things I can't even imagine.
TBF it's a pretty wide field, this Turing complete stuff.
Because programming can be a means to an end. You can do both: Learn enough programming to do useful things for yourself -- maybe not in 24 hours, but 24 weeks is not unthinkable. And spend longer to learn it as an art if you manage to get over the initial "hump" and are still interested.
For the fundamentals I would say 2 - 3 years of dedicated work is enough.
There's a guy on youtube called clearcode. He will teach you how to make games, in a Bob Ross voice...pretty much from scratch. You can also use ChatGPT to help you out.
The resources for learning are so much better. Socratic method of just asking questions is now possible with AI.
I think Sam Altman said that he is seeing x3 productivity increase from AI helping out programmers.
I also think it's worth saying, "you don't need to be an expert in programming to try it! Start by tinkering!" (Other comments have been downvoted for describing what tinkering might look like, but any tinkering is valid! Try running llama.cc on your MacBook! Quantize a model yourself)
Ultimately, you'll become good if you do it a lot, and you'll do it a lot if you have one or more hobby projects that you're motivated to work on. I have a few friends who are completely self taught (one going the Arduino / electronics / hardware route, the other going the web app and tools for personal use route), and the keys to their success is that they have projects they like working on. And they've kept at it for years.
They don't know everything, and they don't necessarily have great foundations, but it's not too hard to learn things on an as-needed basis these days. Both of them find information very differently than I do, which is also valuable for me to learn and see.
There are other ways to motivate yourself: taking a class with homework that gets you coding (the success of this strategy depends on the person!), finding an accountability buddy who you discuss your projects with, finding an open source project you're interested in (start by adding comments, fixing typos, or looking for a good "first timer" GitHub issue), do Recurse Center (although their job placement program may have limited options for junior / entry level engineers)
At some point, you'll have beaten your head against a problem (how can I order these things correctly? How do I get this interaction to work correctly? Why is my component re rendering in an infinite loop?) and you'll watch a video or read a blog post explaining it and you will truly understand the issue. It will be common, and you might have encountered it in a 201 class, but your first-hand experience will help it stick.
Another totally valid way to learn programming is to be good enough to get a job [1] and then be paid to figure it out day after day, and ideally have experienced programmers mentoring you. I've seen people go through bootcamps get a lot out of it, but I think the quality is highly variable
[1] unfortunately, while I think this was a really good path ten years ago, the bar continues to be raised (new grads with internship experience can be very good, companies are not hiring as aggressively today as they did in the world of zero percent interest rates)
It taught me variables, expressions and how the tooling works.
I was 6 years old and that was that.
That was 31 years ago and I still feel like I know only a tiny tiny fraction of my field. It is terrifyingly awesome. I hope I always feel this way.
Got a US remote job early 10s (I'm in the EU), and by mid 10s I was called "software engineer" by my peers and bosses.
I have just fairly recently upgraded my LinkedIn bio from "Web developer" to "software developer", as I can't even call myself an engineer.
Honestly, I have no idea what I'm doing other than making a real effort not to do stupid shit (and RTFM).
And then again you ask the run-of-the-mill SAP consultant how long it takes until an updated data record is available to a connected system and the answer will be something like 86.400.000.000.000ns
or closer to the original wording: 'one day'.
Thanks Peter Norvig.
I guess I spontaneously picked up on the 'challenge yourself a little, improve, repeat' strategy a long time ago. I often implement things over decade or more, through a series of small increments. I also decompose many problems recursively and use a sort of A* approach to make progress, sometimes revelling in some detail for months or more at a time before solving it, then backing up the stack to the larger problem I was working on.
For example, I'm building an automated microscope. I work with folks who buy $1M scopes just to speed up their science. I don't want a $1M scope- I want a $1K scope that does 30% of what the $1M scope does. To do this, i've learned how to design and 3d print components, integrate motors, controller boards, etc. Eventually I reached a point where improving the illuminator (the LED light that provides the light to the sample, which is then picked up by the camera) was the most important step and so I took a deep dive into LEDs, and the electronics required to support them.
This has meant putting the scope down and instead creating a series of designs for PCBs that incorporate increasingly sophisticated electronics and higher power LEDs. I set a challenge for myself that is beyond my ability: design and have manufactured, a working constant current driver and assemble the PCB myself using surface mount components. When I started, I knew nothing about constant current, or SMD, or designing PCBs. I started with the simplest possible designs- copying a reference design for ac ontroller, cloning a board I already have, incorporating low-power LEDs onto a board. Each step along the way, adding something slightly more challenging.
When I do this I fail a lot. Some days I get a PCB made to my design after a week of waiting (JLCPCB is AMAZING) and within 5 minutes realize I made a fundamental mistake. Other times, a board works perfectly and I "level up": I can now take everything I learned in the process, and use it to pick up the next challenge. Sometimes I get frustrated and depressed- not being able to figure out something that should be straightforward, and then I either rubber duck it, or ask a simple/stupid question on reddit, which typically unblocks me.
Today, I expect to receive my next constant current board design. If I assemble that and it works, I can then proceed to building a board to host a high power LED. That will introduce all sorts of new problems (heat management) that involve going into Kicad, thinking about stuff, making some experiments, sending a design to JLCPCB, waiting a week, and then assembling a bunch of boards, most of which will burn out (high power LEDs are tricky, if they got hot they fail faster). There's an opportuntity to buy some thermistors (little temperature measuring devices) and put them on the board to see how well my design for heat spreading it.
At the end of all this, I'll have a world-class transmission light microscope that can track tardigrades for hours at a time (itself an enjoyable delve into modern computer vision techniques), and I've talked to the world's leading tardigrade researcher, who wants to incorporate my ideas into his research to make tardigrades a model organism.
By the way, if I had stayed in academia, I would NEVER had the time, money, or energy to pursue this; I'd be stuck working on my funded research. NOBODY wants to give me money to design scopes that are roughly where state of the art was in the 1970s. But if I keep this up, in a few years I'll be ready to go play with the big boys and girls in the robot biotechnology labs with their $1M toys.
Bringing this back to Peter, I had the chance to work with him on a project (attempting to disprove the Beal conjecture by finding a counterexample). He did all the brilliant math and we wasted a bunch of CPU (and I mean A BUNCH) trying to find counterexamples. I like how when he wrote https://norvig.com/beal.html he wrote in the nicest possible way that I was wasting time and energy.
One can also look at, say, concurrency. A topic often seen as unimportant in the 90s, but ultimately taught at the lowest level, with mutexes, threads, semaphores and such. Those aren't going away, but how often is concurrent programming all about manually setting mutexes? We use higher order abstractions, but those change too. Many languages are encapsulating this in monads, whether people know their promise implementation is a monad or not. But that's not the only way, and the most popular way can change: Maybe languages in 10 years will be all about continuations and direct styles. Maybe it'll be something else. The fact that in the end, the same basic features from the 80s and 90s will exist at the bottom somewhere isn't that useful for most programmers.
And html generation... I was writing UIs before web apps were there. A lot of things that seemed fundamental went away when the browser was embraced. But will the browser live forever, or be superceded? I suspect that it will all get replaced, or be utter legacy, eventually. Will that eventually be 10 years? 30? It's very hard to say what will remain fundamental, and what will not.
Structured Analysis and System Specification, Tom DeMarco, 1978.
When a link has had significant discussion in the last year, the software will normally redirect the submitter to the previous thread rather than allow a repost through.
The bootcamp stayed true to the name. Core hours were 9-5 but many of us would get in early (usually 7am) and leave late (sometimes 10pm). I would also go in on weekends, sometimes taking Sunday off. I intentionally went to one in a different city so I wouldn't by distracted by a social life.
The focus was in ruby, then javascript. I got a job as an intern in C#/.NET a few months after graduating. I took the intern position because it seemed a tough sell to get a junior dev position right away. I was promoted to junior dev after just 2 weeks.
The school is no longer around, bought by kaplan and dissolved.
Edit: Whether I'm really worth the investment to these companies is another thing. I tend to think I'm not because I do sorta suck. But in terms of whether it's possible to go that path, be constantly employed and improve in time, yes it definitely is possible.
Since then, I've spent a metric fuck-ton of time programming (tens of thousands of hours to date). I've worked on compilers, 3D graphics, semiconductors and game engines.
I guess my experience kind of supports both sides of the coin. I was relatively easily able to get into industry with little experience (circa ~2012), although since then I've put in a ton of work to become a good engineer that people with interesting projects want to hire. Take that as you will :)
The first 2 years were very hard and it felt like swimming upstream the entire time as I didn't have that basis. It was only at the end of the 2 year programme that I actually felt like I could provide value independently.
A lot of my knowledge is very applied and I've noticed that I lack the CS fundamentals which sometimes makes it a bit harder as I'm having to learn 'basics' as I go.
In fairness my role is a Data Engineer now so it's a lot lighter on the more traditional CS areas like Data Structure and Algorithms.
I taught myself to program Basic aged 11, using the manual that came with the early 80s Dragon 32 home computer (a whole 32k of ram). Wrote some simple games, worked out you couldn't really do anything cool without knowing assembly language, completely failed to learn assembly language, as it was too hard for this 12 year old on his own, armed only with a copy of https://colorcomputerarchive.com/repo/Documents/Books/6809%2...
By the time I was 13 I'd given up programming and basically barely touched a computer for the next 15 years, did a History degree, bummed around as a musician for a few years and then, courtesy of the UK dole office, did a 3 month, 5 day a week, 9-5 course in Visual Basic, followed by a 3 month work placement. The company I worked for employed me when the placement came to an end and I've been working as a programmer for the last 25 years - although the last Visual Basic I did was about 24 years ago...
I think I was lucky that I hit the London job market as the first dotcom boom was starting, it seemed to be pretty easy to get a job back then and no one seemed that bothered if you had a CS degree or not. (I still don't have one)
I have done some academic CS courses (via Coursera) and did learn some interesting and useful stuff - but I think the most important thing to have if you want to be a good programmer is to have a self-directed mindset, you have to want go and figure stuff out and be able to learn on your own, using what ever resources you have to hand.
One of the things I like most about programming/software engineering is the fact that there is always more than one way to solve the problem, always scope for improvement and inovation
My tech lead did this.
And it’s also just wrong. People get into professional programming with... less experience than that. You might have never met anyone in your particular bubble but they do exist.
Going through extra steps to learn something through primary sources and valuing being uncomfortable at times are important for my evolution as a programmer.
The big difference for me is being able to struggle right up until I'm ready to give up, and then ask ChatGPT for insight. Usually my issue is a syntax one, and I have the concepts down (i.e. I was right to solve it using nested if statements, but I forgot I need to put a variable outside a function, for example). This way I get that dopamine hit of being mostly right, and quick feedback on what I need to improve. If not for ChatGPT, I'd be left feeling like I just failed entirely and I'm not getting it at all, which I don't think is the case.
I think the same experience would be achieved with a good teacher, but then I'd need my schedule to overlap, and the feedback on problems would still be often be delayed instead of instant.
I wouldn't use Copilot. I've noticed how it distracts people in screen recordings. They pause to see if what is proposed makes sense, and it usually doesn't. Distractions are the last thing I need.
To make an analogy to music, I see it like brass players at the advent of the valve.
It’s a new way of playing the instrument. The old ways and new ways aren’t congruent in all ways, but the new way does seem to have a higher skill ceiling
You shouldn't take the easy route when learning lads
But clearly using an IDE does not make one a bad programmer any more than using ChatGPT will in the future. The bigger issue is the field is awash in people not really interested in programming. There's nothing wrong with this as everyone has to make a living, but this has a far bigger impact on the quality of engineers out there than the nature of the tools used.
Not long ago I was at a hip Bay Area startup and I don't think any of my coworkers, senior or otherwise, spent a second of their free time thinking about programming. For me I program for a living because it's great to get paid to do my hobby during the day. Getting started in the field during the shadow of the dotcom bust, the majority of the senior engineers that inspired me were likewise obsessed with programming and would be programmers even if it paid minimum wage. I don't think I would have necessarily become a programmer today since I wouldn't have been near enough the flame to ignite my own spark.
Then again, we've had similar conversations about "iPad kids." As an iPad (along with everything else) user, I find it's not a bad approximation of a laptop -- you do have a filesystem, for example, and apps continue to be more fully-featured (in an Apple-approved way, of course).
I use copilot myself, but mostly as a smart autocomplete for setting variables or other minor things that consume time better spent contextualizing through problem solving and interacting with teammates. It's not a substitute for being an engineer.
Expertise comes with experience and experience will only come if you keep coming back. Some people can force themselves to toil endlessly, but here's some wisdom for mere mortals: start by searching for a part of software that you can truly love, then cultivate it.
If you simply do more work in your free time you might burn out. You want something that provides relaxation but still synergy effects with your day job.
I've seen incredibly smart people in the coding space (definitely smarter than I) basically "smart themselves out of it" because they felt it wasn't challenging anymore. Or they felt tired of the "wrong" challenge, like "waiting for everyone else to catch up to them." (They were usually involved with bleeding-edge tech that ended up being the norm years later.)
If fascination is motivating, I guess be happy that you're not too smart? ;)
If you just need someone to have done the legwork and established the exercises and presentation of material for you, there are a myriad of options: books, blogs, videos, open courses, paid courses, etc.
The trick I've found to mastering a field without having a teacher standing over me and guiding me (and even when I have a teacher) is to learn to construct my own courses and exercises. These are "synthetic". I look at multiple university courses on a topic and grab one or more books, and then work through them in an order that fits my way of learning. If they have a lot of exercises, I do them. If they don't or their exercises are poor (happens), I have learned (over the years) to construct my own exercises.
A major lesson from years of doing this is that there are no perfect teachers, courses, books, or other resources that will, on their own, teach me a topic to mastery. I have to assemble it myself to fit my way of learning and needs as a learner. That part requires introspection along with trial and error. I attempted courses and books that taught me nothing (or barely anything). After a bit of floundering with that, I took a step back and figured out what resources were effective and ineffective for me, what they had in common or were missing, and started assembling my own "courses".
That's a very useful skill to develop, and it transcends disciplines. Even if you do have an actual teacher with you this is still helpful (perhaps even essential) to be able to go beyond what they're teaching you and to cover over their weaknesses as a teacher (either general weaknesses or weaknesses with respect to you).
Most days I program 12 hours a day, most weeks 6 or 7 days a week. On a day I'm feeling very motivated I'll program for 18 hours. I've been doing this for close to 10 years. Occasionally I'll take a month 'off' and gear down to 3-4 days a week, still long days. By my conservative estimates, I hit about 3500h/year.
I work this much because I fucking love programming, and there's nothing I'd rather do ( other than my daily surf in the mornings, of course :)
FWIW, 10 years professional experience seems to be about right, give or take, to make a solid developer. I don't think I've ever met anyone who really got there in 5. Some people shave a few years off by having done it obsessively as a teen also, but at some point that typically overlaps anyway.
Of course there is also the old saw about 1 year, 10 times being a problem. I've met plenty of developers with >10 years experience that weren't that solid, too...
Though it probably helped that I had two mentors at a job 2 years in who were ruthless about reviewing my code.
Isn't this basically a software job? Like, get a junior role and work your way up over 5 years doing 40 hrs a week.
You can learn more about programming by giving yourself new and challenging projects at home. Doing both personal and professional work is the fastest way to progress while learning lessons from both. (commercial work teaches you the "professional" side of software engineering, which has almost nothing to do with programming)
Syntax is something I never learned, I programmed with man pages and manuals open at all times. But every language and technology I learned taught me something useful about a fundamental problem in computing and systems. The way we address problems gets wrapped in different clothes but the problems themselves are the same.
There’s no short cuts, and I know for a fact that as a programmer I’m orders of magnitude more capable than my 5 years in self. I’m excited to learn more and do new things more now than ever because they will unlock more of the craft to me. The only thing I worry about is my body and mind failing me at some point, not that I’ll run out of things to learn or be lapped by those younger than me.
If only I got to spend my time writing interesting code and learning interesting things.
Believe me, I have plenty of criticisms of that entire culture but it has a lot of good ideas. What in particular (besides the obvious overwrought ceremony) do you find not worthwhile?
I believe that was in this Bob Martin talk — The Future of Programming
It feels like we’re still in the alchemist days. Eventually the chemists will come along. They’ll systemize our ad-hoc observations and jettison a ton of them. Until then… Neuton was an alchemist and he still made some pretty big contributions.
Put another way: I think almost everything in software is arbitrary. Certainly some ideas are better than others, but on balance everything is a tradeoff, and I don't really expect for some powerful new discoveries or ideas to reshape the industry towards more structure and efficiency. I think it's more likely that AI replaces human programming entirely (although I dont think that's likely either).
It's like building buildings without "building science" - which, surprisingly, we have actually been doing in many ways to the current date.
There aren't really formal schools of "be a carpenter and build a house" - it's all very master/apprentice even if it is not formally so everywhere. And since things like "energy usage" of the building didn't really matter until recently, many buildings just kept being built the way they always have.
Now things like "can we keep this building comfortable at much less energy usage with some additional up-front costs" are coming to the forefront, and how buildings are built is slowly changing.
Compared to that, software is very in its infancy, because the real only bottom line items are "does it mostly work" and "did it not cost infinity dollars more than it made".
As for programming, I don't think programming is all that hopelessly complex and broad as field, but it can seem that way to a beginner. Most computer science concepts translate very well to other parts of the field, and the core programming constructs and libraries don't change much at all. How many ways can you configure a website, a mobile app or a database? Your instinct might be to think about all the different libs you can pull in, all the different programming languages, etc. But they all do roughly the same thing, they all compile down to the same stuff. You just have to develop the skill of understanding the fundamentals as opposed to getting lost in a sea of high level abstractions.
Also, broad-based knowledge can be the expertise; think a general contractor who's skill is tying all the specialists together. The best software managers I've ever had came from skilled generalists backgrounds vs. incredibly deep specialists.
I think the “in 24 hours” thing was more a case of “I’m going to tell you everything I know about XYZ in 24 hours”. Still, I have so many fond memories from the late 80s and 90s spending countless lunchtimes at McGills or the Technical Bookshop in Melbourne (now since long gone), flipping through tech magazines and wondering which of the many weighty tech tomes I’d spend my precious hard-earned on.
Yes in 24h you are not going to learn enough to contribute to Linux kernel - but also will be ahead of something like 80% of general population.
If you google image search for 'aol progz' there are pictures of FateX, AOHell, Revolution, Icy Hot, Rampage Toolz. Crazy trip down memory lane!
Apparently we're not alone: "Steve Case Confirms Zuckerberg as Former AOL Hacker": https://patorjk.com/blog/2014/04/27/steve-case-confirms-zuck...
Children/young adults aren’t even necessarily aware that their behaviour is inappropriate as it’s “normal” based on what they’ve seen happen around them their whole lives.
Adults should know better, but may do it anyway due to the human tendency to often dig their feet in, or consciously/actively do it for a reason which really has nothing to with the persecuted group.
Bigotry/racism/sexism persevere largely due to the above.
That was the only time I’ve been asked to “sir, please keep your voice down” and “sir, we need you to leave”. I still think I was on the right side of that one.
My credit card company eventually handled it for me.
So someone will.
Also, programming languages in 10 years from now will be pretty much the same languages we have today. There might be a newcomer or two, but it will be niche, as incumbents don't really change and only grow.
As a reminder, for people thinking that technologies change too fast, POSIX is still here and as relevant as ever.
Long lived historic articles can shape multiple years worth of discussion. I think it's even more fascinating to read the comment history and see what the current thinking is, if it has changed compared to previous years, etc.
About a quarter of those that graduated in my cohort are in the IT field, but are project managers or something similar.
The bootcamp was in 3 phases and you had 2 chances to test out of a phase or you'd be kicked out. Of my starting cohort of 16 people, 12 of us completed the bootcamp. Our cohort grew to 22 people though because there were people that had repeated phases to complete it.
There's definitely a cohort of "moderately capable at plugging away" type developer that can successfully come out of a bootcamp, and it's usually something like this path:
bootcamp - headhunter agency that needs bodies - develop familiarity/skill with the toolset - hired directly via some other company.
Less "startup valley next great thing" and more "updating the Java application for a change in the tax code this year" style corporate programming (which is the vast majority of all programming).
I like that point of view and generally code for fun that way. My biggest use for autocompletion is when working with unfamiliar Java APIs on a tight timeline.
But programming will remain domain of CS, which requires a deeper understanding and proper studying to perform it well. So, while I agree with you, I don't think all of this is that bad. It must be a positive think that more and more people at least try to pick up coding, can solve some basic problems with it, and if anything, will maybe motivate their kids to learn it properly.
Congrats you've found an edge case.
I've spent my whole life working in "commercial" settings, I've learned everything doing that, and it's all programming. I really don't know which places you work at where a software engineer doesn't do programming. That's the whole job, 8hrs a day.
Fuck going home and slugging another 4hrs software, unless you have the energy in which case good for you, you can fast track.
I did spend the next year or so adding features, bug fixes, etc. It was very much a case of learning on the job and I was quite fortunate to be in the position that I was. I think it was 2 or 3 years later I managed to land a dev role at Agoda (who had offices in Bangkok at the time)
Which, among other things, are also vital.
Oversimplified: 1-2 years of not knowing what you don't know. Then 3-5 learning how to write code, then 3-5 learning how to really write software. Most of that last learning curve happens outside the editor. That's a little to linear and non-overlapping, but the essence is true I suspect.
I'd agree lots of software is like engineering in that it is further tilted towards the practitioners and marketplaces and their limitations. It has more focus on cost-effective repeatability and risk management. But, traditional engineering is more rooted in some physical reality. I.e. civil engineering has basis in physics and materials science, because those drive failure modes and design criteria. The more social aspects---say evacuation routes for fire safety---developed within an existing practice that already been formalized to manage risks of structural failure etc.
But, lots of software is far detached from such a physical realm. It is more like legislation or contract law, or the arts. It's all about what people want to say or hear and display to each other. Massive influence from the cognitive and social context. It may be colored by technique and available materials or resources, but thanks to Moore's Law and friends, these practical limits have less and less influence on the shape of the outcome. Significant failure modes can be rooted in the vagaries of psychology, social sciences, or even political sciences.
However, software diverges from law or arts when we attempt to scale it up. We want to reach speeds that cannot be supervised and quality controlled by a human operator, or volumes of support tasks that cannot be managed by an affordable human workforce, or impactful decision-making and effects that cannot be adjudicated by a higher court. You need something like engineering here to manage risk, but there is no physical basis for building codes etc. Not only the new software products, but even the elements of risk are social constructs.
But I think the metaphors are broken as one pushes too hard "up the stack", into AI replacing knowledge workers and analysts. Our current best social systems completely depend on human adjudicators in hierarchical layers of oversight. Courts that can comprehend the big picture and resolve differences when our other abstract social activities go wrong. I am nervous about a future where tech behaviors become too complex for such oversight. Or worse, where naive practitioners think they can solve it with another layer of unproven tech. Instead of turtles all the way down, it becomes some faith-based electronic oracles all the way up?
And are things setup to "not" generate registration codes automatically?
Sitting on a couch for 10 years will make you an expert. Not an expert in sitting on couches in general but an expert in sitting on your couch during the period you were there.
The problem is the explosive decentralised development of tools, languages and frameworks under a hyper-competitive neoliberal economic system. Someone invents a language to lock programmers to their platform. Another programmer creates a tool to transpile that language to their half-assed dialect of another language. This leads to a huge problem of entropy and inefficiencies at all levels.
When people hear "civil engineering" they think "skyscrapers, bridges, roads" - this is more like "if you wrap a house in insulation, it's insulated better, but that can also cause moisture capture, which destroys it" type engineering.
https://venkivasamsetti.github.io/ebookworm.github.io/Books/...
The pdf of the book at this link does not have the error (page 84),
https://seriouscomputerist.atariverse.com/media/pdf/book/C%2...
so hopefully it's just an issue with the pdf from the github link.
Java as a first language: won't like the boilerplate but won't have any point of comparison anyway, will get a few NPEs, might use threads and get data races but won't experience memory unsafety.
Go as a first language: much less boilerplate, but will still get nil panics, will be encouraged to use goroutines because every tutorial shows off how "easy" they are, will get data races with full blown memory unsafety immediately.
Rust as a first language: `None` // no examples found
I think Go as a beginner language would be better if people were discouraged from using goroutines instead of actively encouraged (the myth of "CSP solves everything"), otherwise I think it needs much better tooling to save people from walking off a cliff with their goroutines. And no, -race clearly isn't it, especially not for a beginner.
And in one respect I've found Go more of a hazard for experienced devs than beginners: the function signature of append() gives you the intuition of a functional programming append that never modifies the original slice. This has literally resulted in CVEs[1] even by experienced devs, especially combined with goroutines. Beginners won't have an intuition for this and will hopefully check the documentation instead of assuming.
[1] https://github.com/grafana/grafana/security/advisories/GHSA-...
For all of Go's faults, "just send it over a channel bro" is easy to explain for trivial cases even if it often risks deadlocks and data races. To avoid the worst risks of this kind of code, Rust makes even trivial cases a big exercise. Go has an opportunity here to become more resistant to bugs without becoming less simple, but resistance to bugs doesn't appear to be a priority even for the Go team itself (e.g. even recently https://github.com/golang/go/issues/64474 )
In comparison, Python, Go, Javascript and C# are all much easier to teach and leave students more able to make real software.
Data structures, algorithms, algorithm analysis, various discrete math topics (set theory and number theory, a bit of graph theory, are usually included in a typical CS undergrad curriculum), models of concurrency, models of computing (lambda calculus, Turing machines), complexity classes, Chomsky hierarchy, type theory (some might consider this more advanced, varies by school and its lean towards practical or theoretical CS), systems of logic.
I've also heard good things about 7 programming languages in 7 weeks, as well as crafting interpreters.
The latter 2 I intend to pick up this year
https://sarabander.github.io/sicp/
If you want to run these locally, I can set Chicken Scheme for you.
From the perspective of pulling some C++ programmer in 1993 into 2024, and dropping them into a large C++ code base consistently written with the latest C++ idioms.
(And yes, this is humorous exaggeration. But the name of C++ is apt. A C language dedicated to accumulating features.)
I just don't understand how someone could have been working in C++ and not picked up the largest changes even just by osmosis. My code-based "upgraded" to C++11 about a year ago, but I can still read C++17 and am not intimidated by C++20 fragments. YMMV I suppose.
But as a senior, I can’t imagine using an LLM at this stage for solving anything meaningfully complex.
I could possibly be way off in my estimations, though. A true comparison would be having me do a task with and without it, but of course once I've done it once, the next time I will do it faster.
Without ChatGPT I'd just ensure I got an exercise right, and move on, half cloudy and uncertain in my understanding. The static content on Codecademy obviously doesn't explain that when first teaching you, but ChatGPT allows you to do ANY such comparison, and explains things exactly as you asked them, complete with demonstration code blocks and said fringe/examples where, in the above example, one method or the other would break or be suboptimal.
I think that’s the challenge he described.
C++ = Every time you look at old code, it is already out of date based on new features that were adopted after the code was written.
It's completely wild to me to have been in the field long enough to remember when agile was revolutionary, and then to see it slowly become twisted by decades of mismanagement into something that people hate today.
For most engineers today "agile" just means using jira, 30-60 minute long "stand-ups", and a perpetual panic about not getting enough done in 2 weeks.
It's giving me energy this Monday holiday(USA)!
That's probably the essence of the "good parts" that I referenced.
Not defending scrum but sounds more like you've been abused by bad culture disguised as scrum.
Their "sound biting" of a complex issue resonates. It can be difficult to even explain what I'm doing to several people in the bandwidth of 2 minutes sometimes.
Most charitably, it's just a quick, lossy status report and forced request for help with blockers.
I feel like something is wrong if you feel like you need to cut corners to perform a "good-looking" report in standup. You shouldn't feel/cave to such a pressure.
Actually, back in the days, google would have given you a tutorial with the correct answer together with examples too. You don't need LLMs for this, just honest search. But honest search is gone.
I wonder how long till ChatGPT gets entshitified too...
What might save us from ChatGPT enshittification are the freely available LLM's. Probably won't be long before we can have a code companion running locally. It's probably already here
In my experience if you search for an advanced topic it's likely to drown you in beginner's tutorials for anything even remotely related.
My pet peeve is i do embedded linux on custom hardware, and every time i need to check something i'll be up to my neck on tutorials telling me how to enable, say, spi on a raspberry pi in user space. Even if I was explicitly searching for a totally different SoC and a recent reference for the kernel functions :)
https://learn.microsoft.com/en-us/cpp/c-runtime-library/comp...
https://en.cppreference.com/w/c/language/arithmetic_types#Co...
Dear ProbablyRealPersonGPT, please provide the necessary code in C with a short explanation
Some of you are set in this idea that an LLM can possibly not be even slightly helpful that you have to trudge through pages of documentation just to look for one slight thing that it'd have told you right away _if_ you wanted it to.
You shouldn't cave, but if that's the culture around your in for an uphill battle.
> I feel like something is wrong ...
Yeah, bad culture.
... Which is Tiny C Compiler
The point isn’t that day to day is full of brilliant insight, but that process year over year you become really adept at these things you’re struggling with and you see patterns more clearly and can cut through the struggle faster and focus more on doing cool things with that ambiguity.
Frankly today is better in these respects than it’s ever been. The tooling for insight and debugging is mind bogglingly powerful relative to 30 years ago. But that doesn’t make struggling in your own ignorance without a clear guide through any more fun. That feeling of desperate helplessness and idiocy is the feeling of LEARNING, which is compounded by ambiguity. It’s easy to feel angry with X for not doing Y (I.e., lack of documentation) for your situation, but the right answer is to buckle down and figure it out and focus on developing skills to make it easier next time you have to learn.
What do you think a mechanic does ALL DAY? Very few carpenters start with a raw blank of nice wood and craft something amazing. It's all interpreting plans (poor spec), framing (boiler plate), figuring out an addition (bolting on features to a shaky platform), correcting things that have failed (maintenance), addressing things that were built wrong (bug fixes) or fixing shoddy renovations (tech debt). Sounds EXACTLY like the majority of software development.
Are you implying that they are fixing their tools rather than cars? I don't know any mechanic that would put up with that and would replace their tools with tools that actually work.
It was basically unusable. Fundamentally flawed design. There's no possible way anyone tried it and went "yes, this is fit for purpose". Worse, the complexity of its design which caused so much of the trouble (it had a single-sided blade that could be spun around—the locking mechanism was simply flawed, I didn't get a bad one, it just could not work well) could have been entirely avoided by spending barely more money on manufacturing. I mean it was also very dull but at least it would have been usable, if slow.
I managed one jamb with it, taking probably 10x as long as a version of the tool fit-for-purpose would have, busting up my knuckles plenty, and making an uglier cut besides, so I could move on, and ordered a different one for the rest, since the store didn't have any other models.
That's about the median quality of all tools and libraries I encounter in software, in my estimation. Size of vendor or how "smart" their employees allegedly are (LOL. LMFAO.) doesn't seem to much matter, either. And usually it's like that crappy jamb saw being the only jamb saw available at the store, except there's no option to skip the big box store and look for acceptable ones online, and if there are any other options they're somehow even worse.
Luckily 99% of the tools for "real" work I've bought haven't been anywhere near that bad. Even the cheap ones. Almost all of them are more-or-less sensibly designed and actually do what they're supposed to without causing a huge amount of trouble.
Most of an average day programming, for me, metaphorically, is swearing at this fucking piece of shit jamb saw while my knuckles bleed and I'm fucking around with its brokenness instead of getting anything done that I actually wanted to.
On the other hand the tools are mostly very simple and highly standardized. The simple tools are applied to the problem through a combination of applied experience and constructed jigs. I guess the equivalent in the software world would be classic non-fat Unix as your base tools, and building your own libraries and toolkits as your jigs (no or very limited third party deps), while aggressively avoiding complexity. You’ll get reliability this way; of course, there are serious tradeoffs.
Don’t misunderstand me, though. I agree that the modern software treadmill is horrible and needs to be tamed.
> Yeah, it’s not quite the same.
I actually don't know quite why I wrote what I did, because the concession really isn't true. I can only imagine we were discussing some romanticized view of the subject. My own experience, however, shows that reality is otherwise.
Cheap tools usually don't work well or last; you end up constantly complaining about them and constantly replacing them. This is true whether you're talking about power tools or simple hand tools. (How much do you pay for most of the software and libraries that you use?)
For the hand tools --- some things like hammers basically work, but other things, unexpectedly, do not. Handsaws and handplanes are two good examples of simple tools that are fundamentally broken from the manufacturer, and in many cases simply cannot be fixed due to design. Other tools can be salvaged, but don't work out of the box. You can shell out inordinate amounts of money to a company like Lie Nielson, or hope to get lucky on the purchase of an antique, but the typical products you might expect to work, don't.
For power tools, the cheaper tools might technically do a job, but they often function in ways which are detrimental to the work or to personal safety, and don't last long.
You might think the solution is to spend more money for quality tools, but this doesn't always work out either. I'm thinking of a DeWalt biscuit joiner and a Makita pin-nailer; both are well-respected brands for "real contractors" who rely on their tools and expect them to work. The Makita pin-nailer doesn't load its nails right, so I have to futz with it after every nail --- which kind of defeats the purpose of the tool (it didn't do this originally, but it didn't take much use before the problem developed). The biscuit joiner, despite being a well respected model, cuts slots that have so much slop in them that there's no point in using the tool at all.
Now lets talk about machines briefly. My radial arm saw (no longer a common tool, but once quite common both in homes and on jobsites) cannot be calibrated to proper specifications. One of the adjustments cannot be made to spec and it throws off several of the others. The result is a tool that, while useful, is only half-functional. I have theories, but don't know exactly what is causing the issue (I got it second-hand); I would need to completely tear it down and grok the entire design, then rebuild it, to properly fix the issue. By the way, the calibrations it does have need to be periodically checked and corrected (the RAS takes a lot of flak for this, but I find this is true of any machine with adjustments).
This is usually about the time where the internet gets up in arms and tells you to throw away the RAS and use a table saw, so lets talk about my table saw --- the fence can't be calibrated to lock parallel to the miter slots. I don't think the fence is broken by design, but I don't know exactly what's wrong. The calibration process is logical, it just inexplicably doesn't work. I suspect one of the fence rails may be slightly out of alignment. I could fix this by building my own high-quality fence system --- I have the skills --- but this is analogous to throwing out your third party library or tool and writing your own.
In all of the above cases concerning power tools, the answer is maintenance/repair, but in all cases (aside from building a new fence), it is not the work I want to be doing, nor is it work in which I am experienced, nor is the necessary work obvious through casual investigation.
Of course, I have plenty of tools that work great and never give me trouble, other than periodic maintenance, but it's the problem tools that stand out. Software is the same for me; most of it works fine, some of it breaks down due to bit rot (maintenance required), some of it is broken from the manufacturer (out-of-box repairs required), and some of it is just piss-poor in design (see hand tools above).
I still hate the treadmill just as much as you appear to, but romanticizing the life of a tradesman is probably a mistake. Entropy is everywhere, poor design and unfortunate occurrences are everywhere. I don't know if you have any personal insight into the life of a tradesman, but they deal with all kinds of BS, from all angles, that just isn't commonly discussed outside the field in question.
=== Addendum:
I keep mentioning software libraries, but those really aren't tools. They're more analogous to prefab construction components, so in that case we could talk about items such as pre-hung doors and prefab cabinetry that is supposed to save time and require less skill to install. That's great, until you discover that the item was assembled out of alignment at the factory, defeating the entire purpose. I could go on ad nauseam, but I imagine you probably get the point by now...
God, it's all just miserable and depressing when you really start digging into it, isn't it?
That was my entire point.
