Ask HN: What programming tutorial/course/article/blog would you like to see?
For many months if not years I've been thinking about sharing knowledge I have. That's natural order of things of course, but because of limited opportunities of face to face contacts I didn't really have a chance to listen to people's problems and challenges. I work as full time software engineer, but also I do a lot of experiments and side projects. Because of that I've accumulated lots of different impressions and perspectives.
So I'm asking here: what would you like to read about, what are your current doubts about programming in general or related to dreaded by many subject of JavaScript and frontend frameworks. Is there any 'next level' you'd like to reach?
This question can help many other people in situation similar to mine. Thanks!
92 comments
[ 3.0 ms ] story [ 172 ms ] threadIt certainly could be
This might be an answer you don't like very much, but seriously, all the best articles that I've read and shared in the past have been been things that the author would probably have felt compelled to write even if no one bothered read their work. I can't imagine that soliciting for ideas really works.
I think this is the main reason why I've always failed to be the blogger I aspire to be. There are few subjects that I care enough about to write consistently on. It's weird, because I post on the web a lot and I feel like I'm pretty passionate about web stuff. It just doesn't manifest in the form of blog posts though.
Practically everyone who has a decent amount of experience delivering something feels that way. Usually it's a combination of the original team not having as much experience, or that the situation at the time didn't allow it (lack of resources, incompatible acceptance criteria that no longer apply, etc), or that you've missed something important that actually means the solution you're going for is the wrong approach. Understanding which it is is hard.
I'm curious: How do you replace entire teams of devs by choosing cloud architectures? Is it because cloud architectures bring so much stuff out of the box that is otherwise implemented in a custom way by individual developers? What would be an example?
Edit: Found your blog post about it: https://kulikalov.com/how-to-make-sense-of-cloud-architectur...
Not trying to be bring you down or anything, but the most likely answer is that every senior engineer in the company knows what needs to be done but lacks the political capital/will/etc to implement the change.
I've felt compelled to write this question on HN. Even if I don't draw anything for me, maybe someone else will. Additionally, remembering I asked this question and didn't get inspiring answer, I might finally be compelled to write my own thing without any other questions. You never know.
And if we already do meta talk: 1. Every rule has an exception. 2. Always do most exciting thing, today it's asking a question, tomorrow it's writing an article. Rule 1 works for points 1 and 2. And also works for your impressions about best articles. :)
I beg to differ. Might be true for the most interesting articles, but the most useful articles are day to day stuff like How to do X in Y imho.
Now I am curious of some examples of such articles. I like good articles that makes me think.
Say we start with a fresh Debian install, the first line might be
The second line might be Or Python or Node. And then the commands to create the project directory, switching to it, installing a webserver etc would follow. At some point there would be a line At this point, we accomplished serving a static page.And then line by line, a full web application is created, with routing, templating and user accounts. With no other tool than the command line. So the page would never say "Click on this then click on that..." or "Depending on your environment...". No, you could simply copy every line, paste it to your terminal and thereby create the exact same application.
Ideally the page would have one column of commands for every typical approach like Django, Flask, Laravel, Symfony, NextJS etc.
I would expect this page to start with just one approach - say Django. And then accept pull requests from experts for the other approaches.
So we would have side by side examples of what steps are needed in different environments to create a typical web app nowadays.
I had this idea for a while but so far did not get around doing it. If someone wants to collaborate on it, hit me up.
Then depending on who's writing the tutorial, the content ranges from "create a VM and issue these commands" to gcloud commands to spawn VMs.
Usually, when a student doesn't know anything about React, they won't know anything about Debian, and the whole tutorial will go over their head. Alternatively, it will be highly shallow. Or, usually, both.
A single Docker container can be used like a fast, lightweight VM. And from there on it is just copy+paste.
So on a Linux machine the process would be:
After a few years, the history if it would be very interesting. It would show how much maintenance a minimal web app based on the different approaches needed.
What I'm highlighting is:
* The knowledge depth and time required on your part to maintain the text such that it works on all supported systems
* The fact that you're depending on a number of tools that might become obsolete quite fast, which might throw a wrench into your text.
** For example, Docker stops supporting CLI due to licensing. Linux splinters off to podman, Windows creates its own tool, macOS users will generally continue working with Docker. You'll then be forced to migrate to a different tool, like Vagrant.
Rather than create a text that's a "bring your own developer workstation", create a webpage that I pay $15 for monthly, you record a video explaining a concept, and then you have a button that says "spin up a lab for X". This throws me to a controlled environment, e.g. in AWS, where you tell me the exact steps that will achieve what I want to achieve.
echo "<h1>Hello World</h1>" > index.php
in a Dockerfile.
With the shell, all of this can be combined in one command that you can easily read, understand, copy and paste and which is exactly reproducable:
1. Run this:
2. Now paste in this: Access rights are a separate command in both methods, and if you're really concerned about file encodings (seems unlikely for this sort of thing), that's either an editor setup step at the very start, or one command to convert in either method.Even just reading it would give me an unambiguous insight into the concepts of the framework.
To "fork" it, I would copy all commands into a shellscript and then change something like "mysite" via search+replace. In vim it would be: :%s/mysite/yoursite/gc to change all occurances of "mysite" to "yoursite" and be shown each replacement before it takes place.
Most things I found when my interest was piqued were from the perspective of building or running NixOS, which is (for now) much less interesting to me.
(Edit: If anyone feels like they have the technical knowledge but not the writing skills, I'd be happy to team up!)
* "Algebraic effects" are still a research topic, they aren't a feature of any production programming language today (as far as I'm aware): https://overreacted.io/algebraic-effects-for-the-rest-of-us/ - did you mean "algebraic data-types" instead?
* "Linear-programming" refers to a class of optimization problems in mathematics and statistics, it has little to do with FP.
* True dependent-types are... complicated (and seen in theorem-provers more than in any language); when most people say "dependent-types" they often really mean just "refinement-types", and while refinement-types are a feature of many FP languages, they aren't exclusive to FP: in fact you can implement practical refinement-types in any conventionally-typed (even non-FP) language with cheap value-types and user-defined implicit conversions (like C#, C++, Swift, but not Java).
-How to do modern frontend dev without installing almost a Gb of transient onliner JS deps.
-Modern Frontend development for Backend devs.
-Mobile apps development without installing huge frameworks and heavy tooling.
This would help countless people new to development. Lots of systems (I'm looking at you, Java) throw up vast splats of tracebacks. Others chunder out great chunks of poorly digested code. Sometimes daunting even for experienced people.
An article with basic advice about looking for the one or two useful lines in error messages would be great.
I think most beginner programmers treat every error message as simply "you screwed up", and reading the error message and gleaning useful information from it doesn't occur to them as a possibility. That knowledge can come from it being explained like you suggest (but in person with their actual problem is better), or from them sitting down and puzzling it out. If you haven't been through this though, and don't know what kind of information is available in error messages, you won't go looking for an explanation of how to find it.
Not Spotify, but I have several decently loaded projects running with this setup for years.
People who are fine with control flow, git, unit tests etc, but who would be lost if you start talking about things like state machines or depth-first search.
I'm largely talking about myself here, but I've worked with dozens of colleagues in several different jobs who would also match this description.
I find this too. I’m self taught and have made a lot of good projects with blog tutorials and SO. Python has let me do a lot quickly, but I get stuck on some odd things.
Last time it was data structures. For a project I was expanding, the data structure was insufficient. I imagined there must be more complex data structures to solve the challenges, and I asked people for this. Lack of response helped me realized my thinking was wrong. Then I realized I could do what I needed with SQLite. Haha.
Right now I’m stuck on an aspect of Django. Django is a Python module. When I want to add another module to modify how Django behaves I need to override in my code. It’s all too complicated to imagine for me. Example, adding wiki pages to django by adding django-wiki module, then adding tags to the wiki pages by adding danio-tagulous. I know this is some kind of class override, but I just can’t imagine it.
Also, How to think through adding API data to your project? Like swagger.
For me it’s about thinking or visualizing how to put my code together with other people’s code. And once in a while I ‘imagine’ what a solution should be, and I make everything more complicated than it need be.
Can you expand on what you're trying to achieve? It sounds like it's a mixture of frontend and backend in Django?
>> Also, How to think through adding API data to your project? Like swagger.
Tell us more what you mean. What's your end goal?
I’m not looking for problem solving, and I’m not going to discuss specifics here. I’m describing for the OP a difficulty I have in programming, which I assume is due to a gap in my education. You’ll have to use your imagination.
The best I can do to explain what I’m struggling with is confusion over levels of abstraction further from the code I’m writing—write some code, then expand it by importing someone else’s code and then import another piece of code to expand the first import—it’s turtles all the way down.
Dealing with APIs isn’t as terrible as that, but I could use some better language to describe these special cases. I’m also bad at reading other people’s code on GitHub and understanding what they’re doing—for example. But of course I understand my code.
How's that saying go? Show me a programmer with 20 years experience, and I'll show you a programmer that did the same thing twenty years in a row.
Create a
1. Mandelbrot
2. Julia set
3. Ray tracer with shading and shadows of a few simple spheres
4. A simple virtual machine
5. Rewrite the first three programs in the virtual machines assembler
6. A simple language such as Forth for the virtual machine
7. Rewrite the first three programs in your implemented language
All of these 7 tasks together will likely take under 2,000 lines of code, maybe even under 1,000.
If you know what you're doing, each one individually should take under an hour.
Doing a write-up about your experience with this would be great. Each one of these tasks has tradeoffs and can reflect personality and approach.
This is version 1.0 of this, and I just came up with it a few hours ago so I'm open to slight modifications (perhaps an extremely easy game instead of one of the fractals)
In other words - the second or third time you do it, it should take under an hour.
I hope not.
The point is to give experienced people challenges that are achievable but are both hard and simple
I mean, I'm not interested in a html/css/javascript tutorial, we have enough resources on that. What I found really missing on the internet (maybe I'm not that good at searching), is a step-by-step detailed guide on how to deploy/update/maintain a website. An unordered list of thing that came up to my mind:
- How to deploy the website on a server
- Which server should one use
- How to expose it on the internet (buy domain name)
- Version control and hosting the repository (GitHub vs gitlab vs ...)
- Updating your website (CI/CD like Jenkins?)
- Reproducible environments (Docker?)
- How to integrate analytics
- How to integrate ads respectfully (of your users)
- How to integrate paying contents
- How to address security
- Ho to address scalability
- How to integrate analytics
- How to integrate ads respectfully (of your users)
- How to integrate paying contents
If you aren't familiar with any of this stuff, i'd recommend focusing on the fundamentals (HTML, CSS, JS), avoiding CI/CD at all cost, avoiding complex back-ends that require fragile docker containers to ever work. Get familiar with the basics of running a simple static web server and simply upload your files via rsync. Then start approaching dynamic backend runtimes, php, nodejs (with caution). The reason I recommend this approach is that much of the complex tooling and environments you will no doubt encounter in tutorials is extremely opaque, they can provide you a giant leg up to get up and running with something impressive, but will give you very little insight into how or why.
From this point on everything gets opinionated and project specific... which is why it's hard to write a timeless and comprehensive guide.
To add to my other comment in this thread, as this relates to your particular comment, we try to keep Molecule.dev as up to date as possible. We cannot of course cover every piece of tech out there, but we attempt to cover what we think are the best tools available and will continue to exist and improve for many years to come.
It is definitely a very difficult problem to solve and will need constant maintenance, but I think it's worth it if it helps people get started building awesome, high quality things faster.
It includes detailed step-by-step guides for every little thing you need to know to develop, release (and rerelease) your app on every platform you've selected, using the tools you've selected. It also covers many edge cases and obscure issues which we know that you will probably run into.
It's written for developers of varying levels of experience so that any member of the team (present or future) can quickly jump on board and get started building and deploying.
It also includes a (very meta) guide which explains how to update the guide itself and regenerate new documentation as you (and your team) add to it for your own purposes.
Starting this week, however, we'll be publishing regular articles about the inner workings, design decisions, and architecture, among other things. We may actually cover some of the core basics and release sample code with documentation. We'll probably publish at least 2 articles per week.
Me too. I consider most of these trivial too. But there's another aspect. Many things (version control flow, release model, rollbacks, etc) has to take into consideration and will inevitably affect the workflow, meaning the way engineers write code (feature flags? dynamic config? gitOps? what about rollbacks? Do we keep the tip of the branch synced with prod or no?).
The _state of art_ is different based on things like: Monolith or micro-service (like smaller, well defined scope)? Is the app written in Java, NodeJS or Python? Do we have 5 developers, 1 or 400? Do we need to testing because the app is handling medical data or we don't care if we don't case because our SaaS doesn't handle sensitive data? Do we need integration tests? Do we care about raw computation perf? Mem leaks? What about testing thresholds?
All the above and many more, depend on business goals and domains, engineering cultures and less obvious intangibles. These evolve "naturally" over time.
There's no "state of art", just business needs. The "state of art" is the sweet spot between engineering velocity and reliability, which is a moving target anyway :-)
So many projects list a gazillion features on their site, and then leave you with a "Good luck! The features are in the code base".
It seems like it'd be a fun pet project.
For example, hundreds of papers talking about 'inductive bias' or 'SE(3) operators' and what not. There isn't even a general boundary between unsupervised and self supervised learning (Remember Yann Lecun stepping in one such debate but without a conclusively clear demarcation). Very few actually try to explain a view that general practitioner can connect (with some basic exposure). Google maintains a ML glossary but that sorely needs some updation beyond the very basic stuff.
I’ve had an idea for a while that it would be interesting to document a computer language with a complete set of example code. This example code would exhibit all the language’s functionality. It would be written with best practices in mind.
The code wouldn’t necessarily need to do anything useful, The goal would be the code itself.
The technology in IDEs, the things you Google, the bugs you get, stack trace messages, none of these things TELL YOU WHAT TO DO OR FIX. They are clues or evidence. You have to bring the understanding and intention.
I expect that some people disagree about this being a problem, but I've seen it enough times to recognize it. Senior developers need to remember that they were not always senior.
I find the first hand story of how different architectural decisions turn out in real world scenarios are way more valuable than all the blogs out there writing about any new hot piece of tech. I'm curious what you found interesting and even check regularly.