Ask HN: Tips to become a great programmer
40 comments
I have three basic tips:
1) Find problems first, then solve them. It sounds obvious, but so many programmers find solutions and then go look for a problem. That's backwards. Problems, then solutions.
2) Test your solutions as much as you can. Does it actually solve the problem? Is it too slow? Is it confusing or cumbersome? Nine times out of ten, it's better to take an extra hour to test something than to rush it through. There are very, very, very few instances in which you legitimately do not have time to test. For all practical purposes, you ALWAYS have time -- you just aren't making it a priority if you don't test. Make it one. It's far more important to deliver solid code that works than it is to be the first one to submit your code.
3) Don't reinvent the wheel. Stand upon the shoulders of giants. Use what others have done and get ahead. There are two major exceptions to this tip, imo: 1) if you're reinventing it as a learning exercise, or b) you are absolutely, positively, 100% convinced you can bring something new to the table.
Also, just for kicks: tabs, not spaces. runs away
1) Find problems first, then solve them. It sounds obvious, but so many programmers find solutions and then go look for a problem. That's backwards. Problems, then solutions.
2) Test your solutions as much as you can. Does it actually solve the problem? Is it too slow? Is it confusing or cumbersome? Nine times out of ten, it's better to take an extra hour to test something than to rush it through. There are very, very, very few instances in which you legitimately do not have time to test. For all practical purposes, you ALWAYS have time -- you just aren't making it a priority if you don't test. Make it one. It's far more important to deliver solid code that works than it is to be the first one to submit your code.
3) Don't reinvent the wheel. Stand upon the shoulders of giants. Use what others have done and get ahead. There are two major exceptions to this tip, imo: 1) if you're reinventing it as a learning exercise, or b) you are absolutely, positively, 100% convinced you can bring something new to the table.
Also, just for kicks: tabs, not spaces. runs away
A few tips every developer should learn.
1) Solve the problem before you write the code.
2) Figure out what data structures to use and the code will follow.
3) Debugging is your fault, you screwed up. The language or the compiler didn't (true 99.999% of the time).
4) The difference between genius and insanity is if the algorithm runs faster.
The biggest general tip is learn data structures. They are the fundamentals, you will always use them, get used to them.
1) Solve the problem before you write the code.
2) Figure out what data structures to use and the code will follow.
3) Debugging is your fault, you screwed up. The language or the compiler didn't (true 99.999% of the time).
4) The difference between genius and insanity is if the algorithm runs faster.
The biggest general tip is learn data structures. They are the fundamentals, you will always use them, get used to them.
> The biggest general tip is learn data structures. They are the fundamentals, you will always use them, get used to them.
Yes. E-R data modelling is worth learning early and well, http://www.aw-bc.com/info/riccardi/database/Riccardi_ch4.PDF
Yes. E-R data modelling is worth learning early and well, http://www.aw-bc.com/info/riccardi/database/Riccardi_ch4.PDF
"1. Solve the problem before you write the code."
Sometimes the problem is difficult or huge (or both) and you don't know how to solve it. By starting to write some exploratory code, like a solution to a small part of the problem that you do understand, you can frequently get ideas about how to solve the bigger problem. Even if you end up ultimately throwing this code away, it could still be a useful learning experience and help you make progress toward understanding the real solution.
Sometimes the problem is difficult or huge (or both) and you don't know how to solve it. By starting to write some exploratory code, like a solution to a small part of the problem that you do understand, you can frequently get ideas about how to solve the bigger problem. Even if you end up ultimately throwing this code away, it could still be a useful learning experience and help you make progress toward understanding the real solution.
"Write it; throw it away; rewrite it." Not always the best solution, but a good voice to have in the mix.
Code Complete: A Practical Handbook for Software Construction is considered one of the language agnostic classics on computer programming. It focuses on higher level concepts as they relate to the process and sequence of writing code. It covers just enough architecture and design to provide context and allow one to think intelligently about it.
[affiliate link] http://www.amazon.com/gp/product/0735619670/ref=as_li_tl?ie=...
[non-affiliate link] http://www.amazon.com/Code-Complete-Practical-Handbook-Const...
[affiliate link] http://www.amazon.com/gp/product/0735619670/ref=as_li_tl?ie=...
[non-affiliate link] http://www.amazon.com/Code-Complete-Practical-Handbook-Const...
I would highly recommend this as well. BUT - don't try to dive too much deeper into code patterns. The last decade has a massive spike in patterns and I can remember a lot of meetings wasted debating patterns.
There's an 80s book with fantastic interviews of programmers before they became business leaders, check out the reviews:
http://www.amazon.com/Programmers-Work-Interviews-Computer-I... & http://www.amazon.com/Programmers-at-Work-Susan-Lammers/dp/0...
Some (all?) interviews free here: http://programmersatwork.wordpress.com/
http://www.amazon.com/Programmers-Work-Interviews-Computer-I... & http://www.amazon.com/Programmers-at-Work-Susan-Lammers/dp/0...
Some (all?) interviews free here: http://programmersatwork.wordpress.com/
There's also a more recent book of interviews with well-known programmers called Coders at Work:
http://codersatwork.com
http://codersatwork.com
+1 a very good book.
Writing too much code can make you a worse programmer.
The real way to get better is to pick an area of study and research the shit out of it, even non-technical aspects if applicable. Go back as far as you can and read every canonical book you can find on the subject. Even if it's outdated information, it will help you see how we arrived where we are now (as long as it's not a purely technical reference).
Read those things until you feel some things click in your head. Then go back and try to write some code.
This might be difficult to do while in school though. I'm sure you're doing a lot of reading already.
The real way to get better is to pick an area of study and research the shit out of it, even non-technical aspects if applicable. Go back as far as you can and read every canonical book you can find on the subject. Even if it's outdated information, it will help you see how we arrived where we are now (as long as it's not a purely technical reference).
Read those things until you feel some things click in your head. Then go back and try to write some code.
This might be difficult to do while in school though. I'm sure you're doing a lot of reading already.
I disagree with this. I read every software engineering book I could get my hands on when I was in school - GoF, Refactoring, SICP, Pragmatic Programmer, XP Explained, Implementation of Functional Programming Languages, TAPL, Basic Category Theory, On Lisp, Art of the Metaobject Protocol, numerous textbooks I wasn't assigned. As a result, my code ended up overcomplicated, with a bunch of cool algorithms, a lot of OO design, a nice smattering of patterns...but relatively few useful solutions for people. It was only when I was like "Alright, I've already read every book anyone I've met has ever mentioned...I need to push through and actually finish a project now" that my skills started shooting up.
Write code first. Write code until your programs collapse under their own weight. Then go out and read what the masters have written. You'll understand it much better when you have personally faced the problems that they were facing.
Write code first. Write code until your programs collapse under their own weight. Then go out and read what the masters have written. You'll understand it much better when you have personally faced the problems that they were facing.
I was having a similar discussion with a friend of mine.
When I was a teenager, I wrote small C projects, then I discovered the world of OS development and set myself to write a minimal operating system from scratch. It was an amazing experience, with a lot of head-scratching, hours spent debugging weird hardware issues, reading other people's code and just churning out badly engineered (but working) code.
Now, 10 years after, after playing with Haskell, OCaml, Scheme, learning about best practices, variants, typeclasses, static vs dynamic typing and data structures, every time I set myself to write something more than 100 lines I just get stuck: which language is best for the job? How should I refactor this to be more clear and concise?
My programming life definitely got worse (as a C/Python programmer) after I discovered variants and the Option/Either monads.
As I said to him, ignorance is bliss.
When I was a teenager, I wrote small C projects, then I discovered the world of OS development and set myself to write a minimal operating system from scratch. It was an amazing experience, with a lot of head-scratching, hours spent debugging weird hardware issues, reading other people's code and just churning out badly engineered (but working) code.
Now, 10 years after, after playing with Haskell, OCaml, Scheme, learning about best practices, variants, typeclasses, static vs dynamic typing and data structures, every time I set myself to write something more than 100 lines I just get stuck: which language is best for the job? How should I refactor this to be more clear and concise?
My programming life definitely got worse (as a C/Python programmer) after I discovered variants and the Option/Either monads.
As I said to him, ignorance is bliss.
It does get better - write a lot of code with the new language features and you'll get a sense when they're not useful, or how you can apply them to more mundane languages. You can define a decorator in Python to do Maybe monads, for example:
def maybe(decorated):
def worker(*args):
if any(arg is None for arg in args):
return None
return decorated(*args)
# Standard decorator machinery
return worker
But that's not what the post you replied to said to do.
The post said to pick one area, research all of the shit right out of it, e.g., focus. Your list (and I assume it's abbreviated) is the opposite of that.
I agree you need to code (and a lot). I disagree (vehemently) that you need to fuck, then un-fuck, your code in order to progress.
The post said to pick one area, research all of the shit right out of it, e.g., focus. Your list (and I assume it's abbreviated) is the opposite of that.
I agree you need to code (and a lot). I disagree (vehemently) that you need to fuck, then un-fuck, your code in order to progress.
Focus helps, of course. But my list (and other reading material..yes, it was abbreviated) was actually pretty focused - it specializes in programming language theory and implementation, particularly for functional programming languages.
The problem with reading a lot before coding is that you learn the knowledge ("what to do") without learning the wisdom ("when to do it). Even if you specialize in one area, there's a large body of practical knowledge that people do unconsciously when they're working on a problem, but don't think to write down in a book. Or if they do write it down in a book, you won't understand the context for it until you've been in several situaions where their advice has both worked and not worked. When I was studying this stuff in college, I read multiple books on each topic, it "clicked", I knew when to use each technique - but I didn't know when not to. As a result, my designs tended to be jam-packed with features. It takes experience to realize "Oh, metaclasses are really handy in this one situation...but most of the time, you are better off banning them because the cost in understanding your code is greater than the code simplification they give you."
The problem with reading a lot before coding is that you learn the knowledge ("what to do") without learning the wisdom ("when to do it). Even if you specialize in one area, there's a large body of practical knowledge that people do unconsciously when they're working on a problem, but don't think to write down in a book. Or if they do write it down in a book, you won't understand the context for it until you've been in several situaions where their advice has both worked and not worked. When I was studying this stuff in college, I read multiple books on each topic, it "clicked", I knew when to use each technique - but I didn't know when not to. As a result, my designs tended to be jam-packed with features. It takes experience to realize "Oh, metaclasses are really handy in this one situation...but most of the time, you are better off banning them because the cost in understanding your code is greater than the code simplification they give you."
Don't give up learning.
Learn from your mistakes and failures.
Don't be afraid to make a mistake or fail.
Fixing your mistakes and failures is called debugging, learn how to debug.
Communication is 80% of the job, develop your social and people skills to avoid acting like a jerk, treat others with empathy and compassion.
Learn to work with others on a team, don't be a Lone Ranger, sometimes you get stuck and need another pair of eyes to look things over.
Learn how to manage stress better so you can get a good night's sleep. If you cannot get 8 hours of sleep at night, consider seeking help for that. If your stress levels make it so you cannot even get sleep, something is wrong.
Learn from your mistakes and failures.
Don't be afraid to make a mistake or fail.
Fixing your mistakes and failures is called debugging, learn how to debug.
Communication is 80% of the job, develop your social and people skills to avoid acting like a jerk, treat others with empathy and compassion.
Learn to work with others on a team, don't be a Lone Ranger, sometimes you get stuck and need another pair of eyes to look things over.
Learn how to manage stress better so you can get a good night's sleep. If you cannot get 8 hours of sleep at night, consider seeking help for that. If your stress levels make it so you cannot even get sleep, something is wrong.
I would recommend writing apps as much as you can from "scratch" (do use standard libraries for your language, but shy away from big libraries or platforms that aren't a core part of the language). I think this helps ensure you're not just wiring things together but are truly creating something out of thin air and thinking algorithmically. That experience will serve you well when one day you're confident in piecing together ready-made libraries, platforms, and your own code to create your projects.
From my experience there are a few things that I try to keep in mind while working.
1) Keep your code as simple as possible. In the real world if you can call your code complex or clever it is probably bad.
2) When presented with a problem don't immediately reach for the keyboard. Take some time to make sure you understand the actual problem that you are solving.
3) Good enough and working beats perfect and not working. Perfectionists make horrible co-workers and usually end up with horrible code.
1) Keep your code as simple as possible. In the real world if you can call your code complex or clever it is probably bad.
2) When presented with a problem don't immediately reach for the keyboard. Take some time to make sure you understand the actual problem that you are solving.
3) Good enough and working beats perfect and not working. Perfectionists make horrible co-workers and usually end up with horrible code.
In the real world if you can call your code complex or clever it is probably bad.
This principle is often called "kill your darlings".
http://c2.com/cgi/wiki?KillYourDarlings
This principle is often called "kill your darlings".
http://c2.com/cgi/wiki?KillYourDarlings
There's a great presentation on the topic by Angelina Fabbro www.youtube.com/watch?v=v0TFmdO4ZP0 with matching slides http://afabbro.github.io/jsconf2013 . The title says javascript, but it's really a platform agnostic guide that sketches out what mastery looks like and lays out actionable steps to get there.
Seriously, listen to the talk and/or check out the slides.
But 90% won't, so here's her actionable steps:
Seriously, listen to the talk and/or check out the slides.
But 90% won't, so here's her actionable steps:
1. Ask why obsessively
2. Teach and/or speak at an event
3. Work through a suggested curriculum*
4. Experiment recklessly (the code doesn't care)
5. Have opinions
6. Seek mentorship
7. Program a lot
8. Stop fucking programming sometimes.
9. Write Javascript* a lot
10. Write in another language for a while
11. Think like a programmer when afk
12. Know what feedback is good feedback and reject everything else.
13. Break free of imposter syndrome
13 is easier said than done. Maybe this is just me trying to rationalize, but it feels like if you don't have some level of impostor syndrome, it's almost hubris.
I think the trick is to shed your imposter syndrome, but remain humble. You can be confident and humble at the same time. It can come with accurate self-assesment. Keeping your weakness in mind helps a lot.
You've taken the most IMPORTANT step already - You care about programming. Keep this up. Join forums, read books on programming, follow programming blogs.
Next, do not fixate on languages and frameworks. Aspire to make this irrelevant to you. Great developers often can work with multiple languages and frameworks.
Be prepared and excited to learn every single day of your life as a programmer. The best programmers I know are always learning. This is an investment you will need to make regardless of work pressures and schedules. I've seen far too many developers have their skills atrophy because they've not invested in improving.
Use the Rubber Duck debugging model - http://en.wikipedia.org/wiki/Rubber_duck_debugging.
One simple way to do this is that whenever you get stuck, go to stackoverflow and start explaining the problem.
I have found my solution innumerable number of times by forcing myself to explain it to someone else with no context. It makes you confront your assumptions and understanding.
Next, do not fixate on languages and frameworks. Aspire to make this irrelevant to you. Great developers often can work with multiple languages and frameworks.
Be prepared and excited to learn every single day of your life as a programmer. The best programmers I know are always learning. This is an investment you will need to make regardless of work pressures and schedules. I've seen far too many developers have their skills atrophy because they've not invested in improving.
Use the Rubber Duck debugging model - http://en.wikipedia.org/wiki/Rubber_duck_debugging.
One simple way to do this is that whenever you get stuck, go to stackoverflow and start explaining the problem.
I have found my solution innumerable number of times by forcing myself to explain it to someone else with no context. It makes you confront your assumptions and understanding.
+1 Rubber Duck
You need someone more experienced than you who can read your code (and look at your architecture). They will say things you don't want to hear. Listen anyway, and try to pick up where they're coming from.
Programming well requires judgment and taste. It takes years to develop these well (at least, it did for me), but it helps to have people who have more than you explain why they wouldn't have made the same choices you did.
(Note well: Not everyone with more experience than you has better judgment. You need someone with good coding judgment, not just someone older.)
Programming well requires judgment and taste. It takes years to develop these well (at least, it did for me), but it helps to have people who have more than you explain why they wouldn't have made the same choices you did.
(Note well: Not everyone with more experience than you has better judgment. You need someone with good coding judgment, not just someone older.)
The books that I think are must-read are "The Pragmatic Programmer" and "Apprenticeship Patterns". I learned a lot from them.
I'm aware you expect some quick tips from HN though. Have a look at my old blog posts that summarize these books. While 3 years old and written in Polish, Google translated it very well. Direct links to the translations: https://bit.ly/1oZiidn and https://bit.ly/1w8ELhY.
I'm aware you expect some quick tips from HN though. Have a look at my old blog posts that summarize these books. While 3 years old and written in Polish, Google translated it very well. Direct links to the translations: https://bit.ly/1oZiidn and https://bit.ly/1w8ELhY.
Honestly, the best thing you can do is make friends with people who have already graduated college.
Not even software engineers necessarily. And I don't mean acquaintances. I mean friends. They can give you real perspective - no piece of generic advice I can give you will come even close to the advice of someone who both knows you well and has been in your shoes. Having perspective is better than any specific programming skill you could ever learn.
Not even software engineers necessarily. And I don't mean acquaintances. I mean friends. They can give you real perspective - no piece of generic advice I can give you will come even close to the advice of someone who both knows you well and has been in your shoes. Having perspective is better than any specific programming skill you could ever learn.
Don't obsess with premature optimisation. Get your code working then start profiling if you think it should run faster/use less memory when under load.
“Thankfully, perseverance is a great substitute for talent.”
― Steve Martin
― Steve Martin
1. It's ok to feel you're a bit more good that other people but never let yourself feel you know better than everyone.
2. Respect your teammates and always be open to learn from them
3. Programming is not typing or coding. It's about coming up with solutions. So, before you start typing code use your brain.
4. Don't run after a hype. Think before you use any tool or technique.
5. Enjoy !!
Think about the problem and solution before you think about code.
Don't just start writting code, Write the algos/steps, dataflow.
Experience.
A lot of being a good programmer doesn't have to do with technical skills.
Take a compilers course. This was required at my school and I figured it would be boring (I mostly likely the theory classes). I was wrong! Writing a compiler really made me understand what they do. I had seen a lot of people who were trying to appease the compiler. Instead, the compiler is now my slave.
A lot of being a good programmer doesn't have to do with technical skills.
Take a compilers course. This was required at my school and I figured it would be boring (I mostly likely the theory classes). I was wrong! Writing a compiler really made me understand what they do. I had seen a lot of people who were trying to appease the compiler. Instead, the compiler is now my slave.
Go here: http://c2.com/cgi/wiki and read everything.
- always try to solve nasty problems (e.g. https://www.hackerrank.com/)
- read this: http://www.paulgraham.com/gba.html
- read this: http://www.paulgraham.com/gba.html
I would say purposeful learning. That is, exploring avenues of programming where you know your skills would be stretched, become better to the point that you are able to either:
(a) produce and deliver something usable.
or
(b) make things better
(a) produce and deliver something usable.
or
(b) make things better
Use source control. Even for 1 person throw away projects.
As much as we’ve emphasized that hours of practice are necessary for success, you need to have balance, meaning a life outside of the game. Many pro players started as teens, but now have grown up and have families of their own. Friendships and family are vastly important for your mental well-being, so don’t shut people out in favor of holing yourself up to play at all hours.
try http://www.cs.bell-labs.com/cm/cs/pearls/ (Programming pearls)
Also if you are into Java/C++, Effective Java/C++ are def worth reading.
Also if you are into Java/C++, Effective Java/C++ are def worth reading.
I'm coming up on my sophomore year in college as a cs major. I feel as though I understand a good bit more than majority of other people in my classes but I still feel as if I'm only an "okay" programmer. I understand it takes writing a lot of code to get better but other than that are there any tips you might be willing to share to help me on my journey to becoming a great developer?