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

31–40 of 125 posts

Re: How I Became a Better Programmer

#31

Post by BurningFrog »

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!

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.

Re: How I Became a Better Programmer

#32

Post by nitely »

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

His previous blog did react.js server side rendering. That's prolly it. Plus, may be it was an advice to his followers as well.

Re: How I Became a Better Programmer

#33

Post by thr0waway1239 »

pacaro wrote: post #21
markwaldron wrote: post #16

Those that are complaining about this article: Care to share the experiences that made you a better programmer? Can you link to blog posts yourself or others made that we may find useful?

I like this question! I think that working in constrained environments early in my career gave me lasting instincts both for efficiency and maintainability/sustainability. I wrote a lot of code on Win16, GeoOS, Epoc32, and a variety of embedded systems. Debugging tools aren't good, the dev-test-repeat cycle can be arbitrarily long, so you learn to avoid a certain sloppiness. I've been having fun with PICO-8 on a Pock…

Reminded me of this story about Donald Knuth:

https://www.quora.com/How-would-Donald-Knuth-fare-as-a-compe...

Re: How I Became a Better Programmer

#34

Post by keithnz »

I agree with the author, I think people are getting too hung up on the "fluff" statement. His point is that their are deeper issues in programming that will make you a better programmer. Still useful to write clear concise code, just don't get hung up on it, and certainly don't mistake it for being a good programmer.

My other piece of advice would be to code with other people as much as you can, ideally from very different programming backgrounds.

Re: How I Became a Better Programmer

#35

Post by pacomerh »

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…

Same thought here. He makes it sound like he got to the finish line. This is an infinite journey. Good read though.

Re: How I Became a Better Programmer

#36

Post by pacaro »

couchand wrote: post #26
pacaro wrote: post #19

Earlier quoted context omitted.

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

I love your use of the cooking metaphor here. Are you expanding on Uncle Bob's discussion of it in The Clean Coder or was that just a coincidence? If I remember correctly, he uses it there to describe the difference between delivering quickly once (and making a mess in the kitchen) and reliably producing over the long term (by taking a little extra time to clean as you go). Adding the spin about the learning process…

I'm thinking more of the "You cannot be Mommy!" scene from the movie Ratatouille

Re: How I Became a Better Programmer

#37

Post by zoul »

pacomerh wrote: post #35
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…

Same thought here. He makes it sound like he got to the finish line. This is an infinite journey. Good read though.

He explicitly writes:

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

Re: How I Became a Better Programmer

#38

Post by smp_ »

BurningFrog wrote: post #31
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!

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.

That's ok assuming that time ever comes; pressure to deliver new features or just the possibility that you move on and it stops being your code and becomes someone elses means you may never get a chance to look at those ugly things. I think there's a middle ground that takes that kind of uncertainty into account and is pragmatically wary of 'ugly' and 'improvised'

Re: How I Became a Better Programmer

#39

Post by Fifer82 »

I also have 10 years experience but I am in the same job because I can't defeat recruitment agencies. If today a new Framework, let's call it "Framework9" is announced, all jobs will instantly want 3 years experience, and 4-5 years experience of all other known frameworks, preferably in all languages, and preferably a designer who is a master of photoshop and CSS, with a long history of blah blah blah blah

I am really starting to wonder what other careers are possible as this kind of sucks. I am especially bad at bullshitting so I don't really get anywhere.

Re: How I Became a Better Programmer

#40

Post by bobwaycott »

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 met James around 9 years ago when I was first starting out in professional development, before he eventually joined Mozilla. I inherited more than one massive project from him, and I'd like to assure you he did not actually ignore the form of his code, nor did he avoid improvements that paid huge dividends. I've always been rather OCD about DRYness, and I never had cause to complain about the quality of his work, nor was there ever much of any duplication.

I believe the spirit of what he's trying to get at is not letting concern for DRYness stand in the way of working things out. I saw this in practice many times, and even approach complex projects in much the same way--I'll typically not worry about DRYness until I've implemented something a couple of times, sometimes in different ways, to get a feel for how I can approach it best. Once I've figured that out, I clean things up.

I've seen many junior devs get so worried about the quality of their code, and how they should do things, and omgosh, DRY that they can often become paralyzed and don't just start writing code. I've been mentoring someone for nearly 18 months, and I'm always trying to push him to just start coding and get something working, then come back and discuss and evaluate his work together.

I think you've misunderstood what James has said, and feel compelled to push back on any suggestion that his advice regarding DRY and duplication is borne of any misunderstanding or lack of recognition of the value of DRY. Nor is he someone who I've ever seen stop learning. I keep up with his work, and I'm always impressed by the different things he picks up just because something about it interests him.

Post reply on HN