Git: It took me a while to learn the basics, and it's still something I don't feel like an advanced user of. I tend to stick to the commands I'm most comfortable with.
Testing: This took a while for me to get the hang of, but I feel like it's turned into a strength. I love TDD and find great comfort in a well-written regression test. π
Typed languages: I think I got into the domains of untyped languages as a career because I had some mental blocks around types. These days I'm much more comfortable in either domain, but happen to still work mostly with Ruby, my fave lang.
One of the most salient features of our Tech Hiring culture is that there is so much bullshit. Everyone knows this. Each of us contributes his share. But we tend to take the situation for granted.
Why not the git CLI ? I've hardly ever used anything else (apart from some basic git tooling in VSCode to view diffs and git history), and I've always been happy with it. Whence the advice NOT to learn it?
One of the most salient features of our Tech Hiring culture is that there is so much bullshit. Everyone knows this. Each of us contributes his share. But we tend to take the situation for granted.
Maybe, but for me learning and using the CLI was/is the easiest way ... I've tried to use a GUI a couple of times, but pretty much disliked it.
The CLI (i.e. text based commands) also allows me to script, document and google what I do ... making it all much more repeatable and "discoverable" than when I have to click around in a GUI. Anyway I've always loved and preferred the command line :)
One of the most salient features of our Tech Hiring culture is that there is so much bullshit. Everyone knows this. Each of us contributes his share. But we tend to take the situation for granted.
A simple terminal UI for git commands, written in Go with the gocui library.
Sponsors
Maintenance of this project is made possible by all the contributors and sponsors. If you'd like to sponsor this project and have your avatar or company logo appear below click here. π
Elevator Pitch
Rant time: You've heard it before, git is powerful, but what good is that power when everything is so damn hard to do? Interactive rebasing requires you to edit a goddamn TODO file in your editor? Are you kidding me? To stage part of a file you need to use a command line program to step through each hunk and if a hunk can't be split down any further but contains code you don't want to stage, you have to edit an arcane patch file by hand? Are you KIDDING me?! Sometimes you get asked to stashβ¦
Ah I misunderstood that ... okay, added this to my ever-growing list of "things I should check out" - but in all likelihood I probably won't, and I'll stick to my current workflow instead, as I'm used to it and it seems adequate to me - and since I'm, well, a bit too "lazy" ;) to adopt an "entirely new way" ... tradeoffs, always tradeoffs.
(I do acknowledge that, once I've learned it, I MIGHT become marginally more productive - but I'm probably better off eliminating a few far worse sources of unproductivity among my current working habits)
One of the most salient features of our Tech Hiring culture is that there is so much bullshit. Everyone knows this. Each of us contributes his share. But we tend to take the situation for granted.
My question then would be: how much time did it really took you to learn to do git without bad mistakes all usually during many years?
For me I realized it was much much more that I would have needed to learn lazygit once I understood the git concepts.
That's why I tell people that they should feel free to not learn the details of git if they have better things to do with their life. Like I learned all vim commands when I was young and it was fun but no one should feel obligated to do the same.
"How much time did it really took you to learn to do git without bad mistakes all over the years?"
The honest answer is, not much ... I'm absolutely not saying I'm more clever than the average dev, but maybe I'm more pragmatic. I learned the basics and that was pretty simple, and the number of errors or screw-ups has been tiny over the years.
Note that I've always steered clear of "advanced" stuff like git rebase, when a "merge" does the job as well, I just keep it simple and it works for me. Less than a dozen commands that I'm using on a daily basis (I tend to define bash aliases for most of them), and on the rare occasion when it gets hairy I google it.
Not feeling like I've ever missed anything, git is simple and logical, a breath of fresh air and a huge relief when you've had to work with stuff like CVS or Subversion (or, the lord forbid, MS SourceSafe).
One of the most salient features of our Tech Hiring culture is that there is so much bullshit. Everyone knows this. Each of us contributes his share. But we tend to take the situation for granted.
One of the most salient features of our Tech Hiring culture is that there is so much bullshit. Everyone knows this. Each of us contributes his share. But we tend to take the situation for granted.
I can't really comment on that in a knowledgeable and objective way, but the ones I know and have worked with don't really seem to have the problem, AFAIK ... could be wrong tho :)
One of the most salient features of our Tech Hiring culture is that there is so much bullshit. Everyone knows this. Each of us contributes his share. But we tend to take the situation for granted.
The easiest way to know is to look at how much traffic super basic git questions that shouldn't be an issue get on stackoverflow. That's the equivalent of a code smell but for a product
Look, what I know has been criticized a lot is that some of the commands aren't intuitive - I mean, when I want to discard my local changes, why on earth do I need to type git reset HEAD . ?
But personally that has never bothered me, it was part of the learning curve, and not even the most complex part by far. In some cases I've even tucked it away behind a bash alias.
I wanna discard my local changes? I press Control-R in my bash shell and type "reset" and bada bing bada boom there's my git reset HEAD . and I press ENTER, done.
Does-not-bother-me-at-all.
Oh and more recent versions of the git client have rationalized a few commands by introducing more logically named new variants.
The thing I appreciate about git is the sheer genius of how it's designed and how it works, the commands are just that, it's never bothered me.
Personally I'm just the type of guy who wants to work with "the thing" itself - 'bare metal' if you like. I don't want wrappers or GUIs or whatever stuff needs to be put on top of it, and being dependent on that.
One of the most salient features of our Tech Hiring culture is that there is so much bullshit. Everyone knows this. Each of us contributes his share. But we tend to take the situation for granted.
When I get lost in my programming of a library, for example, because there are so many ways to implement its features and so many plans for features, I then start to ask myself: how I can simplify things or get something useful implemented more quickly? Then I act like the user of the library by writing unit tests about how I want to interact with it to access its features, before they are done. This in turn forces me to tie down the library by programming it to match the desired usage, and reduces frustration by fast-tracking a workable solution in a pragmatic manner. It's specing out the solution in parallel with implementing it, instead of having it speced out fully beforehand and following up with implementation only afterwards.
TDD for the sake of itself isn't necessarily useful, until you find a reason that it helps you in your line of programming. Not all lines of development need TDD like user interfaces that are more driven by design specs and implemented using an event system, as one example.
One of the most salient features of our Tech Hiring culture is that there is so much bullshit. Everyone knows this. Each of us contributes his share. But we tend to take the situation for granted.
I think testing/TDD is one of the topics people struggle with the most ... not to understand the theory, but to practice what "we" preach, and to stick with it ... it's THE first thing people (including myself) tend to drop, or get sloppy with, when push comes to shove.
Iβm currently working on two open-source projects: Fugu (https://fugu.lol), a privacy-friendly product analytics software, and Mapzy (https://mapzy.io), a store finder.
Same with testing. Used to hate it, now can't sleep well at night if I deploy untested code. Also, the green check marks have something oddly satisfying. Have you ever used RBS or Sorbet with Ruby?
I believe to test out a concepts, we do clone a repo and test it out if it worksout push it or bail out. Critical scenarios is when you do force push on remote branch and working with remote repo.
I used to always hate CSS. I just couldn't understand any of it. I said I want nothing to do with it and stayed learning backend development with C# and ASP.NET. Fast forward a couple years and now I'm labeling myself as a Front-End Developer. Ive always loved making things look good but css just didn't click with me for a while. Not sure what changed but suddenly I understand a good amount of it. Still haven't touched grid but hey flex is working just fine so far.
I also hated css early on. I couldn't make anything look good, I didn't know what half of the properties did or what their values were. Over time (largely thanks to type-hinting) I slowly started memorizing what does what, what goes where, etc.
I think I just didn't like it because of the learning curve. As someone who just wanted something to work, overcoming that curve was always a secondary goal, therefor CSS was more of an obstacle than a curiosity. It feels really natural to me now. I wouldn't say I love it but I don't hate it anymore. π
It's funny, but it took me the longest time to grasp the concept of a function parameter. I didn't understand what they were or how they altered what the function would output.
I finally got it when I found this simple example in JS that illustrated it well.
function feetToInches(feet) {
return feet * 12;
}
I feel so dumb now, but I guess it kind of illustrates how far I've come! π
I still find async tricky. I was puttering along fine using Rust's flavor of it until I needed to use tokio::select! - even though I understand it now and can use it effectively in solutions, the code is just not intuitive for me. It takes me a while to think through, and often some napkin-scribbling.
One of the most salient features of our Tech Hiring culture is that there is so much bullshit. Everyone knows this. Each of us contributes his share. But we tend to take the situation for granted.
I will say testing things properly is the biggest one.
And also probably the biggest step from programmeur amateur to becoming a professional.
I haven't figured out testing fully to be honest, but I'm definitely better than I used to be.
Ugh, I was really dumb back then. In my first month as a programmer:
What the world does return mean?? What is it supposed to do?
Why do I have to create a class just to access a method (I started out with Java)? Does OOP stand for obscene obscure programming?
What's OOP and why use it??
After a while in web dev, I had a hard time understanding:
Why every time I access the DOM it just says [object Object]? lol
CSS:
It's really frustrating because I didn't know how properties work with each other, and thus the CSS "didn't do anything"
Later as a fullstack dev:
NodeJS was confusing to learn
Later learning JS frameworks:
Cannot use import outside a module ... invalid module path
What in the world is webpack? Why use babel?
After learning about security and authentication:
How in the world do I keep hackers out??
Learning Rust:
Ownership is sooooo annoying and confusing
In my career now as a ML dev:
What's a neural network?
How does ML even work??
I'm glad to be over all that now, although I'm sure something new will come up sooner or later. I guess it makes me understand those people on SO who have literally no idea what they're doing, because many years ago I was one of them.
I was merely an 'user' for long, until I had to debug a patched version ot a custom library... well after that I made a mental folder of things you learn to avoid doing the same mistake in the future.
Starting out, the concept of "frameworks" and "libraries" confused me a lot. Not just the distinction between the two, but how they actually work, and the patterns they guide you into. For example, when I first heard about them, Jquery and Angular looked completely foreign to vanilla JS. They might as well have been separate languages to me.
Regex was a complete mystery to me for years. It still sort of is, but I can at least parse it mentally and create some basic ones. I still have to use regexr.com/ to test them though, lol
Linux was pretty tricky to learn. I was pretty much obligated to learn it because I was managing a php server. Docker actually made this process a lot easier. It's not the shell that gave me trouble, rather it was the nagging feeling that I wasn't fully understanding something, not getting the bigger picture. All those weird folders, config files, etc...
Learning React, Redux, JSS, etc for the first time was pretty rough. There were a lot of new paradigms thrown at me all at once. Took me a few months but I got comfortable eventually.
Docker and Kubernetes gave me a lot of trouble too. Docker was the easier of the two to grasp, but trying to combine them and get my own cluster set up was a lot of work. I bet the learning material and guides are a lot better these days. Kubernetes in particular was rough, because there were times where I didn't even know what to google. "If you know what you're looking for, inquiry is unneccesary. But if you don't know, how do you inqire?" π
A couple of things that are still giving me trouble: Microservices and event sourcing. Sort of in the same boat with those!
One of the most salient features of our Tech Hiring culture is that there is so much bullshit. Everyone knows this. Each of us contributes his share. But we tend to take the situation for granted.
because you don't enjoy runtime errors like object null doesn't have property undefined?
because you like writing unit tests but it's even better if the compiler automatically writes tons of them for you?
That's good, but for front-end it is more edge cases in customer facing in terms of design and layout and it requires the unit test cases along with accessibility cases however to be written.
One of the most salient features of our Tech Hiring culture is that there is so much bullshit. Everyone knows this. Each of us contributes his share. But we tend to take the situation for granted.
How do you explain then that people writing other kind of front ends use languages with static types?
When you write apps for Windows, Mac, iPhone, Android,... you use languages with static types like Java, Swift, Kotlin, C#, ...
Are web frontend essentially different or is it rather that JavaScript who happened to not have static types has completely dominated the web ecosystem until recently?
Yes, as i see the startups early adopters mainly focus on either a loosely typed language like javascript and make it responsive make it a PWA or use a cross platform like RN to make easily adaptable to multiple platforms.
In backend it is required to keep the consistency of data that is being sent as a response. Keeping that consistency can be quiet hard in terms of complicated pages for styling and other props which apart from the data we receive from back-end.
PS : it is a personal opinion.
I was very familiar with using JS on a website, so I thought React would be an easy transition. Nope. What stung me was:
React is compiled locally. If you're not used to that and how it works then its a pain to get started. When I learnt JQuery ages ago I started with something very, very small eg $(".mydiv).text("hello world");. This worked and I was able to build upon that and create more and more complex DOM manipulations from there. With React you can't just start with that one line.
React has a lot of dependancies that don't make sense at first. Node, npm, React-DOM. In most beginner React tutorials there is little to no explanation of these. Initially I thought I would have to learn Node.js in and out before I learnt React - and that's a totally different kettle of fish.
React tutorials are inconsistant. Some are very old, some predate React Hooks, some use TypeScript, some don't use Create React App, some presume prior knowledge of things like Redux.
It's not intuitive to actually deploy a React component or app up on a live site. Most React tutorials end at the point where you've completed the app on your local machine... cool, but now what? How do I actually get it on my site?
For me it was DNS configuration for domains. I was wise to take some time to learn how it works in order to be able to debug it. Now ten years later I'm still explaining it to my colleagues :)
PKCE flow and all frontend authorization. The auth part, I get it, the authorization part part, when it start implying refresh tokens is still a bit abstract to me.
Overall identity management in SPA or even Next-like app isn't that easy, is different on Netlifly, Firebase, platform.io etc.
I have a heavy Frontend background it felt easy to me and I was afraid of backend, then I moved into backend, boyyyy was I wrong, backend web development is 1000x easier than frontend, no idea why the pay is better. Then I became a solid fullstack. Then later manager. So back to the question dynamic programming challenges are insane I don't get it and it hurts my brain, also binary operations. The most difficult thing I came across my career so far was in gaming client side predictions and server reconcilliation, also everything with geometry I struggle, like calculating the sum or two angles etc. seems like learning formulas by heart but understanding is tricky. Yeah the more you know the more you know you don't know and impostor syndrome grows bigger.
I disliked JavaScript greatly for many years. I just didn't get how to use it, coming from mostly object-oriented languages (Java, C++, even PHP 5 and above). Then, one day, a switch flipped and suddenly I thought it was actually pretty fun! I think it took just embracing a new mental model and embracing/getting over some of its quirks.
Oh that's easy. Rust. More precisely - its borrow checker.
I have read about it many times and I'm pretty sure I understand the theory behind it pretty well. Meanwhile, in my several attempts to learn Rust, I was never able to transfer this theoretical knowledge to practice and always ended up metaphorically throwing my keyboard out of the window.
Initially coming from Angular, React took me awhile to grok. Something about the one-way data flow, and using props to pass data just took longer than I would have expected to click. Now React is my favorite FE framework and I find it very easy to use, but yeah it took awhile at first.
Containers and Kubernetes, for my first internship I was thrown into the cloud computing world and I had no prior knowledge of it at all. It took a week to figure out what exactly a container was and why containerized apps are crucial to today's CI/CD.
And kubernetes..... don't get me started with that. Something I'm still trying to figure out until this day xD
Software Architect and Security Officer with 20 years of experience, Web Dev has shifted from my main profession to a hobby as I rarely get to code by now and just love the craft. Check out my channel
Some concepts of Functional Programming like pure functions and monads. To this day I cannot reconcile/fully understand the idea of functions without side-effects and basically no external state that does not depend on the function's arguments with what I know about programming. I simply could not find a consistent approach on how to build the applications I code on a daily basis using pure functional programming and I would trade my right arm for a look at a codebase of a buisness application that fully embraces FP.
I struggle with Rx specificity RxJava. I know enough for the pubSub but thatβs about it. I know it can do so much more but that whole concept really donβt not stick in my brain.
Recently stepped into the React and React Native world. As a person who built their career on OOP, the whole functional programming is like the Wild Wild West and hard to learn and follow.
Everything revolving around functional programming, monads and all, were hard for me to grasp. On top of having to learn this concept, I had to learn it in a language I didn't know, Scala. Since then I've had a lot of fun with those concepts and the language!
Head of Software @Holaluz, trying to create a better future for everyone. Looking to share ideas, knowledge & code. Before: @Thoughtworks @ClimatePartner
developer ego as carreer goew by and experiences diferent things grows an idea of how things have to be (ex. Clean code) and makes growth, value delivery, etc more complex and slow. its q phase but not everyone goes over it, to improve collaboration and contine growing without the safetynet of "being correct".
I've had some trouble with OOP... functional concepts are so much easier to grasp. I'm a lot more comfortable with it now, but took me some good 5 years :|
Still have trouble understanding DDD, it's too complex for me
Anything involving equations in uni. Certain things clicked quickly, but at a certain point, my eyes would just glaze over.
AVL trees and other ways of balancing binary trees. i just couldn't get the transformations into my head
shell scripting (I know enough to be productive, but many things still confuse me)
SQL queries. I picked up the basics quickly, but I'm still finding myself tripping up about ways that different parts of a query can interact, especially when dealing with joins, aggregations and grouping.
For me, it's definitely has to be the module bundler. Firstly, I tried to learn webpack but gave up after a week after seeing the sheer volume of documentation. Currently I'm learning Rollup. But either way, I feel like crying while going through the docs of a module bundler because there are so many options, configuration and plugins. It's really overwhelming for me.
Applying concepts using technology is tough, in general, no matter the programming language or technologies. For example, algorithms and their data structures to mimic the real world or to create optimizations, for example exploding simple arrays into trees and scanning them really increases complexity for gain.
It requires constant learning and adaptation. The nice thing is when you've implemented a concept in programming and rolled it up well into a library such that it's reusable, and hopefully you can be done with it for a while, moving on to the next thing.
Oh, and Single Sign On (SSO) technology. Conceptually OK. Implementation-wise, always frustrating because you're tying together disparate things and there isn't really a turn-key solution that's easy. I'll be estatic if anybody proves to me that last statement is wrong!
Sockets (as in WebSockets), not coding them, that was the easy part.
But actually understanding why and how they work with multiple sessions and clients.
Data structures and algorithms are really hard to understand, especially for beginners. My advice is to just stick with it and you'll learn it eventually!
In computer science, an abstract syntax tree (AST), or just syntax tree, is a tree representation of the abstract syntactic structure of text written in a formal language. Each node of the tree denotes a construct occurring in the text.
I'll go first with a few:
As a lazy programmer, I don't fear to give the advice we are not supposed to give:
More details here:
Can beginners make a simple but meaningful contribution? Some unconventional advice #hacktoberfest
Jean-Michel Fayard π«π·π©πͺπ¬π§πͺπΈπ¨π΄ γ» Oct 1 γ» 7 min read
Why not the git CLI ? I've hardly ever used anything else (apart from some basic git tooling in VSCode to view diffs and git history), and I've always been happy with it. Whence the advice NOT to learn it?
Laziness, the reason is Laziness.
I prefer to use tools that
Try to read
man git-logand you will understand what I meanMaybe, but for me learning and using the CLI was/is the easiest way ... I've tried to use a GUI a couple of times, but pretty much disliked it.
The CLI (i.e. text based commands) also allows me to script, document and google what I do ... making it all much more repeatable and "discoverable" than when I have to click around in a GUI. Anyway I've always loved and preferred the command line :)
Lazygit is not a gui, it works in the terminal, give it a try
simple terminal UI for git commands
A simple terminal UI for git commands, written in Go with the gocui library.
Sponsors
Maintenance of this project is made possible by all the contributors and sponsors. If you'd like to sponsor this project and have your avatar or company logo appear below click here.π
Elevator Pitch
Rant time: You've heard it before, git is powerful, but what good is that power when everything is so damn hard to do? Interactive rebasing requires you to edit a goddamn TODO file in your editor? Are you kidding me? To stage part of a file you need to use a command line program to step through each hunk and if a hunk can't be split down any further but contains code you don't want to stage, you have to edit an arcane patch file by hand? Are you KIDDING me?! Sometimes you get asked to stashβ¦
Ah I misunderstood that ... okay, added this to my ever-growing list of "things I should check out" - but in all likelihood I probably won't, and I'll stick to my current workflow instead, as I'm used to it and it seems adequate to me - and since I'm, well, a bit too "lazy" ;) to adopt an "entirely new way" ... tradeoffs, always tradeoffs.
(I do acknowledge that, once I've learned it, I MIGHT become marginally more productive - but I'm probably better off eliminating a few far worse sources of unproductivity among my current working habits)
My question then would be: how much time did it really took you to learn to do git without bad mistakes all usually during many years?
For me I realized it was much much more that I would have needed to learn
lazygitonce I understood the git concepts.That's why I tell people that they should feel free to not learn the details of
gitif they have better things to do with their life. Like I learned allvimcommands when I was young and it was fun but no one should feel obligated to do the same."How much time did it really took you to learn to do git without bad mistakes all over the years?"
The honest answer is, not much ... I'm absolutely not saying I'm more clever than the average dev, but maybe I'm more pragmatic. I learned the basics and that was pretty simple, and the number of errors or screw-ups has been tiny over the years.
Note that I've always steered clear of "advanced" stuff like git rebase, when a "merge" does the job as well, I just keep it simple and it works for me. Less than a dozen commands that I'm using on a daily basis (I tend to define bash aliases for most of them), and on the rare occasion when it gets hairy I google it.
Not feeling like I've ever missed anything, git is simple and logical, a breath of fresh air and a huge relief when you've had to work with stuff like CVS or Subversion (or, the lord forbid, MS SourceSafe).
Then if isn't broken don't fix it.
That's what I mean :)
Yes, and what I mean is that I think it's broken* for many more developers than you probably think.
(*) meaning here that it technically works but it requires way much efforts than necessary
I can't really comment on that in a knowledgeable and objective way, but the ones I know and have worked with don't really seem to have the problem, AFAIK ... could be wrong tho :)
The easiest way to know is to look at how much traffic super basic git questions that shouldn't be an issue get on stackoverflow. That's the equivalent of a code smell but for a product
stackoverflow.com/questions/tagged...
Look, what I know has been criticized a lot is that some of the commands aren't intuitive - I mean, when I want to discard my local changes, why on earth do I need to type
git reset HEAD .?But personally that has never bothered me, it was part of the learning curve, and not even the most complex part by far. In some cases I've even tucked it away behind a bash alias.
I wanna discard my local changes? I press Control-R in my bash shell and type "reset" and bada bing bada boom there's my
git reset HEAD .and I press ENTER, done.Does-not-bother-me-at-all.
Oh and more recent versions of the git client have rationalized a few commands by introducing more logically named new variants.
The thing I appreciate about git is the sheer genius of how it's designed and how it works, the commands are just that, it's never bothered me.
Personally I'm just the type of guy who wants to work with "the thing" itself - 'bare metal' if you like. I don't want wrappers or GUIs or whatever stuff needs to be put on top of it, and being dependent on that.
I should do an article about this.
Do you have any suggestions for how to learn TDD? I can't seem to grasp it.
When I get lost in my programming of a library, for example, because there are so many ways to implement its features and so many plans for features, I then start to ask myself: how I can simplify things or get something useful implemented more quickly? Then I act like the user of the library by writing unit tests about how I want to interact with it to access its features, before they are done. This in turn forces me to tie down the library by programming it to match the desired usage, and reduces frustration by fast-tracking a workable solution in a pragmatic manner. It's specing out the solution in parallel with implementing it, instead of having it speced out fully beforehand and following up with implementation only afterwards.
TDD for the sake of itself isn't necessarily useful, until you find a reason that it helps you in your line of programming. Not all lines of development need TDD like user interfaces that are more driven by design specs and implemented using an event system, as one example.
The most awesome way to learn TDD is to do a pair-programming/mob-programming session where you strictly divide the responsabilities
I should add that I think that TDD should be one strategy that you have in your toolbox and not a dogma.
I think testing/TDD is one of the topics people struggle with the most ... not to understand the theory, but to practice what "we" preach, and to stick with it ... it's THE first thing people (including myself) tend to drop, or get sloppy with, when push comes to shove.
Lol I'm the opposite. Untyped languages drive me nuts.
I feel the same way about git
I started my programming with Java, so typing wasn't a problem π€£
Same with testing. Used to hate it, now can't sleep well at night if I deploy untested code. Also, the green check marks have something oddly satisfying. Have you ever used RBS or Sorbet with Ruby?
Thank for your writing. Wonderful
Javascript. . .still javascript. What I'd give to understand it!
I mean, JavaScript is just lots of concepts. What are you having trouble understanding?
I believe to test out a concepts, we do clone a repo and test it out if it worksout push it or bail out. Critical scenarios is when you do force push on remote branch and working with remote repo.
I used to always hate CSS. I just couldn't understand any of it. I said I want nothing to do with it and stayed learning backend development with C# and ASP.NET. Fast forward a couple years and now I'm labeling myself as a Front-End Developer. Ive always loved making things look good but css just didn't click with me for a while. Not sure what changed but suddenly I understand a good amount of it. Still haven't touched grid but hey flex is working just fine so far.
I also hated css early on. I couldn't make anything look good, I didn't know what half of the properties did or what their values were. Over time (largely thanks to type-hinting) I slowly started memorizing what does what, what goes where, etc.
I think I just didn't like it because of the learning curve. As someone who just wanted something to work, overcoming that curve was always a secondary goal, therefor CSS was more of an obstacle than a curiosity. It feels really natural to me now. I wouldn't say I love it but I don't hate it anymore. π
Good one ... yes, CSS is friggin' hard especially layout.
It's funny, but it took me the longest time to grasp the concept of a function parameter. I didn't understand what they were or how they altered what the function would output.
I finally got it when I found this simple example in JS that illustrated it well.
I feel so dumb now, but I guess it kind of illustrates how far I've come! π
if the function was inches to feet wouldn't it divide by 12?
EDIT:(not that it really matters and not trying to be that guy, just tripped me up.)
Thanks, nice catch! Changed it :)
I still find async tricky. I was puttering along fine using Rust's flavor of it until I needed to use
tokio::select!- even though I understand it now and can use it effectively in solutions, the code is just not intuitive for me. It takes me a while to think through, and often some napkin-scribbling.try generators more fun π
Docker
Oh, good one!
Have you come around on it yet?
Not yet, but trying. Let me know any resources that can help.
For me its Regex, I still don't get it right.
I will say testing things properly is the biggest one.
And also probably the biggest step from programmeur amateur to becoming a professional.
I haven't figured out testing fully to be honest, but I'm definitely better than I used to be.
Ugh, I was really dumb back then. In my first month as a programmer:
returnmean?? What is it supposed to do?After a while in web dev, I had a hard time understanding:
[object Object]? lolLater as a fullstack dev:
Later learning JS frameworks:
Cannot use import outside a module...invalid module pathAfter learning about security and authentication:
Learning Rust:
In my career now as a ML dev:
I'm glad to be over all that now, although I'm sure something new will come up sooner or later. I guess it makes me understand those people on SO who have literally no idea what they're doing, because many years ago I was one of them.
I'd say SOAP.
I was merely an 'user' for long, until I had to debug a patched version ot a custom library... well after that I made a mental folder of things you learn to avoid doing the same mistake in the future.
Starting out, the concept of "frameworks" and "libraries" confused me a lot. Not just the distinction between the two, but how they actually work, and the patterns they guide you into. For example, when I first heard about them, Jquery and Angular looked completely foreign to vanilla JS. They might as well have been separate languages to me.
Regex was a complete mystery to me for years. It still sort of is, but I can at least parse it mentally and create some basic ones. I still have to use regexr.com/ to test them though, lol
Linux was pretty tricky to learn. I was pretty much obligated to learn it because I was managing a php server. Docker actually made this process a lot easier. It's not the shell that gave me trouble, rather it was the nagging feeling that I wasn't fully understanding something, not getting the bigger picture. All those weird folders, config files, etc...
Learning React, Redux, JSS, etc for the first time was pretty rough. There were a lot of new paradigms thrown at me all at once. Took me a few months but I got comfortable eventually.
Docker and Kubernetes gave me a lot of trouble too. Docker was the easier of the two to grasp, but trying to combine them and get my own cluster set up was a lot of work. I bet the learning material and guides are a lot better these days. Kubernetes in particular was rough, because there were times where I didn't even know what to google. "If you know what you're looking for, inquiry is unneccesary. But if you don't know, how do you inqire?" π
A couple of things that are still giving me trouble: Microservices and event sourcing. Sort of in the same boat with those!
When Typescript started "taking off", I was like... wut?
combining typescript with backend is fine, but with front-end why? why? why? π
because you don't enjoy runtime errors like
object null doesn't have property undefined?because you like writing unit tests but it's even better if the compiler automatically writes tons of them for you?
That's good, but for front-end it is more edge cases in customer facing in terms of design and layout and it requires the unit test cases along with accessibility cases however to be written.
How do you explain then that people writing other kind of front ends use languages with static types?
When you write apps for Windows, Mac, iPhone, Android,... you use languages with static types like Java, Swift, Kotlin, C#, ...
Are web frontend essentially different or is it rather that JavaScript who happened to not have static types has completely dominated the web ecosystem until recently?
Yes, as i see the startups early adopters mainly focus on either a loosely typed language like javascript and make it responsive make it a PWA or use a cross platform like RN to make easily adaptable to multiple platforms.
What's the difference? Why do you think it makes sense on backend and does not on frontend?
In backend it is required to keep the consistency of data that is being sent as a response. Keeping that consistency can be quiet hard in terms of complicated pages for styling and other props which apart from the data we receive from back-end.
PS : it is a personal opinion.
Ok, fail point. But modern frontends usually don't just include styling and layouts, but a significant part is some business logic as well.
Yeah, i agree with that.
React for me.
I was very familiar with using JS on a website, so I thought React would be an easy transition. Nope. What stung me was:
$(".mydiv).text("hello world");. This worked and I was able to build upon that and create more and more complex DOM manipulations from there. With React you can't just start with that one line.For me it was DNS configuration for domains. I was wise to take some time to learn how it works in order to be able to debug it. Now ten years later I'm still explaining it to my colleagues :)
PKCE flow and all frontend authorization. The auth part, I get it, the authorization part part, when it start implying refresh tokens is still a bit abstract to me.
Overall identity management in SPA or even Next-like app isn't that easy, is different on Netlifly, Firebase, platform.io etc.
Currently trying to find my feet within the AWS ecosystem - it's huge, and oftentimes pretty confusing ... other more or less "hard" subjects:
I have a heavy Frontend background it felt easy to me and I was afraid of backend, then I moved into backend, boyyyy was I wrong, backend web development is 1000x easier than frontend, no idea why the pay is better. Then I became a solid fullstack. Then later manager. So back to the question dynamic programming challenges are insane I don't get it and it hurts my brain, also binary operations. The most difficult thing I came across my career so far was in gaming client side predictions and server reconcilliation, also everything with geometry I struggle, like calculating the sum or two angles etc. seems like learning formulas by heart but understanding is tricky. Yeah the more you know the more you know you don't know and impostor syndrome grows bigger.
I disliked JavaScript greatly for many years. I just didn't get how to use it, coming from mostly object-oriented languages (Java, C++, even PHP 5 and above). Then, one day, a switch flipped and suddenly I thought it was actually pretty fun! I think it took just embracing a new mental model and embracing/getting over some of its quirks.
Oh that's easy. Rust. More precisely - its borrow checker.
I have read about it many times and I'm pretty sure I understand the theory behind it pretty well. Meanwhile, in my several attempts to learn Rust, I was never able to transfer this theoretical knowledge to practice and always ended up metaphorically throwing my keyboard out of the window.
Initially coming from Angular, React took me awhile to grok. Something about the one-way data flow, and using props to pass data just took longer than I would have expected to click. Now React is my favorite FE framework and I find it very easy to use, but yeah it took awhile at first.
Reactive programming made properly: RxJS or/and Reactor.
Other:
Containers and Kubernetes, for my first internship I was thrown into the cloud computing world and I had no prior knowledge of it at all. It took a week to figure out what exactly a container was and why containerized apps are crucial to today's CI/CD.
And kubernetes..... don't get me started with that. Something I'm still trying to figure out until this day xD
Some concepts of Functional Programming like pure functions and monads. To this day I cannot reconcile/fully understand the idea of functions without side-effects and basically no external state that does not depend on the function's arguments with what I know about programming. I simply could not find a consistent approach on how to build the applications I code on a daily basis using pure functional programming and I would trade my right arm for a look at a codebase of a buisness application that fully embraces FP.
I struggle with Rx specificity RxJava. I know enough for the pubSub but thatβs about it. I know it can do so much more but that whole concept really donβt not stick in my brain.
Recently stepped into the React and React Native world. As a person who built their career on OOP, the whole functional programming is like the Wild Wild West and hard to learn and follow.
Everything revolving around functional programming, monads and all, were hard for me to grasp. On top of having to learn this concept, I had to learn it in a language I didn't know, Scala. Since then I've had a lot of fun with those concepts and the language!
developer ego as carreer goew by and experiences diferent things grows an idea of how things have to be (ex. Clean code) and makes growth, value delivery, etc more complex and slow. its q phase but not everyone goes over it, to improve collaboration and contine growing without the safetynet of "being correct".
I've had some trouble with OOP... functional concepts are so much easier to grasp. I'm a lot more comfortable with it now, but took me some good 5 years :|
Still have trouble understanding DDD, it's too complex for me
For me, it's definitely has to be the module bundler. Firstly, I tried to learn webpack but gave up after a week after seeing the sheer volume of documentation. Currently I'm learning Rollup. But either way, I feel like crying while going through the docs of a module bundler because there are so many options, configuration and plugins. It's really overwhelming for me.
Kubernetes,.... the name alone sends chills down my spine
As a kid starting programming in basic it took me ages to understand why this didn't work
if data = βcat' or 'dog' thenYou should have seen the illumination when i got it!
Applying concepts using technology is tough, in general, no matter the programming language or technologies. For example, algorithms and their data structures to mimic the real world or to create optimizations, for example exploding simple arrays into trees and scanning them really increases complexity for gain.
It requires constant learning and adaptation. The nice thing is when you've implemented a concept in programming and rolled it up well into a library such that it's reusable, and hopefully you can be done with it for a while, moving on to the next thing.
Oh, and Single Sign On (SSO) technology. Conceptually OK. Implementation-wise, always frustrating because you're tying together disparate things and there isn't really a turn-key solution that's easy. I'll be estatic if anybody proves to me that last statement is wrong!
Sockets (as in WebSockets), not coding them, that was the easy part.
But actually understanding why and how they work with multiple sessions and clients.
Cucumber. Probably because I'm not the fan of the syntax.
TDD. I still struggle a lot with it. I failed many interviews because they asked me to create applications using TDD and I didn't know where to start.
SQL Joins: I understand them theoretically, but I don't know how to do them practically.
Aws.
OAUTH
I've read and even studied several times. My mind just go blank for some reason.
Redux - reducers, dispatch, thunks π€―
Data structures and algorithms are really hard to understand, especially for beginners. My advice is to just stick with it and you'll learn it eventually!
Ownership model in Rust
Regular expression π€£
What even is this?
In computer science, an abstract syntax tree (AST), or just syntax tree, is a tree representation of the abstract syntactic structure of text written in a formal language. Each node of the tree denotes a construct occurring in the text.
For me, it was Redux, and it was because I didn't understand immutability at the time and didn't have dev tools which made it difficult to visualize.
Kubernetes. In fact, I am still on it.
And Flex is all you need π