301–310 of 346 posts
I largely agree w/ the argument here, but "slow" is going to be self-defeating nomenclature, and is also inaccurate. Business doesn't want slow. So if we're pitching slow, we're setting ourselves up to lose and the speed-hackers are going to win. Our goal is architectural soundness. I believe the biggest fallacy of our industry is we think the only way to get these is to go "slow". Not true. What we're really saying…
Earlier quoted context omitted.
The best analogy I heard for communicating this to superiors is that programming is like doing a crossword puzzle. 95% of the time you're doing a crossword you're not writing but that doesn't mean you're not intensely working on solving the puzzle.
You need to get better at crosswords.
I kind of disagree with the premise here, from my own experience, it's much better to work fast but ruthlessly refactor and never be afraid to delete your own code. I find I rarely nail things on my first attempt, but by being quick and failing fast, I learn more about the problem domain and I end up with a nicer end result than the person that agonized about their decisions rather than trying things out. (Of course,…
I largely agree w/ the argument here, but "slow" is going to be self-defeating nomenclature, and is also inaccurate. Business doesn't want slow. So if we're pitching slow, we're setting ourselves up to lose and the speed-hackers are going to win. Our goal is architectural soundness. I believe the biggest fallacy of our industry is we think the only way to get these is to go "slow". Not true. What we're really saying…
How do developers currently learn to build scalable, maintainable, well-architected systems? Certainly there are some books on the subject, and that might be a good start, but I'd be willing to bet that these skills are largely learned "on the job" through a bunch of trial and error. Are there any good ways to dive in and get experience with a lot of smaller examples, similar to the "code school" approach but for mor…
Earlier quoted context omitted.
I am clueless about this, How do you learn to make good architectural choices?
By making a lot of shitty ones, realizing it afterwards, and gradually making less shitty ones until you rarely make shitty architectural choices.
You get shitty fast programmers and shitty slow programmers. You get good fast programmers and good slow programmers too. 'Fast' or 'slow' in isolation are not really a measure of anything valuable, except perhaps how an individual fits into the team culture. The crucial thing to measure is how long it takes to get to good, robust software that does what it needs to do. There are many strategies to achieve that (agil…
Earlier quoted context omitted.
Maybe I'm missing something, but this seems like a bad idea to me. What if projects are relying on differing versions of the same package? What if two developers collaborating on the same project have different versions of that dependency installed? Sure, it's space-efficient, but disk is cheap, and developer hours are expensive. I certainly wouldn't want two employees burning man-hours trying to figure out why some…
There's a philosophical disagreement here. It's true, developers are expensive. But I think it's a fallacy that what's less efficient for a computer is better for a developer. The npm-style dependency tree enables and encourages much more complexity, which developers then have to deal with when debugging or deploying. They need new tools to help them get a handle on the huge number of modules. That's more expensive t…
I don't think that was ever said; I claimed that trading disk space for developer hours is a good trade-off in this case.
> The npm-style dependency tree enables and encourages much more complexity, which developers then have to deal with when debugging or deploying.
I don't believe this is the case. When developing an app (as opposed to a library) it's considered a best practice to check your node modules into source control, ensuring that there's never a mismatch between installed dependencies on developer machines. If you don't want to do that, you take what comes - but even before I picked up on that, I never ran into issues even when collaborating with 5+ developers. You just need to make sure your package.json locks your versions appropriately.
> My wife often comes out into the yard and asks me: “are you coding?” Often my answer is “yes”. I think I need this quote in my kitchen! My girlfriend often pounces be with the accusation "YOU'RE NOT WORKING" if she sees me out of my chair moving around, doing mindless house chores or half-vacantly tossing a cat toy around the house, or running errands, but the reality of _design_ is that it happens all day. And whe…