4 ms·
In the vast majority of cases, writing good, maintainable code does not require more time. The real problem is that the majority of people working as software e
by manicennui 3y ago
In the vast majority of cases, writing good, maintainable code does not require more time. The real problem is that the majority of people working as software engineers barely know what they are doing, and use excuses like this because it makes some amount of sense to the incompetent managers in charge of them.
- bdangubic 3y agoIf I had a dollar for everytime I heard “we had a tight deadline” as an answer to a question “why is this code so shi*y” I’d have more money than Musk. There is no good code vs. bad code, there are just good programmers and bad ones. And given how many programmers there are in total, roughly 98.76% of them are the bad ones :) I am in my 26th year of this career and I can count on one had situations where a bad programmer wrote good code and good programmer wrote bad code.
- tacitusarc 3y agoI’d consider myself a good coder, and though I have the standard number of digits, I do not have enough to count the number of times I’ve written bad code. But I’ve written a lot of code, and over the decades I’ve learned a lot. I think that process requires some bad code along the way.
- dingi 3y agoAnd this is not a total narcissistic opinion at all. Just say all programmers are bad except you.
- bdangubic 3y agoIf you actually read my comment I never said I was the good one mate ;)
- roflyear 3y agoI would love to see an example of your code, please!
- mattgreenrocks 3y ago> In the vast majority of cases, writing good, maintainable code does not require more time Yep. Especially with practice. You can pretty much get to a point where you build things reasonably well by default without even thinking too hard about it. You have to want to attain it, and be willing to ruthlessly evaluate and file down your design repeatedly. I believe there's a compounding effect at play here, which accounts for super-linear gains in ability, given enough focus, time, maturity, and number of projects.
- BlackjackCF 3y agoI equate it a lot to writing an essay. Once you’ve gotten enough practice, you know the general structure. You’ll write a draft and then do some edits with some red ink. Then, if you have people willing to reas it, you get their eyes on it.
- hinkley 3y ago> You can pretty much get to a point where you build things reasonably well by default without even thinking too hard about it. That's mastery. There are probably about as many master programmers as there were master... let's say blacksmiths. The problem is there are 10, 20, maybe 50 times as many programmers as we ever had journeymen blacksmiths. And they all seem to think that tenure equals mastery. If we had 10, 20, 50 times as many masters, we'd have enough people to keep an eye on things. But we don't.
- Tade0 3y agoThis. And it's often simple techniques like preferring pure functions or using immutable data structures that enable a huge improvement in maintainability, yet few seem to be employing them. Occasionally the difference comes purely from the fact that someone looked into the library docs and chose the appropriate API method.
- hinkley 3y agoA large fraction of people doing woodworking videos are overtly or covertly pushing the fundamentals. If you don't have the fundamentals down what are you doing trying to do complicated stuff?
- jcul 3y agoI think one of the exceptions is heavily optimized code, though the surrounding code can still be maintainable and clear, with the weird stuff to tickle the compiler or inline assembly being heavily commented.
- a_e_k 3y agoFor those kinds of cases, I love having as-simple-as-possible reference code checked in alongside it, even if it's just #ifdef'd out for common builds. Having a baseline makes it sooo much easier to understand and debug the optimized code.
- RhysU 3y agoIdeally, the slow code is available alongside the fast code and the unit tests confirm they are sufficiently equivalent. If that's not possible, the go-fast bits need to be refactored until it is possible. Don't forget that error handling is part of the equivalency testing.
- DylanSp 3y agoBeyond unit tests, this seems like a great opportunity to leverage property-based testing, at least for pure functions; checking that both versions return the same results is an easy property to think of.
- deleted 3y ago[deleted]
- icedchai 3y agoI work with someone who regularly opens PRs for untested code. I'm talking stuff that hasn't even been run once: missing imports, undefined variables, etc... not bugs. I'm fine with bugs. I'm not fine with not testing your work in the most basic sense. PR reviews don't mean throwing crap over the wall and hoping the reviewer figures it out. With this guy, there is so much back-and-forth hand holding, it would be simpler to close the PR and do it myself. But I don't...
- beezlewax 3y agoWouldn't a linter catch most of this? You can also block commits with listing errors
- nly 3y agoIsn't this what draft PRs, CI/CD and automated integration tests are for?
- josephg 3y agoSounds like something to raise with their manager. Or with this person, before even reading the PR, "Hey - just to check before I review this, does it work on your machine? Have you tested it?". If they say no, close the PR and tell them to do that before opening it. If they lie, call them on it. If they aren't learning, don't waste your time hiding this useless coworker's failures.
- icedchai 3y agoI have raised it in the past and will do so again. One of the problems is the manager has no software engineering experience and his view of "working norms" often go against mine. Some of my complaints are fairly basic: test/review your own work before asking someone else to review it. This should be applicable regardless of industry.
- nathants 3y agotime to go next?
- zeroonetwothree 3y agoAgree completely. In fact it often takes less time to write code properly because you won’t have accidentally introduced a regression that you need to fix before shipping.