Ask HN: Have I lost my skills in programming?
75 comments
> Do I just have to go heads first and it will all just "fit in place"? I will finally become a good and confident programmer one day?
You have to build things without tutorials for this. Just take something and then build it without a tutorial. For example, you can build space invaders. How would you build that without a tutorial? Here would be my process:
1. Space invaders has graphics, do you know how to do graphics in your environment of choice? If not look up documentation for some draw API and try to draw things moving around.
2. Space invaders has images, look up documentation how to load images and implement. Make sure that you can draw the images and move them around like in 1.
3. Games need user input, look up documentation for how to listen for keystrokes, make the things that move around from earlier controllable.
4. The rest of the game is just implement some boring logic like tracking score, tracking aliens, checking collisions, killing the player, winning etc. This is fairly straightforward to implement.
This was just an example, you can do most things in similar ways. Like building a forum, building a text editor, building a web server, building an interpreter/compiler etc.
You have to build things without tutorials for this. Just take something and then build it without a tutorial. For example, you can build space invaders. How would you build that without a tutorial? Here would be my process:
1. Space invaders has graphics, do you know how to do graphics in your environment of choice? If not look up documentation for some draw API and try to draw things moving around.
2. Space invaders has images, look up documentation how to load images and implement. Make sure that you can draw the images and move them around like in 1.
3. Games need user input, look up documentation for how to listen for keystrokes, make the things that move around from earlier controllable.
4. The rest of the game is just implement some boring logic like tracking score, tracking aliens, checking collisions, killing the player, winning etc. This is fairly straightforward to implement.
This was just an example, you can do most things in similar ways. Like building a forum, building a text editor, building a web server, building an interpreter/compiler etc.
Agreed on the project instead of tutes, but a simple crud app would be much more typical than a complex game.
If you have any reasonable skills as a programmer (which I have to assume if you have been programming professionally for some time) then you should stop watching videos, etc. As you have observed many are poor quality and aimed at beginners. Many so called challenges are created by jerks who are trying to prove that they are "clever".
Why don't you pick up a well recognised book and learn from that instead. I'm thinking along the lines of SICP (Structure and Interpretation of Computer Programs)? Yes, learning a new programming language probably would also help with your progression.
Why don't you pick up a well recognised book and learn from that instead. I'm thinking along the lines of SICP (Structure and Interpretation of Computer Programs)? Yes, learning a new programming language probably would also help with your progression.
I think SICP is way too hard for the amount of material it wishes to explicitly convey to you. If we were speaking thoroughly, what do people expect to get out of SICP?
SICP is one of the books that I've seen everyone recommend - and I never understood what is so special about it, until I finally read it!
It feels very similar to a mathematical book. Rather than learning about the syntax, or the programming rules It teaches a way of thinking. I agree it is hard - but I don't know if it could be simpler.
In the end programming is not about computers or programs - but people solving problems. It teaches people to solve problems using computers.
It feels very similar to a mathematical book. Rather than learning about the syntax, or the programming rules It teaches a way of thinking. I agree it is hard - but I don't know if it could be simpler.
In the end programming is not about computers or programs - but people solving problems. It teaches people to solve problems using computers.
Fantastic explanation of the impact of working through SICP.
Scheme notation is effectively AST, thus you can mentally map any PL to it and at the same time avoid getting caught up in the syntax issues of any given language.
Agreed working through SICP is a non-trivial experience. However, what you learn will provide solid foundations for your professional future regardless what languages you end up using.
Scheme notation is effectively AST, thus you can mentally map any PL to it and at the same time avoid getting caught up in the syntax issues of any given language.
Agreed working through SICP is a non-trivial experience. However, what you learn will provide solid foundations for your professional future regardless what languages you end up using.
Stop sharpening your tools and just use them for a while to do something fun or interesting. Different parts of your brain are trained by different activities: study, play, taking tests, competing, working with other people, fighting for your life, etc. You've probably done the equivalent of an athlete who spends all of his time on drilling certain basics without spending much time actually playing the game.
Go play the game. Put projects before skills for a while and your skills will improve, too.
Go play the game. Put projects before skills for a while and your skills will improve, too.
I believe your problem is simple and has a simple fix...
There are 2 kinds of learning: "Push" and "Pull". "Push" means you find learning opportunities and "push" them onto whatever you're building. "Pull" means you have something you have to build but don't have all the personal resources you need, so you "pull" in what you need as you go.
You're problem is that you're a "Pull" learner using a "Push" approach. The result is that you haven't learned deeply enough because you're pushing what you have so that permanent deep knowledge hasn't successfully transferred into the firmware of your brain. When you "pull" knowledge, you're applying it immediately in a deep, permanent way and you're much more likely to get all the value from it.
How do I know you're a "Push" learner? Easy, your language. "Coding challenges", "tutorials", "videos" are classic examples. Nothing wrong with these when you need them (by "Pulling"). But when you "Push" them into your brain you get the classic result: confusion, over complication, frustration, and eventually, anger. This is a common problem. You are not alone.
I am the opposite, a classic "Pull" learner. I bet I don't know more that 20% of the syntax of any technology I know. I've written over 2 million lines of code in over 1,000 successful projects but I've only written about 15 programs from scratch. I really don't care about how much I know or how good I am; I only care about getting the job done and satisfying my customer to get their job done with my tools.
Like I promised, your solution is simple: Find someone who needs what you're building and then find a way to build it. That's it. Trust your inner self to find what you need, learn it, make it work, and the internalize it.
The sooner you stop worrying about your problem and start worrying about your customer's, the sooner you solve your problem as a byproduct of solving theirs.
Give it a shot and let us know how it goes.
There are 2 kinds of learning: "Push" and "Pull". "Push" means you find learning opportunities and "push" them onto whatever you're building. "Pull" means you have something you have to build but don't have all the personal resources you need, so you "pull" in what you need as you go.
You're problem is that you're a "Pull" learner using a "Push" approach. The result is that you haven't learned deeply enough because you're pushing what you have so that permanent deep knowledge hasn't successfully transferred into the firmware of your brain. When you "pull" knowledge, you're applying it immediately in a deep, permanent way and you're much more likely to get all the value from it.
How do I know you're a "Push" learner? Easy, your language. "Coding challenges", "tutorials", "videos" are classic examples. Nothing wrong with these when you need them (by "Pulling"). But when you "Push" them into your brain you get the classic result: confusion, over complication, frustration, and eventually, anger. This is a common problem. You are not alone.
I am the opposite, a classic "Pull" learner. I bet I don't know more that 20% of the syntax of any technology I know. I've written over 2 million lines of code in over 1,000 successful projects but I've only written about 15 programs from scratch. I really don't care about how much I know or how good I am; I only care about getting the job done and satisfying my customer to get their job done with my tools.
Like I promised, your solution is simple: Find someone who needs what you're building and then find a way to build it. That's it. Trust your inner self to find what you need, learn it, make it work, and the internalize it.
The sooner you stop worrying about your problem and start worrying about your customer's, the sooner you solve your problem as a byproduct of solving theirs.
Give it a shot and let us know how it goes.
Pick a problem you have and solve it. Even if you have to start small, like a grocery checklist. Just do a few of those to explore a problem space and see it through to the end. Don't grind like "I must learn". Let curiosity be your guide and get curious about making something you need.
If you need help, refer to documentation in the IDE, then Stack Overflow. Read. Don't watch videos, you should be able to read faster than anyone can talk. Take notes. With pen and paper, not a text editor window. The muscle movement of writing is a different way to teach yourself. There are studies that say retention is much better when taking notes on paper vs. computer.
After that, move your problem space up, like maybe a video game and repeat. I learned I dunno probably 5 different languages by writing Space Invaders in the new language.
Revisit one of your programs and either refactor or rewrite it. Actually, refactor one, rewrite another - from scratch. No peeking at the original. And by rewrite, I mean design a new approach to solving the same problem set.
If you need help, refer to documentation in the IDE, then Stack Overflow. Read. Don't watch videos, you should be able to read faster than anyone can talk. Take notes. With pen and paper, not a text editor window. The muscle movement of writing is a different way to teach yourself. There are studies that say retention is much better when taking notes on paper vs. computer.
After that, move your problem space up, like maybe a video game and repeat. I learned I dunno probably 5 different languages by writing Space Invaders in the new language.
Revisit one of your programs and either refactor or rewrite it. Actually, refactor one, rewrite another - from scratch. No peeking at the original. And by rewrite, I mean design a new approach to solving the same problem set.
> Maybe I am just overcomplicating things when programming
This is probably the root of the problem. But there is good news because a) many people suffer from this and b) they tend to be good or at least experienced programmers
For example; we use FizzBuzz and some algorithm challenges to screen new hire candidates - the number of times an otherwise great programmer has submitted a 100 line behemoth (for something that should be less than 10) is unamusing.
As others have said; sounds like youve cracked programmig, you now need to hone your craft by learning engineering methods and problem solving.
This is best achieved by doing; try building something useful based on an ambiguous goal (if you let us know what programming languages/interests you have then it might help get more specific advice). Work your way up to submitting patches to open source projects - where youll get valuable feedback that will help hone your method
This is probably the root of the problem. But there is good news because a) many people suffer from this and b) they tend to be good or at least experienced programmers
For example; we use FizzBuzz and some algorithm challenges to screen new hire candidates - the number of times an otherwise great programmer has submitted a 100 line behemoth (for something that should be less than 10) is unamusing.
As others have said; sounds like youve cracked programmig, you now need to hone your craft by learning engineering methods and problem solving.
This is best achieved by doing; try building something useful based on an ambiguous goal (if you let us know what programming languages/interests you have then it might help get more specific advice). Work your way up to submitting patches to open source projects - where youll get valuable feedback that will help hone your method
- HTML
- CSS
- JavaScript
- NodeJS
- MongoDB
- PHP
- C#
- Java
I've sorted the list as my knowledge is in them. HTML, CSS, JavaScript is where I'm best and PHP, C#, Java is where I'm worst.
Interests that I have are, Math, Programming, Electronics, Physics, Chemistry.
I've sorted the list as my knowledge is in them. HTML, CSS, JavaScript is where I'm best and PHP, C#, Java is where I'm worst.
Interests that I have are, Math, Programming, Electronics, Physics, Chemistry.
Thats a pretty big spread :) Id say focus on the web side of things and build a few apps - perhaps something you would find useful or rebuild an app you use.
<rant>
> the number of times an otherwise great programmer has submitted a 100 line behemoth (for something that should be less than 10) is unamusing.
What are your requirements? Short, terse, untested code? Objected oriented code? Bullet proof, modular code capable of handling a never ending stream of inputs?
Interviewers like asking questions that seem simple, but then they like to pile on unstated requirements, or judge code that was written sub-optimally on purpose as if it were production ready. Interviewers also don't usually have empathy for how badly interviewees have been treated by other interviewers, and how easy it is to get nervous as an interviewee when you find yourself talking to yet another interviewer with unstated expectations.
tl;dr...
- garbage in, garbage out
- we're all damaged goods, so be nice by just saying what you really want
</rant>
> the number of times an otherwise great programmer has submitted a 100 line behemoth (for something that should be less than 10) is unamusing.
What are your requirements? Short, terse, untested code? Objected oriented code? Bullet proof, modular code capable of handling a never ending stream of inputs?
Interviewers like asking questions that seem simple, but then they like to pile on unstated requirements, or judge code that was written sub-optimally on purpose as if it were production ready. Interviewers also don't usually have empathy for how badly interviewees have been treated by other interviewers, and how easy it is to get nervous as an interviewee when you find yourself talking to yet another interviewer with unstated expectations.
tl;dr...
- garbage in, garbage out
- we're all damaged goods, so be nice by just saying what you really want
</rant>
Its a test given pre-interview to do in their time. 90 minutes, 3 questions.
It is a gateway; candidates we want to interview a) can easily solve the problem and b) realise that its a 90 minute gateway test and therefore probably doesnt need to be gold plated.
In baseline and control testing it has proven entirely effective in screening out the two extremes;those that cannot code and those that over engineer.
(btw I agree with your overall sentiment; I put a lot of effort into making sure our interviews are friendlier, more effective and clear)
It is a gateway; candidates we want to interview a) can easily solve the problem and b) realise that its a 90 minute gateway test and therefore probably doesnt need to be gold plated.
In baseline and control testing it has proven entirely effective in screening out the two extremes;those that cannot code and those that over engineer.
(btw I agree with your overall sentiment; I put a lot of effort into making sure our interviews are friendlier, more effective and clear)
Thanks. The context helps.
Probably you are just procrastinating. Procrastination has to do with anxiety emotion. Whatever creates anxiety, creates procrastination.
I have programmed for more than 20 years, but programming is never what I want. In fact it is an obstacle for getting what I want, like helping people.
You probably need real problems-challenges that you can solve.
I have created compilers because I needed it for something else. If I could get the same result with 0 programming I will do. In fact I proactively work to destroy programming in its current form in the future.
Programming is a dead end without something else as a goal. In fact, it creates a serious imbalance in your life: You spend most of your time thinking rationally(conscious mind), slowly,alone, static, in front of a computer(sit down?).
That is deeply abnormal for humans beings. We are designed for moving miles or kms each day, mostly use our subconscious mind(not thinking rationally)in a social way while hunting, fishing, collecting, making tools, pottery or clothing.
When you break the balance you don't need more of what created the imbalance in the first place. Spending your life only programming for me is the definition of a miserable life.
As I have to program, I will do whatever I can to restore the equilibrium, like going out each day, practicing a sport that requires coordination, meeting colleagues,friends and family regularly, meditating and never sitting down while in front of a computer(well I use a stool).
I have programmed for more than 20 years, but programming is never what I want. In fact it is an obstacle for getting what I want, like helping people.
You probably need real problems-challenges that you can solve.
I have created compilers because I needed it for something else. If I could get the same result with 0 programming I will do. In fact I proactively work to destroy programming in its current form in the future.
Programming is a dead end without something else as a goal. In fact, it creates a serious imbalance in your life: You spend most of your time thinking rationally(conscious mind), slowly,alone, static, in front of a computer(sit down?).
That is deeply abnormal for humans beings. We are designed for moving miles or kms each day, mostly use our subconscious mind(not thinking rationally)in a social way while hunting, fishing, collecting, making tools, pottery or clothing.
When you break the balance you don't need more of what created the imbalance in the first place. Spending your life only programming for me is the definition of a miserable life.
As I have to program, I will do whatever I can to restore the equilibrium, like going out each day, practicing a sport that requires coordination, meeting colleagues,friends and family regularly, meditating and never sitting down while in front of a computer(well I use a stool).
The fundamentals never change. If I had to guess, your anxiety is from an overload of information and paralysis by analysis. It's easy to get lost in noise.
I remind myself of this whenever I feel like I'm being swallowed up in a rabbit hole of videos and opinions.
Do you have a math background? The thing that ultimately saved me from what I think is a similar problem to yours, and bear with me, is mathematics, particularly Discrete Math. I learned to program long before I discovered an interest in mathematics and the difference in skill, confidence and happiness is stark.
Many programmers go on about how math is not really necessary for programming. They are wrong. Sure, you can get by and you can do creative things and have a job that doesn't require "CS theory" but you'll be forever hamstrung by the torrent of shit being hurled at you from every direction at all times. You'll forever be at the mercy of bad tutorials, shortcuts and conveniences.
Mathematical thinking is the antidote to this kind of paralysis and insecurity. It's the power of knowing how similar things really are in computing and how little it's really changed. It's the power to eliminate bullshit.
You'll still have to learn new languages and tech but you'll be far greater equipped to detect and avoid the garbage.
Mathematical thinking is a super power in this field.
I remind myself of this whenever I feel like I'm being swallowed up in a rabbit hole of videos and opinions.
Do you have a math background? The thing that ultimately saved me from what I think is a similar problem to yours, and bear with me, is mathematics, particularly Discrete Math. I learned to program long before I discovered an interest in mathematics and the difference in skill, confidence and happiness is stark.
Many programmers go on about how math is not really necessary for programming. They are wrong. Sure, you can get by and you can do creative things and have a job that doesn't require "CS theory" but you'll be forever hamstrung by the torrent of shit being hurled at you from every direction at all times. You'll forever be at the mercy of bad tutorials, shortcuts and conveniences.
Mathematical thinking is the antidote to this kind of paralysis and insecurity. It's the power of knowing how similar things really are in computing and how little it's really changed. It's the power to eliminate bullshit.
You'll still have to learn new languages and tech but you'll be far greater equipped to detect and avoid the garbage.
Mathematical thinking is a super power in this field.
mathematical thinking is a subset of thinking
Well that seems overly broad and meaningless. Care to expand on that?
A good developer starts out by planning, not coding.
When you have a good plan, the next step is usually obvious.
Also, you only learn by doing, and luck favors the active.
Learn the very minimum by tutorials, make up a project and go - learn as you need...
That is my go-to plan (and I have been working as a developer for 20+ years)
When you have a good plan, the next step is usually obvious.
Also, you only learn by doing, and luck favors the active.
Learn the very minimum by tutorials, make up a project and go - learn as you need...
That is my go-to plan (and I have been working as a developer for 20+ years)
If you have trouble picking a project, code katas are really fun to try.
The instructions are broad enough that you can solve them in different ways. Take a crack at one, solve it. Reflect on what was easy and what was hard or painful. Come back some time later, re-do differently - maybe this time optimising for what was hard the first time.
Also you can take a look at classic data structures and reimplement them from scratch. Don't look at the current implementation, just at how it's supposed to work, and try implementing a List (array or link based ?), a Map (hash, tree?), etc. Then you can compare with the existing implementation.
Or play those coding games you're talking about ! Start easy, work your way up. When it gets too hard, take a break, try another game. Let it rest a bit, come back to it when you have fresher ideas in 2 weeks time.
In general, flex your muscles where you think you're lacking. E.g.: think you overcomplicate ? Do a kata, finish it. Then look at it and try to simplify what you've done.
Good luck in your practice, I hope you enjoy it :)
The instructions are broad enough that you can solve them in different ways. Take a crack at one, solve it. Reflect on what was easy and what was hard or painful. Come back some time later, re-do differently - maybe this time optimising for what was hard the first time.
Also you can take a look at classic data structures and reimplement them from scratch. Don't look at the current implementation, just at how it's supposed to work, and try implementing a List (array or link based ?), a Map (hash, tree?), etc. Then you can compare with the existing implementation.
Or play those coding games you're talking about ! Start easy, work your way up. When it gets too hard, take a break, try another game. Let it rest a bit, come back to it when you have fresher ideas in 2 weeks time.
In general, flex your muscles where you think you're lacking. E.g.: think you overcomplicate ? Do a kata, finish it. Then look at it and try to simplify what you've done.
Good luck in your practice, I hope you enjoy it :)
You don't need programming skills what you need is engineering skills.
Try to find other root causes. Anxiety, depression, vitamin/minerals/good fat deficiency.
https://medium.com/@dr_eprice/laziness-does-not-exist-3af27e...
I think that anxiety or depression can be a factor. Because before programming was just a hobby for me. Now I'm doing a coding bootcamp where I pay about $100/month which is a lot for my family. I have a lot of pressure on me to be good to get a job, since I am going all in for a tech career. I am going to school in the day and doing the coding bootcamp at night and I'm learning from other sources too because I feel like I have to work 120% to be better than other to have a better chance finding a job.
I'm not sure. :(
I'm not sure. :(
To the extent that you can steer what you are working on at the coding bootcamp I recommend picking something that you are genuinely interested in as that will lead to greater satisfaction in both the minor and major achievements in programming. It will also give you something to talk about during interviews :)
where are you from?
I am from Bosnia and Herzegovina.
Bosnia and Herzegovina.
Sometimes confusion is just the integration phase of learning. Up to a point, it is completely natural and healthy. You have to feel mixed up when learning to combine so much knowledge.
But always consider the possibility that you are suffering a mild amount of burnout. After 15 years of coding I had a two year stretch when it became difficult for me to organize projects, and I found that taking 5 mg a day of Paxil really helped. Mild problems of concerntration sometimes arise, and you have to ask yourself the basics, are you getting enough sleep, are you getting enough exercise? If yes, consider the possibility of burnout, and pursue treatment.
But always consider the possibility that you are suffering a mild amount of burnout. After 15 years of coding I had a two year stretch when it became difficult for me to organize projects, and I found that taking 5 mg a day of Paxil really helped. Mild problems of concerntration sometimes arise, and you have to ask yourself the basics, are you getting enough sleep, are you getting enough exercise? If yes, consider the possibility of burnout, and pursue treatment.
It's irresponsible to suggest that burnout is treated with antidepressants and sleep. Burnout is an occupational health problem whose only solution is in the form of occupational changes.
https://en.wikipedia.org/wiki/Occupational_burnout
If a job is killing you, the solution is not to numb the pain away.
https://en.wikipedia.org/wiki/Occupational_burnout
If a job is killing you, the solution is not to numb the pain away.
(Could do with context: how old are you? Are you doing this as a job? As a student?)
> When I was a beginner I could solve any problem those "coding challenge" websites, but now I simply can't. I haven't stopped coding since then, I was doing it every single day and I still got worse. Maybe I am just overcomplicating things when programming.
How has this happened? Probably you are overcomplicating things. I would say that one good tutorial is better than a thousand bad ones. I would also say to skip video tutorials entirely.
Can you find a mentor or colleague? Or even just fellow learner? Not everyone is an autodidact, it's quite rare.
> When I was a beginner I could solve any problem those "coding challenge" websites, but now I simply can't. I haven't stopped coding since then, I was doing it every single day and I still got worse. Maybe I am just overcomplicating things when programming.
How has this happened? Probably you are overcomplicating things. I would say that one good tutorial is better than a thousand bad ones. I would also say to skip video tutorials entirely.
Can you find a mentor or colleague? Or even just fellow learner? Not everyone is an autodidact, it's quite rare.
I'm 18 years old, I don't have a job. I am going to school right now (Electrical Engineering).
I live in Bosnia and Herzegovina, it's not a good place to live if you want to pursue an IT career. I don't have any friends that do programming that I can talk to and create programs together. I would love to have a mentor or a colleague to work with me. I've tried learning with other developers, but it didn't work out that well.
I really want to find a open source project that is meaningful to me and is on my skill level. I'm bored of doing stupid todo apps and calculators for learning.
If you know any good open source projects that I can contribute to easily that would be awesome.
I live in Bosnia and Herzegovina, it's not a good place to live if you want to pursue an IT career. I don't have any friends that do programming that I can talk to and create programs together. I would love to have a mentor or a colleague to work with me. I've tried learning with other developers, but it didn't work out that well.
I really want to find a open source project that is meaningful to me and is on my skill level. I'm bored of doing stupid todo apps and calculators for learning.
If you know any good open source projects that I can contribute to easily that would be awesome.
Whenever I get similar feelings to this it usually means I’ve been working too much and I’m burning out. After days on a coding binge, code starts to look like spaghetti that I can neither make heads nor tales of. After taking a break and decompressing things start to make sense again. About a year ago, I was working so many hours that I forgot how to program all of a sudden. Taking time off quickly remedied the situation and made me excited to program again. I don’t know you or your situation but it sounds like you’re burned out.
> When I was a beginner I could solve any problem those "coding challenge" websites, but now I simply can't.
Just something to consider - you might be trying to solve harder problems then what you solved easily in the past. Easy problems can be very similar in structure to hard ones - but are much less complex to solve.
I'm sure that if you'll start with easy problems and move on from there this skill will get back to you. Solving coding challenges is a different skill than your day to day programming.
Just something to consider - you might be trying to solve harder problems then what you solved easily in the past. Easy problems can be very similar in structure to hard ones - but are much less complex to solve.
I'm sure that if you'll start with easy problems and move on from there this skill will get back to you. Solving coding challenges is a different skill than your day to day programming.
Do it like any other sport: go back to basics and play in a restricted style.
Go through Knuth AOCP. You don't have to work every problem(nobody really does) but the book is there to point you towards fundamental computing concepts.
Strip down your language in the process. If you're used to something bulky like C++, try hopping over to Go or Lua and see how you like those.
Finally, throw out any abstraction and try coding in a primitive way for a while: use basic loops, arrays, and rarely a function call. Hold off even on defining structures with fields. Doing this will get you in the appropriate mindset for solving real problems, because it leaves no room for burying the design underneath the abstraction - you just apply one algorithm after another and rely on good commenting to know what it does.
Aim to read more code from real projects, open-source ones that people are using. Good code that is in production mostly contains necessary complications. It often doesn't do things in a fancy, code-challenge style or a style that takes a performance optimization because it is aiming only towards surfacing the feature as quickly and reliably as possible. That is a good goal to aim for with any real project.
Go through Knuth AOCP. You don't have to work every problem(nobody really does) but the book is there to point you towards fundamental computing concepts.
Strip down your language in the process. If you're used to something bulky like C++, try hopping over to Go or Lua and see how you like those.
Finally, throw out any abstraction and try coding in a primitive way for a while: use basic loops, arrays, and rarely a function call. Hold off even on defining structures with fields. Doing this will get you in the appropriate mindset for solving real problems, because it leaves no room for burying the design underneath the abstraction - you just apply one algorithm after another and rely on good commenting to know what it does.
Aim to read more code from real projects, open-source ones that people are using. Good code that is in production mostly contains necessary complications. It often doesn't do things in a fancy, code-challenge style or a style that takes a performance optimization because it is aiming only towards surfacing the feature as quickly and reliably as possible. That is a good goal to aim for with any real project.
You are on the verge of finding the coding nirvana, dont stop! To me it seems you're facing ego depletion due to lack of proper practise, like a musician that does not sit down and tune their instrument and practise tempo. The best solution to this would be to find a great mentor, whose well-crafted mental model you could emulate and in the process learn it yourself.
If this is not possible, try to get feedback in other ways. You have to rearrange your mental pathways just like someone who has bad squatting technique. Go out and work in projects, do code reviews. Try to explain a problem youre facing, and how you think you could solve it to someone. Override your instinct to give up when it gets hard and you dont know what to do. Do something else maybe for a while, then come back to the problem. All in all i wish i could guide you in your workplace but such is life. Do something different, clearly the previous methods have not been working. Try to find the things you like and are good at, and then develop your programming identity on top of that.
If this is not possible, try to get feedback in other ways. You have to rearrange your mental pathways just like someone who has bad squatting technique. Go out and work in projects, do code reviews. Try to explain a problem youre facing, and how you think you could solve it to someone. Override your instinct to give up when it gets hard and you dont know what to do. Do something else maybe for a while, then come back to the problem. All in all i wish i could guide you in your workplace but such is life. Do something different, clearly the previous methods have not been working. Try to find the things you like and are good at, and then develop your programming identity on top of that.
Maybe in those 2 years the coding challenges you used to solve became harder, in order to remain challenging?
In any case, 2 years is not enough time to become a good programmer, or a good anything. If you feel you're going backwards, perhaps the simplest explanation is that you have only advanced very slowly, which is normal given the steep learning curve of programming.
Be patient. Keep working at it and the mad coding skillz will come. In the meantime, I hope the following will act as a soothing balm upon your troubled soul :0
Researchers (Bloom (1985), Bryan & Harter (1899), Hayes (1989), Simmon & Chase (1973)) have shown it takes about ten years to develop expertise in any of a wide variety of areas, including chess playing, music composition, telegraph operation, painting, piano playing, swimming, tennis, and research in neuropsychology and topology. The key is deliberative practice: not just doing it again and again, but challenging yourself with a task that is just beyond your current ability, trying it, analyzing your performance while and after doing it, and correcting any mistakes. Then repeat. And repeat again. There appear to be no real shortcuts: even Mozart, who was a musical prodigy at age 4, took 13 more years before he began to produce world-class music. In another genre, the Beatles seemed to burst onto the scene with a string of #1 hits and an appearance on the Ed Sullivan show in 1964. But they had been playing small clubs in Liverpool and Hamburg since 1957, and while they had mass appeal early on, their first great critical success, Sgt. Peppers, was released in 1967.
Teach Yourself Programming in Ten Years, Peter Norvig
https://www.norvig.com/21-days.html
Or, to look at a more prosaic source of the same wisdom:
In any case, 2 years is not enough time to become a good programmer, or a good anything. If you feel you're going backwards, perhaps the simplest explanation is that you have only advanced very slowly, which is normal given the steep learning curve of programming.
Be patient. Keep working at it and the mad coding skillz will come. In the meantime, I hope the following will act as a soothing balm upon your troubled soul :0
Researchers (Bloom (1985), Bryan & Harter (1899), Hayes (1989), Simmon & Chase (1973)) have shown it takes about ten years to develop expertise in any of a wide variety of areas, including chess playing, music composition, telegraph operation, painting, piano playing, swimming, tennis, and research in neuropsychology and topology. The key is deliberative practice: not just doing it again and again, but challenging yourself with a task that is just beyond your current ability, trying it, analyzing your performance while and after doing it, and correcting any mistakes. Then repeat. And repeat again. There appear to be no real shortcuts: even Mozart, who was a musical prodigy at age 4, took 13 more years before he began to produce world-class music. In another genre, the Beatles seemed to burst onto the scene with a string of #1 hits and an appearance on the Ed Sullivan show in 1964. But they had been playing small clubs in Liverpool and Hamburg since 1957, and while they had mass appeal early on, their first great critical success, Sgt. Peppers, was released in 1967.
Teach Yourself Programming in Ten Years, Peter Norvig
https://www.norvig.com/21-days.html
Or, to look at a more prosaic source of the same wisdom:
The Ancient One: How did you get to reattach severed nerves and put a human spine back together bone by bone?
Dr. Stephen Strange: Study and practice, years of it.Programming is weird. The better I get through experience and painful failure, the more I have tool anxiety. It starts with using a package for everything, now I fear updating my database drivers which tend to be the only code outside the standard lib I use. I have way more fear about exceptions and robustness. Every time I learn something hard ish like recursion I get worse for a while trying to use it all over the place. Then you learn the flaws. Now I feel like I spend all my time data modeling and liberally profiling and logging stuff, the code slinging itself barely takes time at all so I forget how much I've learned.
What do you want to achieve? One learns to program by doing. I've never heard of learning to program by watching. No one programs in a vacuum. Programming in general is just a collection of techniques to sustainably build instruction sets to automate hardware. The techniques are as various as the domains they serve. Are you trying to write enterprise banking code? Detect anomalies in satellite imagery? Automate cloud infrastructure for a startup on the cheap? Sequence a genome? Support energy telemetry? Render lifelike images on a consumer desktop computer / gaming console?
Go and do, would be my two cents.
Go and do, would be my two cents.
Try to create products or services instead of trying to solving coding challenges. They are fine until one point. Puzzles can keep getting harder which might be increasing your frustration.
On other hand, when you solve real life problems (they might not need complex algorithms but you've to figure out a lot) the result is huge reward which is not in case of coding challenge. There's another puzzle harder than the one you solved.
Also the impact of product or service or the optimization that you did might save lot of time and money of others while paying your bills at the same time.
On other hand, when you solve real life problems (they might not need complex algorithms but you've to figure out a lot) the result is huge reward which is not in case of coding challenge. There's another puzzle harder than the one you solved.
Also the impact of product or service or the optimization that you did might save lot of time and money of others while paying your bills at the same time.
Hey,
I've also noticed that my skill seems to be deteriorating a bit. I worry that I may have f'd my attention span. So I decided to run an experiment and see how high I can count in my head. Not out loud. Just count until you lose the thread as some other thought barges in.
I find that I only seem able to get to the low thousands.
I also find that I'm tired all the time. This condition seems to have developed slowly over the past year or so. I don't know when exactly and I have yet to find a doctor who can tell me why.
So I guess my question to you is, how high can you count in your head?
I've also noticed that my skill seems to be deteriorating a bit. I worry that I may have f'd my attention span. So I decided to run an experiment and see how high I can count in my head. Not out loud. Just count until you lose the thread as some other thought barges in.
I find that I only seem able to get to the low thousands.
I also find that I'm tired all the time. This condition seems to have developed slowly over the past year or so. I don't know when exactly and I have yet to find a doctor who can tell me why.
So I guess my question to you is, how high can you count in your head?
I am not a doctor but had some tiredness issues and found that low vitamin d or low thyroid could cause such. Other symptoms include dry skin, depression, inability to focus, muscle pain etc.
Low thousands? Is that really worth your time?
Buy post-it notes, go momento and discover that all is well - distraction on details is part of creativity. Self awareness of it is key to directed productivity.
Buy post-it notes, go momento and discover that all is well - distraction on details is part of creativity. Self awareness of it is key to directed productivity.
Wow, my focus is out of control. I started skipping numbers when I was on 50.
I got to 34 then got bored lol. My attention span is wrecked.
Try taking a sleep study.
Perhaps a foundational course in data structures and algorithms would re-ignite your thirst for good engineering. Read a book on the subject or do one of the free courses on Coursera.
It sounds like it could be burnout.
Nevertheless I de-facto recommend you read "The Practice of Programming" by Pike and Kernighan. I would also you recommend learning how to learn (there is a good coursera course on it), and also I would recommend finding a good course on learning to search for things.
The last two things are probably more important that having "good knowledge" -- being able to find the good knowledge, and good sources, and knowing enough to discern bad knowledge from good.
Nevertheless I de-facto recommend you read "The Practice of Programming" by Pike and Kernighan. I would also you recommend learning how to learn (there is a good coursera course on it), and also I would recommend finding a good course on learning to search for things.
The last two things are probably more important that having "good knowledge" -- being able to find the good knowledge, and good sources, and knowing enough to discern bad knowledge from good.
Will do, thanks for the recommendation.
Is it possible that the anger you are experiencing is due to a fear that you have no other skills you can rely upon other than programming? Maybe you feel pressured to only express your creativity and intellect through programming. Worth considering. You're probably only a few small adjustments to your goals away from being happier.
P.S.
If you're putting in the time, you're probably getting better - plus, you are likely a good judge of whether or not you have actually wasted time.
P.S.
If you're putting in the time, you're probably getting better - plus, you are likely a good judge of whether or not you have actually wasted time.
Programming, in my view, is a craft more than anything else. Like blacksmithing or painting. You may learn some specific tricks by watching others but you'll only get good yourself by doing it.
Listen, if you're looking at your code and saying "this is crap", that's good- it means you can now tell crap from quality. So refactor it again and make it better. Fire up the forge and hit the hammer a few more times until it feels right.
Listen, if you're looking at your code and saying "this is crap", that's good- it means you can now tell crap from quality. So refactor it again and make it better. Fire up the forge and hit the hammer a few more times until it feels right.
Pick up a good book and start to do the problems. Examples of good books are Sedgewick, Siena, etc. Stop with all the online videos and blogs.
You could refresh your memories from the time before you started to complicate stuff by reading (or rereading) the marvelous book "code complete"
https://www.amazon.com/Code-Complete-Practical-Handbook-Cons...
https://www.amazon.com/Code-Complete-Practical-Handbook-Cons...
Thanks, will read it.
I have just ordered a copy for myself. I haven't read this book in more than 10 years, but it is the best computer book I have ever read. I have always said, that if I had my own company, then I would place a copy of this book on the table of all new employees. Reading this book should be their first assignment. It is a truly amazing book that anyone, despite experience level, platform of choice, project type and size, will benefit from reading.
You should read it.
You should read it.
Good luck :)
There have been many times when I have felt I was a much better programmer 4 years ago. One advice is to understand a good, sufficiently complex open source code base. Maybe something you use daily and perhaps wanted to add a feature or fix a bug. Chromium, Sqlite, django, etc. If you have access, discussing solutions with peers also helps.
Stop trying so hard? It sounds like you're spinning your wheels and just getting further stuck in a rut. Find another activity, area of study, or topic of interest you can go deep in. The true masters of a given field are known for both depth and breadth. Find something else that sparks your interest that's NOT programming.
Give examples of problems and what you find hard.
The more I code the more I realise how hard it is. 20 years later and I can count the good programmers I know on one hand. Most of them think they are terrible also.
Programming is about delivering something that adds value to your clients customer.
If you do that without the latest sexy over complication that's pricey better than most.
The more I code the more I realise how hard it is. 20 years later and I can count the good programmers I know on one hand. Most of them think they are terrible also.
Programming is about delivering something that adds value to your clients customer.
If you do that without the latest sexy over complication that's pricey better than most.
It's normal. I remember feeling the same way. Remember it takes way more than 2 years to become good at anything. This is a difficult uncharted profession and you are experiencing a transition.
The best thing you can do is to take on a manageable risk and build something. Approach it with an engineering mindset.
The best thing you can do is to take on a manageable risk and build something. Approach it with an engineering mindset.
With about two years of learning you are probably just reaching the stage where you start to understand what you don't know (stage 2 below). Keep at it and you will grow.
Stage 1: Unconscious Incompetence. Stage 2: Conscious Incompetence. Stage 3: Conscious Competence. Stage 4: Unconscious Competence
Stage 1: Unconscious Incompetence. Stage 2: Conscious Incompetence. Stage 3: Conscious Competence. Stage 4: Unconscious Competence
Length of programming means nothing, some people have 1 yr experience 10x over 10 years. You have to continually challenge yourself and build new things. Try building things you use. An editor, your own programming language, a database, servers, games, etc
I find i do much worse work under pressure (real and imagined - as pressure is always imagined)
If there is a deadline I do all I can to remove it.
I do better work without the anxiety and i write cleaner code, add more tests, do more B work.
For me i think it is to do with ownership / control
If there is a deadline I do all I can to remove it.
I do better work without the anxiety and i write cleaner code, add more tests, do more B work.
For me i think it is to do with ownership / control
I prefer deadline driven as I have an objective and date to meet. It makes it easier to push really hard to get it all done by the date as I always work smarter then. Unbounded causes feature creep and process to drift, in my experience.
Can you give an example of what kind of programming challenge or task that you recently had difficulty working on? I think part of your problem is thinking that programming is a mostly monolithic, easily quantifiable kind of skill.
In the first few months of programming I was able to create todo lists apps and simple games, but now I have a hard time structuring everything together and I don't know where to start.
Forget puzzles! Solve a real problem with code. Read only as little as necessary and then build something you care about. Before you know it you have become a programmer.
Simly do what you like. Find some good idea and enjoy doing it as a side project without leaving your current job. Who knows maybe some day it will become a good startup.
I'll respond and try to clean up the issue:
Broadly my guess is that the problem is too much advice on how to program, like being told to put your nose to the grindstone, shoulder to the wheel, and ear to the ground and then work in that position!
First, on how we can be "confident", let's make a few very simple points:
In some subjects, we do have some solid information.
E.g.: (1) If you want to be sure of the Pythagorean theorem, then there are many clear, short, rock solid proofs that will remove all doubt. (2) If you want to know when the next solar eclipse is, then basic physics from Newton's laws can give you an astoundingly accurate answer years into the future. (3) If you want to transmit a billion bytes of data over the Internet, then from coding theory there are some codes that can do really well at error detection and correction.
But in some subjects we don't have such clear, solid answers.
E.g.: (1) I recall very well that in high school I didn't know with much confidence what a girl I was dating thought of me, and I suspect, of course don't know for sure, that I was not nearly the first such boy!! (2) Tough to know what the US Federal Reserve will do to interest rates in 2019. We can't predict interest rates nearly as well as solar eclipses. Instead, interest rate predictions are a definite maybe.
Second, as an example, I'll outline how I became a "confident programmer":
I've been programming for a long time, back to Kemeny-Kurtz Basic, assembler, Fortran IV, Algol 60, PL/I F level, C, .... I skimmed through the first three volumes of Knuth's The Art of Computer Programming, paid close attention to radix sort, heap sort, and AVL trees, and learned a lot of applied math and the associated computing. In six weeks while teaching the business school course in computing at Georgetown University, I designed, wrote, and ran some software to schedule the full, planned fleet at FedEx, pleased the BoD and two experts from BoD Member General Dynamics, "solved the most important problem facing the start of FedEx" (F. Smith, founder, COB, CEO), enabled funding, and saved the company.
My Ph.D. dissertation was in stochastic optimal control with computing, e.g., some algorithms to make the computing faster, from about 64 years down to three minutes.
While working in an AI project at IBM's Watson lab, I cooked up some applied math and algorithms to do better than our AI work. I programmed the algorithms and published my work in Information Sciences.
I also taught computing in the MBA program at Ohio State University, was named Chair of the college computing committee, etc.
And there was more.
I was self taught. E.g., while I was teaching computing at Georgetown and saving FedEx, I'd never had any courses or instruction in computing. Taught courses? Yes. Taken courses? No! I still have had essentially no instruction, and have had no meaningful instruction, in computing.
Still, now I'm deep into my startup: The software is 100,000 lines of typing, about 24,000 programming language statements. I've plugged together my first server, based on an ASUS motherboard, an AMD FX-8350 processor (8 cores, 4.0 GHz standard clock speed), 16 GB of ECC main memory, etc.
Third, during this work, I heard about various lessons on how to be a better programmer. So, sure, I read The Mythical Man-Month, read lots of stuff about the challenges of writing and documenting good code, saw the interest in APL programming, Prolog and logic programming, the roles of block structure, exceptional condition handling, and scope of names in PL/I programming, saw the rush for Ada programming, saw structured programming, saw object oriented software design and programming, read about Backus and functional programming, did a lot in AI rule based programming, of course studied SQL programming (there's some of it in the code of my startup), etc.
Once I was flatly told that since I had done some Fortran programming, my brain "was forever damaged" for programming.
Lesson: There is a LOT of advice on programming. Yes, that advice is maybe more solid than predicting interest rates in 2019 or what women's Paris fashions will be next fall but, IMHO, not much more solid. Or, advice on programming is nowhere nearly as solid as, say, proofs of the Pythagorean theorem or using physics to predict solar eclipses.
In particular, it's possible, and maybe the best way, to do well at programming while essentially ignoring all the advice and just being self taught. Sorry 'bout that: Such a remark violates some politically correct norms, calls into question the importance of a lot of revered, respected, and coveted undergraduate teaching in computer science, and will rub some fur the wrong way. Sorry 'bout that, but I'm trying to respond to the OP.
IMHO, the important and really useful parts of programming remain a simple subject. Here are the high points: We (i) look at requirements, inputs, and outputs, (ii) get a high level design, likely exploiting the principle of divide and conquer, (iii) find needed algorithms, (iv) define storage, (v) write expressions to do the data manipulations, (vi) wrap the expressions in If-Then-Else, (vii) as a case of divide and conquer form those lines of code in functions/subroutines, (viii) handle exceptional conditions, (ix) design the code so that it will be easy enough to test, (x) test the code, (xi) document the code following "Given the code, without documentation only the programmer and God understand it; six months later, only God." So, write the documentation to explain, clearly, all the important thinking in the work.
I'm confident you can do (i) - (xi), and in that case you should be a "confident programmer".
My view is that the most difficult part of programming and the worst bottleneck to progress in computing is working with tools, e.g., object oriented programming classes, APIs (application programmer interfaces), USB (universal serial bus), etc. that way too often are not clearly documented. E.g., yesterday I was struggling with lack of documentation of Vcore, one of the motherboard voltages. What devices use Vcore? What Wattage is needed? What parts of the power supply provide that voltage and Wattage? But no way is poor documentation about tools a programmer is to use the fault of the programmer. In response, one approach for a programmer, a "confident programmer", is to stay close to old tools, known to be solid, and with many good examples of usage and maybe even some good documentation. E.g., for my first server for my startup, I deliberately went with a motherboard with an old BIOS instead of the newer UEFI.
Most of these lessons are much the same as or follow closely from lessons in projects going way back. E.g., the technique of divide and conquer is really old. How old? For that technique and more, the art goes back at least to military campaigns, designing ships to travel the oceans, construction of palaces, churches, and monuments, e.g., the Pyramids back 4000+ years.
So, for the OP: If you got started in programming, then there should be no good reason for you not to be a "confident programmer". Maybe all you need is what was passed out in the classic movie The Wizard of Oz. Or, I hereby confirm on you the title of Confident Programmer First Class with all the honors, rights, and privileges thereunto appertaining. Congratulations, and happy confident, programming.
Broadly my guess is that the problem is too much advice on how to program, like being told to put your nose to the grindstone, shoulder to the wheel, and ear to the ground and then work in that position!
First, on how we can be "confident", let's make a few very simple points:
In some subjects, we do have some solid information.
E.g.: (1) If you want to be sure of the Pythagorean theorem, then there are many clear, short, rock solid proofs that will remove all doubt. (2) If you want to know when the next solar eclipse is, then basic physics from Newton's laws can give you an astoundingly accurate answer years into the future. (3) If you want to transmit a billion bytes of data over the Internet, then from coding theory there are some codes that can do really well at error detection and correction.
But in some subjects we don't have such clear, solid answers.
E.g.: (1) I recall very well that in high school I didn't know with much confidence what a girl I was dating thought of me, and I suspect, of course don't know for sure, that I was not nearly the first such boy!! (2) Tough to know what the US Federal Reserve will do to interest rates in 2019. We can't predict interest rates nearly as well as solar eclipses. Instead, interest rate predictions are a definite maybe.
Second, as an example, I'll outline how I became a "confident programmer":
I've been programming for a long time, back to Kemeny-Kurtz Basic, assembler, Fortran IV, Algol 60, PL/I F level, C, .... I skimmed through the first three volumes of Knuth's The Art of Computer Programming, paid close attention to radix sort, heap sort, and AVL trees, and learned a lot of applied math and the associated computing. In six weeks while teaching the business school course in computing at Georgetown University, I designed, wrote, and ran some software to schedule the full, planned fleet at FedEx, pleased the BoD and two experts from BoD Member General Dynamics, "solved the most important problem facing the start of FedEx" (F. Smith, founder, COB, CEO), enabled funding, and saved the company.
My Ph.D. dissertation was in stochastic optimal control with computing, e.g., some algorithms to make the computing faster, from about 64 years down to three minutes.
While working in an AI project at IBM's Watson lab, I cooked up some applied math and algorithms to do better than our AI work. I programmed the algorithms and published my work in Information Sciences.
I also taught computing in the MBA program at Ohio State University, was named Chair of the college computing committee, etc.
And there was more.
I was self taught. E.g., while I was teaching computing at Georgetown and saving FedEx, I'd never had any courses or instruction in computing. Taught courses? Yes. Taken courses? No! I still have had essentially no instruction, and have had no meaningful instruction, in computing.
Still, now I'm deep into my startup: The software is 100,000 lines of typing, about 24,000 programming language statements. I've plugged together my first server, based on an ASUS motherboard, an AMD FX-8350 processor (8 cores, 4.0 GHz standard clock speed), 16 GB of ECC main memory, etc.
Third, during this work, I heard about various lessons on how to be a better programmer. So, sure, I read The Mythical Man-Month, read lots of stuff about the challenges of writing and documenting good code, saw the interest in APL programming, Prolog and logic programming, the roles of block structure, exceptional condition handling, and scope of names in PL/I programming, saw the rush for Ada programming, saw structured programming, saw object oriented software design and programming, read about Backus and functional programming, did a lot in AI rule based programming, of course studied SQL programming (there's some of it in the code of my startup), etc.
Once I was flatly told that since I had done some Fortran programming, my brain "was forever damaged" for programming.
Lesson: There is a LOT of advice on programming. Yes, that advice is maybe more solid than predicting interest rates in 2019 or what women's Paris fashions will be next fall but, IMHO, not much more solid. Or, advice on programming is nowhere nearly as solid as, say, proofs of the Pythagorean theorem or using physics to predict solar eclipses.
In particular, it's possible, and maybe the best way, to do well at programming while essentially ignoring all the advice and just being self taught. Sorry 'bout that: Such a remark violates some politically correct norms, calls into question the importance of a lot of revered, respected, and coveted undergraduate teaching in computer science, and will rub some fur the wrong way. Sorry 'bout that, but I'm trying to respond to the OP.
IMHO, the important and really useful parts of programming remain a simple subject. Here are the high points: We (i) look at requirements, inputs, and outputs, (ii) get a high level design, likely exploiting the principle of divide and conquer, (iii) find needed algorithms, (iv) define storage, (v) write expressions to do the data manipulations, (vi) wrap the expressions in If-Then-Else, (vii) as a case of divide and conquer form those lines of code in functions/subroutines, (viii) handle exceptional conditions, (ix) design the code so that it will be easy enough to test, (x) test the code, (xi) document the code following "Given the code, without documentation only the programmer and God understand it; six months later, only God." So, write the documentation to explain, clearly, all the important thinking in the work.
I'm confident you can do (i) - (xi), and in that case you should be a "confident programmer".
My view is that the most difficult part of programming and the worst bottleneck to progress in computing is working with tools, e.g., object oriented programming classes, APIs (application programmer interfaces), USB (universal serial bus), etc. that way too often are not clearly documented. E.g., yesterday I was struggling with lack of documentation of Vcore, one of the motherboard voltages. What devices use Vcore? What Wattage is needed? What parts of the power supply provide that voltage and Wattage? But no way is poor documentation about tools a programmer is to use the fault of the programmer. In response, one approach for a programmer, a "confident programmer", is to stay close to old tools, known to be solid, and with many good examples of usage and maybe even some good documentation. E.g., for my first server for my startup, I deliberately went with a motherboard with an old BIOS instead of the newer UEFI.
Most of these lessons are much the same as or follow closely from lessons in projects going way back. E.g., the technique of divide and conquer is really old. How old? For that technique and more, the art goes back at least to military campaigns, designing ships to travel the oceans, construction of palaces, churches, and monuments, e.g., the Pyramids back 4000+ years.
So, for the OP: If you got started in programming, then there should be no good reason for you not to be a "confident programmer". Maybe all you need is what was passed out in the classic movie The Wizard of Oz. Or, I hereby confirm on you the title of Confident Programmer First Class with all the honors, rights, and privileges thereunto appertaining. Congratulations, and happy confident, programming.
Thank you a lot for sharing your story and giving magnificent advice, I will think of this post the next time I write code.
Thank you for "Confident Programmer First Class". I will add it to my resume now. :P
Thank you for "Confident Programmer First Class". I will add it to my resume now. :P
As some have suggested:
Switch to being a producer, not a consumer. Build something. And do it again, and then again.
Switch to being a producer, not a consumer. Build something. And do it again, and then again.
This happened to me after suffering seizure-induced memory loss last January. It was disheartening, but I'm back to normal now. (For reference, a few weeks post-seizure [mid-February], I thought the 2016 Trump/Clinton election was still 6-8 weeks away.)
Read the basics, implement them, understand their tradeoffs, then build cool side projects that require their use instead of worrying about the best way to implement a Red-Black tree.
The basics are tools you use. The projects you build with them dictate which tools will stay fresh in your mind.
If you don't need the tool, remain aware of them, but don't stress over not remembering the low-level details of something you haven't touched in years.
Read the basics, implement them, understand their tradeoffs, then build cool side projects that require their use instead of worrying about the best way to implement a Red-Black tree.
The basics are tools you use. The projects you build with them dictate which tools will stay fresh in your mind.
If you don't need the tool, remain aware of them, but don't stress over not remembering the low-level details of something you haven't touched in years.
have you consider checking your health ? im not kidding, vitamins, brain, etc.
You sound burned out.
I had faced the same problem 4 years back, while working in a job for 4 years where my programming skill was used in very limited manner. I was pretty good during my college time, but due to lack of practice for 4 years, i was feeling almost the same.
The thing i did to overcome was to force my mind to do it or there is nothing else. This thought came to my mind when I started interviewing in other companies. During interviews you are forced to go into survival mode where solving a problem matters a lot. Interview experience pushed me to take each coding assignment like that only. I will put a pomodoro for 25 mins, and will try to solve it. If I can't, i will look at solution and try to implement in next pomodoro. You need to tell your mind, coding/problem solving is something you love so much that you won't do anything else until this gets done. You will definitely get a kick, atleast worked for me.
The thing i did to overcome was to force my mind to do it or there is nothing else. This thought came to my mind when I started interviewing in other companies. During interviews you are forced to go into survival mode where solving a problem matters a lot. Interview experience pushed me to take each coding assignment like that only. I will put a pomodoro for 25 mins, and will try to solve it. If I can't, i will look at solution and try to implement in next pomodoro. You need to tell your mind, coding/problem solving is something you love so much that you won't do anything else until this gets done. You will definitely get a kick, atleast worked for me.
I am literally getting worst at programming. When I was a beginner I could solve any problem those "coding challenge" websites, but now I simply can't. I haven't stopped coding since then, I was doing it every single day and I still got worse. Maybe I am just overcomplicating things when programming.
I feel like the thousands of free (not good quality) tutorials that I watched online are now showing their flaws. I just have piles of trash "programming knowledge" in my head that I don't know how to clean or replace.
How do I relearn programming? Relearn it in a way that I don't have to watch or read tutorials with the stuff I already know. Cuz I seriously can't watch another video of someone explaining what a variable or function is.
Do I just have to go heads first and it will all just "fit in place"? I will finally become a good and confident programmer one day?
I wanted to share this because I don't want someone wasting two years learning programming and get to the state that I am in. :(
If someone had this problem before or has advice to get back on track please reply.