101–110 of 211 posts
> In JavaScript, this is often indicated by new Promise inside a .then(). I have found myself doing this sometimes, why is it considered bad practice?
As an addendum perhaps to the Organize and Design Systems section, I'd propose including mise-en-place as it applies to project maintenance and the development environment. This centers on tooling and documentation, especially the README. I want a README that gets me set up and running as quickly and in as few steps as possible. Recently I needed to test out some stuff one of my teams was working on. It was a somewha…
Mise-en-place is so important. Inexperienced engineers sometimes find themselves in teams which don’t appreciate it. Because confrontation can be nausea-inducing, they sometimes don’t endure the discomfort to insist on it. ——— When a customer walks into a restaurant, does he ask about the temperature of the fridge the chicken is stored in? Does he ask if the kitchen is clean and organized? No. Thats the chef’s job to…
I "fondly" recall one early job in my career starting with the promoted-from-the-ranks dev lead filling a whiteboard with boxes and acronyms... an overwhelming brain-dump to a newcomer that took hours of time spread over days. By the time I'd sorted out what we really did, months later, I could explain the whole thing to a new hire in fifteen minutes. One easily understood diagram, pointers to the two actually-important directories in our codebase, and some context – and they would be off to the races. Funny enough, I met a number of other people at that gig that thought of their work as "irreducible". One was, to use the recent meme, a "10x engineer" for whom the company maintained a rotating roster[1] of tech writers to follow around everywhere and try in vain to record what the heck they were doing.
[1] "rotating" as in "hired, then fled screaming"
Most programmers do not follow the Golden Rule, which is to write code you'd like to maintain with minimal training. It's a principle, but there are various skills involved in doing it successfully, including writing, automation, design, seeking quality peer review, and a few other things. Similarly, writing code that can be deleted is an important skill. Using "good design" and "knowing your language" are fairly neb…
> writing code that can be deleted is an important skill Are you saying "I can easily delete this code from the project" is a metric for modularity? That's really interesting, is it your own thought?
* computers will always run my code fast
* infrastructure problems will not happen
* our team will always have plenty of time to understand my code
* users are not malicious and the libraries I depend on are not malicious
* I will always have to plenty of time to diagnose and fix problems in this code
The author covers some of that.
But you can care about those, and still be a poor programmer: being too pessimistic is problematic. You need to pick your battles and spend your time mindfully.
Now, I have a problem with this:
> Naive programmers think that design means “don’t make functions or classes too long”. However, the real problem is writing code that mixes unrelated ideas.
How do you enforce that policy using a linter? How do you audit a large project for these issues? You can count characters in a line, you can count lines of code in a function or file, and you can count import statements. All those are indicators of coupling unrelated ideas together.
Well, where he says "You may have seen code which misunderstands how expressions work: if isDelivered and isNotified: isDone = True else: isDone = false; Instead of: isDone = isDelivered and isNotified " I think that's a matter of style, I prefer the isDone = isDelivered and isNotified style myself, and I think the people who write the other way have very poor style but as arrogant as that sounds I don't think I woul…
In college they taught me that every line of code should do one thing and one thing only. So doing both a test and an assignment on one line would not be prefered over the first example(split over multiple lines). I don't have a lot of experience with programming so for now I do what I was taught. :)
Taking that at face value results in something like Asm written in a high-level language: very short lines with not much on each one, and it's a pain to read and understand because you have to scroll two pages to see what could be accomplished in a dozen lines. I've seen code written in that style and it was not easy to work with. (What often goes along with that, "every function 'should do one thing and one thing only'", is even worse when taken to its logical conclusion --- it turns lots of scrolling into lots of jumping around.)
I don't have a lot of experience with programming so for now I do what I was taught.
Reading the code for lots of other successful open-source software will probably tell you far more useful things about how to write code than the "indoctrination" that passes for teaching these days. I'd recommend older codebases; the newer ones tend to unfortunately show the same bad habits due to the reasons above.
Earlier quoted context omitted.
Can you give a clear example on “thinking in types” approach ?
I can’t speak for the parent, but my take on it is a skilled programmer would define structs or classes, for example: parent, student, address While the unskilled would: parentfirstname, parentlastname, parentaddress1, .... studentpostcode
Incidentally, that's another thing about the difference between actually-skilled programmers and "pretenders": the former will always explain something in very simple terms, while the latter will try to use as much abstract and vague technical-sounding terms as possible.
> You may have seen code which misunderstands how expressions work: > if isDelivered and isNotified: isDone = True else: isDone = false; > Instead of: > isDone = isDelivered and isNotified Are people actually finding code like this in professional work or is this just an example? I'm self-taught and know I've got some gaps, but this example is so fundamental I find it shocking.
> In JavaScript, this is often indicated by new Promise inside a .then(). I have found myself doing this sometimes, why is it considered bad practice?
I guess because inside of a then() you can simply return the success case and throw the error case, no need to create a new Promise and call the resolve/reject functions.
Most programmers do not follow the Golden Rule, which is to write code you'd like to maintain with minimal training. It's a principle, but there are various skills involved in doing it successfully, including writing, automation, design, seeking quality peer review, and a few other things. Similarly, writing code that can be deleted is an important skill. Using "good design" and "knowing your language" are fairly neb…
It is in every engineer to write the gold plated car, as it is in marketing and sales to always need the future tomorrow to gain competitive edge.
The number of times I wrote beautiful code are quite numerous, the number of times it is still not used to its potential as well. In the end I spent too much time over engineering for a disastrous moment or extension that never happened, or was never requested by a customer.
I have written godforsaken shortcuts that are used so frequently it made me feel proud and ashamed at the same time.
Now, I have come to believe that knowing when to stop is the greatest skill of all.