Have 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 -
Yo OP cool you commented here! At the very least I think your website is pretty good - and I like the prism logo. Being able to write up a post and have it get international eyes (via HN) is more than many people ever try to accomplish.
I often think of coding like making music: you don't need to be an expert at an instrument to make nice music - so much to the point where "making music" and "playing an instrument" can be considered very different things.
Frustration is something I can feel as well when I am stuck. It is not a productive emotional state. It means to feel stuck, and maybe I was even stuck before I began.
Sometimes I just need to take a step back and look at it the next day. Sometimes it helps, sometimes not. Sometimes taking a walk helps, or cycling, or taking a shower.
But when I feel frustrated, I know it's an uphill battle that will be mostly unproductive, mostly productive in getting a look at it, some reconnaisance.
I've come to feel that while I love reading HN, it's quite toxic as well. It's like the instagram of coding - every person is so smart, so authoritative, such breadth and depth of knowledge they are all making $300k/yr+ and profess how easy it is to find such a job. It can be really demoralising and even depressing for people who are struggling to be exposed to such potent concentration of things like that.
So it's great to hear someone being vulnerable and owning up to struggles.
I would say, my approach when I hit the types of feelings you express is always to drop down a layer to fundamentals. If X is hard, why is that? It probably means your knowledge isn't sound at some layer below the one you are working at. It sounds like a huge amount of your learning approach has been based on online learning and the issue with these is that they are usually very shallow. They teach you a direct skill but nothing underneath it. So drop down a level and just take time, to properly fill in those gaps. Steadily unravel what is going on one level down. Don't keep battering at the level above constantly getting frustrated. Build your knowledge at the level below. Learn the joy of patiently establishing a sound basis and a complete knowledge of the underlying principles on which something works.
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.)
You are not dumb. It is normal to feel frustrated, when figuring out, step by step, how something works, and what to do. It is like labyrinth. Having enough breaks, taking a walk when needed, having enough coping skills or adding more of them, having patience to keep notes of what is current position in that labyrinth. If some way does not work, try some other way. Getting something working is victory feeling.
It is always about the basics. Many programming languages change syntax often. Some dependencies change.
For example, when writing some for database export:
1) There was no working code examples at documentation
2) Google etc searches had old info, did not work
3) I did not find from source code how it did work
4) ChatGPT, Bing AI etc examples did not work
5) So I tried with trial and error, what is correct syntax, character by character
For some error messages, sometimes Google search shows somebody having same problem, or even a fix. But if not, it's about reading source code of the software.
But this works only when code is available, like in Open Source.
If something is binary executeable, then there is need to decompile, read assembler, deobfuscate, etc. That means even more time required, I have not gone there yet. That is why I use and develop FOSS, when it is possible to more easily fix something, when it is broken.
> It's just refactoring the codebase a bit, reorganizing it, making it cleaner and more structured, and it's supposed to be easy.
Why is that supposed to be easy? When things start to sprawl, and more and more tech debt gets left behind (i.e., in the codebase) then complexity increases, as do the risk of balloon grabs (i.e., grab in one place and something pops out somewhere else).
Of course you're tired and demoralized, every change has to be second or third guessed.
I believe that stuck feeling, the helpless head banging feeling, is your brain forming new connections and breaking old ones. In other words, learning. That’s where the experience points are. Accept the feeling of being dumb and the reality of being smart, mixed together, and you’re advancing for real.
The way I think about it is that the struggle is essential if you want to push yourself to learn new things. Learning is a messy process and it's rarely a linjar affair.
Once I took over a project that needed some SQL updates. Oh, and there was one issue in the issue tracker that needed looking at. How naive I was.
If I knew beforehand what it all would entail, I would never have taken over that project. Therefore I do feel lucky that I was so naive, it brought me many good things. Nowadays I easily see the scope of taking over a project and I hesitate a lot more doing that.
> 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 with it, a lot.
> I go back to the basics, again and again and again.
There shouldn't be this much struggle after 10 years. I wonder if your issue is you were never intentional in your learning and practice and just bounced from topic to topic. You say you're the "idea guy." There's a saying that it's better to finish something than to start something.
I'll admit to being a little shaky on the types of programming needed in enterprise projects at the beginning (less of a focus on maintainable code, but probably more of a focus on what the machine is actually doing), as I only knew exactly what I needed to hack together whatever my hobby project was, but after 5 years of a career and working in 9 different languages it's been pretty easy.
I mean, occasionally there's something that takes a bit to work into my brain's L1 cache, like the precise semantics of prototypical inheritance in javascript, or call by name in scala, but for the most part, everything's been extremely transferable. A hashmap is still a hashmap in any language.
I taught myself to code in high school and then did the 5 year CS degree at university. School taught me a lot of interesting stuff that I probably would've never picked up on my own, and gave me a much more grounded perspective on the entire field. But very little that was directly relevant for enteprise programming (which I've been doing professionally for over a decade by now).
I have been writing JavaScript since JS has existed, and the One Weird Trick I learned to working with JS’s OO system is to use it as little as possible. Don’t get me wrong, objects are wonderful, but you don’t need JS’s barking insane semantics around “this” when static closures work fantastically. It’s not even the prototype model that I’m talking about, it’s having to do things like foo.bar.bind(foo) or having to know that an event handler will re-bind “this” and so on. The Vue and React communities have caught on to this, and writing code for those is so much more pleasant now that there are fewer land mines like that to step on.
As I was reading through it, it sounded like he didn't have an actual idea of what to build. I'd expect an 'idea guy' would learn just enough to get going and start building whatever the idea was, and use the project as a means to guide him to whatever he needed to learn next. I find this to be the most effective way to learn, as all the learning gets applied right away, outside of the context of a very controlled problem given by the teacher.
The idea that he was jumping from course to course, across a bunch of different languages made it seem like he valued having the identity as someone who built something, but didn't know what to build. The gap year suggests that as well. I've been in the same boat and the only thing that moved me forward was having a project to work on that I cared about. In my case, I had a normal job with some down time, and learned to code to make that job easier... no courses, just reading the docs and trying to solve the problem right in front of me. I actually had programming classes in college before this, and while I passed without issue, I never felt I learned how to code or built by own stuff, and years passed between that course and when I felt I actually learned. Having a problem, breaking it down, and building a solution, one small bit at a time, was required to go from knowing some basic ideas of syntax to knowing how to solve a problem with code.
I still struggle after 15 years into programming, and I never published or finished anything because of "judgement anxiety". I waste days, weeks, months writing and rewriting code and then I decide to abandon it because "other developers are going to see how shitty of a developer I am and it'll jeopardize my reputation forever".
> other developers are going to see how shitty of a developer I am and it'll jeopardize my reputation forever
When I first started pushing out shit code on GitHub, I did it under a pseudonym and never tied it to my real identity. I think that really helps when first getting started since you know it’ll never affect you personally. After getting the hang of it, then perhaps tie that to yourself.
But to be honest, I doubt anyone cares much about your/my code nor would they bother judging it.
Of course, I’ve only been programming for ~5 years so I might be missing stuff.
You may not realize just how terrible much of production code actually is! ;-)
There is some source code I've looked at that I thought was clear and easy to understand (at the time at least. I also like simple C/C++ code that compiles with "make", ideally with minimal #ifdefs and without lengthy configure scripts.) This is very rare in my experience, although I really like to see it!
Seriously, building things that are fun and interesting to you and getting them to work is one of the best things you can do. Once you have something working then you can decide whether you can just clean up your existing implementation or whether you want to reorganize it or rewrite it completely, but you'll be at the point where you understand your problem and its solution.
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.
Even after a decade, many coders make limited progress for their potential, and some make very little. Progress depends on balancing consumption of knowledge and application. If one consumes a lot (watches many YouTube videos) but does not create anything with this knowledge, it is evident that they will not progress quickly. If one constantly applies the same knowledge and never seeks to learn new things, they will likewise stagnate.
I don’t know, I only bother to finish projects for work. With personal projects, it always ends up following the 20/80 rule — 20% of the code produces 80% of the value. The remaining 80% of code is largely uninteresting busywork and just isn’t worth the effort for a pet project.
But it’s definitely worth implementing the core concepts in total, both for whatever goal and your own learning. The rest just needs a working mental model, but actually implementing is a waste
As an aside, I’ve found this also holds true for most games, and stopped bothering to finish them (you can usually understand most games in total very quickly, largely because their systems are so shallow)
Yep. Resonates a lot. I've tinkered with code on the side and realised its very hard to do it "part-time".
Learned HTML/CSS in 2012. Built an app in Rails in 2014. Learned basic Javascript in 2018. Delved into React in 2020. Shifted to no-code. Back to Fundamentals in 2023.
I think its hard to really be good at it, but depends on the goal. Most people want to be software engineers for the wrong reasons these days. To me it was always a hobby and if I can build some small useful things for people with just front-end and a database its a win.
Its not easy though. It never was. It requires commitment and patience as well as regularity beyond tinkering with it 1 time a month.
In 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.
I have a lot of respect for self learners. Don't think I would have learned to code if I didn't feel the financial and academic pressure from learning it in University. I still remember my intro course being so mind numbingly difficult coming from an arts background. Simple if else code block assignment that I could complete in 1 minute now took me a whole weekend to initially do 10 years ago.
When it comes to programming we are all self learners because no one teaches you how to write the software you might want to write… Getting taught merely means getting exposed to. The real teaching of something happens when you do it on your own… Taught my self to code in 6th grade and was able to drop out of college to work.. Started and sold my own company. I have to say the CS/CE curriculum is severely lacking and in all honesty not many benefit from it. Someone coming out of school with a bachelors doesn’t seem to be able to translate their “learned” skills into real working knowledge. That can only happen when you actually do what you want to do. Grab a bunch of CS and grads and ask them to write a simple FizzBuzz and you will be astonished at how many barely know where to start. It’s quite sad. Ironically I am now a researcher at MIT… I am in academia and didn’t even finish my degree…
One of my students in a summer school class about programming just couldn't get their head around what a variable was. These concepts are very hard to teach when you are very familiar with them and they come natural to you.
A variable is a box where you can store a certain type of an object. For example, you can have a box with the right size and shape to store toy cars. At one point the variable (box) may contain a red toy car, and at another point it may contain a blue toy car.
If you try to put a banana in there it won't fit because it has the wrong shape for that. We say that the type of the variable (the box) doesn't match the object.
The analogy can be extended to talk about null values (empty boxes), arrays (boxes with slots for multiple objects), etc.
That analogy is heavily stretched with dynamically typed languages, you could say that it's a box that can hold anything, but then the value of the analogy falls apart.
As you point out, all it takes to describe dynamically typed languages is describing a variable as a box that can contain an object. It can contain a fish now and a truck later. What is the problem? Assignments, l-values and such work just fine as far as I can tell.
The analogy works because it's not far removed from what is actually happening in memory. And while laypeople don't know what computer memory is, they have a good intuition about boxes.
The concept of a variable is just the tip of the iceberg: the syntax for dealing with variables (e.g. assignment vs. testing equality) is difficult for newbies to grasp.
Next level of difficulty for newbies is arrays: understanding expressions to set and get values in an array; variables that hold indexes; non-numeric indexes; each of these is a potential huge stumbling block for newbies. And remember, these are just basic programming skills. Things get much harder from there.
The concepts of data manipulation, let alone the mechanics, are difficult for many newbies. Some never get past that point.
That's where I learned before I ever saw any code. When I did see the code I was confused by "x = x + 1" since it makes no sense mathematically, but assignment and state were obvious and intuitive after that.
I didn't either as a kid. I had one of those British Usborne Publishing computer books - one of their intros involved paper only with a long roll of instructions you wrote out and pulled through a cardboard "window" for the current instruction while you kept track of variables on a sheet of paper.
I soon figured out you didn't really need the roll and cardboard window, and could just do the while thing on normal sheets of paper.
Got to try it out for real on a borrowed TRS80 not too long after that though.
Yeah the "Trash80" was the first computer I actually used, the display model at the local Tandy Electronics store.
It was so very barebones with less than 2K free memory if I recall correctly. Later I found another local electronics store with a C64 which was bliss.
I was blessed with a bunch of CHM files. I knew by heart how to browse that style of documentation. I still to this day prefer reference style to tutorial or by example.
In 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 know what you’re doing, and you’ll keep struggling when facing new problems that are outside of the scope of the tutorial.
Maybe you’re learning from low-quality resources? Yes, the internet is full of free resources but most of them are useless and actually harmful, and some curation is needed. Instead of studying the basics over and over from endless free online tutorial/courses, just learn them once, the right way, from a high-quality resource instead. See: teachyourselfcs.com
The author says he struggled with concepts that are “easy” or supposed to be. In my experience of coding since 6th grade and having been in the industry for quite some time, it’s difficult to say something is supposed to be “easy” or “hard”. The author doesn’t give many concrete examples so it’s possible he is just assuming certain things should be super easy… A lot of programmers I meet love to claim they don’t struggle with basics, then I ask them to write be a simple bubble sort or binary search from scratch and 90% cannot do it. They could only do it when they could reference or look it up. Everything thing seems “easy” after you learn it. There’s this romanticized super genius idea everyone thinks they need to live up to but that portrayal is simply fake. No one’s grasps things instantly.. I am a researcher at MIT. I work with arguably some of “smartest” people on the planet, and even they struggle with basic concepts from time to time, as does everyone. There is simply too much information for any single human to know it all, and learn new things instantly. It doesn’t happen…. Most things that should be “simple” or “easy” always end up requiring significant effort because we don’t truly know how to do something until it’s actually down. Forgive my spelling and grammar errors. I am typing on a phone and my hands are just too big to do it quickly.
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
I agree it isn’t but the point I was trying to make is that when you have to do something from scratch, on your own, even if it’s simple, it can be a challenge. My example was poor because I am typing fast sitting in a car parking lot and I hate typing my thoughts on phones.. Forgive 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 time grasping loops, conditional comparisons or swaps. But if you understand all of those the sort writes itself. And understanding loops, comparisons and swaps is pretty fundamental to anything you do as a software engineer, so I'm not sure how any competent software engineer could struggle with it.
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.
Assuming knowledge and understanding of an algorithm but no prior practice with implementing it, one’s way of implementing it does tell about their proficiency in programming.
GPs bubble sort was obviously just an example, effectiveness of the algorithm or wether there’s ever need for implementing it by hand is irrelevant.
> 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!
Thanks for catching the reverse. I was aware of the off by one but thought the “to” operator I invented would be exclusive of the second operand (kinda like range in Python) :)
> Fizzbuzz is actually completely trivial to the point where the problem statement is almost literally (modulo modulo) a description of the algorithm.
Fizzbuzz requires you to read and understand a few lines of requirements. That is much harder than just "order these elements, runtime isn't important", you can easily miss some part of the problem statement or misunderstand it for Fizzbuzz and fail, you shouldn't but it can happen, no such thing for a quadratic sort.
>This is only hard if you have a hard time grasping loops, conditional comparisons or swaps
Or because you don't know the algorithm in question... The problem isn't bubble sort but any generic algorithms test. The examiner wants you to write code but not tell you the specification because it would be shockingly similar to telling you the solution.
When I read a post on HN about inverting a tree I was wondering how exactly you are supposed to invert the child and parent relationship so that children point to parents instead of parents pointing to children. I.e. leaf nodes are now at the root and the root node is where the leaf nodes are supposed to be. Then someone said "He meant reversing the tree" and I'm like "That is not what he said."
> Or because you don't know the algorithm in question
I don't think anyone would care if you did an insertion sort or some other brute force way to sort. Brute force sorting in general is trivial to come up with.
You'll often see responses like "but many people don't need to write sorting algorithms from scratch in their day to day work, so they're out of practice". But to me this attitude itself is indicative of the issue.
Being able to do this doesn't require sorting algorithms to be well-practiced and fresh in one's mind. It requires a general ability to visualize and reason about simple data manipulations. Which to me is an absolute fundamental for a programmer working in any field.
If the algorithm can be described with a small sketch or a couple of sentences, generally an implementation should just flow for an experienced programmer who has general fluency? For something like bubble sort, the description can be more or less directly translated to code.
The fact that someone even conceives of this as something which needs to me memorized / practiced suggests to me that they might not have that kind of basic working fluency.
No need to be so literal. Substitute "bubble sort" for "any simple algorithm involving nested loops/branches/collections" and the result is likely to be the same. Mistakes are common. Partially, that is why unit tests may be useful.
The problem is that people need to know the algorithm you're asking them to implement, which biases it towards memorization.
When you tell them how the algorithm works, it feels like you are not testing anything except syntax.
If you let people look it up, it feels like you aren't testing anything except their research skills.
It is difficult to have a test in a vacuum. It would probably be better to have a test with multiple steps.
Exercise 1:
a) Research the topic bubble sort. Explain what bubble sort does and write some notes or pseudo code that will help you implement it. Once you are done, we will disable internet access and close your browser.
b) Write a working bubble sort in COMPANY LANGUAGE.
c) Modify the bubble sort so that it can sort by multiple columns.
The first tests your research skills, the second your syntax skills and the third your ability to deal with changing requirements and implement novel functionality without research.
This seems like an uninteresting test. Nobody (almost) is implementing sorting algorithms in their day job. We use libraries. It's like asking people who claim to not struggle with driving basics to change their spark plugs and saying "aha, I new you were an idiot".
Yes but it is basic in the sense that it’s one of the first couple algorithms/data structs mostly everyone has been exposed to. Many knowing what they are and the general principle of how and why they work. That is exactly my point though.. Like what do we consider “basic” exactly? That line becomes blurry in any complex field…
If you don't use something, you forget it. Nobody is writing these algorithms in their job. If you did, it will get flagged in code review, the same way rolling your own crypto does. Which is why I think it's unreasonable to expect people to remember how to implement them off the top of their head.
It seems pretty indicative to me. Bubble sort is a simple idea that I understand conceptually but haven’t written the code for yet. That summarises most of my job. And yet, 30 years in, I still make stupid mistakes all the time.
I think the difference between professional engineers and person writing the blog isn’t necessarily skill. I think it’s how we react when we make mistakes. Maybe the real test of a programmer is watching how calmly they can write their buggy bubble sort, then test it and fix the bugs. Bugs happen. How we roll with the punches is what makes some people great.
Theory: "imposter syndrome" is simply seeing the truth. No one lives up to the social conception. Einstein needed help with mathematics. The realistic perspective is the curiosity of a scientist; the humility of a mortal. Knowing the premises does not automatically imply you know all the consequences... even though it "should".
Bugs have been found in production binary search.
Skipping bubblesort, I think quicksort is easy to implement, if you know Hoare's fp insight (I remembered it, but had to check it was him). Making a version that is both efficient and correct may be harder for me... Similar for Boyer-Moore substring matching (I remembered their names!)
He learnt about recursion in a fp workshop(?), and as a first exercise, tried applying it to sort.
You pick a number in the list, then put lesser numbers into a left-list, and greater into a right-list. Recurse.
It's very slow as intuitive, simple and elegant fp, because it's creating new lists like crazy; but a mutable, in-place version (e.g. in C) is super fast. Maybe the origin of the folklore "learn fp to be a better coder, not to code fp"? I don't think he expected it to be so good; he was just doing him. A very smart man.
> I work with arguably some of “smartest” people on the planet, and even they struggle with basic concepts from time to time, as does everyone. There is simply too much information for any single human to know it all, and learn new things instantly.
This. Many programmers, for some reason, act like skill is a complete order; you are either more skilled or less skilled than someone else. In practice you are just familiar with different things, so if somebody doesn't know something that feels trivial to you, it just means he didn't encounter it in the same way.
I have been giving advice to a person, young also (16 years old) and he thinks he can go very far very quickly.
I told him to be patient, to insist, to commit time learning not only typical courses of how to code your website with a database. In fact I gave him advice against doing that first.
I adviced him to learn binary/hex, algorithms, data structures and structured programming as a minimum. Also how a machine works (at least the abstract model): memory addresses, data, pc.ñ, call stack... etc. Interpeters vs compilers, some OS basics (though at first can skip most of this). My advice has been to first learn with Python and later C.
Understand why or when to use functions, certain data structures, etc. Do increasingly difficult but basic exercises.
And specifically, develop a sense and taste, at the end, on how to figure out how to code a solution to a problem he never saw. Cost analysis also helps lots and must be learnt at some point.
This is what happens when you gothrough random courses, exactly:
> 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 know what you’re doing, and you’ll keep struggling when facing new problems that are outside of the scope of the tutorial.
That is SO true. You have to start from scratch. I mean it. Because when you see something like s stacktrace that goes from Python to your native library with memory addresses you will understand NOTHING when the time comes.
Programming is a discipline where you need a lot of practice.
Something I have realized with my struggles in learning how to program is that it's as much a philosophy of how we get a computer to solve a problem as it is an experience learning the structure and syntax of a new language. Coming at it from a complete newbie perspective I don't even know what I don't know, so therefore I can't begin to learn what I should. At best, I can memorize how to do basic things but I don't understand the fundamentals of how those things work, or why they were designed that way.
To be honest, I don't have an objective reason to learn much CS as that's not my layer, so I'm butting up against my own ignorance any time I try to advance in something easy. And then my ADHD determines memorizing that information is unnecessary so I struggle to get concepts to sink in.
Recently I discovered Roblox uses Lua so learning that to make silly experiences for my son sounds wonderful. It's goal oriented so I can convince myself it's worth pursuing, and I feel like Lua concepts will help expand my toolkit for the future. But I'm also not starting from a blank IDE page going "geez how do I even know what to start building first..."
> I don't understand the fundamentals of how those things work, or why they were designed that way
The problem with not understanding things is that when you face a new problem or things crash or go wrong you get totally lost and do not know how to proceed at all.
Another recommendation if you want to learn is that you use a terminal and an editor. Nothing else. You will see things closer to how they work. You will be aware you are launching a script or compiling a file. You will see the output files, you will understand there is a compiled file to be run. You will see if it is native code you run it directly but if it is compiled to bytecode you need a VM, etc.
You probably don't know how valuable motivation is. I learned that lesson only three years ago. It is so easy to simply do nothing both when you are motivated and not motivated. You don't need to know how write lua if you can inspire your son to build things with it. In the last three years, I have probably had more ideas of things that I want to do than in the two decades before that.
When I was 16, I had software skills but was clueless about what to actually build. Now I know what to do and don't have enough time to do it. The idea of grinding two hours a week just doesn't work for me. I want to do things in bursts. Like working 10 hours on it and then weeks of nothing.
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.
I find the story relating, though in a somewhat less dramatic sense.
Even after 20+ years of coding, there are very little moments of feeling on top and fully in control.
The other end -- feelings of "damn I don't get it, why won't it work" and the feeling of being overwhelmed by a big mess -- is quite more frequent.
The weird thing is that thinking "I'm no good at this" is an easy trap to fall into. Sometimes I feel software engineering must be one of the hardest jobs in terms of mental flexibility, constantly trying to figure things out and adapting to new frameworks and ever evolving ways of working.
But most probably there are plenty of other jobs with the same kind of complexities.
i feel very sad that this is a thing. in programming you should always have a feeling of absolute agency. there is no pile of crap deep enough you cant peek under. no bug you shouldn't be able to find, given enough time.
the problem should be that maybe it doesn't make sense to so do in a given context, not that you couldn't choose to do that.
That's the trick. You should not chase every issue down. You should prioritize, but give one issue you should be able to chase it down and get to the bottom of it. So it's not about actually taking om the task of solving every issue, it's about the capability of solving any issue you deem worth solving.
If 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.
He probably isn’t that bad. He just has imposter syndrome most likely… He is assuming people sit down and write things like web browsers in a single, linear sitting. You don’t write any nontrivial software easily if you’re doing something new. The decisions you need to make when developing real software or systems are numerous. Having been in the industry for a very long time and having worked with arguably some of the smartest people in the world, no one lives up the the romanticized “super cider genius” that solves all problems effortlessly in their first go. I am currently a researcher at MIT. I work with some of the most brilliant people out there and you’d be surprised what “simple” things or concepts they struggle with… Everything is simple when you know the answer, but try devising the answer to a truly original problem that hasn’t been breached yet and see how far you get. Even simple sorting algorithms, and basic data structures, were the product of research that took a long time. People didn’t just sit down one night and invent the quick sort in one go….
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.
> 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
Meh this is just cope. The things you are talented at may not be valuable, they may be outside of your reach, specifically if you’ve wasted enough time that your time for discovery is over. Flogging that dead horse probably pays the bills at least (unless you’re a total incompetent, in which case, yes find something ) and then some.
To be fair it sounds like OP found something else, but I’ve known people who never did or never could.
The method that worked for me was working on actual projects.
Build something useful for yourself. And just search the web and ask chatbots and keep hammering on it until it's done, one problem at a time. Maybe forgetting the bigger picture and focusing on small bite sized problems would work for you too.
And when you're done, start working on your next project and you will notice you can reuse some of the knowledge you already have. Make sure every new project challenges you.
I don’t mean to be insulting, but have you considered the possibility that you are too stupid to learn programming? For example, I could never be a doctor because I myself am too stupid at chemistry. Sometimes it’s better to take the path of least resistance. :)
Learn the fundamentals and keep them surfaced, either through explicit spaced repetition or something that approximates it, such as writing, reading or trying to (re)implement them. Then build up on that. Just don't do more than what you can handle at a time. The goal is to reference at least 80% of the necessary from memory.
Coding is hard exactly the way painting is hard or sculpting is hard or playing guitar is hard or writing is hard. It is but it's not. You need to put real effort in to learn, some less if you're naturally inclined to it, and many reach a point where they crest ahill and it really isn't that hard at all anymore.
If you're chasing after it as a career and coding feels persistently hard and unnatural, you might be aiming for a career not really suited to you. On the other hand, if you think making software is cool and you're just quite finding it easy all the time, keep grinding and you may get there. At least in this latter case, you'll be grinding on something you care about as you try to get there. If it's just about money (be honest with yourself), that can be found in a lot of places and some of them might come a lot more easily to you.
I have the impression that some people can be software developers for 10 years or longer but they still don't "get it" while some junior devs are really great right from the start.
These Seniors might be good at duct taping, overengineering or have a "my way or the highway" mindset but aren't capable of finding and implementing a good solution given the constraints.
It probably boils down to factors like intelligence, creative problem solving, ability to focus, reading skills, knowledge retention and a healthy dose of humility.
I guess everyone can (and probably should) learn basic coding skills, but it doesn't mean everyone can become a great software engineer.
Absolutely. Some people just find learning itself hard too. It's a whole other skill that's orthogonal and similarly trainable. To keep making progress at making more things feel easy, you need to remain curious and ambitious. Many don't internalize that and just plateau when pressure lets up enough.
I object to bringing intelligence into the equation. It never explains anything that other factors couldn't. And it trains people to think they have innate limitations, which is a poor mindset for learning.
A common definition of intelligence is the capacity for problem solving.
There are few fields where the capacity for problem solving is more relevant.
People do have innate limitations. I agree that it's dangerous to categorize one's self too harshly, but it's also important to understand your own capabilities and limitations.
Telling people they have no innate limitations sounds nice, but probably just results in them becoming more frustrated and confused if they do hit those limits later on.
I say this as someone who has hit my own limits before. They exist. Maybe not in an absolute sense - I could likely learn nearly anything - but in a relative sense. If it takes me ten times longer than the average participant, it's simply not viable as a career. As a hobby? Sure, go wild.
> I wanted to prove to myself that I was smart, that all the adults in my life who told me I was "dumb and stupid" because I couldn't excell at school were wrong. I was not dumb, I was not an idiot, I could do it.
> And that was when reality slapped me really hard for the first time on my face.
These two consecutive paragraphs seem contradictory.
It's 2 am here right now. I wrote this post very quickly in about 30 mins on the recommendation of a friend to just take my mind off things before going to sleep. I was not expecting it to get any real attention, and so did not attempt to provide much context in the post.
Genuinely appreciate your comments, especially those with encouraging, emphatic words and guidance. Also great to read your own personal journeys as well.
Although I started learning to code 10 years ago, I have not actually been actively coding for all these years. I have worked as a full time dev professionally for maybe just 3 months, and quickly moved into management roles from there.
My primary expertise today is more towards product management, sales, marketing, etc than coding. I currently work in a Enterprise Sales role, and my goal is still being an entrepreneur and building companies.
Zooming out and looking at my entire history, I have spent very little actual time coding. This is the primary reason behind the struggle I express in this post. I feel frustrated with how much little time I have put into it over the years, and how little progress I have made.
Also, perhaps important to note, I have diagnosed ADHD, chronic anxiety disorder and some level of bipolar as well. I don't like to attach these as part of my personality, but it explains a lot of my impulsivity, grandiose thinking and mood swings, which contribute to my frustration significantly as well. Also the reason why I could never learn well in classroom or with tutors. Self-learning has always worked better for me.
The post is intentionally very generic and vague, and doesn't give any specific examples of what I was struggling with and why, simply because it was more of an emotional post to express my frustration from the past week. I also have not written anything in a long time, so this was a good excuse for me to quickly write and publish something.
I recently started working on a new side project, and I have a team of people working with me, but we have been falling short of hands, and so I decided to get more involved in the development, and things were going great until last week when I started trying to refactor our codebase. I hit many walls with things I did not fully deeply understand, and struggling to keep track of a lot of different changes as I was making them - thus ending up breaking things and compounding my frustration even more.
I am currently strongly motivated to get better at coding. That is what prompted me to talk to my friend, who is the best engineer I know, and who encouraged me to write down my thoughts and publish them.
I am certain that with persistence and consistency, I would get through and not struggle as much as I have in the past week.
I think the author is being a little too harsh on himself. It’s totally okay to struggle or feel like you can’t solve something right away. There’s no need to be so hard on yourself. The most important thing is that you have fun with what you do :) You don’t need to be the best for everyone, just be the best for yourself and enjoy it!
I've been coding since I was 15, am now an industry professional with 7 years software development experience. I just spent close to 15 hours debugging a really simple HTML/CSS issue. Why? Because I've never touched HTML/CSS before beyond some CS 101 labs. I'm sure an experienced web dev could have fixed it in 10 minutes.
In my experience programming is less having it all in your head and more where and how to look things up. Because pretty much no one has it all in their head, and the ones that do are hyper-specialized workaholics and would be just as slow as anyone outside of that specialty.
> In my experience programming is less having it all in your head and more where and how to look things up.
This! I was helping teach web dev to a first year student in uni: I realized that for some beginners, knowing what to search is just as important as being able to code.
Having been programming for 5 years (not much but I do dedicate pretty much all my time to it), I feel like the secret sauce is being able to type in the magic words and be able to get the result you’re looking for immediately as the top results. That and being able to read the source code of libraries & lower level code to understand behavior.
I feel like I could've wrote this myself. I've been dabbling with programming for about 20 years. Much of that time though I was managing other programmers and doing very little programming myself. I was also working on unchallenging (but profitable) projects for far too long. Only in the last few years have I felt like I've had breakthroughs and actually begun to feel confident. I attribute this to the fact that I've decided to do the work myself and take on more challenging work. However, most importantly, I've removed distractions from my life. The initial and intermediate learning curves of programming are certainly hard and I don't think it's possible to have any breakthroughs if you are not in a good place in your life. For me, it was the people I had chosen to surround myself with whom I realized were not supportive of me or my goals. Once I fixed that, I had more time and energy to focus on becoming good at programming. I still don't think I am "good" at it but I am certainly improving now. Don't give up, OP. I certainly never will.
169 comments
[ 3.7 ms ] story [ 211 ms ] threadI often think of coding like making music: you don't need to be an expert at an instrument to make nice music - so much to the point where "making music" and "playing an instrument" can be considered very different things.
Sometimes I just need to take a step back and look at it the next day. Sometimes it helps, sometimes not. Sometimes taking a walk helps, or cycling, or taking a shower.
But when I feel frustrated, I know it's an uphill battle that will be mostly unproductive, mostly productive in getting a look at it, some reconnaisance.
I've come to feel that while I love reading HN, it's quite toxic as well. It's like the instagram of coding - every person is so smart, so authoritative, such breadth and depth of knowledge they are all making $300k/yr+ and profess how easy it is to find such a job. It can be really demoralising and even depressing for people who are struggling to be exposed to such potent concentration of things like that.
So it's great to hear someone being vulnerable and owning up to struggles.
I would say, my approach when I hit the types of feelings you express is always to drop down a layer to fundamentals. If X is hard, why is that? It probably means your knowledge isn't sound at some layer below the one you are working at. It sounds like a huge amount of your learning approach has been based on online learning and the issue with these is that they are usually very shallow. They teach you a direct skill but nothing underneath it. So drop down a level and just take time, to properly fill in those gaps. Steadily unravel what is going on one level down. Don't keep battering at the level above constantly getting frustrated. Build your knowledge at the level below. Learn the joy of patiently establishing a sound basis and a complete knowledge of the underlying principles on which something works.
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.)
I have added and removed about 4 million lines of code:
https://github.com/wekan/wekan/graphs/contributors
to WeKan Open Source kanban:
https://wekan.github.io
You are not dumb. It is normal to feel frustrated, when figuring out, step by step, how something works, and what to do. It is like labyrinth. Having enough breaks, taking a walk when needed, having enough coping skills or adding more of them, having patience to keep notes of what is current position in that labyrinth. If some way does not work, try some other way. Getting something working is victory feeling.
It is always about the basics. Many programming languages change syntax often. Some dependencies change.
For example, when writing some for database export:
1) There was no working code examples at documentation
2) Google etc searches had old info, did not work
3) I did not find from source code how it did work
4) ChatGPT, Bing AI etc examples did not work
5) So I tried with trial and error, what is correct syntax, character by character
For some error messages, sometimes Google search shows somebody having same problem, or even a fix. But if not, it's about reading source code of the software.
But this works only when code is available, like in Open Source.
If something is binary executeable, then there is need to decompile, read assembler, deobfuscate, etc. That means even more time required, I have not gone there yet. That is why I use and develop FOSS, when it is possible to more easily fix something, when it is broken.
Why is that supposed to be easy? When things start to sprawl, and more and more tech debt gets left behind (i.e., in the codebase) then complexity increases, as do the risk of balloon grabs (i.e., grab in one place and something pops out somewhere else).
Of course you're tired and demoralized, every change has to be second or third guessed.
Famous last words.
If I knew beforehand what it all would entail, I would never have taken over that project. Therefore I do feel lucky that I was so naive, it brought me many good things. Nowadays I easily see the scope of taking over a project and I hesitate a lot more doing that.
> 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 with it, a lot.
> I go back to the basics, again and again and again.
There shouldn't be this much struggle after 10 years. I wonder if your issue is you were never intentional in your learning and practice and just bounced from topic to topic. You say you're the "idea guy." There's a saying that it's better to finish something than to start something.
I'll admit to being a little shaky on the types of programming needed in enterprise projects at the beginning (less of a focus on maintainable code, but probably more of a focus on what the machine is actually doing), as I only knew exactly what I needed to hack together whatever my hobby project was, but after 5 years of a career and working in 9 different languages it's been pretty easy.
I mean, occasionally there's something that takes a bit to work into my brain's L1 cache, like the precise semantics of prototypical inheritance in javascript, or call by name in scala, but for the most part, everything's been extremely transferable. A hashmap is still a hashmap in any language.
The idea that he was jumping from course to course, across a bunch of different languages made it seem like he valued having the identity as someone who built something, but didn't know what to build. The gap year suggests that as well. I've been in the same boat and the only thing that moved me forward was having a project to work on that I cared about. In my case, I had a normal job with some down time, and learned to code to make that job easier... no courses, just reading the docs and trying to solve the problem right in front of me. I actually had programming classes in college before this, and while I passed without issue, I never felt I learned how to code or built by own stuff, and years passed between that course and when I felt I actually learned. Having a problem, breaking it down, and building a solution, one small bit at a time, was required to go from knowing some basic ideas of syntax to knowing how to solve a problem with code.
Those who put down others or leave nonconstructive feedback, even HN commenters, are not worth your time worrying over.
When I first started pushing out shit code on GitHub, I did it under a pseudonym and never tied it to my real identity. I think that really helps when first getting started since you know it’ll never affect you personally. After getting the hang of it, then perhaps tie that to yourself.
But to be honest, I doubt anyone cares much about your/my code nor would they bother judging it.
Of course, I’ve only been programming for ~5 years so I might be missing stuff.
There is some source code I've looked at that I thought was clear and easy to understand (at the time at least. I also like simple C/C++ code that compiles with "make", ideally with minimal #ifdefs and without lengthy configure scripts.) This is very rare in my experience, although I really like to see it!
Seriously, building things that are fun and interesting to you and getting them to work is one of the best things you can do. Once you have something working then you can decide whether you can just clean up your existing implementation or whether you want to reorganize it or rewrite it completely, but you'll be at the point where you understand your problem and its solution.
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.
But it’s definitely worth implementing the core concepts in total, both for whatever goal and your own learning. The rest just needs a working mental model, but actually implementing is a waste
As an aside, I’ve found this also holds true for most games, and stopped bothering to finish them (you can usually understand most games in total very quickly, largely because their systems are so shallow)
Learned HTML/CSS in 2012. Built an app in Rails in 2014. Learned basic Javascript in 2018. Delved into React in 2020. Shifted to no-code. Back to Fundamentals in 2023.
I think its hard to really be good at it, but depends on the goal. Most people want to be software engineers for the wrong reasons these days. To me it was always a hobby and if I can build some small useful things for people with just front-end and a database its a win.
Its not easy though. It never was. It requires commitment and patience as well as regularity beyond tinkering with it 1 time a month.
“I tried to do a 12 week course in 4 weeks” … and failed, fell into a flurry chaos of self doubt and gave up.
You are not going to shortcut it, you’re running in circles because you cut too many corners.
Take a big breath, focus yourself, divide your tasks into smaller chunks until you can actually solve them, and keep going. There IS NO QUICK FIX.
The only thing that changes with experience is the growing faith that whatever state you’re in now, you’ll be in the other shortly.
If you try to put a banana in there it won't fit because it has the wrong shape for that. We say that the type of the variable (the box) doesn't match the object.
The analogy can be extended to talk about null values (empty boxes), arrays (boxes with slots for multiple objects), etc.
The analogy works because it's not far removed from what is actually happening in memory. And while laypeople don't know what computer memory is, they have a good intuition about boxes.
Next level of difficulty for newbies is arrays: understanding expressions to set and get values in an array; variables that hold indexes; non-numeric indexes; each of these is a potential huge stumbling block for newbies. And remember, these are just basic programming skills. Things get much harder from there.
The concepts of data manipulation, let alone the mechanics, are difficult for many newbies. Some never get past that point.
That's where I learned before I ever saw any code. When I did see the code I was confused by "x = x + 1" since it makes no sense mathematically, but assignment and state were obvious and intuitive after that.
Kids these days
:P
how did you learn to program computers without computers around?
I soon figured out you didn't really need the roll and cardboard window, and could just do the while thing on normal sheets of paper.
Got to try it out for real on a borrowed TRS80 not too long after that though.
It was so very barebones with less than 2K free memory if I recall correctly. Later I found another local electronics store with a C64 which was bliss.
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 know what you’re doing, and you’ll keep struggling when facing new problems that are outside of the scope of the tutorial.
Maybe you’re learning from low-quality resources? Yes, the internet is full of free resources but most of them are useless and actually harmful, and some curation is needed. Instead of studying the basics over and over from endless free online tutorial/courses, just learn them once, the right way, from a high-quality resource instead. See: teachyourselfcs.com
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
Companies ask that kind of stuff at interviews lol
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 time grasping loops, conditional comparisons or swaps. But if you understand all of those the sort writes itself. And understanding loops, comparisons and swaps is pretty fundamental to anything you do as a software engineer, so I'm not sure how any competent software engineer could struggle with it.
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.
GPs bubble sort was obviously just an example, effectiveness of the algorithm or wether there’s ever need for implementing it by hand is irrelevant.
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!
(Also a subtle off-by-one error, it should be 0 to |n|-1 and i to |n|-1.)
Fizzbuzz requires you to read and understand a few lines of requirements. That is much harder than just "order these elements, runtime isn't important", you can easily miss some part of the problem statement or misunderstand it for Fizzbuzz and fail, you shouldn't but it can happen, no such thing for a quadratic sort.
Or because you don't know the algorithm in question... The problem isn't bubble sort but any generic algorithms test. The examiner wants you to write code but not tell you the specification because it would be shockingly similar to telling you the solution.
When I read a post on HN about inverting a tree I was wondering how exactly you are supposed to invert the child and parent relationship so that children point to parents instead of parents pointing to children. I.e. leaf nodes are now at the root and the root node is where the leaf nodes are supposed to be. Then someone said "He meant reversing the tree" and I'm like "That is not what he said."
I don't think anyone would care if you did an insertion sort or some other brute force way to sort. Brute force sorting in general is trivial to come up with.
You'll often see responses like "but many people don't need to write sorting algorithms from scratch in their day to day work, so they're out of practice". But to me this attitude itself is indicative of the issue.
Being able to do this doesn't require sorting algorithms to be well-practiced and fresh in one's mind. It requires a general ability to visualize and reason about simple data manipulations. Which to me is an absolute fundamental for a programmer working in any field.
If the algorithm can be described with a small sketch or a couple of sentences, generally an implementation should just flow for an experienced programmer who has general fluency? For something like bubble sort, the description can be more or less directly translated to code.
The fact that someone even conceives of this as something which needs to me memorized / practiced suggests to me that they might not have that kind of basic working fluency.
When you tell them how the algorithm works, it feels like you are not testing anything except syntax.
If you let people look it up, it feels like you aren't testing anything except their research skills.
It is difficult to have a test in a vacuum. It would probably be better to have a test with multiple steps.
Exercise 1:
a) Research the topic bubble sort. Explain what bubble sort does and write some notes or pseudo code that will help you implement it. Once you are done, we will disable internet access and close your browser.
b) Write a working bubble sort in COMPANY LANGUAGE.
c) Modify the bubble sort so that it can sort by multiple columns.
The first tests your research skills, the second your syntax skills and the third your ability to deal with changing requirements and implement novel functionality without research.
I think the difference between professional engineers and person writing the blog isn’t necessarily skill. I think it’s how we react when we make mistakes. Maybe the real test of a programmer is watching how calmly they can write their buggy bubble sort, then test it and fix the bugs. Bugs happen. How we roll with the punches is what makes some people great.
Bugs have been found in production binary search.
Skipping bubblesort, I think quicksort is easy to implement, if you know Hoare's fp insight (I remembered it, but had to check it was him). Making a version that is both efficient and correct may be harder for me... Similar for Boyer-Moore substring matching (I remembered their names!)
Could you please provide more information on this?
You pick a number in the list, then put lesser numbers into a left-list, and greater into a right-list. Recurse.
It's very slow as intuitive, simple and elegant fp, because it's creating new lists like crazy; but a mutable, in-place version (e.g. in C) is super fast. Maybe the origin of the folklore "learn fp to be a better coder, not to code fp"? I don't think he expected it to be so good; he was just doing him. A very smart man.
This. Many programmers, for some reason, act like skill is a complete order; you are either more skilled or less skilled than someone else. In practice you are just familiar with different things, so if somebody doesn't know something that feels trivial to you, it just means he didn't encounter it in the same way.
I told him to be patient, to insist, to commit time learning not only typical courses of how to code your website with a database. In fact I gave him advice against doing that first.
I adviced him to learn binary/hex, algorithms, data structures and structured programming as a minimum. Also how a machine works (at least the abstract model): memory addresses, data, pc.ñ, call stack... etc. Interpeters vs compilers, some OS basics (though at first can skip most of this). My advice has been to first learn with Python and later C.
Understand why or when to use functions, certain data structures, etc. Do increasingly difficult but basic exercises.
And specifically, develop a sense and taste, at the end, on how to figure out how to code a solution to a problem he never saw. Cost analysis also helps lots and must be learnt at some point.
This is what happens when you gothrough random courses, exactly:
> 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 know what you’re doing, and you’ll keep struggling when facing new problems that are outside of the scope of the tutorial.
That is SO true. You have to start from scratch. I mean it. Because when you see something like s stacktrace that goes from Python to your native library with memory addresses you will understand NOTHING when the time comes.
Programming is a discipline where you need a lot of practice.
To be honest, I don't have an objective reason to learn much CS as that's not my layer, so I'm butting up against my own ignorance any time I try to advance in something easy. And then my ADHD determines memorizing that information is unnecessary so I struggle to get concepts to sink in.
Recently I discovered Roblox uses Lua so learning that to make silly experiences for my son sounds wonderful. It's goal oriented so I can convince myself it's worth pursuing, and I feel like Lua concepts will help expand my toolkit for the future. But I'm also not starting from a blank IDE page going "geez how do I even know what to start building first..."
The problem with not understanding things is that when you face a new problem or things crash or go wrong you get totally lost and do not know how to proceed at all.
Another recommendation if you want to learn is that you use a terminal and an editor. Nothing else. You will see things closer to how they work. You will be aware you are launching a script or compiling a file. You will see the output files, you will understand there is a compiled file to be run. You will see if it is native code you run it directly but if it is compiled to bytecode you need a VM, etc.
That is part of the details one must be aware of.
When I was 16, I had software skills but was clueless about what to actually build. Now I know what to do and don't have enough time to do it. The idea of grinding two hours a week just doesn't work for me. I want to do things in bursts. Like working 10 hours on it and then weeks of nothing.
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.
Even after 20+ years of coding, there are very little moments of feeling on top and fully in control.
The other end -- feelings of "damn I don't get it, why won't it work" and the feeling of being overwhelmed by a big mess -- is quite more frequent.
The weird thing is that thinking "I'm no good at this" is an easy trap to fall into. Sometimes I feel software engineering must be one of the hardest jobs in terms of mental flexibility, constantly trying to figure things out and adapting to new frameworks and ever evolving ways of working.
But most probably there are plenty of other jobs with the same kind of complexities.
the problem should be that maybe it doesn't make sense to so do in a given context, not that you couldn't choose to do that.
I mean, yea, technically? But when the codebase gets very big, it can become intractable to chase every issue down.
> given enough time.
Okay sure. One often isn't given enough time though, if it's for a job.
But I wouldn't describe it as a feeling of absolute agency. More like pressure-induced minor chaos
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.
I can't imagine how someone with 10 years of programming experience would make this assumption.
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.
Meh this is just cope. The things you are talented at may not be valuable, they may be outside of your reach, specifically if you’ve wasted enough time that your time for discovery is over. Flogging that dead horse probably pays the bills at least (unless you’re a total incompetent, in which case, yes find something ) and then some.
To be fair it sounds like OP found something else, but I’ve known people who never did or never could.
And when you're done, start working on your next project and you will notice you can reuse some of the knowledge you already have. Make sure every new project challenges you.
If you're chasing after it as a career and coding feels persistently hard and unnatural, you might be aiming for a career not really suited to you. On the other hand, if you think making software is cool and you're just quite finding it easy all the time, keep grinding and you may get there. At least in this latter case, you'll be grinding on something you care about as you try to get there. If it's just about money (be honest with yourself), that can be found in a lot of places and some of them might come a lot more easily to you.
These Seniors might be good at duct taping, overengineering or have a "my way or the highway" mindset but aren't capable of finding and implementing a good solution given the constraints.
It probably boils down to factors like intelligence, creative problem solving, ability to focus, reading skills, knowledge retention and a healthy dose of humility.
I guess everyone can (and probably should) learn basic coding skills, but it doesn't mean everyone can become a great software engineer.
There are few fields where the capacity for problem solving is more relevant.
People do have innate limitations. I agree that it's dangerous to categorize one's self too harshly, but it's also important to understand your own capabilities and limitations.
Telling people they have no innate limitations sounds nice, but probably just results in them becoming more frustrated and confused if they do hit those limits later on.
I say this as someone who has hit my own limits before. They exist. Maybe not in an absolute sense - I could likely learn nearly anything - but in a relative sense. If it takes me ten times longer than the average participant, it's simply not viable as a career. As a hobby? Sure, go wild.
> And that was when reality slapped me really hard for the first time on my face.
These two consecutive paragraphs seem contradictory.
It's 2 am here right now. I wrote this post very quickly in about 30 mins on the recommendation of a friend to just take my mind off things before going to sleep. I was not expecting it to get any real attention, and so did not attempt to provide much context in the post.
Genuinely appreciate your comments, especially those with encouraging, emphatic words and guidance. Also great to read your own personal journeys as well.
Although I started learning to code 10 years ago, I have not actually been actively coding for all these years. I have worked as a full time dev professionally for maybe just 3 months, and quickly moved into management roles from there.
My primary expertise today is more towards product management, sales, marketing, etc than coding. I currently work in a Enterprise Sales role, and my goal is still being an entrepreneur and building companies.
Zooming out and looking at my entire history, I have spent very little actual time coding. This is the primary reason behind the struggle I express in this post. I feel frustrated with how much little time I have put into it over the years, and how little progress I have made.
Also, perhaps important to note, I have diagnosed ADHD, chronic anxiety disorder and some level of bipolar as well. I don't like to attach these as part of my personality, but it explains a lot of my impulsivity, grandiose thinking and mood swings, which contribute to my frustration significantly as well. Also the reason why I could never learn well in classroom or with tutors. Self-learning has always worked better for me.
The post is intentionally very generic and vague, and doesn't give any specific examples of what I was struggling with and why, simply because it was more of an emotional post to express my frustration from the past week. I also have not written anything in a long time, so this was a good excuse for me to quickly write and publish something.
I recently started working on a new side project, and I have a team of people working with me, but we have been falling short of hands, and so I decided to get more involved in the development, and things were going great until last week when I started trying to refactor our codebase. I hit many walls with things I did not fully deeply understand, and struggling to keep track of a lot of different changes as I was making them - thus ending up breaking things and compounding my frustration even more.
I am currently strongly motivated to get better at coding. That is what prompted me to talk to my friend, who is the best engineer I know, and who encouraged me to write down my thoughts and publish them.
I am certain that with persistence and consistency, I would get through and not struggle as much as I have in the past week.
In my experience programming is less having it all in your head and more where and how to look things up. Because pretty much no one has it all in their head, and the ones that do are hyper-specialized workaholics and would be just as slow as anyone outside of that specialty.
This! I was helping teach web dev to a first year student in uni: I realized that for some beginners, knowing what to search is just as important as being able to code.
Having been programming for 5 years (not much but I do dedicate pretty much all my time to it), I feel like the secret sauce is being able to type in the magic words and be able to get the result you’re looking for immediately as the top results. That and being able to read the source code of libraries & lower level code to understand behavior.