DEV Community

Ben Halpern
Ben Halpern

Posted on

What conventional wisdom in software is wrong?

And was it always wrong or has it become wrong due to a change in the ecosystem?

Top comments (92)

Collapse
 
katafrakt profile image
Paweł Świątkowski

That two similar-looking pieces of code must alway be abstracted out, because DRY.

Collapse
 
gypsydave5 profile image
David Wickes

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.

Collapse
 
technoplato profile image
Michael Lustig - halfjew22@gmail.com

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?

Collapse
 
kenbellows profile image
Ken Bellows

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

Collapse
 
imdanwu profile image
Daniel Wu

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

Collapse
 
silvestricodes profile image
Jonathan Silvestri

That your programming skills outweigh the importance of your communication and collaboration skills.

Collapse
 
codemouse92 profile image
Jason C. McDonald

This. So much this.

Communication and collaboration skills are the difference between being an asset to a team, and being a hazard.

Collapse
 
thojest profile image
thojest

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 => ...)

Collapse
 
codemouse92 profile image
Jason C. McDonald • Edited

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: length
  • iter, it: iterator

Beyond that, you should probably write real names.

Collapse
 
metalmikester profile image
Michel Renaud

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).

Collapse
 
guitarino profile image
Kirill Shestakov • Edited

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.

Collapse
 
codemouse92 profile image
Jason C. McDonald

"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.

Collapse
 
bjornhollander profile image
BjornHollander • Edited

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.

Collapse
 
metalmikester profile image
Michel Renaud

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.

Collapse
 
thompcd profile image
Corey Thompson

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'.

Collapse
 
codemouse92 profile image
Jason C. McDonald • Edited

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.

Collapse
 
gypsydave5 profile image
David Wickes

One of my favourite things in Go is the enforcement of good comments as documentation by the language.

Collapse
 
peledzohar profile image
Zohar Peled

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).

Collapse
 
tacomanick profile image
Nick Shattuck

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 )

Collapse
 
ericbalingit profile image
EricBalingit

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.

Collapse
 
_morgan_adams_ profile image
morgana

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.

Collapse
 
codemouse92 profile image
Jason C. McDonald

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:

Every tool has a valid use case.

Use what works, popular opinion be darned.

Collapse
 
_morgan_adams_ profile image
morgana • Edited

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".

Thread Thread
 
codemouse92 profile image
Jason C. McDonald

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.

Thread Thread
 
codemouse92 profile image
Jason C. McDonald • Edited

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.")

Thread Thread
 
_morgan_adams_ profile image
morgana

I think this happens a lot and it definitely hurts the conversation.

Thread Thread
 
_morgan_adams_ profile image
morgana

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.

Collapse
 
ben profile image
Ben Halpern

I agree with the above point, If I'm running users.each do |u| in Ruby, I think that u is pretty communicative, even if it's shorthand.

But I'd personally avoid var1 or meaningless x, 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.

Collapse
 
dyland profile image
Dylan Davenport

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.

Collapse
 
murkrage profile image
Mike Ekkel

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.

Collapse
 
dyland profile image
Dylan Davenport

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.

Thread Thread
 
murkrage profile image
Mike Ekkel

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.

Thread Thread
 
dyland profile image
Dylan Davenport

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.

Collapse
 
sm0ke profile image
Sm0ke

Java Slogan: Write once, run anywhere.

Collapse
 
metalmikester profile image
Michel Renaud • Edited

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.

Collapse
 
sm0ke profile image
Sm0ke

:) ...

Collapse
 
wagslane profile image
Lane Wagner • Edited

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.

Collapse
 
iamschulz profile image
Daniel Schulz

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.

Collapse
 
redoxeon profile image
Michael Harding

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.

Collapse
 
ifarmgolems profile image
Patrik Jajcay

PHP BAD

Collapse
 
jsn1nj4 profile image
Elliot Derhay

Thank you!

Collapse
 
_morgan_adams_ profile image
morgana

"It's industry-standard". This is often used to try and end debate, but the "industry-standard" for most things seems to have a shorter and shorter lifecycle as new and emergent technologies make them obsolete.

Collapse
 
guitarino profile image
Kirill Shestakov

If it's a phrase you have to use to explain a solution, then you're doing it wrong. Even if it's an "industry standard" for a good reason, the underlying reason for it matters more than the fact it's an "industry standard".

 
codemouse92 profile image
Jason C. McDonald

The _ convention should depend on your language's scoping rules. In Python, where there is no formal private scope, the _ convention is reasonable. However, in C++ or Java, where such scope is explicitly declared, the _ basically becomes noise, in the same manner as Systems Hungarian notation.

Collapse
 
jmfayard profile image
Jean-Michel 🕵🏻‍♂️ Fayard

Devs think that's it's a good practice to share and follow good practices.

But in fact you shouldn't copy a solution from $bigCompany unless you are sure that you have exactly the same problem.

And you usually don't have the same problem than Facebook.

so here is my advice for advice givers:

I know that you have good intentions, want to help and are excited by the solution you have found to your problem.

But do realize that your readers may have totally different problems, so explain first what is your context and the problem you needed to solve.

That will help your readers a lot to understand whether your advice is meant for them and to see what is the trade-off.

Dan Abramov did this really well

Collapse
 
jwp profile image
John Peters

"umm, let's see, that'll only take a week"...

I've never; in 30 years, seen a pre-determined due date happen.
Even Agile cannot predict due dates for software. Yet everybody is doing it.

Collapse
 
andrewharpin profile image
Andrew Harpin

Yes and no, a pre determined due date from a project manager, definitely not. From an experienced dev, some of the time.

Collapse
 
jwp profile image
John Peters

Experienced developers can do it, but only in two week cycles.

Collapse
 
missamarakay profile image
Amara Graham

Does "we tried this already" count as conventional wisdom? 😝

Collapse
 
_morgan_adams_ profile image
morgana

This one hurts 😂 😭

Especially when there's no documentation to review what was "tried" or what the results were.

Collapse
 
missamarakay profile image
Amara Graham

You get me!

Collapse
 
jwp profile image
John Peters

Yes, it's a problem because, what they don't say is when they tried it. This is the same fallacy as 'we've always done it this way'