And was it always wrong or has it become wrong due to a change in the ecosystem?
For further actions, you may consider blocking this person and/or reporting abuse
And was it always wrong or has it become wrong due to a change in the ecosystem?
For further actions, you may consider blocking this person and/or reporting abuse
ViitorCloud Technologies -
Grenish rai -
Oliver Bennet -
Sotiris Kourouklis -
Top comments (84)
That two similar-looking pieces of code must alway be abstracted out, because DRY.
The mistake here: people assume they need to DRY up repeated code. This is wrong. They need to DRY up repeated knowledge in the software.
Seems profound here and like this could be highly useful. Could you maybe expand on how to identify the difference between knowledge and repeated code?
I usually do feel like I want to DRY things up once I hit 3 or 4 times though, at least if the block of code is at least like 10 lines long
I think a useful heuristic is 3. If you see the same thing implemented 3 times, it's worth considering, at least, if it's time to refactor and DRY it up
That your programming skills outweigh the importance of your communication and collaboration skills.
This. So much this.
Communication and collaboration skills are the difference between being an asset to a team, and being a hazard.
"Never comment your code."
The truth is, you should never restate your implementation in comments. That, in fact, is almost always what proponents of this "wisdom" will cite!
However, while your implementation and naming should "self-comment" what the code is doing, it cannot explain why you did it, and more often than not, it fails to explain the abstract goal (or business logic). That's what comments are for: describe WHY, not WHAT.
I completely agree. I work for a company that makes software for Dutch healthcare providers. A lot of financial processing which we automate is based on legal standards. When implementing these rules we always add a comment pointing to the legal documents that it implements. This saves a lot of "why did you do this" questions.
That's the kind of comment I write these days. I'll go the extra mile if a weird hack is needed (e.g., to circumvent a bug in a framework or library, stuff like that). Throw in the best names I can come of with for classes, methods, properties, variables, etc.
One of our team's accepted code review standards is that comments should not need to be refactored when code is refactored. Keeps comments focused on the 'why', not 'what'.
Not a bad rule of thumb (keeps it language agnostic), although I don't know that it's altogether avoidable. In any case, if the two ever do fall out of sync, both should be carefully reviewed, as that's usually a signal there's a logic bug therein.
One of my favourite things in Go is the enforcement of good comments as documentation by the language.
That you always have to put extremly verbose and meaningful variable names. In general yes!
But it depends on the scope of the variable.
There is nothing wrong to use variable names like 'el' or 'num' in lambda functions like e.g. foreach(el => ...)
It all depends on your language's conventions. I've often seen these be standard, many coming from mathematics itself:
i,j: indices, loop control variables (no lifetime beyond context).x,y,n: temporary variables in algorithm (no lifetime beyond algorithm)n,num: temporary "number", such as an accumulator or the current value when iterating over numbers (no lifetime beyond context).v,val: temporary value, usually from iteration (no lifetime beyond context)x,y,z: coordinates (meaning from context).len: lengthiter,it: iteratorBeyond that, you should probably write real names.
That depends on what the loop, temp var (etc.) does. Sometimes having a meaningless name like that is perfectly fine, something you need something more descriptive as it may help read what's being done more easily (I just coded a case like that this morning).
Why not? I'd rather see a meaningful variable name that describes its purpose rather than something generic that I have to figure out on my own.
That an academic degree in computer science is needed for software developers. Worst: that said degree makes one a better developer (or a developer at all, for that matter).
Most CS degrees aren't solely focused on software development. They are rooted in theory, data structures & algorithms (and the mathematics beneath them), and whatever electives are offered by the institution (today a lot of them are AI/Data Science intro courses). In my program, we have two classes where we build big projects, and in the end, there's a capstone project, but I have no idea how developers function in the wild. I feel like a lot of CS students live under a rock (at least I do :D )
Academia is a long lost cause for producing really only two things - academics or good worker bees. Only life can produce educated thoughtful and well-informed people. As one of the comments mentioned Ai and data science, that's what industry wants not what you want. If you're going to waste money on a degree, waste a lot of money and take the classes that you want, then force yourself to do the minimum requirements for the degree but only because it's handy to help you get a job not because it has anything to do with education.
I agree with the above point, If I'm running
users.each do |u|in Ruby, I think thatuis pretty communicative, even if it's shorthand.But I'd personally avoid
var1or meaninglessx,y,z, even if it's just your own thing. That one second to come up with a somewhat meaningful variable still seems useful even for your own train of thought.This is probably a hot take, but when people say "choose the best tool for the job". There are so many tools and libraries out there that you aren't gaining much by sifting through all of them to find "the best" one out there.
More often then not, I see engineers get into "analysis paralysis" and end up taking a long time to make a decision when several of those options would be more than suitable.
Sure there are cases where the options aren't so plentiful, but this is definitely becoming the exception rather than the rule.
I think what's often meant is "don't listen to fad-based admonishments to use X or avoid Y." Of course, that's quite lost in "choose the best tool".
I tend to adjust that aphorism myself:
Use what works, popular opinion be darned.
I see this very frequently in common everyday engineering decisions. A recent one I saw was "Which config management tool should we use between Salt, Puppet, and Chef?". Others I see, "which static code analyzer...", "which framework...", "which data store...", "which log aggregation tool...", "which apm...".
There's definitely an element of "avoid the fad" in the conversation, but where I mostly see people get stuck is deciding between the more time-tested and stable options. Each option might be valid, but they get stuck on "find the best".
At that point, I like to ask them "Well, which one do(es) you(r team) know best?"
If that fails, and if the basic feature lists of each provides no insight, then flip a coin.
Sorry to reply twice, but I have to wonder...
How many people, by saying "use the best tools for the job", are actually only saying "use my favorite tools for the job"? (After all, "my favorite tools are always the best.")
I think this happens a lot and it definitely hurts the conversation.
I like your comment about flipping a coin :) It bothers some folks since it doesn't seem like a rigorous argument, but at that point you don't need one.
That titles mean anything. Junior, Mid-level, Senior. I’ve met Seniors who don’t know basic things and I’ve met Juniors who blow me away. It all comes down to the person’s ability to solve problems, learn and know when to ask for help if they’re stuck.
It's exactly the title based recruiting that companies tend to do that's keeping me from getting a new job at the moment. "You're a junior, but we're looking for a mid-level / senior type of person". Okay, but you have no idea what I know and what I can do... you can't simply base that off of an X amount of years someone has been doing it. You gotta look into what this person can actually do, not how much time he's been sitting behind a desk at company X.
I feel you there. I’ve been dealing with that for a while now. Luckily I’ve been interviewing with a company that is focusing on my work and not titles. Final interview is next Tuesday! Just keep building things and keep pushing! You’ll find something eventually.
That's amazing! I hope you get the job! Yeah, I've decided to start doing more stuff outside of my current job to enrich my portfolio. Probably do some freelance stuff so it's not just for a potential future employer.
Yeah that’s your best bet in my experience. Build so much stuff that they can’t ignore you! Freelance will definitely help you gain more credibility.
Java Slogan: Write once, run anywhere.
I think it was (that's from my memory way back in 1994 or so):
"Write once, run everywhere"
Which quickly turned into:
"Write once, test everywhere" because of all the different VM implementations. That was back in the Java 1.0.1 days.
:) ...
Write once, run anywhere... As long as the client has java installed and the versions are up to date... And the client has 50000 gbs of ram.
That $mylanguage is better than $yourlanguage.
Programming languages are tools that are meant for specific purposes. One language might be suited better than another in this scenario, but maybe not in another.
That's why I like to say "this is my personal favorite language" because I'm not trying to make claims about it being objectively better, but I enjoy working in it and with the scenarios it's best suited for.
PHP BAD
Thank you!