How to become good at programming?

I’m a self taught programmer, I feel inadequate most of the times and I’ve been wondering what makes people good at programming. There are times I feel lost in programming discussions especially when the experts talk about edge case, performance etc, I wonder when I will use a language to experience or encounter these edge cases and how they are able to determine these cases. How do I become as smart as these programming experts. I want to take my programming skills to another level. I’m currently studying elixir and I need advise on how to be a good if not great programmer.

4 Likes

You code. There is no magic. The more you code the better you are in programming.

14 Likes

@kodepett great question. I assume you are going to get a mix of answers and different approaches on how to take on this life long project. Here are some things to think about:

  • As others will most likely point out, you need to start trying to program as much as possible. This is more of a time spent thing. No magic, need to put in time (as @mudasobwa said). Check Exercism as a starting point.
  • as time passes and you are coding, I’d try to not do it as a hobby. This means getting a job somewhere where you have some type of responsibility regarding the code you write. This is fantastic because even though you will know how to program, you will most likely never get real feedback on a non-trivial problem you solve. There are technical and social benefits you get from working with others.
  • Unfortunately, code can be somewhat of a static product. You see a “snapshot” of a product, the end result. It is a picture, not a movie. Here is the great thing: we have tools that can let us see the “video”, in fact, they are videos! We have excellent, excellent material from (in my opinion) one of the very best and diligent programmers out there, for free, for us to check out: Twitch . Even though some people can say the approaches can be dated (Elixir evolves at a fast pace and a new way of solving the problem now exists), or less than ideal (maybe Jose himself would go back and say: “maybe this is not the best approach”), or whatever else people may say about those videos, I think they are priceless. The reason I like those videos is that you get to see the bigger picture, you get more context of just a final static product. Maybe we can how someone refactors code. Maybe we can see that the final implementation is NOT the last one. It’s great.
  • I think you should immerse yourself in the environment as much as possible. Follow people on Twitter, read hackernews, join the mailing lists, the weekly newsletters, the Slack.
  • You can watch talks/videos from the Conferences as well. ElixirConf, ElixirConfEU are examples that should be searched.
  • There are books on certain subjects. There are also specific courses that are interesting and add value.
  • I’d follow projects on Gihub that you find interesting. I’d watch how other programmers interact through issues, etc.

You’ll most likely not do all of the above. But, that’s the journey, at least you can choose/are aware of some options. I tried to give as much insight as I could. This is a big project and think we should be clear about it, that’s the kindest thing to do. It is a very rewarding experience though. I’ve met awesome folks so far in my journey. I also like that you asked. Good work asking for feedback. :slight_smile:

Hope this helps and that you become the very best programmer you can be.

PS: Side note, @josevalim I don’t think the videos should be priceless by the way. I’ll actually go sub or do whatever Twitch allows me to contribute to your efforts right now. People learn a lot from those videos, I know I learned a ton in the ones I was able to watch. It doesn’t need to be a prepared video. Or a video lesson. Or follow a script. That’s actually not what I like about livestreaming code sessions and I think it ends up being a deterrent. Streamers think they need to prepare for it, and never get to doing it. This is not a talk, not a presentation you need to prepare. I want the unedited, the day to day. But maybe that’s just me and I’m a small part of the overall market.

With that said, streaming can probably be a way to monetize open source work. This can be a fairly hot topic, you can refer to hackernews threads about it. I’m in the camp that thinks any contribution is more than it existed before and is an incentive for folks that do it. If anything, just the educational value of the videos is worth so much.

As usual thanks for the hard work Jose, :heart: .

9 Likes

Listen to experts but don’t overestimate them. Just because someone knows a lot about a given subject a you often transpose this into a belief that they know everything. Concider the causality that when an expert talk about a subject they talk because they are the expert. Knowing a does not have to mean that he/she also know a lot about b,c and d.
I would say that it is most likely that he/she is the person in the group who happened to make some mistakes in this matter at one point or another and thus got to know what the problem actually means.

This is the no-magic you get from writing code and (importantly) exposing it to real life.

4 Likes

This probably won’t be the type of answer you’re looking for, but I’ll give my 2 cents here anyway. First, I think it’s important to know why you want to be a better programmer. This may seem to be a silly question, but I think it’s crucial. A lot of people are chasing some idea just because everybody else is doing it. I understand that improving ourselves is natural, and it feels good, but everything has its cost. The more time you will invest in the programming, the less time you’ll have for other activities. And to be a good programmer, I think you need to be a balanced person with interests in social life, sport, culture, etc. So I suggest you go for quality, not quantity. Find the reason why you want to be a better programmer. To solve some specific problem or to develop some specific project? If yes, then you already know what you need to know to solve it. If it’s just for the sake of improvement, then it’s very difficult to improve yourself consistently, because there’s no benchmark. In my experience, I gained most knowledge when doing some non trivial real life project. And also when I stepped outside of my comfort zone and tried something that was quite challenging at first. But then, when you split the problem into smaller ones, and start step by step, you realize that everything is possible.
And I really agree with @otuv - it’s easy to fall into the bias he’s mentioning. So do not feel inadequate, it’s really hard to compare who’s a better programmer. For example, I see programming as a hobby and as a tool to have a good time and to earn enough money for my lifestyle. Do not fall into the rat race of competition and enjoy what you’re doing right now.

3 Likes

What a great question for this forum, I bet you would find a ton of answers on quora or wherever google leads you if you googled exactly this question, but I really like reading other peoples take on the topic, especially in a smaller community! Everyone can give their 2 cents, and it’s never gonna be a “wrong answer.” Here is my take on it:

I am a “certified” programmer, I went through 4 and maybe a half semesters of computer science at university in germany, before going the more hands-on-less theory path in germany (“IT specialist, specializing in Application development”) and about 7 years of professional experience. I used to feel what you described, being “inadequate” and less knowledgable in theoretical discussions, so I used to be a little obsessed with “becoming a good programmer.” You know what they say about when you enter your 30s, you kind of settle down and realize some things are not as important as you thought they were when you were 20, this is definitely one of those things. Being “A good programmer” can mean so many things, but all of them come down to you personally.

The first question you should ask yourself is, what exactly makes you feel “inferior” to those other people you think are “better at programming” than you. If it is knowledge about - lets say - performant code, then this is a field you can look into in whatever programming language you prefer (since you are posting here, I assume it is Elixir). You can look up talks, books, blog posts and start doing your own benchmarks, you can start proof of concept projects with different approaches, and backed by what you learned from your journey, chime in to those conversations: “Actually, that might all be true, but I tried different approaches and the overhead on X only becomes viable after Y amount of Blabbaquats”.
I hereby give you a guarantee, this will not make you feel like you have finally become good at programming though, because other people will know more than you in other fields. You will probably just become a very annoying person.

So, to contradict myself, the first question you should ask yourself is “what do I want to be good at?”
IT, or Computer Science, is a huge field - and there is no expert on everything. All the people writing blog posts, giving talks or even developing their own language (and I hope Jose will back me up on this) are good at what they are doing, but they don’t know everything, because NO ONE does. As @pdgonzalez872 said, go to Jose’s twitch and watch him live code, or watch this video of Matz - creator of Ruby - doing the game of life exercise at Ruby Kaigi 2018. You will notice they make mistakes, or not take the best approach to the problem right away (or at all) - even in “their own language” - because we are all humans and (once again) no one knows everything.
On a side note, a huge shout-out to everyone who puts out videos of themselves live coding, because that made me realize that you do not have to be perfect in everything you do, you just have to be good at “something” to be acknowledged as a being good at programming :slight_smile:

Maybe a good approach to improving is to look at what you have done so far, pin point something you want to improve, and dive in! Being good at programming does not mean you know everything - in fact some of those people you consider “better” might be worse in certain areas than you!

Being good at programming can mean so many things, just look at how many different great talks are out there on youtube or other platforms, most of them don"t even have a single line of code in their presentation!

Here are some anecdotes from my daily live as a programmer:

  • I work with people with various levels of experience, some of them have more years of coding experience and at least a bachelors degree in CS under their belt than I do, but my most productive conversations come from talking to a guy who worked for us part time for a year, and about 6 months fulltime after graduating from a bootcamp, having only a little coding experience from his degree in Bio Engineering. I feel like we connect in how we think about code and architecture, and he often finds the questions that make me go “holy crap, you are right, I might have to rethink my take on this topic.” Not because he knows more about programming, not because he has more experience than me, not because he knows some fancy words I don’t understand - only because he can follow my trail of thoughts and find the bump on the trail I could not see, because I have been doing it like that for a few years or months or I haven’t thought about it that way until now.

  • We are currently working on a huge e-commerce project in our company, and one of the decisions I made early in the project was having a module that dispatches messages to different platform-handlers (think amazon, ebay, shopify, …), that module does nothing but look at what platforms the message should go to and invoke all the handlers. But instead of directly calling those handlers, it uses a dispatch module for every single platform, that then invokes the function with the correct arguments (or starts processes where applicable). When I explained that concept to a newly hired coworker, she asked “why doesn’t the first module invoke the function directly? Shouldn’t they just implement it for the same arguments anyways?” (pretty good usecase for a behaviour… maybe…) and I realized the whole concept was straight bullshit and my decision was straight out wrong. An innocent question made me rethink almost a year of development in that direction. There is a little more stuff to consider, but I realized it was really hard to reason about the code just by having to explain our thought process to a person disconnected to what we already have.

  • When we first implemented a GraphQL API for a service, we decided to use a certain convention. A guy freshly out of bootcamp with no experience whatsoever asked if we could use another convention, because what we were going for made it harder to consume for react-apollo. I over ruled him back then and just recently acknowledged he was right all along and we are currently re-writing things. I don’t regret that decision for various reasons, but he was better at programming in that situation than I was, despite not even knowing the big picture or implementation details and having years worth of experience less than me and the other people who made that decission.

All these things brings you to your second question “where can I get feedback to whatever I want to get better in?” It depends on what you are trying to accomplish, but open source projects are a great way of improving (getting a job in programming being the next best thing, but maybe you are not in the position to start working professionally or are already a professional right now).
Step 1: Find a library you like, dive into the source code and issues - sometimes you may find a library to already be very good and nothing for you to contribute, that’s ok. Just keep looking for opportunities. On github http://you can look for good first issues, or help wanted tags
Step 2: Get involved in some way. you can even start with writing an issue if you have a problem in a library you are using (writing issues that gives the maintainers a good idea of where to start is actually not that easy). Try to fix the issue with a PR. Don’t try to solve everything at once, focus on a small thing and be aware that maintainers are people with jobs and limited amount of time, so don’t expect a response for at least a week, but also don’t be afraid to ping the maintainers after a reasonable waiting time.
Step 3: Always ask questions or re-explain any kind of feedback in your own words. I can’t stress this enough: If you think a suggestion doesn’t make sense or another idea might be better, put it out there and wait for feedback! If you think you understand the suggestion, try to find a different way of putting it. A lot of the times just trying to find different words will get you to a point where something doesn’t make sense anymore.
Step 4: Rinse and repeat. Some of your PRs will be rejected, other you will have to heavily modify, and some will get merged without feedback. No matter what, always ask for feedback, even if it was merged - sometimes the maintainers think it’s good enough, but would have done things different.

Getting involved into open source projects will also improve your understanding of how certain libraries work (and make you more proficient in using them), and you can pick up ideas of how to tackle different problems in different ways. I am pretty sure it will also help improving or backing up your own conception of what good code looks like, because some code bases are simply easier to maintain and contribute to than others. Try to really think about why some code is easy or hard to understand, and what could be done better (might lead to your next PR!). I am not the biggest open source contributor, in fact I don’t think I spend more than 1 hour/week in open source projects over all, but even this small amount has been a huge contribution to my overall knowlegd.

Here is your TLDR, being good at programming can mean many things, maybe it means you ask the right questions, maybe it means you know a lot about architecture in certain contexts, maybe it means you know a lot about X-theory or language, maybe it means you know a lot about utilizing a language or are really fast in cranking out features in a framework, or maybe you are the guy who can bring theoretical discussions back to the problem at hand! Pick whatever fits your personality, don’t be afraid of asking questions and put yourself out there.

EDIT: I made some edits, because I was really excited about this question and made some grammar mistakes. But here is an afterthought: no matter what happens, the more time you spend in the industry, you will realize that you become a better programmer every hour you spend thinking of or actually doing programming. A programmers age is not measured in actual years spent living, but in years spent doing or thinking about the craft. A developer who has spent 10 years at the same company is way, way, way more valuable to that company than a developer who has spent 10 years doing things. The guy who was hopping jobs (lets call them Tylor) might know more about a lot of thing than the guy who spent his 10 years at the same company (lets call them Jade, and the company ACME), Tylor will have to start his journey at ACME at 0 because Jade knows way more about the codebase and how things might or might not integrate with it than Tylor. Jade is better at programming for ACME than Tylor, even though Tylor might have more knowledge overall. Keep that in mind :wink:

EDIT 2: @Fl4m3Ph03n1x in this forum is a good example of “keep asking questions”, if you go through their post history, there are some posts in there that raise very specific questions about how to apply certain “givens” to code - take everything with a grain of salt since they have some very strong opinions and (imo) sometimes stick to certain details in some general advice way too much, but it’s a good guideline of how to ask questions in a meaningful way and start discussions about programming paradigms with real examples.

6 Likes

Another data point: Things I Don’t Know as of 2018

The awareness of what can be known grows with knowledge.

2 Likes

Great example of what I tried to explain! Knowing things will only make you realize how much you do not know. There is no shame in admitting you don’t know about things, only in pretending you do.

If someone throws things at you you don’t know about, ask them about it! They will either be able to explain it to you, meaning you become officially smorter (sic), or they can’t usually meaning they were just throwing around big words and don’t understand the topic very well either.

That right there is a very important thing for beginners and less experienced programmers to know. That’s why I’m not a fan of live on the spot coding interviews. To me coding is like sketching out ideas and refining them over time.

Have in mind that everyone is self-taught at some point, you can’t stop learning with everything you learn at school or university and expect to be a professional developer. You become a good programmer by coding, making mistakes, and spending so much time and patience, sometimes is stressful, but Software Engineering is such a huge topic.

Let’s say you focus on Web development, which is also a huge topic per se. You can’t master every aspect of it, you can’t even master only the front-end part; HTML, CSS, JavaScript, UX, A11Y, frameworks, libraries… not to mention good skills with tools for design that some startups ask for, they don’t ask for designers, instead they assume you know how to build the entire front-end and how to design a logo, anyways, so much stuff to learn. But that’s not all! You also need familiarity with your day-to-day tools for development; Bash commands, Git, Editor / IDE…

So the journey to become a professional developer is too long and you’ll earn that experience along the way. I feel that I’m constantly learning new things every day I spend coding.

Side note: I understand that startups or medium enterprises are not Google or Microsoft to pay hundreds of engineers for each task, but asking for expertise in a huge topic like this is such intimidating for newcomers, and overwhelming for developers, also 10 years of experience required, heh.

As all people, I have my own flaws, one of them is probably searching for the holy grail of the universal truth - a set of rules that can be applied to all cases in all programming languages, the silver bullet to the “it depends” meme answer.

This is where my first advice for anyone wishing to become a good programmer starts: Understand why the “it depends” meme answer is so prevallent and understand that very very few rules are universal to programming. Even principles we take for granted ( SOLID comes to mind ) are not universal when you trully understand them.

On the flip side, I feel honored someone mentioned me as an example to follow. There are many things I could write here, but I will try to keep it short. Good programmers share a few orthogonal skills:

  1. They are good team members
  2. They are humble
  3. They know the downsides of the tools they use (as well as the benefits)
  4. They are keen on learning

The first 3 are more or less obvious. Programming is mainly a team effort (lone wolfs only go so far) being humble means you have an open mind to new ideas and concepts even when they seem odd at first and knowing the tools you use makes good professionals.

Story time

But it is the last point I want to focus on. Learning. Technology is ever evolving. If we want to not become obsolete, so must we.

Many years ago, while I was still studying, the crisis hit Portugal like a fat lady hits a chocolate cake. It wasn’t pretty. Some of my friends could not afford the university’s public meals for 2.95 euros (included a soup, water, main plate, desert and bread). Some of them searched the leftover for scraps, while I helped them. The university had public microwaves, so most people could heat their rice and pasta (the cheapest meals you could make at home) but the queue to use them stretched for hundreds of meters.

It was common to see homeless people in the cafeteria too, asking for food. People from nearby universties joined also.

Some of my friends didn’t ask for food, but they had to go onto huge debts with the bank. This was all in a public, state funded university.

During all this chaos and famine, I always wondered - “I understand their families lost their jobs because of the crisis, but why can’t they find new ones?” This was a dumb question.

You can’t ask a man late in his 40s or 50s, whose whole life was a single job to change over night because the market crashed. Some of these people were even programmers who failed to keep up.

So, my best advice, for being a good programmer, is to always learn, always improve yourself. What;s the best way of doing it? There is no single answer, but one way I recommend it is to surround yourself with people better than you - and this forum is a great place where that happens. I mean, Jose Valim, the creator of the language is often active here. You can’t beat that if you are learning Elixir :stuck_out_tongue:

Conclusion

Read books, adapt, learn from mistakes. Never stop. Programming evolves continuously, and if you wanna be good at it, so must you.

1 Like

I might have a slightly different perspective than the others. I think being good vs bad programmer doesn’t depend on the volume of code you’ve written. I think it’s all about your problem-solving skills - your ability to truly understand the problem at hand, not superficially, but deeply, and in broader context. And then come up with a solution that is simple, but robust at the same time, that survives the test of time, that really solves the problem without introducing a whole bunch of new ones.

Of course, practice helps tremendously, but I’ve seen developers with 20 years of experience that suck in the above, and I’ve seen juniors with 2 years of experience, who had their mindset right, and really cared about thinking their solutions through - thus I’d call them “better” programmers at that point.

I’ve seen a great talk recently that partially touches on this topic, by Rich Hickey, the author of Clojure. Well worth your time, especially the initial 10 minutes https://www.youtube.com/watch?v=f84n5oFoZBc

3 Likes

First I’d recommend to drop the belief that there’s a linear bad to great programmer dimension. It’s totally subjective and multifaceted and comparing to others usually makes unhappy.

Apart from that: try to interpret this feeling of being inadequate differently. It’s not what you perceive but how you give meaning to this feeling. Working as a programmer for some years means that you have to learn a lot new things, technology is evolving so fast. And in the beginning of learning something new it’s totally normal that you feel stupid (at least that’s true for me).

When you have gone through the cycle of feeling stupid, learning, understanding and mastering some piece of technology you get more confident that you can do it again.

Maybe you can find the openness in the feeling of being inadequate? The emptier the cup, the more you can pour into it.

It was said a lot about the “how” to become good at programming. I’d recommend to aim to produce software that’s useful for you and for others. This will motivate you to become better and you focus on what actually matters. You can write perfect software that nobody uses - what’s the value there to be a great programmer?

3 Likes

There’s pretty good advice in this thread already. I want to add a book recommendation:

https://www.amazon.com/Talent-Code-Greatness-Born-Grown/dp/055380684X

This book is about all sorts of industries and how people within them grow their skills. I reckon you’ll enjoy it.

2 Likes

thank you for the recommendation, @radar , here’s another one on this topic.
Not specifically for programmers but it also applies to programming:

https://www.amazon.com/Turning-Pro-Inner-Power-Create/dp/1936891034/ref=sr_1_1

All great answers there! I want to add my two cents no how to accelerate the learning process.
a) Apply the scientific method as often as possible; e.g.
Problem statement: “I feel inadequate”. Brainstorm various ideas:
Hypothesis 1: “Maybe it is just impostor syndrome, and I am perfectly adequate?”
Hypothesis 2: “I don’t know enough about measuring performance and big “O” notation to understand the conversation.”
Hypothesis 3: “I don’t have a good enough mental model of the problem to see all the edge cases.”

Try to disprove them, and if that is not possible, you can consider dealing with the problems one by one by ordering them from most painful to least painful.

b) Look for ways to get feedback and to get it as fast as possible Principle of immediate feedback In programming, the most immediate feedback you get is pair programming. If you can’t pair program - make sure you get code reviews.

I can assure you: if you have the growth-mindset (which you proved you have by posting that question), you can quickly become better than programmers after university that slowed down learning.

1 Like

One thing to keep in mind is that most of these experts are employed by large companies that by their nature work on challenging problems. Most developers will not have to tackle those types of challenges in everyday corporate environments or client work.

So it’s not really a good idea to measure your adequateness against those developers who specialize on the kinds of things you mention here.

What you might want to do instead is work on your architecture skills. I leave you with this timeless blog post by Bram Cohen, wherein he says: “What truly separates the great programmers from the journeyman programmers is architecture.”

https://bramcohen.livejournal.com/4563.html

In my experience a good programmer thinks along with designers / business analists testers etc. Read through designs, discuss your findings, make designs clear for testers en look after testability of your work (which does not mean stuff your codebase with unit tests or use tdd! BDD / TDD criticized).
Futhermore (Turing award winner Leslie Lamport writing):

https://archive.li/2zZKy#selection-293.0-305.209

1 Like

A “truly great” programmer has to deal with this when there is business value. When there is no design / documentation redesign and rewrite.