What’s a concept you understand now, but took you forever to grasp?

I’m sure we all have plenty of answers to this one, but sometimes we forget how far we’ve come.

Did you find this post useful? Show some love!
DISCUSSION (95)

Code is like 10% of what is required to build software systems. The other 90% is not code.

That a programming language is just a tool to an end. It’s surely important to pick the right tool, but it’s much more important to learn programming techniques rather than languages. That it is better to learn to think rather than memorizing. That there are no geniuses, only hard work and persistence.

Absolutely. Nobody needs to be a genius to do this. The job of an engineer is to solve problems with appropriate tooling. If you think about it, everybody commits acts of engineering every day. It's just that when in the context of computing systems, you just need to think in a different way and get used to leveraging a different set of tools.

  1. JavaScript Promises.
  2. The referencing of this in JavaScript.
  3. CSS display property. (Sometimes I still don't get it).
  4. Lambda and Proc in Ruby.
  5. DyanmoDB
  6. ECS and EC2 on AWS. (I still don't get it).

This list could cross the count of a hundred.

Nowadays I have a pretty solid handle on webpack, babel, and other related tools, but it took me a long time to get here. The entire Node ecosystem, including its meta tools (essentially all the devDependencies), were really tough for me to grasp.

The interplay between browser, server, and developer-run javascript can still get me caught out sometimes.

I find myself having a hard time switching to the React toolchain. The concept of needing a preprocessor for your HTML/js before it can be opened by a browser really bothers me. One of the best things about web development imho was that code would just run as-is in the browser.

Or maybe I'm just getting old.

medium.com/the-node-js-collection/...

For anybody that can relate to this thread, that is an amazingly well put together article that helps with understanding different pieces of the modern front-end dev world...

Oh wow, that's an excellent resource.

I absolutely love learning the "why" behind everything, and that post does a great job of covering it all. Thanks for the recommendation!

Interplay between browser and server still confuses me. Any articles on figuring this out would be appreciated - what's served to browser, run on server, how does this get setup?

Pointers. I'm totally 100% unsure why now, I think they must have been explained really poorly, but I didn't get them at all at first.

This too. The course I taught went full on Java so the C++ type pointers were no longer used. But as long as C++ was around I struggled with getting the right resources to help students with it.

In my college experience, I think pointers were just introduced too early in the curriculum. Students are barely able to grasp the fundamentals of control flow and scope, are just starting to learn about types, and are then thrown in the deep end with pointers. Until you really understand types and good variable scoping, pointers will make no sense.

People often hate or love C++. It is certainly a complicated language. But I love it because it really showed me how data is truly represented in memory. Not only C++, you go with assembly and will get references, pointers and everything else. In the end there are no pointers and references, only memory addresses :)

In my opinion there are two main issues: C uses fucking awful syntax for pointers which is always a stumbling block when trying to learn something.

The second is that most explanations only tell you what pointers are, not what they're used/useful for.

The, "used/useful for", bit being particularly key there.

Functional programming. I got the how but I never understood the why.

I took a free FP course on edx.org that taught me some Haskell and it Al clicked.

Unfortunately, I am forever doomed as I have a hard time going back to non-fp.

Same. Though, learned functional programming with Lisp, which I am sure makes me worse than even I can comprehend.

Same here. Functional Programming was very frustrating for me wondering all that's side effects and pure functions etc.

Right now it's something I can't really seem to abandon.

All thanks to a strict frontend development library called Hyperapp. It enforces FP in JavaScript.

I'm still looking towards learning more as I still have alot of cool things in FP I haven't learned.

Same here. Functional Programming was very frustrating for me wondering all about side effects and pure functions etc.

Right now it's something I can't really seem to abandon.

All thanks to a strict frontend development library called Hyperapp. It enforces FP in JavaScript.

I'm still looking towards learning more as I still have alot of cool things in FP I haven't learned.

Same. A co-worker introduced me to F# a few years ago. I thought it was a bunch of baloney.

Then PF started to click. C# is too...verbose for my taste.

I'm forever cursed.

Here are a few of mine in no particular order and not necessarily only code related:

  • Pointers and memory allocation in C
  • Why kids are not taught financial literacy in schools
  • Sorting algorithms
  • The power of habit and compound interest
  • The importance of having a coach
  • N-dimensional arrays
  • The importance of failing
  • Linked lists
  • The importance of starting a blog
  • A* search algorithm
  • The importance of living below one's means and staying humble

The importance of starting a blog ? Please explain me

I was told, way back in the day, that it's important to start a blog and get your name out there. For a very long time, I was baffled by that statement and thought it's a waste of time (don't judge, I was young :)).

It wasn't until I started my own, for no other reason than to have my notes searchable (Evernote was not a thing back then), that I saw the huge impact it had on my career.

As I was honing my skills as a 'blogger', my general writing improved, so I was able to communicate my thoughts in a clear an concise manner. Mind you, I was learning about getting better at writing, and I was publishing posts on a 'multiple posts per week' basis.

Few years (yes, years) forward, I got such writing (and working) possibilities that I could have never even dreamed.

Therefore, get your name out there and share the knowledge freely. The effort will be rewarded in multiple ways in the long run.

Is it simple? Yes. Will it be easy? No.

Good luck!

I put this in the same type category of Lisp and Haskell that Linus did, to a degree, "anyone who [understands] it is probably crazy and dangerous."

Recursion . I understand that recursion is where a function calls itself, until it doesn't.
But given a problem statement, transforming it to recursive program is still difficult to grasp.

I understand that recursion uses stack frames to load the function.
Hence I too solve such problems like DFS (Depth First Search) using stacks and for-loops

I experienced the same as a CS student,lots of practice and use of recursion helped!

It took me so long to understand recursion, like 2-3 years before I felt comfortable thinking recursively. Making recursive solutions early on required just throwing shit at a wall and seeing what worked. Now it (recursion, not throwing shit at walls) is my favorite way to solve problems.

It took me a a while to get the hang of using Git in a team. It is scary to push the changes at first. Merging issues, stashing, undo, how every one uses Git flow differently, etc a lot could go wrong.

For now I am struggling with understanding AWS, continuous integration and a bunch of new technology.

Totally agree with this but in more general terms, the concept of distributed version control. We started with Mercurial, and I remember being able to use it but could feel like I was missing something. Eventually once it clicked, understanding git became easy.

There are still some things left but these are the Big 4 of them:

  1. HTTP (only have a rough idea but it's enough)
  2. APIs (much simpler than I thought)
  3. The server (still don't completely get it)
  4. Recursion

Overall, the back-end stuff always leave me clueless and learning them in the past is like going on a random place for some unknown reason. Learning one of the three led me to understand the other two and so on.

Singletons and the static keyword (in class declarations), that took me a while. I had a hard time with it when I developed in PHP. Interestingly, when I started doing more work in JS I got the concept :)

In which cases do you use singletons? I’m not big fan of them and try to use it as little as possible.

It's useful to store global state. Similar to Vue's vuex or React's redux.

The Model-View-Controller setup. I saw references to it everywhere but never really got how it worked or why it was important. It was only until using an actual framework did I see how it was useful in building apps to scale.

Yeah this was a big one for me too. It made logical sense - I understood by reading, but I didn't truly appreciate it until I actually used it.

  • The N+1 problem. It took bringing down the production website to really understand why it was such a huge problem. And then, when I reduced the time to do an expensive batch calculation from around 30 seconds per user (needing to batch around 20 users at a time) to just a couple of seconds for the entire batch, it really clicked how fast a database really is, and how ORMs are optimized to fix these problems if you know what you're doing.
  • Parsing expressions. I really like writing parsers and want to create a toy language someday, but expression parsing is something that eluded me for the longest time. The algorithms needed to parse an expression is just so dense and mentally difficult to grasp, despite the actual implementation needing very little code. I have a much better grasp on it now and can at least understand how these algorithms work, but there's still lots for me to learn before I could write my own toy language.
  • Caching. Ah who am I kidding, I still don't know this very well 😜

Design patterns - most of them.
Still trying to decode every single day ;-)

You and me both :D Been at it 14 years and all I can do is name like, 3 of them.

You spend 80% of your time creating flowchart(s) for the program. The remaining 20% is actually coding and actually implementing your abstract flowchart into a concrete program. Which, if you design the program properly, should be a piece of cake.

I do not remember an example but Im living one now:

Kafka SQL, looks like SQL but because they work on streams the queries never end, and on top of that there are multiple ways to interact to the KSQL server.

  1. Backtracking
  2. Dynamic programming
  3. Learning to use some higher order functions like reduce and flatMap
  4. The utility and power of sed!

I have to agree with this list. Bullet points 1 and 2 really took me a while to fully understand (I still sometimes struggle with it though). But the moment I gradually realize the concept was a learning FP especially with Haskell.

Dependency Injection, but time to time I need to revisit it.

I still don't understand it :)
It seems to me every time I try to read up on it it is something different than what I had learned before.

Refactoring.

The concept is easy enough of course.

However, as a beginner watching videos it seems the creators just KNOW what module, class, etc. to use. Some false sense of perfection is unintentionally communicated.

So if you truly embrace refactoring you also liberate your self from that false perfection. Just start: as you code the questions and cleanup organically appear and evolve.

How to implement exponential back off with JavaScript callbacks. Once I got it working I copied the snippet of code into my snippets notebook and always, always had to just look it up every time I needed to implement it again.

Things got easier once Promises arrived and now with async/await it’s trivial.

I don't know if it took me forever, but this year one of my goals was to fully understand functional JavaScript. I read Eloquent Javascript, practiced a lot. I'm sure I don't know the half of it, but now that I get it, I think it's very powerful.

The model layer, and that using MVC doesn't mean everything has to go into either explicit model classes, views or controllers.

I know from experience that I'm not the only one to not get this earlier in my career, as I wrote several applications with fat controllers, and now work on several written by other people.

Pointers, in C++(other langs I've used obfuscate them) specifically for me.

I still kind of wonder if pointers are like zen koans in the idea that if you think you understand them, then you don't understand them.

DNS. Seemed like magic for the longest time.

The OO concepts like inheritance, polymorphism and especially: what is it good for.

I had problems to understand what percentiles were and how they could be used to analyze metrics. I started to understand only when a peer told me "imagine all your measurements, order then and only took the X results where X is meant to be the pX". That's was a great moment :).

For details: medium.com/@djsmith42/how-to-metri...

This will sound strange but: Efficiently writing effective unit tests. Too often when starting out I would write tests that were redundant, dual purpose and overly complex. I would even test functionality that was not the responsibility of the unit under test. Now I focus on strong coverage of the API and refactoring each unit so that a high percentage of coverage is easy to accomplish while remaining meaningful.

This talk is one of many that helped me improve:

destroyallsoftware.com/talks/bound...

But mostly it has been learned through time and tears spent re-reading old unit tests that did not stop bugs and took way too long to write.

That a pointer in C could point to a function - functions live at an address just like data. Which helped me understand most programming languages I’ve encountered.

Also that a well firing agile team can be a thing of beauty. The trick is getting it firing!

Unit testing! Haha. I was so nieve when I thought "I write good code, I don't need unit tests!"

Containerization. I'm taking time currently to tackle this one, but the difference between an image and a container is so subtle that it's very hard to comprehend at the beginning.

Technology does not solve human problems. Only humans do.

Context: I started as a young bright eyed optimist, that tech could be used to solve everything. Only to realise most problems in the world out there are not due to tech, but human nature.

Tech may at times make certain solutions - easier, cheaper, or harder to do so (possibly all 3 at the same time).

But ultimately only us humans can make our own selves better. With tech being the enabler to solutions previously too expensive, or too complicated.

Memoization has been a bit tricky for me to grasp for a while, but I've got some good friends that have helped me geta better understanding.

  1. Abstractions, when a abstraction is good and when it is bad (Sometimes I still struggle with it).
  2. Joins in Sql.
  3. Javascript prototype inheritance
  4. CSS floats and clear

This list can go on....

  1. this and specifically binding
  2. controlled components in React
  3. Proc in Ruby

RegEx... jk, I still don't get that. ;)

Angular.
The redux pattern specifically NgRx libraries.

But at some point it all clicked and it's fairly easy to implement for me now.

  1. SQL (I still use ORM's cause the syntax gives me major headaches)
  2. Perl (not a concept, but you know...)
  3. CPS.
  4. What to do with Monads in a non-Haskell world.

Recursion. In fact even now I feel like there are elements to it that confuse me. But better hold on it now after teaching it for several years. :)

When you're interviewing, you're interviewing the company just as much as they are you. This applies no matter what level you're at in your career.

CSS Media Queries...
Webpack...
req.query req.params and another req properties

definitely recursion. that messed my brain UP in college for some reason!

The difference between a cursor and a connection.

CSS selectors

  • relations hierarchy
  • specificity hierarchy

Still need to trial and error more than I'd like to admit :)

Static site generators! Didn't get it. Now I love them!

Classic DEV Post from Oct 4

What is your best advice for a junior software developer?

What is your best advice for a junior software developer?

Ben Halpern
A Canadian software developer who thinks he’s funny.
Join dev.to

Coding is hard. Community is here.