4 ms·

>Until it starts generating PROFIT, anything else like: clean code, unit testing etc, makes zero sense. And also for the record, whenever I'm trying to figure o

by alexb_ 4y ago

>Until it starts generating PROFIT, anything else like: clean code, unit testing etc, makes zero sense. And also for the record, whenever I'm trying to figure out where something went wrong, commit are not the thing I look at, it's the code changes in the commit. Look, I work in a "squash commits, messages are for detailing tickets" place. I can understand not liking commit messages (although you really should, they are comments for your changes!). But this whole idea of "it's okay to have completely awful code because you are still growing :)" is how you get permanent spaghetti that costs absurd amounts of money to fix. There is nothing more permanent than a temporary solution, and deluding yourself into thinking uncommented, messy, untested, godawful code is acceptable "for now" will never end. Maybe I could excuse this if it was just commit messages being automatically the ticket names or at least some idea of what is happening. Making it "commit" is a horrendous idea. Why are you sabotaging your future self by not describing what you are doing in a commit message? Just to save 10 seconds per commit via your script?

rolenthedeep 4y ago
I used to work in a shop where "bad code is okay, we're a startup" and "our entire system depends on spaghetti written by an intern that quit after six months five years ago" were the norm. By the time I came along, the consensus among senior devs was that the entire project was a loss and we'd have to start from the ground up on the next project. They're still shipping the same showstopper bugs nearly ten years later. If you want your project to last more than a couple of years, or if you want to use it as a base to build other projects on, you should care about code quality. Don't try to implement an entire game engine on the back of some shit an intern threw down in a weekend and now you're too scared to touch it
- ido 4y ago
  If you want your project to last more than a couple of years And yet by your own reporting the project you're speaking of is still around 10 years later.
  - graypegg 4y ago
    I’d imagine rolenthedeep is trying to communicate that they survived in spite of their confusing codebase, not thanks to it. Maybe they could be shipping even more if they didn’t have to deal with the opportunity cost of maintaining it.
    - rolenthedeep 4y ago
      Yeah, pretty much. Last I checked, they've made no major improvements to the game since I left. They've just been pumping out DLC for the last several years. It took them a good five years to announce the sequel. Presumably because they had to scrap the entire bespoke game engine and redo everything from scratch. When I was there it was accepted as fact that the only path forward for a sequel was to start from zero and build a whole new engine because it was so bad. I could go on for days about it, but I think the best example was the Character class. At one point it was over 27000 lines of code split across 5 separate files. Characters took up an astonishing fraction of the total cpu time, especially considering that you'd have a dozen or two characters in a world with thousands or tens of thousands of other entities.
- tinglymintyfrsh 4y ago
  Yes, exactly. Throwing tech debt to the wind is going big bags shopping on a credit card. Someone will eventually have to pay the bill. I saw a startup that was so tech debt-heavy that they couldn't move. They were stuck daily patching nasty code. Engineers who don't care about code quality are like coworkers with messy desks that spill onto yours.
- gumby 4y ago
  > They're still shipping the same showstopper bugs nearly ten years later. They can't literally be showstoppers if they are still in business. Still, nobody accepts that level of crap any more when building, say, a bridge. They used to, back in the Victorian age, until they figured out what worked (the great victorian era bridges still in use are the ones that didn't fall down -- a survivorship bias). I think the fact that we only demand reliability from aircraft, trains, (some) med devices, spacecraft and banking shows how unimportant most software is. Most software will never need the level of reliability of the domains in my previous sentence, but sheesh, the needle needs to move in that direction.
  - rolenthedeep 4y ago
    To this day I see people play the game on YouTube and the player model will glitch out like it always has. Limbs go weird directions, or the tool you're holding will slowly expand to fill the entire screen. Vehicles regularly sink into the ground, or explode, or have a physics glitch that launches them into space. Totally unacceptable issues that have been around basically the entire life of the game. Their success is complicated, but in general the loyal players became conditioned to accept these bugs, while new players would hang out for a few weeks until their vehicle explodes and they lose days of progress for the nth time. Player turnover was huge, but they have a fairly large core of players who just deal with it.
_fat_santa 4y ago
I would say as an indie hacker, clean code, comments and good commit messages is almost more important than it would be with a small team. One thing I learned building an app over the last year or so is that as a solo dev, you have to be very deliberate and careful with your time. Any time that I spend fixing and refactoring code I already wrote is time that I can't spend building new features to the app. Granted there is a balancing act here but my experience so far has taught me that you want to go the extra mile and make sure your work will not need to be re-written, because that cuts directly into the time you'd spend working on new features.
- tinglymintyfrsh 4y ago
  Small teams can't have any dead weight people or internal limitations. My problem is often perfectionism gets in the way of shipping where I'll spend too much time on minutia. At work, coworkers are more liberal in tech debt accumulation because there's a drive to ship maximum impact that can be quantified.
100011_100001 4y ago
For me, the biggest benefit of commit messages is for myself, dealing with my own code, to be able to revisit a change that caused a new problem. I also like having the story id as part of the commit message so merge requests can be connected to stories. It gives a better overall picture of what took place.

by alexb_ 4y ago

rolenthedeep 4y ago

I used to work in a shop where "bad code is okay, we're a startup" and "our entire system depends on spaghetti written by an intern that quit after six months five years ago" were the norm. By the time I came along, the consensus among senior devs was that the entire project was a loss and we'd have to start from the ground up on the next project. They're still shipping the same showstopper bugs nearly ten years later. If you want your project to last more than a couple of years, or if you want to use it as a base to build other projects on, you should care about code quality. Don't try to implement an entire game engine on the back of some shit an intern threw down in a weekend and now you're too scared to touch it

ido 4y ago
If you want your project to last more than a couple of years And yet by your own reporting the project you're speaking of is still around 10 years later.
- graypegg 4y ago
  I’d imagine rolenthedeep is trying to communicate that they survived in spite of their confusing codebase, not thanks to it. Maybe they could be shipping even more if they didn’t have to deal with the opportunity cost of maintaining it.
  - rolenthedeep 4y ago
    Yeah, pretty much. Last I checked, they've made no major improvements to the game since I left. They've just been pumping out DLC for the last several years. It took them a good five years to announce the sequel. Presumably because they had to scrap the entire bespoke game engine and redo everything from scratch. When I was there it was accepted as fact that the only path forward for a sequel was to start from zero and build a whole new engine because it was so bad. I could go on for days about it, but I think the best example was the Character class. At one point it was over 27000 lines of code split across 5 separate files. Characters took up an astonishing fraction of the total cpu time, especially considering that you'd have a dozen or two characters in a world with thousands or tens of thousands of other entities.
tinglymintyfrsh 4y ago
Yes, exactly. Throwing tech debt to the wind is going big bags shopping on a credit card. Someone will eventually have to pay the bill. I saw a startup that was so tech debt-heavy that they couldn't move. They were stuck daily patching nasty code. Engineers who don't care about code quality are like coworkers with messy desks that spill onto yours.
gumby 4y ago
> They're still shipping the same showstopper bugs nearly ten years later. They can't literally be showstoppers if they are still in business. Still, nobody accepts that level of crap any more when building, say, a bridge. They used to, back in the Victorian age, until they figured out what worked (the great victorian era bridges still in use are the ones that didn't fall down -- a survivorship bias). I think the fact that we only demand reliability from aircraft, trains, (some) med devices, spacecraft and banking shows how unimportant most software is. Most software will never need the level of reliability of the domains in my previous sentence, but sheesh, the needle needs to move in that direction.
- rolenthedeep 4y ago
  To this day I see people play the game on YouTube and the player model will glitch out like it always has. Limbs go weird directions, or the tool you're holding will slowly expand to fill the entire screen. Vehicles regularly sink into the ground, or explode, or have a physics glitch that launches them into space. Totally unacceptable issues that have been around basically the entire life of the game. Their success is complicated, but in general the loyal players became conditioned to accept these bugs, while new players would hang out for a few weeks until their vehicle explodes and they lose days of progress for the nth time. Player turnover was huge, but they have a fairly large core of players who just deal with it.

_fat_santa 4y ago

I would say as an indie hacker, clean code, comments and good commit messages is almost more important than it would be with a small team. One thing I learned building an app over the last year or so is that as a solo dev, you have to be very deliberate and careful with your time. Any time that I spend fixing and refactoring code I already wrote is time that I can't spend building new features to the app. Granted there is a balancing act here but my experience so far has taught me that you want to go the extra mile and make sure your work will not need to be re-written, because that cuts directly into the time you'd spend working on new features.

tinglymintyfrsh 4y ago
Small teams can't have any dead weight people or internal limitations. My problem is often perfectionism gets in the way of shipping where I'll spend too much time on minutia. At work, coworkers are more liberal in tech debt accumulation because there's a drive to ship maximum impact that can be quantified.

100011_100001 4y ago

For me, the biggest benefit of commit messages is for myself, dealing with my own code, to be able to revisit a change that caused a new problem. I also like having the story id as part of the commit message so merge requests can be connected to stories. It gives a better overall picture of what took place.