[HN Gopher] Ask HN: What helped you get good at programming?
___________________________________________________________________
Ask HN: What helped you get good at programming?
What are the most important things that have helped you get as good
at programming as you are today?
Author : robalni
Score : 38 points
Date : 2022-05-02 21:06 UTC (1 hours ago)
| mikequinlan wrote:
| In order of impact:
|
| 1. Programming. Lots and lots and lots and lots of programming.
|
| 2. Having my code reviewed by people with strong opinions, some
| of which I agreed with and some I didn't.
|
| 3. Reading, and practising what I read (number 1 above).
| skydhash wrote:
| A lot of reading. I started programming when I was in high
| school, but procrastinated hard on making project. So I read a
| lot of books about C, assembler, network, security, operating
| systems, algorithms. When I started doing projects in university,
| everything I did made sense conceptually. To this day, when I'm
| doing project, I can go left and right on the slider [Abstraction
| ----Implementation], very easily, from the architecture of the
| whole systems, and the gritty details of the particular language
| and algorithms.
| beefjerkins wrote:
| - A LOT of practice. One of that parts of becoming a good
| programmer is learning about potential pitfalls and bad
| practices; what better way is there of avoiding these than by
| making these mistakes yourself and learning from it.
|
| - Studying and researching best practices for not just your
| current language or paradigm, but others as well. If you've got
| experience with Java, look into other paradigms than OOP such as
| Haskell / Elm that focus on Functional Programming. This can lead
| to learning about new ideas of programming in general, which is a
| good thing as it exposes you to more tools that you can use.
|
| - Making your own things. Find areas in your life that could use
| some automation, or perhaps use programming as a creative outlet;
| the more tools you make, the more practice and experience you'll
| get which leads to the first point I made.
|
| - Cringe at your old code. If it's really that bad, it's likely
| you've come a long way as a developer, which is good! Reflect
| from time to time about _why_ you originally wrote code a certain
| way, and think about how you would approach the same problem now
| with more experience.
| LeftHandPath wrote:
| My first real experience programming was when I was 19, before
| ever having a class, teaching myself PHP/JS on the job to write
| custom wordpress themes. I started writing inefficient spaghetti
| code and progressed into writing object-oriented, then started
| looking at performance. The performance aspect was definitely the
| deepest rabbit hole.
|
| I would say that I learned more doing that than I have getting a
| CS degree at my state school (aside from writing performant code,
| which classes have helped with). But it is mostly because I
| viewed getting good as a way to escape from some bad
| circumstances at the time - every word I didn't know was a low-
| hanging fruit waiting to be picked. I did a lot of reading, and I
| practiced at home in my spare time as well.
|
| I got really good at front-end stuff and learned how to use the
| terminal so that I could host and manage our company's websites
| on a digital ocean droplet (running centos). I learned a lot on
| the linux terminal - writing bash / shell scripts, managing
| configurations, etc. Improved speed a lot by configuring
| apache... then again by redoing things in Nginx on the next site,
| which I've preferred since.
|
| Since I've gone back to school, going overboard on programming
| labs has also helped a lot.
| gdulli wrote:
| Time and self awareness.
| joeld42 wrote:
| programming a lot
| irrational wrote:
| Anything you persist in doing you will get better at. So, I got
| better at programming by programming. So what if your code sucks
| today. Keep programming and it will get better.
| mdp2021 wrote:
| I presume, a large number of problems to solve through coding and
| a passion to solve them...
| notreallyserio wrote:
| I've been at it for a bit over 20 years and I haven't figured out
| how to get good at it. I do OK, though, because I learned it's
| often more important to ship than perfect[0], and rewriting isn't
| so bad because the second time is usually better than the first.
|
| 0: I choose not to work anywhere that sells critical
| infrastructure, medicine, or anything else where imperfections
| could jeopardize someone's life.
| mmcgaha wrote:
| I have no clue who you are but from reading your answer, I bet
| your coworkers love working with you and I bet you write nice
| maintainable code. You are probably better than you think.
| notreallyserio wrote:
| That's very kind of you to say.
| conradfr wrote:
| Supporting & evolving my own code/projects for years.
| 2OEH8eoCRo0 wrote:
| SICP has timeless advice that I follow: Write programs.
| jdrek1 wrote:
| Practice, lots of practice. Doesn't really matter what kind of
| program you write as long as you write code. Can be assignments
| from your university, can be online puzzles like advent of code,
| can be a program that sends you reminders to kiss your wife, can
| be the 984397594th minecraft clone, or whatever else you want.
| Basically if you have a problem that can be solved by coding, do
| that.
| mikewarot wrote:
| Access to a programming environment with good discoverability,
| and reasonable examples of working code that I could tweak. Back
| when I learned, examples abounded in print material, and print
| documentation tended towards complete. (Especially Turbo Pascal's
| manual)
|
| This made it possible to experiment, and get started. Since then
| it's a matter of repetition, deliberate practice, and raw
| experience over time.
|
| Everything has scaled towards good thanks to Moore's law, the
| Internet, and GIT. You can't overstate how much better git makes
| things.
| _pdp_ wrote:
| starting my own company and doing everything by myself
| jcranmer wrote:
| I don't believe I can prioritize these between more or less
| important things, but this is the set of things that I usually
| credit:
|
| * Programming competitions. The main utility I got out of this
| wasn't learning obscure data structures or algorithms (which tend
| to often not be very relevant), but rather the experience in
| coming up with corner cases that might break my own code, and how
| to write and debug code _without_ sitting in front of the
| computer. I guess in short it 's the ability to separate the
| algorithm from the implementation and track down failures to one
| or the other.
|
| * Going to school and getting a CS degree. Learning in general is
| useful, but I believe that the structure of a full CS degree is
| generally better than picking things up ad-hoc, especially in
| guiding you towards areas you wouldn't otherwise think to learn
| about (e.g., I wouldn't have picked up information visualization
| on my own).
|
| * Seek out and learn as much as you can in general. You never
| know when randomly learning some topic in some distaff field
| might come in useful; one time, I happened to discover (while
| looking up information on ptrace in a debugger-like side-project
| I was working on at the time) that Linux supported hardware
| watchpoints via perf... and a few days later, we had to resort to
| that to track down a bug that wouldn't reproduce in gdb.
|
| * Peruse other projects for how they do stuff. Part of the above,
| but you'll pick up on "huh, that's an interesting thing to do" as
| you learn about how they work. If you're curious about how
| something works, just open up the source code to see how it
| works. At the very least, doing so frequently will give you a
| good sense of how to quickly find stuff in large, unfamiliar
| projects, which is apparently not as common a skill as I take it
| to be.
| recursivedoubts wrote:
| programming
| laerus wrote:
| * reading other people's code
|
| * studying algorithms
|
| * experimenting with different solutions
|
| * learning paradigms, methodologies and best practices
|
| * striving for simplicity
|
| * being curious about how things work
|
| * systems thinking
| MrFishy wrote:
| I had a really good mentor for many years. He was my manager
| starting back when I was in high school, and he was always
| working with us to improve our code. He recommended good books
| and articles, put in place systems of formal code reviews that
| emphasized egoless programming, so we could review, learn about,
| and improve our code without feeling threatened. He helped me
| think about the code development process and how to be constantly
| improving it.
|
| He helped me establish many good habits that helped me to grow
| throughout the years. More than 3 decades later we are still good
| friends.
| betwixthewires wrote:
| I wouldn't say I'm a top notch programmer by any means, but one
| thing ironically that made be better is to take a step back for a
| while and _stop_ programming and try to learn, read and
| understand things better. This doesn 't work unless you've been
| programming for a bit and have some hands on the basics, but it
| does help to break bad habits.
|
| Stick with standards and conventions, even if they seem stupid.
| Just do them. Four spaces in python, that sort of thing. Pretend
| they're rules of the language, pretend that not following them
| will break your program.
|
| Try to understand data types and structures, they're vastly more
| important than programming. Knowing how to write code, syntax,
| libraries only helps you if you understand the data you're
| manipulating, what you want to do with it, and how it is best
| structured for your purpose. You're better off knowing about data
| structures and not knowing a single programming language than the
| opposite.
|
| Finally, build things, solve problems. If you want to do
| something, do it. Don't worry about if you're good enough.
| itsdwit wrote:
| its gonna sound crazy but... practice.
|
| i made toy apps and widgets. chrome extensions. took on a bit of
| client work.
|
| read some books.
|
| stay up all night and hack on projects for a few years while
| people are sleeping and youll get some where.
|
| never had a sideporject or 'startup' that actually made money,
| but thye taught me the skills i have now that are paying the
| bills, and i pretty much have my pick of jobs at this point.
|
| but also suffer from extreme impostor syndrome and try and use
| that to fill my (perceived) gaps
| lr4444lr wrote:
| Use an IDE that lets you follow stack traces into library source
| code easily. You learn a lot from going down the rabbit hole...
| ... when you have time to do it.
| timoteostewart wrote:
| 1. Having a passion project that made it easy for me to sustain
| lots of hours of coding as I strove to complete the project.
|
| 2. Reading widely in the coding literature, from personal blogs
| to engineering blogs to O'Reilly (etc.) books, to "philosophy"
| stuff like Bentley's Programming Pearls
|
| 3. Regular LeetCode. Not grinding exactly, but disciplined
| practice of solving specific, short challenges.
|
| 4. Browsing OOP (other people's programs) on github and such.
|
| I'm curious to see what others post!
| notsrg wrote:
| Getting an internship at a company with solid engineering
| culture.
| mediocregopher wrote:
| - A lot of practice, which stemmed from a lot of fooling around
| and abandoned side-projects. I would deliberately start projects
| which were way over my head, with no intention of even getting
| something working, just to see how far I could get before getting
| bored.
|
| - Learning new languages which had vastly different paradigms
| than the ones I was used to. Java to Perl to Javascript to PHP to
| Erlang to Clojure to Go to... Over time you learn patterns from
| one place you can bring to another, and learn patterns which
| exist in most places which you'd rather didn't.
|
| - Lots of experience in the actual workforce, building things
| people (supposedly) wanted. There are aspects of programming
| which people spin their wheels on which really don't matter in
| the long run, and conversely there are aspects which go ignored
| but are very important. Working on real, rubber-to-the-road
| projects gives you perspective on what actually matters.
|
| - Being a daily archlinux user (I don't use any non-archlinux OS
| on any machine I own). Yes, it's hard. Yes, it's an incredibly
| good use of your time to figure out. Once you're comfortable in
| arch, every other Unix-like OS (ie, most of them that you'll ever
| probably work with) will feel familiar.
| shaftoe444 wrote:
| Avoiding taking sides in religious wars and understanding there
| are no solutions, only tradeoffs.
| andrewstuart wrote:
| Writing lots and lots and lots of code.
|
| Being really interested and motivated to write my own projects.
|
| Learning everything I possibly could about every topic I found
| interesting relating to computing ans software.
|
| Focusing my effort on a small selection of technologies.
|
| Making the decision to be able to build an end to end application
| on my own.
| efortis wrote:
| I was able to code much larger projects after watching this Uncle
| Bob's Live Refactoring video:
|
| https://web.archive.org/web/20150905163826/https://www.youtu...
|
| BTW, I think sometimes is ok to have inline code with a comment
| of what the extracted function name would have been.
|
| ---
|
| Also, by coding using his TPP helped me gain confidence on
| figuring out complex algorithms. For example, he explains how
| writing a sort algorithm went from bubble sort to quick sort (I
| think) by following the TPP.
| https://en.wikipedia.org/wiki/Transformation_Priority_Premis...
|
| ---
|
| Lastly, as I have a few projects that I can't even run dev on
| them, because their deps are too outdated, I try to keep deps at
| a minimum. e.g. I have a custom minifyCSS that minifies ~85%
| compared to other minifiers, but it's super simple in comparison.
|
| https://github.com/uxtely/js-utils/blob/main/minifyCSS.js
| rektide wrote:
| Dive deeper. A huge amount of programmers bounce out, throw up
| their hands when something isnt working as expected. Go look at
| the souce of the libraries you are using. Learn tools like strace
| or dtrace. For god sake get good at your debugger.
|
| In programming, everything is about mindfulness, perspective,
| awareness. The willingness & ability to go deeper, to dig for
| truth is the ultimate superpower. The docs dont help, your
| mentors dont help: Seymore Papert was correct. You have to mine
| your own truth, develop your own internal models for what is
| going on, how things are happening, and you need endless
| boundless ability to dive further in, to chase real genuine truth
| yourself. The ability to develop your own mental model of how you
| think things work, and your ability to probe & validate & make
| inquisitions into each little step: that scientific minded
| exploration makes all the magic happen.
|
| Also, get good at promises & async. How things happen over time
| has gotten more complex in modernity. You need to understand & be
| able to internalize/visualize the timeline of execution, in a way
| we didnt used to demand.of programmers. Learn the tools, think
| about causality.
| ltbarcly3 wrote:
| Came to say basically this.
|
| Whenever something doesn't work the way you believe it should
| have, whenever you see something that does not make sense, that
| is your understanding at odds with reality. Something doesn't
| work the way you think it does! Every time you don't get to the
| bottom of why it doesn't work the way you think it should work
| you are continuing to be a little worse than you might have
| been.
|
| Accumulating moments like this over time adds up to the
| difference between being a great programmer and being complete
| crap. It's the difference between someone who overhears two
| people talking about a problem and says "Did you check that the
| locale is not set to iso8859?" and blows their minds that you
| could debug the problem they have spent 2 days working on in 5
| seconds and the person who tells people "oh, yea, sometimes our
| app just crashes, it's something about text encoding but if you
| just open the file and save it as utf8 then you can manually
| fix the broken characters after you import it"
| ryneandal wrote:
| Still trying to figure out how to get good at programming.
| PaulDavisThe1st wrote:
| A mentor who wouldn't give me answers.
|
| When I needed to make SunOS give me tty key stroke input 1
| character at a time, he refused to tell me what he already knew
| and just pointed me at some "areas to look into". Knowing about
| kernel tty drivers and terminals and line buffering didn't make
| me a better programmer, but it didn't hurt. Knowing my way around
| a variety of different documentation at many different levels of
| the systems I was working on helped make me a better programmer,
| and my mentor refusing to just answer my questions was a major
| factor in that. It also forced me to understand much more of the
| systems I was working on, rather than just how to use some piece
| of convenient API.
| don-code wrote:
| I'm curious if you've ultimately found your mentor's behavior
| to be a net positive, or net negative, in your career.
|
| One of the engineers under me often expresses his discontent
| that I won't give him answers, either. I think he's more than
| able to get to those answers on his own, and that the value
| he'll derive from learning how to learn is vastly greater than
| the value of being able to complete his work faster. On the
| other hand, he's given me the feedback that the method is
| excessively socratic at best, and flat-out frustrating at
| worst.
| rg111 wrote:
| I am not sure that I am good at programming. I am certainly not
| as good as the HN-type second generation SV kids who started
| programming at four.
|
| Given that, I do work at a lucrative position doing cutting-edge
| work.
|
| What made me _get_ programming was- _getting hired_. I was so-so
| before.
|
| When I got hired, the work was so challenging and the situation
| was so unforogiving, I _had to_ grow. I had no other way. I
| learned new stuff, wrote code that inspired me, and was really
| "impossible" by me a few months ago. Sometimes, a few weeks ago.
|
| What made me and and keep making me better than before is Hacker
| News and peers.
|
| I want to get as good (from the first paragraph); grow as a
| programmer, grow as an overall problem-solver and thinker.
|
| I keep learning new paradigms, new applications, gaining new
| knowledge, and growing as a person.
|
| So the most important thing would be community. Before HN,
| Reddit. Now, Twitter and Discord, too.
|
| I get to know so many new perspective, so many new resources to
| follow, books to read, stuff to generally know. I barely have
| time to breathe.
|
| I also made some genuine, long-term friends through this process.
|
| So, community would be the utmost important things.
|
| I was born in a middle-of-nowhere small town, and community and
| internet are the ones that made me who I am today.
|
| I am not much, but definitely levels above what I was a decade
| ago.
|
| Edit: It would be incomplete if I did not mention high-quality
| teachers teaching for free through MOOCs, YT playlists, etc. And
| internet pirates, too. Having quick access to any book you might
| want is very important. (I do spend a lot on books, but piracy is
| what makes me spend that money so that authors get what they
| deserve).
| marginalia_nu wrote:
| I've just been programming a lot since I was about 10 years old.
| Persist in doing anything for 25 years of your life and odds are
| you'll get decent at it.
|
| I've never deliberately practiced or anything like that, just
| built stuff that I wanted to build.
| DIVx0 wrote:
| I was never good at practicing for practice sake but I also know
| of the value of "doing the work" to get better at a skill.
|
| So, I become a better programmer when I'm actively working on
| something. I no longer contribute code on a regular basis at my
| day job so to stay sharp I've started creating little utility
| programs for personal use.
|
| I've also started finding hobbies that incorporate some
| programming, generative art, robotics, etc.
|
| tldr; find ways to incorporate programming into everyday life,
| practice by building things that are actually useful to you.
| ncmncm wrote:
| The single most important concept separating a good from a bad
| programmer is the concept of the _invariant_. Good code maintains
| (or anyway restores) invariants, bad code doesn 't.
|
| It is very easy to miss this because invariants are often not
| written down, and you have to discover them.
|
| Related are preconditions and postconditions. Function A
| establishes postconditions that satisfy the following function
| B's preconditions.
|
| Your goal maximizing merit of code is to ensure invariants,
| preconditions, and postconditions may be stated as simply as
| possible; and keep them satisfied.
| omega3 wrote:
| ncmncm wrote:
| What?
| adalu wrote:
| It uses complicated words to express literally nothing at
| all.
| ncmncm wrote:
| If you don't understand it, say that.
| mikewarot wrote:
| What do _you_ mean by invariant? Clearly, the word has special
| meaning for you, but it is defined as never changing. That
| definition is not consistent with your emphasis.
| ncmncm wrote:
| An invariant is a predicate expression about the state of
| computation, typically about values in variables affected by
| code, but may involve control flow.
|
| An invariant is maintained at entry into and exit from a
| function. What happens inside the function is usually nobody
| else's business. You can violate it for a reason, there, if
| you make sure to restore it before returning.
|
| The role of invariants is much like that of conserved
| quantities in physics. Things can get very complicated, but
| energy and momentum conservation mean the amount of chaos is
| strictly limited.
|
| If they are kept as simple as possible, the code can be more
| easily understood, and has less scope for bugs.
| hobs wrote:
| getting a job where I couldn't shirk programming duties and being
| forced to program every day for at least a year to meet deadlines
___________________________________________________________________
(page generated 2022-05-02 23:01 UTC)