People are being too harsh. Deliberate practice and coming out of comfort zone is the key.
https://www.joshwcomeau.com/blog/how-to-learn-stuff-quickly/
Coding Is Hard
71–80 of 170 posts
Re: Coding Is Hard
#72I have a trick for understanding code. What I do is I look at the function, and when there is an if statement or loop, I extract this (and possible some of the surrounding code, depending on what the code does) into a named function.
Slowly, the function starts to make sense.
Another thing that works for me, is I write a unit test for a function. Personally, I’m beginning to loathe encapsulation in classes, because what would be better would to write a unit test for the extracted function, but if it is a private function - we’ll, that means you can’t easily write a unit test.
On that last bit - the only way I know of unit testing private functions is to ensure that a unit test for the public function is writtten. I then place a temporary assert into the private function code path I am exercising and run the unit test. If the test fails because of the assert, then I know I’ve tested that code path.
A dreadful way to test, at least that’s how I feel. I am increasingly looking at Haskell which is a revelation! I now know why some people aren’t happy with OOP…
Re: Coding Is Hard
#73In my experience it’s not supposed to be that hard, unless you’re working at the cutting edge or on really hard problems. But from what you’ve written it seems like you’re struggling with basic stuff. Maybe you’re still lacking fundamentals? Seems like your strategy so far has been to grind tutorials and crash courses. They will make you feel like you’re learning a lot in a short time but in the end you’ll still not…
I've been thinking about this a bit lately and I think it's actually less about fundamentals and more of an issue with process. I'm not saying that fundamentals are not essential, but we often don't have the time to learn all aspects of a complex system.
There is definitely a lot of overlap here, but I have a finite amount of time that I can put towards solving problems. I've been thrown into AI over the past 6 months and know none of the fundamentals of this space, but I can still be very productive.
My process now is to know how to pull up docs quickly (in my editor), take advantage of the LSP, use my debugger and learn the systems on the fly. I'm probably not going to take courses in AI, Data Science and other aspects of this discipline as it will only have a marginal affect on my daily activities.
My job is to understand the flow of data, so I need to focus on that and make sure my process, tooling and access to documentation are the best possible to accomplish that.
Re: Coding Is Hard
#74If you're still bad at coding after 10 years, give up. There are dozens of other things you might be great at, and every minute you're spent flogging the dead horse of becoming a coding genius, you're missing out on the opportunity to practice something you're really talented at.
That's making three assumptions: 1) That everyone has something they're really talented at, 2) that they'd want to do that thing if they found out what is is, and 3) that the time, money and effort to do so would pay off compared to having remained an average developer.
Personally, I'm not a great developer, but I was even worse at all of the other things I put a lot of time and effort into. And at the end of the day I do enjoy programming. So remaining an average developer it is.
Re: Coding Is Hard
#75> That's when I decided that I didn't need to go to college. I could just teach myself, for free, through all these online resources. > I went through all the tracks, from basic HTML (again) to JavaScript and even Ruby amd Python. And I was super proud of myself for doing just that. I then started this 2-day python crash course... > It's been 10 years since I first started learning how to code. And I still struggle w…
Yeah, I don't think this guy's problem is that coding is hard, I think he finds learning hard. At this point I think a better understanding of pedagogy would help advance his coding more than anything.
He makes it pretty clear that his frustration was due to the overall brittle nature of code (change the wrong thing and the whole system breaks), not simply the learning process.
Unfortunately brittleness is baked into virtually every computer system and development process: it's all essentially predicated on a series of finicky text files (source code, config files, etc.), none of which have any inherent, enforced relationship to each other except when seen through the lens of an IDE, compiler or interpreter. The system as a whole doesn't enforce meaningful constraints, and when it does you often have nothing more to go on than a cryptic error message.
Unfortunately that has been the nature of software development for the past 70+ years. Some developers are creative, willing, and talented enough to deal with this realm. But it's not for everybody.
Re: Coding Is Hard
#76Sounds like the author didn't ever really progress beyond the learning stage. When I was starting out, I also tried things like Codecademy and CS50, but wasn't really learning anything from those. University courses provided enough structure and incentive for me to get through all the topics. At first, I agree, it is challenging. My first language was C++ and then we switched to C. It's tough to understand what you're doing wrong at first.
Then, over time, you start to get the hang of things and can read the docs and debug your own problems decently enough.
Once you start working professionally, coding becomes the easy part. Your days will be filled with design discussions -- trying to figure out how to fit new features into your existing system that was already designed and built without those features in mind. That's the hard part. After you've figured out your new designs, coding is the easy part.
Re: Coding Is Hard
#77Earlier quoted context omitted.
I don't think writing bubble sort from scratch without mistakes is necessarily a good demonstration of someone's ability to "handle the basics" Realistically you will never need to write it yourself unless you're coding in some very specific domains It's at most a signal for whether or not they remember algorithms 101 or some leetcode exercise, but knowing that they do remember isn't really useful to me
> It's at most a signal for whether or not they remember algorithms 101 or some leetcode exercise, but knowing that they do remember isn't really useful to me For bubble sort? Do you really think anyone should have to remember an algorithm to write a quadratic time sort? All you have to do is "compare and swap" and loop through until you are done, this is way easier than Fizzbuzz. This is only hard if you have a hard…
Every technical thing you know is informed by your practice in an area. There's a lot of roles where you don't even have to think about which algorithm is implemented behind your favorite sort method. If you work in a role like that for 10 years, bubble sort becomes "which one was that again"?
Engineering is about solving valuable problems. Solving some of those problems requires obsessive control over (and selection of) specific sorting algorithms, many do not.
Edit: it's also worth bearing in mind that many of the people who discovered these algorithms are famous in part for having thought them up. If data structures and algorithms were so obvious, nobody would know who many of these people were.
Re: Coding Is Hard
#78In a 6 year period, the blog post author has only worked as a software engineer as part of a team for _one year_. That likely explains why he still finds it hard.
And never really seemed to learn how to code. I spent a bit of time in this phase of bouncing between tutorials and different learning approaches. Eventually, I found the one that worked for me. Coding is now the easy part. Designing this is the hard part.
Re: Coding Is Hard
#79Earlier quoted context omitted.
I don't think writing bubble sort from scratch without mistakes is necessarily a good demonstration of someone's ability to "handle the basics" Realistically you will never need to write it yourself unless you're coding in some very specific domains It's at most a signal for whether or not they remember algorithms 101 or some leetcode exercise, but knowing that they do remember isn't really useful to me
> It's at most a signal for whether or not they remember algorithms 101 or some leetcode exercise, but knowing that they do remember isn't really useful to me For bubble sort? Do you really think anyone should have to remember an algorithm to write a quadratic time sort? All you have to do is "compare and swap" and loop through until you are done, this is way easier than Fizzbuzz. This is only hard if you have a hard…
> All you have to do is "compare and swap" and loop through until you are done, this is way easier than Fizzbuzz.
I think you have this wrong, Fizzbuzz is actually completely trivial to the point where the problem statement is almost literally (modulo modulo) a description of the algorithm.
Bubble sort is very easy but it's not literally trivial to the same degree as Fizzbuzz!
Re: Coding Is Hard
#80Have been feeling very frustrated this past week working on something. Started wondering if I am dumb or is this actually hard. Decided to write a simple quick blog post on it -
It's hard.
The hardest part is the big gap between "I can write a function that does X" and "I can write non-trivial software that does Y".
That's where you're hitting walls - because there are a ton of them, and it is demoralising to try something that "should" be simple but end up spending numerous days and weeks fighting problems you didn't even realise existed.
Even experienced programmers have this issue. It's why a lot of us seem to think estimation is basically impossible. IMO it certainly is possible to estimate fairly accurately, but it requires a very good understanding of the problem, the technology, and the people involved.
First try to limit your problem space, only one or two new things to learn at a time. Use only mainstream ("boring") technology. Then spend a few hours every day banging your head against those problems. (Every day, not every weekend. A few hours, not 12 hours.) If you can, set goals you can achieve every week or two to keep morale up - small projects, proofs-of-concept, etc.
(I've been doing this for 20+ years, and if I'm working on stuff I'm comfortable with I'm pretty good. If I compare myself to people like John Carmack or Fabrice Bellard I discover am comparatively very very dumb indeed.)