I’m sure we all have plenty of answers to this one, but sometimes we forget how far we’ve come.
Code is like 10% of what is required to build software systems. The other 90% is not code.
And YAML and bash
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.
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. 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 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 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.
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.
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.
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.
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 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.
Things got easier once Promises arrived and now with async/await it’s trivial.
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.
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 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.
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
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:
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.
The OO concepts like inheritance, polymorphism and especially: what is it good for.
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.
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.
interface in Go.
DNS. Seemed like magic for the longest time.
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!
RegEx... jk, I still don't get that. ;)
This list can go on....
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.
Coroutine was so difficult till I watched a talk from golang creator
could you share a link?
This one : youtu.be/f6kdp27TYZs
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.
I gotta go with my best friend prototypal inheritance here.
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. :)
Redux, still struggling with all the boilerplate so I just keep on avoiding it.
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!
ForEach loops. Took me two weeks of sticky notes, diagrams, and code to finally get it.
The difference between a cursor and a connection.
Still need to trial and error more than I'd like to admit :)
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.
The redux pattern specifically NgRx libraries.
But at some point it all clicked and it's fairly easy to implement for me now.
Pure functions (18 months, heh)
Beans in Java.
...and monads, as usual.
definitely recursion. that messed my brain UP in college for some reason!
CSS Media Queries...
req.query req.params and another req properties
..... 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....
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🤔
Static site generators! Didn't get it. Now I love them!
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.