DEV Community

Cover image for What coding concept or practice seem commonly understood, but you never learned?
Ben Halpern
Ben Halpern

Posted on

What coding concept or practice seem commonly understood, but you never learned?

Let's say you work independently and you get by, but maybe you're a little afraid that if someone were looking over your shoulder you might be exposed — even if you're a senior dev?

Latest comments (78)

Collapse
 
hello10000 profile image
a

memoization

Collapse
 
qureshi81 profile image
qureshi81

Javascript Document object model.

Collapse
 
pavelloz profile image
Paweł Kowalski

TypeScript. I fail to see a profit in obfuscating the code so much for better linting.

Collapse
 
tinussmit profile image
Tinus Smit

Unit Tests. It comes from years of inheriting code that did not follow proper OOP guidelines, and thus not easy to write tests for. When entire swaths of business logic sits behind Button1_Click in Blah.aspx.cs, then there's just no easy way to introduce testing.

I've since learned that it's easier to put such logic in a Class Library project, and I even sometimes just have an additional Console Application that references it and I can easily step through without all the manual steps of the UI. I understand the concept, but I just don't have the practical experience 😅

Collapse
 
oricohen profile image
OriCohen05

Meaning of pseudo code

Collapse
 
marcello_h profile image
Marcelloh

invented to make something complex more understandable without the burden of being totally syntactically correct.

if I would write a part in real code, and make one typo, probl. 50% of the people is complaining about "it doesn't compile" instead of getting the idea behind it.

Collapse
 
rajvirsingh1313 profile image
Rajvir Singh

Design Patterns, they are little hard to understand but when you understand them. It is like when you have hammer everything looks like a nail.

Collapse
 
adam_cyclones profile image
Adam Crockett 🌀

10 years on... SQL 😱 please don't tell anyone

Collapse
 
maxart2501 profile image
Massimo Artizzu

Big-O notation.
I didn't graduate in CS, so I never had the chance to learn it academically. And while I could have taken some time to learn it on my own, in my everyday job it's not really that important to aim for the best performance.

It's not like I couldn't see common performance pitfalls, mind you. But if you ask me to compute the big-O value of a function, it's very possible I could be wrong.

And sometimes it bit me when doing Advent of code challenges.

Collapse
 
highcenburg profile image
Vicente G. Reyes

CSS and ReactJS in general 😆

Collapse
 
dagr8 profile image
DAGr8 • Edited

Favorite thread ever

Collapse
 
dagr8 profile image
DAGr8 • Edited

/me googles all the things. /me using self made cheat sheet /me not know why he should be uncomfortable copy paste anything wether its an ssh cmd or git cherry-pick head tilden 2. So yea im not. But if any dev would see me coding live they would have a blast watching how lazy I can be googling for getAttributeBysomething[something=something] or if rhe areayname goes first or last in pregmatch strpos etc

Collapse
 
k_penguin_sato profile image
K-Sato • Edited

CSS Grid Layout.........😢

Collapse
 
dagr8 profile image
DAGr8 • Edited

Grid aera is so fun its all u need and pretty easy

Collapse
 
theaccordance profile image
Joe Mainwaring

The last time I encountered this type of question it was around 100% Code Coverage.

I had several years of exposures to tests but our team and products didn't fully embrace the strategy; I wasn't seeing the value in terms of code quality, rather just a check that what you wrote isn't broken upon a later revision.

After our company was acquired, the new engineering org embraced a standard of 100% code coverage. That is a very high bar, and we do allow exceptions, but overall the team has been able to meet that standard with ease.

With our projects having 100% code coverage, we saw improvements in Frequency of Deployments, Lead Time for Changes, MTTR, and Change Failure Rate (Read the book Accelerate if you're unfamiliar with these metrics), ultimately allowing us to build a product at scale - in terms of collaborators (~50 engineers) and deployment stability/consistency.

Collapse
 
marcello_h profile image
Marcelloh

Unfortunately, 100% code coverage doesn't say much if done the wrong way.
We aim as high as possible, but the complex code before the simple code.
And anything added should be covered by a test.

Collapse
 
theaccordance profile image
Joe Mainwaring

Read the book I reference in the original comment, if your engineering org adopts those practices, 100% code coverage makes a significant difference.

Thread Thread
 
marcello_h profile image
Marcelloh

Which book is that. Tried to find you book reference, but can't find it.
BTW: if we write a test for a simple getter (or for generated code for that matter), that will be the day that all other significant tests are written :-)

Thread Thread
 
theaccordance profile image
Joe Mainwaring

Accelerate

Collapse
 
darthbob88 profile image
Raymond Price
  • Multi-threading; I can copy'n'paste other people's work, and sometimes change it, but I can't write it myself.

  • Web animations; I can write very basic transitions for like moving from one location to another, but I can't do anything complex.

  • (Large) System design and architecture, particularly WRT the cloud. I can build and run small projects, but anything big enough to make money off of is beyond me.

Collapse
 
nicm42 profile image
Nic

Recursion. When I read about it I understand it, then forget everything 5 minutes later.

Collapse
 
dagr8 profile image
DAGr8

Read(something){
something.forget;
Read(something);
}