151–160 of 196 posts
[flagged]
I like that this was included.
[flagged]
Do a thing. Write rubbish code. Build broken systems. Now scale scale. Then learn how to deal with the pattern changing as domains specific patterns emerge.
I watched this at play with a friend's startup. He couldn't get response times within the time period needed for his third party integration. After some hacking, we opted to cripple his webserver. Turns out that you can slice out mass amounts of the http protocol (and in that time server overhead) and still meett all of your needs. Sure it needs a recompile - but it worked and scaled, far more then anything else they did. Their exit proved that point.
Earlier quoted context omitted.
While I do agree with the content, this tone of writing feels awfully similar to LLM generated posts that flood some productivity subreddits recently. Are there really people who "spend weeks planning the perfect architecture" to build some automation tools for themselves? I don't buy that. Commenter's history is full of 'red flags': - "The real cost of this complexity isn't the code itself - it's onboarding" - "This…
> Are there really people who "spend weeks planning the perfect architecture" to build some automation tools for themselves? I don't buy that. I understand that it's not the main point in your comment (you're trying to determine if the parent comment was written using an LLM), but yes, we do exist: I've spent years planning personal projects that remain unimplemented. Don't underestimate the power of procrastination…
My struggle is having enough patience to do any planning before I start building. As soon as there's even the remote hint of a half-baked idea in my head, it's incredibly tempting to just start building and figure out stuff as I go along.
[flagged]
"Doing it badly is doing the thing." This one works for me, and I've learned it from a post on HN. Whenever I feel stuck or overthink how to do something, just do it first - even with all the flaws that I'm already aware of, and if it feels almost painful to do it so badly. Then improve it a bit, then a bit, then before I know it a clear picture start to emerge... Feels like magic.
At a previous company we used to joke that most of management was a "problem admiration society": They'd love to talk about problems, investigate them from all angles, make plans on how to plan to solve the problem, identify who caused it or how to blame for it, quantify how much it costs us or how much money we could make from solving it, everything and anything except actually doing something about it. It was never…
I used to think this. Then I noticed how often "preparation" became its own infinite loop. At work we built something from a 2-page spec in 4 months. The competing team spent 8 months on architecture docs before writing code. We shipped. They pivoted three times and eventually disbanded. Planning has diminishing returns. The first 20% of planning catches 80% of the problems. Everything after that is usually anxiety d…
What I am still on the fence about is when "design" or "architecture" type work counts as Engineering. There's a certain amount of design work that is valuable to do before coding and is part of the thinking process. But sometimes you get into a lot of abstract talking that is "not doing the thing".