Advice to a novice programmer | Hacker News Reader

Advice to a novice programmer

blog.plover.com

119 pointsrrampage153 comments

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.

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.

This. Software engineering needs to be a separate field from CS, as mechanical engineering is a separate field from physics.

But maybe it's good that you were taught how to become a software engineer. My guess is that 90-95% of CS grads will actually work as software engineers.

But, a question if I may: How good of a software engineering training was the CS degree? Would a real software engineering degree have done a better job?

> But, a question if I may: How good of a software engineering training was the CS degree? Would a real software engineering degree have done a better job?

In my opinion, it was pretty bad. We didn't get to write much code after CS 101, and we only had one group project in a class that I cannot remember - so there wasn't much opportunity to learn how to develop in a collaborative environment.

What this meant for me is that I learned on the job, and my first job was at a very small PHP/JS shop where I learned some very bad habits that I didn't know were bad habits at the time.

I think a software engineering degree would have been significantly more useful, and I don't think the CS portion of it would have had to suffer much. I think the college even offered that degree at the time; I'm not sure why I didn't switch.

Software engineer training without engineering training is just programming training. Doing a CS degree does not automatically entitle one to call themselves an engineer. You're a programmer, not an engineer.

This discussion has been hashed out many a time. While they may not be an engineer by designation (PEng), the word is used often enough to refer to programmers that it is pedantic to reiterate the fact that they aren't "real" engineers.

> I don't think he was shitting on command line tools

Yes he is; he put "You can't do good work with bad tools" in bold.

Well you'd find it hard to do good work with a hammer made from cardboard but that doesn't mean all hammers are bad.

I found VSCode's remote plugins to be a really good option when the code lives on a shared remote machine over a slow connection. vim+scp is an extra step on each change, vim over ssh is just awkward, and sshfs isn't the most reliable piece of software.

> vim over ssh is just awkward

What's wrong with vim over ssh/mosh? I was taught emacs by a grad student back in college and the ability to be fully productive on any server where I can install emacs has been a huge benefit to my career. I can't imagine vim is much different in that scenario.

Most people don't use vanilla vim, from what I've seen. It's not so great, out of the box. Definitely not comparable to any remote editor these days, that also supports vim navigation, like VSCode.

What does vim lack that one might need to complete a basic programming assignment?

Integrated linters save a lot of time with their immediate feedback. Depending on the language you're working with, remote debugging can be an incredible time saver. Modern editors are aware of the structure of the code, so can do things that are impossible for default VIM to do, like find the usage of a variable, rather than text occurrences, automatically show documentation, etc. All time savings.

Agreed, good points. I guess I still wonder whether these are needed for an introductory assignment. A vim/ssh workflow seems more future-proof than any particular IDE. As an instructor maybe it would make sense to do the first assignment with low-level tools, then introduce VSCode/etc and briefly demo these things, to make the added convenience even more visceral to the novice.

> would make sense to do the first assignment with low-level tool

Sure, but if the goal is to teach programming, I think vim massively confuses a beginner. vim is hard for beginners, famously so. Something like VSCode, used as a remote text editor, is trivial and familiar to anyone who has used at MS Word. I agree it should be introduced, but there's definitely some cargo cult around vim and "the old ways".

Idk, if we're working on a remote machine already, it's not the student's first day. The bar to basic editing with vim is pretty low. Mode switch with i and esc, :x to save/exit, navigate where your fingers already are, slash to find. That all fits on a sticky note if it isn't already memorized in the first 30 seconds. They've likely played video games their whole lives, I struggle to see how mapping buttons to behaviors is a foreign or difficult concept.

As you say we're teaching programming. The ability to pick up an unfamiliar tool and get to know it on the fly is critical and the only way to develop it is practice.

That said, maybe there is no right answer here. I imagine the instructor's broader approach will make the difference, not which editor they make the class use for assignment three :)

These days you don't edit things on servers. The most you might do is edit a file and change a single option. You can do that in vi, vim or nano. Certainly you don't get to install you favorite editor (and version) and the .config folder an every server.

Most of the time you'll be editing config locally on your laptop and it'll get pushed to the servers via config management or whatever.

Your laptop is the place for your tricked-out IDE with 27 plugins

I learned vi on a Tandy Model 16 running Xenix. The Xenix console driver, for whatever reason, throttles comms to the display to 9600 baud. It was fine. Today a "slow connection" is megabytes per second. Latency may be an issue, but otherwise vim, or any terminal-based editor, will run nicely over any modern connection.

By contrast, VS Code needs to inject itself, plus any plug-ins, over to the remote side. Wanna know how long that can take if the link isn't decently fast?

You're talking about this right?

> I think CS curricula should have a class that focuses specifically on these issues, on the matter of how do you actually write software?

Are you really opposed to "a class" on writing software being included in CS curricula? CS courses have plenty of writing software.

"We're going to ask you to write code for four years. Professional coding may not be the point of this curriculum but coding is still the primary way you're going to interact with it. And don't you dare take even a week to sharpen the saw out of those those four years, because that's not the point of this curriculum! Saw with that dull saw! Saw harder! Because sawing is not the point of this school, so we're not going to teach you, so just saw harder!"

How is this a sensible position? It's not even "vocational training" being called for here, it's basic fundamentals for anyone who is going to code. I can tell you from experience that data scientists could stand to be oriented on the basics of this stuff too, and it would pay off in less time than just the course that taught it, let alone the full curriculum, let alone a career.

This is agreement with you, btw. Of course the very basics of management of programming should be taught. Of course the stuff in the blog post should be taught formally in some introductory class. Who trains their football players by just having them play games over and over? Who teaches musicians by just having them play concert music? Who expects English students to improve by just writing journal articles continuously? Every field has some sort of basics to it that aren't the actual output of the field but will cause anyone who is weak in them to waste arbitrary amounts of time spinning uselessly on useless irrelevancies.

If the short term goal is to finish a project by a deadline, just use vscode. Teach yourself vim and scp later.

I think this type of attitude doesn't stop here. Vim is the topic but if you also are taking the easy paths you tend to get stuck. Sometimes you have good tools you just don't know how to use them. That doesn't mean you should throw out the tools you have and buy new ones immediately though. This can work for vim but in general reaching for something that is easy is not always the right solution especially while in college you hace classes yes but you don't have the pressure of actual deadlines and deliverables where you don't have the time to learn

Real life example I have a guy at work who didn't have the time to learn git beyond git clone. He's not a software engineer but his workflow to get things to "work" was to create a new directory everyday and clone the repos he needed. The next day he'd do the same thing again and again until his disk drive was full and than he'd delete the old directories because he thought he didn't need them anymore. This work style was ludicrous but he didn't have the time. 1, 1hour tutorial on git he nows safes the 5 minutes it takes everyday to clone the repo, and the hours lost when he deleted something he needed.

People can learn vim, and git, and insert tool here but we need a culture of teaching and a culture of asking questions. I'd argue the person in question didn't feel comfortable with sharing because they didn't want to look dumb and computer science departments tend to breed that what you can't do it mentality? That causes this problem like I mentioned and the hours of wasted time using vim and scp when you don't know how.

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

Are you writing space robot surgery AI big data containerized event-drive sixth-generation F-99s? Just curious.

I absolutely disagree with you by the way - most people don't use vim, ever. I mean, it's a cute flex, which is what I imagine is happening here.

Just to stay with the analogy: For something to "pay dividends", you need to have some starting capital first. =)

It's much slower to gather the capital when you're starting with zero and you spend weeks just fighting the tools. It's a lot more effective to gather some capital with easier tools (IDE + press F5 to run) and then move in to the low level stuff.

This is a great take. Just like learning anything else, getting context and foundational software engineering knowledge helps accelerate further learning.

I would never counsel a beginning programmer to learn vim first, but after 6 months or so when they have their bearings, it can help text editing speed immensely. Is that the biggest problem a new dev has? It depends, but probably not. Their time is probably better spent getting up to speed on software engineering concepts and practices.

"Text editing speed" is my per peeve in this field.

If your productivity is mostly limited by your typing speed you're either deluded or the greatest 1000x coder in the world.

I spend most of my time thinking and slowly prototyping the issue. It's not like I have the code 100% ready and my mind and just need to type it out as fast as possible and it'll Just Work after that.

And if it's speed of generating code you want, you can use templates in IDEs for it instead of going ":as12#:asd" in vim. Or use Copilot or a similar system to generate the rough outline and finish it up yourself.

Theory vs career training in college is not a simple issue. In reality many students are going to college because they want a job, that’s the goal, that’s why they’re there, that’s why they’re paying. Employers want graduates with practical skills.

This is a huge divergence from the University landscape in the 20s for example, where the purpose really commonly was “we’re here to think thoughts, for their own sake.”

I don’t necessarily mind the latter, it has a role and purpose for humanity, but it’s also not compatible with the existing paradigm that every HS grad has to go to college and accumulate debt to have any chance at a career.

Colleges do need to get real about their contemporary role or accept massive scaling back. Right now college enrollment is shrinking because of these issues.

And trade school enrollments are up. https://thehustle.co/04242023-trade-school-enrollment/

Universities will need to get used to smaller enrollments.

https://www.bestcolleges.com/research/college-enrollment-sta....

Everyone going to trade schools is just as stupid a line of thinking as everyone going to college, and yet I hear the former now all the time.

What if we combined universities and trade schools then we kill two birds with one stone.

That’s already happening in many cases as universities launch their own clock hour programs.

The human tendency to decree how large scale, complex systems ought to be never ceases to amaze me. Everyone thinks they understand and have the right opinion about problems that have been with civilization for 5 thousand years or more.

The very nature of economics and education paradigms means the continuous adjustment is the correct process. Yet all sorts of people who never had to be responsible for more then a household and some team of workers think they have the answer.

> This is a huge divergence from the University landscape in the 20s

we're still in the 20s

"dividends payed out" yeah no. crusty editing utilities don't give you superpowers, sorry. it's fine to learn them if you're interested but if you read the short intro docs on VS code and print out the 1 page keybinding cheat sheet you're going to be extremely effective without wasting time learning a bunch of quirky bullshit and coping with bad design for "muh historic reasons". and you can get learn you need to know about scp from `tldr scp`.

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

No, it simply doesn't. And certainly not in the timeframe of a single semester course.

The best things to get someone through a CS program today are VSCode and Python.

VSCode works. VSCode has lots of tutorials. VSCode has other users near you you can ask for help. VSCode works great on Windows. VSCode is useful in practically every course.

Python works. Python has lots of tutorials. Python has other users near you you can ask for help. Python works great on Windows. Python is useful in practically every course.

Notice a trend?

A fledgling programmer will get WAY further leaning into VSCode as their IDE and using Python as a replacement for command line tools everywhere. And they'll be able to use them all on Windows, macOS and Linux.

Finally, I'm sorry but the unix command line tools suck. The command line shells suck worse. There are litanies of things you have to remember to not blow both feet off with your shells. And the command line arguments between utilities have zero consistency merely for starters.

Yes, me being able to knock out that 4 terminal line pipeline is clever and super-fast, but a newbie needs things to be stable, observable and debuggable. And command line shells and utilities are notoriously none of those.

Even if you use VS Code, learning and using VIM bindings can make much much faster and reduce risks of and even help existing repetitive stress injuries.

(Speaking from personal experience)

In my current job I was forced to learn Vim and a lot of the other Unix command-line tools as we mainly do embedded Linux development. For a while I scraped by with VSCode and it’s integrated debugger as a crutch, and I do still use it via the SSH remote extension but some systems I work on are just too lightweight on resources to set that up, particularly for shorter tasks.

My advice to other novice programmers would be to learn the tools that your job requires when it becomes a priority, but always keep yourself at least somewhat familiar with tools outside of the scope of your current task. You never know when you will need to quickly get up to speed with a new tool set or language. Part of the keys to success is also gaining an intuition of when the need to learn new tools and skills is on the horizon and when to start practicing in anticipation of needing to use them.

For a vast majority of programmers today, CLI editors are not "the standard". Sorry, they're just not. The world has moved on.

To your 2nd point. Why shouldn’t CS students learn how people build software?

Computer science isn’t separate from actual programmers and some knowledge of the day to day jobs of programmers could inspire advances in Programming Language Theory or VCS

Are the dividends that significant over using CUA shortcuts* that usually are available in most other places?

I've done some reading and I'm considering diving into Vim, but I'm not sure, at least without much experience the surface level feels achievable by 2 keystroke combos and the mental overhead of getting used to using vim style bindings in some places but not others feel like exactly the kind of friction the article is trying to avoid

* Like navigating using Home, End, PgUp/Dn, moving between lines by Ctrl+arrows, Ctrl+X'ing for yanking etc

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.

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.

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.

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.

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.

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

I almost went to vscode for copilot, but then I found out emacs can run copilot too. It works great.

As a 2+ year user of Vs Code for daily dev work - yes, this is accurate. Code is a lot like Linux: lightweight, fast, and a royal pain to set up.

But once it is set up with a cocktail of plugins it is rock solid. It is also much faster than any other IDE I have used.

However I am a weird user - I don’t usually use buttons on the ide. I just pop open a terminal for things like git commands, build commands, test commands, etc.

It still astounds me that people actually use "lightweight" and "fast" to describe vscode these days. How times change.

Compared to the competition. I don’t use VI or EMacs. I compare code to Visual Studio Pro 2022 or any Jetbrains product.

It feels lightweight and snappy when opening and loading a new project, opening individual files, and searching through a repo.

I will say though that Jetbrains Idea and Rider are getting much better, but vscode is free whereas those are quite expensive. So if I can get 90% of the functionality for 100% less cost, I will do it.

I second GP. My point of comparison isn't just Emacs, but also Visual Studio 2015 and 2017, as used for C++. The editor in VS feels snappy, in this general and hard to pinpoint way that lets you easily tell apart a native app from an Electron one. Conversely, despite being reasonably performant (for modern standards), it still feels a little heavy.

I don't know what it is exactly, but I know I'm very sensitive to it. That's the main reason I rarely use VS Code, despite being more feature-packed than VC++ (or, along a few dimensions, even my Emacs) - extra features are nice, but not worth the ongoing discomfort I'd feel with every single key press.

My current hypothesis is that VS Code (and JetBrains IDEs too, so it's not strictly an Electron thing) tends to do too much stuff asynchronously at the same time, making execution times of most actions highly variable and potentially unreliable. The variability usually isn't huge in absolute terms - it's just big enough to be annoying.

This is fair for certain languages like JS or Java (IntelliJ is amazing), but not as much for less popular languages. I started learning Rust a few years ago, where the Rust plugin for Jetbrains IDEs was still in its infancy. Switching to VSCode specifically for rust-analyzer was a great decision for me, due to the amount of tooling included.

VSCode is popular because it is easy to learn for a beginner and shares much of the language server tooling with Vim and other popular editors. If you write a language server, it can work across multiple editors like VSCode and Neovim. (Though not Jetbrains IDEs, as far as I'm aware.) Writing a plugin for Jetbrains will only work for Jetbrains, so there's less incentive.

While Jetbrains have more powerful IDEs for specific languages, its less popular when VSCode, Vim, Helix, etc. all work together.

JetBrains released an LSP integration for their IDEs sometime ago: https://blog.jetbrains.com/platform/2023/07/lsp-for-plugin-d... Yes, it’s still new and somewhat buggy, but I am using Zig LSP plugin and it works pretty good.

Interesting! I stopped using Jetbrains IDEs by that time, which is why I didn’t mention it.

Jetbrains tooling is amazing. But can you attach to a running Docker container and develop inside it using Jetbrains?

Because last I checked I couldn't and was a blocker for my team.

With VSCode I can attach to both local and remote environments using Remote Development plugin by Microsoft (https://marketplace.visualstudio.com/items?itemName=ms-vscod...).

Yes most things are plugins. But they are high quality and maintained by the likes of Google, Microsoft, Docker, Shopify, Vue team, etc.

I like Docker development containers because they contain all the tools and configuration, down to the precise dependency and tooling versions.

Not only is the onboarding easier but we get less surprises by small differences in environments.

What do you mean “develop inside it”?

Here’s a link on doing it with python

https://www.jetbrains.com/help/pycharm/using-docker-as-a-rem...

Note that this feature is only available in the Professional (that is, paid) version. And since VS Code can do it for free, it has the upper hand in money-tight environments.

If you can't afford to pay for an IDE then your employer should get out of software development.

That's a hard fact.

Any organisation that can pay a salary or a contract rate, pay for a computer for the person to work on, pay for the hosting of their service, well they can also afford to pay for the tools that the developers need to do their job. And if they really can't, as I say, they should stop doing development because they are deeply unserious.

> If you can't afford to pay for an IDE then your employer should get out of software development.

That's my most workplaces. After cut-throat technical recruitment process with complexity and data structures smartasses, I thought they must be great workplaces with the best tools. Then on the first day in the office "IDE?! no we have no budget for it, why don't you write code in the new message window of outlook?"

Developers clearly don't need Jetbrains in order to work. Millions and millions work every day without it.

Yes but they’re so nice to use. It’s the integrated part that matters. The collection of tools just play well together.

That's just the python interpreter inside Docker being called from outside Docker. That's basically a configuration to call:

docker exec -i container_name python3 myfile.py

What VSCode does is much more powerful. It's as if you opened VSCode from inside the container. It works because VSCode installs a server inside the container so the world is now your container and you get full isolation, precise tooling and other goodies.

In my case the development Docker file has all dependencies devs need to work on the project. No need to fight with versions of npm, node, Python, Java, Go, nginx, Caddy, yada yada. Everything is configured in the Docker file. Everyone on the team gets a copy of the exact same environment.

We could even attach to a remote container running somewhere in "the cloud" if we wanted to.

I believe that IntelliJ can do this for remote servers. It installs an IntelliJ agent on the server and it’s like remote development, your real IDE becomes a lightweight client of it.

This?

https://www.jetbrains.com/help/idea/remote-development-a.htm...

JetBrains Gateway is a lightweight launcher that connects a remote server with your local machine, downloads necessary components on the backend, and opens your project in JetBrains Client.

That requires SSH daemon running inside Docker.

Plus it looks broken from the comments on https://youtrack.jetbrains.com/issue/IDEA-226455

> Peter commented 21 Feb 2023 11:23

> Remote development is my biggest JB disappointment. After years of development, it still doesn't work -- is too slow, buggy, crashes all the time, with most features just missing. Seems like they can't do it.

Last comment is from 16 May when they just closed the issue (and other related issues) with the same message.

In VSCode these things just work. And it needs no SSH to attach to a Docker container.

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.

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.

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

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

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

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

The variable naming can be good advice once you get used to programming and have some experience at it, but I'm not sure I'd agree it's best for novice programmers. I've seen even seasoned programmers with garbage variable names, which I'm sure were their first instinct, that tell you nothing.

One thing I see a lot of in particular that I wish I didn't are variables that are overly abbreviated to save the programmer some typing (which there is autocomplete, so typing shouldn't be a big deal), to the point where you don't know what it represents without sitting there and decoding the code.

To make up an example that's similar to what I saw in a code review a month ago (I don't remember the exact example), what does "tpTr" stand for? Turns out it's the target position for the transition out animation, but I have no idea without chasing that variable around and seeing how it's manipulated. Just say what it does.

Or you might see a lot of generic variables like 'data' or 'obj'. Like what type of data or object? Yeah for a tiny function you can probably get away with something like that, but anything larger and you should have something on there to help specify it a bit more. And yet I see this in code I review as well.

> Regarding variable names strongly consider keeping the first variable name which comes to your head. It is simple, straightforward.

Strongly disagree with this. Variable naming is so important if you want to write code others can understand.

The first name I come up with tends to be overly verbose/specific or too general. Variables named "count" are a good example of a name that's too general requiring a developer new to the code to ask, what is being counted? While "userUniqueVisitCount" might be too verbose when given the context perhaps, "visitCount" would be fine.

Just little things like that can really help a developer understand what's going on quickly.

Code structure is super important too though... If you're making too many abstractions it generally forces your variables and methods to be abstract and meaningless too. Your names should hint at this when there is a problem. If you find you need to use extremely verbose names to explain what a variable or method is doing, you likely have something structurally wrong with your code.

Just "visits", unless you use that name for something else. I find code that relies excessively on catch-all terms to be very tacky.

These things depend heavily on context. "count" is better and less redundant than "visitCount" when it is a field or method of a "Visits" or "VisitList" class, for example, and nothing else is being counted. Or as a variable: "count" is also good enough in a small function with a few lines, that only concerns itself with a single type of item being counted. If there are multiple things being counted in the same context, by all means specify them.

I get the good intention, but in the end those guidelines get in the way of good code more than they really help. The "no methods bigger than N lines" for example (popular with some linters) cause more damage than improvements.

I have gone back and forth on this many times in my career, but the word which comes to your head in the second or third attempt is usually the max depth you should search for. Chances are when you think of this again, the same word will come to your head making it easy to grep.

A lot depends on the scope of the variable but if one is using a language with strong typing I'm leaning towards decide asap, got for a short one and refactor after. Human short term memory is limited and getting the logic right while also getting the naming right is often pushing it too far.

Naming is still a hard problem :)

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

we use nano ! because its keybinds are faster for us : 3 and the legend means we can't forget !

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

> 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

That's what a legend is. The term is widely used with maps.

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.

Dealing with vim plus learning to code is hard. And the reward comes later on. It makes sense to start with vscode...

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.

Vim is a katana sword alright, one with two blades and no hilt.

You must pinch it with your thumb and index fingers. Even so, many have become deadly text slayers this way.

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.

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.

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?

you do that in vim?

I do that in terminal (I'm a heavy vim user)

vscode subs for vim, not for the CLI

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

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

I'm confused by this. Do you... not own a mouse? In my line of work, the actual editing of code is at most 10% of my time, and the remaining 90% is spent deliberately thinking through the actual algorithms and backend work.

Piping to CLI tools is easily done through Jetbrains macros.

Vim allows the editing to be thinking.

I feel like using your mouse is actually pretty efficient in many cases though.

Why would you want to keep your hands off the mouse?

Why do you think the mouse is slow?

Have you seen StarCraft players? They use the mouse and keyboard and perform an average of 200 actions per minute.

In fact, to select a certain piece of text, to get precisely to the end of what I want, the mouse is, most of the time, the fastest option.

I think the right idea is to use both, master them, and combine their strengths.

It depends on what you're doing. This article is more about programming than other kinds of computery work. In the industry I work in (openstack devops/gitops, running a large fleet of ubuntu machines), using Vim isn't a flex, it's just taken for granted that you can and will use Vim at least some of the time.

It's weird when I read threads like this and people treat using Vim as some kind of weird flex. It feels like I'm living on a different planet. Vim isn't a flex, it's a natural part of the broader Unix environment. It works seamlessly with Git, SSH, and the GNU ecosystem of bash, coreutils, gawk, gcc (which are all ubiquitous, too.) In such an environment, the more you learn about Vim, the more it pays off.

Why? Vim is ubiquitous, (relatively) lightweight, extensible with a lot of plugins available, and stable/predictable in its behavior. Its ubiquity and history ensures there is a huge body of documentation about it on the web. Unlike some other editors, it doesn't leave hidden "artifacts" all over the place, just one hidden swp file at a time which vanishes as soon as you save and exit the editor. This politeness is attractive because you don't have to deal with stale or interfering hidden statefulness.

Summary: Although you can edit quickly with Vim, and can keep getting faster the more you learn, it's not like I stick with Vim because "editing speed" is some metric that I really care about. And when assessing a candidate in an interview, it's not like I'm assessing them on their words-per-minute and tell them they need to switch to Vim to match our typing speed standards, lol. I use Vim, and I care about Vim, because it is polite and stable and integrates well with the broader Unix/GNU ecosystem I spend a lot of time working and playing in, and once you get muscle-memory for it, it feels really clunky to try using some other tool which doesn't have the same set of features.

You're not selling it to me. For simple admin tasks, Micro is totally fine. For actual programming where I really want the full power of an advanced editor, VSCode has all the properties you listed except arguably lightweight, though even there VSCode itself is pretty lightweight; it's just the heavy LSP servers that bog things down.

I obviously don't see Vim as a flex. Maybe a misguided flex.

It’s not VIM specifically, it’s the vim way, a language for editing texts. Actions are atomic and composable. And then you can add your own commands.

You could probably use VIM inside VSCode but the latter does not expose the necessary API. What you got instead is a very simplified version. Emacs does and evil-mode is a very good vim.

> Actions are atomic and composable.

That sounds like a downside. Incremental editing with multiple cursors is so much better than e.g. regex based find/replace or long vim commands because you get immediate feedback. If you make a mistake you just undo. You don't have to start again from scratch.

With complex atomic editing operations it is painful to get them right because you only see the final output.

Atomicity of complex editing operations is not a desirable property.

Undo is just the letter u. With the concepts of text objects, boundaries and movement, making mistakes is not easy. Code is also structured which makes it easier to manipulate.

Atomicity here has a linguistic meaning. You know the basic operations, and you compose them to express a more complex ones. Like d is delete, and w is one word to the right, dw means delete one word to the right. di” (delete in) is delete the characters inside the quotes and da” (delete around) also deletes the quotes too.

Once you got the hang of the languages, editing, inserting and selecting text becomes as easy as thinking.

N.B. Normal mode is the default mode, not insert mode

I wasn't trying to "sell" you on it. You seemed confused. My intention was to inform, not to persuade.

Use what you want, I don't care.

Some of the things I use in vim:

* Mark a position in the file, so I easily can jump back.

* Quick recording of a macro that to do the same type of edit multiple times (very handy when refactoring)

* regular expression search and replace, very easy to limit the scope.

* Easy to select, copy and paste lines or columns.

Everything without touching a mouse.

Here, this will help: https://gist.github.com/nifl/1178878

(Emacs user happily using Evil mode since 2011 or so)

Not really. I already know that Vim can be used as a difficult-to-remember editing language.

My point is that in practice the number of situations where that is better than normal editing with multiple cursors is so few that it doesn't get close to the threshold of being worth committing to memory.

That gist is rather long and rambling so I only skimmed it, but it seems to list commands you can do in Vim rather than real life editing situations that they are especially good at.

That's a clear case of the Blub paradox, man... Multiple cursors can be useful, but the Vim editing model goes way beyond that. If you're not interested, that's cool, but it's really your loss.

My experience with vim faithfuls is that they have no idea what modern tools are capable of and convinced themselves 23 years ago they they had found the peak editing experience. Watching them struggle through intra team demos with their shitty editors is a highlight of my week.

> sure you can if you're comparing with Notepad++. But modern editors have multiple cursors

Notepad++ has multiple cursors. Vim has "repeat last command", which is better.

Why is it better?

It is not just typing in multiple places, but executing a vim command in multiple places. Which means, you can replace the insides of a parenthesis with something, then proceed to do the same action on a different-length parenthesis, without actually typing the whole command again. While not getting confused by other parentheses inside the first one, because the i( adverb handles that. Similar with quoted strings, words, sentences, paragraphs, etc.

By "repeat last command", I meant repeating a single command with ., which can do simple things like pasting a string, deleting something, toggling case, incrementing an integer, and probably more stuff I don't use. Then there are macros which can repeat multiple commands, and are actually not much harder to use than the dot.

Another thing I like about the repeating approach is that you don't have to find all the places beforehand. You can target some of them with a regex, then remember to do more of them with another regex, then the rest, one-by-one by hand.

I used to think that typing in multiple places at once was cool, but now I wouldn't go back. Not even if other editors are catching up. Are they, by the way? I remember Notepad++ could not do much more than insert the same string in multiple places at once, but I confess, I have never used VS Code, Sublime, Atom, or really anything that popped up while I was in the vim rabbit hole. Am I missing out?

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.

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.

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

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

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.

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

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

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.

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

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.

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

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.

You can go through vimtutor in like 30 minutes.

If it doesn't all stick, you can just go through it again once per Sunday until you internalize everything you need for everyday development, though this is unlikely to be necessary.

This is an incredibly dishonest framing. I learned enough about vim to get around in it in a single sitting. In fact, learning to use an IDE has taken more time in many cases.

At university in the 1990's we had a short mandatory unix+emacs introduction as part of our first programming course. Maybe a few hours spread out over a week or two. Enough to get everyone started I think. Most of us ended up using it for everything after that and it was pretty much mandatory for some later courses (instructions assuming that you could use some REPL or such in emacs).

Not saying that it must be emacs and not some other editor, but it surprises me that any education does not include at least some introduction to how to use important tools like a code editor to getting work done.

> Should a novice programmer postpone their education by months because they need to satisfy the imaginary pre-requisite of learning vim via vimtutor?

I think this splits out into two camps of people:

1) People who are deeply curious and want to tinker and learn new things

2) People who view programming as a means to an end and want to build an app

If you're a novice I think you're better off falling into camp #1 even if it takes longer because you're still picking up education at every step of the way about what tools exist on your system and how to use them and then eventually once you're good enough you can coast and move into camp #2.

The same curiosity that led me to want to learn vim led to me wanting to learn about as many tools shipped with Linux as possible because I assumed many of them would be as powerful as vim was. That curiosity led to me eventually building up a much deeper intuition about how systems work and I think ultimately made me a better developer.

Is it a frustrating process? Maybe at times. But for the most part I think computers are fun and learning about them is fun even if I don't fully grok what I'm doing at the time.

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

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.

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.

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

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

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

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/

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?

Fair enough. There's a 'start here' sidebar with some of the most popular and best advice.

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.

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.

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?

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.

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.

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/

[1] https://en.wikipedia.org/wiki/Traditions_and_student_activit...

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)

Curious if anybody else experienced this, and what's behind it?

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

Looks harmless, but I learned something new today :)

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

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

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 :(

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

I use vim therefore disagree

> 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

Reply on news.ycombinator.com