5 ms·

Aside from the NLP-related aspects, which are pretty interesting by themselves, I was glad to see this: > The biggest thing I learned. The thing I also hope my

by zwegner 13y ago

Aside from the NLP-related aspects, which are pretty interesting by themselves, I was glad to see this: > The biggest thing I learned. The thing I also hope my team has learned. Everyone else has hit the limits of what they can do because they weren’t willing to burn it all to the ground and start over. We start over a lot. We code for 3 days and then decide this won’t work, and we do it over again. We take the lessons we learned but little of the code. The second, or thrid time we do it right based on what we now know. I am a big fan of rewrites, and am sad to see how much of the software engineering world has centered around the Spolskyesque idea of rewriting being a horrible waste of time. Truth is, 99.9...% of software just sucks. The more and more infrastructure we build up around it, the more constrained we become. Just look at the most common languages/tools/technologies we use on a daily basis. C++/Java/JS/Python? These are just awful. Hell, I'm even like Python compared to most languages, but there's still so much historical cruft, and it's ridiculously slow to boot. I think this is mostly because people just suck at writing software in general. Rewriting in the industry usually doesn't buy you anything since it's the same people writing it, and they're still constrained by all the other software that they interact with. But if everyone was more willing to rewrite, focusing on code quality, I believe our tools would be less intertwined, we could achieve much faster rates of progress, and the life of a software engineer would be a lot more tolerable.

drakaal 13y ago
I fixed my misspelling of third... I think for us the biggest thing is that often we don't know what approach will work best until we try, and often we have to balance more than just readability or performance. Memory usage issues meant that we prototyped one way for getting all the words in to memory, proved that we had enough information about the words for 99% of what we were going to do, and that we could get the other 1% later, and then re-wrote with a different "loader" and different information about the words loaded. I like functional programming but it made sense to make parts of the code object oriented not just for readability or ease of programming, but because it was more performant. So our rewrites are partly for performance, partly because the end goal moved slightly, and partly for maintainability. As we stack on new features often the way we should do things changes drastically.
- zwegner 13y ago
  > I think for us the biggest thing is that often we don't know what approach will work best until we try Absolutely--and I think pretty much all software is like this. Engineering/optimization is, in a vague sense, all about how much shit you can throw at a wall and how well you can tell what sticks. The faster/easier/more accurately you can do this, the better. If you're going to be bound to the first pile of shit you throw due to business constraints or whatever, you're not likely to end up with something very nice.

by zwegner 13y ago

drakaal 13y ago

I fixed my misspelling of third... I think for us the biggest thing is that often we don't know what approach will work best until we try, and often we have to balance more than just readability or performance. Memory usage issues meant that we prototyped one way for getting all the words in to memory, proved that we had enough information about the words for 99% of what we were going to do, and that we could get the other 1% later, and then re-wrote with a different "loader" and different information about the words loaded. I like functional programming but it made sense to make parts of the code object oriented not just for readability or ease of programming, but because it was more performant. So our rewrites are partly for performance, partly because the end goal moved slightly, and partly for maintainability. As we stack on new features often the way we should do things changes drastically.

zwegner 13y ago
> I think for us the biggest thing is that often we don't know what approach will work best until we try Absolutely--and I think pretty much all software is like this. Engineering/optimization is, in a vague sense, all about how much shit you can throw at a wall and how well you can tell what sticks. The faster/easier/more accurately you can do this, the better. If you're going to be bound to the first pile of shit you throw due to business constraints or whatever, you're not likely to end up with something very nice.