The content taught here is the highest payout thing you can learn, in my opinion. Certainly more important than actually writing code or learning algos.
What this content covers should unlock iteration speed, which is the single greatest lever in learning and growing faster (on a computer). Thus it gives you more cycles to go back to improving your code, experimenting with algos, etc. Probably also highly correlated with upwards mobility in the software job market.
Great seeing this under a common umbrella I can hand to students and new grads.
I went to Purdue over a decade ago and we had a 1 credit hour lab that taught this stuff. Unix command line, git, bash, and finally some python.
Like you said, it's been a complete game changer. I feel these skills continue to differentiate me from my peers in terms of how I can attack arbitrary problems bravely to this day.
They still teach this stuff at Purdue. I graduated a few years ago and by far the most important class was about how unix works, moving around the command line and finally introducing us to vim
<3 Me and a few others created this course in 2014. Glad you found it useful! I got so much joy out of the content creating the content for the lectures and labs.
I sat with a talented developer whilst we wrestled with a threading issue this past week. I wanted to inspect the value of a variable within a method during execution and asked him to set a breakpoint. He didn't know how to do that in the IDE, which he'd been using for over a year. Debugging is indeed a skill which needs learning.
Hi! I'm that person! Senior engineer, decade of experience. I've used debuggers in the past, both for running code and looking at core dumps, but I really don't find them to be cost effective for the vast majority of problems. Just write a print statement! So when I switched from C to python and go a couple jobs ago, I never bothered learning how to use the debuggers for those languages. I don't miss them.
Or assume that python debuggers aren't as nice to use, or that python does not lend itself to inspecting weird memory and pointer dereferences, or a bunch of other possibilities.
I am also this person. I'm a systems programmer (kernel and systems software, often in C, C++, golang, bit of rust, etc)
What I find is that if my code isn't working, I stop what I'm doing. I look at it. I think really hard, I add some print statements and asserts to verify some assumptions, and I iterate a small handful of times to find my faulty assumption and fix it. Many, many times during the 'think hard' and look at the code part, I can fix the bug without any iterations.
This almost always works if I really understand what I'm doing and I'm being thoughtful.
Sometimes though, I don't know what the hell is going on and I'm in deep waters. In those cases I might use a debugger, but I often feel like I've failed. I almost never use them. When I helped undergrads with debuggers it often felt like their time would be more productively spent reasoning about their code instead of watching it.
Your list of programming languages excluded Java. Please ignore this reply if Java is included.
Are you aware of the amazing Java debugger feature of "Drop to Frame"? Combined with "hot-injection" (compile new code, then inject into current debug'd JVM), it is crazy and amazing. (I love C#, but the hot-injection feature is much worse than Java -- more than 50% of the time, C# compiler rejects my hot-injection, but about 80% of the time, JVM accepts my hot-injection.) When working on source code where it is very difficult to acquire data for the algorithm, having the ability to inspect in a debugger, make minor changes the the algorithm, then re-compile, inject new class/method defs, the drop to frame, the re-exec the same code in the same debug session is incredibly powerful.
Yes, that sounds pretty cool and it doesn't take a lot of imagination to see the utility in this. I've done a lot work on lower level software, often enough on platforms where the debuggers are tough to get working well anyway.
The plus side of less capable tooling is it tends to limit how complex software can be--the pain is just too noticeable. I haven't liked java in the past because it seems very difficult without the tooling and I never had to do enough java to learn that stuff. Java's tooling does seem quite excellent once it is mastered.
This part: "I haven't liked java in the past because it seems very difficult without the tooling"
If you are a low level programmer, I understand your sentiment. A piece of advice, when you need to use Java (or other JVM languages), just submit to all the bloat -- use an IDE, like IntelliJ, that needs 4GB+ of RAM. The increase in programmer productivity is a wild ride coming from embedded and kernel programming. (The same can be said for C#.)
I think there's a sort of horseshoe effect where both beginners and some experienced programmers tend to use print statements a lot, only differently.
When you're extremely "fluent" in programming code and good at mentally modelling code state, understanding exactly what the code does by looking at it, stepping through it doesn't typically add all that much.
While I do use a debugger sometimes, I'll more often form a hypothesis by just looking at the code, and test it with a print statement. Using a debugger is much too slow.
This varies, but in a lot of environments, using a debugger is much _faster_ than adding a print statement and recompiling (then removing the print statement). Especially when you're trying to look at a complex object/structure/etc where you can't easily print everything.
I think there is a bit of a paradox, debugging can seem heavy, but then when you’ve added enough print statements you’ve spent more time and added more things to clean up than if you had just taken the time to debug, well, you should have debugged. But you don’t know until you know. This seems to also appear with the “it would’ve been faster to not try to automate/code a fuller solution” than address whatever you were doing.
In what way is using a debugger "slow"? I find that it speeds up iteration time because if my print statements aren't illustrative I have to add new ones and restart, whereas if I'm already sitting in the debugger when my hypothesis is wrong, I can just keep looking elsewhere.
I find I use the stepping debugger less and less as I get more experienced.
Early on it was a godsend. Start program, hit breakpoint, look at values, step a few lines, see values, make conclusions.
Now I rely on print statements. Most of all though, I just don't write code that requires stepping. If it panics it tells me where and looking at it will remind me I forgot some obvious thing. If it gives the wrong answer I place some print statements or asserts to verify assumptions.
Over time I've also created less and less state in my programs. I don't have a zillion variables anymore, intricately dependent on each other. Less spaghetti, more just a bunch of straight tubes or an assembly line.
I think it's possible that over the years I hit problems that couldn't easily be stepped. They got so complicated that even stepping the code didn't help much, it would take ages to really understand. So later programs got simpler, somehow.
I find I use the stepping debugger more and more as I get more experienced. Watching the live control flow and state changes allows me to notice latent defects and fix them before they ever cause actual problems. Developers ought to step through every line of course that they write.
Most of what I worked with code wise growing up was either very niche or setup in such a way that debuggers weren't an option so I never really used them much either. I don't understand their appeal when print statements can give you more context to debug with anyway. I'm definitely no senior but I'm used to solving things the "hard way" as one developer told me. He wondered how I could even work because of how "bad" my tools were but I didn't know any better being self taught and with certain software it's just not compatible with the tools he mentioned.
It depends what you're doing. Sometimes inserting a print and capturing state works. Sometimes you're not sure what you need to capture, or it's going to take a few iterations. That's where pdb / breakpoint() / more interactive debuggers can be very helpful.
As an untalented developer, I used to make heavy use of debuggers, and knew them well. Currently, as a still untalented developer, I've fallen out of the habit of using them and don't know how to for my current toolchain.
Neither situation was at all related to my talent (or lack thereof).
You don’t need breakpoints all the time though. If you’re familiar with the code (or just “talented”), you might have an intuition for what the problem is and it’s faster to just think through it (and maybe write a few quick prints) instead of interrupting your train of thought setting breakpoints, clicking continue, waiting for the IDE to freaking load the debugging session (cough Visual Studio), rerunning the test, etc.
Besides, every IDE has a different way to debug, so they might just not be familiar with the interface. I can’t tell you exactly how to debug in VSCode even though I’ve used it the most. I’ve had to run a debugger only a handful of times in the past couple of years and it’s always for codebases that are more tangled (e.g. .NET where there’s interfaces everywhere).
+1. i just used a debugger today at my work for the first time in 4 years by coincidence. normally i just throw a couple prints and rerun the test and today i was reminded why. takes like 8 minutes to run the test in debug mode. lots of useful info in there but usually i can guess where the error is without it.
it was indeed good at pinpointing the sigsegv though.
There is a world of programming where debuggers don't serve much purpose. Individual microservices are usually trivial, but push complexity into the interactions between services. Debuggers are not much use there; distributed tracing is more relevant. Functional programming, which is a growing part of the industry, really emphasizes code you can easily reason about. That's arguably the whole point of functional programming. Debuggers don't get much use there either.
I'm not a talented developer but I did spend my day on an F# piece of code that builds a databale based on a record type using reflection (and eventually realized it was going to need to be recursive) and I probably would've just quit if I wasn't allowed to use a debugger.
Now maybe if I was better that wouldn't be the case, but even the cleanest "wish i thought of that" functional code i've seen still looks like it'd be easier to fail fast using a debugger with.
In fairness though, I will admit I use the debugger a lot less when i'm not screwing with reflection on generic types or whatever because runtime errors just happen a lot less in functional styles. Usually if it compiles, it runs, because the compiler can sanity check the code better than you can.
Perhaps if you already know C#, otherwise I doubt it. Of course it depends on ones prior experience, but F# is functional but still requires you to understand OO in order to interact with the framework.
I think it's harder if you already know C# or some other OO language. I really think it would be easier, or about the same, to teach a raw beginner the basics of F# vs C#.
The only reason F# winds up feeling harder isn't so much how F# works, but simply because the entire dotnet environment was built for C# first, so you do need to know how to handle the C# style. I do think that if you could just pick one and then suddenly have every library support it's styles, F# would probably be easier overall because it's just got a lot of nice features built in that make updating your code so much easier.
F# has two ways to invoke functions, ‘f a b’ and ‘f(a,b)’. You need to know when to use what. There is no way this is simpler to beginners compared to having one consistent way.
C# is not a simple language, but F# has basically all the complexity of C# with OCaml on top.
Either C# or OCaml would be simpler to learn, although the combination is powerful.
I don't know F# but the reference only mentions the `f a b` syntax.[1]
`f(a, b)` looks like a call to a function that takes a single tuple as its argument. So I would expect `f` to have the type signature `A * B -> C` instead of `A -> B -> C`. Is my intuition wrong? If it is, then what does F# use the parenthetical syntax for?
Methods from the .net framework and other libraries are called with a tuple of argument, since they are not compatible with the native F# was of calling functions.
This to me is a pretty simple thing to explain and deal with.
F# enforcing a lot of good practice code style stuff (order matters for example pisses off long time devs who already have styles, but prevents SOOOO much stupid bs from beginners) and basically eliminates runtime/chasing variable state errors completely so long as you can stay within style. Yes it'd be nicer if there was only one way to invoke functions but if i had to take a tradeoff I think it's a pretty easy one.
It is an issue that yes, like your example, you're often stuck ALSO learning OO because "oh you want to use X library, well that's OO so...", and even then you can isolate your mutable/OO areas really well, but this is more of an issue with it being an second fiddle language. If F# got F# specific libraries for all the C# stuff out there tomorrow I think it'd take off and most people would never look back.
If we're talking basic business logic/beginner programmer stuff, yeah I think F# offers a lot of stuff that makes it flat out easier to use. And if you want to point out complex issues, I feel the biggest one is that something that's intuitively much easier to understand in OO (create a variable/object, populate it on each iteration of a loop depending on logic), can feel daunting as hell in F# (fold).
Knowing a good bit of Rust helped me considerably, due to the commonalities of being expression-based, pattern matching and sum-types. F# almost feels like a more functional and GC'd Rust.
F# is heavily based on OCaml and Rust was heavily inspired by the ML family of languages, and I've often heard it described as an ML without GC and with memory management and a C++ style syntax.
This was me - my first .net language was F# (although I'd dabbled a tiny bit in C#); it was hard to learn the .net standard library as well as trying to learn functional idioms...
I don't agree, because learning F# is essentially learning two very different languages at the same time: first OCaml from which it was initially an implementation, then C# for all the object/CLR layer.
It's easy for people with functional programming knowledge, or who had OCaml as their first programming experience like I did at university, but for people without those exposures I can understand the difficulty.
I’ve encountered the same thing. I’m a terrible programmer but find f# way clearer than most C#/java. But I work with tons of great developers who would rather cut off their finger than learn f#, it bothers me because it exposes some fundamental difference between us I dont like to believe exists.
Not a humblebrag. I’ve noticed I struggle with tracking lots of variables and states compared to many fellow developers. I’ve sort of tried to turn this weakness into a strength, by making code simpler, but sometimes I make it too terse because I like code golfing.
It's 100% the latter. I get "ok we don't want to mix codebases" and that's fine, but if you can code in C# you can probably get up and running in F# in a week, maybe a month if you struggle with some of the concepts.
One major issue I do see coming from the C# side is "well how do I do this then?!", which often the answer is "you don't, because you don't need to" or "well what if it's more performant to do it mutably!" well then thankfully F# can absolutely do that.
If you keep an open mind it's really a very clean and simple language, but in an age where half of development is importing 8 well known libraries, not being the main supported language is a major weakness.
I normally write C++, but I've also written in Rust, Python, Ruby and bunch of other languages. I've never had trouble with a programming language until Haskell, and had to accept that I'm just probably just not smart enough to do it.
However, I wrote my first thing a port of a small C# tool of a couple hundred lines, to F# in about an hour. It's been about a week now, and things are considerably smoothing out.
To be considered niche, the F# tooling has been great. Also, having the .NET libraries available adds a lot of built-in capability.
It's really not. I'm quite terrible from any industry perspective.
F# isn't hard, it's just different. Hell in many ways i'd argue it's much much easier once you get used to it. It doesn't have the support C# does so often you're stuck with a library that WILL work but doesn't have documentation for doing it in F#, and that can lead to struggles, but that's not really a sign of being a good coder.
Most dotnet developers could probably code circles around me in F# if they knew it existed/gave it a chance.
Personally I stuck with it because it had the low code look of python with strong typing. It took a bit to wrap my head around some functional stuff (basically map/iter = foreach and if you want to update something on each loop you probably want a fold, or more likely a built in function), but once I got over that hurdle it was pretty smooth sailing.
The irony is that by far the hardest part is the library thing, which your average dotnet dev would handle WAAAAY better than me.
Agreed, when I commented earlier I was also thinking about mentioning something similar with regards to classes of bugs due to interactions between systems.
Unless you have a setup where you can easily run one system with a debugger attached while connecting it to everything else, you’re basically restricted to running a debugger for bugs that can be reproduced locally.
The distributed tracing point makes sense, but I think debuggers are still quite useful for functional code. Though maybe less commonly needed than just the repl.
Concluding that using printf to debug is superior to using a debugger would be a mistake!
I’ve been programming in C for nearly 20 years and primarily used printf for debugging for the first 12-15 years, and have used debuggers more and more. I use Emacs, and its gud mode is so nicely integrated into everything that using gdb is truly much, much faster than the alternative. I don’t use print debugging at all anymore.
It takes less time and cognitive overhead to just stop the program on the same line you would have inserted your printf, but you can now inspect the entire program state.
Obviously I’m not saying anything revelatory if you use an IDE on a regular basis… I guess this comment is for the folks who eschew IDEs.
This works well mostly and I use this. I usually implement a logging system where I can enable/disable individual components but use a debugger to examine functions which are not behaving as intended.. or core dumps. Usually in connection with an unit test that fails or started failing caused by my changes to the codebase that I'm working on.
Logging alone is fine, but it can often be difficult not to drown in information.
I do embedded programming in C mostly.
I didn't use debuggers since switched from C to Rust. By the way I switched from emacs to VSCode and I do not know how to debug here. I never used debugger with lisp. Debugging is a language dependent technique.
Meh. I use the right tool for the job, and most of the time, a simple print statement put in the right place beats any debugger. Certainly the debugger has helped me in the past, but maybe one or two times only. Besides, putting a print statement costs nothing, and one knows exactly how to do so. Debuggers vary wildly: terminal, IDEs, etc.
I don't usually use breakpoints in part because I use neovim and in part because... I seldom truly need them. Who are these people and what are these problems where stepping through method calls etc is actually necessary? I find it hard to believe. I've been successfully programming and problem solving this way for over 15 years.
I haven’t been shocked that fellow engineers don’t know how to use a debugger for at least ten years. Most jobs in the industry can be done adequately without getting into tools that low level.
Maybe rare but you may be very skilled at understanding structure and finding solution but knowing nothing about tools. As long as you're either one of them.
Well. a big part is curiosity, and apparently he isn’t curious not interested in what his tools do.
I used to read every help file on windows / visual c++, the FreeBSD manual, plowed through the file system and tested this it. Just because I was curious
Nah, debuggers are useful but hardly necessary to do your job well. People have been productive at programming long before they had many useful tools at all, the most important thing will always be how well you understand the program you are writing and not how you use your tools.
It's interesting. I mainly use functional-first languages, and I rarely need breakpoints. Programming is much more compositional with certain languages.
I agree you should know how to use a debugger, however will also note that some companies mandate use of a specific IDE (or heavily encourage).
I have seen devs scoff at the thought of print debugging, but I recall that in systems programming there are many times you can’t use a debugger or need to rely on other tool.
I’d rather schools teach the concept of step debugging vs runtime debugging. Teach students to try to understand the code, make hypotheses, and verify them.
I have seen some people use a debugger solely because they only know how to step debug. Meaning they start from main or another entry point and step through every line of code.
My point being that, you can’t judge a developer by if they use print statements or a debugger. Judge them by the methodology of how they debug.
> I have seen devs scoff at the thought of print debugging
Next time they do, ask them to recommend a better method of debugging that works across generally all languages, compilers, IDEs, and platforms with next to zero configuration.
The key thing about print debugging for me, that I've never seen a typical debugger handle well, is what I like to think of as "temporal debugging":
Taking a program trace from the print debug statements, grepping through it repeatedly to filter down to certain events of interest, looking at the interleaving of those events, and figuring out the order that things happened in to cause it to go off the rails. That sort of thing. (To be fair, time-travel debuggers can start to get at this, but those are pretty uncommon. Traces, as you say, work almost everywhere.)
Or better yet, compare the traces between working and non-working runs to see how they differ. I've looked at diffs of traces this way before. (Sometimes I'll first use a small script to renumber pointers in traces by order of appearance.)
I've also used this sort of strategy before for debugging rare threading or other non-deterministic issues. Have the shell run the program in a loop, saving each run's trace and results to a different file, go off and get lunch, come back and see if anything failed. Then look to see if any of the runs failed and look for the structural differences between the working and non-working traces.
I can't imagine sitting and stepping through in a debugger 100+ times in the hopes that maybe this time, it will be the run that's just different enough to trigger the bug and that the debugger itself won't prevent the issue from manifesting. Not to mention, trying to remember the steps from all the good runs and spotting where the bad run goes bad before you've stepped to far. No thank you.
I think people really underestimate print debugging. Debuggers are fast and easy for simple bugs, sure, but there's powerful stuff that you can only really do with printed traces.
> I can't imagine sitting and stepping through in a debugger 100+ times in the hopes that maybe this time, it will be the run that's just different enough to trigger the bug
Isn’t that where things like breakpoint conditions, data breakpoints (“break whenever X value/field changes”), and dependent breakpoints, work pretty dang well? You just set up the appropriate situation and let it run until it breaks
Those help in some situations, sure. I'm talking about the non-deterministic things like unusual race conditions, where the problem only manifests rarely. Conditional breakpoints could certainly help you detect when things have broken, but you'll often be well downstream of the root cause by then. Though I suppose tracepoints could help with that. So I'll concede that you could probably do something similar in a powerful enough debugger with sufficient effort.
But one thing that I have found helpful in the past has been aggregating the information from the traces across runs. Comparing good with good and bad with bad to classify the commonalities, and then compare good with bad to see how they differ.
Yeah. Also for any kind of race condition a debugger is usually pretty useless. Also most memory corruption problems. The debugger has a place but so does printf debugging.
> I agree you should know how to use a debugger, however will also note that some companies mandate use of a specific IDE (or heavily encourage).
The debuggers in most popular IDEs (IntelliJ IDEA/any JetBrains IDE, Visual Studio, VSCode, Eclipse) work the same way. You set breakpoints (typically by clicking somewhere around the line number), step into and out of functions, and look at the memory state. If you learned how debugging works in IDE X, you can easily switch to IDE Y without having to learn much.
The biggest hurdle for beginners when using built-in IDE debuggers in my experience is the requirement to set up the debug run configuration to properly execute their program. Even though this amounts essentially to "how do you run the program on the command line? Write that in the IDE configurator", newbies don't know how to run the program from the command line (and can't debug any startup errors they might get), so can't properly set up the debugger in their IDE, and revert back to print debugging everything.
> I have seen devs scoff at the thought of print debugging, but I recall that in systems programming there are many times you can’t use a debugger or need to rely on other tool.
Not just systems programming, but fixing issues in scaled production systems as well. Have fun attaching a debugger to the process that got killed twenty minutes ago when the spot instance it was running on got reclaimed. If you don't collect telemetry, you're blind. Debuggers are a luxury that you get to enjoy for issues you have before you ship.
I have this feeling that the kids who appear better at uni are the ones who happened to pick up certain not-quite-programming skills before they started. Basics of networking, how installation of programs happens, how to use the command line, that kind of thing.
I looked over her shoulder as my wife was doing a CS degree, and I realised there's a bunch of these little things that make life a lot easier if you know them.
In my class 5 years ago, the differentiating factor was whether the kids who grew up online or not. Students like myself or my roommate who’d spent their formative years in front of a computer, not because they had to, but because it seemed like the thing to do at the time. I never realized how much I was learning during the time I spent scripting RuneScape bots and writing toy “viruses”, I did it because it was more fun.
I got my start writing RuneScape bots too! It's such a shame because speaking to the younger generation (I call them the TikTok generation) they don't have the same experience with the web the way we did. For them, the internet is closed off, a few big websites like Facebook, youtube, twitter. They use their phones primarily to access the web, and a laptop is exclusively used for school work; "A PC? Why would I need that when I can game on my XBox/PS5??". The internet really did change so much in the last decade, and in my honest experience computer literacy has gone down not up as we've all expected
I sort of get that, in this day and age, it would probably seem a bit unusual for someone to show up at Stanford or MIT and be like "I've only ever used a computer to play video games but I think I'll major in CS." On the other hand, I also don't think programming had to be an all-consuming passion for the past 10 years as some seem to deeply believe.
I think there actually may be some of this. Both of my kids are in college right now, but I knew a lot of high school kids and their parents through the extracurriculars that my kids were involved in. The kids knew what the "hot" college majors were, including CS.
But they also knew the precise formula for college entrance, and were laser focused on getting into an "elite" school. Any activity that didn't contribute to that process was eschewed.
There are a lot of students interested in CS who have very limited access to a computer. Most kids these days get a locked down ipad or Chromebook at school, and Windows' footprint in schools has massively shrunk over the years.
It's not like how it was when I was growing up. We spent $2000 on a Gateway PC that I had full admin access to, and unfiltered internet. Now that kind of money is being spent on cellphones in the household. Because I had that kind of access I was bricking the OS (and reinstalling it), Mailbombing people's AOL inboxes, putting Sub7 on Kaza and Limewire and remotely messing with peoples computers.
The computers at school were only networked my senior year. Even then they were basically wide open.
Me and my friends effectively operated a screwdriver shop out of whoever's house we happened to be at. We were trying to host game servers on whatever we could cobble together.
None of our families had cellphones because they were still only used by businessmen. Computing priorities were way different and how you were exposed to them was different as a result.
None of those opportunities are anywhere near as common now. Kids get devices in schools but they're basically bricks that log everything you do. Computer Labs are rare and their access is fully locked down. Most students first personal computing device is a cellphone, and more likely than not it's an iPhone. All phones are super locked down but apple's even more so.
The market has changed. The days of open computing are now relegated to the back of the line or for those who can afford it.
So it's no wonder a class like this exists. We see similar issues in middle school where students don't understand what folders are or where their files are stored. Phones and tablets make it so easy you never have to think about it. This also extends to collage as well.
There's definitely a thing with CS that, at least at more elite schools, there's an assumption that you more or less know how to program--at least a language like Python--and you also more or less know your way around a computer well enough to use it as a tool for programming. (Or you pick it up quickly on the side along with your full course load.)
This is more or less unique among college majors outside of some arts disciplines like music. Yes, there's a requirement for some secondary school algebra and some basic science but an electrical engineering major could basically have never assembled a circuit before attending college and probably wouldn't be at any particular disadvantage.
And, per the original post, MIT is certainly one of the institutions that does this. The 6.001 MOOC(s)--basically intro to algorithms--teaches a bit of Python on the side but clearly you're intended to mostly learn it on your own.
(By contrast, back in the day, I took a FORTRAN course as part of a non-CS engineering major. The assumption was that you had never touched a computer before.)
I had a guitar tutor once and I asked him if I honestly had a chance to get into the Royal College of Music. He said absolutely, no problem, as long as you practice for at least two hours per day. Every day. For the next ten years... High-level CS is the same and I don't see any reason why it should be different. There is just no, or very little, time to teach introductory programming classes at most universities.
With the performing arts--perhaps music in particular--it's certainly the case that you mostly can't decide you want to do the music thing, except as maybe a very recreational activity for the first time in college. However, I'm not sure I'm sold that CS--more or less uniquely among technical fields (including electrical engineering)--needs to have the same level of informal prerequisites.
Well after they spend 4-8yrs of their life learning CS, damn right they’re going to romanticize and gatekeep it every chance they get.
Meanwhile I agree with you, software engineering jobs are a trade 90% of the time. It’s why so many highly educated folks are being laid-off right now, while the doers keep-on building and making
bank.
Coal miners also do stuff like massively die in gas explosions and are kind of a poster child for labour exploitation. Wouldn't it be crazy if this line of work held the same prestige to hold in special regard?
There is beauty in just about any trade that is well done. To the extent this is romanticized is up to you. I'm not a big fan of the professionals that feel it is 100% trade. On the flip side, the 100% romantics are not ideal either IMHO - too focused on technology for technology sake.
It sounds like you are thinking of software engineering, which is an adjacent field often conflated. CS is about pushing current boundaries and inventing the future.
Software development is a trade, if all you aspire to be is a WordPress or frontend developer then you don't need a fancy degree, you can just as easily go to a 6 to 8 week code camp for that.
Computer science is a pathway for those that want to delve deeper, and that necessitates rigorous fundamentals in applied mathematics and information theory.
> Computer science is a pathway for those that want to delve deeper, and that necessitates rigorous fundamentals in applied mathematics and information theory.
I dare say that one can go through a whole career as a software engineer without spending a single semester learning about algorithms, in the sense that you just start learning about them in a JIT fashion if/when they become an issue, which is rarely.
Some of the O(X) trivia so much sought after in some interviewing circles is even fundamentally wrong when real world aspects such as problem size or CPU architecture come into play.
This is basically my career. I had a stable gig for my first handful+ of years after college and never much encountered the leetcode grind people talk about until recently. A lot of the O(X) stuff is self apparent when you're writing practical code: lotsa slow loops within loops == bad and should be avoided where possible.
When I started doing job interviews it was a little bewildering how much some companies focused on this. I ended up taking a job whose interviews focused on more practical skills and also stressed a good culture fit and understanding of development practices. It feels like a place I'll be happier.
I think you're right about the JIT aspect to this sort of thing--that's really what being an engineer is about in my experience. When you encounter a problem, figure out how to do it better. If my filter/sort/whatever is too slow for a specific application, I'll do some research and implement something more appropriate.
Computer science != algorithms. There's also the whole systems branch! If you ever find yourself thinking about TCP, virtual memory, system calls, frame buffers, shaders, signatures, interpreters, compilers, query planners, etc. these are also things you could have studied and practiced building in a CS program.
MIT has an expectation that students would cover their programming skills via internships or outside jobs, and thus they focus on teaching CS which is quite hard to pick up on your own. Unlike frameworks or trends which change every 2 years, fundamentals are quite hard to change and can carry you quite far if you know how to apply it correctly.
My school handled this cleverly by taking people with prior programming experience into a Haskell sequence, which suitably kicked our asses to the same degree as what the first-time programmers were getting.
My college's CS program did the same, but with Scheme back in the day.
I can't complain, since I was introduced to Emacs along the way, which I still use heavily to this day. And while I don't really use Scheme anymore, it made Elisp trivial to figure out.
My CS course at the University of Sussex, UK did this (in 1988) with ML, the functional programming language. Plenty of us had already been coding in C or Pascal before starting at college. None of us had done any functional programming. I loved ML: it seemed all elegant and beautiful and magical.
When I hear people starting their CS degree with C++ or Java, it makes me cringe.
But is it common for kids to be taught how to code before they come to uni? I would imagine it's not that easy to find someone to teach that sort of thing, so then the only kids who graduate high school with any tech skills are the ones who did it themselves.
Your point about engineering is exactly right. I built a working radio in my first term, having never done anything like it before, save for acing some physics exams with minimal electricity sections. When we came to coding, I had mucked about a bit with a computer, but I also found other students who'd worked at Microsoft. Wide wide range, and a lot of people of course ended up getting that fellow to email them the solution.
Even if it's more like hacking around in Python than being "properly" taught, I assume that it's pretty common for a technically-inclined and motivated high school student to play around with a Raspberry Pi. I imagine I'd be doing so if I were in high school today. In addition to books, there are also some pretty breezy intro to programming MOOCs out there that wouldn't be out of the reach of a smart high-schooler.
I don’t think that’s quite right. You’re not going to expect someone majoring in French to not have studied any French before college.
It seems completely reasonable to expect someone to be comfortable finding their way around a computer if they’ve chosen to major in computer science.
I’d also expect an entering electrical engineering major has studied more math than just “some secondary school algebra”. They’ve probably already studied some calculus or at the very least are ready to as soon as they start their first semester.
It’s a bit of a red flag to have no foundations in a subject you’ve decided to focus on for the next four years. That said, sufficiently motivated individuals can catch up and overcome their initial lack of preparation.
You have to put yourself back into your 18yo self, right? The kind of people who think a degree in management will make you a manager, and if they let you on to your course they must know what the requirements are and you must satisfy them.
At that time in your life your entire world has been school, and everything you did in school led to another thing in school. Why wouldn't you assume you'd get taught programming when you applied for a CS course, whose prereq was math that you did in school?
everything they teach you in a CS degree is useful and broadens your knowledge of the space, and all of it might potentially come in handy as your career develops, though much of it might not.
Doesn't mean you'll be a great programmer or archtect or planner or teacher. Right? you might drop it and go into something else.
Same is actually true of a management degree, everything they teach has been well thought out and is applicable to managing a company. Doesn't mean you'll be any good at it or work in all those departments. It is not a useless degree, though many useless people might pursue it.
>(By contrast, back in the day, I took a FORTRAN course as part of a non-CS engineering major. The assumption was that you had never touched a computer before.)
This was my "back in the day" experience as well, though I had a choice between C and Pascal. There was no expectation that anyone had any programming experience. I only had a touch of C64 BASIC knowledge going in.
> I have this feeling that the kids who appear better at uni are the ones who happened to pick up certain not-quite-programming skills before they started. Basics of networking, how installation of programs happens, how to use the command line, that kind of thing.
This one really stood out to me and highlights a change in things since then. That describes ALL of the CS kids during my time. We were the ones who a) had computers and b) did weird things like rebuilding kernals or futz around forever trying to get remote X sessions running.
A fact that blew my mind a few years ago was that, of the 13 software engineers on my team, only 3-4 actually owned a computer other than the work-provided one.
Yeah, I remember taking this machine architecture course with a friend who was getting a journalism degree and had never written any code or done anything more technical than playing StarCraft brood war before college.
One of the later assignments they gave us this "bomb" executable and we had to use gdb to pick it apart and modify the instructions or find ROP gadgets or something to make the code not "explode". He was my partner in the assignment and I spent most of the time trying to teach him what I was doing in gdb. And trying to express that, sincerely, he wasn't stupid GDB is just really hard and he didn't have the background knowledge to make learning it easier.
I mean, yes, this was me. I came in knowing most/all of this. I knew six (or more?) programming languages, had at least played with CVS/SVN, had installed Linux (read: fought with the Linux bootloader to get my AMD CPU to boot without crashing), had dipped my toe in a few open source communities.
But I was a tutor in college and I interacted with a bunch of people who didn't come in with any of this experience. Many of those people struggled, but I also know a bunch of people who came into CS knowing nothing, loved it, and went from zero-to-sixty faster than even the people who came in knowing a lot.
I'm still not sure I can identify what the ingredient was, but experience alone is not enough to explain it.
I went to college in the late 90s. Didn't even own a computer until I was a freshman (used my loan money to buy one). Math and science had always been my subjects, so I started college pre-med. But, this new computer I just bought kept sucking me in. I'd stay up all night reading how to make it faster, learn all the tricks, and finally make it do what I wanted through programming. Next semester I took a programming class just to see how it went, then dropped everything, and switched majors. I got a part time job writing custom software for local companies as a sophomore/junior (late 90s dotcom was just ramping), and I guess it has all worked out ok.
Indeed. While I think learning algorithms and ds is a non-negotiable thing, in 90% of the companies out there in 90% of the situations one will never have to write a binary search from scratch or implement a queue from scratch. On the other hand, profiling, debugging, glueing things together via bash, etc., that’s what distinguishes you from the colleges who only write passable code.
I dropped out after a year of college and have since weaseled my way into a dev position, your observation could not be more true in my experience. I've since strongly considered going back to school for a degree, but as interesting and probably useful some of the material may be, I'm not convinced it's worth it as an investment into making me better at my job.
If only I could use 529 funds on some of these online course providers.
I love vim, it's great to know how to navigate it, but I have met very few people who use it professionally. I'd love to hear others' experiences, there.
Lots of people at my work use it, but I don't know if I'd consider it essential. If you can use any editor/IDE very fluently that's good; probably doesn't hurt to learn with vim if you don't already have that.
if you ever find yourself needing to modify files at the shell on any sort of remotely modern unix/linux system, you're probably going to have vi or vim available.
it's worth knowing an editor that doesn't require 6GB of RAM and a graphical environment, but it's probably not going to be most folks' primary editor. ;d
Sooo many choices. I started[1] programming on a 5 MB machine with ~4 MB free.[2]
But I'm not allowed a GUI? Ok… then, I'll choose an editor with a keyboard-driven menubar across the top (keyboard shortcuts appearing in the menus), a status line on bottom, and as many keycombos that match my preferred GUI as possible.
Failing that, I can muddle along with Nano.
Until some once-in-20-years task actually requires using an arcane 'editor' that assumes I live in PDP-11. (^:
[1] Wellll… I sometimes forget typing BASIC from magazines into an Apple II and making small changes.
[2] And it was luxurious…until I tried to fit 8 MB of a CD-ROM app into compressed RAM.
I use (Neo)vim as my daily driver, professionally (for the past 4 years, coming from Goland). I've found every other editor to be too heavy/slow (VScode/Jetbrains), or too noisy (regarding features).
Neovim allows me to specify the precise minimum I desire to have a fully functional IDE-like experience (basically treesitter + LSP + DAP + minimal extra plugins).
It's super fast, I'm already in my shell, and my memory usage gets to stay super low :)
Once I learned how to use vs code productively it really changed my mind. The other day I needed to do a quick base64 encode and vs code had that. Same goes for formatting some json or doing a diff. It's all available in a single tool with no learning curve. Hell it even has git and git blame in there.
I think VS Code is just extremely convenient and can address most peoples needs out of the box. It’s therefore also very beginner friendly. You don’t need to constantly fight the tool or spend hours researching how to configure some trivial feature. That being said VS Code is quite heavy and has an enormous amount of GUI elements. I mean they even have buttons for things like git fetch and pull for heavens sake. They could release a VSC Light that strips most of the GUI out.
Vs Code is the gateway drug of real IDE's. Last time I checked, it still cant do things like navigate to definition, or rename a calss along with all mentions of it in comments. Or count TODO: comments
Yeah - to each their own. I have all these tools in my terminal too. I'm just a lot faster in the terminal, and I don't really think it's possible to be faster in a GUI (even if there are shortcuts - there will surely be shortcomings before you eventually just re-invent a terminal via VSCode).
I've given up on Vim a long time ago. However, every IDE or editor or notebook tool I use that has Vim keystrokes I enable that and use that. You have to let the Vim purist in you die, it's not a fight that can be won. Settle for like 80% of what you used to be able to do in Vim and call it a day.
I don't understand. Why do you need to do this? What am I settling for? I use vim daily and want for nothing.
Vim becomes a state of mind, a model for editing that is really empowering. I can translate any thought to code by doing a little dance on my keyboard. My mind is freed by this expression.
Every time I'm working on a personal project I boot up neovim and have some fun. I have an extensive neovim (and emacs) configuration.
If I need to do anything in a professional environment, I boot up intellij/vscode/whatever they use and just install a vim emulation plugin. Vim is fun and all, but when time is money the last thing I want to worry about is configuring my editor.
I use Vim infrequently. I know it and if it was the only option I'd be efficient with it. I've even started with Vi as the only option. However I prefer Emacs because I feel way more efficient and comfortable with it. As a bonus main key bindings are consistent with Bash and others GNU tools. The course should introduce Emacs as well so that students can choose on their own. Whatever your preferred editor is IMHO it is up to an IDE to integrate with it.
I use neovim with Ale plugin for LSP and linters. Somehow it maps into my brain better than anything else. Its fast, on cli, feature rich, usable without a mouse...
The only thing where vim/neovim really sucks against other tools is the project specific configuration.
been using it my entire career. works well, never had much reason to switch, especially these days when I do most of my work sshed into another machine (we aren't allowed to have work code on our laptops)
I'm not fond of Vim, have been an Emacs user for going on 40 years, starting with Gosmacs. That said, I'd rather that students learn one editor really well, rather than the smattering of editor/IDE usage most of them seem to acquire. So, fine, teach them enough Vim that they can use it well, afterwards, they can use whatever editor they choose.
I use it (well neovim) exclusively now because I like it. I have in the past used Emacs, IntelliJ, and VSCode. All work, the choice between them doesn't matter a jot, and that choice has never had the slightest influence on my competence or so-called 'productivity'.
More useless words have been spent over editor choice than .. "how good is Linux?" or "how terrible is Electron!" or any one of the handful of sometimes entertaining and always vacuous areas of argument software people frequent over their peccadilloes.
Depending on what kind of programming you're doing. I think it's fairly command in sysadmin stuff. But I can't imainge doing, say, Android development in vim. (Of course it's physicall possible, but...)
Of the 10 developers I work with the most, 9 are vim users and one is VSCode. The VSCode guy won’t shut up about it but then he is also the proselytizing type.
Honest, I’m not that attached to vim and mainly keep using it because it’s what my colleagues use. If everyone suddenly switched to VSCode I would follow the herd. The only thing about vim that I love, and would not give up, is the keybindings and I am sure I could find a decent plug-in for that.
I'm 30 and have been using vim since college. Usually I'm not actually using the vim editor, but some IDE that has vim keybindings. Good enough for me since I don't customize it much anyway. And then I get the best of both worlds: IDE features for navigating around files (jump to definition, display references), and vim for navigating within a file. Professionally I never paid attention to how many people are using it. Off hand I know a couple people that use emacs, and zero that know vim, but this is probably because emacs users talk about emacs :)
man I forever wanted to have a class like this... but also know it would have gone way over my head, I learn by solving problems I actually have. But having known version control would have saved me so much time. I got by with judicious use of tar -gz
As far as cryptography is concerned, I think one of the best options these days is to teach the libsodium API. It's very rationally structured and well documented, and also available on every platform and in every language. Most importantly of all, there's nothing in there that you shouldn't use, which is one of the biggest problems with real world cryptography.
It's amazing how many CS programs fail to teach you even the basic tools of being a software developer. Yes, yes, CS is not programming, but there is a non-trivial amount of CS that is indeed programming, and that is generally what people do with their CS degrees, so it'd make sense for a CS program to teach the basics. Maybe even more than the basics.
CS programs prepare you first and foremost for a PhD in CS. They're great for learning the theory and fundamentals, but teach practical Software Engineering skills as a side effect.
This very much varies by school. In California, undergrad as prep for grad school is the default for the UC system, but not so for the Cal State system.
Ironically, as a CS PhD student I spend an enormous amount of my time on the subject matter listed. There are very few research areas in which PhD students can get away with ignorance of the command line, shell environments, build systems, version control, debugging, etc.
A common scenario is that I want to reproduce and extend some earlier research, and there's a GitHub repository for it that hasn't been touched for the last seven years, which was forked from an even older repository that some grad student hastily pieced together. And I need to run components of it on our high-performance computing cluster, where I don't have sudo privileges. So it's whole lot of moving things around between VMs and Docker containers, figuring out what to do about ancient versions of packages and libraries that are dependencies (especially everything that's still written for Python 2.7); either refactoring things to update it all, because I want to take advantage of newer functionality, or setting up some isolated environment with older releases of everything built from source.
I was on the CS faculty at a Canadian university in the 1980s. I proposed a course with almost exactly this outline, only to be told it wasn't university-level material. MIT seems not to have got this message; good on them!
I think this is mostly a US thing, or countries based on similar education systems.
In Portugal our computing degrees are Informatics Engineering to use a literal translation, a mix of CS stuff and Engineering. And validated by the Engineering Order as fulfilling certain requirements, for anyone that at end of the degree also wants to do the admission exam for the professional title.
Those that only care about the theory part of CS take a mathematics degree with major in computing.
Caltech's mechanical engineering program did not teach you how to use machine tools. The courses were all math, more math, lotsa math, a heapin helpin of math, with a side dish of math.
My university (ANU in Australia) added a course very similar to this along side their first year courses. Didn’t get to see the results, but having tutored the years before the course’s introduction it was certainly… necessary
Which uni was this? Presumably you're a proud alumni, even if you don't want to donate money to them, you might at least consider repping them in this context for having taught you this stuff. Fwiwi, many CS programs focus on the science end of things like Big Oh notation, and utterly fail to discuss any day-to-day, practical applications of things.
Some programs manage to sneak in some of this material in an "operating systems" or "network programming" or other such class where you do more hands-on programming. More so in technical universities and CS Engineering degrees (at least this is the case in Europe).
I try to minimize the amount of personal info I share. Hacker News community is smart people, and my thread history is triangulation data.
Wouldn’t say I’m a particularly proud alum. They dropped the ball on a wide swath of other topics that I would consider integral. For instance, distributed computing should be a more common undergrad elective, not something you get blindsided by when you get out of school. “Sorry, you said Who-bernetes?” Now, I get that Kubernetes is a relatively young project, as is Docker and other containerization tech, but it is nonetheless staggering how school felt like it was 10 years behind the ‘cutting edge’ when I was there. They seemingly had no interest in educating engineers to go out and join the web community unless that individual sought self-guided study.
I don't think it's so much a case of better or worse--but rather that some schools see a place in the CS curriculum for a Computers, Programming, and Tools 101 course and others do not--figuring you know a lot of this stuff or can pick it up.
We're teaching a course at ETH Zurich [1] where --besides the actual payload of solving partial differential equations (PDEs) on GPUs-- we put a lot of emphasis on "tools". Thus students learn how to use git and submit their homework via pushing to a repo of theirs on github, we teach testing and continuous integration, writing documentation, running code on a cluster, etc. In their final project, again submitted as a GitHub repo, they need to make use of all of theses skills (and of course solve some PDEs).
Note that excellent work in this space is done by the Software Carpentry project which exists since 1998 [2].
As an alumni, thanks a lot for doing this. Looking back, all the things that I've learned in just the first few weeks in the industry made writing code so much more productive - if only someone had shown some of it already during some early semester, even just during some assistant teaching hour, it would have saved so many hours.
I remember specifically when one of the exercises for some compiler lecture contained unit tests the code had to satisfy, and I was like, wow, why didn't I already knew about this during algorithm classes earlier where I was fumbling around with some diff-tools to check my output. Let alone proper version control, now that would have been a blessing.
In hindsight, it's a bit embarrassing that I didn't bother to, well, just google for it, but neither did my colleagues - I guess we were so busy with exercises and preparing for exams that we just didn't have the time to think further than that.
Thank you very much for the GPU course. Even though my college taught shell usage to some extent, when I asked about GPU programming it was considered a nerd topic back in 2009.
Yes, in many ways it is closer to Windows and IBM mainframe/micros semantics, even though it looks like UNIX on the surface.
For example, it uses COFF (although it also does ELF), the shared libraries also use export files, are private by default, and allow lazy loading on demand when symbols are touched for the first time, just like on Windows.
The TUI tooling to manage the OS is similar to what the other IBM platforms use.
Not much I can remember, the last time I used Aix was in 2002.
By a happy accident I did a 3 year masters program in India called Research Assistant program. I was a system-admin at the CS department's for 3 years. I had to do ton of stuff, like setting up and maintaining backups, installing tools such as DNS, mail servers, handling server failures, provisioning new servers, debug networking failures by inspecting router connections, so on and so forth. It was a lot of work but super fun and lots of stories. This was ~20 years ago so no SaaS tools etc., One had to do almost everything in house and we had to use free/open-source tools to save money.
That experience taught me so much and I still use most of those learnings on a day to day basis.
Lots of laudatory comments here about this being essential but missing teaching but I have a different take. The content looks good, nothing wrong with teaching these things. But these things can be and are learned on the job fairly quickly for anyone interested enough in the field and with enough aptitude. In fact, I would say these things can be learned on your own time as a side effect of being interested in computers.
So I would say it's good content, but not essential for a CS program.
I don't think you're wrong that you can learn this stuff on the job, but a "primer" kind of class like this which surveys several useful tools helps new engineers develop pattern matching skills around how to continue self-teaching these kinds of things. Shell/scripty/vim-ey,linux-ey stuff can be really challenging to learn how to learn for some people.
a) Universities are places of higher learning that do not need to cater to industry
b) There is an implicit social contract whereby universities should produce industry-ready graduates
c) Something in-between
… the skills taught in this course are as useful for the PhD candidate as for the junior software engineer.
Why leave these out or up to the student, then?
Furthermore, in many other academic disciplines, it’s very common to teach applied technique (eg, on writing essays or structuring research), is this any different?
I think it’s dependent on the person learning the material. My college had a similar course and it was also highly regarded as useful by students. However, while I found the course fun I already knew most of the basics from my research job, and the advanced stuff hasn’t really come up again even in work (e.g. fancy git or gdb commands), so I’ve entirely forgotten it; my biggest takeaway is probably ctrl r for searching in shell. But I can see why a guided intro would be really helpful to someone who had no experience or some trouble getting started learning this kind of material (which is very different from programming or computer science).
There’s probably an aptitude threshold past which the course’s value diminishes - don’t mean any disrespect to anyone, just trying to expand on your point. The top students either have already figured it out or will do so easily, so they might be better off doing something else with the time they would’ve invested in this. But for a lot of students learning about these tools and concepts can be a real force multiplier, more so than a random upper level course.
I think it can be useful to distinguish between the "known and unknown unknowns" here. For example, everyone will quickly realise that that they need to know git, and they will learn what they need to know (a known unknown). A university course would maybe save them time, but it would not really change what you know after 2 years in industry. Compared to e.g awk or shell scripting which can be incredible usefull, but maybe not something people realise by themselves that they need (a unknown unknown). A university should make people at least aware of these latter tools.
Totally agree. Further, these skills actively support rapid iteration on learning other core university outcomes. In CS it’s very easy to waste lots of time doing things the wrong way that could otherwise be spent doing something useful.
Good point. Some things you will learn by necessity, but if you dont know about say regexes you probably wont think of searching specifically for such a tool.
> The class is being run during MIT’s “Independent Activities Period” in January 2020 — a one-month semester that features shorter student-run classes. While the lectures themselves are only available to MIT students, we will provide all lecture materials along with video recordings of lectures to the public.
It seems that the course is only 1 month and runs alongside some student-run classes. So this is from the get go not an essential course of a CS program.
There's quite a broad mix of offerings during IAP--a lot of which isn't part of a regular academic program and a lot of which is just for fun/intellectual interest. It's mostly all non-credit. And there are a fair number of sessions dealing with practical details that may not be covered in regular courses.
This is also what i thought too. The content is effectively a roadmap on how one could use the computer well to perform tasks (without the algorithmic/programming portion).
If your main usage environment is windows, none of these are that helpful, but the ideas could be translated mostly (windows shell is similar enough, that you can just as easily script them with batch files).
Yeah I pretty much agree with this comment. But I think my take on whether universities should be training for academia or for industry is "why not both?". I think these are just different valid tracks. There is a lot of education that overlaps between "computer science researcher academic" and "software engineering professional with strong fundamentals". So that should be the required set of credits. But then there are different tracks toward where you want to take your degree. Those sound like electives. Academics should learn more about research techniques and publishing and presenting at academic conferences, etc. And those on the professional track should learn more about tools and techniques used in industry.
There's no conflict or contradiction here, just different strokes for different folks.
At university, my co-founders and I took over teaching a few modules. We were eager to find a larger pool of students that had useful skills for a company, rather than those versed in just theoretical knowledge and Java.
To provide the students with the skills they'd need in their career, we taught them how to use real world tooling: how to make a website from a design, how to use Git, how to write backend code, identifying security risks, how to use editors that weren't JEdit or Netbeans, how to use PhoneGap, how to deploy to a server, how to use Unix.
As a result of our training, we managed to get some great students on-board. No longer were we surrounded by students who could make some ServiceFactoryBean, but instead ones who were fully capable of making real things in a real company.
It's awesome to see that MIT has a similar programme - covering all the skills that we actually did teach. Too much of university is spent theorising and not spent making students employable.
This is great! I can remember how painful it was to figure this stuff out when I was a student. Even with what I know now, I still learned a few things from browsing through the material.
At some point, we might need to accept that "mock" has become a generalised term which refers to many kinds of test-doubles. If it's being taught that way in universities and embodied that way in tooling, then the term has a new meaning.
Any reason why you would use jq over Python? Certainly this can be attributed to my lack of knowledge in jq, but anything beyond a simple query is going to be done with Python for me. Beyond not having to look up query syntax, doing it in Python (or any script) is easier to read (both during and after writing it) due to auto formatting in an editor.
To give an example from another context: This is a bit like asking "why would you use document.querySelector() instead of just looping over childNodes directly?"
That's funny. This is much of what I teach my own IT Product Development students in the first year course The Web of Things at my CS Department, Aarhus University. My goal for the course was precisely to introduce tooling and techniques, and to habituate the students to their use through the construction of systems integrating Web and IoT. It's a busy seven weeks, but students further along often tell me that they learned a lot and are still using the same tools.
At my uni this is a course in the first semester, called introduction to operating systems, covering command line, git, encryption, bash and all that. It's pretty good for second year student that are TA's because it's quite some infrastructure needed to teach the labs(containers, configuring vms, custom autograders) so
346 comments
[ 2.9 ms ] story [ 304 ms ] threadWhat this content covers should unlock iteration speed, which is the single greatest lever in learning and growing faster (on a computer). Thus it gives you more cycles to go back to improving your code, experimenting with algos, etc. Probably also highly correlated with upwards mobility in the software job market.
Great seeing this under a common umbrella I can hand to students and new grads.
Like you said, it's been a complete game changer. I feel these skills continue to differentiate me from my peers in terms of how I can attack arbitrary problems bravely to this day.
This could be causal.
What I find is that if my code isn't working, I stop what I'm doing. I look at it. I think really hard, I add some print statements and asserts to verify some assumptions, and I iterate a small handful of times to find my faulty assumption and fix it. Many, many times during the 'think hard' and look at the code part, I can fix the bug without any iterations.
This almost always works if I really understand what I'm doing and I'm being thoughtful.
Sometimes though, I don't know what the hell is going on and I'm in deep waters. In those cases I might use a debugger, but I often feel like I've failed. I almost never use them. When I helped undergrads with debuggers it often felt like their time would be more productively spent reasoning about their code instead of watching it.
Are you aware of the amazing Java debugger feature of "Drop to Frame"? Combined with "hot-injection" (compile new code, then inject into current debug'd JVM), it is crazy and amazing. (I love C#, but the hot-injection feature is much worse than Java -- more than 50% of the time, C# compiler rejects my hot-injection, but about 80% of the time, JVM accepts my hot-injection.) When working on source code where it is very difficult to acquire data for the algorithm, having the ability to inspect in a debugger, make minor changes the the algorithm, then re-compile, inject new class/method defs, the drop to frame, the re-exec the same code in the same debug session is incredibly powerful.
The plus side of less capable tooling is it tends to limit how complex software can be--the pain is just too noticeable. I haven't liked java in the past because it seems very difficult without the tooling and I never had to do enough java to learn that stuff. Java's tooling does seem quite excellent once it is mastered.
If you are a low level programmer, I understand your sentiment. A piece of advice, when you need to use Java (or other JVM languages), just submit to all the bloat -- use an IDE, like IntelliJ, that needs 4GB+ of RAM. The increase in programmer productivity is a wild ride coming from embedded and kernel programming. (The same can be said for C#.)
When you're extremely "fluent" in programming code and good at mentally modelling code state, understanding exactly what the code does by looking at it, stepping through it doesn't typically add all that much.
While I do use a debugger sometimes, I'll more often form a hypothesis by just looking at the code, and test it with a print statement. Using a debugger is much too slow.
This varies, but in a lot of environments, using a debugger is much _faster_ than adding a print statement and recompiling (then removing the print statement). Especially when you're trying to look at a complex object/structure/etc where you can't easily print everything.
Don't remove the print statement. Leave it in, printing conditionally on the log level you set.
Early on it was a godsend. Start program, hit breakpoint, look at values, step a few lines, see values, make conclusions.
Now I rely on print statements. Most of all though, I just don't write code that requires stepping. If it panics it tells me where and looking at it will remind me I forgot some obvious thing. If it gives the wrong answer I place some print statements or asserts to verify assumptions.
Over time I've also created less and less state in my programs. I don't have a zillion variables anymore, intricately dependent on each other. Less spaghetti, more just a bunch of straight tubes or an assembly line.
I think it's possible that over the years I hit problems that couldn't easily be stepped. They got so complicated that even stepping the code didn't help much, it would take ages to really understand. So later programs got simpler, somehow.
Neither situation was at all related to my talent (or lack thereof).
Besides, every IDE has a different way to debug, so they might just not be familiar with the interface. I can’t tell you exactly how to debug in VSCode even though I’ve used it the most. I’ve had to run a debugger only a handful of times in the past couple of years and it’s always for codebases that are more tangled (e.g. .NET where there’s interfaces everywhere).
Now maybe if I was better that wouldn't be the case, but even the cleanest "wish i thought of that" functional code i've seen still looks like it'd be easier to fail fast using a debugger with.
In fairness though, I will admit I use the debugger a lot less when i'm not screwing with reflection on generic types or whatever because runtime errors just happen a lot less in functional styles. Usually if it compiles, it runs, because the compiler can sanity check the code better than you can.
> [uses F#]
That has to be humblebragging. The average .net developer is terrified of or doesn't even know about F#.
The only reason F# winds up feeling harder isn't so much how F# works, but simply because the entire dotnet environment was built for C# first, so you do need to know how to handle the C# style. I do think that if you could just pick one and then suddenly have every library support it's styles, F# would probably be easier overall because it's just got a lot of nice features built in that make updating your code so much easier.
C# is not a simple language, but F# has basically all the complexity of C# with OCaml on top.
Either C# or OCaml would be simpler to learn, although the combination is powerful.
`f(a, b)` looks like a call to a function that takes a single tuple as its argument. So I would expect `f` to have the type signature `A * B -> C` instead of `A -> B -> C`. Is my intuition wrong? If it is, then what does F# use the parenthetical syntax for?
[1] https://learn.microsoft.com/en-us/dotnet/fsharp/language-ref...
F# enforcing a lot of good practice code style stuff (order matters for example pisses off long time devs who already have styles, but prevents SOOOO much stupid bs from beginners) and basically eliminates runtime/chasing variable state errors completely so long as you can stay within style. Yes it'd be nicer if there was only one way to invoke functions but if i had to take a tradeoff I think it's a pretty easy one.
It is an issue that yes, like your example, you're often stuck ALSO learning OO because "oh you want to use X library, well that's OO so...", and even then you can isolate your mutable/OO areas really well, but this is more of an issue with it being an second fiddle language. If F# got F# specific libraries for all the C# stuff out there tomorrow I think it'd take off and most people would never look back.
If we're talking basic business logic/beginner programmer stuff, yeah I think F# offers a lot of stuff that makes it flat out easier to use. And if you want to point out complex issues, I feel the biggest one is that something that's intuitively much easier to understand in OO (create a variable/object, populate it on each iteration of a loop depending on logic), can feel daunting as hell in F# (fold).
You're noticing a very real relationship.
It's easy for people with functional programming knowledge, or who had OCaml as their first programming experience like I did at university, but for people without those exposures I can understand the difficulty.
Oh? Did you win some award? I'm curious as to how you're determining this?
One major issue I do see coming from the C# side is "well how do I do this then?!", which often the answer is "you don't, because you don't need to" or "well what if it's more performant to do it mutably!" well then thankfully F# can absolutely do that.
If you keep an open mind it's really a very clean and simple language, but in an age where half of development is importing 8 well known libraries, not being the main supported language is a major weakness.
However, I wrote my first thing a port of a small C# tool of a couple hundred lines, to F# in about an hour. It's been about a week now, and things are considerably smoothing out.
To be considered niche, the F# tooling has been great. Also, having the .NET libraries available adds a lot of built-in capability.
F# isn't hard, it's just different. Hell in many ways i'd argue it's much much easier once you get used to it. It doesn't have the support C# does so often you're stuck with a library that WILL work but doesn't have documentation for doing it in F#, and that can lead to struggles, but that's not really a sign of being a good coder.
Most dotnet developers could probably code circles around me in F# if they knew it existed/gave it a chance.
Personally I stuck with it because it had the low code look of python with strong typing. It took a bit to wrap my head around some functional stuff (basically map/iter = foreach and if you want to update something on each loop you probably want a fold, or more likely a built in function), but once I got over that hurdle it was pretty smooth sailing.
The irony is that by far the hardest part is the library thing, which your average dotnet dev would handle WAAAAY better than me.
Unless you have a setup where you can easily run one system with a debugger attached while connecting it to everything else, you’re basically restricted to running a debugger for bugs that can be reproduced locally.
I’ve been programming in C for nearly 20 years and primarily used printf for debugging for the first 12-15 years, and have used debuggers more and more. I use Emacs, and its gud mode is so nicely integrated into everything that using gdb is truly much, much faster than the alternative. I don’t use print debugging at all anymore.
It takes less time and cognitive overhead to just stop the program on the same line you would have inserted your printf, but you can now inspect the entire program state.
Obviously I’m not saying anything revelatory if you use an IDE on a regular basis… I guess this comment is for the folks who eschew IDEs.
Logging alone is fine, but it can often be difficult not to drown in information. I do embedded programming in C mostly.
I work on compilers and debuggers are more of an hindrance than help when trying to fix a compiler bug.
I believe there is a similar situation for distributed systems.
I used to read every help file on windows / visual c++, the FreeBSD manual, plowed through the file system and tested this it. Just because I was curious
I have seen devs scoff at the thought of print debugging, but I recall that in systems programming there are many times you can’t use a debugger or need to rely on other tool.
I’d rather schools teach the concept of step debugging vs runtime debugging. Teach students to try to understand the code, make hypotheses, and verify them.
I have seen some people use a debugger solely because they only know how to step debug. Meaning they start from main or another entry point and step through every line of code.
My point being that, you can’t judge a developer by if they use print statements or a debugger. Judge them by the methodology of how they debug.
Next time they do, ask them to recommend a better method of debugging that works across generally all languages, compilers, IDEs, and platforms with next to zero configuration.
Taking a program trace from the print debug statements, grepping through it repeatedly to filter down to certain events of interest, looking at the interleaving of those events, and figuring out the order that things happened in to cause it to go off the rails. That sort of thing. (To be fair, time-travel debuggers can start to get at this, but those are pretty uncommon. Traces, as you say, work almost everywhere.)
Or better yet, compare the traces between working and non-working runs to see how they differ. I've looked at diffs of traces this way before. (Sometimes I'll first use a small script to renumber pointers in traces by order of appearance.)
I've also used this sort of strategy before for debugging rare threading or other non-deterministic issues. Have the shell run the program in a loop, saving each run's trace and results to a different file, go off and get lunch, come back and see if anything failed. Then look to see if any of the runs failed and look for the structural differences between the working and non-working traces.
I can't imagine sitting and stepping through in a debugger 100+ times in the hopes that maybe this time, it will be the run that's just different enough to trigger the bug and that the debugger itself won't prevent the issue from manifesting. Not to mention, trying to remember the steps from all the good runs and spotting where the bad run goes bad before you've stepped to far. No thank you.
I think people really underestimate print debugging. Debuggers are fast and easy for simple bugs, sure, but there's powerful stuff that you can only really do with printed traces.
Isn’t that where things like breakpoint conditions, data breakpoints (“break whenever X value/field changes”), and dependent breakpoints, work pretty dang well? You just set up the appropriate situation and let it run until it breaks
But one thing that I have found helpful in the past has been aggregating the information from the traces across runs. Comparing good with good and bad with bad to classify the commonalities, and then compare good with bad to see how they differ.
The debuggers in most popular IDEs (IntelliJ IDEA/any JetBrains IDE, Visual Studio, VSCode, Eclipse) work the same way. You set breakpoints (typically by clicking somewhere around the line number), step into and out of functions, and look at the memory state. If you learned how debugging works in IDE X, you can easily switch to IDE Y without having to learn much.
Not just systems programming, but fixing issues in scaled production systems as well. Have fun attaching a debugger to the process that got killed twenty minutes ago when the spot instance it was running on got reclaimed. If you don't collect telemetry, you're blind. Debuggers are a luxury that you get to enjoy for issues you have before you ship.
I looked over her shoulder as my wife was doing a CS degree, and I realised there's a bunch of these little things that make life a lot easier if you know them.
um yea thats my job dude and i fought for it so other people should too these people waltzing in not knowing shot should not get into CS
But they also knew the precise formula for college entrance, and were laser focused on getting into an "elite" school. Any activity that didn't contribute to that process was eschewed.
It's not like how it was when I was growing up. We spent $2000 on a Gateway PC that I had full admin access to, and unfiltered internet. Now that kind of money is being spent on cellphones in the household. Because I had that kind of access I was bricking the OS (and reinstalling it), Mailbombing people's AOL inboxes, putting Sub7 on Kaza and Limewire and remotely messing with peoples computers.
The computers at school were only networked my senior year. Even then they were basically wide open.
Me and my friends effectively operated a screwdriver shop out of whoever's house we happened to be at. We were trying to host game servers on whatever we could cobble together.
None of our families had cellphones because they were still only used by businessmen. Computing priorities were way different and how you were exposed to them was different as a result.
None of those opportunities are anywhere near as common now. Kids get devices in schools but they're basically bricks that log everything you do. Computer Labs are rare and their access is fully locked down. Most students first personal computing device is a cellphone, and more likely than not it's an iPhone. All phones are super locked down but apple's even more so.
The market has changed. The days of open computing are now relegated to the back of the line or for those who can afford it.
So it's no wonder a class like this exists. We see similar issues in middle school where students don't understand what folders are or where their files are stored. Phones and tablets make it so easy you never have to think about it. This also extends to collage as well.
Okay then dont.
This is more or less unique among college majors outside of some arts disciplines like music. Yes, there's a requirement for some secondary school algebra and some basic science but an electrical engineering major could basically have never assembled a circuit before attending college and probably wouldn't be at any particular disadvantage.
And, per the original post, MIT is certainly one of the institutions that does this. The 6.001 MOOC(s)--basically intro to algorithms--teaches a bit of Python on the side but clearly you're intended to mostly learn it on your own.
(By contrast, back in the day, I took a FORTRAN course as part of a non-CS engineering major. The assumption was that you had never touched a computer before.)
I see it more as a trade. There can certainly be some beauty to it. I’m sure coal miners hold some of their own in special regard too.
Meanwhile I agree with you, software engineering jobs are a trade 90% of the time. It’s why so many highly educated folks are being laid-off right now, while the doers keep-on building and making bank.
It’s spelled Doerr
Computer science is a pathway for those that want to delve deeper, and that necessitates rigorous fundamentals in applied mathematics and information theory.
I dare say that one can go through a whole career as a software engineer without spending a single semester learning about algorithms, in the sense that you just start learning about them in a JIT fashion if/when they become an issue, which is rarely.
Some of the O(X) trivia so much sought after in some interviewing circles is even fundamentally wrong when real world aspects such as problem size or CPU architecture come into play.
When I started doing job interviews it was a little bewildering how much some companies focused on this. I ended up taking a job whose interviews focused on more practical skills and also stressed a good culture fit and understanding of development practices. It feels like a place I'll be happier.
I think you're right about the JIT aspect to this sort of thing--that's really what being an engineer is about in my experience. When you encounter a problem, figure out how to do it better. If my filter/sort/whatever is too slow for a specific application, I'll do some research and implement something more appropriate.
I can't complain, since I was introduced to Emacs along the way, which I still use heavily to this day. And while I don't really use Scheme anymore, it made Elisp trivial to figure out.
When I hear people starting their CS degree with C++ or Java, it makes me cringe.
Your point about engineering is exactly right. I built a working radio in my first term, having never done anything like it before, save for acing some physics exams with minimal electricity sections. When we came to coding, I had mucked about a bit with a computer, but I also found other students who'd worked at Microsoft. Wide wide range, and a lot of people of course ended up getting that fellow to email them the solution.
It seems completely reasonable to expect someone to be comfortable finding their way around a computer if they’ve chosen to major in computer science.
I’d also expect an entering electrical engineering major has studied more math than just “some secondary school algebra”. They’ve probably already studied some calculus or at the very least are ready to as soon as they start their first semester.
It’s a bit of a red flag to have no foundations in a subject you’ve decided to focus on for the next four years. That said, sufficiently motivated individuals can catch up and overcome their initial lack of preparation.
At that time in your life your entire world has been school, and everything you did in school led to another thing in school. Why wouldn't you assume you'd get taught programming when you applied for a CS course, whose prereq was math that you did in school?
Doesn't mean you'll be a great programmer or archtect or planner or teacher. Right? you might drop it and go into something else.
Same is actually true of a management degree, everything they teach has been well thought out and is applicable to managing a company. Doesn't mean you'll be any good at it or work in all those departments. It is not a useless degree, though many useless people might pursue it.
This was my "back in the day" experience as well, though I had a choice between C and Pascal. There was no expectation that anyone had any programming experience. I only had a touch of C64 BASIC knowledge going in.
> I have this feeling that the kids who appear better at uni are the ones who happened to pick up certain not-quite-programming skills before they started. Basics of networking, how installation of programs happens, how to use the command line, that kind of thing.
This one really stood out to me and highlights a change in things since then. That describes ALL of the CS kids during my time. We were the ones who a) had computers and b) did weird things like rebuilding kernals or futz around forever trying to get remote X sessions running.
A fact that blew my mind a few years ago was that, of the 13 software engineers on my team, only 3-4 actually owned a computer other than the work-provided one.
One of the later assignments they gave us this "bomb" executable and we had to use gdb to pick it apart and modify the instructions or find ROP gadgets or something to make the code not "explode". He was my partner in the assignment and I spent most of the time trying to teach him what I was doing in gdb. And trying to express that, sincerely, he wasn't stupid GDB is just really hard and he didn't have the background knowledge to make learning it easier.
I mean, yes, this was me. I came in knowing most/all of this. I knew six (or more?) programming languages, had at least played with CVS/SVN, had installed Linux (read: fought with the Linux bootloader to get my AMD CPU to boot without crashing), had dipped my toe in a few open source communities.
But I was a tutor in college and I interacted with a bunch of people who didn't come in with any of this experience. Many of those people struggled, but I also know a bunch of people who came into CS knowing nothing, loved it, and went from zero-to-sixty faster than even the people who came in knowing a lot.
I'm still not sure I can identify what the ingredient was, but experience alone is not enough to explain it.
https://www.youtube.com/watch?v=ZQnyApKysg4
It's all about leveraging "simple" cli tools and combine their powers to cut through work very swiftly. The opposite of many days for many people.
If only I could use 529 funds on some of these online course providers.
it's worth knowing an editor that doesn't require 6GB of RAM and a graphical environment, but it's probably not going to be most folks' primary editor. ;d
Sooo many choices. I started[1] programming on a 5 MB machine with ~4 MB free.[2]
But I'm not allowed a GUI? Ok… then, I'll choose an editor with a keyboard-driven menubar across the top (keyboard shortcuts appearing in the menus), a status line on bottom, and as many keycombos that match my preferred GUI as possible.
Failing that, I can muddle along with Nano.
Until some once-in-20-years task actually requires using an arcane 'editor' that assumes I live in PDP-11. (^:
[1] Wellll… I sometimes forget typing BASIC from magazines into an Apple II and making small changes.
[2] And it was luxurious…until I tried to fit 8 MB of a CD-ROM app into compressed RAM.
Using vim motions? Everywhere. All the time.
Neovim allows me to specify the precise minimum I desire to have a fully functional IDE-like experience (basically treesitter + LSP + DAP + minimal extra plugins).
It's super fast, I'm already in my shell, and my memory usage gets to stay super low :)
rename all instances of class/method/variable -> f2
count TODOs: too many vs code plugins that will do that for you
Not sure when the last time you checked, but vs code is a practical full fledged IDE with the right plugins.
That said - I haven't used it in years. Way too heavy and Vim does all of those + modal editing.
Plus - modal editing :)
Vim becomes a state of mind, a model for editing that is really empowering. I can translate any thought to code by doing a little dance on my keyboard. My mind is freed by this expression.
If I need to do anything in a professional environment, I boot up intellij/vscode/whatever they use and just install a vim emulation plugin. Vim is fun and all, but when time is money the last thing I want to worry about is configuring my editor.
The only thing where vim/neovim really sucks against other tools is the project specific configuration.
More useless words have been spent over editor choice than .. "how good is Linux?" or "how terrible is Electron!" or any one of the handful of sometimes entertaining and always vacuous areas of argument software people frequent over their peccadilloes.
But I don't think anyone can avoid learning how to quit vim. We've all been there, you think you know the keys, you don't, now you are trapped.
Honest, I’m not that attached to vim and mainly keep using it because it’s what my colleagues use. If everyone suddenly switched to VSCode I would follow the herd. The only thing about vim that I love, and would not give up, is the keybindings and I am sure I could find a decent plug-in for that.
They taught command scripting and code management later.
Debugging was a black art.
But name is the only thing we get right in CS education.
A common scenario is that I want to reproduce and extend some earlier research, and there's a GitHub repository for it that hasn't been touched for the last seven years, which was forked from an even older repository that some grad student hastily pieced together. And I need to run components of it on our high-performance computing cluster, where I don't have sudo privileges. So it's whole lot of moving things around between VMs and Docker containers, figuring out what to do about ancient versions of packages and libraries that are dependencies (especially everything that's still written for Python 2.7); either refactoring things to update it all, because I want to take advantage of newer functionality, or setting up some isolated environment with older releases of everything built from source.
In Portugal our computing degrees are Informatics Engineering to use a literal translation, a mix of CS stuff and Engineering. And validated by the Engineering Order as fulfilling certain requirements, for anyone that at end of the degree also wants to do the admission exam for the professional title.
Those that only care about the theory part of CS take a mathematics degree with major in computing.
make can be a career in and of itself.
Wouldn’t say I’m a particularly proud alum. They dropped the ball on a wide swath of other topics that I would consider integral. For instance, distributed computing should be a more common undergrad elective, not something you get blindsided by when you get out of school. “Sorry, you said Who-bernetes?” Now, I get that Kubernetes is a relatively young project, as is Docker and other containerization tech, but it is nonetheless staggering how school felt like it was 10 years behind the ‘cutting edge’ when I was there. They seemingly had no interest in educating engineers to go out and join the web community unless that individual sought self-guided study.
Note that excellent work in this space is done by the Software Carpentry project which exists since 1998 [2].
[1] https://pde-on-gpu.vaw.ethz.ch/ [2] https://software-carpentry.org/
I remember specifically when one of the exercises for some compiler lecture contained unit tests the code had to satisfy, and I was like, wow, why didn't I already knew about this during algorithm classes earlier where I was fumbling around with some diff-tools to check my output. Let alone proper version control, now that would have been a blessing.
In hindsight, it's a bit embarrassing that I didn't bother to, well, just google for it, but neither did my colleagues - I guess we were so busy with exercises and preparing for exams that we just didn't have the time to think further than that.
Not saying you're insinuating that. Just curious about AIX.
For example, it uses COFF (although it also does ELF), the shared libraries also use export files, are private by default, and allow lazy loading on demand when symbols are touched for the first time, just like on Windows.
The TUI tooling to manage the OS is similar to what the other IBM platforms use.
Not much I can remember, the last time I used Aix was in 2002.
That experience taught me so much and I still use most of those learnings on a day to day basis.
So I would say it's good content, but not essential for a CS program.
a) Universities are places of higher learning that do not need to cater to industry
b) There is an implicit social contract whereby universities should produce industry-ready graduates
c) Something in-between
… the skills taught in this course are as useful for the PhD candidate as for the junior software engineer.
Why leave these out or up to the student, then?
Furthermore, in many other academic disciplines, it’s very common to teach applied technique (eg, on writing essays or structuring research), is this any different?
There’s probably an aptitude threshold past which the course’s value diminishes - don’t mean any disrespect to anyone, just trying to expand on your point. The top students either have already figured it out or will do so easily, so they might be better off doing something else with the time they would’ve invested in this. But for a lot of students learning about these tools and concepts can be a real force multiplier, more so than a random upper level course.
It seems that the course is only 1 month and runs alongside some student-run classes. So this is from the get go not an essential course of a CS program.
If your main usage environment is windows, none of these are that helpful, but the ideas could be translated mostly (windows shell is similar enough, that you can just as easily script them with batch files).
There's no conflict or contradiction here, just different strokes for different folks.
To provide the students with the skills they'd need in their career, we taught them how to use real world tooling: how to make a website from a design, how to use Git, how to write backend code, identifying security risks, how to use editors that weren't JEdit or Netbeans, how to use PhoneGap, how to deploy to a server, how to use Unix.
As a result of our training, we managed to get some great students on-board. No longer were we surrounded by students who could make some ServiceFactoryBean, but instead ones who were fully capable of making real things in a real company.
It's awesome to see that MIT has a similar programme - covering all the skills that we actually did teach. Too much of university is spent theorising and not spent making students employable.
[0] https://missing.csail.mit.edu/2020/metaprogramming/#a-brief-...
[1] https://martinfowler.com/articles/mocksArentStubs.html
Being moderately competant at jq on a team that doesn't know jq is a super power.
To give an example from another context: This is a bit like asking "why would you use document.querySelector() instead of just looping over childNodes directly?"