I really have to disagree with the disparagement of vim/scp at the beginning. It's a bit slower to start if you begin with command-line tools, but the dividends payed out by learning the standard command-line utilities are huge. Learning the command-line utilities means you have the tool-set to build your own tool-set; since it's a lot easier to using CLI tools as building blocks for larger tools.<p>At both of the last jobs I've held, it was rare that you would be in an environment where you had a full IDE. And in both cases I was asked several command-line oriented questions during the interviews.<p>Also big disagree on the final statement of the article. CS is not a vocational major, nor should it be. There are plenty of good post-secondary schools that focus on writing code and the tools you use to do so; CS curricula should not be focused on producing programmers, it should be focused on producing computer scientists. The recent insistence that we turn CS programs into job-mills is one of the big reasons for declining quality in my opinion, my local university CS program was recently told to "push more people through" and to make the curriculum "less theoretical" and more "career oriented". If you want that kind of stuff, go to a career college.
Speaking of using sharp tools…. I really don’t get the love for VSCode.<p>I’ve used Jetbrains for years and last week gave VSCode a really solid try.<p>Man what a mess. Everything is a plug-in, plug-ins are inconsistent, getting basic things to work requires a tsunami of plugins. Everything feels half baked and duplicated and needing updates or abandoned ugh.<p>Nothing feels professional because everything is a plug-in built by random person X or y or maybe some plugins are professional I don’t know.<p>And even when I’d plugged in as much stuff as I could find it still couldn’t do basic things like find and import node modules.<p>I abandoned the experiment and gladly went back to JetBrains where the tools are sharp, available and well organised.
The commenters in this thread don't seem to understand what it's like to be a new programmer, especially when you may not have had a burgeoning passion for computers your whole life. I too am a huge vim user but I would never recommend it to someone who doesn't <i>really</i> care about programming. You can make it your whole career without using vim. The subset of programmers on HN is very different from the industry at large. Most developers clock in, sling some Java and PHP for a few hours, and clock out. In general, this advice is fine. Maybe a little opinionated but who cares, they're valid opinions. If you're on HN, you're probably already disqualified from ever having needed this advice.
Regarding variable names strongly consider keeping the first variable name which comes to your head. It is simple, straightforward.<p>I often see overly elaborate variable names where I know the author took their time to come up with it ending up with an abstract variable name which makes far less sense.<p>Another tip for novice programmers: don't do leet code or watch random videos which talk about loops and variable naming. Instead watch or read about people building things. Imo we tend to prescribe these things too late in people's journeys. It would make far more sense for someone to watch a tsoding video on building something with Haskell rather than watch beginner Haskell tutorials.
This is great advice, although personally I will continue using vim over vscode. If vscode is a sharp kitchen knife then vim is a katana sword.<p>Novice programmers should probably not start with vim.
> "I think CS curricula should have a class that focuses specifically on these issues, on the matter of how do you actually write software?"<p>I agree. And for that reason, I liked these playlists: <a href="https://www.youtube.com/@MissingSemester/playlists">https://www.youtube.com/@MissingSemester/playlists</a>
> <i>Something we discussed that I forgot to include in the memo that we discussed is: After you fix something significant, or add significant new functionality, make a checkpoint copy of the entire source code. This can be as simple as simply copying it all into separate folder. That way, when you are fixing the next thing, if you mess up and break everything, it's easy to get back to a known-good state.</i><p>> <i>I think CS curricula should have a class that focuses specifically on these issues, on the matter of how do you actually write software?</i><p>God, I wish any of my classes had even <i>mentioned</i> version control. I graduated a year after git was released, so I probably wouldn't have been exposed to that, but how great would it be to not have the practice of having things like `something.2.old.php` scattered around the file system?
> ... start in VSCode... set aside time to do some tutorials...<p>Read a vim tutorial. Sheesh, I'm an emacs user and I think it's the greatest thing since sliced bread but I don't go around telling newbies that they should use <i>good</i> tools. vim's great. If that's what works for you, stick with it. You'll learn how to work with it eventually.
I am a vim user, and I agree, start with whatever text editor is reasonable, vim is not at that stage, if you were doing intro to system administration, vim prowess would be advisable, but not for learning to program.
Use vscode.<p>I think the advice are good, I'd like to add my own experience.. When I started programming, the hardest thing for me was
: Understanding how to build the source code into a binary, and what parts were "code that became the executable" and "code that makes the executable be created"<p>Too much magic at the beginning is terrible, don't start with Makefiles or CMake.<p>Start with a one-liner that directly calls the compiler and linker.<p>When your one-liner gets too long, make it into a script.<p>When you consider doing things in your script with loops or conditionals: Now is the time for a Makefile.<p>When your project moves out of your compter and into a wider community, and people start being annoyed at your build process, look into CMake.<p>Also, stay away from anything that is cloud, anything you can't execute locally, it only adds extra abstractions and error scenarios.<p>Paradoxically, the first environment in which I found it easy to get my code executed was with Apache and PHP, but the underlying infrastructure was rather complex, and it didn't allow me to do real programming, I couldn't open new windows or call any graphics APIs, but it was useful for learning algorithms and "thinking like a programmer".
I'm from the school of thought that when teaching beginners, it is completely okay to make things as smooth and easy as possible. After all, the goal is not to teach students how to become efficient with development tools, but to teach computer science.<p>Back when I took data structures & algorithms in college, the course was thought in C. Every assignment / project would be something like this:<p>1) SSH into some school server, navigate to the correct folders via the shell/CL.<p>2) Copy the assignment / project to your own student folder. To solve the problem the student would have to get familiar with the (rather small) codebase.<p>3) Upload your own source files etc. when you've solved the problems, create a makefile, etc.<p>4) The TAs would the run some script which tested all the different programs.<p>Pretty straight forward process. But, still, the students that aced these were obviously those that were experienced with using a shell, navigating code, somewhat experienced with the dev ops side of things.<p>The kids that were very fresh to coding, and had only ever taken the "101 introduction to programming" course were like fish out of water. To such a degree that many could simply not focus on the actual problems. Especially the larger projects would essentially be as much "Advanced C" + "dev ops" as DS&A, which IMO kind of went against the purpose of the course.<p>With that regard, I think it would have been better to just make the students solve the problem in some IDE, or even web application sandbox, and focus 100% on the DS&A part.
What I like about this format is that it's observing and addressing real problems someone actually had.<p>It's not a philosophical debate nor is it advice based on what someone did 20 years prior when they were a novice.<p>It's a programmer observing an actual novice and observing their actual problems.
> <i>When you start the next project, start it in VScode in the beginning.</i><p>That's just pushing your preferences onto the kid.<p>> <i>And maybe set aside an hour or two before you start in earnest, just to go through the VSCode tutorial and familiarize yourself with its basic features, without trying to do that at the same time you are actually thinking about your homework. This will pay off quickly.</i><p>Going through a tutorial works for Vim also.<p>> <i>copying files back and forth with scp</i><p>Wait, why back <i>and</i> forth? If you consistently edit here, and build there, it's unidirectional. A simple update script will do the scp. Copying back and forth will cause confusion. Where is the latest file, remote end or local? Oops, I made parallel changes to both, now what?<p>Good advice to the novice would be to teach them how to make a simple script to copy the files.<p>> <i>losing the network connection</i><p>If you must work over a terminal connection that drops, use termux or screen. Then you can reattach to a dropped session.<p>How about ... <i>don't do that</i>? This is not the 1970s; students don't work on a large, shared, departmental machine that wouldn't even fit in their home if they could afford it; you can have all the tools on your own machine.<p>Debug the program once locally, copy it once to the remote machine, build it there and test it again, done.<p>Katara has enough of a machine to run <i>scp</i> and Vim; but not actually build and debug the program? Does not compute.<p>My advice to novices would be that unless you're very lucky, your dad is unlikely to be a good source of advice. Most novices will get better advice from non-dad than dad.
> Debugging is methodical. Always have clear in your mind what question you are trying to answer, and what your plan is for investigating that question.<p>This is really excellent advice. I often try and debug in terms of the whole system. Explicitly having a hypothesis and then trying to verify or invalidate it with experimentation is a much better framing.
> <i>Debugging is an engineering discipline: You come up with a hypothesis, then test the hypothesis. Then you do it again.</i><p>I like this - I've given some form of this advice, but I usually say: "you should call your shots in pool".<p>You can flail about randomly and hope a ball goes in, but you won't get any better. You must be intentional, and train yourself to come up with and systematically work through hypotheses to get faster. This isn't getting better at programming - it's getting better at reasoning.<p>In my mind, this is also one of the main value-adds of working on "useless" projects. The end product isn't the point, the debugging and problem solving practice is.
I have a whole blog, with 100s of posts, about what I feel should be taught to new devs but is not.<p><a href="https://letterstoanewdeveloper.com/" rel="nofollow noreferrer">https://letterstoanewdeveloper.com/</a>
To a novice: 'Make it work, then make it better!'<p>Wasting cycles in already not-so-sure brains is not a practical way to gain confidence.<p>Having a code that works, boosts the novice's confidence greatly.<p>Review would help the novice get better. Just be practical in dispensing the review comments - gaining proficiency needs time, trial and error.<p>There is a good enough advice for any level of the novice, no need to try to mold the novice into a pro in one shot.<p>The most critical - make sure the novice understands the task they are to solve. And also they should have freedom and a way to declare that they got stuck and need help.
In wood shop in school, they teach you to use the saw, screwdriver, and tape measure before they say "make a box". Why not in programming shop?
This advice is really good, even excellent. The first bullet is very important, and often ignored: "you can't do good work with bad tools". I might prefer to say "use low friction workflows", but it's largely a semantic quibble. The insight here is that what makes a good set of tools for a novice programmers is different from what an expert programmer needs. Specifically, while VSCode is a great editor, it's maze of plugins and configs makes it quite challenging for a novice programmer. Something trivial like Notepad++ or nano is actually more appropriate for a novice. The new crop of web IDEs are also quite good for the novice and should be seriously considered for intro classes. No novice should be forced to manage ssh keys for their first assignment.<p>A novice student should be able to generate a working "hello, world" program in 10-20 minutes. This typically means leaving a lot of the software engineering aspect out of the workflow. That's all ok for a novice programmer. It is important for them to engage directly with the workflows.<p>For example, consider this SWIG tutorial: <a href="https://www.swig.org/tutorial.html" rel="nofollow noreferrer">https://www.swig.org/tutorial.html</a><p>Assuming you have a basic editor that you can use (nano) and an environment with all the dependencies installed, you can get a working python plugin built by reading 4-6 sentences, copying data into 2 files, and invoking 3 shell commands. This despite the fact that SWIG is a very deep and complex tool.<p>The debugging information is really important. I've seen classes where they do not discuss this at all with novice students. Kids need tools to troubleshoot their problems, desk checking code is difficult and only gets more difficult as the length of the programs grow.<p>The advice on avoiding long expressions is likewise golden. Long expressions are difficult to read, shorter ones are easier to read (this actually applies to variable names well - contrary to the advice in the article).<p>Finally, the advice on adhering to the DRY principle is not really applicable to novice programmers. Refactoring is hard. Writing library quality code is time consuming. Novice programmers should not be shamed for copy pasting 2-5 lines of code throughout their program. The topic of code organization, libraries, and SOLID principles are things to dig into after a novice has written a couple dozen programs.
Regarding #1:<p>> You lost a lot of time and energy dealing with issues like: Using vim; copying files back and forth with scp; losing the network connection; the college shared machine is slow and yucky.<p>Sometimes struggling with the tools you don't like and ending up at the ones you do build "character" and some familiarity with struggling with the unfamiliar. Those can be formative even if they're not "efficient" towards finishing an assignment as soon as possible. I think there's a balance to strike here, and as others have noted, some people _like_ vim and SCP, so which setup is "right" is subjective and requires a bit of struggling (albeit ideally time-boxed / within reason) to find it.<p>That said, I would've _killed_ to have this much help getting started as a novice programmer. I *love* how much effort and care this person puts into helping their kid(s) manage the whirlwind of early CS and university.
From MJD's post: <i>I think CS curricula should have a class that focuses specifically on these issues, on the matter of how do you actually write software?<p>But they never do.</i><p>FWIW, MIT's "The Missing Semester of Your CS Education" attempts to deal with this lack, though, even there, it was an unofficial course taught in 2020 between terms, during MIT's IAP -- Independent Activities Period[1] -- and not an actual CS course.<p>[0] <a href="https://missing.csail.mit.edu/" rel="nofollow noreferrer">https://missing.csail.mit.edu/</a><p>[1] <a href="https://en.wikipedia.org/wiki/Traditions_and_student_activities_at_MIT#Independent_Activities_Period" rel="nofollow noreferrer">https://en.wikipedia.org/wiki/Traditions_and_student_activit...</a>
Maybe somewhat off-topic, but visiting this URL causes my Ubiquiti setup to trigger a Security Alert about an Incoming connection from the IP that hosts plover.com related to TOR (screenshot of the alert: <a href="https://share.cleanshot.com/J1cfSd1W" rel="nofollow noreferrer">https://share.cleanshot.com/J1cfSd1W</a>)<p>Curious if anybody else experienced this, and what's behind it?
> After you fix something significant, or add significant new functionality, make a checkpoint copy of the entire source code<p>Aside from suggesting using git and committing frequently, this is one reason I use Jetbrains IDEs - local history. They make it really easy to go back and see local changes over time.
Your IDE may be saving after every keystroke, but make sure you're saving to a smart place.<p>2 weeks ago I started a new project, I was saving to /opt/ and then my machine crashed and I lost 2 weeks of work :(
> When you start the next project, start it in VScode<p>And use Edge and Teams. This surely will awake the programmer in you. But, for god's sake, don't touch the bugs. They are dirty. /s