111–120 of 121 posts
Earlier quoted context omitted.
I was just told at my day job that the team will not be using VC for tracking production analytics code because "using git is over-engineering".
Time to start the job hunt.
Earlier quoted context omitted.
I used to think those books were great before I got my first job at FAANG. Literally the only thing that matters is moving fast. Technical debt is just the price of scaling and beating the competition. Code quality is really not important at all as long as the product works and is bug free. So I’ve become extremely nihilistic about software development. It isn’t that I don’t think the properties of clean code and sof…
> Literally the only thing that matters is moving fast > Code quality is really not important at all as long as the product works and is bug free According to Robert C. Martin is not possible to move fast without good quality.
Of course scaling to billions of users only proves that it can be done without quality, not that they could have done it better with quality software.
Earlier quoted context omitted.
Would you still recommend the original version? I have a printed copy and tried to read it ages ago, but gave up (it bore me). I am sure I'd appreciate it better now, but with a new edition coming out I'd be wondering whether I'm missing out.
Hunt and Thomas themselves don't really recommend it anymore. Large parts of the industry have changed over the years. They're interviewed in episode 352 of The Changelog podcast. It's worth a listen if you're a fan, or interested in either edition.
Earlier quoted context omitted.
> I think that so many of the practices (like version control) have become so popular that reading an argument for their use seems superfluous. This made me laugh - not because you aren't right (in theory), but because I just took over a project from a big four consulting company. When I asked about the location of the latest version of the code (after looking in VC and not finding it)...answer: on the production ser…
My business partner worked at an education-related company you've almost certainly heard of about six or seven years ago. When he started he ask where the defect tracking system was. The guy he was talking to pointed and said, "Go ask Susan. She has a spreadsheet." It was, as you can imagine, pretty much all downhill from there.
Earlier quoted context omitted.
When I finally read Romeo and Juliet, I was surprised at how many cliches and tropes were in it.
When I finally read Romeo and Juliet, I was surprised at how many cliches and tropes were __from__ it. There, I fixed that for you. ;)
Earlier quoted context omitted.
I understand just fine, it just sounds like software is too hard for some folks, and while that's okay, but there are those of us who aren't burned out by doing our jobs.
You actually said 2 things. I thought your first point was perfectly reasonable, as you misinterpreted it. > Whats with companies constantly throwing people in the trenches and forcing them to be in constant maintanence mode all the time? > Because companies like to make money, and they can't make money when systems fail. The second issue you raised is a nonsequitor, because you clearly misconstrued the initial point…
Earlier quoted context omitted.
Since many of us have vastly different jobs in practice (no matter similar in principle), your continued insistence that people being burnt out by their jobs means that software is too hard for them is obnoxious and blatantly untrue.
Except I didn't say that. I said that if maintaining software burns you out, then maybe software is too hard for you. So the only blatantly untrue and obnoxious comments right now are yours. Seems like this might be hitting too close to home!
Maybe you are someone who enjoys maintenance. Glad you've found your niche. But don't insult people who are good at what they do, but don't enjoy the parts they don't enjoy.
Earlier quoted context omitted.
Except I didn't say that. I said that if maintaining software burns you out, then maybe software is too hard for you. So the only blatantly untrue and obnoxious comments right now are yours. Seems like this might be hitting too close to home!
Do you not enjoy greenfield projects? Many programmers prefer them. If you never get to do greenfield projects all the time and are instead stuck doing maintenance, that doesn't sound like a lot of fun right? Maybe you are someone who enjoys maintenance. Glad you've found your niche. But don't insult people who are good at what they do, but don't enjoy the parts they don't enjoy.
A developer without a mind for writing maintainable code is a bane to the existence of everyone who works with him/her, and a developer who constantly builds new projects and does not have to stick around to keep them running will never grow that mind.
Earlier quoted context omitted.
My business partner worked at an education-related company you've almost certainly heard of about six or seven years ago. When he started he ask where the defect tracking system was. The guy he was talking to pointed and said, "Go ask Susan. She has a spreadsheet." It was, as you can imagine, pretty much all downhill from there.
was this education-related company, related to moocs ?
I was underwhelmed by this book. I think that so many of the practices (like version control) have become so popular that reading an argument for their use seems superfluous. That also makes it really jarring when it recommends something that decidedly hasn't taken off, like the blackboard design pattern. I had the same experience reading "The Design of Everyday Things". To some extent, these books seem most valuable…
20 years ago this stuff wasn’t prevalent, and now people should at least be able to make educated decisions. But, alas...