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

11–20 of 125 posts

Re: How I Became a Better Programmer

#11

Post by couchand »

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 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.

In particular, the advice to "not worry about" DRY and duplicate freely reveals a common misunderstanding. DRY shouldn't be taken literally, it is a recognition that repetition is evidence of some greater underlying truth. By duplicating freely rather than thoughtfully avoiding duplication, you're just creating opportunities for bugs.

Re: How I Became a Better Programmer

#12

Post by pm »

fiatjaf wrote: post #9
nsfmc wrote: post #6

Earlier quoted context omitted.

i don't see the contradiction. he's not asking for people to star his repo and it's not unreasonable to offer this advice if you perceive harmful cults of personality developing in a community. besides, lots of people just star things for lots of different reasons, bookmarking, giving props or ???.

"or ???", what does that mean? I didn't point a contradiction, just noted that he has fans that idolize him. The contradiction is theirs.

Having an audience doesn't mean having a cult of personality.

Re: How I Became a Better Programmer

#13

Post by Bahamut »

Not sure I agree with a lot of those recommendations - the number one recommendation I have is to challenge yourself as much as possible, whether it is with picking up algorithms, or learning new things such as the workings of a compiler. Other aspects include challenging yourself to be more efficient in your workflow, such as running through your thought process faster, decrease iteration time due to absorbing prior lessons, etc. This also includes the humility of being willing to learn from anyone, including developers who haven't been in the profession as long or haven't accomplished as much as you - ego can get in the way of challenging yourself to better yourself, and maybe that more junior person will indeed become better than you/has better intuition.

Make sure you get good rest too - all the learning in the world won't help you if you cannot retain what you learn. If you're in a pressure cooker of a job, consider transitioning to a less stressful job to give yourself space to work on yourself so you're better prepared for the long haul/set yourself better up for success.

Lastly, focus on being a problem solver - this means if you see a point of friction/inefficiency/tricky situation, that is something to be solved. Your success rate in solving these problems is ultimately what drives stable success. This means practice as much as possible applying your mind to these problems, and if you fail, be ruthless about figuring out what you did wrong and iterate. Very few people can get away with being excellent there with minimal effort.

Re: How I Became a Better Programmer

#14

Post by Permagate »

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…

> 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, rather than completely ignoring it (like code styles as you mentioned). He created Prettier, so I'm sure he knows the value of code styling.

Re: How I Became a Better Programmer

#15

Post by richdougherty »

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…

Responding to your last two paragraphs...

James's suggestions about ignoring code form, DRY, etc resonate with me because I'm someone who is usually inclined to spend too much time on those things. I consciously try to reduce the effort I put into those things and instead focus on trying to get the code to actually do something!

Re: How I Became a Better Programmer

#17

Post by damon_c »

richdougherty wrote: post #15
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…

Responding to your last two paragraphs... James's suggestions about ignoring code form, DRY, etc resonate with me because I'm someone who is usually inclined to spend too much time on those things. I consciously try to reduce the effort I put into those things and instead focus on trying to get the code to actually do something!

There is a good place, somewhere in the middle.

Re: How I Became a Better Programmer

#18

Post by brokenmachine »

fiatjaf wrote: post #4

He writes "find people who inspire you, but don't idolize them". And yet, his blog repository[1] which is, in his words, "This is just a stupid simple server that indexes posts off the filesystem", has 1193 stars. Why would anyone star anything like that if not because they idolize jlongster? [1]: https://github.com/jlongster/blog

I star githubs just in case I might want to read them later, with no comment implied about what I think of the author or even the content.

Re: How I Became a Better Programmer

#19

Post by pacaro »

damon_c wrote: post #17
richdougherty wrote: post #15

Earlier quoted context omitted.

Responding to your last two paragraphs... James's suggestions about ignoring code form, DRY, etc resonate with me because I'm someone who is usually inclined to spend too much time on those things. I consciously try to reduce the effort I put into those things and instead focus on trying to get the code to actually do something!

There is a good place, somewhere in the middle.

Always, but with regards to writing clean code, it pays to just learn how to do this upfront. An analogy is of cooking. I used to be a very messy cook, the food is just as good, but when I was done the kitchen looked like a bomb had hit it. Cleaning becomes intimidating at that point. Learning to be cleaner in my processes didn't change the end result for the food, but made the rest of the evening much more pleasant. Professional cooks and chefs learn to optimize this, they are neat and clean where this is most efficient, and offload cleanup to a plongeur where necessary.

Secondly I believe that with practice, DRY can become second nature. Back in the mid 90s I wrote a lot of COM code in straight C (for reasons). This ends up being extremely verbose, so repetition carried a sufficient penalty that I learned to avoid it, to carry a sufficient mental model of the code base to know when I could avoid repetition.

[edit] plonjeur -> plongeur

Re: How I Became a Better Programmer

#20

Post by jredwards »

Permagate wrote: post #14
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…

> 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.
Post reply on HN