Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How I Became a Better Programmer

jlongster.com

Post reply on HN
Print view View original

91–100 of 125 posts

Re: How I Became a Better Programmer

#91

Post by hinkley »

couchand wrote: post #30
Permagate wrote: post #14

Earlier quoted context omitted.

> I also strongly disagree with the suggestion that you should ignore the form of your code. Code is read many, many times more than it is written, so improvements to your own and your teammates' understanding can pay huge dividends. While he explicitly said to ignore fluffs, he followed it up with `Another way to say this is "use your time wisely"`. So I interpreted it as to just not spend too much time on fluffs, r…

Simply using the term "fluff" to describe the form of code shows a lack of respect that I find deeply troubling. Those that pay little attention to code style, form, names of things, etc. (including those who rely on the tooling to fix it for them) tend to miss other, arguably more critical, things. Sometimes, but not always, this happens because those errors are lost in a soup of poor formatting and copy-paste repet…

I had a coworker come to my desk one day, years ago. "Why did you add all that duplicated code to that file??" Huh? Oh, I didn't 'add' that duplication. I took two long files by two different authors, changed them to use the same white space, variable names, comment style and organization strategy. That's all I did. I didn't have the time at that moment to take the next step.

He came back four hours later and said that he couldn't stand it and he had refactored the code and fixed/written some tests.

Perfect. I learned long ago that there are ways you can start cleaning that will induce (some) others to participate.

He spent hours writing tests while I was working on an adjacent part of the code that had worse bugs in it. The work got done and a big piece of the code (this was a project I supported but didn't maintain) didn't, in the end, have my edit history all over it.

Re: How I Became a Better Programmer

#92

Post by cloverich »

jredwards wrote: post #20
Permagate wrote: post #14

Earlier quoted context omitted.

> I also strongly disagree with the suggestion that you should ignore the form of your code. Code is read many, many times more than it is written, so improvements to your own and your teammates' understanding can pay huge dividends. While he explicitly said to ignore fluffs, he followed it up with `Another way to say this is "use your time wisely"`. So I interpreted it as to just not spend too much time on fluffs, r…

Other people's time is also valuable. Try not to write code that's impossible to read.

I think pure style (e.g. that a linter would catch) and DRY could be treated separately. The former should always be followed. To the latter: I find weak or incorrect abstractions much harder to follow than repetitive code. And I find those much more commonly when implemented early rather than later.

There's definitely a balance, and if you know the type of problem you are solving ahead of time you can probably abstract early. But if you're just kind of feeling around in the dark, which seems to be relatively common in complex business applications (for instance), I much appreciate an implement-test-reflect-refator cycle.

Re: How I Became a Better Programmer

#93

Post by hinkley »

> Even now, though, I continually doubt myself. The point is that this feeling doesn't go away so just try to ignore it,

No. This is the advice you'd expect from someone in their early thirties who has been coding and doing nothing else their whole adult life.

Your doubts should fuel your learning and temper your decisions. They are the voice in the back of your head and you can make it work for you instead of against.

Mastery isn't working harder, it's working smarter. It involves retraining your instincts to match your rational understanding of the domain. You get the shape of a problem and you naturally gravitate toward a reasonable solution without having to intellectualize the whole process first. If challenged, you of course have to walk back your intuition and build a step by step case, not just a rationalization, but that's fine because you've trained for that.

Study something else, anything else. Preferably with a teacher. What you're going to learn about the process of learning (and teaching) will be profound. It will make picking up and putting down new things easier, which will keep you from getting in a rut later.

Source: 40-something who spent his precocious twenties only coding. I learned a hell of a lot but I didn't know everything.

Re: How I Became a Better Programmer

#94

Post by metaphorm »

darkerside wrote: post #86

Regarding the claim that only Scheme implements continuations, aren't coroutines/generators in Python a type of continuation as well?

yes, they absolutely are. the author would probably argue that only scheme natively implements first-class continuations though, which is more specific and a little different.

Re: How I Became a Better Programmer

#95

Post by metaphorm »

SnowingXIV wrote: post #75

Learn C - Just the basics, if you don't already. I think it's valuable to understand why everyone complains about it. When you say just the basics, what are you referring to? Syntax? Pointers? Dealing with garbage? I've got a vague idea about it, but never had to really do anything with it so I feel now is a good time to mess around with it. Great read though, always a pleasure seeing James mentioned (someone that de…

> Syntax?

yes, because so many other languages have copied that syntax in superficial ways. being familiar with C syntax (ugly as it is, way too much punctuation imo) automatically makes you able to comfortably read Java, JavaScript (sort of), PHP, C#, etc.

it's kind of a shame because aesthetically speaking its so full of bad choices, but it is still very influential.

> Pointers?

yes, absolutely this. most memory managed languages don't give you pointers at all and let the GC and objects implementation handle that completely. however, understanding the details of reference, dereference, and memory addressing is good for developing insight into how things are implemented at a lower level and what the performance characteristics of those implementations will be.

> Dealing with garbage?

C is a manual memory management language. Doesn't even have smart pointers or optional GC. To avoid memory leaks you have to be extremely dilligent about error handling and cleaning up/deallocating on every possible program branch. this will really hammer home a few points about rigor that are easy to gloss over in memory managed languages.

however, it's a pain in the butt and I'm really really glad I don't have to do manual memory management on a daily basis. still, learning a bit about this has made me a lot more sensitive to possible memory leaks that turn up even in higher level languages.

Re: How I Became a Better Programmer

#96

Post by metaphorm »

sillysaurus3 wrote: post #54
jondubois wrote: post #52

My advice is that whenever you become confident/comfortable in your current work, that's when you have to change team or company. Whenever it gets easy, it means you have stopped learning. I agree with what was said about tools; it doesn't make you a better programmer to know all the latest ES6 features and frameworks. What makes you a better programmer is your ability to adapt and customize your approach to differen…

My advice is that whenever you become confident/comfortable in your current work, that's when you have to change team or company. Whenever it gets easy, it means you have stopped learning. I agree with what was said about tools; it doesn't make you a better programmer to know all the latest ES6 features and frameworks. It's tough to say. Given a choice between being a JS ninja capable of hammering out http://www.trac…

is that really a good example of highly focused coding skills? it looks like a very standard web site that any web developer familiar with modern frontend tools could hammer out in a week.

I don't see anything there besides some content presentation stuff. Am I missing something more interesting? When I think of "JS ninja" I think of sites with really complicated UI, like multipart forms with lots of validation, or interesting map layer based tools, or browser games or something like that.

Re: How I Became a Better Programmer

#97

Post by metaphorm »

arkadiytehgraet wrote: post #58

Apparently the author still has a long way to go to become somewhat good, given how this link returns 502 on moderate load for a something like a simple blog. I also wonder if this discredits the article itself.

I don't think it discredits the author's coding skills to _not_ being using cloudflare (or similar) on what is otherwise a very low traffic blog. you don't get HN spiked every day.

Re: How I Became a Better Programmer

#98

Post by vdnkh »

hinkley wrote: post #93

> Even now, though, I continually doubt myself. The point is that this feeling doesn't go away so just try to ignore it, No. This is the advice you'd expect from someone in their early thirties who has been coding and doing nothing else their whole adult life. Your doubts should fuel your learning and temper your decisions. They are the voice in the back of your head and you can make it work for you instead of agains…

When you mean studying something else, do you mean something academic or hobby-based? I think having deep hobbies are really beneficial, and with mine I like to take a more "organic" or free-form approach to learning.

Re: How I Became a Better Programmer

#99

Post by couchand »

amelius wrote: post #57
couchand wrote: post #11

There's a lot of value here, but I have to raise concerns about a few things. First, the title: written in the past tense makes it seem like he believes the journey is complete. The article itself doesn't convey that message, fortunately. But I think it's worth noting that a critical skill for a professional is constant education - don't be satisfied that you're already "better", get better every day. I also strongly…

> First, the title: written in the past tense makes it seem like he believes the journey is complete. How should he have formulated the title then? I think it is logically correct.

Anything in the present tense would be preferable. Just a one letter change would be an improvement: "How I Become A Better Programmer". If it's in the past tense, possibly some indication that he's partway along the journey, such as "How I Got to the Level of Programmer I Am Today" (not as punchy, needs editing).

Re: How I Became a Better Programmer

#100

Post by ianbicking »

cname wrote: post #89
BurningFrog wrote: post #31

Earlier quoted context omitted.

The time to clean up the code is when it already does what it should. That is: Make it pretty and readable and DRY once the code works. Until then my code can have several ugly and improvised things I've left for later.

I think a good metric for "advanced/senior programmer" is "writes reasonably clean code from the start". Not perfectly clean, but reasonably well-architected--at least easy to read and change. At a certain point, there's really no good excuse for starting out with a big ball of mud.

This is a reasonable expectation when writing something the developer understands and has experience with, with an architecture that seems self-evident early on. Lots of problems are like this.

But when I see developers with the self-expectation of clean code take on a task where the architecture is not self-evident, where the architecture probably won't be right the first time, then they often freeze up. Or they move their efforts into the abstractions they do understand, instead of the task they are trying to accomplish.

Post reply on HN