I’m sure we all have plenty of answers to this one, but sometimes we forget how far we’ve come.
Create templates to quickly answer FAQs or store snippets for re-use.
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.
This list could cross the count of a hundred.
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.
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 :)
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.
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.
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.
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!
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.
Check out videos of React Advanced meetup London from a couple of months ago. There was a guy who showed that you can do pretty much the same thing without any preprocessing now that modern browsers support most of the features in React. Things will hopefully get simpler again as older browsers fall away
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?
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 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.
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.
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.
Please share the edx link
Pretty sure this was it: edx.org/course/introduction-functi...
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
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.
I experienced the same as a CS student,lots of practice and use of recursion helped!
Here are a few of mine in no particular order and not necessarily only code related:
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.
Thanks for your explanation.
You're welcome. Hope it helps.
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."
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:
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.
And YAML and bash
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.
Design patterns - most of them.
Still trying to decode every single day ;-)
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.
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 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.
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.
Things got easier once Promises arrived and now with async/await it’s trivial.
The OO concepts like inheritance, polymorphism and especially: what is it good for.
Working out how node uses modules, how to require them in web pages an the browser ,using browserify to use modules on a client browser, for some reason this took me a long while to work out but something just clicked
interface in Go.
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.
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...
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!"
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.
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:
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.
How to work on the right part at the right time,
Problems usually lead to new questions who lead to problems that need solved.
It took me so long to realize that I can cut one problem into 100 small problems.
Which in turn would make solving the major problem a lot easier.
Also, whatever distracts you, needs to be done another time.
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.
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.
RegEx... jk, I still don't get that. ;)
I gotta go with my best friend prototypal inheritance here.
Sadly there was hardly anyone around that was able to teach me what actually happens.
Now I try to be that person to others.
This list can go on....
Coroutine was so difficult till I watched a talk from golang creator
could you share a link?
This one : youtu.be/f6kdp27TYZs
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.
Callbacks. For the life of me, I couldn't figure out how they work! I actually never understood how they worked until I learned promises, and then for some reason, it clicked for me!
Pure functions (18 months, heh)
definitely recursion. that messed my brain UP in college for some reason!
The difference between a cursor and a connection.
That a REST API call is just a glorified HTTP call.
..... And no one's said it yet. SQL joins => EF6 😫😫😭
I write hundreds of these regularly and still go cross eyed when I have to reverse outer joins with DefaultIfEmpty....
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. :)
ForEach loops. Took me two weeks of sticky notes, diagrams, and code to finally get it.
Redux, still struggling with all the boilerplate so I just keep on avoiding it.
Still need to trial and error more than I'd like to admit :)
CSS Media Queries...
req.query req.params and another req properties
Data Structures. My lecturer at University wasn't the best and explained them very poorly. I always figured I'd never understand them. Then I watched CS50 and it 'clicked'.
The redux pattern specifically NgRx libraries.
But at some point it all clicked and it's fairly easy to implement for me now.
Beans in Java.
...and monads, as usual.
I think it has to be props in React. I didn't get until someone said it just like argument to a function the name doesn't really matter. And also testing, It just didn't make any sense at first.
Static site generators! Didn't get it. Now I love them!
For me it was Redux, I took around 2 weeks to get my head around it.
Now i think it isn't that hard was i too hyped up then🤔
Women’s thinking. I never get 😁
We're a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.