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

101–110 of 125 posts

Re: How I Became a Better Programmer

#101

Post by BurningFrog »

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.

Several people made the same argument, so I'll try to answer it here:

I'm talking about one single commit.

If I spend 4 hours on a story, the last half hour is probably spent cleaning up things. That's when it's easiest to do, because now that the problem is solved, I understand things the best, and the code is not in flux.

I do not have to ask a manager for permission to do this. If you do, you should really try to find a job where you're trusted to make these simple technical decisions.

Re: How I Became a Better Programmer

#102

Post by ant6n »

AstralStorm wrote: post #88
tshannon wrote: post #77

Earlier quoted context omitted.

Yep, I agree. I see it more as a list of priorities, not necessarily sequential steps. 1) Make it work 2) Make it maintainable 3) Make it fast All three should be on your mind when developing something, but if you have to choose between 2 and 1, go with 1.

And you end up with the 60+ year old TODO this way. Or lack proper reason comments (the why) and end up in a gaggle of legacy code. My rule is simpler: never write instant legacy code. If it feels like something you won't understand a month later, it likely is legacy code. If it reads badly (and I'm not talking about this or that brace or whitespace choice), then it also provably is in that category.

If there is actually a trade-off like tshannon notes, then by not making it work first, you may end up with un-finished projects.

Re: How I Became a Better Programmer

#103

Post by hinkley »

vdnkh wrote: post #98
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.

Generally I think developers don't see our 60 year history as a liability. We've only begun to figure stuff out (the 90's and early 00's were punctuated by arguments over Tony Hoare's work in concurrency, that was all done in the mid 70's by people who don't seem to be aware that they were all written by a single person).

I think specifically it helps to deep dive on something that is much older than programming. A craft, an art, a sport, or a physical passtime (dancing, martial arts, kayaking). People have been teaching that stuff for centuries and it turns out they actually know a few things that we only pretend to know. Two things in particular stand out.

Cross-training is one. The notion that pushing harder, white-knuckling everything, is a virtue in software development is rarely ever challenged. Not good yet? Just keep doing it.

The second is that we don't get that rules exist in a context. Always do this. Never do that. As you mature it is partly your responsibility to figure out when you are no longer part of that context. When you are ready, you will understand why you had to follow the rule and why you are now free of it. Look at the backlash against DRY. A bunch of people who've been using it for 10-15 years figuring out it's not all roses. See also: 'it depends...'

Re: How I Became a Better Programmer

#104

Post by AstralStorm »

ant6n wrote: post #102
AstralStorm wrote: post #88

Earlier quoted context omitted.

And you end up with the 60+ year old TODO this way. Or lack proper reason comments (the why) and end up in a gaggle of legacy code. My rule is simpler: never write instant legacy code. If it feels like something you won't understand a month later, it likely is legacy code. If it reads badly (and I'm not talking about this or that brace or whitespace choice), then it also provably is in that category.

If there is actually a trade-off like tshannon notes, then by not making it work first, you may end up with un-finished projects.

The solution to making it work first is to make a prototype with the correct design. You do not have to implement it at once.

(On C2 wiki, a proper SpikeSolution)

If you hit a case your design cannot cleanly handle, it is time for redesign, but often a tiny amount of design constrained by use cases will expose a good design quickly.

Re: How I Became a Better Programmer

#105

Post by AstralStorm »

BurningFrog wrote: post #101
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.

Several people made the same argument, so I'll try to answer it here: I'm talking about one single commit . If I spend 4 hours on a story, the last half hour is probably spent cleaning up things. That's when it's easiest to do, because now that the problem is solved, I understand things the best, and the code is not in flux. I do not have to ask a manager for permission to do this. If you do, you should really try to…

Can you really clean up a bad design in a bunch of minutes?

Re: How I Became a Better Programmer

#106

Post by AstralStorm »

cloverich wrote: post #92
jredwards wrote: post #20

Earlier quoted context omitted.

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

For actual redesign, you end up with a long true refactoring iteration when no new features can be added. There is no guarantee you will not repeat the same mistakes or make it worse.

It is a very tough sell to most customers.

The quick cycle does not scale with project size.

Re: How I Became a Better Programmer

#107

Post by mythrwy »

tshannon wrote: post #77
fauigerzigerk wrote: post #59

Earlier quoted context omitted.

>The time to clean up the code is when it already does what it should. I'm a bit skeptical of that as a general principle. I want code to be a consistent representation of my mental model of the solution at all times . I use code to help me think, remind me of my thinking and communicate with others. It's not just a series of commands that make a machine do something. As long as any ugliness is not in conflict with t…

Yep, I agree. I see it more as a list of priorities, not necessarily sequential steps. 1) Make it work 2) Make it maintainable 3) Make it fast All three should be on your mind when developing something, but if you have to choose between 2 and 1, go with 1.

They never give me the time for items #2 and #3. As soon as it works most clients and bosses figure "done".

Re: How I Became a Better Programmer

#108

Post by BurningFrog »

AstralStorm wrote: post #105
BurningFrog wrote: post #101

Earlier quoted context omitted.

Several people made the same argument, so I'll try to answer it here: I'm talking about one single commit . If I spend 4 hours on a story, the last half hour is probably spent cleaning up things. That's when it's easiest to do, because now that the problem is solved, I understand things the best, and the code is not in flux. I do not have to ask a manager for permission to do this. If you do, you should really try to…

Can you really clean up a bad design in a bunch of minutes?

I'm mostly talking about minor cleanup like finding the best names, removing duplication, deleting unused code. That can be done quickly, and is often easiest once the dust has cleared and the design is finished and working.

If the code is working but is badly designed, that can take longer.

Occasionally, the new feature requires larger refactorings to redesign preexisting code. That can take days, but is of course essential to do.

Re: How I Became a Better Programmer

#109

Post by BurningFrog »

mythrwy wrote: post #107
tshannon wrote: post #77

Earlier quoted context omitted.

Yep, I agree. I see it more as a list of priorities, not necessarily sequential steps. 1) Make it work 2) Make it maintainable 3) Make it fast All three should be on your mind when developing something, but if you have to choose between 2 and 1, go with 1.

They never give me the time for items #2 and #3. As soon as it works most clients and bosses figure "done".

How does that work exactly?

Why can't you just keep working until you consider your task done?

Post reply on HN