Discussed at the time: https://news.ycombinator.com/item?id=18780065
Things I Don’t Know as of 2018
71–80 of 119 posts
Re: Things I Don’t Know as of 2018
#72I noticed he didn't know much about Rust. And I really want to learn Rust. Except it seems the installation size is reprehensible. Is there a way to install a minimum version to get started with some fiddling about?
Re: Things I Don’t Know as of 2018
#73I'd love to see lists like this from more high-profile programmers. What does John Carmack not know? What does Dan Bernstein not know? What does Bryan Cantrill not know?
Not exactly that, but when reading Coders at Work I was surprised to learn that a lot of big names in our field use "printf debugging" and don't like actual debugging tools. Made me feel less bad about it :)
Even George Hotz does it.
Although he did write a debugger.
Re: Things I Don’t Know as of 2018
#74Earlier quoted context omitted.
> I would suggest to learn C, because a lot of stuff is written in it Does it also mean we all need to learn how to design integrated circuits?
I do recommend learning VHDL/Verilog (it's like learning functional programming or prolog - a completely unique experience), but it really depends on what you're after in life. Churning out Java/Web CRUD apps is enough to earn a living, it is actually what most programmers do (and even though every such app is boring as hell, collectively it is highly important for the world).
It really does depend what you're after. I find working on CRUD apps quite interesting, because I care greatly about UX and understanding the people and business problems that motivate the tech.
Re: Things I Don’t Know as of 2018
#75I'd love to see lists like this from more high-profile programmers. What does John Carmack not know? What does Dan Bernstein not know? What does Bryan Cantrill not know?
Not exactly that, but when reading Coders at Work I was surprised to learn that a lot of big names in our field use "printf debugging" and don't like actual debugging tools. Made me feel less bad about it :)
I’ve found that the more state and code paths to the bug, or the more confused I am about the bug the more likely I am to need a bunch of print statements. Debugging for me is a fine scalpel that works great when I think I precisely understand what is going on but my code appears to be doing something impossible. Starting stepping at the top of a program and just looking for what goes wrong is a usually a huge time sink.
Re: Things I Don’t Know as of 2018
#76This article really makes me feel good as a current intern and comp sci student. I thought I clearly defined what a junior dev could be if I worked at it for another year. Having read all the stuff this guy doesn't know and what I've learned at my internship, it's almost any hint of imposter syndrome I might of had went away. Now I'm not saying he doesn't know how to program. I'm just saying it's very interesting to…
Keep in mind technological knowledge is not the only factor. We pass on hiring plenty of technically competent people because of their communication skills. Knowing what you don’t know is one way to improve your communication skills.
[deleted]
Re: Things I Don’t Know as of 2018
#77From the list, I would suggest to learn C, because a lot of stuff is written in it or at least uses its ABI. So understanding that will give you a lot of leverage. Besides that, a deep dive into operating systems (yes, that means to get rid of MacOS if you use it) will give you a solid foundation to understand networking, containers and even more.
> I would suggest to learn C, because a lot of stuff is written in it Does it also mean we all need to learn how to design integrated circuits?
If we could, that would be a great thing. But contrary to programs you cannot inspect an IC so we would not gain ass much.
Otoh, running strace, gdb, and objdump can get you pretty far when debugging production code you've never seen that uses trillions of abstractions.
Re: Things I Don’t Know as of 2018
#78Lets face it, we are all the same. Gap over gap... We just pretend to be otherWISE.
Re: Things I Don’t Know as of 2018
#79I'd love to see lists like this from more high-profile programmers. What does John Carmack not know? What does Dan Bernstein not know? What does Bryan Cantrill not know?
Not exactly that, but when reading Coders at Work I was surprised to learn that a lot of big names in our field use "printf debugging" and don't like actual debugging tools. Made me feel less bad about it :)
IME it depends on what kind of bug you are dealing with, and also what language and debugging tools you have available. Historically I used to do a lot of printf debugging. The other day I was helping a friend write some C++ code and I had a bug where only the first element in an array was matching a condition. Using the debugger in my IDE I set some breakpoints in a couple of places that seemed close to where the problem was. The advantage of the debugger is that it is fast and easy to see at each breakpoint what all of the defined variables and their values are. If you do it manually you could easily forget to print one of the variables that you ought to be paying attention to. In this case the debugger helped me figure out the problem within only a couple of minutes which was great because we were really pressured for time at the moment.
Furthermore, in response to what one the siblings said about creating logging infrastructure, in my own debugging I tend to not find much value in keeping a bunch of logging around. For me keeping logging around boggs me down. Typically what I will do if I do printf debugging is I add logging statements, hunt down the bug and then commit the fix and the added printfs because they add context but then I immediately make another commit where I remove the printfs. This way I have them in the version history should I need them, while at the same time avoiding extraneous log entries at later time.
And really I’ve found that over time I do printf debugging less and less.
I attribute this to mainly four things:
1. A friend of mine that encouraged me to use an actual debugger
2. Watching Jonathan Blow program on his Twitch stream and observing how proficiently and fast he is able to get the information that he needs by using the debugger
3. CLion. As much as I like the commandline, I never found gdb with the commandline interface to be a suitable tool for me. Whereas with CLion I get a good debugger that makes visible to me most of the information that I need while I am debugging
4. Through years of programming I have learned to recognize many of the types of bugs that I produce. Also, with experience I have learned to write code that is easier to reason about and to debug as opposed to in the beginning where I was trying to be “too clever” for my own good with the code that I wrote.
I think another of the sibling comments put it well about the debugger being like a scalpel. Trying to step through a whole program and following what’s going on would be slow, confusing and ultimately error prone. In order to effectively use a debugger I think you need to have a hypothesis about what is causing the bug and then set very specific breakpoints that you make use of in order to figure out where things are going wrong. From your initial observations you can set more breakpoints at a more coarse level (shallower call stack levels) and use those to observe what leads up to things going wrong.
Re: Things I Don’t Know as of 2018
#80I'd love to see lists like this from more high-profile programmers. What does John Carmack not know? What does Dan Bernstein not know? What does Bryan Cantrill not know?
Not exactly that, but when reading Coders at Work I was surprised to learn that a lot of big names in our field use "printf debugging" and don't like actual debugging tools. Made me feel less bad about it :)
As a distributed software developer, I have found debuggers less useful these days. If I need a debugger, it probably means I don't really know the code that I am working on.
Good IDEs with good static analysis, good unit test/integration test/e2e test coverage, a true understanding of the code base before changing it, all these avoid most bugs.
When the production hits a bug, good monitoring and logging can help root-causing. It is extremely difficult to debug and reproduce a bug in a distributed environment. Many bugs I have root-caused are purely based on monitoring and logging then show the proof with mind-execution of the code.