I graduated college in 1996. I had four language classes - C, Pascal, FORTRAN, and COBOL.

Out of those four C is still heavily used.

If someone graduated college 20 years ago and they were taught Java, and they stayed on the course as a Java developer, they would still have plenty of work today. If they learned how to use SQL Server 2003, Oracle or MySQL, they would know one of the three top databases today.

> Had she followed that advice in the 60s, she points out, her students would have spent their time studying JCL

That’s kind of irrelevant.

20 years ago Microsoft was king of the desktop, Unix was big in servers and Apple was a distant second when it came to seconds. In 2023, how much has changed?

> This is false. “The only way to improve at X is to do it” is the advice you give when you actually have no idea how to improve…

This is also false. I was an active fitness instructor for 8 years and my cardio was great and also was a weightlifter. I could teach a two hour master class and go hard without giving out of breath. The first time I decided to do an outdoor 5K on a whim, it took me 40 minutes and I felt like I was going to die. I had to do run specific training.

> Instead of substituting for a traditional degree, recruiters are calling bootcamps jokes

I’ve found BootCamp grads far better junior developers when I was in enterprise dev than CS grads.

> My Advanced Software Design Web

“It is difficult to get a man to understand something, when his salary depends upon his not understanding it.”

To get good at doing the thing, you have to do a lot of the thing. To optimize your doing of the thing, you have to spend time understanding the thing. Because pure doing eventually hits a wall.

Take boxing for example. You can be really good, have great stamina, and even a fantastic jab. But then a coach looks at you and says ”When you throw the jab, try twisting your forearms 10deg more, and adjust your shoulder like so”. Suddenly you have a whole inch more reach. Whoa!

And none of those optimizations will help when you’re sparring against a terminator who steamrolls you with 2x your punching rate. Even if all their punches suck.

see also: The pottery class metaphor –> https://excellentjourney.net/2015/03/04/art-fear-the-ceramic...

https://daedtech.com/how-developers-stop-learning-rise-of-th...

And I imagine someone who had a crash hands-on course in plumbing would be better at doing some basic plumbing that someone with a mechanical engineering degree from an elite school. And that's fine if I need some basic plumbing done rather than someone who can model fluid dynamics.

If I need some basic plumbing work done, I'm far more likely to hire even a relatively inexperienced plumber than an MIT mechanical engineer with very little practical experience.

And if I just need a fairly interchangeable entry-level enterprise developer I might well hire a bootcamp grad rather than an MIT EECS major (who will cost more and may have less hands-on experience). The former may not grow in their job as much--or they may--but that's not really my problem if they help address my current need.

Even though I started in computers like this.

https://news.ycombinator.com/item?id=36801868

I “pivoted” to Enterprise Dev - and really restarted a stagnant career - in 2008-2012 (muddled my way through the recession)

Career projection for an enterprise dev is just like a BigTech dev to a smaller degree.

Junior engineer - learning the ropes and learning how to be a real professional developer. They will learn the then current frameworks and learn how to turn requirements into code. A boot camp grad has a leg up here.

Mid level - they can work mostly independently and by now they can take a relatively complicated feature from requirements to production following standard best practices. They may even be able to lead a team of developers working on a feature.

Senior - they can figure out what needs to be done (high ambiguity), lead multiple teams (scope and impact).

(After this I happened to pivot slightly and fell into a role at BigTech in the cloud consulting department.)

Senior+ - they can have an organizational impact and lead corporate technical strategy.

At higher levels, you need to know more about architecture and design. Even in large tech companies, being a good developer and knowing algorithms only distinguishes junior and a mid level developer

College wouldn’t help anyone after they pass the L5 level.

We did that in undergrad, most of my friends and I are leading small teams a few short years after graduation. We found that people without CS degrees can't handle ambiguity, and need a lot of hand holding to get things done, but maybe bootcamp grads are different.

> Senior - they can figure out what needs to be done (high ambiguity), lead multiple teams (scope and impact).

I am doing that, on AWS, one of the most important projects of the org, even though on-paper I don't have a lot of "experience".

I, the cs grad with an MSc, was the only one who could show that what the seniors wanted to do was [fundamentally] impossible - because this is very exotic CS knowledge. I delivered an approach - on time - that actually worked, when all senior engineers said it would take months. I was the only one who found a way out, and it leveraged all of my diverse - and at times exotic - knowledge and background.

> At higher levels, you need to know more about architecture and design. Even in large tech companies, being a good developer and knowing algorithms only distinguishes junior and a mid level developer

Ehhh, when you try to solve NP-Hard (or worse) problems, it is good to have people who can identify reductions and implement the right kind of algorithms. When the complexity (hah!) of the task is so enormous that exact solutions are impossible and you need to involve exotic stuff, neither design nor architecture can compensate.

To design a good system you need proper knowledge of what you are solving, no amount of engineering and architecture can get around a bad solution to a problem you don't understand.

> We did that in undergrad, most of my friends and I are leading small teams a few short years after graduation. We found that people without CS degrees can't handle ambiguity, and need a lot of hand holding to get things done, but maybe bootcamp grads are different.

i don't think that bootcamp grads are different because of the bootcamp but possibly because they already have real world experience from before or were switching fields. they are also often older and more mature, but, most critically i wonder how many places teach how to turn requirements into code. my CS undergrad classes didn't have any of that. it's not "science" to solve peoples problems.

I don't know. I know that where I did my undergraduate and msc, you either learned to do that, or you failed the courses. Fewer than 40% graduated on time where I did my undergrad, and a large portion outright quit in the first half of the first semester in grad school.

I did a year in the army, explosives-eod equiv, and it was a lot more chill than university.

I happen to have access to the internal guidelines for being promoted to a senior developer at AWS. It mostly talks about “scope”,”impact” and “dealing with ambiguity”.

It very possible for a mid level developer to be stronger than a senior technically. But that doesn’t put you on the promotion track.

I had been previously rejected from vacancies because, according to HMs, "I would find the role and responsibilities boring", and the company didn't want to "hire me and on board me, only for me to leave 3 months later".

> It mostly talks about “scope”,”impact” and “dealing with ambiguity”.

Yet, here I am, org-wide impact, and, deep in ambiguity, project-wide scope with no requirements and specs outside "do magic" to make it happen. So much ambiguity that no other team wanted this part of the project, and all managers were worried about us delivering, yet we are the only team ahead of the schedule.

I am not a back-end engineer, I don't know frameworks, I don't "know" cloud or front-end either. What I am good at is finding the right models to use to think about problems and then asking the right questions.

I understood what needed to be done because I understood what we were actually solving, I built the prototypes and showed that it works. The two actual SDE3s we have treat me as an equal and everyone else asks for my opinion and listens to me.

I’m saying that you have to continuously demonstrate and document a history of showing that you can deal with increasing amount of scope, impact, and ambiguity to get promoted or do well on behavioral interviews at your next job.

From your description, the problem was well defined (we want to be able to do $x), you designed the solution. That’s not how “ambiguity” is defined according to the leveling guidelines. Being able to solve “complex” problems without help is L5 level behavior. That’s what you are describing.

> I understood what needed to be done because I understood what we were actually solving, I built the prototypes and showed that it works. The two actual SDE3s we have treat me as an equal and everyone else asks for my opinion and listens to me.

The difference between an L5 and L6 is not subject matter expertise either. There are plenty of areas where I have more and deeper subject matter expertise than L6s or L7s and I’m called in to talk to and advise customers based on my experience.

Have you read the internal definitions of “impact”,”scope”, and “ambiguity” as it pertains to the leveling guidelines? Your manager if he is decent should be able to help you.

I understand your frustration. But “what got you here won’t get you there”. It’s not about technical expertise.

My contact information is in my “About” section. From there we can exchange internal usernames.

And on the other hand if they did go to a good college and ended up at a company without good practices, they will probably end up being “expert beginners”.

Also, I would be very hesitant to hire a software developer who only got experience at BigTech at a startup. They usually don’t have the breadth of experience that you need at an early startup.

> That’s kind of irrelevant.

To be fair, I graduated from a small college in 2001 and I still had a course on JCL. Local industry used it and my program was basically a factory for graduating programmers who could help fix Y2K issues.

I think another friend is still doing mainframe type stuff today.

> This is also false. I was an active fitness instructor for 8 years and my cardio was great and also was a weightlifter. I could teach a two hour master class and go hard without giving out of breath. The first time I decided to do an outdoor 5K on a whim, it took me 40 minutes and I felt like I was going to die. I had to do run specific training.

This is also false. If you look at professional soccer players. They do all sorts of excercises that you never see in a game. I assume lot's of American footplayers also lift weight in training. Yet there are no weights on playing field. Shouldn't they just play games in training?

We had project based learning at my university, it was fine. Not the best, but 2 weeks scoped projects are similar to sprints which is what businesses want. You are not reinventing the wheel in most programming jobs. I just feel it lacked some some theory, but theory is everywhere on the internet if you bother to look.

I went through the curriculum, it was interesting. Are there any books which teach the same?

A blog post should have one and only one reason to edit, meaning that a blog post should have only one job.

“I have a course I am selling based on my theory of learning. Let me give you my thoughts”.

And the title being

“Why I created my course”.

but I see the trends: any time now we will have to pay to watch publicity of this level. I've seen some youtube content which is really just advertisement prefixed by a funny skit.

they imply that my comment is wrong because clearly a blog post can do many things at once: be useful, but also invite the reader to buy more. like drug sellers know and make (ab)use of: "the first one is free"

... now who is going to pay me for this valuable AI training data? [explaining sarcasm over text]

I think this post largely argues against a strawman (which I'm sure some people actually believe).

Seems fairly clear to me that you should (1) do projects that resemble the work you're trying to improve to: a. Build up the basics across all the skills you need b. Uncover gaps

And (2) then practice the skills you actually care to improve outside of the project.

If you really want to try-hard you can spend time actively thinking about how to improve what you're doing and observe other people to learn from them.

People who advocate project-based learning have generally experienced spending a ton of time learning things in theory and then being unprepared for actual work. Maybe address that concern instead of bypassing it with "I don’t want to debate the current way universities do things." To have a nuanced take you have to understand the arguments in favor and against the main options, no?

I don't think people who advocate for project-based learning are advocating for exclusively project-based learning (mostly).

Implying that project-based learning fails is like saying the practice of learning to play whole pieces of music on piano fails (to use the same comparison the author has used.)

Staying on the author's comparison: to learn to play piano, one must practice exercises in isolation (deliberate practice, as Angela Duckworth calls it in "Grit," an amazing book) AND ALSO practice playing whole pieces of music.

The same is true for learning anything. Practice exercises in isolation PLUS project-based learning is the most effective way.

At least in Software you can easily get feedback on your own, i.e. if your program fails to run you have received instant feedback that you can improve on.

It's easy to get focused on objective measurements like how fast you play a scale and forget to ask "but does it sound great?" This is the bigges risk with the grit mindset. With software, it's more subtle but I think it's possible to essentially ask whether a program is lifeless or if it sings. The hard part is that usually you can feel whether a work is good before you can explain it. There is a lot of software that I might liken to some shredders on guitar: it's impressive technically but there is something ineffable missing and it leaves me feeling cold.

It's like Feynman said: “What I cannot create, I do not understand”

What do normal people mean by 'project-based learning'?

The phrase 'project-based learning' is typically used to describe an approach to education that centers around student-led, inquiry-driven projects. In this model, the student starts with a goal or project they aim to achieve and navigates their way towards it. The learning pathway isn't predefined; rather, the student learns as they progress, gaining knowledge on a need-to-know basis.

Conversely, the Nand2Tetris course, while project-oriented, adopts an approach akin to a traditional curriculum. The path is meticulously charted out from the outset. You begin with the most fundamental concepts (e.g., understanding a logic gate) and progressively construct more complex structures, culminating in a fully operational system. The sequence of learning and the projects are predefined by the course structure, not dictated by the student's initiative or inquiry. Thus, while both involve project work, the degree of student autonomy and the nature of inquiry diverge significantly between traditional project-based learning and Nand2Tetris.

I prefer the Nand2Tetris approach. I suspect that 100x as many people could complete Nand2Tetris, than could build tetris from scratch using a PBL approach, in some reasonable timeframe. Maybe ChatGPT makes this less true than it once was, because you're less likely to get totally stumped/blocked.

I've said this myself for many years.

For some reason I prefer to quote Feynman for it.

Learning on my own meant I avoided the trap of only learning part of how to complete the project (because I had to do all the parts) but I only learnt enough to complete the project I was working on. I didn't learn any data structures or algorithms fundamentals until I started playing with C (in fact, my algorithms knowledge is still rubbish, and I've never implemented a hash map, I just use tries), and there's so much I pick up on just from listening to my CS-qualified colleagues in the office.

To make guided project-based learning achieve this, the projects have to be so finely structured that they end up forming a traditional curriculum anyway.

Which is itself an important skill. I was working at a small startup while in undergrad. During the day I was being taught theory and 'correctness', while at night I was coding with my boss trying to get features built so the client would give us another check to stay in business. Sometimes you just have to get things done - "Real artists ship." - SJ

If you need to write an associative data structure, write a trie. There are too many pitfalls when implementing a hash-table. e.g. It's really hard to accidentally write a trie with linear lookup performance or quadratic space usage, but it's really easy to accidentally write a hash-table that does one of those.

A well implemented hash-table will beat a well-implemented trie for pretty much all unordered operations, but a quick and dirty trie will usually be far more robust to corner cases than a quick and dirty hash-table.

As for A&D, there are a couple of data structures that are interesting and generally applicable. But I found that there are diminishing returns here. If you know a reasonable set of them, you _can_ stop there and pick up new ones when you actually need them for something.

That's how I messed up my <big-company>-Luxembourg-office interview many years ago. At least, that's one way, out of the possibly many ways I messed up.

The interviewer asked what was in retrospect a trivial question whose obvious and straightforward solution involved using a hash table, but me being clever proposed a ridiculous solution involving tries.

Didn't get the job :)

I spent my first 12 years doing at least some C on mainframes, x86 PCs and later maintaining a proprietary development stack written in C for Windows CE devices.

I think in my entire career, the only algorithmic complex things I had to do were some recursive programming and the “Shunting Yard” algorithm.

I did some real hairy C and assembly language optimizations back in the day that I haven’t needed in over a decade. But nothing that was taught in algorithms classes.

I would venture to say that a great majority of your developers doing enterprise CRUD development - which most are - would need to know any algorithms to get their job done.

The value in doing projects is learning to do... projects - not a trivial thing, actually.

By working on a networking project, that's how. This article is a stupid joke.

My own education included learning fundamentals, individual projects, and group projects. I find a mix is the best. Do the fundamentals. Practice them in individual projects while also learning how to teach yourself things that weren't directly taught, which is an important skill set. Finally, practice these skills again in group projects to learn cooperation in software development and how to scale beyond single individual solutions. Source control is a skill you can learn the fundamentals and practice by yourself, but working in a group project makes some of the benefits immediately visible to many students.

You have to match the intended learning with the right environment, there is no single solution.

Is the goal to learn music theory, or is it to learn to play an instrument? If I want to become a concert pianist, knowing music theory will help, but the only way to get good is to practice.

The problem with computer science education is it's a bunch of music theorists teaching others how to play the piano. Doing projects is the only way to practice programming. You're not going to learn how to program from these people because most of them have no significant experience building real software.

In what universe does the author live in? Universities teach you standard industrial languages like C, Java, Python and C++. The only course that had a functional programming language at my university has always been optional and is not available anymore.

Also, project based learning is practiced in the form of assignments. Operating systems homework consists of writing your own OS primitives. You are supposed to write a simple memory allocator, a simple thread scheduler and so on.

Also for reference my Co. paid for a training course from this guy on Hoare Logic and I found it to be a complete waste of time as a professional developer and not a grad student in theoretical CS.

A friend of my wife's husband is a boot camp grad, he can whip out a buzzword compliant web app, but is missing some foundational understanding of what's really happening under the covers. When his aws account started racking up charges like crazy, helping the poor guy debug what he'd built meant working back from his project based understanding of what he'd built meant filling in a lot of blanks for him so he could connect the dots.

If you're a nerd, you probably already know why the boring stuff is important because you've already aware of the domain and you can connect back. Just like the author, who also ONLY in hindsight started to realize that the boring stuff was important, doesn't mean everyone else will magically realize that as well. You need to make an explicit effort for them to do that, for example, through projects they can connect to.

A more scientific version of the claims here can be found e.g. in the paper "Why Minimal Guidance During Instruction Does Not Work: An Analysis of the Failure of Constructivist, Discovery, Problem-Based, Experiential, and Inquiry-Based Teaching" available at [1] (paywalled, other sources may be available) and a brief summary of the state of research in the field is available at [2] for free, with links to various relevant papers.

Note that all of these show that discovery learning (which more or less overlaps with project-based learning unless the project is very tightly guided) is ineffective for learning new things, but this is often rounded off to "discovery learning is ineffective". As far as I know, the research does not show that projects are necessarily bad to practice and deepen knowledge that you've already built up.

[1] https://www.tandfonline.com/doi/abs/10.1207/s15326985ep4102_... [2] https://debunker.club/2015/06/05/discovery-learning-is-not-e...

The Practice is not the Performance: Why project-based learning fails - https://news.ycombinator.com/item?id=16451797 - Feb 2018 (128 comments)

- learning a certain programming language - learning to programm

The first one can only be learned through practice.

The second one needs context and studying specific narrowly constrained subjects in isolation and, at times, only on a purely theoretical level (mathematics).

A better summary would be “Project-based learning does teach you things, but often ineffectively because you’re also made to focus on other concepts besides the one you were initially setting out to learn. Thus the best approach to learning needs to be targeted and customized with the help of a personal coach (and here’s my course).”