Live data from Hacker News

Advice to a novice programmer

blog.plover.com

21–30 of 158 posts

Re: Advice to a novice programmer

#21
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

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.

Re: Advice to a novice programmer

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

Re: Advice to a novice programmer

#24

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 na…

> 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', 'Data'.

So please, newbs, don't use the first thing the comes to mind, if your understanding of what you're building is limited.

Re: Advice to a novice programmer

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

Re: Advice to a novice programmer

#26

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?

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.

Re: Advice to a novice programmer

#27

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.

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.

Re: Advice to a novice programmer

#28
> 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?

Re: Advice to a novice programmer

#29

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…

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.

Re: Advice to a novice programmer

#30

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 na…

> 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', ' Data'. So please, newbs, don't use the first thing the comes to mind, if your understanding of what you're building is limited.

A former coworker loved using `hold` as a "temporary" variable, that would inevitably be passed around everywhere. Along with its cousins, `hold1` and `holdA`.
Post reply on HN