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.

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.

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.

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.

So someone will.

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.

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.

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.

I think that’s the challenge he described.

Looks great! Reminds me of some of my early classics!

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.

Another favorite book was Turbo Pascal DiskTutor.

My C++ book was C++ How to Program.

Let beginners cut their teeth on stuff like Python and Go. Rust can wait.

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.

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.

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.

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.

Structured Analysis and System Specification, Tom DeMarco, 1978.

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

(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...

[1] https://www.w3.org/Provider/Style/URI

I think this is the really important part, you have to challenge yourself and go outside of your comfort zones to keep learning.

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.

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

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.

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.

0. https://paulgraham.com/avg.html

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.

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.

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

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

    Peter Norvig (Copyright 2001—2014)

[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

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.

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.

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.

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?

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.

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.

I believe that was in this Bob Martin talk — The Future of Programming

https://youtu.be/ecIWPzGEbFc?si=A4qBR2YdX-0CV2bM

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

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?

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".

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.

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.

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.

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.

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

Or is there? Has anyone here done one of those 0 to 1 bootcamps with success?

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.

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

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.

Realistically, it takes closer to 10 years to achieve that goal.

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.

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.

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)

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)

1: https://micromasters.mit.edu/

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.

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.

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.

Thanks Peter Norvig.