351–360 of 788 posts
> Typed languages are essential on teams with mixed experience levels I'm 30 years in now, and on balance, whilst they have clear advantages, I'm still not convinced that typed languages are essential, particularly for low level or module programming.
Do you think the Linux kernel could be written in a language without types enforced?
This is true of working with LLMs, too
Earlier quoted context omitted.
> the formatting and conventions of the blueprint Some of those formatting conventions are written in blood. The clarity of a blueprint is a big deal when people are using it to convey safety critical information. I don’t think code formatting rises anywhere close to that level, but it’s also trying to reduce cognitive load which is a big deal in software development. Nobody wants to look at multiple lines concatenat…
Fortunately nowadays formatting issues can be delegated to autoformatting in any popular language. Some people still argue over autoformatter parameters, but then people will always find a bike shed to argue about.
With clang-format & co. on Save plus possibly a git hook this all went away. It might not always be perfect (which is subjective anyway) but its so worth it.
How does > There is no pride in managing or understanding complexity interact with > If I think something is easy, that's a sure sign I don't understand it. ? Is it implying that you must understand the irreducible complexity, but mustn't take pride in that understanding? Or is "difficult" the opposite of "easy" here, rather than "complex?"
It's saying you don't need to be proud of your app that has multiple layers of abstractions to be immune to every possible change. There are hard problems, but the most complex solution is rarely good or best.
But once you’re more experienced you realize complexity is arbitrary and anyone can make things more complex
Earlier quoted context omitted.
> stressing over the formatting and conventions of the blueprint (to use a civil engineering metaphor) This is incredibly important. This is the kind of stuff that prevents shit like half the team using metric and the other half thinking they're imperial, or you coming up with the perfect design, but then the manufacturer makes a mirrored version of it because you didn't have the conventions agreed upon.
Imperial vs Metric is a hard requirement not a convention or formatting. I have a co-worker who wants everything to be a one liner, doesn't like if/else statements, thinks exception handling is bad and will fail a code review over a variable that he feels isn't cased properly. This makes code reviews super slow and painful, it also means you aren't focusing on the important stuff. What the code actually does and if i…
Many projects have fairly strict rules about identifier naming conventions, so this doesn't feel so far fetched to me.
The example about if/else vs ? : is pretty damning though.
Earlier quoted context omitted.
> time++; // increment time This isn't too many comments, it's a poor quality comment. Try: time++; // advance 1 simulated second
What is wrong with time++; That seem obvious enough to me without any comments.
"93%, maybe 95.2%, of project managers, could disappear tomorrow to either no effect or a net gain in efficiency. (this estimate is up from 4 years ago)" This made me laugh it is so true. My last big project at "Big Co" ( Knee surgery robot ) My small group went through 4 project managers - just for our small team. The entire project had probably 20. While a few where enjoyable to work with, there was very little val…
The rest? At best they were glorified QA/QC with a large stick to hit the engineers with when the spec wasn't met exactly. And when it was, and things still failed, they still hit the engineers with the large stick and were usually promoted for it.
Add Jupyter notebooks to the list.
Currently in a corporate environment where that seems to be the go to way of coding and it’s just fuckin awful compared to an IDE
Earlier quoted context omitted.
experience gives you some possible ideas for how it will be used in the future, but after a long time I'm coming to the position you're fooling yourself if you think you can predict where with any accuracy. It's still valuable and important to try, just not as critical to be right as I used to think. Example: I've completely flip-flopped from interface simplicity to implementation simplicity. I agree that a house is…
You have to be pragmatic about it, balancing between the speed of only implementing the now and the flexibility of taking care of the future. It's not predicting, mostly it's about recognizing the consequences of each choice (for later modifications) and and either accepting it or ensuring that it will not happen.
This is the exact trap I'm describing. It sounds very reasonable, but how is it not prediction when you're asking people to "recognize the consequences of each choice"? You have very little to no understanding of the context, environment or application of today's creations. Smart, experienced people got us into the current microservice, frontend JS, "serverless" cloud messes.
Earlier quoted context omitted.
That’s because the few hard rules you have to comply with have workarounds and matters rarely. In house construction, you have to care about weight, material degradation, the code, etc… there’s no such limitation on software so you can get something to work even if it’s born out of a LSD trip. But we do have some common concepts. But they’re theoretical, so only the people that read the books knows the jargon.
I mean why should we expect soft ware to have hard rules? Flexibility is the point, no?