161–170 of 177 posts
"Users couldn't care less about the programming language you used", and yet the author is so protective of his work that I can't copy paste this phrase. Unhappy user right here. We code for ourselves. We deliver value to the costumer. Two different things.
The inability to copy/paste was actually an oversight on my part, will fix. Thanks for pointing it out, not even sure why that's the case right now :)
This is a false equivalency. Pieter does not run a hypergrowth startup. His businesses are completely different to AirBnB and Stripe. He does this because he's the only person who works on the codebase and because it generates a lot of attention due to how polarizing this choice is. I'd also argue that messy code is the product of hypergrowth, rather than messy code being required for hypergrowth. Purposefully writin…
Here's what I've learned over the past 35 years developing software: I typically don't care much about implementation. There are many ways to skin a cat and it's not very productive to argue amongst them. Whatever. What is important however are interfaces. Function interfaces, class interfaces, subsystem interfaces (mediator design pattern). Factory methods are also extremely important: how do I get an instance of the thing I need? These are the things that are important. How a piece of functionality is actually implemented is far down on the list of things to care about.
Earlier quoted context omitted.
I rarely prototype but the scenarios where I do are in the game engine context where I’m trying to hack together a real time graphics algorithm, meshing algorithm, etc. The difference between a one second and 15 second iteration time is meaningful.
Do you throw that code away and start over when you're done prototyping?
When dissatisfied with an approach I'll often copy a class/function or three into new versions. I'll append the names of the old with 0. Then I start writing new ones with the new approach. In effect throwing the old ones away, even if sometimes it is a gradual process.
This happens frequently in a new project, less frequently in a maturing project, to never in a maintenance project.
However, it has a lot in common with (a severe) refactoring. Generally you're keeping the "overhead" docs, code, and even files, so it is not a complete rebirth, perhaps ~30% of the core code.
Earlier quoted context omitted.
> I cannot relate to people who make prototypes to throw away, I've never done it, and I don't know why I'd do it. When I'm at the prototyping stage, I don't yet know how to solve the problem. That means I need to iterate quickly, which affects my choice of language (Python) and the amount of time I'm willing to spend keeping code clean (very little, because I could hit a dead-end at any point). But once I have a wor…
I prototype in C++ all the time. And then refactor it to production code if it makes sense. Switching between languages seems like a waste of time to me.
Earlier quoted context omitted.
> I cannot relate to people who make prototypes to throw away, I've never done it, and I don't know why I'd do it. When I'm at the prototyping stage, I don't yet know how to solve the problem. That means I need to iterate quickly, which affects my choice of language (Python) and the amount of time I'm willing to spend keeping code clean (very little, because I could hit a dead-end at any point). But once I have a wor…
when writing complex algorithms the best approach is usually to write pseudocode, just literally write comments that explain what you are going to do in that particular block of code but not actually code it at all. that lets you build the mental model of how it's all going to work, but without any of the overhead of actually writing code. then write the main algorithm but leave some functions as stubs, just name the…
Earlier quoted context omitted.
when writing complex algorithms the best approach is usually to write pseudocode, just literally write comments that explain what you are going to do in that particular block of code but not actually code it at all. that lets you build the mental model of how it's all going to work, but without any of the overhead of actually writing code. then write the main algorithm but leave some functions as stubs, just name the…
Python has often been called "executable pseudocode." Avoid it and similar techniques at your detriment.
you're welcome to do whatever you want, but I'd rather do a pseudocode outline and then fill it in and have a statically typed program when I'm done, than to do a first-pass python program that is written as I go with no pseudocode.
again, the actual act of typing the code is a pretty insignificant part of development, what really takes the time is debugging all the edge cases and maintaining it for the next few years, and that's where static typing gives you a bit of an advantage. python is very much like the programmer bragging about their dvorak keyboard, it just doesn't improve on a part of the development lifecycle that is a particular bottleneck, and it does pose disadvantages down the road for maintenance and collaboration on a larger codebase. A little mandatory structure (not too much) is indeed a good thing when you have to work with other people's code (including past-you code).
And jeez, "ignore at your own risk!", maybe not intended but you just come off as dismissing a substantiative argument with a meme and a condescending dismissal.
Earlier quoted context omitted.
When I was working on this https://codaris.github.io/UnderDeskBike/ I honestly didn't know if what I wanted to do was even possible at many layers. I didn't know how to do Bluetooth. I knew nothing. It's not worth doing things "the right way" right off the bat because you might not know what that is. My first version was literally a linear file of statements and console output. Once I got something working and unders…
This is really how all new code is birthed. You start build something from no prior knowledge and few assumptions. It gives maximum agility and freedom to pursue multiple paths initially.
Occasionally I will code that way when I'm fairly certain of what I'm doing but you have to be very careful that you're not painting yourself into a corner.
In my experience, new programmers tend to build a lot of structure for their code that it's not clear they even need yet or will ever need and then often end up solving a problem with much more code than was necessary. It's usually my advice to get something (anything) working end-to-end first and then expand on that rather than the more linear approach.
"throw the first one away" When I'm prototyping or hacking something together, I don't write tests, I don't comment/document much, I use lots of shitty variable/type names, lots of commented out code, debugging printfs, not much organization of files (often one large file). The prototype software is write-once, read-maybe. Maybe I'll want to see what I did down the road, but more likely I'll be shortly rewriting what…
Earlier quoted context omitted.
If it happens years into production, especially after the load has increased or requirements have changed, it is a legitimate version 2 :)
I've seen rewrites introducing massive bughunts and upsetting customers without improving too much. I've also seen customers expecting and even relying on old bugs for comfort. Rewrite is always a business decision and need legitimate reasons. You rarely have those reasons, knowledge and time between projects.
Not because the previous version was wrong, but because it became inadequate as business grew and requirements changed.