Live data from Hacker News

Challenging projects every programmer should try (2019)

austinhenley.com

191–200 of 346 posts

Re: Challenging projects every programmer should try (2019)

#191
post #133

Earlier quoted context omitted.

Nowadays (and increasingly, going forward) it's possible to be a very productive programmer without knowing much low-level stuff. This may seem unfair to those who spent years wrestling assembly and then C pointers but that's just today's reality. It's not possible to be a "productive" musician on a traditional instrument (i.e. excluding iPads) without knowing how to play scales, chords, etc.

This is also the reason a computer with 4GB of RAM can't run Gmail and Spotify at the same time.

> This is also the reason a computer with 4GB of RAM can't run Gmail and Spotify at the same time.

That’s demands for faster delivery of software and ridiculous demands on user experience.

Does looking down on higher level devs make you feel superior or something like that?

Re: Challenging projects every programmer should try (2019)

#192
post #107

Earlier quoted context omitted.

I don't understand why you think a search engine requires the use of "real engineering skills" like picking and choosing libraries and identifying which opportunities will yield fruitful optimization. Literally all of the listed projects, text editors, compilers, operating systems, and ray tracers, can exercise the exact same activities. I'm more inclined to think that your comment is really more revealing about what…

> Literally all of the listed projects, text editors, compilers, operating systems, and ray tracers, can exercise the exact same activities. In the linked article, these projects are all explicitly described as opportunities to learn about low-level stuff like how to efficiently store editable text. The difference with a web search engine is that nobody today can build such a thing completely from scratch, therefore…

Please can you define "from scratch"?

Re: Challenging projects every programmer should try (2019)

#193
post #24

While writing a text editor, a compiler, an operating system, or a raytracer might make you a better programmer, it won't make you a better software engineer. In fact, it might make you worse at software engineering, because it embodies the disastrous "Not Invented Here" doctrine. Hackers like to obsess about Big-O, data structures, HoTT, and other high-theory stuff, yet the following skills, essential for software e…

I could not disagree more.

If it is not not invented here, on the limit is not invented anywhere because nobody knows how to build these things, which we have been on that path more or less.

Perhaps you were visualizing that guy on your job who creates his own libraries and obscure systems within the system before telling anyone and that is generally a bad peer.

But the Universe is much bigger and diverse than that, people who programmed their own things but do a Google search first and use other software because they know it’s more feature complete, more known, trusted and better future supported are the best to work with.

We are all using the products of not invented here syndrome right now, don’t forget that.

Re: Challenging projects every programmer should try (2019)

#195
post #39

Earlier quoted context omitted.

What if we don't want to be "software engineers"? I'm still not totally convinced that "software engineer" is even a thing , frankly.

Who do you think puts systems like a web search engine together? It's certainly not people who are lost in details like string matching or how ACID is implemented in distributed databases. Of course you need all these things in order for the search engine to work – but if you write them yourself, even if you think about them excessively, you will never finish. Software engineering is knowing that you don't need to kn…

> Who do you think puts systems like a web search engine together?

Literally by stitching together people you’ve listed here and making them work together:

> It's certainly not people who are lost in details like string matching or how ACID is implemented in distributed databases.

> Of course you need all these things in order for the search engine to work – but if you write them yourself, even if you think about them excessively, you will never finish.

Being able to write something from scratch is not the same as always writing from scratch. Let me turn this around. Who would you trust with writing search engine, a software engineer who worked on and wrote search engine from scratch or someone who only theoretically knows about it?

> Software engineering is knowing that you don't need to know everything, you only need to know where to find everything. "Programming" is an important part of it, but far from the only one.

I hear this excuse more and more when it comes to threads like this. You don’t need to defend your life position, it’s okay to not know everything.

Re: Challenging projects every programmer should try (2019)

#196
post #146
post #131

Earlier quoted context omitted.

I believe this more and more as I go through my career. There is usually one person carrying progress hard. If you can get three or four of those people and another one to coordinate them you can do truly amazing things. Usually though you just need one unencumbered by bureaucracy.

Not sure what you guys think software engineering means, but it's definitely not the same as what I think it means.

Software engineering is whatever definition that allows me to procrastinate and sleep at night knowing I don’t need to learn more.

Re: Challenging projects every programmer should try (2019)

#197
post #114
post #68

Earlier quoted context omitted.

Do you have any good resources for what you mentioned?

I wish. As you can plainly see in this thread, most "real programmers" consider such things beneath them, and the scarcity of relevant resources is a natural consequence.

Nobody considers them beneath them, you just found a straw man and keep doubling down on it.

Re: Challenging projects every programmer should try (2019)

#198
post #56

Earlier quoted context omitted.

"The vast majority of ML/AI software that is published (which often implements revolutionary techniques!) is of incredibly poor quality from a software engineering standpoint. As a result, practical AI applications are orders of magnitude slower than they could be." That's quite the claim. Why should anyone take your word for it?

There are literally performance breakthroughs being made every few weeks (most recently, PowerInfer, which can speed up LLM inference by 10x or more) where the main improvement amounts to the application of caching/preloading techniques. If the "engineering" part of ML had kept up with the "science" part, I have no doubt that performance for typical use cases would be 100x-1000x higher than we are seeing today.

> If the "engineering" part of ML had kept up with the "science" part, I have no doubt that performance for typical use cases would be 100x-1000x higher than we are seeing today.

Even more of a claim than previous one.

Re: Challenging projects every programmer should try (2019)

#199

Earlier quoted context omitted.

Back when online learn-to-code courses like Codecadamy and Udemy were a fad, I remember that one of them (and unfortunately I don't remember which, and Google, ironically, turns up nothing) taught how to build a search engine in Python from scratch as a first project for complete beginners. I thought it had a reasonable level of complexity for this task. You can still find search-engine-from-scratch courses on Udemy,…

was it udacity's cs101?

Yes! Thank you.

Re: Challenging projects every programmer should try (2019)

#200
post #62
post #57

A text editor can use an array as data structure. You only need it to be fast during the typing, where you are only changing one line. But for entering new lines, the extra latency needed for rebuilding the array after pressing enter is not noticeable for several million lines. The more challenging part of a text editor is making sure you only render what the user sees.

And the most challenging part is making a text editor that actually works well from a usability perspective. Which has almost nothing to do with data structures and optimization. I've used dozens of text editors. I have never once thought "man, that thing is slow". But I have thought "man, that thing is a bug-ridden, unintuitive piece of garbage" many, many times.

> I have never once thought "man, that thing is slow".

You’re either lying or incapable to detect typing latency.

Try typing while CLion indexes stuff in background or open couple hundred thousand line file in VS Code with Vim plugin and let me know how it goes.

Post reply on HN