28 ms·

Advice to a novice programmer

119 points by rrampage 3y ago

ghostpepper 3y ago
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. Novice programmers should probably not start with vim.
- Our_Benefactors 3y ago
  I did not start regularly using vim until about 6-8 years into my career. The switch came naturally as a result of working more heavily in shell environments. I still do most of my heavy coding in VScode.
  - LoganDark 3y ago
    we use nano ! because its keybinds are faster for us : 3 and the legend means we can't forget !
    - doubled112 3y ago
      > and the legend means we can't forget I am not sure what "the legend" is supposed to mean, but at least nano has the keyboard shortcuts displayed at the bottom so you can't forget those. Edit: Ahh yes, the other kind of legend. I was expecting some lore from the old days. I'm going to try some more coffee, but I suspect it won't help. Probably unsafe to drink it laughing at myself anyway.
      - LoganDark 3y ago
        > at least nano has the keyboard shortcuts displayed at the bottom so you can't forget those https://en.wikipedia.org/wiki/Map_layout#Legend https://en.wikipedia.org/wiki/Map_layout#Legend
      - ghostpepper 3y ago
        That's what a legend is. The term is widely used with maps.
      - Jtsummers 3y ago
        That is "the legend". It's a reference to maps which have (in the printed form) a legend displaying symbols and what they mean. Nano has that same concept in the form of displaying which keyboard shortcuts correspond to which behavior.
- joak 3y ago
  Dealing with vim plus learning to code is hard. And the reward comes later on. It makes sense to start with vscode...
- benrutter 3y ago
  I've been using terminal based modal editors for years, but I always recommend VS code for newbies. It has close to no learning required to start using it, and will take you pretty far.
- moffkalast 3y ago
  Vim is a katana sword alright, one with two blades and no hilt.
  - elteto 3y ago
    You must pinch it with your thumb and index fingers. Even so, many have become deadly text slayers this way.
  - ghostpepper 3y ago
    If you use it regularly you stop cutting yourself accidentally and generally become as effective as you would be with vscode, but every once in a while you effortless slice through a dozen enemy ninjas all at once and it's those moments that keep you coming back.
- IshKebab 3y ago
  I still don't really understand what Vim users see in it. They always seem to claim that you can edit faster... and sure you can if you're comparing with Notepad++. But modern editors have multiple cursors and tons of useful editing tools that let you be easily as fast with much less pain.
  - ghostpepper 3y ago
    can you go a full 8 hour work day without touching the mouse? edit: can you easily pipe the entire file through grep or awk, or insert the contents of the output of curl or jq?
    - qup 3y ago
      you do that in vim? I do that in terminal (I'm a heavy vim user) vscode subs for vim, not for the CLI
    - BreveDev 3y ago
      > can you go a full 8 hour work day without touching the mouse? What does this have to do with anything? If I felt the need to work this way, I absolutely could set up my Mac + any JetBrains IDE to do it, but to me it is an entirely unnecessary requirement. > can you easily pipe the entire file through grep or awk, or insert the contents of the output of curl or jq? Yes, and probably from within my IDE (if I cared to), which I probably won't do and don't need to because there exists other tools and plugins.
    - IshKebab 3y ago
      > can you go a full 8 hour work day without touching the mouse? No but I don't want to because mice are a great invention that make lots of tasks faster. Why artificially limit yourself by banning a mouse? Do you really browse the web without a mouse? > can you easily pipe the entire file through grep or awk, or insert the contents of the output of curl or jq? Yes? cat file | ... curl ... | pbcopy Anyway those are super rare tasks! Why would I pick an editor based on being able to do things I want to do a couple of times a month at the absolute most?
    - 3y ago
- andrewstuart 3y ago
  The biggest mistake I made when learning to code was trying to do it with vim. Get an IDE, I suggest JetBrains. I use vim everyday day as I work on Linux systems copying code and writing scripts and things but it should not be your primary development tool, certainly not for novices.
  - BD103 3y ago
    Jetbrains has good IDEs, but I've always disagreed with how much they abstract over "running" programs. Run configurations are great for projects where you iterate quickly, but they do not teach newcomers how to use the command line. I've seen this hurt new programmers in practice when they talk about "command line witchcraft," when really it's a very useful tool.
- ThrowawayR2 3y ago
  > "...vim is a katana sword." Vastly overhyped and overrated by Japanophiles, requires a lot of dedication and learning to use properly, and a hassle to use for day-to-day household tasks? Sounds about right, dohohoho. (I'm kidding, I'm kidding...)
  - a1369209993 3y ago
    No, aside from not being literally Japanophiles specifically, that does in fact sound about right, unironically. Likewise Emacs. But VSCode (/JetBrains/etc) is more like a Internet-of-Things version of one of those meat-and-cheese-slicing machines they use in delis: needlessly oversized, optimised for producing stuff in large quantities with no attention to detail, and cannot be used correctly anyway because you can never be sure the next software update won't brick it or cause it up phone home all your information to the malware developer you got it from, because the S in IoT is for security. Notepad, of course, is a rusty butter knife with suspicious-looking stains on it, while ed is a sharp piece of flint (with different suspicious-looking stains). (Does $ echo ' printf("Hello, World!\n");' >> hello.c count as tearing up raw ingredients with your teeth? This metaphore kind of got away from me.)
- Shorel 3y ago
  I have tried, many times, I even have some plugins installed like git-gutter, etc. It's not for me, thanks. I went back to Sublime Text and will only use vim in case of emergency, and only if I get paid for it.
binidxaba 3y ago
> "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 agree. And for that reason, I liked these playlists: https://www.youtube.com/@MissingSemester/playlists https://www.youtube.com/@MissingSemester/playlists
mooreds 3y ago
I have a whole blog, with 100s of posts, about what I feel should be taught to new devs but is not. https://letterstoanewdeveloper.com/ https://letterstoanewdeveloper.com/
- ghostpepper 3y ago
  Ironically, it's not realistic to ask a newbie to read hundreds of posts or to know which ones to look at. Are there 2-3 you'd recommend starting with?
  - mooreds 3y ago
    Fair enough. There's a 'start here' sidebar with some of the most popular and best advice.
FigurativeVoid 3y ago
> 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. 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.
OliverJones 3y ago
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?
- lelandbatey 3y ago
  Cause even the simplest "app" that a usual user is familiar with is much less of a "box" and more of a "house" (in scope). If you tell users to "build a box" they will often say "what is a box?" or "why do I care about a box?" and they'll often disengage at that point. Woodshop starts with "before you can build a box, you must learn the tools" because the students already know what a box is, they probably already know what "wood" is, they understand that "there are tools, such as saws and drills and hammers" even if they don't understand necessarily how to correctly use those tools. Meanwhile in beginner programming, students have so little context that you almost have to start with "here's the concept of vision and touch". So to keep students focused on something they understand, we don't focus on the tools (at first), we focus on the outcome, with the tools merely as a means to an end, and mostly we give the students "rote procedures" that they must carry out exactly in order to get something that they do understand. Later, once they've begun to become aware of what even exists, what the "box" of the programming world even is, that there are tools for doing different things, what those tools are, etc. Then we start showing them how to use things.
- livrem 3y ago
  As I mentioned elsewhere here, at university in the first undergraduate computer course we started out with a unix+emacs intro. It sounds unreasonable to me to just start out asking kids to write code without first showing them the tools they need?
LouisSayers 3y ago
> After you fix something significant, or add significant new functionality, make a checkpoint copy of the entire source code 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.
ilrwbwrkhv 3y ago
Regarding variable names strongly consider keeping the first variable name which comes to your head. It is simple, straightforward. 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. 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.
- cratermoon 3y ago
  > strongly consider keeping the first variable name which comes to your head Apparently the first and only thing that came to the minds of the developers on the last project I consulted on was "data", so we had variables named 'datablob', 'dataProvider', '<thing>Data'. So please, newbs, don't use the first thing the comes to mind, if your understanding of what you're building is limited.
  - pavel_lishin 3y ago
    A former coworker loved using `hold` as a "temporary" variable, that would inevitably be passed around everywhere. Along with its cousins, `hold1` and `holdA`.
- tmtvl 3y ago
  > consider keeping the first variable name which comes to your head. It is simple, straightforward. That strongly differs from person to person, I am the kind of guy who immediately comes up with names like glass-hardness-at-temperature-in-centigrade-before-tempering before refactoring it to untempered-glass-hardness-at-centigrade. > Instead watch or read about people building things. Definitely watch/read those too, but there's nothing wrong with watching e.g. the MIT OpenCourseWare Structure and Interpretation of Computer Programs (SICP) videos.
- lainga 3y ago
  > the first variable name which comes to your head. I do this. I do it, but I will say it's not for everyone, including me. There have been a lot of "jimmy" and "pibbo" over the years. Keep the first name that doesn't embarrass you...
andrewprock 3y ago
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. 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. For example, consider this SWIG tutorial: https://www.swig.org/tutorial.html https://www.swig.org/tutorial.html 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. 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. 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). 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.
agentultra 3y ago
> ... start in VSCode... set aside time to do some tutorials... 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 good tools. vim's great. If that's what works for you, stick with it. You'll learn how to work with it eventually.
- conor- 3y ago
  You don't even have to read a vim tutorial. The tutorial is already baked in. I learned vim by doing vimtutor every couple of months to learn more advanced features after getting basic navigation and editing motions down and forcing myself to use it for as much of my work as I possibly can. Learning vim early paid dividends in terms of productivity and also by forcing me to learn more about how to actually leverage other coreutils around vim to get the most out of it. The path of learning that way from the start is slower and more difficult, but the skill ceiling it unlocks is much higher in the long run imo.
  - infrabr0 3y ago
    > I learned vim by doing vimtutor every couple of months to learn more advanced features after getting basic navigation I think you're missing the point. Should a novice programmer postpone their education by months because they need to satisfy the imaginary pre-requisite of learning vim via vimtutor? There's a lot of thinking involved at all levels let alone at the novice stages. I cant imagine how frustrating it'd be to understand closures + remembering that ci" changes the expressions inside double quotes.
    - agentultra 3y ago
      I suspect there’s also no small amount of exaggerating how much work it is to learn enough about vim to get proficient. The basic tutorial takes a couple hours? It’s not that big of a deal compared to how long it takes to learn how to program. I just find it funny that for both VSCode and vim, the advice is the same but one is considered easier/better than the other.
    - 3y ago
pprotas 3y ago
I use vim therefore disagree
icyberbullyu 3y ago
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. 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. 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.
- linsomniac 3y ago
  As someone who is a die-hard vim user, I agree with the article. The amount of time over the last nearly 40 years of using vi, which I've spent messing around with vim configs and plugins, trying to get a smarter editor, has been amazing. Over the last year I've switched to LunarVim, which is a pre-packaged vim setup with all the plugins and configs, and an LSP and TreeSitter, and it's been amazing. All the "IDE-like" setups I had done in the past either were half-baked or ended up breaking in obtuse ways fairly quickly. LunarVim is giving me great code suggestions from the LSP and really is a game changer from my various older vim setups. I catch so many errors I would have run into at runtime now that I'm getting python type annotation messages right in my editor.
- pavel_lishin 3y ago
  I don't think he was shitting on command line tools; he was shitting on the remote machine his child was having to use, which was slow and unreliable. > 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. Colleges should make this distinction clearer as well. I got a CS degree, and my belief was that I was being taught how to become a software engineer.
pavel_lishin 3y ago
> 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 think CS curricula should have a class that focuses specifically on these issues, on the matter of how do you actually write software? God, I wish any of my classes had even mentioned 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?
- 63 3y ago
  I talked to my department head about this before I graduated and the answer was basically that new programmers have enough to worry about already and, frankly, she didn't want to have to answer constant emails about how to do or undo this or that in git. I think this was fair enough. Version control is useful but git is a huge pain for newbies and the students who get internships or work on open source learn it on their own anyway.
andrewstuart 3y ago
Speaking of using sharp tools…. I really don’t get the love for VSCode. I’ve used Jetbrains for years and last week gave VSCode a really solid try. 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. 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. 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. I abandoned the experiment and gladly went back to JetBrains where the tools are sharp, available and well organised.
- jdc0589 3y ago
  100%. I'd be using jetbrains stuff right now if I wasn't experiencing weird inexplicable issues with Rider in the .netcore stack. Legit the first real issues I've had with their stuff in over 10 years.
- stinkbutt 3y ago
  i tried Goland (the Jetbrains IDE for Go) and when my mouse hovers over a variable the IDE does not provide a tool tip that tells me what its type is. And for that reason I've stuck with VS Code.
  - deleted 3y ago
    [deleted]
  - Carducci 3y ago
    This is simply not true. I have been using Goland since the first beta and can remember this feature being in there and using since then.
- tpmx 3y ago
  I used Emacs for about two decades. It worked well and did exactly what I wanted it to. Then I started using Copilot+VSCode while learning a for me new language (Python) this spring. I've grown rather fond of VSCode since, to be honest. This extension by Yuichiro Tachibana is the one to use to get Emacs keybindings, btw: https://marketplace.visualstudio.com/items?itemName=tuttieee.emacs-mcx https://marketplace.visualstudio.com/items?itemName=tuttieee...
eterm 3y ago
What I like about this format is that it's observing and addressing real problems someone actually had. It's not a philosophical debate nor is it advice based on what someone did 20 years prior when they were a novice. It's a programmer observing an actual novice and observing their actual problems.
zoomablemind 3y ago
To a novice: 'Make it work, then make it better!' Wasting cycles in already not-so-sure brains is not a practical way to gain confidence. Having a code that works, boosts the novice's confidence greatly. Review would help the novice get better. Just be practical in dispensing the review comments - gaining proficiency needs time, trial and error. 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. 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.
Willish42 3y ago
Regarding #1: > 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. 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. 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.
kazinator 3y ago
> When you start the next project, start it in VScode in the beginning. That's just pushing your preferences onto the kid. > 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. Going through a tutorial works for Vim also. > copying files back and forth with scp Wait, why back and 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? Good advice to the novice would be to teach them how to make a simple script to copy the files. > losing the network connection If you must work over a terminal connection that drops, use termux or screen. Then you can reattach to a dropped session. How about ... don't do that? 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. Debug the program once locally, copy it once to the remote machine, build it there and test it again, done. Katara has enough of a machine to run scp and Vim; but not actually build and debug the program? Does not compute. 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.
hiroprot 3y ago
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: https://share.cleanshot.com/J1cfSd1W https://share.cleanshot.com/J1cfSd1W) Curious if anybody else experienced this, and what's behind it?
- hiroprot 3y ago
  This was a fun distraction to track down...looks like the IP that this site is hosted on is in some IDS rulesets, likely this one, which Ubiquiti uses: https://github.com/vncloudsco/suricata-rules/blob/main/tor.rules https://github.com/vncloudsco/suricata-rules/blob/main/tor.r... Looks harmless, but I learned something new today :)
robtaglang 3y ago
> Debugging is an engineering discipline: You come up with a hypothesis, then test the hypothesis. Then you do it again. I like this - I've given some form of this advice, but I usually say: "you should call your shots in pool". 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. 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.
63 3y ago
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 really 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.
qohen 3y ago
From MJD's post: I think CS curricula should have a class that focuses specifically on these issues, on the matter of how do you actually write software? But they never do. 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. [0] https://missing.csail.mit.edu/ https://missing.csail.mit.edu/ [1] https://en.wikipedia.org/wiki/Traditions_and_student_activities_at_MIT#Independent_Activities_Period https://en.wikipedia.org/wiki/Traditions_and_student_activit...
throwaway5959 3y ago
My advice to a novice programmer is to find another profession that doesn’t involve “agile” and “scrum masters”.
dusted 3y ago
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. 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" Too much magic at the beginning is terrible, don't start with Makefiles or CMake. Start with a one-liner that directly calls the compiler and linker. When your one-liner gets too long, make it into a script. When you consider doing things in your script with loops or conditionals: Now is the time for a Makefile. 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. Also, stay away from anything that is cloud, anything you can't execute locally, it only adds extra abstractions and error scenarios. 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".
incomingpain 3y ago
Your IDE may be saving after every keystroke, but make sure you're saving to a smart place. 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 :(
streakfix 3y ago
Most of this would be useful for intermediate level programmers as well.
TrackerFF 3y ago
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. Back when I took data structures & algorithms in college, the course was thought in C. Every assignment / project would be something like this: 1) SSH into some school server, navigate to the correct folders via the shell/CL. 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. 3) Upload your own source files etc. when you've solved the problems, create a makefile, etc. 4) The TAs would the run some script which tested all the different programs. 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. 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. 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.
hulitu 3y ago
> When you start the next project, start it in VScode 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

119 points by rrampage 3y ago

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. Novice programmers should probably not start with vim.

Our_Benefactors 3y ago
I did not start regularly using vim until about 6-8 years into my career. The switch came naturally as a result of working more heavily in shell environments. I still do most of my heavy coding in VScode.
- LoganDark 3y ago
  we use nano ! because its keybinds are faster for us : 3 and the legend means we can't forget !
  - doubled112 3y ago
    > and the legend means we can't forget I am not sure what "the legend" is supposed to mean, but at least nano has the keyboard shortcuts displayed at the bottom so you can't forget those. Edit: Ahh yes, the other kind of legend. I was expecting some lore from the old days. I'm going to try some more coffee, but I suspect it won't help. Probably unsafe to drink it laughing at myself anyway.
    - LoganDark 3y ago
      > at least nano has the keyboard shortcuts displayed at the bottom so you can't forget those https://en.wikipedia.org/wiki/Map_layout#Legend https://en.wikipedia.org/wiki/Map_layout#Legend
    - ghostpepper 3y ago
      That's what a legend is. The term is widely used with maps.
    - Jtsummers 3y ago
      That is "the legend". It's a reference to maps which have (in the printed form) a legend displaying symbols and what they mean. Nano has that same concept in the form of displaying which keyboard shortcuts correspond to which behavior.
joak 3y ago
Dealing with vim plus learning to code is hard. And the reward comes later on. It makes sense to start with vscode...
benrutter 3y ago
I've been using terminal based modal editors for years, but I always recommend VS code for newbies. It has close to no learning required to start using it, and will take you pretty far.
moffkalast 3y ago
Vim is a katana sword alright, one with two blades and no hilt.
- elteto 3y ago
  You must pinch it with your thumb and index fingers. Even so, many have become deadly text slayers this way.
- ghostpepper 3y ago
  If you use it regularly you stop cutting yourself accidentally and generally become as effective as you would be with vscode, but every once in a while you effortless slice through a dozen enemy ninjas all at once and it's those moments that keep you coming back.
IshKebab 3y ago
I still don't really understand what Vim users see in it. They always seem to claim that you can edit faster... and sure you can if you're comparing with Notepad++. But modern editors have multiple cursors and tons of useful editing tools that let you be easily as fast with much less pain.
- ghostpepper 3y ago
  can you go a full 8 hour work day without touching the mouse? edit: can you easily pipe the entire file through grep or awk, or insert the contents of the output of curl or jq?
  - qup 3y ago
    you do that in vim? I do that in terminal (I'm a heavy vim user) vscode subs for vim, not for the CLI
  - BreveDev 3y ago
    > can you go a full 8 hour work day without touching the mouse? What does this have to do with anything? If I felt the need to work this way, I absolutely could set up my Mac + any JetBrains IDE to do it, but to me it is an entirely unnecessary requirement. > can you easily pipe the entire file through grep or awk, or insert the contents of the output of curl or jq? Yes, and probably from within my IDE (if I cared to), which I probably won't do and don't need to because there exists other tools and plugins.
  - IshKebab 3y ago
    > can you go a full 8 hour work day without touching the mouse? No but I don't want to because mice are a great invention that make lots of tasks faster. Why artificially limit yourself by banning a mouse? Do you really browse the web without a mouse? > can you easily pipe the entire file through grep or awk, or insert the contents of the output of curl or jq? Yes? cat file | ... curl ... | pbcopy Anyway those are super rare tasks! Why would I pick an editor based on being able to do things I want to do a couple of times a month at the absolute most?
  - 3y ago
andrewstuart 3y ago
The biggest mistake I made when learning to code was trying to do it with vim. Get an IDE, I suggest JetBrains. I use vim everyday day as I work on Linux systems copying code and writing scripts and things but it should not be your primary development tool, certainly not for novices.
- BD103 3y ago
  Jetbrains has good IDEs, but I've always disagreed with how much they abstract over "running" programs. Run configurations are great for projects where you iterate quickly, but they do not teach newcomers how to use the command line. I've seen this hurt new programmers in practice when they talk about "command line witchcraft," when really it's a very useful tool.
ThrowawayR2 3y ago
> "...vim is a katana sword." Vastly overhyped and overrated by Japanophiles, requires a lot of dedication and learning to use properly, and a hassle to use for day-to-day household tasks? Sounds about right, dohohoho. (I'm kidding, I'm kidding...)
- a1369209993 3y ago
  No, aside from not being literally Japanophiles specifically, that does in fact sound about right, unironically. Likewise Emacs. But VSCode (/JetBrains/etc) is more like a Internet-of-Things version of one of those meat-and-cheese-slicing machines they use in delis: needlessly oversized, optimised for producing stuff in large quantities with no attention to detail, and cannot be used correctly anyway because you can never be sure the next software update won't brick it or cause it up phone home all your information to the malware developer you got it from, because the S in IoT is for security. Notepad, of course, is a rusty butter knife with suspicious-looking stains on it, while ed is a sharp piece of flint (with different suspicious-looking stains). (Does $ echo ' printf("Hello, World!\n");' >> hello.c count as tearing up raw ingredients with your teeth? This metaphore kind of got away from me.)
Shorel 3y ago
I have tried, many times, I even have some plugins installed like git-gutter, etc. It's not for me, thanks. I went back to Sublime Text and will only use vim in case of emergency, and only if I get paid for it.

binidxaba 3y ago

> "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 agree. And for that reason, I liked these playlists: https://www.youtube.com/@MissingSemester/playlists https://www.youtube.com/@MissingSemester/playlists

mooreds 3y ago

I have a whole blog, with 100s of posts, about what I feel should be taught to new devs but is not. https://letterstoanewdeveloper.com/ https://letterstoanewdeveloper.com/

ghostpepper 3y ago
Ironically, it's not realistic to ask a newbie to read hundreds of posts or to know which ones to look at. Are there 2-3 you'd recommend starting with?
- mooreds 3y ago
  Fair enough. There's a 'start here' sidebar with some of the most popular and best advice.

FigurativeVoid 3y ago

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

OliverJones 3y ago

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?

lelandbatey 3y ago
Cause even the simplest "app" that a usual user is familiar with is much less of a "box" and more of a "house" (in scope). If you tell users to "build a box" they will often say "what is a box?" or "why do I care about a box?" and they'll often disengage at that point. Woodshop starts with "before you can build a box, you must learn the tools" because the students already know what a box is, they probably already know what "wood" is, they understand that "there are tools, such as saws and drills and hammers" even if they don't understand necessarily how to correctly use those tools. Meanwhile in beginner programming, students have so little context that you almost have to start with "here's the concept of vision and touch". So to keep students focused on something they understand, we don't focus on the tools (at first), we focus on the outcome, with the tools merely as a means to an end, and mostly we give the students "rote procedures" that they must carry out exactly in order to get something that they do understand. Later, once they've begun to become aware of what even exists, what the "box" of the programming world even is, that there are tools for doing different things, what those tools are, etc. Then we start showing them how to use things.
livrem 3y ago
As I mentioned elsewhere here, at university in the first undergraduate computer course we started out with a unix+emacs intro. It sounds unreasonable to me to just start out asking kids to write code without first showing them the tools they need?

LouisSayers 3y ago

> After you fix something significant, or add significant new functionality, make a checkpoint copy of the entire source code 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.

ilrwbwrkhv 3y ago

Regarding variable names strongly consider keeping the first variable name which comes to your head. It is simple, straightforward. 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. 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.

cratermoon 3y ago
> strongly consider keeping the first variable name which comes to your head Apparently the first and only thing that came to the minds of the developers on the last project I consulted on was "data", so we had variables named 'datablob', 'dataProvider', '<thing>Data'. So please, newbs, don't use the first thing the comes to mind, if your understanding of what you're building is limited.
- pavel_lishin 3y ago
  A former coworker loved using `hold` as a "temporary" variable, that would inevitably be passed around everywhere. Along with its cousins, `hold1` and `holdA`.
tmtvl 3y ago
> consider keeping the first variable name which comes to your head. It is simple, straightforward. That strongly differs from person to person, I am the kind of guy who immediately comes up with names like glass-hardness-at-temperature-in-centigrade-before-tempering before refactoring it to untempered-glass-hardness-at-centigrade. > Instead watch or read about people building things. Definitely watch/read those too, but there's nothing wrong with watching e.g. the MIT OpenCourseWare Structure and Interpretation of Computer Programs (SICP) videos.
lainga 3y ago
> the first variable name which comes to your head. I do this. I do it, but I will say it's not for everyone, including me. There have been a lot of "jimmy" and "pibbo" over the years. Keep the first name that doesn't embarrass you...

andrewprock 3y ago

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. 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. For example, consider this SWIG tutorial: https://www.swig.org/tutorial.html https://www.swig.org/tutorial.html 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. 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. 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). 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.

agentultra 3y ago

> ... start in VSCode... set aside time to do some tutorials... 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 good tools. vim's great. If that's what works for you, stick with it. You'll learn how to work with it eventually.

conor- 3y ago
You don't even have to read a vim tutorial. The tutorial is already baked in. I learned vim by doing vimtutor every couple of months to learn more advanced features after getting basic navigation and editing motions down and forcing myself to use it for as much of my work as I possibly can. Learning vim early paid dividends in terms of productivity and also by forcing me to learn more about how to actually leverage other coreutils around vim to get the most out of it. The path of learning that way from the start is slower and more difficult, but the skill ceiling it unlocks is much higher in the long run imo.
- infrabr0 3y ago
  > I learned vim by doing vimtutor every couple of months to learn more advanced features after getting basic navigation I think you're missing the point. Should a novice programmer postpone their education by months because they need to satisfy the imaginary pre-requisite of learning vim via vimtutor? There's a lot of thinking involved at all levels let alone at the novice stages. I cant imagine how frustrating it'd be to understand closures + remembering that ci" changes the expressions inside double quotes.
  - agentultra 3y ago
    I suspect there’s also no small amount of exaggerating how much work it is to learn enough about vim to get proficient. The basic tutorial takes a couple hours? It’s not that big of a deal compared to how long it takes to learn how to program. I just find it funny that for both VSCode and vim, the advice is the same but one is considered easier/better than the other.
  - 3y ago

pprotas 3y ago

I use vim therefore disagree

icyberbullyu 3y ago

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

linsomniac 3y ago
As someone who is a die-hard vim user, I agree with the article. The amount of time over the last nearly 40 years of using vi, which I've spent messing around with vim configs and plugins, trying to get a smarter editor, has been amazing. Over the last year I've switched to LunarVim, which is a pre-packaged vim setup with all the plugins and configs, and an LSP and TreeSitter, and it's been amazing. All the "IDE-like" setups I had done in the past either were half-baked or ended up breaking in obtuse ways fairly quickly. LunarVim is giving me great code suggestions from the LSP and really is a game changer from my various older vim setups. I catch so many errors I would have run into at runtime now that I'm getting python type annotation messages right in my editor.
pavel_lishin 3y ago
I don't think he was shitting on command line tools; he was shitting on the remote machine his child was having to use, which was slow and unreliable. > 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. Colleges should make this distinction clearer as well. I got a CS degree, and my belief was that I was being taught how to become a software engineer.

pavel_lishin 3y ago

> 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 think CS curricula should have a class that focuses specifically on these issues, on the matter of how do you actually write software? God, I wish any of my classes had even mentioned 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?

63 3y ago
I talked to my department head about this before I graduated and the answer was basically that new programmers have enough to worry about already and, frankly, she didn't want to have to answer constant emails about how to do or undo this or that in git. I think this was fair enough. Version control is useful but git is a huge pain for newbies and the students who get internships or work on open source learn it on their own anyway.

andrewstuart 3y ago

Speaking of using sharp tools…. I really don’t get the love for VSCode. I’ve used Jetbrains for years and last week gave VSCode a really solid try. 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. 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. 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. I abandoned the experiment and gladly went back to JetBrains where the tools are sharp, available and well organised.

jdc0589 3y ago
100%. I'd be using jetbrains stuff right now if I wasn't experiencing weird inexplicable issues with Rider in the .netcore stack. Legit the first real issues I've had with their stuff in over 10 years.
stinkbutt 3y ago
i tried Goland (the Jetbrains IDE for Go) and when my mouse hovers over a variable the IDE does not provide a tool tip that tells me what its type is. And for that reason I've stuck with VS Code.
- deleted 3y ago
  [deleted]
- Carducci 3y ago
  This is simply not true. I have been using Goland since the first beta and can remember this feature being in there and using since then.
tpmx 3y ago
I used Emacs for about two decades. It worked well and did exactly what I wanted it to. Then I started using Copilot+VSCode while learning a for me new language (Python) this spring. I've grown rather fond of VSCode since, to be honest. This extension by Yuichiro Tachibana is the one to use to get Emacs keybindings, btw: https://marketplace.visualstudio.com/items?itemName=tuttieee.emacs-mcx https://marketplace.visualstudio.com/items?itemName=tuttieee...

eterm 3y ago

What I like about this format is that it's observing and addressing real problems someone actually had. It's not a philosophical debate nor is it advice based on what someone did 20 years prior when they were a novice. It's a programmer observing an actual novice and observing their actual problems.

zoomablemind 3y ago

To a novice: 'Make it work, then make it better!' Wasting cycles in already not-so-sure brains is not a practical way to gain confidence. Having a code that works, boosts the novice's confidence greatly. Review would help the novice get better. Just be practical in dispensing the review comments - gaining proficiency needs time, trial and error. 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. 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.

Willish42 3y ago

Regarding #1: > 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. 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. 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.

kazinator 3y ago

> When you start the next project, start it in VScode in the beginning. That's just pushing your preferences onto the kid. > 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. Going through a tutorial works for Vim also. > copying files back and forth with scp Wait, why back and 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? Good advice to the novice would be to teach them how to make a simple script to copy the files. > losing the network connection If you must work over a terminal connection that drops, use termux or screen. Then you can reattach to a dropped session. How about ... don't do that? 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. Debug the program once locally, copy it once to the remote machine, build it there and test it again, done. Katara has enough of a machine to run scp and Vim; but not actually build and debug the program? Does not compute. 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.

hiroprot 3y ago

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: https://share.cleanshot.com/J1cfSd1W https://share.cleanshot.com/J1cfSd1W) Curious if anybody else experienced this, and what's behind it?

hiroprot 3y ago
This was a fun distraction to track down...looks like the IP that this site is hosted on is in some IDS rulesets, likely this one, which Ubiquiti uses: https://github.com/vncloudsco/suricata-rules/blob/main/tor.rules https://github.com/vncloudsco/suricata-rules/blob/main/tor.r... Looks harmless, but I learned something new today :)

robtaglang 3y ago

> Debugging is an engineering discipline: You come up with a hypothesis, then test the hypothesis. Then you do it again. I like this - I've given some form of this advice, but I usually say: "you should call your shots in pool". 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. 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.

63 3y ago

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

qohen 3y ago

From MJD's post: I think CS curricula should have a class that focuses specifically on these issues, on the matter of how do you actually write software? But they never do. 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. [0] https://missing.csail.mit.edu/ https://missing.csail.mit.edu/ [1] https://en.wikipedia.org/wiki/Traditions_and_student_activities_at_MIT#Independent_Activities_Period https://en.wikipedia.org/wiki/Traditions_and_student_activit...

throwaway5959 3y ago

My advice to a novice programmer is to find another profession that doesn’t involve “agile” and “scrum masters”.

dusted 3y ago

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. 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" Too much magic at the beginning is terrible, don't start with Makefiles or CMake. Start with a one-liner that directly calls the compiler and linker. When your one-liner gets too long, make it into a script. When you consider doing things in your script with loops or conditionals: Now is the time for a Makefile. 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. Also, stay away from anything that is cloud, anything you can't execute locally, it only adds extra abstractions and error scenarios. 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".

incomingpain 3y ago

Your IDE may be saving after every keystroke, but make sure you're saving to a smart place. 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 :(

streakfix 3y ago

Most of this would be useful for intermediate level programmers as well.

TrackerFF 3y ago

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. Back when I took data structures & algorithms in college, the course was thought in C. Every assignment / project would be something like this: 1) SSH into some school server, navigate to the correct folders via the shell/CL. 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. 3) Upload your own source files etc. when you've solved the problems, create a makefile, etc. 4) The TAs would the run some script which tested all the different programs. 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. 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. 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.

hulitu 3y ago

> When you start the next project, start it in VScode 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