Live data from Hacker News

Ask HN: What overlooked class of tools should a self-taught programmer look into

news.ycombinator.com

201–210 of 416 posts

Re: Ask HN: What overlooked class of tools should a self-taught programmer look into

#201

Read the curriculum of an undergraduate computer science course and read up on the things you haven't heard of. Some courses will even have lecture notes available. E.g. these four pages are the university of Cambridge masters in computer science: https://www.cl.cam.ac.uk/teaching/1819/part1a-75.html https://www.cl.cam.ac.uk/teaching/1819/part1b-75.html https://www.cl.cam.ac.uk/teaching/1819/part2-75.html https://www…

I support this 100%. I worked for years as a self-taught programmer. When I went back for my CS degree, I was shocked at how much I didn't know that I didn't know.

Numerous times I'd be sitting in a class and we'd go over a solution to some theoretical problem, and I'd realize that this solved a problem that had taken me days to discover on my own (and this solution was usually better than what I'd come up with).

If you are the kind of person who can work through everything on your own (including what may seem like the the boring parts), I highly recommend doing so.

Re: Ask HN: What overlooked class of tools should a self-taught programmer look into

#203
post #48

Unit testing, mocking, and various other testing techniques. Why? Any project of sufficient complexity is very hard to test. If all you're doing is code -> build -> run to debug your code, you can very easily break something that's not in your immediate attention. The problem is that good unit testing is hard, and time consuming. It can be so time consuming, that unless you can really plan in advance how you test, yo…

Let me second this. And in particular, I strongly encourage every developer to try starting a new project in a test-driven fashion (by which I mean that you advance the code by writing a bit of test and making it pass, and then doing that over and over.) There's a qualitative difference between working in a well-tested code base that's very hard to describe convincingly. A lot of my early development experience was i…

> Experiencing a well-tested code base totally changed things for me. Instead of work being a death-of-a-thousand-cuts experience, it became pleasant, steady progress.

I had the luxury of taking a well known data process and rewriting it with integration tests (input in, matching output with a golden file). It changed my professional life. Whereas before our deployment process included a 3 day wait and manual data checking on stage, after I was able to do deploys multiple times a day with confidence.

Made a believer out of me.

Re: Ask HN: What overlooked class of tools should a self-taught programmer look into

#204
Not one in particular besides the obvious. If it is really fundamental, it is not overlooked.

Every programmer has their favorite tools. Some will use debuggers, others will prefer logging. Some will use class diagrams, others will grep. Some will use IDEs and GUIs, others will use text editors and shells.

Same thing for programming languages, techniques, libraries, frameworks, etc...

So you are very likely to get a lot of answers. It seems that you got an epiphany when you learned about message passing. All programmers had similar experience as they discovered the one thing they really needed.

In reality it depends on the project. Great programmers simply have a lot of experience with many, many things.

My suggestion: continue what you are doing.

Try new things, don't blindly follow other people lists. In the process that led you towards that messaging library, you learned named pipes, unix sockets and shared memories, all useful, and maybe they will be essential to your next project. Had someone else served you that library on a platter, you would have lacked that insight.

Re: Ask HN: What overlooked class of tools should a self-taught programmer look into

#205
Devops; being able to stand up your entire stack in an automated way. Some programmers dismiss this as "yaml/bash engineering", and that's true, but it also challenges all of your assumptions in your stack. If you can't stand up a complete duplicate programmatically, you almost certainly have implicit assumptions that you haven't verified, which will make it much harder to recover from disaster or scale.

Put another way, devops is a mix of declarative programming (YAML) and writing idempotent, imperative code in the presence of large side effects (bash). Learning to handle both is very educational.

Re: Ask HN: What overlooked class of tools should a self-taught programmer look into

#206
post #200

Makefiles. I always dismissed them as a C compiler thing. Something that could never be useful for Python programming. But nowadays every project I create has a Makefile to bind together all task involved on that project. From bootstrapping the dev environment, running checks/test, starting a devserver, building releases and container images. Makefiles are just such a nice place to put scripts for these common tasks…

I hate makefiles. That said, I wholeheartedly agree with the comment. It's sad that something so central to a project and so useful and important to so many people seems like it hasn't advanced ... ever. Developers generally do the minimum with Makefiles and get out. They are similar to 1040 forms in popularity. I've always had a dream of a redesigned "make" system... with import statements, object oriented rules, cl…

Bazel is pretty nice.

Re: Ask HN: What overlooked class of tools should a self-taught programmer look into

#207
I would say studying any of the AWS paas offerings. Not saying you have to use them, but they cover a large segment of the system component space.

They can help you answer questions like "When would I use an in memory cache vs a rdbms vs a key value store?"

Re: Ask HN: What overlooked class of tools should a self-taught programmer look into

#208
Value/message/actor/event oriented programming like you mentioned is useful for building distributed systems. I am a huge fan of going a step further and learning this model:

Imperative shell, functional core.

The external shell of code in a project is responsible for network connections, console IO, etc. But the internal guts of a program should be largely functional, that is, instead of mutating (changing) values, consider returning different forms of the same value.

Decisions (branches, logic) are made at one level, data dependencies at another.

The talk Boundaries by Gary Bernhardt describes this model in detail: https://www.destroyallsoftware.com/talks/boundaries

Re: Ask HN: What overlooked class of tools should a self-taught programmer look into

#209

Earlier quoted context omitted.

>The big downside of Make, alas, is Windows compatibility. Isn't the big problem that you have no idea what it's doing to your system? Also that you aren't expected to be able to undo it. You can read the makefiles, of course, but it seems simpler not to have to. (Just update the necessary packages yourself, to the latest version.) Forgive me if this is naive of me.

>Isn't the big problem that you have no idea what it's doing to your system? As opposed to what exactly? Any other alternative, e.g. separate shell scripts, "npm run" scripts in package.json, running a Docker image, hell even cmake or other make-like tools - does stuff you don't know about without reading the files either.

(I was heavily downvoted). What I was thinking is: as opposed to just running your built-in package manager yourself, to upgrade your system to the latest version of all the packages it might require.

Re: Ask HN: What overlooked class of tools should a self-taught programmer look into

#210
post #93

Honestly I still find a lot of engineers don't know git properly. Like they know enough to commit and push but that's about it. It really helps to understand everything git has to offer.

Ha, I just did a talk and asked how many people knew about git bisect. No one.

I found this zine (not free) to be helpful:

http://ohshitgit.com/

Post reply on HN