Students by definition are not experienced engineers. They’re in a given class to learn the topic for that class, and hopefully that class with be a challenging program of learning. In CS often the fact they’re even working in Java is incidental, they’re not even there to learn Java, but generalisable CS concepts.
I’ve got no problem teaching students practical software engineering skills, sure, that can be very valuable. It should be on a course on that topic though.
That's not what I said at all. Inexperienced in general is fine. I benefited from mentorship earlier in my career, and I'm happy to pay it forward.
Inexperienced with my specific tooling is a weird point to make, because it directly contradicts my point. If you teach people how things work: the underlying computer, OS, system libraries, and teach people the nuts and bolts of how to do their jobs: version control, the command line, filesystems, etc., then I especially don't care if they've used my specific tooling before, because they probably have enough foundational and background knowledge to be able to pick up different tooling and languages without too much trouble.
The people who are just taught to open an IDE, click "new project", and never leave the IDE, are the kinds of people that I expect will have trouble if they join my team and we're using different tooling than they're used to.
"What does this have to do with cooking?"
"Well, you want to use a knife to cut your vegetables don't you? How on earth do you expect to get a knife to cut your vegetables if you don't mine for iron slag, refine it, build a forge, learn blacksmithing, make thousands of inferior and useless knives until by trial and error you finally have a knife you can cut vegetables with!"
"Ok, so once that is done then I can be a cook, right?"
"What? are you a fucking moron? Look at this asshole who thinks he can be a chef if he knows how to make a knife! What an idiot! You need a pot and a pan and a kitchen, but to get a kitchen you need a house and to get a house you have to buy the land and then to get the food you have to learn agriculture and animal husbandry, woodworking, stone-masonry, how to quarry, political intrigue, bartering, build a working economy you and 7 other people can all agree on using..."
It isn't that difficult. All I really needed was a problem and a line on the tools I needed to solve them. All the other stuff may make me competent should I need to rebuild the world's technology stack from the ground up a.k.a Dr. Stone but it never earned me a dime of income of served the most basic of purposes in attempting to dissuade me from a computer career.
if, while, and other programming concepts? I'd agree on that.
But the article suggests learning about files, file formats and other low level stuff.
So maybe they should first learn how a filesystem works, how it keeps internal consistency, and how the bytes are mapped into some physical storage. That's pretty fundamental too, right?
What we have here are "leaky abstractions"[1]. If the abstraction an IDE provides is not good enough that students can work with it without knowing about the lower layer, then the abstraction is leaky. And that is the problem. Not "should I teach them with an IDE or without".
[1]: https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-a...
Do you suggest teachers fix Eclipse so it no longer has leaky abstractions rather than just teach students how to work in a modern file system?
> They are the kind of programmers who have a very narrow range of abilities, and whenever they see a problem outside those abilities, they get completely lost.
How does one follow the other? How does not learninging unnecessary skills hinders ability to solve new problems? If skill is really needed later one person from the team can learn it and share most important bits of knowledge. If skill is not needed now why learn it? YAGNI can also be applied when learning things.
I find that not understanding how compilers works or how to use them in low level tasks is minor problem when developing. I never met developer who had problem like that. Much bigger problem during developing is not listening to and understanding your users and IDE will not help you with that. This is much better skill to learn than compiler CLI.
I disagree here. Life is not so easy that you can ignore many problems. If you don't know certain skills you don't know the best way to solve it and it can lead to various problem.
Its like saying why learn chemistry, advance math, physics in high school when you might not even use them other than few simple formula and if you need them just learn it from team. I don't think this is how real world works.
the point of learning all that in high school is not to learn about these things specifically, just to teach you how to learn things fast so that you can easily learn what's useful when you work.
No one cares about what you learned in chemistry class at 15 y.o, it's all approximations if not outright wrong stuff sometimes and it does not matter in the slightest.
A great driver understands how engines work. A great wood carpenter understands about different kinds of Timbers and their properties.
I don't think that's true. I think learning things that are related to your work will almost always make you better at your work, even if you don't use that specific knowledge directly. Human brains are big pattern matching machines, and the more data you can feed it, the better it will be at looking at problems and truly understanding them.
> I find that not understanding how compilers works or how to use them in low level tasks is minor problem when developing.
I'm not saying that you need to understand enough to build your own toy compiler (though that can also be very useful in understanding how to write better programs). But at least understanding it from a basic level, like "javac takes in my source code, turns it into some kind of machine-readable intermediate representation, does optimizations, and outputs bytecode" is something that I expect every Java programmer to know.
The vast, VAST majority of programming is of the type OP described. It ugly and has warts, but is good enough to deliver business value. I’ve seen it first hand.
The truth is that developers working on projects like that outnumber everyone else probably 10-1. See https://www.hanselman.com/blog/dark-matter-developers-the-un...
Sure, maybe they can still get things done without that knowledge, and it'll work, but that's not really the point.
Okay but what matters is not who you want or do not want to work with, but "can it make a business that works". That's the only metric.
The first job I was in the owner did "code" pretty much everything on a visual programming language (Max/MSP). Was it pretty ? No. Did it allow him to start a business and sell things ? Definitely, and that's the only thing that matters
With this myopic attitude you'll get your business up and off the ground fast. Good job.
Then you will be mercilessly hacked.
Once you rename your startup to avoid the negative publicity, you'll hit a performance wall.
You'll lose customer data (and the associated customers) while you try to figure out what the four letters in ACID actually mean.
AWS will take 80% of your profits.
A different company will have taken their time, done it properly, and eat your lunch. They'll take the customers that lost data, as well as the customers that couldn't stand your slow-ass website.
Then they will mercilessly undercut you, because they're not scaling to infinity to compensate for an O(n^3) algorithm being used to scan database tables in their entirety by Mr I Know How to Bang Out Code.
Optimizing is a different item, it reduces costs... More profit, better costs for customers, potentially undercut other companies with prices that are not feasible / offer more features.
Now they are niche when these issues do matter...
One wants to get things done to the exclusion of all else. Possibly trapping you into a corner if you need to ever scale.
And the other wants to “do it the right way from day one“. An undertaking that would cost more than a small business could ever hope to afford or slowing you down giving rivals time to catch up.
Doing it right, to me, means hiring people who can adapt to changing conditions and needs, and who can make (or help you make) the right trade offs when you have to balance faster time-to-market (which can involve cutting corners) against avoiding technical debt.
The team that lives inside IntelliJ and can't do anything outside it is not going to do that for you.
Well, we’re only discussing a specific dimension of software development here. In reality there are a whole bunch of things not even related to software that will cause problems.
My thought when people only have one solution to a problem: If you can only think of one solution, how do you know it's not the worst one?
I don't have an opinion where these people develop these attitudes/skills
And what happens after you get that business running and bringing in some revenue, but you need to start tackling harder problems in order to keep your current customers happy and attract new customers? You're stuck with a bunch of developers poorly suited to solving those problems, and a bunch of infrastructure that wasn't designed with this sort of feature expansion in mind.
So you hire some new people who have to rewrite a bunch of things, or who have to spend months or quarters untangling the mess. You could even miss your market opportunity. Even if you don't, you've still wasted a lot of time and money.
What I want doesn't matter any more than what you want regarding this. What matters is what the society as a whole wants, and the current situation is in big part the manifestation of it.
> And what happens after you get that business running and bringing in some revenue, but you need to start tackling harder problems in order to keep your current customers happy and attract new customers? You're stuck with a bunch of developers poorly suited to solving those problems, and a bunch of infrastructure that wasn't designed with this sort of feature expansion in mind.
you're assuming that you would even have gotten the first customers if things were "done right". My experience seeing entire businesses held by 1kloc of "academic" (I'm not saying this as a compliment) python scripts with 20% of it being globals succeeding says otherwise.
For how long? Until it needs a rewrite because it’s completely unmanageable. Yes I know, the rewrite cycle is part of the business now, but I don’t think it’s necessary. We can do better.
It's not lame, it's fine. It is just fine, and usually better, to teach basic concepts using a simple tool - even if it is not fashionable or up-to-date.
Agree that teaching old techniques can be useful in the cases where the current techniques build on what came before.
Undergrad CS students aren't learning software development first and foremost. They're learning logic and math, data structures and algorithms. They need a low friction environment so they can learn the academic stuff without wasting their (or their TA's) time.
So while I agree that many "real world" programming jobs require dealing with the kind of boring minutia that IDEs try to abstract, this stuff shouldn't necessarily be a prerequisite for students on a CS track. There's plenty of time for the real world later :)
Interesting. In other fields, like surgery, narrow specialization is desirable.
And many developers I know do end up specializing in particular sub-fields (ML, databases, whatever), but they already have a wide breadth of knowledge and experience to serve as a foundation underneath that. In contrast, I also know some developers who didn't take that route, and jumped into specialization early, and who are completely useless at productionizing their work.
IDEs can be great, but in the hands of someone just learning they encourage a cargo cult style that becomes a barrier to actually knowing what you're doing. I've had to work with people who are still stuck cargo culting thing 15+ years into their careers. Not fun.
Relatedly, they can also assist people who to get just enough success (in the cargo cult sense) to get a degree, when they would be much better off in a different field. It does them (and their future team mates) a disservice.
The thing is, they are the ones least likely to cause difficult to debug build issues due to "very clever" features and using the latest version features of build tools in the first place.
Regardless, I don't think "I don't want knowledgeable people because they might write something 'too clever' that causes problems in the future" is a particularly winning strategy. You're basically saying you want dumb people because they will never try to be too smart for their own good.
For example, recently I spent more time than I'd like finding out that we linked two incompatible versions of a library. All the visible dependencies were correct, but at some point someone bundled an old version in a fat jar and that got included transitively via another dependency. If you understand the details you know why you don't distribute libraries as fat jars. But if you're just following some guide it's easier to fat jar it than correctly specify your dependency tree.
If your education was really effective you recognize this is just the static/dynamic linking problem again in new clothes.
> full teams can and have built huge java projects just by using the intellij project wizard and maybe a tiny bit of Gradle from stack overflow.
I would not ever want to work with anyone from those types of teams. They are the kind of programmers who have a very narrow range of abilities, and whenever they see a problem outside those abilities, they get completely lost.
> But this is stuff that should come in later classes, particularly for students who are interested in those details. Not everyone needs to know it.
Yes, they do. They absolutely do. There seems to be this mindset that's starting to infect software development that pushes the idea that people can be good at programming computers without actually knowing anything about how those computers work. I just do not understand how anyone could seriously believe that. My experience over the past 20+ years tells me that people who avoid learning about these topics are generally just not good at their jobs, or at best can do a decent job of things, but then completely freeze when they encounter something outside of their narrow comfort zone.
> In fact my experience is that some colleges have the exact opposite problem: they teach students old tools and techniques
That's lame, but has nothing to do with the point you're trying to make.