[HN Gopher] Ask HN: How did you become better at programming?
___________________________________________________________________
Ask HN: How did you become better at programming?
I've found that the difference between me and great programmers
I've come across in person or online is that they have extreme
mental fortitude, get unstuck on their own, and pick up new things
with breeze. Whereas, I find myself going for almost academic
perfection (i.e read all docs first) / mastery. Really
procrastinate hard when I hit the wall and just hope for things to
click. And then just get sleepy when I do start reading code. This
means if I'm in my space I'm super productive, but anytime I come
across something I don't have an expert level knowledge I come to
complete halt. It took me lot of self introspection to realize
this, so if there are other pitfalls that you have come across let
me know, I might have them too.
Author : techsin101
Score : 17 points
Date : 2022-10-10 19:45 UTC (3 hours ago)
| brailsafe wrote:
| I got better by doing the opposite of what you do, and find
| reading a lot of anything before trying it to be a complete waste
| of time. Unless it's a different way of explaining or building on
| something you're already familiar with. I've read numerous books
| on various languages and frameworks, but they've only been useful
| if I've been incrementally trying the code as I go. Documentation
| is basically pointless to read unless I needed it, and if someone
| interrogated me on the method signature for some api, I'd
| probably laugh. I used to think reading counted as learning, but
| it doesn't, and coming to that realization helped me learn a
| little more efficiently.
|
| Other than that, like others have said, reading and poking at a
| lot of code, diguring out how to get something accepted in a big
| legacy open source project would help tremendously, and is
| something I recommend to anyone serious about starting a career
| in programming.
|
| Also, ya having the humility to accept you're not as good as you
| might think is pretty pivotal. A few years ago I basically just
| started accepting that I'm only as good as some measure (that I
| accept as a valid measure) says I am, but my nebulous opinion of
| my own skill isn't as valuable. Could be commit count, could be
| code clarity, could be PR reviews, time to completion of a task,
| whatever. Pick some measure you agree with that would be
| relevant, and aim to reduce the variability in hitting a mark.
| Think about what 'good' means in the context that you want to be
| good in, and build a mental model of that
| GoToRO wrote:
| Do your own projects start to finish.
|
| At my job I have yet to do the same thing twice. It's hard to get
| any momentum like this. Maybe your situation is the same and by
| great programmers you mean people that do the same thing over and
| over.
| arkj wrote:
| Few common attributes I've seen in some of the master programmers
| I've had the privilege to work with,
|
| * write lots and lots of code as beginner till some programs live
| in the muscle memory of your fingers
|
| * humility, be easy on yourself; no one makes it in the first
| jump
|
| * find better programs and copy but never paste, as a beginner
| always key-in your programs
|
| * keep a count of the lines you write and the time you take to
| write (reach 100k lines, this is to motivate yourself)
|
| * make programming habit
|
| * seek better programmers and study their code
|
| * always go from code to theory
|
| >>Whereas, I find myself going for almost academic perfection
| (i.e read all docs first) / mastery.
|
| I suffered from the same problem. The key for me was to say to
| myself, it's ok to write non-perfect programs, it's ok to fail,
| in fact it's a must to fail, humility, humility, humility is the
| key virtue for a true master programmer.
| givemeethekeys wrote:
| By building things on my own for myself.
|
| I first built a simple thing. But it was buggy. I learned about
| debugging. Then I wanted to add features to it. But the code was
| ugly. So I learned how to refactor. Then I learned about modules
| to separate things out better.
|
| Then I started breaking up bigger features into smaller features
| and planning my implementation - sometimes in a notebook. So,
| white boarding was now easy.
|
| I'd then write the pseudo code as comments first. For obvious
| things, I'd delete the comments as I replaced them with actual
| code. For less obvious things, I'd leave the comment in-place.
|
| I also became proficient enough that I could write code for
| whatever I was thinking without needing to constantly look up
| syntax. This made me fearless during pair programming.
|
| I also found myself solving problems that more senior engineers
| talk about when they talk about battle wounds. This was awesome
| because, as soon as I talked about my (fairly simple, really)
| projects, it made the interviewers happy. I've received at least
| two jobs this way.
|
| One big takeaway for me from doing this has been that simple code
| is far nicer to work with and return to than clever code. If your
| code is so simple that even a freshman in college can understand
| it, then thats a good thing!
| contingencies wrote:
| Write down your requirements before you start ( _README.md_ ).
|
| Always write documentation.
|
| For nontrivial projects, iterate your design on paper before
| writing it in code. Write down why you chose a particular design
| against other candidates (eg. buy vs build) as part of your
| documentation. Use CI/CD and automate testing. Document test
| results. Use an RCS/VCS.
|
| _You 're not going to come up with a simple design through any
| kind of coding techniques or any kind of programming language
| concepts. Simplicity has to be achieved above the code level
| before you get to the point which you worry about how you
| actually implement this thing in code._ - Leslie Lamport
|
| _You 're not going to find the best algorithm in terms of
| computational complexity by coding._ - Leslie Lamport
| bob1029 wrote:
| > And then just get sleepy when I do start reading code.
|
| Could it be that the code you are looking at is solving a problem
| that is entirely uncompelling to you?
|
| In my estimation, I got better at programming by trying to solve
| challenging, real-world problems rather than by laser-focusing on
| specific blocks of code or documentation.
|
| Most of my time these days isn't even writing code. It's thinking
| about how to solve the problem abstractly. If you are trying to
| solve some problem in your head, it _really_ helps if you find
| parts of it exciting or enjoyable.
|
| You can very quickly spot a developer who is not interested in
| their problem domain. They are typically off in some devops
| Narnia constructing a matrix of new problems that _are_
| interesting to hide inside of.
| smackeyacky wrote:
| Don't just fix errors, read the warnings from the compiler,
| understand what they mean and aim for a warning free compile.
| You'll improve rapidly and understand your build system.
| raydiatian wrote:
| > they have extreme mental fortitude, get unstuck on their own,
| and pick up new things with breeze
|
| Then have extreme mental fortitude. That sounds like a choice,
| not an intrinsic attribute.
|
| > Whereas, I find myself going for almost academic perfection
| (i.e read all docs first) / mastery.
|
| It sounds like you're answering your own questions here.
| techsin101 wrote:
| I do the later so I don't get stuck, i.e. if I have mastery
| over language/framework/etc then I'll not get stuck, because
| when I do get stuck my stress goes to cloud 9 and rapidly start
| losing hope. Spend days alternating between procrastinating and
| trying things which feels like putting hands on sizzling pan.
| But "the PROS" I've seen encounter bigger problems and move
| past them in a day or two, without going through entire cycle
| of despair.
| raydiatian wrote:
| How long have you been in tech if you don't mind my asking?
| I've found that (surprise) confidence is a function of
| experience. The kids that started early (age 8 to 13) always
| seemed to have a leg up on the rest of us, but it's because
| they've got a solid 5-10 years "experience" (YMMV in terms of
| quality of course).
|
| If you're still junior in your career, just pay attention. If
| you're getting senior level but you're not getting enough
| work, start doing more personal projects that require you to
| "own" the whole thing from end to end.
| techsin101 wrote:
| about 7 years
| raydiatian wrote:
| Does that include education (uni/boot camp)? Because
| honestly I think unless you went to a school in a tech
| hub city, they didn't teach you everything you need to
| know about CS.
|
| Have you read the seminal literature (the thing they
| didn't teach you in ugrad)? Gang of Four OOP design
| patterns, Patterns of enterprise architecture?
|
| You might ask your employer for a subscription to
| O'reilly books online.
| jareds wrote:
| I've been doing this for over ten years. Experience doesn't
| guarantee you'll be a great or even good programmer, but it sure
| helps especially if you're in environments where you will be
| pushed to take on more responsibilities and have mentorship.
| techsin101 wrote:
| I won't say I'm pushed, but rather I get put a knife to throat,
| each time that has happened it has chipped away at my passion
| for programming in general. Now that I think of coding then the
| emotions that come up are negative. When I was a beginner
| emotions were positive and exhilarating, like I couldn't wait
| to wake up tomorrow and try this new thing. I believe it's all
| thanks "being pushed". I hate managers who think like this.
| danielEM wrote:
| Write code, a lot of it, even if it is useless :)
| bamboozled wrote:
| Working on good open source projects and reading the code.
|
| What's a good open source project, that requires some research
| but I look for projects that are:
|
| * Popular.
|
| * Haven't a lot of open issues.
|
| * Maye you need a certain level of proficiency to realize what
| good code looks like, but I think you'll know it when you see it,
| because good code is readable.
| xsmasher wrote:
| At one point I became very active in a web forum related to a
| language I was using (Objective-C). I tried to help as many
| people as possible. I learned a lot during that year because I
| was getting experience from other people's bugs instead of just
| from the bugs I was creating :)
|
| Re: getting unstuck, see:
| https://news.ycombinator.com/item?id=32735905#32741746
| bravetraveler wrote:
| There's no replacement for practice. I wrestle with the same
| problem; what's helped me is finding things to work on I'm
| interested in.
|
| Say I want to brush up on C again. I'm not going to go reading
| books about it. 80% of it's going to be going over conventions
| I'm already familiar with.
|
| Instead, I'll think about something I want to write with it...
| then dive in. Referring to manuals where necessary.
|
| This being something I want in the end helps me push through the
| uncertainty, and not living in the documentation tests my memory
| while keeping my eyes from glazing over
|
| Eventually it's less of a conscious effort to do things. The idea
| spawns the 'how' effortlessly
|
| Keep in mind I burned myself out on programming/development. It's
| important to know when to sit it down and come back, too.
|
| The closest I get anymore is DevOps, writing pseudocode in a
| higher level language that does the grunt work for me
| jbirer wrote:
| Working on my psychological issues. I was too much of a
| perfectionist and had anger issues, now I can just let go and
| have fun writing code instead of worrying, that's how I got
| better.
___________________________________________________________________
(page generated 2022-10-10 23:02 UTC)