> Most programming should be done long before a single line of code is written What does this mean?
That you must design the system before you type it down as code. Once you make the wrong assumptions or wrong abstractions no amount or skillful coding can save you. You risk solving the wrong problem perfectly.
Software development topics I've changed my mind on
621–630 of 788 posts
Re: Software development topics I've changed my mind on
#622Just personal opinions, I guess, I agree with most, but here are some I disagree with: - There is no pride in managing or understanding complexity Complexity exists, you can't make it go away, managing it and understanding it is the only thing you can do. Simple systems only displace complexity. - Java is a great language because it's boring That is if you write Java the boring way. A lot of Java code (looking at you…
> time++; // increment time This isn't too many comments, it's a poor quality comment. Try: time++; // advance 1 simulated second
seconds++;
That gets the idea across very clearly to me and has the benefit of (likely) making the rest of the code clearer tooRe: Software development topics I've changed my mind on
#623Earlier quoted context omitted.
I 100% agree. The problem is that after a half a century, software engineering discipline has been unable to agree on global conventions and standards. I recently had an experience where a repair crew was worried about the odd looking placement of a concrete beam in my house. I brought over the blueprints, and the technician found the schedule of beams and columns within seconds, pinpointed the beam and said, "Ah, th…
I don't know that we'll ever be able to agree on "global standards" though. Software is too specialized for that. The only software standard that I'm reasonably familiar with is https://en.wikipedia.org/wiki/IEC_62304 which is specific to Medical Devices. In a 62304-compliant project, we might be able to do something like your example, but it could take a while. OTOH, I'm told that my Aviation counterparts following…
Re: Software development topics I've changed my mind on
#624> You have to actively invest in improving your soft skills (and investments pay back immediately) Can anyone elaborate how does one do that? I have seen this advice many many times but never anything actionable attached to it. I believe my soft skills are my biggest weak point right now and is holding me from growing further in my career and I would like to do something about it. But I have no idea how.
Re: Software development topics I've changed my mind on
#625> ORMs are the devil in all languages and all implementations. Just write the damn SQL It depends on what you're writing. I've seen enough projects writing raw SQL because of aversion to ORMs being bogged down in reinventing a lot of what ORMs offer. Like with other choices it is too often a premature optimization (for perf or DX) and a sign of prioritizing a sense of craftsmanship at the expense of the deliverables…
I've never understood the ORM hate because a good ORM will get out of the way and let you write raw SQL when necessary while still offering all of the benefits you get out of an ORM when working with query results: 1. Mapping result rows back to objects, especially from joins where you will get back multiple rows per "object" that need to be collated. 2. Automatic handling of many-to-many relationships so you don't h…
Also, infrastructure guys and DBA types tend not to like ORMs. But they are not the ones trying to manage the complexity in the business process. They just see our queries are not optimal, and it is everything to them.
Re: Software development topics I've changed my mind on
#626Earlier quoted context omitted.
Yes. I love how gofmt has no settings, basically. Is this how you envisioned? Great. Now I don't have to think about optimizing it. Coincidentally, the choices they made are the choices I'd made, but it doesn't matter in the end.
Vehemently disagree. I get that go's conventions line up with your own, but when they don't, it's irritating. For example, Dart is finally coming around on the "tall" style ( https://github.com/dart-lang/dart_style/issues/1253 ). But why should people be forced to wait for a committee (or some other lofty institution) to change a style convention that then effects everyone using the language? What's the harm in letti…
Exactly to avoid conversations like this...If you want a tall format then just add a dummy comment at the end?
Re: Software development topics I've changed my mind on
#627Earlier quoted context omitted.
More than one writer refuses to use a computer, preferring typewriters. Harlan Ellison learned how to repair typewriters after he could no longer find anyone to fix his. Stephen King wrote Dreamcatcher with a fountain pen. Authors totally obsess over details that seem irrelevant to people outside that craft.
And that’s totally fine! But there is no correlation whatsoever between writing on a typewriter or using a fountain pen (or the physical experience of writing generally) and the quality of the writing. None. There is nothing to support this in either writing or programming, at all. For every software craftsman out there obsessing over formatting, editor layout, linters, line length, there is an ancient, horrifyingly…
There is no way this is true. There;s 100% chance that no human is productive is uglified JS code.
Re: Software development topics I've changed my mind on
#628agree on 10/11 because i have not used DynamoDB ;) by the way, whats wrong with serverless functions? Given a long enough time horizon, you'll deeply regret building on Serverless Functions
Re: Software development topics I've changed my mind on
#629> Most won't care about the craft. Cherish the ones that do, meet the rest where they are > (…) > People who stress over code style, linting rules, or other minutia remain insane weirdos to me. Focus on more important things. What you call “stressing over minutiae” others might call “caring for the craft”. Revered artisans are precisely the ones who care for the details. “Stressing” is your value judgement, not neces…